前言

校招入职新公司后，第一次作为技术PM去全链路全视角的对待150人日的大项目，感慨颇多，特此来做个复盘。
作为技术PM，终极责任就是促进项目按时，保质，保量的上线。将职责进行细化，对任务进行拆分之后，应该对以下领域负责：

  1. 传达信息：作为业务（运营/产品）和技术之间的桥梁
  2. 处理杂活：处理边界的开发工作，以及其他的公共事务的处理
  3. 统筹方案：确定各个域的交互方案，统筹整体技术链路
  4. 任务拆解：将业务域拆解为不同技术域，并分配给不同开发人员

方式

做好一个合格的技术PM，我总结了以下方法来协助完成项目管理任务

人员大图

  1. 确定人员关系：各个域对接人，如测试，开发，前端对接人，等。争取让项目组的成员在真正步入开发之前，都能认识各个域负责的接口人

项目排期

  1. 合理使用项目管理工具：使用Teambition/Project进行项目排期，尤其是对里程碑和每个人的项目排期时间进行关注，如果有任务不能按时完成，及时沟通预警，并产出方案
  2. 预留BUFFER：总是有意外发生，如项目环境冲突，休假，等。先紧后松
  3. 安排时间节点：每个时间和里程碑都要确定下来，并且跟相关方（业务/PMO）进行同步

时刻沟通

  1. 站会：当有不确定的风险和待定点的时候，要及时开站会拉上相关人员进行同步&进度跟进，必要时进行上报，寻求主管力量进行解决
  2. 周报（进度周报，风险周报）：汇报项目的整体进度，上报项目相关风险

里程碑

整体分为需求和项目，核心流程是一致的，但是还有些不同点。其中，需求里程碑适用于人力在BU的开发小需求；项目里程碑适用于跨BU的开发项目

需求里程碑

  1. PRD评审（产品/开发/测试）：功能流程

  2. 技术排期：开发&自测/联调/测试

  3. 技术评审（PD/开发/测试）：由内到外，再由外到内的过程

    1. 内部技术评审：评流程/数据库/监控
    2. 外部技术评审：评交互（同步/异步/幂等/重试/异常）
    3. 内部复评：评二方库（二方库和交互相关，所以放到交互后面）

  4. 开发&自测：开发/UT/集成测试/接口自测/MOCK下游

  5. 联调：先局部MOCK联调，最后整体真实环境联调

  6. CR（Owner/开发）：联调完成后即可CR，主要看的是代码是否有误，内部逻辑是否可以优化

  7. 测试评审/测试：如果需求较小，则不需要测试评审，测试可以直接参照PRD进行测试

  8. 发布：发布前要确定发布顺序和依赖，同时还有发布的应用和配置

  9. 灰度：一般都是前端控灰度，先用测试用户在线上正常走一遍，然后逐渐放量，开始灰度

  10. 监控：发布之后，一定要观察日志报警/离线表和准实时数据/状态流程等监控

项目里程碑

  1. BRD评审：需求文档评审，明白业务需求

  2. 确定资源：确定技术资源，如果资源不够，则需要找对应负责人进行协调

  3. PRD评审：功能流程评审，明白产品需求

  4. 技术排期：对开发/联调/测试时间进行排期，并给出大概的上线时间

  5. 技术评审：由内到外，再由外到内的过程

    1. 内部技术评审：状态推进/流程链路
    2. 外部技术评审：交互方案/联调规约
      1. 上游技术评审：确定上游需要的字段
      2. 下游技术评审：向下游索要字段
    3. 内部二方库评审：交互评审

  6. 开发自测：开发/UT/集成测试/接口自测/MOCK下游

  7. 内部联调：在内部进行联调时，一定要联调充分，联调完成后，后续的接口可以放心MOCK，然后再和上游联调也比较放心。联调时候，要记录所有联调的case

  8. 外部联调：外部联调时，先局部联调，其他地方MOCK，在最后再整体串起来联调，减少资源依赖程度

  9. 测试评审：这个时候，一定要把所有case都包含进去

  10. CodeReview：CR前要注意合并主干

  11. 冒烟提测：测试一定要无MOCK的走一遍全流程

  12. 功能预演：将整体功能给业务和产品走一遍

  13. 对账监控：将这些监控策略完善起来

    1. 数据对账：主要对是否存在，状态是否一致，金额是否相同，是否扣费完成等
    2. 日志监控：异常和出错日志，以及一些业务总量大盘

  14. 发布评审

    1. 发布顺序：注意开始发布时间和发布结束时间，同时注意各个域是否有依赖
    2. 发布应用：包括应用，二方库，数据库，离线表，定时任务，配置，等等
    3. 灰度方案：包括前端灰度，上游灰度，灰度比例等方案

  15. 顺序发布：二方库和下游先行

  16. 报警监控：反复校验SLS日志和数据库的内容。包括存量业务和新增业务

经验教训

  1. 其他合作方的技术排期不确定，无法推动开发进度 => 如果TODO没有结论，就留下action和时间
  2. 某接口未确定重试机制，发布前才发现 => 技术评审需要确定交互方案（同步/异步/幂等/重试/异常）
  3. 新接项目，最重要是熟悉成员 => 合理使用Xmind，如各种自测和联调case，各个人员的对接
  4. 和合作方进行联调的时候，他们即使本地修改，也都要调用我们的环境，这就意味着我们需要一直保证项目环境的可用性，显然是不合理的，应该先mock，再在约定好的时间联调 => 在联调之前，一定要约定好联调方案，如如何MOCK下游，下游可提供的真实联调环境等
  5. 因为刚开始不太了解某个流程，所以就没太关心那个流程的测试case，导致项目上线前几天还不知道某些case是否测试通过，非常影响心情 => PM尽量和测试一起把每个域的case都过一遍，然后列出来，让相关人员自测通过，在自测阶段做到心中有数
  6. 如果有方案不确定的，及时拉上产品和业务进行核对（但是各个人员都可能没时间）
  7. 在技术评审阶段，因为涉及到合作方关于某个域的技术冲突，导致技术没办法继续推进 => 当里程碑中有卡点导致整个项目阻塞后，要做两件事情，一个是安排其他并行任务，第二个是预警并汇报主管
  8. 联调和测试的时候，把每个单子的每个字段，每个状态都核对一下 => 在发布之前保司说有个图片被转译了两次，这本应该是测试时候发现的问题，却还是遗留到发布前才发现
  9. 测试最后一天测出问题，需要修改，但是隔天就是发布时间，来不及fix&发布 => 测试排期之后要留最少两天BUFFER
  10. 本次项目二期发布评审， 6号开始发布，7号发布完成。但是只标注了6号发布 => 排期的时候，要给出开始发布时间和发布结束时间

总结

之前一直念叨着没有机会接触整个产品的开发和迭代流程，想不到这么快就有机会上手了。项目刚开始的两个星期，业务和技术，一样都不熟悉。每次业务来问技术，我都一脸懵逼，技术来问业务，我也啥都不懂。有时候睡觉都会梦见项目被我带黄了，压力确实有点大。
不过随着项目不断推进，我也是步步踩坑，在多方共同推动下，把这个几百人日的项目推到了线上。
总觉得踩了这么多坑，总不能啥也不写，所以就留下了我的心路历程和踩坑经历，作为我PM生涯的第一篇处女贴吧。