文章來自：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

團隊管理是一門科學也是一門藝術，而真誠是最好的套路。五個問題幫你把脈，從青銅到王者你學會了嗎？