作为技术同学，不仅要写好自己的代码，做好功能交付，往往还需要担任复杂项目的技术PM，推动整个项目的交付。其实人人都是技术PM，不管有没有这个title，实际上都在做这个工作，只不过是职责边界和复杂度不一样。有些同学缺少项目管理经验，不知道怎么才能做好技术PM，可能在项目过程中感觉混乱，大家做的很累，最后又延期交付，结果过程都不好，最后也搞不清楚哪里没做好。本文结合自身的一些经验，分享一下心得。
职责
技术PM主要是以技术的视角对项目进行管理。项目管理不仅是一个流程或工具，更是一种在复杂多变的环境中驾驭风险、确保项目按时高质量交付的艺术。
技术PM在项目中扮演着多重角色，既是技术决策的参与者，也是项目推进的关键人物。优秀的PM是项目组的主心骨，可以被大家信任依赖，带领项目成功交付。职责包括：
- 深入理解业务诉求，协助PD完善产品方案；
- 结合产技能力现状和业务交付预期，给出合适的整体技术方案；
- 对于无法满足业务交付预期的，协调拆分迭代分期交付；
- 与各技术团队紧密合作，确保技术方案的可行性和风险可控；
- 制定项目计划，明确项目目标、里程碑，明确每个成员（或团队）应该在什么时间交付什么；
- 协调资源，确保项目按照计划顺利交付，必要时可上升寻求帮助；
- 识别、管理风险，积极采取相应措施应对，确保相关方知晓风险达成共识；
- 促进团队内部的沟通和协作，建立有效的沟通机制，如日会周会、日报周报等；
- 跟进线上试单、灰度、实验数据，确保项目有效交付等。
挑战
技术PM面临的挑战是多方面的，需要具备全面的能力和素质来应对。这些挑战要求技术PM不仅要有深厚的技术功底和丰富的项目管理经验，还需要具备出色的沟通、协调、领导和学习能力。
下面是一些常见的挑战：
- 风险识别与管理：项目很少一帆风顺，通常伴随着各种风险，如技术难点、资源瓶颈、需求变更等。技术PM需要具备敏锐的风险意识，能够准确识别项目中的潜在风险，并制定相应的风险管理计划，确保项目在可控范围内进行。
- 跨部门与跨团队协作：复杂项目往往涉及多个部门和团队之间的协作，可能由于不同的KPI或OKR，项目价值无法达成共识，带来更高的协同成本，需要技术PM发挥桥梁作用，协调各方利益和需求。同时，跨团队协作也需要建立高效的协作机制，确保不同团队之间的顺畅沟通和合作。维护良好的人际关系也很重要，有时买一杯咖啡比发十条消息都有用。
- 需求与变更管理：在当前的激烈竞争环境下，需求往往随着项目的进展而发生变化。技术PM需要与业务、产品、技术等团队紧密合作，及时捕捉和响应这些变化，确保项目能够按照最新的需求进行调整和优化。
- 质量与进度平衡：在项目中，质量和进度是两个至关重要的指标。技术PM需要在确保项目质量的同时，合理控制项目进度，确保项目能够按时交付。这需要技术PM具备扎实的项目管理知识和丰富的实践经验，关键时刻做好取舍。
结合以往的经验，第一点最为重要，也比较困难，下面着重聊一下。
风险识别与管理
▐ 风险识别
上文多次提到“风险”，什么是风险呢？简单来说，一切影响交付的因素都是风险，包括财税法、项目组成员的变化、联调环境稳定性、封网计划等。任何可能让你没办法按时交付的因素，都是风险，重要的事情再说一遍。
这里有太多的例子了，比如某项目已经进入开发阶段，发现一个资金流合规问题，存在法务风险，结果整个项目方案基本推导重来，浪费大量人力，耽误了很多时间，造成后面的节奏非常紧张。
难就难在怎么把这些变量识别出来，经验越丰富的PM，这方面的能力就越强，坑踩的多了自然就能提前预判了。比如上述的例子，吃一堑长一智，如果以后再涉及到资金流变更的项目，项目初期先把财税法讨论清楚再设计方案。
经验少怎么办？
- 多听多看：了解身边复杂的项目是怎么做的，ATA里项目管理相关的文章很多，也可以看一些项目复盘文档，跟经验丰富的PM聊聊，项目大多没有一帆风顺的，别人踩得坑对我们来说都是宝贵的经验。
- 多想想：按照时间轴，把影响项目交付相关的因素尽可能的枚举出来，想想每个时间点应该重点关注什么，逐渐形成自己的方法论。
- 多聊聊：积极与团队成员沟通，把大家拉进来一起识别潜在风险，集思广益，相信团队的力量。
一个小建议，带着怀疑的心态去审视一切变量，已经在“黑名单”里的要重点关注，对于不了解的要悲观看待，特别是初次合作的人、初次涉及的领域等。
▐ 风险管理
风险管理是一个系统性的过程，涉及评估、应对和监控等各个环节。有效的风险管理是确保项目成功交付的关键因素之一。常见的风险管理方法：
1）风险评估：a. 对上面识别出的风险进行定量和定性评估，确定其发生的可能性和潜在影响。b. 综合评估，对风险进行优先级排序。c. 确保相关方知悉风险并且对优先级达成共识。
2）风险应对：a. 根据风险评估结果，制定针对性的风险应对策略，包括风险避免、减轻、转移和接受。b. 制定详细的风险应对计划，明确责任人、措施和时间表。c. 确保风险应对计划与项目整体计划相协调。
3）风险监控：a. 建立风险监控机制，定期跟踪和评估风险状态，如日报、周会等方式，确保信息透明和沟通顺畅。
4）持续改进与经验总结：a. 在项目执行过程中，不断总结经验教训，优化风险管理流程。b. 对成功应对的风险进行记录，为未来项目提供借鉴。c. 对未能有效应对的风险进行深入分析，找出原因并提出改进措施。
风险管理过程最能体现要性，优秀的技术PM不是传话筒，在这个过程中会积极push大家，想尽各种办法克服困难，消化风险，力保项目如期交付。这也是最能体现个人价值的点之一，这个项目如何因你而不同。
▐ 早发现早治疗
风险识别得越早，管理过程应对的方案越多。如果到最后阶段才暴露出来巨大风险，大罗金仙也无力回天了，只能面对最坏的结果。
所以一个常见的问题——如何让风险尽早暴露出来呢？
通常一个复杂的项目，可能开发周期很长，开发时感觉很顺利，到了联调或测试阶段才发现很多问题，比如需求理解错了、开发功能有遗漏、技术方案有缺陷、甚至应用启不来等等，带来大量新的工作量，这个阶段所剩时间已经不多了，不得已要加班赶进度，最后还不一定能按时完成交付，就可能造成引言说的大家又累、结果又不好的情况，这种情况很常见，有的同学不愿意做技术PM也大概是这个原因，感觉费力不讨好。
结合经验有两个建议：
- 先紧后松：项目前期的节奏要压的紧一些，尽量往前赶进度，给后期多留buffer，反过来大概率是灾难。比如对于跨部门跨团队协作的复杂项目，我们团队要求在开发阶段就完成自测和主链路TC的联调，保证进入全链路联调阶段没有太大的风险，只要修修补补各种复杂case就好。这个过程中也遇到过其他合作团队的质疑，有同学问为啥还在开发阶段你们就要联调了，还没准备好，是不是太卷了，其实我们是踩坑踩怕了，到联调阶段什么奇奇怪怪的问题都可能发生，有时一个问题就卡一两天，搞得大家苦不堪言。当然项目前期应该把节奏跟上下游拉齐，避免出现这样的gap。
- 化整为零：通常项目会设定一些比较大的里程碑，比如开发、联调、提测、发布等时间点，对于大项目来说，相邻里程碑间隔比较久，这就可能给大家一种错觉，还有很多时间呢，不用太着急，往往接近里程碑了才发现有问题可能来不及了，造成项目延期。我的建议是化整为零，把里程碑拆碎拆小，每个小里程碑没有按时完成及时管理风险。对于重要紧急的项目，我们团队要求要把里程碑拆到天维度，每天晚上下班前技术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
Q1: 做技术PM既苦且难，做PM的收益是什么？（现在越来越多技术不愿意做技术PM）
我在引言里也提到了有些同学不愿意做技术PM，我观察到的几点原因：1）技术PM权责利不清晰，觉得付出没有回报，费力不讨好——这点占比可能会大一些。虽然现在没有明确的说做得好会有什么收益，实际上在绩效考核时是有一把隐形的尺子在测量打分的，做得好的一定会被看到并且拿到结果的，做不好的也会有负面影响。技术PM是挺苦的，不过大概率收益是成正比的，风浪越大鱼越贵。理想的情况，我觉得可以通过一些组织设计，把权责利明确下来，做得好的可以给一些定量的激励，反之惩罚。不过落地可能比较复杂，每个项目的复杂度不同，对不同层级的要求也不一样，想明确考核标准不容易。之前探索过在团队内搞技术PM责任制，明确权责利，最终没有落地。
2）感觉自己能力或者精力不匹配项目复杂度，怕影响结果背责任——多见于新同学，需要主管和师兄多鼓励辅导，挑选合适的机会锻炼，及时给正反馈，逐渐提升自信。关于收益再补充一点，除了上文中提到的综合能力提升以及绩效反馈，同时也可以提升个人影响力，做得好合作方会觉得这个人不错挺靠谱，以后有更大更有挑战的项目还想跟你合作。曾经有个合作过的其他BU团队，在启动新项目时就邀请我去做技术PM，确实跟我没啥关系就婉言谢绝了，当时还是挺有成就感的。
Q2: 怎么识别这个项目的关键技术目标？（过程不易，结果拿到了么）
最重要的也是最基本的技术目标，肯定是保证质量按时交付，先让业务赢，在一些复杂的跨域协同项目中，想完成这个目标已经比较困难了，确实需要一个靠谱的技术PM。
其次，在这个项目中可以沉淀哪些产品、技术能力，或者说顺便完成了哪些技术重构优化，带来质量、效率、性能或体验的提升，都是加分项，也可以作为技术目标。
团队介绍
我们是淘宝买菜交易团队，一个靠谱的的团队，负责淘宝买菜全托管、半托管等多种业务模式的交易链路，致力于通过极致的性能和创新的产品交互，为消费者提供业内最好的交易体验。买菜上淘宝，便宜又新鲜。
