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

我们接着上篇继续聊。

问题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）不仅引起QA的关注，PM、BA其它角色都在关注它的状态。什么时候可以联调，什么时候可以被验收？这带来的是一种无意识的集体内耗。

WIP越多，被动的等待越多，这种无意识的内耗就越多。

5. 救火模式在工作，总在做紧急的事情

总是点火再救火的事后补偿模式。比如团队突然发现方案的漏洞，很多已知问题（比如技术风险）但没有去思考如何解决，结果被问题赶着跑，进入了负向循环的圈里。

怎么办

敏捷团队谚语：不能搞定事情保护团队，为团队扫清障碍的Scrum Master不是好PM。

团队的时间和注意力就像客户和团队的投资一样，有成本有收益，需要有合理的投资策略才能取得成功。如果团队无法在迭代的窗口内专注工作，又如何能要求他们给出高质量的工作。

那，怎么办呢？

作为手握这么多资产的你，需要向团队和客户交出合理的答卷。幸运的是，不论《高效能人士的七个习惯》，还是《卓有成效的个人管理者》等个人效能的书，都已经给出了很多提高效能和时间管理策略。而这些放到团队这个有机的生命体上同样适用。

这里分享几个tips：

1. 主动规划，建立内外规律的沟通计划，约定时间窗口，有效保证团队的大块工作时间和工作习惯

一个应对碎片化工作最好的习惯，就是主动规划工作任务和时间。对于团队也是一样，需要主动的规划，建立有序的内外沟通计划，避免被别人的安排打乱了你的计划，这样提升了团队的抗干扰能力和效率的同时，也提升了更大范围组织的协同效率。如下图示例：

从站会开始安排团队的一天
Code Review尽量安排在一天的结束前
为BA/QA/Dev角色协作的任务建立规律的时间段，如用户故事的开卡验收尽量放在下午的开始
为必要的外部干系人的沟通预留时间（比如PO的相关计划会议和Showcase验收会议)
和第三方集成或沟通会议要么是上午要么是开始的时候
为迭代的几大集体会议预留时间段，且保持规律的节奏。如果一周一个迭代，那么周二可以开始新的迭代，下午进行IPM/技术方案共识的时间，周一下午是本迭代的retro时间。
为团队的集体学习留足时间
为团队迭代关键任务（比如最后的冲刺发布）预留时间

约定这些时间的时候都应遵循以下原则：

尽量给所有角色规划可以专注工作的大块时间
尽量放在一个周期的开始和结束
尽量保持不变的规律和节奏对外建立简单的沟通规律
与团队约定，并让所有相关人看到并遵循

对于一个敏捷团队来讲，变是唯一不变的东西，上述这样的规划也并不是一成不变的，这样的建议更多的是可以保证团队中明确的协作任务可以被有序地执行，以保障大部分的时间和注意力可以是高效的。

善于规划的人胜，善于规划的团队也定能保持专注和高效。

2. 管理团队的认知负荷，约束团队的认知边界与职责，创造心流体验

认知负荷在早期的项目管理中很少被提及，但是随着知识工作者的出现，团队的认知负荷成为越来越多决策的重要要素之一。对于一个Scrum团队的建议是

尽量维持且有意识去维持较小的规模（5-8人）
同一迭代不要超过3个复杂领域的特性开发
人员尽量变动不要超过20%
保持稳定的交付节奏，即使偶尔加班也不要连轴。因为通常连轴的工作量和压力容易影响交付，以及长期的结果。

3. 培养和赋能团队要事第一的习惯，与团队共识哪些事情是团队第一优先级的事情，哪些是不重要的、无价值的可以不做，哪些能工具化或者委托团队外的他人代办

需要将团队的迭代任务，高优先级的任务，识别的风险按照紧急重要的时间四象限进行排列，并可视化，建立处理流程，确保团队将时间和注意力放在第一优先级的任务上。

4. 制定定期的风险Review会议，提前处理或规避风险，防止风险变成突然的Surprise

5. 屏蔽不需要的变化，让不得不发生的变化有序地发生

很多时候的变化是不可避免的，也很多时候有些无序的干扰。团队Leader一个很重要的工作就是扮演好团队的干扰过滤器，对于无序的干扰和任务安排，需要有明确果断的处理措施，避免再次发生。尤其在迭代冲刺的时候，不要让外界的沟通随意侵入我们的团队，让我们的Dev变成客服和PO小秘书，让我们的交付节奏受阻。尤其是一些小的变化就有可能导致团队指数级的影响和成本丧失。

总结

坦诚讲，让开发保持聚焦避免被打扰是PM赢得项目人员尊重的重要Credit之一。

作为团队Leader的你，需要保护好团队最重要的东西：时间和注意力，有策略的管理人员变动、任务变动、工作打扰、多种任务并行开发、前后端联调、等待浪费、上下文切换这些暗时间的消耗；主动为团队构建内外的沟通计划和要务优先的行为习惯，保持良好的认知边界，做好干扰屏蔽器避免无谓的打扰，而这些看似细微的选择和习惯就会给团队带来不一样的投资回报。

善于进行规划的人，可以无形中比别人多出许多时间。团队管理也是一样，可以让团队成员间减少过多”暗时间“的消耗。这不仅是对团队的交代，也是为客户提供服务的专业行为和态度。

那么，如果重来一个迭代，你的团队有7个人，一个迭代两个周，总共2407的工作时间，你又会如何制定投资规划呢？

问题5：团队的关系有多远，信任的电量还剩多少？如果用1-10分的尺子来衡量，你们团队是几分？

（图片来源：https://unsplash.com/photos/CDoKLQeUHyk）

人脑有两个神经特质可以让我们与其它人群建立信任并协作。这种信任关系可以影响人的脑活动和能量状态，激发渴望，可以对人的行为起到非常强的杠杆作用。

信任是将一群人从团伙变成团队的前提，是团队高效协作不可或缺的基础。不管是《团队协作的五种障碍》还是《管理3.0 培养和提升敏捷领导力》、《敏捷革命》这些经典书籍里都提到了信任关系对于构建敏捷团队的重要性。

我想分享另外一本书《The Agile Culture: Leading through Trust and Ownership 》中的信任-责任模型，谈谈我对敏捷团队的信任和 Ownership 的理解，以及作为新Leader如何把脉和构建这样的关系。

1. 认识TRUST-OWNERSHIP MODEL

敏捷文化的核心或者源泉是对团队的”信任和Ownership“，团队的每个人知道项目想要取得的结果，并对结果肩负责任，它们是团队活力和创新的基础，也是高绩效的基础。

只有信任不放权并不能促成这样的变化，必须依靠信任和Ownership的珠联璧合才可以释放团队的潜力，做出改变迈向高效。团队从左下象限向右上象限走得越高，越容易获得更大的成就和价值。

图中的纵轴，指Leader以及公司流程表现出来对团队的信任程度。

信任越低对团队的控制越高，流程、跟踪、治理、控制、审查、报告、汇报、申请许可、繁杂的审批流程这些微管理手段会越来越多；信任越高对团队的赋能就越高，只存在轻量且必要的流程协助团队完成任务。团队懂得项目的重要性，致力于为客户交付价值，信守承诺，优化现有过程，持续改进取得成绩。

横轴，指团队对项目和公司所做出的的承诺以及表现出来的 Ownership 。

Ownership 越高，团队的承诺也越高，团队成员会尽全力完成团队共同的目标；反之，Ownership越低，则承诺越低，绩效就越差：

”我只完成领导安排的任务“
”我是老板我知道该做什么“
”严格规定团队做什么如何做“
”替团队做重大决定“
”对问题保持沉默“
”出了问题就抱怨其他人“
”成不了交付不了与我何干“

这也是命令和控制象限中团队的常见行为特征，可能因为过往的失败或者所处公司发展的不同阶段以及文化的影响，最终营造了一个互相抱怨的环境，而非共同努力，共同面对，一起克服困难。这样团队的士气也会受影响，项目延迟交付，效率低下是常见问题。

看到这里，你可以先试问一下自己是否有如下的行为：

没有问过团队某件事情可否能做到之前，就要求承诺一个某日之前的Deadline
没有和团队讨论或考虑其它可行的办法之前，就要求团队承诺”按我说的做“

这些看起来简单的行为，团队会马上意识到不信任，士气低迷将由此而生，就这样形成了团队不可见的隐性冲突。

图中，左上的失败象限指领导完全信任团队但团队并不在乎所做的事情，对结果没有责任，做坏了做好了和我无关，没有绩效。团队处于失败象限，领导就会担心团队不作为而加强控制，或换人或拆团队或收回决策权等，快速地转向命令与控制。

右下的冲突象限则是因为团队之间、团队与Leader之间的信任几乎为零，互不认可。团队处于冲突状态，要么冲突激化造成失败，要么沉默不发言，而苟于领导的安排。在这种状态下，停留越长伤害越大，对团队和成果都是如此。而Leader要么调整资源重建团队信任，要么团队放弃，让领导收回所有权，进入强命令与控制。

2. 把脉你的团队现状

那么，在了解了TRUST-Ownership Model之后，你和你的团队处在哪个象限？团队的信任电量和Ownership还剩多少？如果用1-10分的尺子来衡量，你们团队是几分？

这里一并也分享以下问题帮你和你的团队进行分析，书中有详细的信任-责任的评估表格，若有需要可以参考：

是否有成员连续几天在站会上说“马上就做完了”
是否有成员在不打招呼的情况下直接把他人刚提交的代码删了重写
大家在开会时都会建言献策吗？还是一言堂？
是否有成员在会议讨论中（比如Retro/IPM）全程路人甲，一言不发
大家是否敢于暴露问题？是否敢于承认错误？
是否可以在团队中放心地谈论自己的弱点吗？
大家彼此间互相了解吗？每位成员在沟通时会相互尊重吗（尤其在重要时刻）？
对于其他成员的困难，大家是积极伸手相助，献言献策，还是默不作声，漠然视之？
是否有成员推卸责任，抱怨他人的行为导致了自己的过失，甚至诬陷他人
大家是否能轻松交流想法，给同事结构化的反馈？
是否总有各种议论和冲突
工作只是走过场，不分配的任务没有人认领
有意无意的迟到

3. 认识信任和Ownership

在谈到How前，让我们再进一步了解信任和 Ownership 是什么。

信任要先予之方能得之。信任他人者，他人信任之。

Stephen M.R. covey说“信任就是相信一个人的品质和能力，信任的四个核心是诚实、动机、能力、成果。”

从心理学的角度，信任=相信意图乃至行为，信任是哪怕对他人意图或行为的积极预期会导致自身出现弱点，也愿意予以接受的一种心理状态。信任也是别人对你是一个怎么样的人的认知，以及对你会做什么的预期。

从行为层面，信任指团队成员相信彼此的言行是出于好意，在团队里不必过分小心或互相戒备，成员间放心地接受彼此的批评。互相信任意味着大家开诚布公，彼此可以真诚地沟通交流。

而麦肯锡有一个重要的信任公式，它提炼了建立信任的4个要素：

1）可信度：这人是不是专家。

你是否让他人可以相信你这个人。这取决于你解决问题的能力、经验、专业知识、资源等等；这个人的专业能力是否真有别人说的那么出色，是否能够胜任这份工作呢？过往的履历中是否做过足以让我值得信任的事情。说白了就是这事我能不能信你，能不能给你时间，给你空间，给你机会，给你资源。

2）可靠度：这人是不是能出活。

你是否靠谱，你是否能按时、保质地干成事。”凡事有交代，件件有着落，事事有回音“。以及言出必行、表里如一。

3）亲密度：和这人工作是不是让我感到舒服。

你是否有亲和力，招人喜欢，是否愿意接近你，和对方熟不熟，有多熟。比如工作之余是否原意和你喝两杯，聊几句，想起你的时候是不是有些温暖。互相越了解信任越高。

4）自我取向（自私度）：你是否以自我为中心，做事总先考虑自己的利益。即使你很可信、可靠也很熟，但如果你总是从自我出发而不是他人或者团队优先的视角考虑问题，也难以取得他人的信任。人呢只有相信你的意图，然后才能相信的你的这个人。

Ownership 原意指所有权，又称完全物权。在民法上，权利人对标的物可以直接全面排他性支配特定物的物权。工作中的 Ownership 泛指对目标任务的所有权、主人翁意识等，它的另一层含义是指拥有权利的同时也拥有同等的责任，团队充分掌握自己负责的工作任务目标，拥有做出决策的权利，且敢于担当，积极主动去解决问题。

简单总结一句话，信任和Ownership是：

我相信你能胜任这项工作，你会与大家分享相关的信息，你言出必行，我相信你的承诺，而且你对整个团队有良好的动机。

作为Leader需要深入理解信任和 Ownership，才有助于我们更好地构建之。

如何构建团队的信任和Ownership

对新晋Leader，从原先独挡一面的团队贡献者到带领团队。往往对如何赢得团队信任和带领团队的工作上存在挑战，一方面既要快速的做出成绩证明自己的能力，另一方面又要能够敢于授权为团队负责。

在这里我给出以下几点建议：

做人：尊重谦逊，坦诚开放，让团队更多的人了解你

人非机器。信任的前提是尊重，每一位成员都是平等不同的个体，有着各自的优势和多样性。尽管不可言说，但尊重、信任、坦诚这些种种关系人们是可以通过你的言行举止感知到的。遇到重大关头的时候，就会如人饮水冷暖自知。只有且必须尊重每一位成员（话语权、信息权、所有权等），才能产生信任和 Ownership，成为Trusted Leader。

其次，信任的构建要先与之，才能得之。加入团队伊始或者角色转变的时候，首先需要让团队更多的了解你，信任始于你迈出的第一步给团队留下的第一印象：

风趣的自我介绍
对项目情况的了解
倾听当前遇到的挑战
1:1成员沟通

再次，在于信息的透明和沟通到位，及时地让大家看到问题、进展及反馈，避免surprise；在涉及团队相关决策的时候，更需要和团队建立预先沟通和商量的渠道，邀请共创和共同改进，制定规则，激活Ownership。

最后，坦诚和开放。我们每一个人都是有局限的，出错是很正常的，尤其是在刚开始去接受一个新挑战的时候。出错之后试图掩饰错误不懂装懂是最愚蠢的行为。也没有必要试图维护”我“的正确性，而是需要坦诚错误、承认局限、聚焦改进。

因为作为Leader，确保“正确的事情和以正确的方法做事情”，比 ”自己是不是正确“的更重要。

成事：发现和带领团队解决棘手的问题

带领一群知识工作者或者极客，一个很重要的赢得信任的条件在于成事。大家更容易因为你的能力和专业而佩服和跟随你。因此，作为Leader，带领一帮专业人士的时候更重要的是通过成事来获得团队的信任。

你可以选择团队当前的棘手挑战入手，充分了解情况，过往的努力和障碍，然后从小的改进入手，分享你的行动计划，把问题解决展示承诺。

促进：成为团队的催化剂，增进了解，培育文化，鼓励有效冲突，引导团队以正确的方式做事。

Leader是团队的催化剂，需要善用各种活动将团队成员凝聚在一起，增加彼此的了解。比如：

Team building活动
Do Food一起做饭
新人Onboard的仪式感
Small success-阶段性的庆祝
Hometown Story
TEAM Appreciations
我想听和/你想讲分享活动
心情曲线

Leader是团队的Facilitator。信任意味着敢于反馈和质疑。Leader既要凝聚和团结大家，又要鼓励冲突，激发善意，因为表面和谐的假象对于解决问题和团队的成就并没有什么用。

有冲突并不是坏事，坏在于Finger point，人人相轻、互相指责，缺乏包容理解。因此Leader在冲突下的规则建立和正确的引导就很重要，包括发言规则、罗伯特仪式法则、结构化的围绕事实的反馈、基于倾听的对话都是必备的工具箱。

Leader同时也是Enabler。对于专业人员来说，最大的驱动力是在技术专业高度上的攀登，这是深深刻印在骨子里，绝不是物质刺激的外部力量所能带动的。一个真正的软件技术人会不断地对新技术、新问题，方案，对架构代码都有着无法抑制的好奇心、冲动、不服输、以及成就感。如果这个缺乏，我可以肯定地说绝无可能做到优秀。所以作为Leader，要关注团队的学习分享和工程卓越的文化氛围，保护这些时间的花费和投入，这是内在原生的驱动力，而这些投入也是值得的，因为这是我们所坚持正确做事的方式，比如：

4. 保护：识别Bad Apple，及时介入并制止

这里的坏苹果是个隐喻，它指的一种行为，而不是一个人。这种行为就像一种疾病，它让团队生病，让其他人不舒服，或者让其他人也表现得不好，即引起破窗效应。

比如：

有毒(toxic)行为（欺凌、嘲笑/严重取笑他人、侮辱、骚扰 - 种族、年龄或性别）

冷漠（缺乏纪律、缺乏主人翁意识、缺乏责任感、缺乏热情）

有感染性（Finger-point、安全问题-不锁屏、CI红着过夜）

为什么要关注？

好事不出门坏事传千里。1个坏的行为比100个好的行为所产生的破坏力更大。不及时制止会让整个团队就像一筐子苹果的故事一样都受到影响。

作为 Leader，当发现有一个坏苹果时，需要能够及时识别它。发现后不要责备个人而是关注机制的改进。要去了解和分析坏苹果这种行为的影响，改善机制，并快速执行。

5. 写在最后

如果你接纳了一种工具，也就意味着你接受了潜藏在这种工具内的管理哲学。-克莱.舍基

对于一个敏捷团队，信任和 Ownership 的文化基因有多重要，就毋庸置疑了。我们鼓励团队拥抱变化，尽早和不断交付有价值的软件。而如今内外环境的不确定性、时间和节奏予以的多重挑战，时时刻都在对企业和团队做着”压力测试“，就更需要团队正视这种不确定性、彼此信任、积极沟通、主动响应变化，兑现承诺，并持续地改进。

这样的团队一定不是被安排和计划出来的，而是靠一个好的Leader带领大家一起构建起来的。作为新晋Leader则需要身先士卒做人成事，从“要求”信任到“赢得”信任。人们在这样Leader的带领下：

共享愿景与目标
快速获得任务所需的信息资源
有序规范的协作
肩负信任和Ownership

团队管理是一门科学也是一门艺术，而真诚是最好的套路。五个问题帮你把脉，从青铜到王者你学会了吗？

文/Thoughtworks 禚娴静

原文链接：如何高效管理一支开发团队（下）