做为无所不能的产品经理，虽不是上知天文下知地理，但是也要对产品相关的知识领域有所涉猎。项目管理就是与产品密切相关的一个知识领域，同时也是产品经理日常工作中经常要负责的一部分内容。别问我为什么不是项目经理负责，因为很多公司没有……

本文结合实际工作实践以及亲身使用CORNERSTONE项目管理工具经验，深入浅出介绍在敏捷开发的互联网公司中一个项目从无到有所经历的各个环节，当然项目管理这门学问还有很多需要深入探索的领域，以下仅仅与各位产品/项目经理们，学习交流一下。

一、做产品还是做项目？

产品就是项目，项目就是产品。

在很多敏捷开发的互联网公司中，产品是项目制，功能也是项目制，在策划一个新功能的时候，对于产品经理来说就是在策划一个项目。

在PMBOK第六版的官方指南中，项目指为创造独特的产品、服务或成果而进行的临时性工作，项目有固定的起止时间周期。

在大一点的互联网公司，多个产品经理为同一个产品服务，每一个产品都会绞尽脑汁想一个idea去实现产品、用户的价值提升。

每一个idea就是一个项目，当项目经历了立项、启动、执行、上线、收尾，这个项目就变成了产品的一个功能或一个服务。

二、项目的生命周期

一个产品从无到有，从生到死会经历多个需求、交互、设计、计划、开发、提测、上线、hotfix、解决线上问题、运维、运营的生命周期闭环。

而在产品生命周期当中也会包含多个项目的生命周期，每一个项目都会经历项目启动、项目执行、项目监控、项目收尾（PMP中项目的五大过程组在这里被缩减成为了四个，其中项目启动包含了项目启动和项目规划）。

1. 项目启动

1.1 需求收集

CORNERSTONE为需求生命周期搭建流程，可以自定义更改按收集、评审、排期、设计、开发、发布设立多个阶段，在不同阶段把任务分发给产品、设计或者开发人员，让需求完成无缝衔接。这个阶段其实是产品经理最擅长的领域，即为什么要做这个项目？

在这里可以参考精益创业画布中的9个要素去回答：

1. 服务的用户群体是谁？

2. 解决的问题是什么？

3. 解决方案是什么？

4. 你的优势是什么？

5. 衡量效果的关键指标是什么？

6. 与竞品相比，你的门槛优势是什么？

7. 项目成本有多少（人力成本、时间成本）？

8. 项目收益有多少（收入、用户感知）？

回答好上面的9个问题后，就可以拿着你的idea去和其他产品pk了，能不能获得老板们的资源倾斜成功立项，就看你的项目能不能真的打动老板。

在这之中，对于老板来说，往往更关心项目成本和收益：即用最少的人力、时间成本，得到更大的收入、用户价值提升。

在这个阶段，对于负责项目的产品经理来说，需要输出的是需求文档及原型，这是你用来打动老板的基础，也是需要与涉及项目团队成员沟通需求的基础。

1.2 项目启动会

在立项会上顺利从老板那里获得资源后，项目可以真正开始启动了，这时就需要召开一个项目启动会，将项目涉及的各个团队召集到一起，给大家讲一个充满想象力的美好故事，让大家为了这个目标而努力。

好吧扯淡完了，具体需要做哪些呢：

1. 明确项目要做什么，其实在这个环节，就是给各团队的同学讲为什么要做这个项目，这个项目能解决什么问题，带来什么样的收益，用项目价值去打动各团队一起努力比老板说必须做这个理由更有说服力和感染力，也会让所有人全心全意去为项目努力付出

2. 明确各团队的职责，即为了这个项目需要做哪些功能的新增或对现有功能的优化。

3. 明确时间节点，即针对于上面提到的功能或优化，各团队开发、测试以及联调的时间节点，明确时间节点可以保证项目可以在计划的时间内完成。

4. 明确项目干系人：项目负责人、技术负责人、测试负责人，在遇到问题时可以找到对应负责人沟通。

这个阶段，在项目启动会完要出一份会议纪要，周知项目涉及的所有成员。

注意：不仅仅是与会人员，有时在项目启动会参与的同学也许仅仅是各团队的主要负责人，并不一定是最终参与项目开发和测试的同学。

所以在会议结束后将会议的内容整理成邮件，群发涉及各团队的所有成员。

会议纪要邮件中可以附上项目需求文档及原型，方便项目成员理解，同时还需要在会议纪要中明确项目启动会中确定的几个关键要素：

• 项目负责人

• 项目中各团队需要做的功能或优化的功能点

• 项目的时间节点：开发时间、测试时间、联调时间和上线时间

在CORNERSTONE里，可以同时并行管理多个项目。每个项目清晰明确可见责任⼈、任务状态、优先级、类别、时间等多维度信息，帮助企业快速⾼效的对项⽬进⾏全周期管理。

1.3 需求讨论及需求分析

作为产品经理，你可能是某一个项目的负责人，也可能是项目相关团队的产品经理。

无论哪一个，你都需要针对自己团队负责的任务进行需求整理，与自己团队的开发、交互视觉设计、测试确认需求、评估需求。CORNERSTONE讨论功能可供团队成员互相交流,共享信息,解决自己在工作中遇到的各种问题。

基于需求文档与开发、测试、设计进行沟通，确认需求并由相关人员给出工时。

在需求确认阶段要注意的是：每个迭代的人力成本和时间成本是有限的，并不是所有的需求都要在一个迭代干完，参照MVP设计原则，项目也是按照一期二期这样规划的。

所以在需求确认过程中，确认需求的优先级及排期，哪些必须一期实现，哪些需要在二期进行完善。

在进行需求优先级排序的过程中可以参考KANO模型，同时也要根据需求点的工时排列，保证在当前排期内可以完成。

这个阶段，输出的文档并非需要由产品负责，而是由具体的开发人员、测试人员、设计人员给出各自负责功能的任务项拆分，细化到天的颗粒度，保证任务是在监控的范围内。

2. 项目执行与监控

2.1 项目执行

需求确认、工时评估完成后，正式进入项目执行阶段，由相关成员进行开发、设计及测试。CORNERSTONE的甘特图功能可方便管理者弄清项目的剩余时间，评估工作进度，调整工作任务，更好地把握项目的整体。

2.2 站立会、周会

每日站立会以及周会是保证项目正常进行的手段之一，通过每天的站立会沟通，确认团队成员是否遇到了问题，针对问题进行及时沟通与解决，保证项目可以正常进行。

如果项目时间较长，通过周会可以统计周期内好的现象以及遇到的问题，通过会议总结，让各团队了解当前项目进度以及遇到的阻碍。

对于跨团队的项目，往往没有时间聚集起所有团队成员一起进行会议沟通，可以由项目负责人与各团队负责人进行周期性沟通，确认可团队的项目进度。

这个阶段，项目负责人会输出项目周报，周报的内容主要包含项目当前进度，项目遇到的问题与阻碍，项目下一阶段的计划，涉及各团队的关键里程碑节点。

2.3 联调

联调往往是跨团队项目需要考虑的问题，只要项目涉及的团队大于两个，就需要进行项目联调，保证各自团队负责的功能模块不会因为新的需求出现问题。CORNERSTONE针对这一需求，提供了全局报表（项目进度）。方便管理者了解项目分布、进度计划、质量风险等，并从中获取客观的实时数据，帮助管理人员分析、评估项目，全面了解组合内项目状况，以便作出及时决策。

如果涉及多团队涉及从前到后的流程变更，需要在联调前，召集各团队测试负责人进行沟通，明确测试范围、测试时间以及回归范围，保证项目上线时新功能模块的使用以及之前兼容功能的正常使用。

在测试联调阶段，需要每日召开团队间的站立会，确认各团队之间测试遇到的问题，如环境问题、版本问题等，提高测试效率，保证上线时间和上线质量，不要因为测试不充分出现上线后回滚的问题。

2.4 项目监控

项目监控，是保证项目进度，保证项目可以在规定时间内保质按时上线。CORNERSTONE中管理者可根据项目创建情况，可实时更新项目状态，预警项目风险。简单来说就是：对项目风险的管理——遇到项目风险如何处理，如何解决。

项目风险的可能性有很多，比如开发的delay、测试出现严重bug、业务需求方在项目进展过程中频繁变更需求导致工时无限延长等等。

CORNERSTONE在可视化的平台活动图上，任意自定义不同纬度统计卡⽚，可⼤⼤⽅便项⽬经理全⾯掌握项⽬进度和团队表现，了解每位成员⼯作产出与⼯时，提前化解潜在⻛险；同时⽀持⼀键分享卡⽚内容。

这里的沟通可能是向上沟通也可能是平行沟通，发现问题背后最本质的原因，基于此去解决问题，如果风险过大真的导致项目的delay，那么也要许沟通项目的各个相关方，保证当前线上不会出现问题。

3. 项目收尾

结束是新的开始，项目也好、产品也好，只要没有死，就一定还会有新的开始。

在产品的生命周期中，包含着无数个项目，这其中有好的项目也有不好的项目。

每一次的项目上线或收尾，都需要对项目进行一次复盘和回顾，发现项目过程中的优点与不足，优点继续保持，不足找到解决方案，在下一次项目中尽可能的避免。

在项目上线后，召集项目成员进行项目的总结与复盘，同时基于项目上线后的效果进行监控，为项目的下一期规划提供指导意见。

如果通过项目发现与市场、用户完全不契合，那么尽快放弃寻找新的方向；如果项目效果还不错，还有值得优化提高的地方，寻找可以优化的点进行新的排期与规划，通过不断的迭代提升产品价值，为用户创造更大的价值。

  三、总结

做项目与做产品一样，都是一个不断迭代不断打磨的过程，对于产品经理来说尤其是对于没有项目经理配合的产品经理来说，并不是产品需求确认后就可以坐等产品上线了。

在产品开发过程当中，不仅要考虑未来产品的规划，还要关注当前产品的进度，通过沟通、监控、协调，保证当前功能可以正常上线，否则再多的规划如果无法真的落地，也终究是规划。

做产品就是做项目，一个优秀的产品经理也必然是一个优秀的项目经理，优秀的产品/项目经理，搭配上好的项目管理工具，必然会对项目开发起到事半功倍的效果，项目管理工具我只推荐CORNERSTONE。