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

一.职责
技术PM主要是以技术的视角对项目进行管理。项目管理不仅是一个流程或工具,更是一种在复杂多变的环境中驾驭风险、确保项目按时高质量交付的艺术。技术PM在项目中扮演着多重角色,既是技术决策的参与者,也是项目推进的关键人物。优秀的PM是项目组的主心骨,可以被大家信任依赖,带领项目成功交付。

职责包括:
1.深入理解业务诉求,协助PD完善产品方案;
2.结合产技能力现状和业务交付预期,给出合适的整体技术方案;
3.对于无法满足业务交付预期的,协调拆分迭代分期交付;
4.与各技术团队紧密合作,确保技术方案的可行性和风险可控;
5.制定项目计划,明确项目目标、里程碑,明确每个成员(或团队)应该在什么时间交付什么;
6.协调资源,确保项目按照计划顺利交付,必要时可上升寻求帮助;
7.识别、管理风险,积极采取相应措施应对,确保相关方知晓风险达成共识;
8.促进团队内部的沟通和协作,建立有效的沟通机制,如日会周会、日报周报等;
9.跟进线上试单、灰度、实验数据,确保项目有效交付等。

二.挑战
技术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。

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