杏彩体育，一文聊聊我理解的技术PM

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

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

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

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

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

　　1.风险识别与管理：项目很少一帆风顺，通常伴随着各种风险，如技术难点、资源瓶颈、需求变更等。技术PM需要具备敏锐的风险意识，能够准确识别项目中的潜在风险，并制定相应的风险管理计划，确保项目在可控范围内进行。

　　2.跨部门与跨团队协作：复杂项目往往涉及多个部门和团队之间的协作，可能由于不同的KPI或OKR，项目价值无法达成共识，带来更高的协同成本，需要技术PM发挥桥梁作用，协调各方利益和需求。同时，跨团队协作也需要建立高效的协作机制，确保不同团队之间的顺畅沟通和合作。维护良好的人际关系也很重要，有时买一杯咖啡比发十条消息都有用。

　　3.需求与变更管理：在当前的激烈竞争环境下，需求往往随着项目的进展而发生变化。技术PM需要与业务、产品、技术等团队紧密合作，及时捕捉和响应这些变化，确保项目能够按照最新的需求进行调整和优化杏彩体育。

　　4.质量与进度平衡：在项目中，质量和进度是两个至关重要的指标。技术PM需要在确保项目质量的同时，合理控制项目进度，确保项目能够按时交付。这需要技术PM具备扎实的项目管理知识和丰富的实践经验，关键时刻做好取舍。

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

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

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

　　1.多听多看：了解身边复杂的项目是怎么做的，ATA里项目管理相关的文章很多，也可以看一些项目复盘文档，跟经验丰富的PM聊聊，项目大多没有一帆风顺的，别人踩得坑对我们来说都是宝贵的经验。

　　2.多想想：按照时间轴，把影响项目交付相关的因素尽可能的枚举出来，想想每个时间点应该重点关注什么，逐渐形成自己的方。

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

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

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

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

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

　　1.先紧后松：项目前期的节奏要压的紧一些，尽量往前赶进度，给后期多留buffer，反过来大概率是灾难。比如对于跨部门跨团队协作的复杂项目，我们团队要求在开发阶段就完成自测和主链路TC的联调，保证进入全链路联调阶段没有太大的风险，只要修修补补各种复杂case就好。这个过程中也遇到过其他合作团队的质疑，有同学问为啥还在开发阶段你们就要联调了，还没准备好，是不是太卷了，其实我们是踩坑踩怕了，到联调阶段什么奇奇怪怪的问题都可能发生，有时一个问题就卡一两天，搞得大家苦不堪言。当然项目前期应该把节奏跟上下游拉齐，避免出现这样的gap。

　　2.化整为零：通常项目会设定一些比较大的里程碑，比如开发、联调、提测、发布等时间点，对于大项目来说，相邻里程碑间隔比较久，这就可能给大家一种错觉，还有很多时间呢，不用太着急，往往接近里程碑了才发现有问题可能来不及了，造成项目延期。我的建议是化整为零，把里程碑拆碎拆小，每个小里程碑没有按时完成及时管理风险。对于重要紧急的项目，我们团队要求要把里程碑拆到天维度，每天晚上下班前技术PM汇报当天进展、整体进展是否符合预期、风险列表跟进情况，如果发现新增风险，快速拉相关方想办法消化掉。哪怕是每天多加班一两个小时消化风险，也总比临近上线不眠不休的加班也无法按时交付要好得多杏彩体育。越紧急的项目，里程碑可以拆的越小。

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

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

　　1.技术PM权责利不清晰，觉得付出没有回报，费力不讨好——这点占比可能会大一些。虽然现在没有明确的说做得好会有什么收益，实际上在绩效考核时是有一把隐形的尺子在测量打分的，做得好的一定会被看到并且拿到结果的，做不好的也会有负面影响。技术PM是挺苦的，不过大概率收益是成正比的，风浪越大鱼越贵。理想的情况，我觉得可以通过一些组织设计，把权责利明确下来，做得好的可以给一些定量的激励，反之惩罚。不过落地可能比较复杂，每个项目的复杂度不同，对不同层级的要求也不一样，想明确考核标准不容易。之前探索过在团队内搞技术PM责任制，明确权责利，最终没有落地。杏彩体育平台登录官网

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