软件研发内部教练：内部教练考量机制

现在比较多的公司都在成立内部教练团队，但是内部教练团队这样的历史并不长， 像我们这种比较长历史的教练团队，时间也只是只有10年左右的时间，这样的角色并不像其他角色，有着非常清晰的定义，一般而言，对一些角色的定义是出于某个问题：Role = Problem Owner。那么，角色的考量就是问题解决的考量。所以，需要考量教练团队，就需要定义好教练团队。

1. 教练也是某个Problem Owner，用Problem的解决来考量

这种情况，一般发生在组织内部有具体的问题需要解决，而没有一个具体的角色承担，这样，组织从现有人员中任命内部教练来承担这个任务。如最近研发团队里产品代码质量堪忧，那么我们任命一个Coding Coach，这样，这个Coding Coach的职责就是把糟糕的代码这个问题解决掉，问题解决了，考量就达标了（也意味着这个角色不再需要了，:p ），那么解决这个问题会有两个途径：

• 自己去参与代码的工作
• 自己去指导影响从事代码工作的同事

既然是教练，那肯定应该是后者，熟知通过指导影响从事代码工作的同事来达到问是的解决是一个长期的过程，而且从短期考核来说是难于达到的。那么，这个教练最后就会成为前者，从指导，变成亲自上阵。当把一个问题的责任给到了某个角色身上，那么也意味着这个责任从其他人身上移走了。

也或者，这个教练会设定不同的KPI来衡量问题的解决程度来考量自己，但其最大的价值——影响指导他人，在这个问题的解决和考量上并不明显。

2. 确定教练团队的目标，对齐公司业务目标；确定教练个体目标，对齐教练团队目标

教练团队是公司业务的支持力量，哪里需要哪里搬。公司是以完成业务目标为目的，说白一点就是从业务上赚到钱。那么，任何组织和个体都是为了公司共同的目标工作的，市场部门在开拓市场，研发在生产“炮弹”，..... 打扫卫生的阿姨在保证一个好的生产环境....。那么，从总目标分解，分解到教练团队这边的目标是什么？以此类推，从教练团队目标分解到每个教练个体的目标又是什么？以目标为驱动，细分，权重。

另一方面，基于这些目标，在整个活动中活动脚印联系起来，连成一个footprint，看针对每个目标的教练活动质量，如提高代码质量为例，教练有哪些活动是以此为目标在进行的：结对编程、介绍静态分析工作、参与Group Code Review，组织编程道场等等，而每个活动的质量又如何，对提高代码质量这一目标的影响又如何。这简直就是一个会计帐本，:p

为了便于考量，什么OKR，360Feedback等工具便自然而生。

3. 像外部教练一样考量内部教练

教练是咨询团队。内部教练因为没有独立教练财务压力，也没有独立教练的等值收入。但是，我们可以借鉴外部教练一样的考量方式，如教练A目前的业务水平如何？这种水平一次培训的费用几何，指导几何等等？如果这一年他所付出， 同样折算成外部教练的话，需要花的开销，就是他为公司创造的财富，对比教练A的实践工资，来进行考量。

那么，教练团队的考量，就像一家咨询公司的考量一样。

但实际情况远没有这么简单，如果是内部教练，跟公司有着各种耦合，哪里有那么容易算出创造的财富和花费的开销。

4. 量无定法

如果教练是精英团队，那，量无定法。因为当我们决定要一只精英的团队时候，对他的期望或许没有那么明确，除了明确的几个职责，你不知道还会有什么惊喜或者惊吓。他们可能在产品探索的教练中，探了新的产品和业务模式；他们可能在协作流程梳理中，发明了新的方法论；他们也可能在一年中，除了完成了几件例行公事，什么新的东西都没有发现出来。对这样的团队，或教练的考量，是考量其产出、影响力、学习目标，还是考量对公司业务的直接贡献呢？我觉得都可以尝试探索。看你需要他们干什么，考核什么，别人就给你什么，这是公理。

后记

常常有人问我这个话题，问我的上司如何考量我，我如何考量我的团队，我常常开玩笑地回答，“看我们合不合得来”，因为这并不容易，合得来，意味着我们承担共同的目标，从WHAT的角度我们是对齐的，另一方面，合不合得来，跟我们做事的方法是否冲突，是否相互支撑，从HOW的角度看，我们也是对齐的。而OKR，或者360Feedback，就是给们合不合得来找些依据罢了。玩笑，不要太当真。