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