怎样辅导工程师

最近读到 David Golden 写的文章，讲如何辅导工程师。说起了我也当了好几年的资深开发，自己也带十多人的技术团队，我自认为尽可能地对团队成员给予指导，来帮助他们成长。但是，怎样去指导新手呢？我好像从来没有系统地的思考过这个问题。读完 David 的文章，我受益匪浅。后面我也试着实践一下 David 总结的方法。好内容岂能独转。我通过邮件联系到 David 取得了翻译授权，现译成中文分享给大家。

建议英文好的朋友直接阅读原文How to mentor software engineers。翻译内容如下：

有一个朋友，也是一个资深一些的工程师，在 Slack 群里问了这样一个问题：

辅导软件工程师有什么最佳实践？大家能给点建议吗？

我当时讲要坦诚、要提供可行的反馈之类东西，但这个问题一直在我的脑海中回响。我一直在辅导别人，但我从未正式地考虑过辅导的内涵和方法。跟很多其他的软技能一样，人们很少能受到如何辅导他人的培训。大多数人都得自己学习。

辅导、训练、培养有什么异同？

虽然辅导和训练看起来有点像，但它们有不同的驱动力。在辅导关系中，一般是被辅导的人设置学习日程。在训练关系中，通常是教练设定学习计划。训练一般也更加正式，而且通常跟钱挂钩。（人们会花钱雇教练，但不会雇导师）

培养关系则非常不同。培养者都会利用自己在权力和影响力创造机会，进而甄别出自己看好的人并促进他职业生涯的发展。

在具体的场景中，导师也可能像教练或领导一样行事。

区分三种关系的办法之一就是看是否会有直接的正向或者负向的建议。导师给出建议，教练给出评价。这也是人们为什么通常从管理体系（链条）外部寻找导师。大家很难相信管理者可以区分这两种角色。人们一般是从资深一点的独立贡献者（也可能是教练）获取无需考虑结果的建议。

回想我自己以往指导他人的情形，脑海中首先出现的就是教练角色——就是那些我有责任帮助他人的场景。

教练角色容易跟辅导角色混淆，其中代码评审就是比较典型的例子。代码评审是工作内容。每次评审别人代码的时候，我都可能发现一些可以给出指导的机会。我会帮助一些人提高能力进而推动其职业生涯的发展，但这跟辅导还是不一样的。

辅导应该分三个层面

当有人来向我寻求建议的时候，无论是一次、两次还是在某段时间内经常找过来，我们的谈话跟我在训练过程中的谈话有很大的不同。

我发现对话内容可以大致分成三类，从战略导面到战术层面有：

• 目标 - 分析他们想要什么
• 场景 - 解决他们不熟悉或者难以应对的问题
• 能力 - 提高他们的技能

在以上三个方面的沟通，一定开诚布公，既要用心听取对方的诉求，又要直言不讳地指出其问题。我这认这是有效辅导的关键所在。你不但需要了解别人丰满的理想，还得愿意帮助别人面对一些骨感的现实。如果你不是这种个性或者不认同这种沟通方式，那最好让对方另请高明。

目标辅导需要提出问题

目标都是自发产生，所以这种辅导比较困难。与其告诉别人他想要的是什么，还不如帮助他们自己发现自己的目标。只有他们自己理解了，目标才有意义。

想要帮助别人理解他们的目标，我们可以提一些问题。这些问题能帮助他们理解自身处境，可以促使他们考虑自己未来的潜力，也可以规划一些课程。

最简单的问题就是「你希望自己在五年之后在哪里？」但多数人可能不会如初回答，或者不认为自己不该回答，抑或是回答一些导师不需要的内容。所以我们应该提一些可以帮助对方理解自身当前处境的问题。现在哪些方面做的好，哪些方面做不好？对自己的角色最喜欢的是哪个，最挫败的又是哪个？如果可以改变现状，最想改变的是什么，为什么？

只有听到这些问题后，被辅导的一方才会具体对照考虑当下和未来的情况。他们可能会说「多做喜欢的事，少做不喜物的事」。他们也可能说：「克服一些困难」。每个人的回复各不相同。导师要帮助把对方的目标和当前的现实情况结合起来，这样被辅导的一方才能找到切实可行的实现路径。

场景辅导需要分享经验

纸上得来终觉浅，绝知此事要躬行。有些人会通过阅读历史、故事、案例，或者其他内容来学习别人的经验。有些人却不会这样做。导师可以面对面讲述自己曾经面临的挑战，所以导师的经历是极好的学习资源。导师可以在需要的时候回答问题以及提供更多的上下文作息，这比读书要强太多。

当有人问起「我应该怎么办的时候」，导师不要立即给出建议，还是得找个合适的机会来讲述个人的经历。为什么不直接用故事回答问题呢？

首先，可能有其他人也面临同样的问题，所以要他们一起分享相关的经验资源。其次，讲故事会吸引听众的大脑，他们只会关注故事内容而忽略了自己的问题。再次，故事可以让咨询者用抽象的方式考虑案例——因为这不是自己面临的问题，所以他们可以更客观更全面地考虑这个案例。最后，这样做可以避免给对方一种被代理或者被撑控的感觉。故事是教育手段——「对导师个人有效」——但是咨询者需要自行决定是否要采用这种方案。

如果你没有相关经验，那一定要实事求是。在这种情况下，要让他们自己主动解决问题。你可以让倾听他们的想法，帮助他们扮演解决方案。即使没有过往的案例，陪伴在他们周围也是极好的支持。

同时，要注意你个人跟被辅导者的权限差异。对你适用的方案不一定对另人也适用。经验还是得分享，但要说明白你与别人之间处境的差异。

能力辅导需要观察行动

能力辅导跟训练最像。跟训练相比，在辅导关系中，你做的事情基本跟教练一样，只不过这不是你的工作，只是因为别人向你请教你才这样做的。

首先，你得观察被辅导者的行动或者产出。对于编码技能，可以通过代码评审或者结对编程实现。对于沟通技能，可以旁听他们主动参加的会议或者观看他们的演讲。对于技术写作能力，需要阅读他们的写的文档内容。

最重要的是给出可行的反馈。这意味着就你具体观察到的内容给予建议。这也意味着指出他们需要具体做哪些改进，或者他们需要学习和练习什么内容才能提高相应的能力。如果被辅导的人不知道接下来要具体做什么，你的反馈就没有可行性。

有时候对方希望提高特定方面的技能。有时候，他们希望获取一些通用的指导，通常是晋升相关的内容。我曾经面向管理者写过晋升谈话中的能力模型一文，但作为导师，你也可以把能力模型教给被辅导者。这样他们就可以自我评估，进而找出最需要帮助的方面。

当你想辅导但对方不主动怎么办？

有时候你会发现有潜力的亲手，但这些人可能不在合适的位置或者并不需要寻求建议。你可以接近他们，告之他们有潜力而且你愿意辅导他们。

如果你的公司有正式的辅导流程，你可以注册成为导师。如果没有，你也可以邀请别人来找你。不需要很正式的声明「嗨，如果有人希望得到我的辅导，请联系我」。在工作时间跟任何人交流的时候，你都可以简单说一下，看看会不会有人来。

从倾听开始

我希望你牢记一点：辅导的关键是倾听。一定要抵住主动提建议的诱惑。听明白别人想要的东西。是目标？案例？还是技能？然后在分享提问、经历和反馈之前继续倾听（或者观察）。

如果你读到这里，你可能会发现，我说的所有内容并不专门针对软件工程师。辅导是一项通用技能，只是你的个人经验只适应于特定行业。