解析精益產品開發：產品開發中的價值

本文是《解析精益產品開發》系列的第二篇。第一篇中我們介紹了看板方法，看板方法協助組織持續改進，實現順暢和持續的價值流動。但是，只有基於正確價值的流動才有意義，這是精益產品開發的前提。在本篇中，我們將揭示產品開發中的價值本質，並以此為基礎，分享一個適合精益產品開發的價值定義和發現實踐——影響地圖（Impact Mapping）。

1. 產品開發中價值的本質

傳統專案管理強調預先定義、分解和估計價值，以此為基礎計劃項目，然後按計劃執行就可以實現價值。這一理念應用在諸如生產或建築之類的工程項目上是有效，但應用在產品開發上時就有問題。以瀑布模式下的軟體開發為例，在項目前段，通常能夠按計划進行，但為了滿足進度要求，往往會讓風險後移；在項目後段，風險和不確定性逐漸顯現，項目出現困難和延期；更有甚者，如果交付的產品不符合客戶或市場的要求，再完美地符合計劃也是沒有價值的。為什麼在工程項目中有用的方法用在產品開發中就會出現問題？其原因是產品開發和工程項目中價值的本質是根本不同的。

1.1 資訊是產品開發的價值載體，它與不確定性如影隨形

工程項目（如生產或建築）的產出是物理產品，價值由物理產品承載；產品開發的產出是方案，價值由方案中的資訊承載。以“製作食品”和“製作食譜”來類比，產品開發相當於製作食譜，工程項目則相當於按食譜製作食品。製作兩份同樣的食品，得到兩份價值。而製作兩遍同樣的食譜，不會產生兩份價值，因為它沒有產出新的資訊，價值也無從談起。

不確定性與資訊及其承載的價值如影隨形。貝爾實驗的偉大科學家香農（Shannon）最早用位元（bit）來度量資訊，並奠定了資訊理論的基石。按資訊理論，資訊的量是對事件不確定性衡量，表達為information = 。一個bit包含了0和1兩種不確定性——，而1個byte包含256（0-255）種不確定性，其資訊量為8bits——。確定事件的資訊量為0 ——。產品開發不可能排除所有的不確定性還保留任何價值。正如管理學之父彼得•德魯克在其經典著作《管理的實踐》中所述：

在所有關於未來的概念中，一定會失敗的就是那些“十拿九穩”、“零風險”等“絕對不會失敗”的概念。

每一次產品開發都必須與過去有所不同，這意味著不確定性和風險，也為產品注入資訊，帶來潛在價值。Tom Demarco 在《與熊共舞》一書中把風險和不確定性比作熊，成功的產品開發是“與熊共舞”的藝術。第一代iPhone採用了全新操作介面——多點觸控、全新材料——大猩猩玻璃材質，和全新商業模式——電訊廠商（AT&T）深度綁定，這些嘗試帶來了技術、生產和商務上的不確定性， 同時也成就了產品與眾不同的體驗和非凡的價值。在技術、產品和市場快速變革的今天，挑戰不確定性和風險已經成為企業交付價值獲得競爭優勢的不二法門。

1.2 和商業目標相關的資訊才能帶來價值

資訊承載產品開發的價值，但只是潛在價值。只有通過達成商業目標，資訊才能成為真正的價值，組織也只應該在能協助達成商業目標的地方承擔不確定性。設想，蘋果如果在第一代iPhone中嘗試4G（LTE）通訊技術，會帶來更大的不確定性，然而即使成功了，也不能帶來價值，因為當時還沒有與之配套的商用LTE網路，事實上，第一代iPhone甚至沒有支援當時已經流行的3G通訊技術。

與商業目標無關的不確定性不帶來價值，而且可能是有害的。Google Wave剛推出時被Google和使用者寄予了厚望，產品紅極一時，但一年後卻因未能吸引到足夠使用者而宣布停止開發。Wave幾乎加入了能夠添加的所有功能，但使用者並不買賬，相反，過多的功能導致複雜的介面、模糊的定位和穩定性的缺乏，讓使用者遠離Wave。

產品開發的目的是實現商業目標，而非完成功能。產品的功能應該圍繞有限和明確的商業目標展開，否則一方面會引發範圍蔓延，造成項目執行和產品維護的困局；另一方面卻無法實現核心目標。Wave引入過多的功能而犧牲了易用性和穩定性，但使用者還是普遍的抱怨，它不能滿足自己的應用要求，它什麼都能做，但作為協作工具它比不上Google Doc或Zoho，作為社交工具它比不上Facebook或Google Buzz，作為通訊工具它比不上Gmail或已有的IM工具。

Scott Berkun曾經成功領導微軟數個重大項目，包括奠定瀏覽器大戰勝局的Internet Explorer 4.0，在其暢銷書《專案管理之美》中他分享了一個曾經使用的需求管理實踐——應用簡單機制跟蹤從目標到功能再到產品項的映射關係。在這一機制下，每個工作項目必須對應一個功能，每個功能必須對應一個目標，並且每個版本僅聚焦於有限數量的目標。依據這一映射，團隊可以明確判定一個新的工作項目能否進入專案範圍。這既有效抑制了範圍蔓延，又確保了核心目標的達成。

1.3 價值要在開發過程中持續發現

產品開發是一個資訊積累和知識建立的過程，團隊持續擷取業務需求、市場環境、實現技術等方面的資訊，深化認知、明確價值。近年來，業界在如何讓這一過程更加有效方面的實踐取得了很大進展。

1.3.1 先期決策是傳統專案管理的一般實務

傳統專案管理強調預先計劃和按計劃執行。如圖 ㈠所示，團隊擁有最豐富資訊和知識的時刻是在項目的末期，這也是最可能做出正確決策的時刻。然而與之對應的是，絕大部分的決策在項目的早期做出，如設定產品需求、承諾專案計劃和確定技術方案等。此時的決策只能依據有限的資訊和知識做出，卻成為後期項目執行的基準。過早的決策成為後來的約束，也降低了應對變化的靈活性。

圖㈠ 先期決策