产品经理如何进行项目管理流程篇

　　闻道有先后，术业有专攻，一个优秀的项目经理在产品迭代的过程中，有着不可小觑的作用。然而在大部分互联网公司，由于团队规模的限制，产品经理往往会承担一定的项目管理职能，那么产品经理应该如何做好项目管理呢。我曾在任职期间以产品经理身份兼任项目经理一职，就产品经理如何进行项目管理这一话题给大家带来分享。
　　上一篇讲到了项目管理的一些理论知识，这篇文章中给大家带来这些理论知识如何在整个项目管理过程中实施。在传统的项目管理过程中，标志一个项目开始的事件是项目立项，由项目经理填写立项申请并提交可行性报告（市场可行性、技术可行性等），如果领导审批通过，则立项结束，项目正式开始。而在互联网行业，并没有立项这个过程，产品通过增量迭代的方式发布，用户的需求不断，产品的迭代不停止。在一次产品迭代过程中，大概会经历以下几个阶段：
　　产品设计阶段
　　产品经理从各个渠道收集用户需求，这些需求有可能是用户的真实反馈，有可能是公司的战略规划，也有可能是某个线上bug的修复，根据优先级的不同，产品经理对这些需求进行优先级排序。有了排序好的需求清单，产品经理就可以根据优先级来进行需求调研和需求分析了，这个过程是伴随产品迭代过程一起发生的。
　　有了初步的产品方案之后，我们要进行2个判断：
　　我的方案是否对其他的产品或模块有影响，很多产品经理容易忽略这一点，导致开发团队在做到一半的时候发现问题导致项目延期甚至返工。如果涉及到其他产品或模块，需要及时跟对应的产品经理进行沟通，提前判断影响的点，补充自己的产品方案。
　　我的方案技术是否能够实现，有一些产品经理天马行空的想出一些能够改变世界的idea，结果开发团队一盆冷水告诉你技术实现不了。确定自己的方案技术是否能够实现最好的办法是跟项目经理沟通，如果项目经理不能确定，则由项目经理找对应的技术leader沟通。这里千万不要直接找技术leader，你的无意打断会降低别人的工作效率。
　　此阶段的输入和输出如下：
　　输入：需求清单
　　输出：产品需求文档、交互稿、视觉稿
　　需求评审阶段
　　可行性评审
　　在我兼任项目经理初期，经常会遇到一个情况：开发团队在实现某个产品需求时，突然发现产品设计上的一些漏洞，于是跟产品经理沟通之后，推翻之前的产品方案重做；产品经理没有注意到产品或模块间的影响，导致需要临时调整方案以适应其他产品的节奏。这不仅造成了项目延期，也给团队的氛围带来影响，开发团队怀疑产品经理的能力，产品经理抱怨开发延期。经过跟几位技术leader交流，大家一致认为，需要有一个流程在开发之前介入，来帮助团队发现产品方案上面的一些问题，避免把问题带到研发阶段，所以就推出了可行性评审例会。
　　可行性评审例会一般每周会进行一次，视需求的情况而定，项目经理会邀请评审小组参加例会。可行性评审的目的是主要由技术团队发现其中可能存在的问题，给出建议。产品经理根据评审小组给出的建议优化产品方案，确保进入迭代阶段时应该为当时最优的产品方案。
　　进度评审
　　经过前面的准备，产品方案基本定型下来，伴随上一期迭代结束，项目经理组织团队所有成员参与新一轮迭代的进度评审会议。会议开始先由产品经理给团队成员解释需求的背景，产品方案的设计，并解答大家的疑惑。接下来开发团队的成员将从需求清单中挑选出满足一次迭代所需要的需求组成当前的迭代计划。挑选的过程，产品经理需要给出建议，产品经理需要从业务角度出发判断当前版本应该主要解决哪些业务问题，开发团队的成员不能只选择优先级较高的需求，或者不选择优先级较高的需求。
　　这里，我在兼任项目经理期间有一个调整，在初始时，我要求团队在会议上能够给出每个需求需要拆分成几个任务完成，每个任务需要花多长时间。后来发现，这样的做法不仅效率不高，而且在开发团队没有对需求理解透彻的基础上，给出的时间往往是不正确的，更别说任务的分解了。后来进行了调整，进度评审会议召开完成之后，我会要求开发团队不要急于动手，先仔细消化需求文档，然后由leader在下班前把每个需求需要拆解的任务和完成的时间节点告知我，由我收集整理成任务清单，通过邮件的方式告知团队每一个成员，也标志新的一轮迭代正式开始。
　　此阶段的输入和输出如下：
　　输入：产品需求文档
　　输出：任务清单
　　研发阶段
　　进入研发阶段，项目经理需要随时跟进开发团队每日完成任务的情况，尤其要确保前后端需求开发进度的同步，以确保前后端顺利对接、提测。我在兼任项目经理期间，采用每日站立会的形式，每天早上固定的时间地点，跟开发团队过一遍任务完成的情况，如果发现某个需求进度落后了，则会在会后去了解情况，做出调整。另外开发团队在实现需求时，一定要按照任务的优先级进行，切不可随意进行，这也是项目经理需要控制的。
　　另外，比较重要的是，要想做到敏捷迭代，团队一定要适应每日集成的节奏。有些开发人员的习惯是完成所有的需求再提交代码，这不仅给测试团队造成工作量突增的问题，还有可能导致其他人提交的代码无法测试。另外，在一些互联网团队，喜欢将所有需求开发完成最后再提交测试，导致测试团队前后期工作量不均衡，团队抱怨测试时间太长。每日集成要求开发团队在完成一个任务清单上的任务时，确保跟其他任务没有耦合的情况下，提交代码测试，而测试团队每天需要收集开发团队已完成的任务制定第二天的测试计划。
　　在迭代的最后阶段，测试团队会对本期迭代进行整体回归，做好上线之前最后的测试。此阶段一般是拒绝任务产品需求的变更的，项目经理需要跟产品经理明确需求变更带来的后果，如果产品经理接受后果，项目经理需要通过邮件的形式告知项目组成员和相关人员，并说明便跟的原因。
　　此阶段的输入和输出如下：
　　输入：任务清单
　　输出：待发布的增量包
　　产品发布阶段
　　产品发布后，并不代表本期迭代就结束了，项目经理需要在迭代结束之后，召开迭代总结会议，一是回顾本次迭代过程中，出现过什么问题，后续该怎么解决；二是回顾上次总结的一些问题有没有得到解决，问题是否依然持续。迭代总结记录是会议的一个重要产物，项目经理需要在会议结束后，协调关联的人员解决问题。如果没有解决问题的过程，迭代总结会议形同虚设，只是一个形式而已。迭代总结会议不仅能够帮助团队发现问题，还能够增强团队的凝聚力。
　　此阶段的输入和输出如下：
　　输入：迭代的回顾
　　输出：迭代总结记录