成为会带团队的技术人 - 前阿里本地生活研发总监 - 拉勾教育

上节课我们已经知道了怎么定目标,那么接下来要解决的问题就是 “怎么达成目标”。我见过不少的技术 Leader(包括我在内),在刚开始做管理时,往往在做一个任务或项目的过程中都是靠经验或者直觉去把控整个过程。

比如技术类的重构项目,诉求并不是直接来源于业务,所以也就没有业务节奏的影响,往往是技术团队基于技术规划(比如提高代码质量,引入新技术、新框架提升整个系统)自发地做一些调整。如果项目较小( 1~2 周),你凭借个人经验和直觉可能会顺利完成,但项目规模较大时,结果就未必可控,有可能往坏的方向发展,比如:

  • 范围越做越大, 本来想解决一个问题,但是在项目过程中,不断识别出关联问题,导致原本计划一个月的重构可能延续半年甚至更久;
  • 交付质量不理想, 项目节奏缺少关键点的把控,加之任务安排不合理,项目节奏一拖再拖,交付质量也随之下滑。

总而言之,没有方法也可以做过程管理,但只有掌握过程管理的方法,才会尽可能减少事务往不好方向发展的波动,从而更轻松、更低风险、更稳妥地去拿到结果,让一切尽在掌控。

什么是过程管理?

要想探讨这个问题,我想先抛出我的管理理念(也是 “管理者三板斧” 的核心理念),在我看来,管理就是追求事务的可持续发展,而想要达成这个目标有两个基本点:

  • 管理动作要形成可持续迭代的闭环;
  • 管理动作足够简单到可以复制和个性化升级。

09 | 追过程:如何用 PDCA 做过程管理? - 图1

过程管理当然也遵循这个理念。比如你这次 A 项目做得很好,下次做 B 项目时能否依然做好?在 A 项目中发现问题、解决问题的方法和思路,是否可以在 B 项目中沿用?

这就是方法的形成与积累。所以根本上说,过程管理是为了让你的想法、灵感、不稳定的发挥逐渐规律化,可以持续迭代被你应用,它的本质就是希望结果越来越好,让你原本靠运气或者模糊经验得来的成功可以被复制,让你在项目中灵光一闪的 Idea 变成你的常规能力。

而且过程管理也是在把管理者处理问题的一些方法,渐渐地 “套路化”,形成可以灵活变换应用到不同的场景中的方法体系。比如你抽象总结了一套体系“ ABC ”,针对 D 场景时,你觉得体系中的“ A ” 是没有必要的,其实你就可以省略“ A ”, 你觉得缺少了“ F ”,也可以添上。

PDCA 模型

我相信,你肯定接触过很多过程管理的方法,不同的理论框架是否好用,这个问题见仁见智,而我的推荐标准只有一个,那就是 “足够简单、直接、易用”,因为如果某一个方法太过复杂,实操性肯定不强,假设这个管理方法有 10 条标准,组成比较复杂,那么它的容错率就会降低,因为如果你有一条没有做好,整个体系的矛盾点就会产生,在落地时,理论和现实就会存在冲突。

而 PDCA 模型就胜在简单、实用,还能让我根据自己的习惯和积累不断优化。

09 | 追过程:如何用 PDCA 做过程管理? - 图2

  • Plan(定计划):围绕着目标明确里程碑,确定关键节点,与执行的员工达成共识。
  • Do(做执行):多给员工空间、多走动、多观察、少干预,放手而非放任,你也不能置身事外。
  • Check(勤检查):狠抓关键节点做检查、问进展、问困难、给建议、做辅导、协调资源。
  • Action(复盘调优):小事尽快复盘、大事分阶段复盘、事后全面复盘,抓住每一次提升和优化的机会。

上面四条是 PDCA 的关键记忆点,言简意赅方便你记忆。按照 PDCA 的模型来看,很多 Leader 比较注重 D 和 C ,因为很多初级管理者为了证明自己,关注点在能够跟结果迅速产生关联的动作上, 而不是认真地思考整件事(事情的背景、关键节点、里程碑……)。

除此之外,C 和 D 一样,同是执行层,而执行往往比分析和决策要容易得多。 P 和 A 就被很多 同学忽视了,尤其是 A ,存在感并不强。这跟互联网公司普遍追求持续迭代、快速验证的工作模式有关,我们其实并没有关注很多项目为什么失败,错了再继续下一个项目,但这样一来久而久之很容易丧失持续迭代自己的能力。

说了这么多,你要怎么用 PDCA 做过程管理呢?我们先来还原一个案例,然后再逐点分析。

如何用 PDCA 做过程管理?

1. 案例还原

李明亮是一家教育公司研发中心的技术总监,前两天,公司启动了 S 级的大促项目,李明亮的团队接了其中 3 个子项目:A、B、C,那么他要怎么分配自己的时间、精力、抓住重点把控过程呢?这是第一个问题。

子项目 A (对交易系统进行改造)最复杂,风险也最高,需要对旧的核心系统做大量的改造,可旧的核心系统已经运行了好几年,负责人也迭代了好几次,这次要让谁负责呢?是团队目前能力最强的小王,还是对旧系统比较熟悉的老张?为了保证顺利交付,他想从方案设计、资源协调、落地执行、上线安排全程的深度参与,不知道是否合适,这是他遇到的第二个问题。

子项目 B(增加对新营销玩法的支持) 难度适中,李明亮交给了刚进入部门的小宇,小宇主观意识非常强,给出了很多的方案,一直希望李明亮放手让自己去试,李明亮犹豫了。这是他遇到的第三个问题。

子项目 C (根据压测瓶颈联合多团队进行系统调优)难度低,但是琐碎,涉及外部团队,老马虽然沉稳,但是沟通能力差,李明亮不知道是否让他担任这个工作,遇到了第四个难题。

他计划在确定人选之后,每周五与各个项目负责人 OneOne 项目进展,每两周三个项目一起做整体进展的对焦和复盘,但因为日常也在了解情况,目前节奏很紧张,例会该取消吗?这是他遇到的最后一个问题。

2. 思路分析

如果是你遇到类似的问题,怎么解决这 5 个问题呢?

在 08 讲我提到,目标的制定要 “定策略、拆任务、细到人”,Plan 的重点就是把复杂的任务或项目拆解出它的关键节点与里程碑,这样你才能确认自己应该跟进什么、什么时候跟进、跟进到什么程度(以一般的技术项目为例,很多同学眼中最基本的里程碑就是各个开发的关键节点:方案确定,开始编码,进入测试,系统上线……)。

总的来说,P 需要结合具体的实际场景情况而定,比如 DB 的设计、服务的设计、上线的方案,不同的项目中可能未必都是关键节点,你要看人、看项目具体分析。

那么在前两个问题中,李明亮应该重点抓 D (执行)和 C (检查):多给空间勤观察、狠抓节点做辅导。因为公司级项目目标比较清晰,重点在执行过程的把控上,并且因为几个项目同步进行,李明亮要保证的是三个项目的结果,自然无法完全 ALL IN 到某一个项目中。

所以,他一方面要放手给员工完成 Plan 的时间和空间,根据项目需要来确定会议的频次,确保信息及时且充分地对焦。另一方面要按照约定检查节点、对不同的项目和员工,要采取不同的方式。

子项目 A 既然难度最大,改造也是面向新系统和未来发展考虑,所以如果我是李明亮的话,会选择能力最强的小王来主导,最熟悉的老张为辅助,然后再结合最初定义好的关键节点,适当放手。

因为计划实施的主角是员工,过度干预会让员工束手束脚,所以给负责具体任务的同学足够的时间和空间,Leader 少干预,日常以观察和帮助为主。在这里,比较重要的一点就是在于你怎么拿捏干预的度,这其实是你管理动作的核心,我建议你在项目关键节点(P)的基础上关注团队伙伴的动态,比如项目进展中遇到的问题、团队成员的工作状态等。

很多能力和经验是历练出来的,只要过程可控,过程中走一些弯路也未必是坏事,要允许犯错。但是你要注意,放手不等于放任,更不等于不闻不问,你依然要对最终的结果负责。

针对第三个问题,既然子项目 B 的小宇能力稍弱,李明亮就应该多关注细节,了解进展,给予帮助,放手是对结果的不负责。你要在 Check 的环节多下功夫,才能确保项目和目标的一致与达成,一定要定期、多维度、较真地 Check!(比如,可以借助会议和邮件做好关键节点的把控与对焦,同时也将信息最大程度打通,那怎么用好它们就比较关键了。)以会议为例:

09 | 追过程:如何用 PDCA 做过程管理? - 图3

当然了,有的时候我们在 Check 时也会走进一些误区,比如:

  • 到了里程碑和关键点时间才进去 Check,日常对进展不关注、不跟进;
  • 把追杀结果当作追过程,与员工不讲 Why,不讲方法,这是 “管理者” 的常见病。团队 Leader 要清楚,成员需要的是你的帮助和支持,而不是简单的情绪发泄;
  • 关键动作不够连续连贯,做出决策或者给出解决办法之后就默认问题已经解决,后续缺少跟进。

第四个问题比较容易解决。阿里有一句土话,叫 “借事修人,借人成事”。项目 C 的难度和风险小就意味着更加可控,老马比较合适,针对沟通的问题,你可以驱动并帮助他在这个项目中得到锻炼,同时保持足够的关注确保整体进展与结果。

最后一个问题, 如果项目节奏紧张、你日常跟进也比较到位,那么可以取消周会。但是复盘会依然需要召开,因为前者的作用更多是信息同步对焦,它可以融入日常,而后者是将三个项目放在一起看整体,思考过程中的得失好坏,这是对团队和项目一个提炼沉淀的动作。

而 Action 的核心在于建立循环,复盘优化。 没有一成不变的计划与执行,只有不断调整的行动力。具体要怎么做呢?可以参考下面这些关键点。

  • 复盘前:复盘前的核心在于思考复盘的目的和产出是什么。借此,你才可以明确复盘会议主要会聊些什么,哪些人会参加。
  • 复盘中:自省是复盘会的基调,复盘就一个目的 “找到团队的不足加以改进,以便在未来取得更好的结果”。所以每个人没必要甩锅,也没必要全盘否定。在复盘的过程中,一定要把问题找准,内部对齐,达成所有人的共识。
  • 复盘后:会议有结论,结论有计划,计划有责任人,责任人有行动,要建立机制保证在复盘会上讨论出的结论能够落地。

总的来说,小事儿尽快复盘,借此向团队成员传授自己的经验;大事儿分阶段复盘,抓住重点矛盾,推动事情的顺利发展而非追求完美;事后全面复盘,不管对个人还是团队,找自己的问题都是 ROI 最高的方式,找到问题的一方才有改善提升的可能。

小结

今天,我结合李明亮的案例讲了对过程管理的理解,以及 PDCA 模型的认知和具体的应用技巧。我日常会用 PDCA 模型处理各类事务性工作,因为它不复杂,可以以较低的成本,更有条理地处理日常繁杂的工作,希望这个模型也可以是你做过程管理的利器,用它将管理方法体系化,使结果越变越好。

总的来说,这节课我想强调这样三个重点:

  1. 目标不会自己长腿走向终点,你一定要做好过程管理以取得可靠的结果。
  2. 追过程不意味着事无巨细都要做,追哪些、什么时候追、追到什么程度才是你更应该关心的。
  3. 复盘是 PDCA 管理动作中的闭环,如果每次都能提高一点点,长期积累的变化就很大了。

最后,我想说 PDCA 不只在管理上有用,它还是一种能够帮你应对各种问题的思考框架,也适用于项目处理,日常生活安排(比如旅游、购物等)。

在我看来,PDCA 这个管理方法遵循了个人的本能,它会将你处理事情的本能更加条理化、清晰化。所以我希望你能举一反三,把 PDCA 这个思考框架融入你生活的方方面面,既提高管理效率,也借此提高生活质量。

最后,你不妨想一想在生活和工作中,哪些事你认为利用 PDCA 的方式来管理会有更好的结果,分享出来,我在留言区等你。