我要提问

这是一个系列博客文章，回答敏捷中常见问题。查看所有常见问题。今天回答的问题是：

• Scrum Master是否需要懂技术？

Bob的观点

Scrum Master需要懂技术，而且是一定要懂技术。不懂技术的Scrum Master很难成为一名优秀的Scrum Master。如果你想成为敏捷教练，或许不懂技术还行得通，但是Scrum Master不懂技术是不行的。具体还可以参考之前的博客文章，Scrum Master和敏捷教练之间的区别。

• 原因1： 不懂技术的Scrum Master很难融入团队。
• 原因2： 不懂技术的Scrum Master很难帮助团队在开发（工程）实践方面发展。
• 原因3： 不懂技术的Scrum Master很难帮助团队发现技术的潜在风险或障碍。

不懂技术的Scrum Master很难融入团队

开发团队成员之间沟通的时候，多半会使用技术术语，如代码仓库、技术债、重构、vs code等等。如果听不懂团队说的是什么，就很难了解问题或背景，从而很难融入到团队中去。所以作为Scrum Master，至少需要了解：

• 常用技术术语
• 软件开发生命周期
• 常用的技术工具，等等

不需要Scrum Master成为代码管理的专家、重构专家，但一定要知道这是什么。

不懂技术的Scrum Master很难帮助团队在开发（工程）实践方面发展

如果一名Scrum Master不懂技术，那么他也很难了解或掌握软件开发行业的最新工程实践（开发实践）。那么作为Scrum Master，如何帮助开发团队认识到当下行业有哪些最新的提高效率的开发工具、工作实践呢。

Scrum Master的关注度不仅仅是团队、产品负责人，还需要关注组织和开发实践。参考Scrum Master和敏捷教练之间的区别中Scrum Master关注度一节。

不懂技术的Scrum Master很难帮助团队发现技术的潜在风险或障碍

最后，如果Scrum Master不懂技术的话，他也很难有技术的感觉，从而很难敏感地发现团队内的潜在技术风险或障碍（不一定是真的风险，但有时候一句话就可以点醒团队）。

综上所述，作为一名Scrum Master一定需要懂技术，而且需要是懂大量的技术（不一定需要很深入）。

职场泥石流的分享

以下来自职场泥石流分享的总结，感谢小新同学（谢晓强）的努力。

之前在群里参与讨论过Scrum master与技术间关系的一些问题，从群友那里得到不少启发，其后有机会能在前两天连线Ethan黄老师，直接就这个问题展开了一些辩论，又聆听了黄老师对一些相关问题的分析与解答，让我对问题的认识又深了一些，这篇文字是对之前视频的回顾总结，加上一些我自己的思考。如果我对于黄老师的观点有引用错误的地方，或者大家认为我的观点有何不对之处，欢迎批评指正。

视频的最开始其实是关于SM懂技术是利大于弊还是弊大于利的一场小型辩论，不过我想先不记录这个，先记录黄老师后面回答的几个问题，然后再回到最开始的这场辩论，这样理解起来可能会更好。

问：没有技术背景的SM感觉无法融入团队怎么办？

针对这个问题，黄老师首先指出这种情况非常普遍，感到fear也是正常的，他自己也有过这样的经历。面对这种情况：

• 第一个是要想到每个人的知识面都是有范畴的，要扬长避短，同时你现在不会技术不代表以后不会，这种fear也是你学习的动力；
• 第二个是要弄明白，这个fear是不是有可能是不必要的，因为在这个行业里或技术里你没有积累，并不妨碍你成为一名好的SM或教练，你可以通过学习掌握软技巧，如有效倾听与强力提问、还有学习的能力，来发挥自己价值，融入团队。

问：技术能力非常强的人，他来做SM会遇到哪些问题？

针对这个问题，黄老师回答问题在于他可能忍不住涉入到技术问题中去，反而可能忽视了本来的职责。解决的办法就是要管住手管住嘴。但现实中当你越界时你自己往往是没有知觉的，所以就还有一些实践小技巧，比如你们团队间可以协商出某种方式来提醒你越界的事，如订做一顶大牛帽子，只有当你带上这顶帽子时才能扮演技术专家的角色，如果你不自觉的扮演了技术专家的角色的话，就要予以一些处罚，比如请喝咖啡等等。

总结一下，就是你作为一名SM，如果你很懂技术，你不是不能涉入到技术中去，只是你要有一种边界感，知道什么时候你是在扮演技术专家的角色，什么时候又该回到SM的角色。

记录完这两个问题黄老师的回答后，我想可以回到最开始的小辩论上来了。

“Scrum Master懂技术是利大于弊还是弊大于利”

虽然黄老师是站的正方，但我觉得黄老师其实心里还是向着反方的，哈哈。言归正传，如果做个比喻，我认为这个辩题，其实是类似于贝壳的东西，贝壳本身并不珍贵，珍贵的是贝壳辛苦酝酿出的珍珠，而辩题酝酿出的珍珠，其实就是它延伸出的一系列问题。

比如，大家应该都听过一句话，叫技多不压身，不管这个懂技术里的“懂”和“技术”具体指的是什么，SM懂技术当然都会给他的工作带来优势，具体可以带来哪些优势，这个也比较容易想到，比如可以更好的和团队沟通、融入团队等等。那么相对应的懂技术的优势，就是不懂技术的劣势，针对不懂技术的劣势，如何来补足呢？
这个可以参见前面黄老师对于没有技术背景的SM感觉无法融入团队怎么办的回答。那么SM懂技术除了能带来优势外，有没有可能带来劣势呢？这个之前群里讨论也有群友指出过，一个可能就是瞎指挥，一个就是虽然不是瞎指挥，但是把原来SM的职责给放下了等等。
针对这种情况怎么办，可以参见黄老师对技术能力非常强的人，他来做SM会遇到哪些问题？的解答。对了，黄老师其实还补充了一个SM懂技术对SM本人的劣势，那就是这可能会让SM停留在舒适圈，而没有去扩充自己的能力圈，去打开自己的视野。

更进一步，我认为，当我们在辩论“Scrum Master懂技术是利大于弊还是弊大于利”时，其实是在辩论技术与SM间的关系。借用波士顿矩阵法用两个维度来分析这个问题，首先，懂技术是不是SM的核心能力？其次，我们也都知道，SM他必须还是得懂一些技术，那么这个懂技术的懂的边界在哪里，是知道性的懂还是深入性的懂？对这两个问题，我认为我和黄老师是达成了一致，即，懂技术不是SM的核心能力，倾听、提问、以及学习的能力才是SM的核心能力；SM懂技术需要的懂是知道性的懂，而不是深入性的懂，当然，具体的SM他可以是一名技术大牛，不是大牛的SM也可以去追求深入性的懂，但这并不是对SM的核心要求。

再进一步，虽然没有明说，上文在辩论技术与SM间的关系之间提到的技术的概念默认还是IT技术，但这个概念其实可以替换为更广义的技术，上面的结论依然不会改变，如黄老师举过例的一些传统制造业的例子，还有日语课件的制作例子等等。

又进一步，我认为，上述结论里的SM名词也是可以被替换掉，而结论的框架依然大致不变的（结论里的具体元素要变），比如把SM变为项目经理、产品经理等。站在SM的立场上来看，也可以从一纵一横来扩展自己的视野，一纵是指从团队到组织到公司，一横是指不同的行业，像黄老师举得很多不同层级不同行业的敏捷转型例子。

另外黄老师还回答了几个问题，比如具备管理层背景的人想加入敏捷团队怎么办？还有一个关于考证的问题等等，我这里就不一一记录了，有兴趣的朋友自己再去看视频回放吧。另外，值得注意的是，黄老师在里面的回答时有一些点冒出来，这些点都值得进一步思考，比如黄老师讲的泰罗制到SM的绩效考核，就激发了我许多思考，但这次来不及写下来了，大家可以看一下是哪些点比较能够吸引你。

顺带再插一句，之前连线时因为网络问题，不但我这边的视频信号没有传过去，lisa和黄老师的视频信号也没传到我这边来，我这边是静态的，这次看回放发现，嗯，黄老师果然很帅，lisa也是美丽大方，善良可爱。

回放的介绍：

Ethan和小新做客直播间期间，带来了非常精彩的话题，包括但不限于： - Scrum Master是否需要技术背景？ - 没有技术背景的Scrum Master应该补充哪些知识和能力。 - 有技术背景的人做Scrum Master应该注意哪些事情。 - 管理人员是否可以做Scrum Master。 - Scrum Master的绩效考核该怎么设置。