工程师的职业生涯中必须且必然会承担项目管理工作. 本文参考文章, 并结合亲身经历, 总结了在项目管理中的实践, 一家之言, 希望对其他人有帮助.

项目是分阶段的(提出需求 -> 分析需求 -> 设计方案 -> …), 这里只讨论工程师视角下的项目施工管理. 项目管理原则: 有明确的项目流程, 保持合理预期, 推动项目前进, 确保团队长期稳定健康.

明确的项目流程

  1. 明确的开发流程

    无论是传统的瀑布式, 还是互联网流行的敏捷式都有各自不同的优缺点. 每个团队适合什么样的开发流程需要在团队中摸索. 找到合适自己的流程后就要以大家能够普遍接受的方式固定下来, 例如定期宣贯, 团队wiki, 视频解释等.

    在进入施工阶段之前, 一个明确的kick-off可以让项目关注者对齐进度认知, 是一个不错的实践.

  2. 明确的权责划分

    每个人的负责范围, 依赖关系, 交付顺序, 预期时间等都要有明确的说明. 最好这些落到纸面上, 帮助大家记忆/追踪.

保持合理预期

没有人喜欢意外, 因此我们需要尽可能减少意外情况的发生, 如果有意外的可能, 则尽早暴露给相关成员.

  1. 保持良好的沟通

    • 沟通可以线上/下, 并且需要有文档记录整个项目的进展情况. 项目进展的文档需要授权所有相关方随时查看, 并且能方便的找到项目相关的各种资源, 例如poc, ticket, 发布计划等. 文档要精练且及时更新, 保持信息密度, 不要有很多口水话.
    • 考虑主动告知相关方项目进展, 例如每次周会后总结一下, 然后发个邮件出来.

  2. 做出尽可能准确的估计

    在项目初期, 需要预估人力, 各模块交付时间表等, 可以通过模块拆解的方式分别预估每个模块大概需要多久完成, 然后相加得出最终结果. 拆解是递归式的, 如果发现很难评估, 则很有可能需求没有理解清楚.

  3. 尽早暴露风险

    一般的项目都会有或大或小的风险(除非是规模小且烂熟于心的项目), 暴露风险的目的是解决问题, 因此我们要持续不断地识别并暴露风险. 风险的暴露范围是尽可能多的让相关人员知晓, 防止有意外(如自损, 延期)发生. 因此,

    • 作为项目管理人员需要在一定程度上了解项目的方方面面, 例如前/后端架构, 交互流程/方式, 业务背景, 发展方向等. 例如我擅长前端, 那我也至少需要知道后端服务实现的大体逻辑, 都需要那些资源, rpc call, 存储方式等, 反过来也一样. 和项目成员保持良好沟通, 确保自己是最了解项目的一个人.
    • 文档记录当前需求会修改/影响的所有服务, 并告知相关人员潜在的可能影响, 让所有人做好准备. 例如曾经我更改了一个数据库中列的口径, 结果忘记通知下游, 导致业务受损1小时. 有时我们需要估计工作量和潜在风险, 如果对业务/代码/人员不熟悉, 则最好给出一个最保守的结果, 如果可能的话, 最好做一些预研, 会帮助自己判断.
    • 如果风险真的发生了, 不要隐瞒, 需要尽早告知相关方. 暴露风险的最好时机就是发现他们的时候, 其次就是现在.

主动推动项目前进

  1. 建立明确的沟通机制

    沟通是必须且必要的, 可以是JIRA, 钉钉群, 邮件组, Wiki等. 核心是需要让大家能轻松访问, 并方便更新, 讨论. 越大的项目, 参与方越多, 沟通越重要, 切忌假设对方和自己有相同的认知(例如对同一事物的熟悉程度).

  2. 及时更新项目进展

    项目进展需要:

    • 持续不断地识别可能的相关方, 并将相关方显式的, 明确的列出来.
    • 确保相关人士知晓. 这可以通过日/周会定期同步给相关方, 形式可以线上/下, 口述/demo等. 每次进展同步之后, 最好总结起来, 发邮件或者群聊消息, 保证大家认知对齐.
    • 确保进展被更新到纸面上可以随时查看. 最直观的方式是用甘特图, 或者表格. 将每次的进展更新到文档中, 以备不能参加会议的人, 未来回顾, 其他感兴趣的人查阅.

  3. 帮助项目成员最大程度的聚焦

    • 以上操作不宜过重, 防止给大家增加额外的负担. 例如落实直面项目进展, 可以在每次沟通前进行, 不一定保持时时刻刻的更新.
    • 项目管理人员不必事必躬亲, 可以适当把一些事情授权给其他人做, 例如组织站会, 项目文档更新.
      • 可以解放项目管理人员部分精力, 更加聚焦在重要的事情上;
      • 对其他人也是一种锻炼, 毕竟大家都需要成长.
    • 确保每个项目成员都清楚项目现状及下一个交付里程碑.

确保团队长期稳定健康

  1. 认可团队的成功

    获得别人的认可是一种内在需求, 同时很多工程师会比较内向. 所以在项目进展过程中, 作为项目管理人员, 需要及时表达对团队成员的工作认可(当然也要纠偏), 并在项目交付之后感谢大家的努力, 形式可以是发庆祝邮件, 群消息, 或者聚餐.

  2. 分析团队的待改进项

    言者无罪，闻者足戒, 反思会帮助我们更快的成长. 在项目阶段性结束之后, 可以组织项目回顾会, 识别项目施工中的可改进点(切忌搞成批斗会, 我们的目的是下次做得更好, 不是甩锅) 详细解释..

  3. 尽可能地帮助成员健康成长

    人的脑力, 精力, 体力, 忍耐力都是有限的, 为了达到全局长期最优的效果, 需要尽可能地营造健康的工作氛围, 例如健康的作息, 个体尊重等.

总结

以上的原则都是尽可能地保证项目能保质保量的交付.

设置这些规则的理念是:

  • 规则不是为了限制自由, 而是为了给大家更多的自由.
  • 项目组的成员作为一个整体, 每个人都需要为项目的结果负责, 项目的失败是每个人的失败, 项目的成功是每个人的成功.

另外, 相互指责的现象在不成熟的团队中经常出现, 这是非常忌讳的. 我们要学会相互鼓励, 欣赏, 学习, 为业务的最终成功贡献力量.

如果觉得上述内容不好理解, 那么可以先按照如下的具体行动实践:

  1. 项目开始时, 组织启动会, 将相关人都拉到会上, 最后听听他们的反馈.
  2. 将项目拆解一系列的里程碑, 预估每个里程碑的工作量和完成时间, 可能需要一/二次开会讨论才能决定.
  3. 将项目方案, 相关方列表, 进展等都记录到可随时查看的文档中.
  4. 组织周会, 并在周会结束后总结并全员同步进展邮件, 包含pm, rd, qa等.
  5. 大型项目可以组织日会, 每日同步进展.
  6. 设置每周工作目标, 将本周的交付目标同步到项目组的所有人, 并在周会上及时回顾/调整.
  7. 如果有可以呈现的阶段性成果, 则在周会上进行展示, 反馈越及时, 成就感会越高, 这可以鼓舞士气.
  8. 项目交付/结束后, 组织复盘会, 总结经验, 下次可以做的更好.