做技术其实是一件挺幸福的事情，只要你沉下心来，享受其中。不用关心太多的事情，只需要完成开发功能。但在工作中，这通常有限期，你所做的工作单靠一个人的力量是难以完成的，在项目中总会有各种各样的问题出现，你有解决不完的bug。你的新迭代开发计划还没完成，你头上的线上bug就有一堆了。也分不清谁先谁后，东搞一下西搞一下是常态，迭代延期也是常态。
公司运营的软件产品，通常以项目迭代的形式逐渐完善。每次迭代就是一个项目，公司内部的软件迭代，成本影响一般被忽略，进度目标和质量目标就成为了直接的测量结果。
前公司的产品总监曾研究探讨并整理了一个IPDO的规范，着重对一个项目的声明周期的理解，以及对需求的管理提出了比较正规的方法。但在技术实施阶段，面临的进度延期的风险仍然十分突出。技术总监在IPDO的基础上完善了D阶段的规范要求，如下：
------------------------------以下正文-------------------------------
目前的开发项目执行过程中出现诸多问题，比如项目计划制定不及时、不合理，项目执行过程中任务跟踪不到位，风险发现与处理不及时，最终导致整个项目延误。为了让项目成员更好地明确自己在项目执行过程中的角色，及时履行相应的义务，特编制此文档以供项目成员遵照执行。
此文档根据技术产品团队目前的现状制定。
本文档将项目过程分为3个阶段：准备阶段、执行阶段、上线阶段。
项目角色指参与项目的人员所属角色，目前包括：项目负责人、前端开发、后端开发、iOS开发、Android开发、产品经理、测试、设计、运维等。
项目负责人在项目准备期间指派，承担项目经理的角色，同时还可以兼任其他角色，比如开发角色。
项目成员在项目准备期间就绪，由项目负责人与技术/团队负责人协调确定。
项目成员有义务配合项目负责人执行项目管理任务。
本阶段在时间上定义为PRD评审后与进入正式开发之前，根据项目复杂度的不同，有2～5天的时间，由项目负责人协调确定。
本阶段各角色的任务：
| 角色 | 任务 |
| 项目负责人 | 协调各组负责人安排项目成员； 协调制定项目计划； 定义各里程碑时间； 制定上线计划； 评估项目风险； 协调项目准备的其他事宜； |
| 产品经理 | 确定最终产品需求文档； 为其他角色提供需求方面的帮助； |
| 开发人员 | 分析需求，制订技术方案； 分解个人任务并排期； |
| 测试人员 | 分析需求，制订测试计划； |
| 设计人员 | 分析需求，制定设计计划； |
| 运维人员 | 了解项目所需要的资源、特殊需求、工具等，协助制定上线计划； |
设计计划可以与开发计划合并。
项目计划模版地址为：**************。项目负责人复制模版成为新的项目计划文档。
开发计划中需要明确定义出模块/功能的提测时间。
本阶段结束前，相应的技术负责人或者团队负责人需要协助确定技术方案的合理性与可行性；项目负责人需要组织会议，评估项目计划的合理性，并使项目计划获得项目组的一致认可。
本阶段的主要输出为：
- 最终的产品需求文档；
- 技术方案文档；
- 完整的项目计划文档；
👉 项目计划制定建议：
- 项目负责人如果同时承担项目中的其他角色，建议留出一定的时间（不超过1/3）做项目管理；
- Code review不要作为单独的开发任务。Code review应该在每次代码提交之前做，而不是某个时间集中来做；任务项估时需要把code review的时间考虑进去；
- 在任务项工作量估时合理的情况下，可以有一定的时间buffer（不超过1/3），用来处理一些特殊情况，从一定程度上可以降低项目风险；
本阶段时间上定义为项目准备阶段之后的开发阶段与测试阶段。
本阶段各角色的任务：
| 角色 | 任务 |
| 项目负责人 | 跟踪项目进度，组织项目例会，频率为每周3～5次； 协调项目成员间的沟通； 及时发现项目风险并推动解决； 撰写项目周报； |
| 产品经理 | 为其他角色提供需求方面的帮助； 及时披露风险； |
| 开发人员 | 进行开发任务，每日更新任务项状态； 配合项目负责人进行项目管理； 及时披露风险； |
| 测试人员 | 进行测试任务，每日更新任务项状态； 配合项目负责人进行项目管理； 及时披露风险； |
| 设计人员 | 进行设计任务与UI还原验证，每日更新任务项状态； 配合项目负责人进行项目管理； 及时披露风险； |
| 运维人员 | 准备上线所需要的技能、工具与资源； 维护开发环境与测试环境； 执行部署任务； 更新任务项状态； |
项目成员需要每日更新任务项状态，发现风险尤其是进度风险的时候需要及时通知项目负责人。项目负责人推动解决风险。
项目例会的目的是让所有项目成员了解到项目目前所处的位置。例会需要简短高效。例会关注的内容应该包括昨日、今日与明日的工作任务（视例会时间而定），以及遇到的问题与风险。例会上的问题需要会后解决。
开发人员需要对提测的模块做出质量保证，做好自测后才能提测。技术/团队负责人确认自测通过后，由项目负责人发出提测申请。需要遵守项目计划中定义的提测时间。
测试人员对提测的模块需要做smoke test，测试不通过不可以进行进一步的测试。不做无效的测试，不做无谓的测试。
本阶段时间上定义为测试完成并达到上线标准后的上线准备、上线执行以及上线后的系统监控阶段。
本阶段各角色的任务：
| 角色 | 任务 |
| 项目负责人 | 上线申请； 协调资源进行上线的准备与执行； 更新项目计划，以及处理其他项目收尾工作； 组织资源进行必要的业务培训； 撰写项目总结报告； |
| 产品经理 | 提供产品更新文案； 协助业务培训； 跟踪产品使用数据； |
| 开发人员 | 提供各渠道发布包； 准备回滚方案； 协助上线； 监控服务运行状态； 第一时间解决线上bug； |
| 测试人员 | 组织上线前bug triage会议； 撰写测试报告； 进行上线验证； 协助解决线上bug； |
| 设计人员 | - |
| 运维人员 | 准备回滚方案； 部署上线； 监控服务运行状态，第一时间发现问题； |
在测试完成后与系统上线前，测试人员需要组织bug triage会议，来确定遗留bug是否要在上线前解决。原则如下：
- 类型为缺陷，优先级为highest以及high的问题需要在上线前解决；
- 类型为缺陷，优先级为medium的问题，经一致同意可以在上线后或者后续版本解决；
- 其他问题可以在上线后或者后续版本解决；
开发人员、运维人员在系统上线前需要做好回滚准备。一旦发生回滚的情况，首要事项是要保证回滚后的系统工作正常。项目负责人需要组织资源分析问题原因并推动解决，再次发出上线申请。
无论发生何种情况的风险，项目负责人与项目成员都要时刻了解项目目前所处的位置，已经做了哪些事情，还有哪些事情没有做，时间还剩下多少。只有了解了这些事情，才能对项目的总体进展有正确的评估。
项目执行过程中会出现需求变更、增减情况。快速迭代的模式中，此种情况不可避免。在IPDO流程保证的前提下，出现的需求变更是有明确原因的。
需求变更需要通知项目负责人。项目负责人组织相关资源分析需求情况，评估对项目造成的影响，决定是否接收需求变更。
在接受需求变更的情况下，项目负责人协调更新项目计划，更新相关文档，并邮件通知项目组成员及其他相关人员。
IPDO流程图
在任务项出现进度延误的时候，项目负责人需要第一时间发现这种情况，组织相关人员分析延误原因，并给出解决方案，比如通过加班来追回进度、增加资源、或者修改项目计划。
项目计划修改后，需要及时邮件通知项目组以及其他相关成员。
------------------------------以上正文-------------------------------
在这个方案中，CTO提明确提出了在准备阶段、执行阶段、上线阶段中不同角色的工作职责和任务要求。在准备阶段对于项目的范围、进度、质量都做出了一定的工作要求，在执行阶段特别突出的强调了会议沟通，并规定了频次，这是出于对项目整体进度风险的把控而提出的，非常有独到的一面，因为在项目执行过程中，沟通是降低项目风险最直接和有效的手段。还提出了Code review的要求，也是为了防止在提交代码时存在“脏手指”的现象（开发活动中有可能会将某些关键代码注释或放开以测试某功能，提交时忘记还原）。在上线阶段，为了防止出现重大问题，还提出了备份还原计划。
这是一份针对于前司的项目管理手册，也够简洁，也够明了，我认为已经相当具体了。如果你正好需要，可以正好拿去。
但在后续的迭代过程中，也没有想象中的一帆风顺，我认为一个重要的原因就是自己的项目管理知识结构不够完善，自然照葫芦画瓢也得不出精髓。
作为在技术的世界里摸爬滚打多年的技术人，思维定式是潜移默化的形成的，他们习惯于标准的流程，并且也认为只要流程搞定，就能程序成章。但项目管理的问题具体的体现其实是在多个方面表现出来的，项目进度，项目成本，项目质量，项目范围等多个层面都有可能出现。综合考虑问题时，思路会更加开阔。
扫一扫
9万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
