為什麼企業靈活團隊會失敗

企業靈活轉型避坑指南

原文位址：

https://medium.com/startup-patterns/why-enterprise-agile-teams-fail-4ae64f7852d6

翻譯君：敏傑小王子

上周，我站在一家市值 200 億美元的公司的會議室裡，推動了一個關于靈活的研讨會。出席會議的小組由這家大公司的一個産品線中的每個職能部門的董事和部門經理組成。從 UX、工程和産品管理的崗位中挑選出來的十幾位上司者組成了一支團隊，他們代表着約 150 人的産品線。作為一個團隊，他們踏上了“靈活”的旅程。

這不是我們平時認為的企業轉型。他們的高層既沒有明确支援也沒有明确阻撓這次轉型，這家公司對靈活的官方态度最準确的描述是“良性冷漠”。是以，這個團隊基本上隻能靠自己來嘗試，無論最終結果是成功還是失敗。

我在那裡的唯一原因，是因為到目前為止靈活旅程還不順利，我的任務是幫助他們找出症結并解決它。好巧不巧，他們出現的問題與我在過去 5 年中遇到其他團隊的原因相同。為簡單起見，以下都是直言不諱的事實陳述，但也并非都适用于您的情況。

不明确的願景

如果你在辦公室走廊攔住任何團隊成員，問他：“同學，我們産品的長期願景是什麼？”他們能否用一兩句話來回答？八成不行。他們可能對目标客戶有所了解，也可以明确地知道解決方案的功能。但是，他們真的可以說出客戶想要解決的痛點嗎？我猜不會。

一些進階管理人員在權利更疊期間，以臨别頓悟為基礎傳達了自己的“突發奇想”。這個“想法”被投入了預算計劃角逐會議中，這位特别的高管最終赢得了影響力戰，并得到了 12 個月的項目資助。緊接着這一消息的所有内容通過一個既成事實的 PPT 傳遞給你，功能和時間表提前計劃好了，你被正式告知“請實作它”。現在你正試圖完成那個不可能完成的任務，并希望靈活能幫到你。

解決方案：花一些時間闡明産品的清晰願景，使用業務模型或精簡圖檔表達您的設想，邀請團隊中的每個人參與，将這些設想回報給高層管理人員（如果他們拒絕參加），并確定你的相關資訊出現在同一頁面上。

PS：如果他們找你麻煩，給我打個電話。

被混淆的業務名額

該團隊不會考慮日常的成本和收入。事實上，團隊可能不知道公司要讓他們賺多少錢，他們也不知道他們需要拓展多少客戶，每個時間段需要支付多少錢，以便他們在這個瘋狂的想法上實作收支平衡。他們基本上不太關心自己的工資來自何處。

但如果你問大多數初創公司，他們對自己整體燃燒率和銷售業績會有更好的了解，因為收入和盈利能力對于他們來說始終是最重要的。

其實這個成本在任何情況下都不難計算。直線經理（Line Manager）通常可以在幾分鐘内得出工程團隊燃燒率的準确數字。然後當我們将這個數字（實際成本）與我們目前的銷售資料（我們作為一個團隊實際産生的收入）進行比較時，這就會是一個全新的業務競賽。

譯者注：直線經理（Line Manager）是指諸如财務、生産、銷售等職能部門經理，每一個直線經理肩負着完成部門目标和對部門進行管理的職責。

解決方案：計算您的産品成功所需的團隊收入和成本，并確定每個人都知曉。它很有可能會讓人大開眼界。您應該在下一次業務規劃會議上與您的團隊一起嘗試。

持續不斷的幹涉

由于方向上的某些緊急變化，您最後一次中斷正常工作流是什麼時候？它可以是最近的客戶投訴或請求，也可以是來自首席執行官措辭強烈的電子郵件——郵件涉及團隊在上周産品示範中使用的配色方案。

無論如何，如果你總是打破團隊的正常工作流，會給團隊帶來巨大的壓力。這種壓力轉化為吞吐量降低、士氣低落、人員流動率增加、航運延誤、工藝粗劣、以及對團隊績效的普遍拖累。是以把這個壞習慣丢棄掉吧，您并沒有因為在組織中的管理地位而擁有在事務優先級排序方案中的特權。

解決方案：每周為計劃外工作配置設定一些容量，比如總容量的 20％，隻安排 80％ 的團隊時間，而不計劃其餘的時間。可以在發生“緊急情況”時使用此容量，而不會影響原來的正常計劃。無人認領的話可以用它來償還技術債務。您可以輪換團隊成員來執行此操作。

不夠專注的團隊

我工作過的每個大公司都有這個問題。項目中的大多數人被配置設定到多個其他項目當中。當我問團隊中都有誰時，我得到的答案一般是某位工程師配置設定了 50％ 在這個項目上，而某位工程師與我們在一起的時間占 20％，超過一半的項目人員将一半以上的時間花在其他項目上。難怪項目的最終結果往往是事故，因為這種工作方式不管用。

産品開發是一項團隊活動，團隊成員之間需要極大的關注和大量的溝通和協調。您團隊中的每個人在部分時間内被配置設定到其他項目，這會使傳遞日期常常延遲數周或數月。

關于這一點我從企業管理者那裡得到了更多的案例，舉一個具體的例子，你也許會問：“我們真的需要在團隊中設定專門的産品體驗人員嗎？如果他們一半閑着怎麼辦？我們不是在浪費錢嗎？”

讓我們思考一下：

假設你有十個工程師和一個互動設計師（本來不應該是這個 1/10 的比例，但你可能會這樣做，是以我們姑且先這麼選着）。設計師為工程師建構了 100 個線框，現在你有 10 名工程師開始工作，設計師又回到了其他項目。

工程師幾乎立即向設計師提出了要求，但設計師此時被其他項目束縛，是以工程師必須等待（延遲）。也許工程師選擇打開另一項任務并開始工作。當設計師重新上線時，工程師必須暫時放下第二個任務以重新打開第一個任務（延遲）。

現在，第二位工程師需要幫助，可能還有第三個工程師，他們都在等待（延遲）。設計師再次有空并開始與第一位工程師合作，而其他兩位排隊等候（延遲），後兩者的任務未完成（延遲）。所有三位工程師都失去了他們正在研究的一些事情的背景（延遲）。

在與第一位工程師合作時，設計師發現了設計中的錯誤，需要更新所有 100 個線框（大延遲）。現在，每個工程師都必須停止并重新檢查他們的工作以應對新設計（大延遲），已經完成的一些工作必須廢棄并重新開始（更大的延遲）。

是以你是選擇固執己見還是有所改變？您可以試試把上面的示例中替換成後端 API 開發人員，事情的結果會變得更糟。

解決方案：請組織小型、跨職能、專注的團隊，将一小組作為一個單元一起工作，并不斷獲得雙方關于事務進展的回報與澄清。

分散各地的團隊

大型企業團隊往往由一個地理位置分散的大型池的“資源”組成（原諒我用“資源”這個詞）。是以，企業産品團隊的成員處于不同的時區和地區，這使得溝通協調效率低下且成本昂貴，結果就會發生很多延遲等待和錯誤傳達。遠端通信的保真度絕對不如面對面溝通，視訊通話确實讓溝通變得更容易一些，但它與能夠一起走到白闆前讨論出來的東西并不相同。

解決方案：将所有團隊成員放在同一個房間，或至少在同一建築物的同一樓層。如果您必須與遠端人員一起工作，請根據康威定律分解任務，按地理劃分（具有明确定義的接口的子產品）而不是按功能劃分（設計、工程）。

太過臃腫的團隊

通常情況下，在企業中找到大型團隊來建構産品不是那麼複雜的事情。但由于各種原因，團隊規模常常大得驚人，這主要與高管傾向于通過指揮大群人來建立自我的事實有關。

100 名工程師建構一個 SaaS 産品？你确定？較大的團隊效率更慢，因為協調成本是巨大的。您需要更多層次的管理，更多會議和更多文檔。大型團隊對其速度的負面影響随着其增長而漸漸變得更強烈。

解決方案：您應該使用盡可能小的團隊在企業中建構産品。如果你可以把它減少到幾十個，甚至一打，那就更好。

太重的技術債務

企業往往有很多舊的代碼庫。然而這并不是企業靈活團隊積累技術債務的真正原因。我敢打賭，您目前項目中的大部分技術債務是從您目前項目開始以來由您的團隊建立的，而不是通過來自較舊的遺留系統的繼承。

這是因為，盡管靈活社群重複了 15 年：

（1）結對程式設計技術實踐的重要性

（2）測試驅動開發

（3）對代碼的持續內建

但非常少的企業團隊真正去做這些事情。出于各種原因（主要是因為那些專注于流程而非卓越技術的大型咨詢公司向高管出售的所謂“靈活”），企業靈活團隊很少接受：核心技術實踐使得靈活出色。結果大型的工程團隊開始設計和執行有缺陷的系統，然後在漫長而痛苦的釋出周期中互相折磨。

解決方案：考慮采用“極限程式設計”，使用靈活的技術實踐。此外還要考慮使用靈活建構的現代技術工具和語言。

太多的并發事務

擁有專門團隊的關鍵是一次隻做一部分事情并且把它做得非常好。大多數企業團隊可能因為他們的人員太多而傾向于同時處理數十種特性。

将疊代限制為幾個關鍵功能會好很多。在看闆語言中，我們稱之為“在制品”（WIP）限制。實際上您可以通過強制許多人在相同的項目上一起工作來建立更加協作的環境。由于 WIP 限制，不允許任何人在未完成目前事務前開始新事務。它可以使事務一次做得越來越少，越來越好。減少返工和減少錯誤，會帶來更多團隊合作、更高的品質和更高的士氣。

方案：立即實施 WIP 限制。如果您有一個 10 人團隊，請将 WIP 限制設定為 5 個項目，以便每個人都被迫與其他人結對工作。相信我，效果會讓你感到驚訝。

更長的部署軟體時間

大多數企業所處的遺留系統的問題是部署時間過長。企業通常由一個運維團隊負責将代碼引導到生産環境。這些人員經過教育訓練，需要確定代碼被準許在公司伺服器上運作之前是安全，高效和可用的。

當你迫不及待讓凡人工程師将他們自己的代碼手動部署到生産中時，像亞馬遜這樣的公司已經迅速搶占你的市場佔有率。您可能依然在權衡開放生産環境通路權限的風險以及在市場中滅絕的風險，這是因為您對競争威脅的反應太慢。

解決方案：DevOps。任何工程師都應該能夠随時啟動新的開發和測試基礎架構。軟體推送到生産環境應該通過一個自動化過程，并具備所有必要的測試和标準。

被忽視的企業其他成員

最後，在您的靈活“實驗”中，對您和團隊來說非常重要的成員，那些不需要完成任何關鍵特性但是你不得不合作的團隊：采購、法律、營銷、人力資源等這些崗位人員。如果您必須及時與組織中這些非靈活團隊進行協調，那麼您會很容易心累。需要有一種方式與團隊外的團隊合作，這種方式不會完全搞砸你的努力。

我們在靈活社群中注意到，由高層管理者提供自上而下的指令，靈活轉型往往并不會真正起作用。除非被雇傭的執行層人員對轉型十分興奮，否則靈活轉型這事就不會被堅持下去。沒有執行支援，也不會自下而上。

解決方案：基本上您有三種政策可以處理轉型問題，需要同時完成所有操作：

• 在您的組織内進行持續影響力的活動，以赢得關鍵的高層支援者。我保證您的企業中還有其他高管和經理也在嘗試或考慮在某個範圍或規模上嘗試靈活，去尋找他們并結成聯盟。畢竟，在大型人類社會中變化是如何發生的，在大公司也不例外。
• 找出你需要從非靈活特性團隊得到的東西，并確定提前與這些團隊交談。告訴他們你正在做什麼，事情是如何運作的，最重要的是如何讓他們更容易地與你一起工作。
• 無情地削減你的依賴。這部分或多或少在你的控制之下。推動使用工具、基礎設施、營銷材料、法律語言等，您和您的團隊可以自己建構、借閱或購買。要做到這一點需要時間，是以你應該馬上開始行動。

靈活，做得對的話，效果驚人

嘗試靈活并不瘋狂，事實上，我認為這是讓你的公司進入下一代所需的競争鬥羅場的唯一途徑。另一種選擇是緩慢地或快速地倒在更小、更靈活的競争對手石榴裙下。