针对当前一些体型较小的传统企业转型互联网时,产品经理与传统部门的项目负责人确认需求时,效率低下、沟通思路不明晰、沟通成本居高不下的问题。为了减少传统部门领导经常提出与项目愿景偏差性比较大的需求,使立项的项目能为公司战略实施发挥更大的价值,同时提高部门之间的沟通效率,节省时间成本。所以特意写了这篇文章,希望能够帮助一些小型企业梳理互联网项目的开发思路。
作为项目的开发人员,做的每一款产品都倾注了自己的脑力与心血,开发人员对项目负责任程度比其他人可能更大。无论从自己的事业历程来讲,还是从从业道德与责任来讲,他们可能更有意愿和驱动力来把这款产品做好。有时候他们提出的一些看法,还是值得斟酌的。
下面的几点思路,希望能够帮助小型传统企业中参与互联网项目的人员,去理解产品开发思想:
一、新项目立项需要明确新项目的总体战略意义
在一个企业中任何一个项目的立项,都需要服务于公司的战略规划。做一款互联网项目与我们做一件事是一个道理,我们必须要明了的一个思想是:我们做每件事都会直接或者间接的对应一个目标。同样,每一个应用的开发都会遵循和服从一个企业的战略目标。比如我们公司的“校营通”项目最终的愿景是“打造一个能够凝聚天地人和潜在客户群体的社区(论坛、直播、互动、资讯),用来提高天地人和在行业中的凝聚力、聚合力,为提高客户成交率、提高行业地位、品牌形象,而实现应用本身的价值”。
一个项目在成立之后,如果没有一个清晰的定位,没有一个清晰的使命,眉毛胡子一把抓的话,那么这个项目对公司的发展产生的作用与意义都是不明了的,并不能作为公司发展整个系统的一个关键环节,并不能发挥其应有的作用,也就是说这个项目的设立可能是没有意义的。
所以,我们需要赋予我们的项目一个使命,一个清晰的战略目标,具有规划性让项目逐步成长,让它能够更好的、更有步骤性的服务于公司的发展,从而为公司发展提供更大的价值。
二、应用版本更迭规范
1、大版本更新,比如2.x更新到3.x:相当于应用在向应用最终愿景,迈了较大的一步;现实表现为,增加或者更改了一项不同于当前阶段的主要功能。
2、小版本更新,比如2.1更新到2.2:是当前版本的战略阶段主要功能的充实、打磨,更好的实现当前战略阶段的功能,实现当前版本的价值;其现实表现为增加相关性比较强的功能,打磨优化现有主要功能,使客户拥有更好的体验。
3、微小版本更新,比如2.3.1更新到2.3.2:不做任何战略性规划或者调整,其现实表现为修复当前版本的bug。
4、功能预热,任何对于客户需求强度不确定的新增功能,都需要试探性的在应用中的发现模块中,统计运营数据,为功能是否提炼成一个功能的决策提供依据。
三、提需求的三条原则
1、首先要理解项目的愿景目标,产品定位;
只有了解了项目的愿景目标和产品定位之后,才能为项目添加合理的,符合产品定位的需求提供思想与理论基础。不至于使项目沦落为诸多功能堆加的大杂烩,从而成为一款失败的产品。
2、每次版本更迭,都需要逐步的靠向项目的愿景目标;
由于市场占有率、客户认可度、应用知名度,公司内部原因等等一系列综合因素的作用下,我们更迭的多个版本并不一定是立即服务于项目的终极目标,但是每个版本应该有其阶段性的意义,应该给每个大版本更迭赋予一个阶段性的战略意义与目标。
3、提出的需求要与当前项目的定位与愿景相符合;
我们为项目提出功能需求时,应该围绕项目的愿景出发,斟酌思考提出的功能需求是否适合在当前项目中开发。
如果提出的需求与项目愿景不是很契合的话,可以思考以什么样的恰当形式来达到我们的目的、实现我们的目标。应避免使我们的项目变成大杂烩、定位不清晰、思路混乱的产品,从而提高项目质量,使项目能够持久的、更好的为公司战略目标服务、更好实现这款互联网产品的价值。
如果提出的需求与当前项目的定位不符,或者无助于项目的愿景目标的话,可以考虑当前提出的需求的意义与目标,可以整理思路,综合考虑当前提出的需求是否满足成立一个新项目;如果成立新项目的可行性不成立的,可以在当前项目的发现模块中,在不影响当前项目格局的情况下,暂时开设一个当前需求的新功能模块。
综上所述,此文的目的在于,在小型传统企业在互联网转型过程中,为项目负责人规划项目开展与更新迭代提供理论基础,提高项目负责人与技术开发部门对接新需求的效率,减少沟通成本,更好的为公司的发展贡献自己力量,实现价值。希望项目负责人能够理解项目的阶段性意义与最终的战略愿景,从而更合理的制定需求,让成立的项目能够持续健康的发展,少走弯路,节省资源,使公司更好更快的向前发展。
网友评论