003 | 工作里的放手

锻炼新人的三个阶段

在计划项目的时候, 我通常会把任务分析透彻, 描述得通透, 然后再发出去给别人做. 仿佛写入的细节越多, 接到项目的人成功率就越高.

逐渐, 我发现工作中有两种人: 1/ 不需要你的分析, 他也很快琢磨明白. 2/ 你分析得再透彻, 他还是很混乱, 甚至看不懂任务明细.

咱们今天避开后者, 不讨论. 失败的理由千千万, 不稀奇.

我最近在权衡: 当遇到了第一种人, 效率高, 反应快, 该如何培养这样的工程师? 我大致的想法是:

遇到骨骼清奇的人才

• 1/ 用两到三个项目来磨炼

• 2/ 而后让他单独带一个项目

这些项目平均而言1 - 1.5 年可以轻松完成的. 遇到高效的人, 可能会加快进度.

计划项目的想法

• 如果机会给的太慢: 即便有"卓越的表现"也会随着时间的推移而变成"稳定发挥", 可能会打击积极性

• 如果机会给的太快: 经验不能够支撑他独当一面, 可能适得其反

假设每个项目需要三个月, 这里写下一些潦草的计划, 帮助我们观察工程师的成长进度. 这里我们说的新人, 包括"刚毕业的新人", 以及"跳槽的新人".

项目A: 引导

• 需要其他工程师的直接引导, 帮新人找足资料

• 项目: 细节全部标明, 手把手带上路. 不会有太多挑战.

• 引导: 在这一阶段, 教他做项目, 写代码的基本规范(每个组每个公司规范不同)

• 期待结果: 不懂的问题全部问清楚; 按时完成.

项目B: 协助

• (如果项目A做的不好, 继续第一个项目的策略, 但注意, 新人进度可能有些慢了)

• 项目: 简略细节描述; 要求他自己研究余下的细节

• 协助: 不再手把手地教, 期待他能在公司内网到答案, 鼓励他思考问题提出见解, 而不只提出问题

• 期待结果: 把项目搞明白; 按时完成.

项目C: 放手

• (如果第项目B做得不好, 可以继续做第二个项目 B, 再稳定输出三个月)

• 项目: 找一个组里讨论过, 风险不大, 但是完全还没有细化的项目.

• 放手: 挑战他自己研究项目的需求, 设计解决方案, 鼓励他提出不同设计, 主导技术讨论. 在设计上提供指导和帮助, 但是要求他独立完成开发.

• 期待结果: 完成项目的设计, 独立开发; 按时完成.

衡量快与慢

平均而言, 4-5 个项目, 一年多做完ABC, 很正常. 高效的新人, 也许会在 9 个月完成.

我认为, ABC 三个步骤, 循序渐进, 但不可跳跃. 也许 A / B 都很快, 但一个新人还是要经历它们, 需要这样的过程: 被引导 -> 被协助 -> 再放手自己干. 倘若缺了前面两个环节, 直接来项目 C, 新人可能就变成了一个更高风险的试验品.

说实话, 我进入新公司的时候, 也急于完成 A 和 B. 取决于这个组承担风险的能力大小, 我们当然可以贸然挺进项目 C. 我去年便这么做了, 风险大, 有点累, 索性结果也是不错的.

• 从新人的角度而言, 若新公司没有新人项目计划, 那么我们要给自己找这样类似A/B/C的三个项目, 培养自己

• 若是职场老人, 但感到自己来了好几个月, 尚未被重用, 那么也许你也是在 A/B的阶段, 厚积薄发

放手的心情

从团队的角度, 或者从管理者的角度而言, 任何一次放手, 都是一次对自己判断的考验. 这样的心情还是挺复杂的.

开头我说过, 我喜欢把细节都描述清楚, 确保新人都弄得明白, 才敢让他们去做. 这样是有弊端的.

• 首先, 我把任务细化成了 A 类型, 风险小, 但是缺少了挑战. 我想, 如果一个高效的人, 屡次接到这样的任务, 恐怕会觉得阻碍了自己的成长.

• 从我的角度, 事无巨细, 凡事都要研究到底. 这样的做法也会让团队里面某一个, 或某几个人消耗过度.

也许这又是另一个话题, 如何在放开项目的同时, 有效地跟进, 确保大方向和时间线的顺畅.

写在结尾

你觉得今天的News Letter怎么样? 每个周一的发送如何? 有什么好的想法, 请在下面给留言! 有什么感兴趣的话题, 也可以噶苏我. 我会听从大家的想法, 把news letter做得更贴近需要 ~ 我们下周见!