01 Scrum 中的争球

Scrum 在敏捷开发中是非常有意思的一种模型，虽然在国内被采纳的公司比较少。 我买过超过 3 本 Scrum 图书，不过它们并没有把 Scrum 背后的人性密码讲出来。

如果对 Scrum 感兴趣的朋友，推荐阅读官网这个材料：

https://www.scrum.org/resources/what-scrum-module

比较简明的说明了作为 Agile Framework 它的一些工作方式和流程。

但是关键的内容隐含在 Scrum 这个词的起源中，Scrum 的英文含义是争球。我在学习 Scrum 时，讲师提到一个要点：工作任务不能由 TL 分配，而是让团队成员自己领取

为什么呢？ TL 分配工作任务不更加便捷和符合逻辑吗？培训的讲师没有说明，只讨论了这是 Scrum 框架中倡导的。

直到我作为 TL 时，惯性的让团队成员领取任务而不是分配任务，这种机制可以工作。但是我尝试自己分配任务时，发现一个问题，分配任务这件事情并不容易。

软件工程并不像建筑一样，每项工作可以被清晰的定义。也就是说，软件开发工作很多时候并不像工程，更像写作。修建一座房子，砌筑一面墙所用的工作量是很容易计算的，然而编写软件往往会出现各种各样的差异，有可能捡到便宜、也有可能遇到麻烦。

在很多时候 TL 并不能完全清晰的掌控每项任务的细节，不能很好的分配任务，以及设置时间节点。

通过考察人性我们会发现，在长期工作中，我们不得不顺应人性制定规则。即使短期内，可以克服人性的弱点，长期来看，人性的效应会慢慢被放大。

任何团队和工作，人们都希望拿到手中的任务工作量、难度和估算匹配，如果能估算的人天能充沛一点更好，这样就能“摸鱼”了。

通过自己领取任务，人们会倾向于先领取简、估算充足的任务，完成手上的工作后，赶紧领取下一项估算充足的任务，这样一个迭代完成后，完成的工作量会更多。

虽然很多时候有运气的成分，但是我们通过完成的工作量作为考核的维度之一，依然是可靠的。

争球让工作量估算变得更容易，也消除了因为工作量估算不准确带来的团队矛盾。

02 关于制度设计

Scrum 是一个不错的制度，从 Scrum 引申出来的是如何设计一个有效的制度？

对于管理者来说，可以通过命令或者设计一个制度来达到自己的管理目的。如果通过命令来完成所有的业务的任务分配，这显然不现实，所以如何设计一个有效的工作制度呢?

我的经验是，以人性的弱点设计制度的下限，以人性的优点设计制度的上限。

争球是任务开发分配的制度。在很多公司，开发任务往往有两个极端。一个极端是让 TL 来分配任务，谁来做、需要做多久全靠 TL 的主观判断；另外一个极端是让 PM 通过估算+甘特度来严格管理。

如果让 TL 完全分配任务，无论是从 TL 的责任心上还是 TL 的工作负荷上都很难关注到一个团队每个人，所以很多时候 TL 自己忙起来，团队有些人在划水也没人知道（真事）。

这样的制度需要考验 TL 是否积极关注每个人的工作任务，也要考验团队成员是否主动报告自己没活儿干了，把制度的下限放到人性的考验上，这是非常危险的事情。

反过来，如果通过 PM 严格管理每个人的工作进度，每个人没有弹性空间，虽然大家都在干活儿，在下限方面不存在问题，但人的创造性也都限制住了，无法发挥人性的优点。

其实理想的制度并不存在，但制度和人性的关系需要仔细考虑，在很多时候人性的优点和弱点混杂到一起。

正所谓不管就乱，一管就死。

很多公司的报销制度就在这两个极端中反复摇摆。一会儿强调信任每个员工，这样就会导致大量的超额报销，甚至这些超额报销有可能是员工没有理解报销政策导致的；一会儿严格限制报销流程，导致在很多特殊场景被报销政策限制住贻误商机，例如临时发起的会议物料采买、紧急处理客户投诉等。

03 总结

关于人性的洞察在管理中的应用有非常多的内涵，从某种程度上来说，好的管理者往往对人性有非常深刻的洞察。

人性是一个中性词，它代表的是人在社会活动中的行为规律和反应。通过理解这些行为规划，可以创建更好的秩序，并让团队工作的和谐。