阿里妹导读

作为技术同学，不仅要写好自己的代码，做好功能交付，往往还需要担任复杂项目的技术PM，但有些同学缺少项目管理经验，不知道怎么才能做好技术PM，本文结合作者自身的一些经验，分享一些心得。

引言

作为技术同学，不仅要写好自己的代码，做好功能交付，往往还需要担任复杂项目的技术PM，推动整个项目的交付。其实人人都是技术PM，不管有没有这个title，实际上都在做这个工作，只不过是职责边界和复杂度不一样。有些同学缺少项目管理经验，不知道怎么才能做好技术PM，可能在项目过程中感觉混乱，大家做的很累，最后又延期交付，结果过程都不好，最后也搞不清楚哪里没做好。本文结合自身的一些经验，分享一下心得。

职责

技术PM主要是以技术的视角对项目进行管理。项目管理不仅是一个流程或工具，更是一种在复杂多变的环境中驾驭风险、确保项目按时高质量交付的艺术。

技术PM在项目中扮演着多重角色，既是技术决策的参与者，也是项目推进的关键人物。优秀的PM是项目组的主心骨，可以被大家信任依赖，带领项目成功交付。

职责包括：

1.深入理解业务诉求，协助PD完善产品方案；

2.结合产技能力现状和业务交付预期，给出合适的整体技术方案；

3.对于无法满足业务交付预期的，协调拆分迭代分期交付；

4.与各技术团队紧密合作，确保技术方案的可行性和风险可控；
5.制定项目计划，明确项目目标、里程碑，明确每个成员（或团队）应该在什么时间交付什么；
6.协调资源，确保项目按照计划顺利交付，必要时可上升寻求帮助；
7.识别、管理风险，积极采取相应措施应对，确保相关方知晓风险达成共识；
8.促进团队内部的沟通和协作，建立有效的沟通机制，如日会周会、日报周报等；

9.跟进线上试单、灰度、实验数据，确保项目有效交付；

挑战

技术PM面临的挑战是多方面的，需要具备全面的能力和素质来应对。这些挑战要求技术PM不仅要有深厚的技术功底和丰富的项目管理经验，还需要具备出色的沟通、协调、领导和学习能力。

下面是一些常见的挑战：
1.风险识别与管理：项目很少一帆风顺，通常伴随着各种风险，如技术难点、资源瓶颈、需求变更等。技术PM需要具备敏锐的风险意识，能够准确识别项目中的潜在风险，并制定相应的风险管理计划，确保项目在可控范围内进行。
2.跨部门与跨团队协作：复杂项目往往涉及多个部门和团队之间的协作，可能由于不同的KPI或OKR，项目价值无法达成共识，带来更高的协同成本，需要技术PM发挥桥梁作用，协调各方利益和需求。同时，跨团队协作也需要建立高效的协作机制，确保不同团队之间的顺畅沟通和合作。维护良好的人际关系也很重要，有时买一杯咖啡比发十条消息都有用。
3.需求与变更管理：在当前的激烈竞争环境下，需求往往随着项目的进展而发生变化。技术PM需要与业务、产品、技术等团队紧密合作，及时捕捉和响应这些变化，确保项目能够按照最新的需求进行调整和优化。
4.质量与进度平衡：在项目中，质量和进度是两个至关重要的指标。技术PM需要在确保项目质量的同时，合理控制项目进度，确保项目能够按时交付。这需要技术PM具备扎实的项目管理知识和丰富的实践经验，关键时刻做好取舍。

结合以往的经验，第一点最为重要，也比较困难，下面着重聊一下。

风险识别与管理

风险识别

上文多次提到“风险”，什么是风险呢？简单来说，一切影响交付的因素都是风险，包括财税法、项目组成员的变化、联调环境稳定性、封网计划等。任何可能让你没办法按时交付的因素，都是风险，重要的事情再说一遍。

这里有太多的例子了，比如某项目已经进入开发阶段，发现一个资金流合规问题，存在法务风险，结果整个项目方案基本推导重来，浪费大量人力，耽误了很多时间，造成后面的节奏非常紧张。

难就难在怎么把这些变量识别出来，经验越丰富的PM，这方面的能力就越强，坑踩的多了自然就能提前预判了。比如上述的例子，吃一堑长一智，如果以后再涉及到资金流变更的项目，项目初期先把财税法讨论清楚再设计方案。

经验少怎么办？
1.多听多看：了解身边复杂的项目是怎么做的，ATA里项目管理相关的文章很多，也可以看一些项目复盘文档，跟经验丰富的PM聊聊，项目大多没有一帆风顺的，别人踩得坑对我们来说都是宝贵的经验。
2.多想想：按照时间轴，把影响项目交付相关的因素尽可能的枚举出来，想想每个时间点应该重点关注什么，逐渐形成自己的方法论。
3.多聊聊：积极与团队成员沟通，把大家拉进来一起识别潜在风险，集思广益，相信团队的力量。

一个小建议，带着怀疑的心态去审视一切变量，已经在“黑名单”里的要重点关注，对于不了解的要悲观看待，特别是初次合作的人、初次涉及的领域等。

风险管理

风险管理是一个系统性的过程，涉及评估、应对和监控等各个环节。有效的风险管理是确保项目成功交付的关键因素之一。常见的风险管理方法：

1.风险评估：

a.对上面识别出的风险进行定量和定性评估，确定其发生的可能性和潜在影响。

b.综合评估，对风险进行优先级排序。

c.确保相关方知悉风险并且对优先级达成共识。

2.风险应对：

a.根据风险评估结果，制定针对性的风险应对策略，包括风险避免、减轻、转移和接受。

b.制定详细的风险应对计划，明确责任人、措施和时间表。

c.确保风险应对计划与项目整体计划相协调。

3.风险监控：

a.建立风险监控机制，定期跟踪和评估风险状态，如日报、周会等方式，确保信息透明和沟通顺畅。

4.持续改进与经验总结：

a.在项目执行过程中，不断总结经验教训，优化风险管理流程。

b.对成功应对的风险进行记录，为未来项目提供借鉴。

c.对未能有效应对的风险进行深入分析，找出原因并提出改进措施。

风险管理过程最能体现要性，优秀的技术PM不是传话筒，在这个过程中会积极push大家，想尽各种办法克服困难，消化风险，力保项目如期交付。这也是最能体现个人价值的点之一，这个项目如何因你而不同。

早发现早治疗

风险识别的越早，管理过程应对的方案越多。如果到最后阶段才暴露出来巨大风险，大罗金仙也无力回天了，只能面对最坏的结果。

所以一个常见的问题——如何让风险尽早暴露出来呢？

通常一个复杂的项目，可能开发周期很长，开发时感觉很顺利，到了联调或测试阶段才发现很多问题，比如需求理解错了、开发功能有遗漏、技术方案有缺陷、甚至应用启不来等等，带来大量新的工作量，这个阶段所剩时间已经不多了，不得已要加班赶进度，最后还不一定能按时完成交付，就可能造成引言说的大家又累、结果又不好的情况，这种情况很常见，有的同学不愿意做技术PM也大概是这个原因，感觉费力不讨好。

结合经验有两个建议：
1.先紧后松：项目前期的节奏要压的紧一些，尽量往前赶进度，给后期多留buffer，反过来大概率是灾难。比如对于跨部门跨团队协作的复杂项目，我们团队要求在开发阶段就完成自测和主链路TC的联调，保证进入全链路联调阶段没有太大的风险，只要修修补补各种复杂case就好。这个过程中也遇到过其他合作团队的质疑，有同学问为啥还在开发阶段你们就要联调了，还没准备好，是不是太卷了，其实我们是踩坑踩怕了，到联调阶段什么奇奇怪怪的问题都可能发生，有时一个问题就卡一两天，搞得大家苦不堪言。当然项目前期应该把节奏跟上下游拉齐，避免出现这样的gap。
2.化整为零：通常项目会设定一些比较大的里程碑，比如开发、联调、提测、发布等时间点，对于大项目来说，相邻里程碑间隔比较久，这就可能给大家一种错觉，还有很多时间呢，不用太着急，往往接近里程碑了才发现有问题可能来不及了，造成项目延期。我的建议是化整为零，把里程碑拆碎拆小，每个小里程碑没有按时完成及时管理风险。对于重要紧急的项目，我们团队要求要把里程碑拆到天维度，每天晚上下班前技术PM汇报当天进展、整体进展是否符合预期、风险列表跟进情况，如果发现新增风险，快速拉相关方想办法消化掉。哪怕是每天多加班一两个小时消化风险，也总比临近上线不眠不休的加班也无法按时交付要好得多。越紧急的项目，里程碑可以拆的越小。

以上两个方法亲测有效，很多硬仗都是这么打过来的。

参考指引

有些新同学没有做过复杂项目的技术PM，不知道每个阶段该重点关注什么，根据以往经验总结了一下以供参考：

项目启动阶段

1.项目KO：

a.召集项目子域PM和相关方（或所有成员），明确项目背景、目标和范围。

b.讨论并确认项目的初步时间节奏、关键里程碑。

2.需求收集和确认：

a.与业务和PD深入交流，确保需求清晰明确。

b.协助PD完善产品方案，把控整体方案，与业务方确认达成共识。

3.项目计划制定：

a.制定详细的项目计划，拆解里程碑，建议越重要越紧急的项目，拆解的越细。

b.识别、评估项目风险，并制定相应的风险应对策略。

设计与开发阶段

1.把控整体方案：

a.结合产技能力现状和业务交付预期，给出合适的整体技术方案。

b.对于无法满足业务交付预期的，协调拆分迭代分期交付。

c.拆解各域关键任务，组织技术方案评审。

2.技术方案评审：

a.把控各域关键技术方案，确保满足功能性和非功能性需求。

b.评估方案的合理性、可维护性、成本、风险，探索更合理的方案。

3.代码开发与审查：

a.监控开发进度，及时识别、管理风险。

b.及时跟进需求变更和技术方案变更情况。

c.推动提测前完成进行代码CR，提升提测质量。

4.联调与测试：

a.监控联调进度，及时识别、管理风险。

b.参与核心链路TC评审，协助完善case场景，与相关方确保对需求理解一致。

c.跟踪缺陷的修复情况，把控交付质量。

d.评估稳定性风险、资损风险，提前布防（压测、监控等）。

e.组织功能预演，确保有效交付。小问题及时推动优化，大问题重新评估项目计划。

部署与上线阶段

1.上线部署：

a.制定详细的上线计划并进行评审，包括数据迁移、版本控制、发布顺序等。

b.组织集中发布，把控节奏，及时跟进突发情况，监控系统的运行状态。

c.确保新增的监控、对账有效运行。

2.线上试单及灰度：

a.发布完成后，组织测试、PD在线上试单验证，确保有效交付。

b.讨论制定灰度计划，明确节奏及操作人，灰度比例执行变更后及时同步。

项目收尾阶段

1.项目总结：

a.总结项目的经验教训，做得好的和不好的。

b.复盘项目结果和价值，是否符合业务预期，总结得与失。

2.文档整理：

a.整理项目过程中的所有文档，包括需求文档、设计文档、测试报告等。

b.相关文档归档，确保项目的完整性和可追溯性。

贯穿始终

1.沟通与协调：

a.持续与团队成员和相关方保持沟通，拉齐信息，如日会、周会或日报、周报等。

b.及时解决项目过程中出现的问题和冲突。

2.风险管理：

a.保持敏感，识别项目新风险，制定相应的风险应对措施。

b.持续监控风险的变化情况，及时调整风险管理策略。

c.驾驭风险，发挥要性，想尽各种办法推动解决风险。

以上是一个粗略的任务列表，实践中还需根据项目类型、规模和具体要求进行调整和完善。重要的是确保每一个步骤都得到妥善执行，以保证项目的顺利进行和高质量交付。

总结

前段时间看电影《奥本海默》，当时非常震撼，这不就是优秀技术PM的典范嘛。造原子弹这么复杂的项目，从选址新建一个小镇，到找齐各个科学家突破技术难点，耗时几年，经历各种变故各种挑战，耗费大量人力物力，最后一次性实验成功，并且按时交付给业务后带来巨大价值。

技术PM非常考验心力、脑力、体力，锻炼综合能力，每次负责不同的项目都会有新的收获。一个成功的项目也离不开技术PM在各个阶段的精心规划和严格执行。作为技术PM，我们需要不断提升自己的专业素养和管理能力，以应对日益复杂的项目挑战，确保项目的顺利进行和高质量交付。

Q&A

做技术PM既苦且难，做PM的收益是什么。（现在越来越多技术不愿意做技术PM）

我在引言里也提到了有些同学不愿意做技术PM，我观察到的几点原因：
1.技术PM权责利不清晰，觉得付出没有回报，费力不讨好——这点占比可能会大一些。虽然现在没有明确的说做得好会有什么收益，实际上在绩效考核时是有一把隐形的尺子在测量打分的，做得好的一定会被看到并且拿到结果的，做不好的也会有负面影响。技术PM是挺苦的，不过大概率收益是成正比的，风浪越大鱼越贵。理想的情况，我觉得可以通过一些组织设计，把权责利明确下来，做得好的可以给一些定量的激励，反之惩罚。不过落地可能比较复杂，每个项目的复杂度不同，对不同层级的要求也不一样，想明确考核标准不容易。之前探索过在团队内搞技术PM责任制，明确权责利，最终没有落地。
2.感觉自己能力或者精力不匹配项目复杂度，怕影响结果背责任——多见于新同学，需要主管和师兄多鼓励辅导，挑选合适的机会锻炼，及时给正反馈，逐渐提升自信。

关于收益再补充一点，除了上文中提到的综合能力提升以及绩效反馈，同时也可以提升个人影响力，做得好合作方会觉得这个人不错挺靠谱，以后有更大更有挑战的项目还想跟你合作。曾经有个合作过的其他BU团队，在启动新项目时就邀请我去做技术PM，确实跟我没啥关系就婉言谢绝了，当时还是挺有成就感的。

怎么识别这个项目的关键技术目标。（过程不易，结果拿到了么）

最重要的也是最基本的技术目标，肯定是保证质量按时交付，先让业务赢，在一些复杂的跨域协同项目中，想完成这个目标已经比较困难了，确实需要一个靠谱的技术PM。

其次，在这个项目中可以沉淀哪些产品、技术能力，或者说顺便完成了哪些技术重构优化，带来质量、效率、性能或体验的提升，都是加分项，也可以作为技术目标。