| 编辑推荐: |
| 本文来自于人人都是产品经理，如果一个产品经理只关注创造需求而忽视需求实现的过程，那么这个产品也很难说会成功，因为执行落地才是最重要的。 |
|
很多人说这个流程更适合初创产品，对于发展中特别是成熟期的产品，是不是就不需要考虑这么多了，其实我感觉不管是初创期的产品，还是迭代过程的产品，都可以用该流程去思考，这也是产品经理培养高阶思维的一种训练过程。当然对于每一部分，需要掌握的知识和技能也是非常多的，后续有机会我们会逐一总结。
好的产品策划设计是成功的一半，但当我们满怀希望憧憬产品上线的样子的时候，却经常发现，产品无法按期上线，开发出的功能和期望很大，过程中产品和技术打架，产品和运营相互吐槽，终究原因就是产品开发管理过程是混乱的，所以产品管理也是我们产品运营体系的一个重要环节，一个好的产品经理，不仅要具备创造性的思维和业务能力，也要具备工程思维和管理能力，所以产品管理体系我们从产品经理的主要职责作为梳理。
产品经理（负责人）要管理全周期
我们经常混淆产品管理和项目管理的概念，简单的说，产品管理重需求（管理），强调产品实现的持续过程；项目管理重任务（管理），强调任务完成的整体协调。从管理周期上来看的话，产品管理过程中包含了项目管理，而且一个产品管理过程可能包含了多个项目管理。我们通过下图来了解产品管理的主要过程：
一个产品功能的开发要从需求探查开始找业务机会，产品经理要负责召开需求评审，确定产品可行性。一旦产品确定开发，产品和技术将并行进行方案的设计，特别对于技术要求比较高的产品，技术的可行性调研和架构就要开始，同时产品团队将需求和业务场景结合，设计最终的产品形态。这几个过程就是我们在第一篇文章中所涉及的部分。接下来进入开发测试过程，在这个过程中很多产品经理会犯的一个错误就是认为这个管理过程属于技术团队，就和自己没关系了。这种想法是不对的，产品经理要对产品最终的结果负责，为了保证自己想要的结果，需要和技术团队进行密切的协作，监控整个开发过程，协调相关资源，共同保证产品交付。
一个项目目标的实现就代表项目过程的结束，而产品管理过程却是一个不断迭代的过程，因为一旦一个版本的产品投入市场，也就意味着通过市场和运营的反馈将产生新的需求和调整，一个新的过程又开始了。
所以，产品经理不仅仅和技术团队协作生产，同时要和市场、运营甚至是用户等各种角色的人进行协作，来保证产品持续的生命力。我们常说，产品经理是没有权利的小CEO，这话一点没错，他需要非常全面的能力和协作，正如下图一样：
产品经理要做好版本规划
初级的产品经理经常犯的一个错误是太关注自己的创意和需求，而不关注需求实现的过程。我在工作中也经常碰到产品和技术互掐，技术说按照领导期望的时间完成不了，希望产品减需求、分阶段。而产品经理就不想减需求，他希望自己的创意能全部实现出来。其实这就是我们为什么要做产品版本规划的原因：资源和时间的冲突。资源总是不够的，时间也总是不够的，为了保证产品持续的成果，我们必须要控制自己的欲望，合理的安排产品需求实现路径。
既然要做产品版本的规划，那么我们应该去规划版本呢？
1.0版本很重要，这是产品的起点
新产品上来第一个版本从开发到上线时间相对较长。按照我们前一篇文章介绍的，此版本的功能一定要紧扣定位，重点要解决用户痛点，不要贪多，贪多反而淡化了定位和产品亮点。比如微信最开始就是定位的移动IM，解决人与人连接的问题，所以微信第一版上线就非常的简单，就是基于手机移动端的即时通讯，甚至这个版本连发语音功能都没有。
大版本的规划考虑战略需求
首先看看微信的大版本的核心功能：
微信1.0：移动IM，图片分享，微信诞生；
微信2.0：语音消息，视频消息，微信成功的基础；
微信3.0：摇一摇，陌生人社交；腾讯新闻等外部插件，平台化初试；
微信4.0：万能的朋友圈来了；公众平台上线；平台化战略正式开始；
微信5.0：微信支付来了，内容能搜索了，深入到人们日常生活，商业化开始；
微信6.0：微信生态，链接一切。
大版本规划基本上都是基于每一步的战略需要来设计的，其实对应的是公司的整体战略规划，基本上以年为单位。产品经理要深刻领会高层的战略需求，并进行具体的产品功能的策划设计，保证战略的实现。
小版本的规划考虑运营需求
大版本的周期很长，方向相对稳定，即使战略调整也并不是一早一夕就能完成，相对比较容易控制。大版本上线以后，接下来就是产品的小版本迭代了，如何来做产品的迭代呢？可以从以下角度考虑：
确定你的产品架构；
拆分架构实现的步骤；
根据步骤，确定需要的支持功能；
根据功能关联耦合情况，拆分成需求story；
根据数据表现、人力、运营计划、市场资源配合情况，确定版本story。
所以，小版本的规划既要契合大版本的战略需要，而且又要和公司其他业务部门紧密的配合，通过市场、运营甚至客户的推动，共同制定迭代的版本计划。在版本的迭代计划中，新功能的产生和比较重大的变更，一般采用0.x版本进行管理，周期根据各自自己情况，控制在一个月到一个季度。bug的修复和小功能更新，可以采用0.1.x版本进行管理，周期一般在一周到一个月。在这种快速的迭代过程中，更需要敏捷的产品开发过程：
产品经理要管理好需求变更
上图虽然很夸张，但是不得不说，产品和技术的战争很多时候都来自于需求的变更。虽然我们每次都做了版本规划，但是很多时候计划跟不上变化，所以需求的变更是不得不面对的，为了保证产品过程的有序，需要建立需求变更机制。
首先我们需要清晰的认识需求变化对项目的过程所产生的影响。如上图所示的项目管理的铁三角，直观的反映了项目中各个变量元素的关系。所以，我们需要统一一下认识：
加/改需求，或者要延长项目时间；或者替换掉相等工作量的需求；如果又不想延长时间，也不想替换掉原有需求，只能找boss协调资源，增加成本，否则只能牺牲质量了。
除了思想意识的统一之外，做好需求变更管理我们还应该：
建立需求池机制
产品经理日常最需要关注的三个东西：当前版本、下个版本和需求池。需求池就是对于现在开发的版本的可量化的描述，就像水池一样，水多了就溢了，水少了资源就没充分利用，对于需求也是。既然可量化，产品经理应该对每个需求需要的开发人天和总周期人天要足够明确，对于需求的优先级和重要级别有个排序。这是我们合理变更需求的基础！
建立需求的评审机制
对于需求变更一定不要着急动手，因为需求变更后影响到后续的所有环节，存在着很大的风险，这个风险既不是产品团队承担，也不应该让技术团队承担，而应该是和产品相关的整个团队共同承担，甚至包含老板和客户。所以需求的变更需要进行评审，评审的目的不仅仅是让相关人都签字确认，更多的还是让大家再仔细的思考、讨论，变更需求所带来的风险，是不是要变更需求！所以需求的评审尽量各相关岗位的决策人都要参加。
统一需求的入口
当一个项目，失去统一的需求入口，当一个产品经理失去对入口的控制，意味着项目的失控。任何一个需求都不是孤立存在的，只有当需求入口统一，才能够整体的判断需求的价值，明确当前的资源使用状况，合理的安排需求的实现关系。过去我一直在纠正运营人员直接向技术提需求的问题，运营人员的需求（除非bug）必须要经过产品经理，由产品经理统一提交给技术。
可持续跟踪的管理工具
需求的变更不是口头上交代就完事的，一定要记录备案，甚至签字画押，正所谓口说无凭，立字为据。这也是避免后续出现问题，出现各方扯皮，踢皮球。
最后说一句，一旦当前版本需求确定，尽量不要变更，少变更，而且变更一定要尽早。产品的开发节奏对一个产品经理是非常重要的，不要去破坏这种节奏！
产品经理要持续主动的进行产品优化
和项目经理不同，项目一旦结束，项目经理的职责也就完结，而产品是一个持续迭代发展的过程，产品的上线并不是工作的结束，而是新一轮工作的开始。产品经理如何做好产品优化，可以参考以下几点：
关注运营数据，多做灰度测试、AB测试，用数据说话；
及时收集市场、运营等相关业务部门的反馈和需求；
保持和用户的互动，获取终端使用者的反馈，提升产品体验；
紧跟趋势，不挑战用户习惯的基础上，开拓创新。
如果一个产品经理只关注创造需求而忽视需求实现的过程，那么这个产品也很难说会成功，因为执行落地才是最重要的，所以产品经理要具备产品管理的能力，以上总结的产品管理体系希望能帮到大家。 |
