[Day05] 团队无杂事，只有混乱的讯息流

在前公司时，有一天，同事愁眉苦脸的来找我：

「学长，PM 跑来问我 A 同事的东西什麽时候会搞定，QA 来找我要新的测试版本，等下的 Planning 会议一开就是一个下午，我自己还有几个 Bug 还没修，当初 X 主管跟我说，当 Scrum Master 就是要处理很多团队的杂事，跟当主管差不多，先习惯一下对我有好处。可是觉得实在好累。」

在台湾，愿意聘雇专职 Scrum Master 的公司，仍属少见。由主管兼任 Scrum Master ，变成普遍的权宜之计。但是否这样就意谓着，主管一定会被所谓的「杂事」淹没呢？对开发者出身的主管来说，我们太习惯，也太喜欢享受写程序时，进入「心流」状态的感觉，对於写程序以外的事情，一概视为「杂事」。换了位子，一定也要换脑袋。我认为，团队中，没有所谓的杂事，而是存在着复杂的「讯息流」。

举例来说，任 2 个团队成员间的沟通行为，就会产生１道讯息流。而 5 人团队的的讯息流，最多就会高达 20 道。以此推论，愈大的团队，沟通的成本也就愈高。当团队中有跨职能 (PO/PM、QA、RD、设计师) 的讯息需求时，与其自己面对这麽复杂的讯息网路，生物本能会趋使我们使用最节省能量的方式达到目的：「不如去找 Scrum Master 吧。」於是，就产生了半调子的仆人式领导（servant leadership) ，简单来说，主管成了仆人。

此时回头拆解同事的困境：

• PM 需要任务何时可以完成的讯息
• QA 需要知道何时拿到新版本的讯息
• Planning 会议是整个团队在交换讯息

只要能将讯息自然地流动到它该去的地方，而不经过主管这个节点，所谓的「杂事」其实也就不存在了。人可以透过改变地貌的结构，来引导水流方向；讯息流，也是一样的道理。所谓的结构，其实就是「系统」。

工程上，系统的定义很单纯：将资讯输入，系统经过处理、运算後，将结果输出。一个稳定的系统，可以在最小的监督与维护下，持续的运作与产出。Scrum 团队，其实就是一个系统，根据客户需求（输入），进行开发迭代，交付产品（输出）。每个成员，就是系统的组成「要素」（Factor)。多数无法高效产出的 Scrum 团队，一部分问题就是出在成员间的讯息交流，导至需要主管／Scrum Master 居中协调。我认为主管就是团队的「系统架构师」，而系统的最终目标是，即使没有 Scrum Master ，整个团队对能有自导航、独立运作的能力，这与 Scrum 精神提倡的「自组织」，其实也是相互呼应。

良好的团队系统，就是主管能过上幸福日子的解药。如此，主管才能空出手来，精进自己，突破天花板。接下来的文章，我将细节地与大家分享，设计与修正 Scrum 团队开发系统的实务经验，我们明天见。