在結束“創建自適應組織”這個話題之前，我想要再說一個故事。如果你經營自己的生意，你可能使用過這個故事中提及的產品。它叫QuickBooks（意為“快速賬簿”），是財捷公司的旗艦產品之一。
多年來，小型商務財務軟件QuickBooks一直是其所在類別中的領頭產品。所以產品擁有一大群忠實的顧客，而財捷也希望它對公司利潤產生重大貢獻。Quickbooks和二十幾年前的大多數個人電腦軟件一樣，以一個巨大批量的形式每年發布一次。三年前，QuickBooks的產品營銷總監格裏格?萊特（GregWright）加入團隊時就是這種情況。正如你所想到的，已有很多流程，保障產品不斷地準時發布。典型的發布方式是花費大量前期時間，找出顧客需求：
一般，每個年度周期的前三四個月裏不開發任何功能特性，隻用於製訂策略和計劃。當計劃和階段性目標確立之後，開發團隊在接下去的6~9個月裏動手開發。最終推出一次大規模的產品發布。在流程的最後，團隊會收到第一次反饋，了解他們是否成功實現了顧客的要求。
所以整個時間表是這樣的：9月項目啟動，6月發布第一個公測版，7月發布第二個公測版。公測版的主要目的是確保新軟件不會讓顧客的電腦係統崩潰，或丟失數據。到了流程中的這個時刻，隻能修複一些重大的漏洞。軟件產品本身的設計已經定型。
這是軟件開發團隊多年來使用的標準“瀑布模型”開發方法。它是一種線性的、大批量係統，它的成功仰賴恰如其分的預測和計劃。換言之，它完全不適應現今快速改變的商業環境。
第一年：完成失敗
2009年是格裏格加入QuickBooks團隊的第一個年頭，他親眼目睹了一場失敗。那一年，QuickBooks把網上銀行作為重要功能之一，推出了一個全新的係統。開發團隊采用了軟件模型和非功能性的原型產品，完成了數輪可用性測試，接著用顧客數據樣本進行了主要的公測版測試。在產品發布的那一刻，事事如常。
第一個公測版在6月發布，團隊開始得到一些負麵的顧客反饋。盡管顧客在抱怨，但並沒有充足理由停止發布，因為軟件本身沒有技術錯誤，沒有令電腦崩潰。在那個當下，格裏格進退兩難，他無從知道在市場中這些反饋會如何反映到真正的顧客行為上。這些隻是孤立的投訴個案，還是廣泛問題的一角？但有一點他很清楚：他的團隊不能錯過產品發布時間。
終於產品推出了，但結果很糟糕。顧客要花比老版本多四五倍的時間核對他們的銀行交易。最終，格裏格和他的團隊除了根據規格開發了產品之外，沒能實現他們本想要解決的顧客需求。同時，因為下一次發布必須要通過同樣的“瀑布模型”流程，開發團隊用了9個月時間來解決問題。這是一個由於成功執行了錯誤計劃，而“實現”失敗的典型案例。2
財捷公司使用一種名為“客戶淨推介值”（NPS）的跟蹤調查體係，評估顧客對公司旗下眾多產品的滿意度。這是一個能了解顧客對產品真實想法的極好指標，而且具有可操作性。我在IMVU也使用過這個方法。NPS的一個好處是，它在一段時間內是非常穩定的。它測量的是核心顧客的滿意度，所以不受小波動的影響；它隻記錄顧客感受的主要變化。那一年，公司的NPS分數第一次發生改變，QuickBooks的得分跌了20個點。下降的20點導致財捷的業績遭受重大損失，也讓公司很丟臉。這都是因為在流程中，顧客反饋來得太晚，以致開發團隊沒有時間重新來過。
財捷公司的高級管理層，包括小型企業部的總經理和小型企業會計部的主管，都認識到需要作出改變。他們明智地決定，任命格裏格負責這次改革，他的任務是：在QuickBooks的開發和部署上，達到新創企業的速度。
第二年：肌肉記憶
這個故事的第二階段展示了建立自適應組織的困難度。格裏格打算用以下四條原則來改變QuickBooks的開發流程：