PMP —— 项目完整生命周期

PMP —— 项目完整生命周期

前言

在网上看资料的时候，看到一篇不错的文档，简单介绍了一个项目的生命周期，按照自己的话把它记下来。

一张图项目管理（以前端角度看）

这是一张以前端（FE）角度梳理出来的项目流程图。

角色介绍

缩写	简介
项目委员会	主要负责“拍板”的个人或一群人
PM	产品经理，项目推动者，兼职项目经理职务
UE	交互设计师，负责页面布局、交互设计、不负责视图细节
UI	视觉设计师，交互确定之后，设计页面样式。注意，很多情况下，UE和UI是一个人
RD	后端开发人员
CRD	客户端开发人员，安卓和IOS
FE	前端开发人员
QA	测试人员
OP	服务器运维人员，一般负责审批上线清单

注意事项

详细流程

假定业务场景：为页面添加评论功能（发布评论、评论列表、点赞、回复），通过上述流程详细分析如何从开始到交付。

项目立项

PM作为纽带沟通立项相关适宜，以及协调团队资源，只有立项通过，PM才会出实际的需求文档。此步骤与其他岗位关联并不密切。

编写需求和需求评审

PM编写需求，结束之后会拉着各个角色开会（UE、UI、RD、CRD、FE、QA），进行需求评审。

会议的主要步骤

• 讲解需求
  叙述需求文档中的功能，包括C端的各个功能（例如：发布评论、评论列表、点赞、回复），也包括后台的一些策略（黄反、敏感词屏蔽）和统计；
• 提问题环节
  参会者提出自己岗位相关的问题，PM解答；
• 评审标准
  问题由PM以及参会人间接解答后，评审通过，表示可以做这个项目；

参会角色思考

• 关心本岗位的功能实现细节，思考是否可以实现，或实现成本（例如：需要阿里云支撑组件、外包核心业务、前端需要炫丽的交互动画，是flsh还是H5插入简单动画来实现，实现成本不同等）
• 实现人员要通过PM的讲解，表达出自我意见，如果PM有逻辑问题一定要及时提出，并纠正。

汇报工期

评审结束后，需要汇报工期。
一定不要当场决定，给定一个期限（不要太久），与相关研发人员及测试人员沟通好什么节点进行什么事情，避免工期汇报错误或者导致其他项目受影响。
我通常汇报工时都是：原定我认为的时间 +（原定我认为的时间）X 0.3

---

PS：实际工期落地时，大多数会出现个leader砍死时间，那就要加班加点干了，加班福利的问题看自己公司情况。

编写技术方案

开发前必须编写技术方案，为什么呢？

什么是技术方案 ？

写出通过什么技术实现需求中的功能。
通过评论项目举例：发布功能如何实现？需调用什么接口，输入输出是什么？是否要考虑XSS攻击？
再如点赞：是先执行动画再调用接口，还是先调用接口再执行动画？
还有：你的代码如何拆解？分几个模块？有哪些核心的方法？

这些都是我们要写清楚的。技术方案并没有指定的格式和参考，因此是否能编写出优质的技术方案文档也是判断一个人技术能力的标准之一。

技术方案评审

技术方案编写完，需要拉内部的经历、架构（或者技术负责人）、其他对接的角色（RD CRD）来评审技术方案。

• 内部人员评审标准
  注意评审方案是否符合设计原则，有扩展性，以及是否有其它坑（例如性能问题，安全泄漏等）。
• 外部人员评审标准
  主要评审接口是否全面，输入输出设计是否合理。

评审技术后，就是PM开始排期

如何做项目排期 ？

• 留Buffer
  排期一定要留有Buffer，给自己留余地。经验告诉我们，一个人在公司内不可能只去完成一件工作，一般会承担很多工作，为了保证完成项目的进度，需要留有余地给自己，也是给团队留有空间。
• 留多少合适？
  例如：此项目预估是 10人/天 工作量，最好反馈为 （（原有人数）* （30%）） + （原有人数） / 天反馈，即13人/天。

PS：在对系统非常熟悉的情况下评审之前反馈天数也可以，但是在技术方案评审通过后反馈排期更加精准有效。
实际研发时，每个研发人员的技术实现都与不同端的同时息息相关（FE、CRD、RD），需要相互把关，指出问题，这样产出的技术方案才会更加合理。

交互视觉设计和评审

交互视觉设计是UI和UE要做的事情，当这些设计结束后，会拉着PM、FE、CRD、QA一起进行设计稿评审，即对最终产品的样貌进行评审。
FE参加主要看看视觉实现的难易度，特别是对一些透明、渐变、毛玻璃、阴影等特效，需谨慎对待，还有比较常见的例如1px边框的问题。当不确定是否能实现的时候，一定要思考后再回复大家，也可以在保证可以完成这些功能的情况下适当的挑战一下自己。

评审结束后，UI将产出设计稿发给FE。

UI提供的设计稿通用要求

• 给750像素的图，即以iphone 6两倍屏为标准的图，并且设计稿中标出所有的颜色色值和间距、字体的大小。

PS：如果在此前你已经给来排期，但是设计稿过于复杂，必须及时的反馈给PM沟通修改排期，为自己和团队争取时间。

开发

这时每个角色进入来开发阶段

• FE （前端）
  需要获取CRD、RD的接口文档，再结合视觉设计稿进行开发。这时通过mock数据进行调用CRD、RD的接口进行开发。
• RD（后端）
  同FE，开始进行后端的接口实际编写，在此之前要提供后端接口文档供响应人员使用（我们可以自己造非真实的数据，但一定要保证与真实数据输入输出参数相同）
• CRD（客户端）
  同RD
• QA（测试）
  此时编写测试用例，根据RD、CRD以及FE提供的文档编写自动化测试脚本，黑盒、白盒的测试计划及了解业务边界。

PS：作为一名技术人员总会以为软件项目中最关键的是代码开发，而在传统的项目管理流程中，代码开发只占整个软件生命周期的1/6。回顾先前的几点，我们可以体会到，代码开发确实只占整个项目的一小部分。所有，如果想让自己更有竞争力，我们不单要提升自己的领域知识，同时也要上升一个层次，在软件项目的整个周期去思考，去磨砺自己的全面能力。

视觉联调

FE开发结束，所有界面都开发结束，要告诉UI进行视觉联调。虽然是按照UI设计进行开发的，但我们还是需要与UI设计一起联调，以确保每个细节都做的正确，需要UI的确认。另外，基本的手机响应式界面的兼容性也需要UI拿不同的手机进行验证。出现问题FE就要进行修改。
这一步会产出《联调报告》，这个报告可以不是一份文档，只需要在项目组（沟通群或企业OA）中告诉PM，视觉联调通过即可。以记录UI设计确认工作。当所有功能和细节都结束并确认，可以通过邮件或群消息发送正规的报告（前提是有足够的时间去编写）

程序联调

FE开发H5、CRD开发客户端、RD开发后端接口，待全部结束之后，需发布一个测试版本，大家一起联调。联调结束后，要让PM确认，确认软件的最终结果是他想要的结果。

自测

无论是FE、CRD、RD都要有自测的习惯，不能不对自己所实现的功能不负责任的提交，让测试岗位人员去提出。

• RD
  编写单元测试，Controller、Service、Dao，覆盖率95%（如果研发周期较紧，也要通过POSTMAN或测试工具验证自己所开发的内容）
• CRD
• FE

PS：自测需对核心功能进行自测，可以是人肉手动测试、单元测试、自动化单元测试，形式有很多。最终要有一份自测记录，即使是一个表格，列出所有的功能，记录输入输出结果。（当某件事需要交付产出物时，对应的人都会认真对待，如果只是一句话“一定要测好来再提交”，往往得到的结果都不是很理想。）

提测

自测结束，FE、CRD、RD、与PM，将需求文档、代码、自测记录提交到QA，并通过邮件发送正式提测申请，告知所有相关角色该项目已提测。QA收到邮件后，确认相关文档并分析完成后，回复计划中测试完成时间（测试周期，复测周期等），然后QA开始测试。

PS：回复时间，让PM知道，对整个项目的实际测试结束时间有一个掌控。

测试 & 回归测试

测试期间，QA通过缺陷管理工具（Redmine、JIRA、蝉道）进行提交BUG，并指派给对应的主管，通过主管来分配实际修改人，主管要与QA进行修改周期确认，来确认复测时间。

当全部BUG修复结束后，PM在这期间反复确认过研发产出后，彩壳进入上线阶段。

PS：在修改BUG期间，收到BUG，如果测试提出的BUG很模糊，一定要让测试复测此问题，如果无法复测先放一放去修改别的问题。避免在一个问题上浪费太多时间。

上线 & 回归测试

上线主要事项

• 上线相关人员需要在
  上线发版时，相关人员都需要在，见证这个事情（除可以快速的修改未知问题意外，从提高团队凝聚力以及提高参与人员成就感的角度都是需要的）。
• 上线时间
  周五和晚上不上线，因为周五和晚上上线，如果出现问题也无法及时修改，大家都在梦里或忙自己的事，不好协调（如有的紧急bug或行业限制，需要在这个时间上线，一定要安排值班和做好运维自动报警工作。）

版本控制

上线前一定要先合并代码，无论是dev、master亦或是自己的分支，都要先合并到一个“上线”分支上，让各岗位技术经理做好审查之后，并发出确认（邮件或提交纸质报告），OP（运维人员）才会确认上线版本，并进入上线工作。

• 关于Code Review 以及版本分配的问题
  可参照这篇文章 （版本管理 —— Code Review）

运维上线

运维上线也分为几个步骤，每一个步骤也需要QA参与回归测试。

• 1.预览机
  只对内有效，外网看不到，但是加载线上的真实数据（即是予发布环境）
• 2.单台机器
  即线上机器的一台机器（微服务情况下，金丝雀发布）
• 3.单机房
  即线上的一个机房（项目很大，华中、华北、华南，选择其中一个机房进行发布）
• 4.全量
  即线上所有机房。

PS：从1 —— 4步骤全部完成，并通过QA全部回归测试，才算项目上线结束。如果其中有一个步骤出现问题，就需要启动快速回滚（制定回滚机制）。回滚到上一个正式版，重新上线，覆盖目前的版本。同样，步骤也是预览机、单台机器、单机房、全量，每一步同样需要QA回归测试。如有BUG影响严重，需项目主要角色“写检讨”，做复盘汇报，总结教训。

项目总结（可选）

大多数的公司没有项目总结，我觉得最好是做项目总结，是对团队的一种警示，也是凝聚团队的一种方式，在这个时候，如有重大贡献，该奖的奖，该鼓励的鼓励，如有错误，也要公开错误（不用到个人）希望大家吸取教训，并彼此共勉。