你的团队是王者还是青铜（下）

我们接着上篇继续聊。

问题4：谁动了团队的时间？如果重来一个迭代，你有7*40个小时的投资，你要如何决策团队的工作安排？

“小溪，一会约开卡；小溪，我这有个问题；小溪，一会约验收…”
“龙哥，第三方集成那边临时有个会议，需要来沟通一下；龙哥，客户那里有个代码规范变化了，你来看一眼；龙哥，API设计的不对；龙哥，日志找不到了…”
“阿泰，七哥，早上新开的卡都先别做了，有另外一个feature进来”
“小波（刚加入团队2周），需要你去另一个团队”
“刚打开微信准备回复一个消息，看到之前同事的消息又顺手处理一下，一封邮件从屏幕上弹了出来，又顺手点开”
。。。。。。

“公司特别热衷于保护，保护了那么多的东西，却总是没能护住最脆弱也最稀有的东西：员工的时间和注意力…，这是我们最稀缺的资源” 。而在Thoughtworks，每位项目人员的工作时间也是对客户的承诺，是我们作为团队最重要的资产。

那么，作为团队的Leader你是否计算过团队成员的时间投资成本，你是否可以保护好每位项目人员工作时间的合理投资？

我观察到主要有以下几个反模式：

1. 团队成员经常被未计划的事务打扰

大多数程序员在写代码时都有一个体验，那就是一旦打开IDE，开始写代码后，就可以很快进入心流的状态，思路全是代码、测试，编写逻辑，方法名入参出参等等，

这个时候的大脑会很兴奋，一直在忙碌地计算着，好不容易代码看懂，也弄清逻辑了，马上测试就要通过了。突然有同事找你问个问题，或者PM来问你进度，或者说临时有个外部会议，临时任务等等。

等你再回来的时候，就发现“完了芭比Q了“。咦，我刚才做到哪里了，脑子出现短暂的空白。而要想再回到原来写代码的地方，就需要一段时间来调取之前的记忆。如果经常被打断，效率和工作体验都会大打折扣。

漫画《当一个程序员一天被打扰 10 次，后果很惊人》里面就有这样的分享：

• 一个程序员被打搅后，他需要10-15分钟的时间才能重新恢复到之前的编程状态。
• 当修改一个程序函数时被打搅，只有十分之一的程序员能在一分钟内回到之前的思路。

其实，这背后的逻辑就在于任务切换是需要成本的。小到写代码，大到团队。频繁的切换工作上下文，就会消耗大量的时间在切换上而非专注地完成任务。

而最讨厌的是，这些切换成本并不容易显性地被表达，到站会的时候，你可能会发现，好像也没有什么阻碍，但进度并没有按预期进行。

如果团队频繁出现这样的状况，这样的“暗时间”越多，整体的效率就会越差，团队成员的体验和工作状态也会受到影响。

如果你想要一个低效的团队，那么随时打扰、调整计划，无目的的任务安排，你一定会成功。而作为投资人的你，无疑是失败的。

2. 团队一天的时间经常被切割的很小

切分60分钟有很多方法：

• 1*60
• 2*30
• 4*15
• 25+10+5+5+5

《重来3》用一个数学题形象地展示了时间的切分策略给效率带来的影响。上面的算式结构都是60，可是效果却完全不同，质量也完全不同。

如果个人一天的时间被切分成这样，很多都是零碎时间也很难说可以做出有效的思考和有质量的工作，而如果你的团队大多数人的时间也是这样的：

• 9:15 站会，
• 10点IPM
• 11点测试策略讨论
• 3点Retro
• 5点Code Review

这样被切分的零碎时间片段，如何能有高效的产出。

3. 多任务处理，团队认知负荷过载

虽然多任务处理是职场人士需要掌握的一种能力，但在一个迭代内，多种任务并行处理无疑是增加团队的认知负担，想象一下如果超过6个特性在一个迭代内出现，对团队的消耗是什么？忙乱的假象，以及不必要的团队认知负荷。

对于一个5-7人的Scrum团队来讲，这个迭代基本就是包干到户。因为，一旦一个团队整体认知负荷过载，团队就无法像一个单元一样运转，每个人都在试图努力完成个体任务，却无法关心是否能给团队带来最大的收益。

通常在一个迭代里有超过3个复杂领域的特性开发，就需要重新复盘你的迭代计划和团队边界的设计。

4. 前后端联调的集体内耗

我们都知道，没做完的事情也会在大脑中留下一个隐藏的进程，时不时蹦出来，打断你正在做的事情。

在”前后端分离“的交付团队中，最常见的是前端开发完成等待后端的例子。前端已经工作在下一张故事卡，但这时候未完成的卡就会像后台的进程一样在工作，站会的时候还会被重新激活。

这件未完工件（WIP，Work in Progress）