[管理]对新人友好的项目管理手册

刚毕业的高材生小姜，有着浑厚的知识储备和满怀热情的心脏来到了某厂，在做了一段时间需求后，发现自己对做事靠谱的老司机倍加羡慕；为什么人家有条不紊，好评如潮？自己确手忙脚乱，频频提测delay，加班到深夜？

今天我们来帮帮小姜，看看小姜为什么技术扎实，态度积极确总是使不上劲？
（故事仅供参考，切勿对号入座）

需求详评

这周产品新提了一个需求，拉了小姜和老梁一起做，在详评会议上：

小姜：听的云里雾里，昏昏欲睡，听产品讲完后准备下来仔细看看代码哪里要改

老梁：对产品频频犀利发问：这个细节A为什么这样做，我感觉体验并不好？我们这个需求预期什么时候上线？是不是倒排？我看到这个项目需要我们合作方A做开发，定容了吗？

小姜恍然大悟的笔记（详评阶段应该做的）：

• 敲定需求细节，可以给出自己视角的建议
  • 对产品考虑不周全的需求，结合现状进行扩充
  • 对于欠缺价值的需求点，合理挑战
  • 对于破坏系统设计过大的需求点，提早商量
• 敲定需求整体节奏和预期上线时间，为做方案做准备
• 对于涉及到前置依赖的需求，一定要尽早确认好工作节奏
  • UE稿什么时候出
  • 下游是否已经定容、什么时候完成开发，下游依赖接口什么时候给

技术评审

小姜：往文档里贴了下代码截图片段，告诉大家我要改这里，其他人听的一脸懵

老梁：给了一个完整的方案，涉及到合作方的关注点的内容写的非常详细，获得一致好评

小姜复制了一份老梁的模板：

• 排期概览（开发、联调、测试、上线的准确时间）
• 业务背景（问题、目标、收益）
• 技术方案
  • 设计模块和改动点列举
  • 架构图、流程图、状态机、时序图、ER图
  • 异常情况和处理
  • AB实验方案
  • 老数据兼容
  • 依赖下游方案
  • 风险点（需求自身风险、产品影响风险、可维护性/效率风险）
• 存储设计
  • DB/TCC/MQ/Redis/ES的schema变更
  • 数据量级、key、分片、索引、选型、异常处理
• 接口文档
  • http接口定义和使用文档
  • rpc接口定义和使用文档
• 服务治理
  • 异常兜底
  • 监控报警
• 工作量评估
  • 工作拆分和估分
  • 进度计划
• 自测用例
  • 冒烟测试用例（描述、步骤、期望结果）
  • 希望测试测到的地方
• 发布计划
  • MR
  • 发布顺序

开发

评审之后大家迅速都加入了如火如荼的开发当中：

小姜：早早地做完了自己的工作，等着联调。联调前一天突然发现下游依赖的接口还没数据，一问原来是有个工作没有对齐漏掉了，心急如焚

老梁：按照之前拆分的开发计划，列出了一个详细的进度追踪表，可以看到工作分配到的人、完成时间、里程碑，还有风险；提前把问题消灭了，大家笑盈盈进入联调

小姜恍然大悟的笔记（开发阶段应该做的）：

• 进度追踪
  • 可视化，有详细追踪进度的记录表，或者通过工具（比如meego）周知大家进度
  • 精细化，工作做尽量细的拆分，到人到天，每天追踪
  • 里程碑，重要的节点设置里程碑
  • buffer预留，根据同学们的熟练程度和项目的不确定性，留25%~100%的buffer
  • 日会，根据项目的大小可以设置日会/双日会/线上追踪的方法，灵活管理风险
• 风险管理
  • 提升重要性，多问一句有没有风险，可能会得到意外的答案
  • 提早暴露，在风险还没发生或者刚被发现时就暴露并讨论
  • 及早解决，有进度风险马上协调人力或者改善方案，迅速和产品、测试达成一致，不要拖到最后延期了才解决
  • 前紧后松，前期尽量把进度往前敢，越往后不确定性越大
  • 灵活处理，如果不得已有些次要工作无法完成，可以和测试、产品商量分批提测，不影响主项目进度

小姜的嘀咕：道理我都懂，但是我做拉会的时候总觉得自己在向上汇报；关心别人工作进度、指出别人问题的时候总觉得得罪了同事；自己暴露自己模块的风险的时候总害怕给别人留下不好的印象

老梁：风险是几乎每次跑项目都会发生的，如果发生了我们就要积极应对，克服恐惧的最好方法就是面对恐惧，奥利给！

联调

终于万事俱备只查把代码跑起来了！

小姜：提前做好了自测，把上游的接口都调了一遍，看着数据没问题，联调完成！结果提测当天，很多地方都没跑通，测试打回提测，delay一天

老梁：拆分了团队内联调、全链路联调，继续用进度会议管理风险。提测当天，自己提前测完了所有冒烟测试用例，并给测试做了showcase，解决了全部问题，顺利提测

小姜恍然大悟的笔记（联调阶段应该做的）：

• case评审
  • 确认开发、测试、产品理解是否一致，方案互相覆盖
  • 给出开发的改动点和希望测试重点测试的内容
  • 注意需要回归的范围
• 联调
  • 联调前需要自测完成
  • 团队内部联调，外部依赖可以先mock
  • 全链路联调，从前端用户操作到数据库都保证准确
• 冒烟测试
  • 提前准备好冒烟测试用例，覆盖主流程
  • 自己跑完冒烟测试用例，推动大家解决所有问题
  • 给开发、产品、测试一起做showcase，记录问题并解决

测试

接力棒交给测试同学后，测试同学非常给力，迅速提出了一堆bug

小姜：测试同学提一个修一个，但是修复的速度始终赶不上bug发现的速度，一会就因为卡顿了测试同学测试而怨声载道，测试同学宣布排期+1天

老梁：和测试同学沟通了P0~P3的优先级，P0为卡顿问题，会在每天下班前保证高优解决；每天下班的时候拉会检查bug修复进度，协助所有同学保障测试进度

小姜恍然大悟的笔记（测试阶段应该做的）：

• bug优先级沟通和时效保障
• 提测后2~3天不排需求，留着解决问题（大项目）
• 此时主owner是测试同学，可以让测试同学主持进度会议

上线

耗时一个多月，剩余工作终于做完，bug也终于收敛。产品、UE验收一遍通过，就等着上线了！

小姜：搭车上线，上线到一半突然发现日志疯狂打error，原来是有个配置忘记改了，吓出一身冷汗，还好没造成线上事故

老梁：和大家开会做CR，制定发布计划、小心翼翼发布观察，沉稳地完成了上线

小姜恍然大悟的笔记（上线阶段应该做的）：

• 发布前CR
  • 最好在测试快结束的时候就做CR，而不是合master的时候
  • 重新check代码和产品的功能是否完全一致
  • 对接口QPS和延迟做重新预估
• 发布计划制定
  • 按照依赖顺序列出发布的模块和负责人
  • 处理好并发和依赖的关系
  • 周知负责人发布时间
• 发布中
  • 严格执行流水线（内含ppe验证、diff流量、panic检测、强制观察）
  • 做好小流量验证
  • 观察核心监控，包括qps、延时、业务大盘
  • 观察告警群
• 发布后
  • 预演，大项目可以组织产品、运营、测试、灰度用户做预演
  • 值班，类似618项目，发布后过几天才有大量用户0点涌入，需要值班

复盘

上线了一周，效果貌似还不错。线上零星的几个反馈也平息了，这次需求似乎做完了？

小姜：终于搞完一个大项目了，下一个！

老梁：这次项目的效果怎么样？产品效果达标了吗？我们服务的架构有没有被破坏，预期的性能达到了吗？

小姜复制了一份老梁的模板：

• 功能复盘
  • 业务数据
• 设计复盘
  • 当初的设计
  • 实现的和设计的有没有差异？为什么产生了差异？
  • 上线后，线上的问题和后续迭代，暴露了系统的哪些问题？体现了系统的哪些价值
  • 未来的改进和规划
• 性能复盘
  • 接口QPS，实际的峰值情况，预估的QPS是否准确
  • 接口延迟，有没有性能隐患
  • 机器、DB负载水位，是否符合预期
• 问题复盘
  • 产生的原因、行为
  • 影响范围
  • 详细timeline
  • 根因分析（设计、开发、自测环节？流程？监控？系统容错？响应速度？SOP？）
  • 改进措施

经过了这次和老梁一起做项目，小姜终于明白了自己的问题在哪，原来是项目管理啊！不过还好做大项目学到了很多，下次就是靠谱的小姜了~