你的团队是王者还是青铜

文章来自：ThoughtWorks，世界经理人经授权转载。

“

4月18日早上9点30分，团队跟着大屏计时器整齐地喊出倒计时，“五、四、三、二、一”，Tech Lead 强哥和 PO 小楠相对看了一眼，一起按下了earth系统发布的回车键。随着app和web系统用户登录的叮咚声不断响起，earth系统正式上线成功。会议室里也再次响起了团队的掌声和欢呼声。

”

那曾经是我职业生涯中为数不多的高光时刻，让我至今记忆犹新。

在我们每个人的职业生涯中，也总是希望能加入一个优秀的团队，一起经历这样的高光时光，项目成功自己也有所成长。而当自己成为团队Leader之后，也希望自己能够带领出这样优秀的团队，乘风破浪，创造这样高光时刻。

那么，如何实现呢？作为团队新任Leader，可以从以下5个问题入手，为自己的团队把把脉。

问题1：团队目标和交付价值是什么，团队成员是否知晓且对此有一致的共识？

“

“如果没有目标，那么任何风向都是逆风；”——摘自网络

”

明确的目标会为团队的工作引导方向，就像航行不能少了罗盘，再大的船也需要有明确的航行目标和方向，再强的出海舰队也需要对去往的方向和如何应对险阻有一致的共识。

没有了目标和共识，团队不仅会偏离行驶的目标，也会在一望无边的任务中忙乱、彷徨、失措而最终黯淡离场。

作为团队Leader，首要任务是从繁杂的信息中明确目标，并清晰地传达给团队每一个人。如果说一个Leader只做一件事，我认为是设置清晰明确的目标，并让目标在团队中达成共识。

然而，能做到这一点的团队并不多。

我观察到最常见的问题不在于有没有，而是在于新Leader多无意识地忽略了这一行动举措，仅传递我们要完成的任务。很多团队中开发人员在写代码时并不知道这个迭代的交付优先级和业务价值，已是常态。

“

敏捷谚语：“所有的Story缺省都是无效需求，除非它有明确的价值”

”

团队成员作为执行个体不知道目标和价值，就只能尽可能根据自己的理解去优化自己的执行过程和结果。这往往会导致：

● 反复执行方案的浪费

● 追求任务本身优化和细节尽善尽美，导致未预期的开发过程蔓延

● 或出现与目标不匹配的结果偏差

● 乃至导项目的延期交付、成本蔓延、目标偏离等问题

曾经有这样一个心理学家的试验（摘自网络）：

“

这个心理学家组织了三组人，让他们分别向着10公里以外的三个村子进发。 
第一组的人既不知道村庄的名字，也不知道路程有多远，只告诉他们跟着向导走就行了。刚走出两三公里，就开始有人叫苦；走到一半的时候，有人几乎愤怒了，他们抱怨为什么要走这么远，何时才能走到头，有人甚至坐在路边不愿走了；越往后，他们的情绪就越低落。 
第二组的人知道村庄的名字和路程有多远，但路边没有里程碑，只能凭经验来估计行程的时间和距离。走到一半的时候，大多数人想知道已经走了多远，比较有经验的人说：“大概走了一半的路程。”于是，大家又簇拥着继续往前走。当走到全程的四分之三的时候，大家情绪开始低落，觉得疲惫不堪，而路程似乎还有很长。当有人说：“快到了！快到了！”大家又振作起来，加快了行进的步伐。
第三组的人不仅知道村子的名字、路程，而且公路旁每一公里都有一块里程碑，人们边走边看里程碑，每缩短一公里大家便有一小阵的快乐。行进中他们用歌声和笑声来消除疲劳，情绪一直很高涨，所以很快就到达了目的地。
在这个心理学试验中显示，当人们的行动有了明确目标的时候，并能把行动与目标不断地加以对照，进而清楚知道自己的行进速度与目标之间的距离，人们行动的动机就会得到维持和加强，就会自觉地克服一切困难，努力到达目标。

”

以上试验向我们证明了目标对于团队的重要。在一个敏捷团队，产品需求不明确，价值交付是唯一方法时，就更需要有明确的目标和价值主张。这样才能指导团队用“简单足够”的设计去“敏捷地”为客户交付可工作的软件，尽快验证价值获取反馈。

与此同时，当一个明确而又看得见的目标在团队内的时候，还会成为激发团队的动力，甚至会让团队焕然一新，创造奇迹。目标有时候不在于多高大尚，而在于团队是否清晰明确的知晓，它的力量甚至超出你的想象。

那么，一个项目的目标包括什么？

● 项目画布（Project Canvas）包括项目的目标/愿景/MoS/价值主张

● 工作说明书（SOW-Statement of Work）中的交付承诺

● 服务框架协议（MSA-Master Service Aggreement ）中定义的客户信息安全要求及其政策

● 项目的交付周期、关键交付里程碑

又如何让大家看得见且形成共识？

第一，构建信息辐射体（Information Radiator），比如利用物理墙、jigsaw电子墙、团队会议模板等可视化渠道传递项目的关键目标。

第二，使用下面这个问题详单帮你在日常工作中融入目标的维持和加强：

● 是否在Onboarding的时候向新人介绍项目的目标、关键里程碑、MVP。

● 是否在Onboarding的时候向新人介绍交付承诺，实现举措以及优先级。

● 是否有阶段性的组织项目Update，及时传递和更新变更，始终保持团队在目标上的同频。

● 是否在迭代计划会议（IPM-Iteration Planning Meeting）的时候向团队清楚的澄清本迭代的目标和优先级，以及原因，确保团队冲向同一终点。

● 是否在Retro的时候回顾本迭代目标和完成情况。

● 目标和进度是否有足够的可视化，让团队可以看得见找得见。

● 是否每个人都清楚自己的职责和任务，并知道与目标关联关系

“

孙子曰：上下同欲者胜。

”

“当一个人知道自己想要什么，整个世界都会为他让路”。团队也是一样。

如果团队成员没有共同认可的目标或对目标缺乏清晰的理解，就会影响到集体决策和协同行动，损及团队以及团队的业务成果。而团队Leader不懂目标的力量，可能累死自己还拖垮了团队。

因此，团队新Leader需要善用目标管理，清楚设置项目目标，并坚信这一目标富有的意义和价值，竭尽全力地始终保持团队在目标的共识，且团队中每个成员都知道自己做什么和怎样做可以共同完成任务。这也决定了在困难来临的时候团队是否有乘风破浪的勇气和动力，也是团队成为王者的前提条件。

在新建一个团队时候，前四个迭代是你做好目标建设的最好时机。

问题2：团队成员是否可以及时获取完成开发任务所需的信息？

在《技控革命(从培训管理到绩效改进)》一书中引用了托马斯.吉尔伯特绩效行为工程模型中，它指出环境因素占组织绩效的75%，在环境因素中信息因素占35%，包括：

● 是否被清晰、明确地告知做好工作的标准和期望

● 是否得到做好工作的各种信息，能及时、明确的获得工作的反馈

对于从事敏捷软件开发的知识工作者来说，及时获取完成任务所需的信息输入及实现共识-包括业务价值、技术方案、验收标准以及反馈-显得更为重要。因为这些决定了他/她将以什么样的方法、多少成本去交付什么样价值的可工作软件。

“

敏捷谚语：“再详尽的文档也无法替代个体和互动”

”

如果没有及时获取这些信息和共识，就会出现如下问题：

● IPM估算时每个人的理解不同，无法达成一致，最后仓促了事。

● 有时候开发了好长时间的用户故事，突然在沟通中发现根本不是客户想要的，只能重做。

● 用户故事没有DoD（Definition of Done）、技术方案、接口设计，经常做到中间才发现需要推倒重来。

● 代码写到快完成了，发现字段命名不符合规范，联调失败，不得不返工。

● 花费了四天终于把模型和复杂逻辑搞定了，突然发现其它同事已经做过了。

● 同一个bug经常反复出现，改了一个bug又可能引起了新的bug

● 每个人说法都不一样，而且有时候自己都忘了当时的决策是怎么回事。

……

那么，当我们进入迭代开发后，需要哪些信息和共识？以及在什么时候？

迭代过程也是团队对交付工件逐渐达成共识的过程。在迭代的窗口内需要确保需求和计划是明确的，以便团队可以快速的完成和持续验证。

迭代开始，PO与团队TL/PM/BA需要就交付范围的优先级达成一致，而开发团队则需要就本迭代开发的工作内容、DoD(完成标准）的要求、以及如何实现（接口设计、多系统处理的集成设计、组件结构、复杂流程处理和组件、逻辑数据库设计、测试策略、编码规范等）获得相同的理解，以便为本迭代的目标进行全力冲刺。

作为团队的Leader需要确保以上任务信息及时给到团队，以实现团队绩效的最大化。可喜的是，Scrum、XP、精益中的工程实践已经帮助我们定义了清晰的迭代结构和信息流，你需要的是合理的遵循和发挥它们在团队信息和共识的价值。

问题3：团队是否可以有序地开展价值交付活动？

疫情时代的到来，我们可以看到不确定性将会是最大的确定。对于交付团队而言，面对的挑战也不仅仅是需求的不确定，还有客户从成本效率向速度及快速适应变化的诉求。对于团队则意味着一切可能都会变，时间紧、压力大会成为常态。

接下来我们来谈谈在这样一个常态下，团队如何从忙乱到有序的这个问题。

1969年塔克曼先生在《小型团队的发展序列》文中指出，团队发展存在五个阶段：组建期（Forming）、激荡期（Storming）、规范期（Norming）、高效期（Performing）和休整期（Adjourning）。这五个阶段在团队的发展过程中都是必须且不可逾越的。

在今天这样的挑战下，留给团队从组建到高效的时间并不多。

一个优秀团队就体现在是否可以快速地从组建的忙乱进入到规范有序。时间越紧压力越大的项目，越需要有经验的Leader站出来，积极主动地通过应用敏捷精益的工程实践构建团队契约、流程机制、可视化价值看板、知识共享等来促成团队在不确定中从无序忙乱到规范有序，而这种适应性的能力和文化也会是未来团队致胜的关键。

1.为什么有序这么重要？

杂乱无序会导致效率低效、士气低下、重复-多头甚至错位管理。无序状态持续越久团队的情况越糟，疲惫不堪，结果也可想而知。而新手Leader容易出现的误区就是缺乏对敏捷精益工程实践的理解、缺乏系统思考、缺乏有效举措，往往导致越管越乱，看不到有效的价值收益。

团队无序的一系列特征可能包含：

● 每个人似乎都有做不完的事

● 任务总在不停的变，团队成员的安排也总在变，随意无逻辑，一切以进度为导向

● 进度迟缓出现救场明星或微管理，结果却越管越乱，系统的负反馈被加强

● 总是被动的响应变化，又马上为了响应被迫做出偏面的决策

● 成员不清楚什么样的事情由谁负责，应invovle谁，好像这算是他负责，也好像是她

● 成员不清楚决策的流程和沟通机制，看到问题也无力解决

● IPM还没有理解清楚业务和方案，也没有清楚的验收标准，赶紧开发吧

● 返工、开发中途的不同反复频繁出现

● 等不了后端了，这几张卡有些复杂我也一起做了

● Bug似乎越来越多

人也不少，感觉总是做不完，团队处在紧张加班的焦虑之中

●

● 反复共识，随随便便就做出决定然后又随随便便推翻，不知道找谁，等待，浪费

2. 如何理解有序？

“

有序指物质的系统结构或运动是确定的、有规则的。序是事物的结构形式，指事物或系统组成诸要素之间的相互联系。有序是动态的、变化的有序。当事物组成要素具有某种约束性、呈现某种规律时，称该事物或系统是有序的。人们通过认识客观世界，认识各种事物和对象的组成要素、相互联系、结构功能及它们的发展演变规律，即事物的有序性，来促成事物不断从无序向有序方向转化。

”

有序是动态变化的，随着新事物以及组成要素的变化，有序可能转向无序，也有可能促成有序向更高能力的有序变化。

那么，在敏捷团队价值交付的上下文中，有序意味着什么？

在我看来，在敏捷交付活动的有序代表了以下三个有秩序的活动闭环：

● 价值验证闭环，从想法提出到生产环境客户验收的价值流转是否有序。

● 围绕迭代的团队协作闭环，从迭代计划、迭代启动、Story开卡和关卡、Showcase和Retro这些活动中的任务分工和人员协作是否有序，遇到问题知道找谁，几时站会，几时code review，如何决策，以及代码的规范有序可依。

● 新人融入闭环（能力提升闭环），在新人被卷入快节奏交付前可以有明确步骤的融入和快速胜任上岗。

2.1 价值流闭环指？

我们需要明确，敏捷团队想要交付的是产品价值的最大化，而不是最多的功能点。团队希望可以将客户最初的想法随着需求到上线发布的快速流动转化为可工作的软件产品，从而给客户最初的想法提供反馈和价值验证的闭环——产品价值指所开发的产品或服务对最终用户的价值，它是用户选购或使用该产品的首要因素，也是企业盈利的本质。

团队可以根据所做产品和客户的诉求，组织和设计流程与任务，确定上下游的关系，并按时间顺序排列起来就形成了该产品的价值流图。

价值流图对团队有什么样的启示？

1）聚焦价值成果（Outcome）而非仅仅产出功能点（Output）的流动

构建一个顺畅、一致经各个步骤的价值流，使得我们能够持续地、有节奏地、没有非必要的延迟、并以最优的资源使用方式来交付成果，它的好处还包含：

● 让整个流程可视化，团队可以聚焦在被创造的价值上（outcome），而不是日复一日交付了多少个功能点（output)。

● 有利于从全局视角去分析问题，识别和消除瓶颈，从而避免局部优化的陷阱—指把时间和精力花费在根本没有效果甚至带来负面效果的管理行为上，尤其在忙乱的时候。

同时，基于此也可以促使团队建立如下的迭代交付物理看板墙，可以从全局上从迭代的角度对交付过程进行管理和优化：

● 进行价值优先级的排列Story和开发任务

● 显示化价值流的运转规则

● 管理负荷，控制在制品数量，降低浪费，促成小批量的交付和验证

● 管理拉式的流动，建立反馈和持续的推动价值闭环的改进

2）促使BA将隐性的业务价值知识从无序拆解到有序且足够小的用户故事，提升它被下游消费的效能传递和消费

我们必须要承认业务价值是隐性知识。不管是大到EDGE价值投资管理框架、还是小到用户故事Story的编写实践和可视化工具，它们都可以帮助我们与客户一起协同，从复杂的业务价值识别出最简可行产品（MVP），并将大块的价值需求进行拆分，从EPIC到用户故事地图，再到按迭代优先级排序的用户故事堆。其中，Story在进入迭代前需要足够小以支持团队持续批量的交付，这是实现快速价值流转的基础。

最近在一个项目走查时也发现了业务价值作为隐性知识传递的特点：它的传播成本是距离的衰减函数。

作为BA，在端到端的交付中，除了将业务价值从无序拆解到有序以Story方式输入给交付团队外，还承担了业务知识传递载体的关键职责。因此，需要积极组织有效地社会化学习活动，向交付团队传递隐性的业务知识，且传递的效果要以知识消费者的角度去检验。

这也是因为软件产品开发的好与坏依靠交付团队整体的认知水平。为了交付成功，团队在这方面花再多的时间也不为过。

2.2 围绕迭代的团队协作闭环？

团队最重要的特征在于成员之间存在分工和协作，良性分工和有效地协作创造协同效应，即1+1>2。在Thoughtworks，我们采用的是Scrum与极限编程XP的工程实践组合，一个典型的交付团队内有PM、BA、UX、TL、前后端开发、QA多个角色。

那么他们分别负责什么，在什么时候，什么样的任务如何协作？

以下以Scrum团队的三个角色Scrum Master、Product Owner、Scrum Team描述了团队的相关职责，在不同的项目通常还会根据具体的交付任务和团队情况设置对角色职责进行调整，比如增加面向产品的特性开发团队及Feature Owner、促进每日站会的主持、迭代的交付负责人IM等。

Scrum Master，通常会有PM或IM负责：

● 组织团队按敏捷过程规范高效运作，促进内外沟通协作；

● 管理进度、风险，协调解决敏捷运作过程中各种阻碍，推动持续改进。

Product Owner:

● 负责产品业务设计、需求提出、验收、运营分析和产品改进；

● 建立产品Backlog，排优先级；

● 与BA紧密沟通、澄清业务需求；

Scrum Team：

● 作为PO和开发团队的沟通桥梁，协助PO分析需求和确定优先级

● 编写和拆分用户故事(含验收条件AC)，维护产品Backlog；

● 交互体验设计和高保交互设计图，确保设计与实现一致和优化

● 给开发团队澄清需求，支持迭代开发

● 负责业务建模、技术架构方案设计，测试策略、梳理技术性故事，管理技术债务；

● 推进单元测试、代码评审、持续集成和自动化部署等工程实践能力提升

● 参与迭代计划，演示，回顾等关键活动；

● 应用和选取技术工程实践，负责故事开发、单元测试，自动化测试、代码评审等活动构建可工作的软件；

● 立即修复持续集成发现的问题；

● 参与迭代计划，评审，回顾等关键活动

● 编写用户故事测试案例（以GWT格式: Given、When、Then）；

● 负责迭代开发过程中的各个故事的测试，迭代增量的集成测试和回归测试；

● 自动化测试用例的编写和维护

● 搭建和维护适合团队的CI（Continuous Integration）系统，实现自动部署流水线；

除了敏捷团队角色分工，促进团队协作还需要建立Team Contract。团队规范制度是团队成员聚集在一起，为了达成共同目标追求而产生的，它是用语言、非语言的沟通 规则来影响团队成员行为。通常从团队的工作规范、DoD、团队纪律协作章程（Ground Rule）几个方面建立团队契约。

“

敏捷谚语：CI 红灯不过夜

”

协作纪律包括提交纪律、移卡纪律、集成规范、站会纪律、DC（Desk Check）时间、远程协作纪律等。

那么团队协作中会遇到哪些挑战呢？

如果把团队交付比喻为一场4*100的接力赛，那么团队胜出的关键就在于交接棒的技术。这也是我们发现协作有序最大的障碍在于上下游的接力棒交接不畅，出现信息的不对称和信息空隙。而这些是混乱、脱节、甚至造成团队犯错的根源，但常会有相当一部分人意识不到这是一个问题。

《赋能-打造应对不确定性的敏捷团队》作者在第七章中也指出信息空隙是无效组织的根源。要打造应对不确定性的敏捷团队，需要打破信息壁垒，连接上下游信息断点，建立共享意识和文化，获得更大的团队协同效应。

2.3 新人融入闭环（能力提升）

Onboard的流程是以终为始的拉动式学习，旨在帮助团队新人刻意练习来完成快速上岗。通常，TL 或者 Senior Dev 需要为团队新人的On Boarding 准备材料，其中主要包含业务背景介绍、架构设计、测试策略、用户故事和上岗的胜任要求。准备好相关材料后，安排一位Buddy 对新人进行 On Boarding和有结构的学习，完成第一个用户故事的编写，并通过上岗胜任练习后，即可融入团队开发节奏。

总结

有序的流程和团队协作是团队进入规范期重要标志。规模大、节奏快的交付团队，越要需要可以有序稳定的”部队作战“。小且目标行动一致，并且能够将业务价值、迭代协作、新人Onboard多个价值流闭环从无序到有序快速打通的团队，是在当下时间紧压力下应对不确定性的最好策略。越乱越忙反而越需要这样坚守正确的实践、原则和价值观才能致胜。其它的任何形式都只可能是一地鸡毛。

当下一个迭代开始的时候，你的团队应该已经可以做到规范且行动有序了。那么，恭喜你，开启团队发展的下一个阶段！

问题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分的尺子来衡量，你们团队是几分？

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

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

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

1. 认识TRUST-OWNERSHIP MODEL

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

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

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

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

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

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

● “我只完成领导安排的任务”

● “我是老板我知道该做什么”

● “严格规定团队做什么如何做”

● “替团队做重大决定”

● “对问题保持沉默”

● “出了问题就抱怨其他人”

● “成不了交付不了与我何干”

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

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

1.没有问过团队某件事情可否能做到之前，就要求承诺一个某日之前的Deadline

2.没有和团队讨论或考虑其它可行的办法之前，就要求团队承诺”按我说的做“

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

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

右下的冲突象限则是因为团队之间、团队与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，从原先独挡一面的团队贡献者到带领团队。往往对如何赢得团队信任和带领团队的工作上存在挑战，一方面既要快速的做出成绩证明自己的能力，另一方面又要能够敢于授权为团队负责。

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

1. 做人：尊重谦逊，坦诚开放，让团队更多的人了解你人非机器。信任的前提是尊重，每一位成员都是平等不同的个体，有着各自的优势和多样性。尽管不可言说，但尊重、信任、坦诚这些种种关系人们是可以通过你的言行举止感知到的。遇到重大关头的时候，就会如人饮水冷暖自知。只有且必须尊重每一位成员（话语权、信息权、所有权等），才能产生信任和 Ownership，成为Trusted Leader。其次，信任的构建要先与之，才能得之。加入团队伊始或者角色转变的时候，首先需要让团队更多的了解你，信任始于你迈出的第一步给团队留下的第一印象：

● 风趣的自我介绍

● 对项目情况的了解

● 倾听当前遇到的挑战

● 1:1成员沟通

再次，在于信息的透明和沟通到位，及时地让大家看到问题、进展及反馈，避免surprise；在涉及团队相关决策的时候，更需要和团队建立预先沟通和商量的渠道，邀请共创和共同改进，制定规则，激活Ownership。最后，坦诚和开放。我们每一个人都是有局限的，出错是很正常的，尤其是在刚开始去接受一个新挑战的时候。出错之后试图掩饰错误不懂装懂是最愚蠢的行为。也没有必要试图维护“我”的正确性，而是需要坦诚错误、承认局限、聚焦改进。因为作为Leader，确保“正确的事情和以正确的方法做事情”，比 “自己是不是正确”的更重要。

2. 成事：发现和带领团队解决棘手的问题带领一群知识工作者或者极客，一个很重要的赢得信任的条件在于成事。大家更容易因为你的能力和专业而佩服和跟随你。因此，作为Leader，带领一帮专业人士的时候更重要的是通过成事来获得团队的信任。你可以选择团队当前的棘手挑战入手，充分了解情况，过往的努力和障碍，然后从小的改进入手，分享你的行动计划，把问题解决展示承诺。

3. 促进：成为团队的催化剂，增进了解，培育文化，鼓励有效冲突，引导团队以正确的方式做事。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

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