使用試驗和數據創新并構建客戶真正使用的產品

Bosch：盡管許多企業花費了很多時間專注戰略，并多次嘗試對行業“預測未來”，但事實上行業中許多現有企業都錯過了發展。無疑，特別在歐洲許多人將諾基亞作為錯失良機，被新進入者淘汰的典型例子。諾基亞通常被視為例外和異常值。然而，對財富500強名單研究顯示 2000年52%入榜企業如今都從名單上消失了 。所有的企業都有戰略和長期預測，但是仍未能錯過市場的潮汐變化。通過對多家企業的研究，和我在行業生涯中的主動經歷，我意識到企業的關鍵區別在于減少識別客戶需求和在市場上擁有可用的能夠解決該需求的解決方案之間的時間。應對快速變化的客戶需求的敏捷和響應能力需要“速度需求”。

Bosch：基于我們的研究，我們開發了一個模型，叫做“通往天堂的階梯”（參見 Continuous Software Engineering 一書）。這個模型基于較長一段時間內跟數十家企業的合作和跟蹤隨著時間推移開發實踐在這些企業的演進。在模型中，組織從傳統典型的瀑布式或者迭代開發方法開始。下一步，企業在 R&D團隊中采用敏捷開發實踐，但是其它組織保持不變。敏捷團隊通常會表達缺乏對所寫軟件驗證能力的不滿，并走向第三階段：持續集成。一旦持續集成成功，企業總會有一個該軟件的生產質量版本，然后企業會進展到下一步驟，持續部署步驟。在這個階段，因為新軟件的頻繁部署不允許 R&D和運營組織之間傳統、緩慢的交接，所以DevOps成為重要的組織原則。這就要求同一團隊負責開發和運營職責。

然而，很少有人意識到持續部署是達到目的的手段，其本身并不是目標。真實目標是它允許企業接近不同的開發模型：持續部署能夠實現A/B和分割測試的使用，也能夠實現其他定量測試方法，向客戶展示新功能的相關性。這允許企業與客戶采用通過假設驅動試驗驅動的開發模型，而不是傳統需求驅動的開發方法。其如此重要的原因是因為我們和其他研究表明典型軟件系統中超過一半的特性從來未被使用過。這些特性可以認為是浪費，一開始就不應該開發。我們需要一個開發模型在構建這些特性時完整的開發工作被提交前清除這些特性。我們已經開發了一些模型且適用這一開發階段，比如“R&D作為創新試驗系統”。

Bosch：在邁向 R&D作為創新試驗系統這一階段的過程中，與之相關聯的重點區域是產品管理與產品開發之間的關系。傳統上來講，產品管理側重于構建什么，產品開發側重于如何構建。這種分割能夠滿足可預測和變化緩慢市場中的組織。但不幸的是，越來越少的市場能夠滿足這一要求。此外，使用這一傳統模型的企業其運行模式是：只有客戶明確要求新特性或者產品的時候，新特性和產品才能得到充分的優先級。有時這會在客戶需求出現和客戶能夠口頭表述需求之間出現嚴重的時間滯后。客戶需求出現跟客戶能夠表達出需求之間的時間就是市場新進入者擾亂現有企業的最佳時機。

所以我們不能坐等客戶上門要特性或者產品，我們不能在“如果我們構建此特性或者產品，他們就會使用”的假設下構建特性或者產品。那么我們如何發現最有價值的特性或者產品提供給客戶？答案是要么與客戶基于領域中已經部署的產品這一背景不斷地試驗，要么通過其它試驗方法不斷試驗。組織方法是將產品管理和產品開發聚集到同一個團隊。雖然這是基本敏捷方法的規范，但是許多企業中產品負責人是一名技術人員，例如架構師或者高級工程師，而不是真正面對客戶的人員。每個敏捷開發團隊（滿足亞馬遜2-pizza規則）同樣包含肩負產品經理角色的人。同時，團隊提出假設與客戶一起測試，然后開發和執行這些試驗。這可能會導致特性從產品中撤回，因為客戶反饋不溫不火。或者，基于客戶使用產品的數據，與產品管理的需求規范相比，可能特性僅僅需要部分實現，但是特性已經充分開發了。此外，可能導致特性的實現與團隊原假設非常不同，因為客戶反饋顯示需要這一特性。最后，當然一些特性的實現可能完全按照說明，因為團隊正確預測了客戶最迫切的需求。

這種工作方式的重點在于（1）產品管理和開發參與團隊，（2）產品管理和開發都要擁抱此工作方式帶來的不確定性并且（3）建立一種數據勝過意見的文化。

Bosch：在 Web 2.0/SaaS領域，這是規范，并且數家企業在 SaaS領域花費了更多的精力重新實現已經開發了的特性，從而弄清楚替代實現方案能不能帶來更好的商業成果。例如，對于電子商務網站，就是客戶進入網站完成事務的匯率。一些我共事的企業如今開始在實現階段和實現后更加嚴格地評估特性，從而決定該特性是否應該保留在產品中還是應該去除。此外，在嵌入式系統領域，有很多企業在特性已經開發后去除特性的案例，因為其增加的復雜性超過了特性提供的價值。不幸的是，由于保密約束，我不能分享這些特性細節。

Bosch：正如我之前提到的，在典型軟件系統中有一半到三分之二的特性從未或很少被使用。試想一下，我們可以騰出 R&D資源的50%，因為我們只構建客戶真正、真正想要的功能，這些功能會為客戶產品增加價值。再想一下，這50%的 R&D資源可以分配給現有產品新特性和全新產品的創新和試驗。這對任何組織競爭地位的影響將是驚人的。這給采用這種方法的企業帶來的關鍵好處是：在投資回報率方面，極大地提升了R&D投資的精度。在軟件中心（ www.software-center.se ），我們積極地與伙伴公司合作研究這一機會，包括愛立信，沃爾沃，Saab，杰普遜（波音）和眾多其他的公司。例如，在一些研究中，我們確實與哥德堡的一家企業合作，我們度量“服務啟動”的頻率，即特性使用的次數。如下圖所示，只有很少的特性使用非常頻繁。許多特性從未或者很少使用，并可能被認為是浪費。

Bosch：有很多實踐組織可以采用并從中獲益，但是這里我將重點介紹三種實踐。首先，組織面向客戶的交流被顯著拓展。傳統上來講，R&D人員從來不會面對客戶，除非在客戶現場出現意想不到的問題。如果 R&D團隊被認為應該對有價值的、新客戶功能提出有見地的假設，那么他們需要理解客戶的實際情況和產品的部署。這需要 R&D人員在客戶和客戶現場花費時間。不僅僅是一些人，而是每個人每年至少要在客戶身上花費一些時間。這似乎是一個昂貴的運動，但增進理解和客戶同理心的價值遠遠超過其成本。例如，我以前的一個雇主，要求企業所有員工每年至少在客戶那花費一天時間，在他或者她的工作日跟蹤客戶。

其次，企業需要適應數據驅動的工作方式。這需要測量現有的和新的產品，以便確定特性使用情況。我們的研究表明所有我們合作的企業收集了大量的數據，但是這些數據主要用于故障排除。R&D不具備訪問權，即使 R&D具備，團隊也沒有使用可用的數據。用 Edwards Deming話說，我們需要“我們信仰上帝；其他所有人請用數據說話”的文化。

第三，大多數組織工作在功能筒倉（functional silo）的環境下，跨筒倉的協作是緩慢、令人沮喪和充滿失敗的。對于渴望敏捷和數據驅動的企業而言，產品管理和開發有效地一起工作是不夠的。整個組織，從銷售和市場到發布和交付團隊都需要有效地一起工作。這需要擺脫傳統的官僚組織機構，轉向授權、自我管理的團隊，并提供前所未有的自治。在管理文獻中，有一連串新奇的出版物在探索個體自我管理和自我導向的組織，和沒有層級、老板、強制性內部決策過程情況下組織的運營。相反，這些組織已經發現了新的機制，用于協調組織內的工作，并且被大眾視為結構化組織的下一階段。一個眾所周知的例子是 Valve，一家負責 Dota，Portal和Half-Life的游戲公司，一路心甘情愿地建立自我管理。

Bosch：有三件事我想解釋清楚。

首先，創新需要個體有時間專注創新。因此，100%甚至更多地分配你的員工，然后告訴他們去創新僅僅是一種假象。一些硅谷公司已經制度化了員工可以自由支配自己10-20%的時間。如果你想利用組織內每個人的創新能量，你需要給他們這樣做的空間。

其次，許多創新思想都扼殺于內部反饋和典型的高層領導驅動的選擇過程。原則應該是創新思想只有在擁有足夠大的客戶反饋樣本表明缺乏該思想的支持的情況下才應該放棄。測試棒應該是客戶，而不是組織內 HIPPOs（薪水最高人的意見）的意見。

最后，建立一種文化：嘗試創新思想并接受不符合最初假設的可能性。我不喜歡關注失敗，有人覺得領導喜歡，但是因為嘗試沒有成功的事情而在組織內懲罰員工是扼殺創新文化最快速的方法。當然，我們喜歡能夠給企業帶來重大好處的創新，但是得到這一成果的唯一方法是嘗試更多的想法和創新，并基于客戶的反饋選擇其中的想法和創新。