接著《??你的團隊是王者還是青銅（上）??》繼續聊。

問題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，從原先獨擋一面的團隊貢獻者到帶領團隊。往往對如何贏得團隊信任和帶領團隊的工作上存在挑戰，一方面既要快速的做出成績證明自己的能力，另一方面又要能夠敢于授權為團隊負責。

在這里我給出以下幾點建議：

(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

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