做为无所不能的产品经理，虽不是上知天文下知地理，但是也要对产品相关的知识领域有所涉猎。项目管理就是与产品密切相关的一个知识领域，同时也是产品经理日常工作中经常要负责的一部分内容，别问我为什么不是项目经理负责，因为没有……
本文结合实际工作实践以及项目管理方面书籍所学，深入浅出介绍在敏捷开发的互联网公司中一个项目从无到有所经历的各个环节，当然项目管理这门学问还有很多需要深入探索的领域，以下仅仅对没有过多项目管理经验的产品新人做一个入门引导。
一、做产品还是做项目？
产品就是项目，项目就是产品。在很多敏捷开发的互联网公司中，产品是项目制，功能也是项目制，在策划一个新功能的时候，对于产品经理来说就是在策划一个项目。
在PMBOK第六版的官方指南中，项目指为创造独特的产品、服务或成果而进行的临时性工作，项目有固定的起止时间周期。在大一点的互联网公司，多个产品经理为同一个产品服务，每一个产品都会绞尽脑汁想一个idea去实现产品、用户的价值提升。
每一个idea就是一个项目，当项目经历了立项、启动、执行、上线、收尾，这个项目就变成了产品的一个功能或一个服务。
二、项目的生命周期
一个产品从无到有，从生到死会经历多个需求、交互、设计、计划、开发、提测、上线、hotfix、解决线上问题、运维、运营的生命周期闭环。而在产品生命周期当中也会包含多个项目的生命周期，每一个项目都会经历项目启动、项目执行、项目监控、项目收尾（PMP中项目的五大过程组在这里被缩减成为了四个，其中项目启动包含了项目启动和项目规划）。
1. 项目启动
1.1 需求收集
这个阶段其实是产品经理最擅长的领域，即为什么要做这个项目？在这里可以参考精益创业画布中的9个要素去回答：
- 服务的用户群体是谁？
- 解决的问题是什么？
- 解决方案是什么？
- 你的优势是什么？
- 衡量效果的关键指标是什么？
- 与竞品相比，你的门槛优势是什么？
- 项目成本有多少（人力成本、时间成本）？
- 项目收益有多少（收入、用户感知）？
回答好上面的9个问题后，就可以拿着你的idea去和其他产品pk了，能不能获得老板们的资源倾斜成功立项，就看你的项目能不能真的打动老板。在这之中，对于老板来说，往往更关心项目成本和收益：即用最少的人力、时间成本，得到更大的收入、用户价值提升。
在这个阶段，对于负责项目的产品经理来说，需要输出的是需求文档及原型，这是你用来打动老板的基础，也是需要与涉及项目团队成员沟通需求的基础。
1.2 项目启动会
在立项会上顺利从老板那里获得资源后，项目可以真正开始启动了，这时就需要召开一个项目启动会，将项目涉及的各个团队召集到一起，给大家讲一个充满想象力的美好故事，让大家为了这个目标而努力。
好吧扯淡完了，具体需要做哪些呢：
- 明确项目要做什么，其实在这个环节，就是给各团队的同学讲为什么要做这个项目，这个项目能解决什么问题，带来什么样的收益，用项目价值去打动各团队一起努力比老板说必须做这个理由更有说服力和感染力，也会让所有人全心全意去为项目努力付出
- 明确各团队的职责，即为了这个项目需要做哪些功能的新增或对现有功能的优化
- 明确时间节点，即针对于上面提到的功能或优化，各团队开发、测试以及联调的时间节点，明确时间节点可以保证项目可以在计划的时间内完成
- 明确项目干系人：项目负责人、技术负责人、测试负责人，在遇到问题时可以找到对应负责人沟通
这个阶段，在项目启动会完要出一份会议纪要，周知项目涉及的所有成员，注意不仅仅是与会人员，有时在项目启动会参与的同学也许仅仅是各团队的主要负责人，并不一定是最终参与项目开发和测试的同学。所以在会议结束后将会议的内容整理成邮件，群发涉及各团队的所有成员。会议纪要邮件中可以附上项目需求文档及原型，方便项目成员理解，同时还需要在会议纪要中明确项目启动会中确定的几个关键要素：项目负责人、项目中各团队需要做的功能或优化的功能点，项目的时间节点：开发时间、测试时间、联调时间和上线时间。
1.3 需求讨论及需求分析
作为产品经理，你可能是某一个项目的负责人，也可能是项目相关团队的产品经理。无论哪一个，你都需要针对自己团队负责的任务进行需求整理，与自己团队的开发、交互视觉设计、测试确认需求、评估需求。
基于需求文档与开发、测试、设计进行沟通，确认需求并由相关人员给出工时，在需求确认阶段要注意的是，每个迭代的人力成本和时间成本是有限的，并不是所有的需求都要在一个迭代干完，参照MVP设计原则，项目也是按照一期二期这样规划的。所以在需求确认过程中，确认需求的优先级及排期，哪些必须一期实现，哪些需要在二期进行完善。在进行需求优先级排序的过程中可以参考KANO模型，同时也要根据需求点的工时排列，保证在当前排期内可以完成。
这个阶段，输出的文档并非需要由产品负责，而是由具体的开发人员、测试人员、设计人员给出各自负责功能的任务项拆分，细化到天的颗粒度，保证任务是在监控的范围内。
2. 项目执行与监控
2.1 项目执行
需求确认、工时评估完成后，正式进入项目执行阶段，由相关成员进行开发、设计及测试。
2.2 站立会、周会
每日站立会以及周会是保证项目正常进行的手段之一，通过每天的站立会沟通，确认团队成员是否遇到了问题，针对问题进行及时沟通与解决，保证项目可以正常进行。
如果项目时间较长，通过周会可以统计周期内好的现象以及遇到的问题，通过会议总结，让各团队了解当前项目进度以及遇到的阻碍。
对于跨团队的项目，往往没有时间聚集起所有团队成员一起进行会议沟通，可以由项目负责人与各团队负责人进行周期性沟通，确认可团队的项目进度。
这个阶段，项目负责人会输出项目周报，周报的内容主要包含项目当前进度，项目遇到的问题与阻碍，项目下一阶段的计划，涉及各团队的关键里程碑节点。
2.3 联调
联调往往是跨团队项目需要考虑的问题，只要项目涉及的团队大于两个，就需要进行项目联调，保证各自团队负责的功能模块不会因为新的需求出现问题。如果涉及多团队涉及从前到后的流程变更，需要在联调前，召集各团队测试负责人进行沟通，明确测试范围、测试时间以及回归范围，保证项目上线时新功能模块的使用以及之前兼容功能的正常使用。
在测试联调阶段，需要每日召开团队间的站立会，确认各团队之间测试遇到的问题，如环境问题、版本问题等，提高测试效率，保证上线时间和上线质量，不要因为测试不充分出现上线后回滚的问题。
2.4 项目监控
项目监控，是保证项目进度，保证项目可以在规定时间内保质按时上线，简单来说就是对项目风险的管理。遇到项目风险如何处理，如何解决。
项目风险的可能性有很多，比如开发的delay、测试出现严重bug、业务需求方在项目进展过程中频繁变更需求导致工时无限延长等等。
项目管理指南中指出了项目管理的铁三角：范围、成本、时间，但是在笔者看来，项目管理的本质是对人的管理，通过沟通与跟进保证项目的风险出现的可能性尽可能低。这里的沟通可能是向上沟通也可能是平行沟通，发现问题背后最本质的原因，基于此去解决问题，如果风险过大真的导致项目的delay，那么也要许沟通项目的各个相关方，保证当前线上不会出现问题。
3. 项目收尾
结束是新的开始，项目也好、产品也好，只要没有死，就一定还会有新的开始。在产品的生命周期中，包含着无数个项目，这其中有好的项目也有不好的项目。
每一次的项目上线或收尾，都需要对项目进行一次复盘和回顾，发现项目过程中的优点与不足，优点继续保持，不足找到解决方案，在下一次项目中尽可能的避免。
在项目上线后，召集项目成员进行项目的总结与复盘，同时基于项目上线后的效果进行监控，为项目的下一期规划提供指导意见。如果通过项目发现与市场、用户完全不契合，那么尽快放弃寻找新的方向；如果项目效果还不错，还有值得优化提高的地方，寻找可以优化的点进行新的排期与规划，通过不断的迭代提升产品价值，为用户创造更大的价值。
三、异地跨团队项目的坑
因为业务系统的融合，最近做了一个涉及两地跨团队的项目：后端两个业务系统之间的对接，涉及业务订单发票的全业务流程对接。
坑一：项目并没有召开启动会，两方团队对项目的重视程度不一致，导致一方将优先级排的较高，而另一方仅仅认为是换接口而已，双方没有就项目达成认知上的共识，在对接过程中积极程度不一样。
坑二：业务流程是从老流程到新流程的切换，双方前期仅仅对于业务概念进行沟通，双方认为各自对业务流程达成了一致。但是有一种你认为并不真的是你认为，这个问题在真正项目上线小流量测试的时候才发现，原来双方对业务流程的认知偏差很大，导致线上不断暴露问题。
坑三：在遇到项目风险和项目delay时，双方团队的负责人一直在针对线上问题而解决问题，并没有认识到问题出现的本质原因是双方流程上的差异，最终导致的结果就是一直在针对暴露的问题而修复，问题不断暴露，产生了持续性的delay。
对于有较为充足的项目经验的产品或者项目经理来说，这个项目中的坑都是小儿科的问题，但是对于一些初入职场负责项目管理的产品来说，还是有可能踩到的。当产品负责人感觉到自己已经深陷入项目的坑中，不如先跳出整个项目，重新去梳理遇到问题的原因，从一个旁观者的视角去分析一下遇到的问题，寻找解决方案。当局者迷，旁观者清。
四、总结
做项目与做产品一样，都是一个不断迭代不断打磨的过程，对于产品经理来说尤其是对于没有项目经理配合的产品经理来说，并不是产品需求确认后就可以坐等产品上线了。在产品开发过程当中，不仅要考虑未来产品的规划，还要关注当前产品的进度，通过沟通、监控、协调，保证当前功能可以正常上线，否则再多的规划如果无法真的落地，也终究是规划。做产品就是做项目，一个优秀的产品经理也必然是一个优秀的项目经理，也许你并不需要考PMP，但是你要对实战中的项目管理有自己的认知和方法，这样才能保证你的产品健康的活下去。
