為什麼企業敏捷團隊會失敗

翻譯君：敏傑小王子

上週，我站在一家市值 200 億美元的公司的會議室裡，推動了乙個關於敏捷的研討會。出席會議的小組由這家大公司的乙個產品線中的每個職能部門的董事和部門經理組成。從 ux、工程和產品管理的崗位中挑選出來的十幾位領導者組成了一支團隊，他們代表著約 150 人的產品線。作為乙個團隊，他們踏上了「敏捷」的旅程。

這不是我們平時認為的企業轉型。他們的高層既沒有明確支援也沒有明確阻撓這次轉型，這家公司對敏捷的官方態度最準確的描述是「良性冷漠」。因此，這個團隊基本上只能靠自己來嘗試，無論最終結果是成功還是失敗。

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

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

一些高階管理人員在權利更迭期間，以臨別頓悟為基礎傳達了自己的「突發奇想」。這個「想法」被投入了預算計畫角逐會議中，這位特別的高管最終贏得了影響力戰，並得到了 12 個月的專案資助。緊接著這一訊息的所有內容通過乙個既成事實的 ppt 傳遞給你，功能和時間表提前計畫好了，你被正式告知「請實現它」。現在你正試圖完成那個不可能完成的任務，並希望敏捷能幫到你。

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

ps：如果他們找你麻煩，給我打個**。

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

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

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

譯者注：直線經理（line manager）是指諸如財務、生產、銷售等職能部門經理，每乙個直線經理肩負著完成部門目標和對部門進行管理的職責。

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

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

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

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

產品開發是一項團隊活動，團隊成員之間需要極大的關注和大量的溝通和協調。您團隊中的每個人在部分時間內被分配到其他專案，這會使交付日期常常延遲數週或數月。

讓我們思考一下：

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

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

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

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

解決方案：請組織小型、跨職能、專注的團隊，將一小組作為乙個單元一起工作，並不斷獲得雙方關於事務進展的反饋與澄清。

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

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

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

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

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

這是因為，儘管敏捷社群重複了 15 年：

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

（2）測試驅動開發

（3）對**的持續整合

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

解決方案：考慮採用「極限程式設計」，使用敏捷的技術實踐。此外還要考慮使用敏捷構建的現代技術工具和語言。

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

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

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

大多數企業所處的遺留系統的問題是部署時間過長。企業通常由乙個運維團隊負責將**引導到生產環境。這些人員經過培訓，需要確保**被批准在公司伺服器上執行之前是安全，高效和可用的。

當你迫不及待讓凡人工程師將他們自己的**手動部署到生產中時，像亞馬遜這樣的公司已經迅速搶占你的市場份額。您可能依然在權衡開放生產環境訪問許可權的風險以及在市場中滅絕的風險，這是因為您對競爭威脅的反應太慢。

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

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

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

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

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

為什麼港灣會失敗？

一 借助國外公司的強勢品牌開拓國際市場的努力還沒有得到實質回報 從2004年三季度開始，由於各種原因，港灣在國內市場迅速下滑，公司高層經過分析，認為國內主要友商由於在國內市場耕耘時間較長，對國內客戶的影響力較 大，港灣在國內翻盤的可能性很少。但國內友商在海外的耕耘時間較短，對海外客戶的影響力暫時還比...

敏捷開發為什麼會流行

許多人好奇，誰真的會從敏捷開發中受益，以及怎樣才能受益。我將從以下5個重要的方面帶領你應用敏捷開發的原則和價值，以及分析 從長遠來看 參與的人將怎樣受益。利益相關者 敏捷開發保證了專案中所有利益相關者的利益，不論是客戶 專案管理 開發團隊或測試小組。每個人對專案都有清晰的可見性，這是成功的關鍵點所在...

為什麼大型專案會失敗？

為什麼大型專案會失敗？這個問題困擾了許多軟體開發者和軟體公司很多年。首先何為大型專案，有一種觀點就是超過了10000行有效 的就可以稱作為專案，而超過100000行 的專案就可以稱作大型專案了。另一種觀點是認為，超過500個人月的專案就可以認為大型專案了。更有甚者，大型專案基本上不用人月來計算，直接...