Gil Zilberfeld在2015東歐敏捷大會上做了新敏捷的演講。InfoQ采訪了Gil Zilberfeld，談到了產品規劃與跟蹤的更好方式，他的觀點#沒有估算，包括在產品規劃中價值的討論，以及如何提高產品開發的決策。

\\

InfoQ：組織正在尋求產品規劃及跟蹤的更好方式。您能說一下嗎？

\\\

Zilberfeld:直到最近，組織都是在開發團隊層面開始他們的敏捷之旅。Scrum、看板以及其他方式給與了我們規劃和跟蹤的方法。Scrum有現成的規劃過程，包括發布、迭代以及每日工作。燃盡圖和任務版可視化了狀態以及查看分析是否到位，從而可提供良好的全局。例如，我與一個團隊合作，他們持續地在一個迭代中交付60%的產品代辦事項。幸運的是，我們只需要查看一下燃盡圖，看到團隊用穩定的速率工作，而他們花費太多的時間計劃沒有進入到迭代中的內容。

\\

看板提供了一個看板板，但這看似簡單。如果我們應用看板原則“政策明確（Make Policies Explicit）”，我們可以追蹤工作流程如何以及在哪里卡住了。如果我們創建累計流圖（Cumulative Flow Diagram （CFD）），我們可以根據前置時間（Lead Time）和在線制品數量（WIP）提前規劃。在這兩種情況下，我們到底基于哪一個做規劃，目前正在收集信息。這個好處就是在過程中有一些可預測性。如果我們應用精益原則，約束理論和排隊理論可以通過可視化、識別瓶頸以及改進流程成倍地增加可預測性。

\\

搞清楚這部分的組織現在想要在組合管理上應用同樣的原則。SAFe（一種規模化敏捷框架）為此提供了發布火車（Release Train），規模化看板是從開發團隊到整個產品團隊。這僅在最近幾年才剛剛開始，因此比較明智的是慎重地把成功與失敗的報告結果作為依據。參與的人越多，流程越復雜，并且可預測性開始遇挫。再次地，過程的可見性會帶來較好的可預測性以及改進的能力。

\\\

InfoQ：對于#沒有估算，您有什么想法？

\\\

Zilberfeld：當我第一次聽說#沒有估算的時候，聽起來像開發人員想要從項目發起人那里爭取得到更多的控制。我的意思是，難道為項目買單的人不允許在整個項目中得到一部分控制權嗎？

\\

當我變得越來越感興趣的時候，我問估算到底是做什么的。也許你對此答案并不驚訝：我們尋求可預測性！發起人想要估算，因為他們相信他們會幫助制定項目的最佳決策。哎，但并不總是這樣。除了一些功能障礙，例如估算神奇地變成了承諾，或者估算通脹，我們并沒有得到我們需要的工具。

\\

要求估算容易，但他們很少有所幫助。實際上，他們是基于成本，而非基于價值來驅動決策。當我們以成本驅動制定決策時，我們是降低風險，而不是創新。在這層意義上，估算限制了我們創建新事物、提供更強大解決方案的能力

\\

對于我來說，#沒有估算變成了不僅是估算。如果決策在乎我們的估算，我們需要提供給他們，并提供其它因素，例如評估的復雜度以及歷史數據。如果他們沒有用，或者信心不足，那就不要投入太多。并且理所當然的，不管成本多少，開發同等的項目價值有時是值得的。

\\\

InfoQ：如您提到的，估算就是有關成本，不是產品和服務可帶來的價值。當我們做產品規劃的時候，在討論中可以做哪些事情把價值考慮進去呢？

\\\

Zilberfeld：這很有趣，我們經常要求估算成本，從而用于制定決策，但我們幾乎從不質疑價值。我們假設有人已經做好了正確的優先級排序。另一方面，我目睹過很多項目，在他們要求成本估算后，得到越來越龐大的數字，而項目依然前行。為什么？因為他們有足夠的價值。

\\

價值估算和成本估算一樣困難。然而，實踐者可以用如延遲成本（Cost of Delay（CoD））的方法進行試驗來進行功能和產品的價值估算。

\\

例如，讓我們看一組選項：

\\

• 功能A可以賣得更多，從而賺更多錢。 \\
• 功能B可支持保留現有的客戶。 \\
• 功能C可以增加我們快速添加更多功能的能力。 \

每一個功能都可以用真實貨幣來評估。我們可以估算，從功能A上期望賺多少錢，或者功能B，我們可以節省多少錢。現在我們問每一項的延遲成本是多少，然后可以進行比較。接著我們可以檢查，從功能A的早期獲利或者從功能B的節省上，先開發功能C對此的影響。

\\

一旦我們把所有功能都放在同一基準線上，并且估算每一項的價值，我們就可以決定先做哪個功能了。

\\

CoD及其類似的方法允許我們基于更多的信息做決定，而不僅是成本估算。

\\\

InfoQ：產品開發涉及到很多決策制定。您可否給一些例子，通常是怎么做的？當制定類似決策的時候組織面臨哪些挑戰？

\\\

Zilberfeld：我剛剛在ACE大會上做了一個演講，名字叫“投資回報率（ROI）已死”，我談到了產品經理從基于直覺到進行復雜的模擬來決定做什么。在項目組合層面，我們基于項目經理們告訴我們的內容制定許多決策。你可以說產品經理們是賭徒。不幸的是，就算你賭對了，產品也可能失敗：一個好的產品會失敗得很慘，僅僅是因為同一公司在兩年前發布了很糟糕的產品，聲譽變差，因此沒有人會再看一眼新產品。

\\

所以組織面臨的最大問題是復雜性。復雜性并不新鮮，它一直存在。但是在新的敏捷世界里，很難讓我們忽視它。當舊的產品扼殺掉了新的產品，這就是復雜性。當我們遭遇了不可預知的事件，這是復雜性。它就是項目殺手，有時也是公司殺手。

\\\

InfoQ：組織要怎么做才能改善產品開發決策？他們如何處理復雜性？

\\\

Zilberfeld：不要忽視復雜性。相反，我們需要找到一種方式穿過迷霧而沒有太多風險。我們需要假設我們在任意層面的無知，包括業務、開發和運營。一旦我們承認，難的部分就來了：我們需要改變工作方式。

\\

多年來，產品經理們定義產品，然后開發團隊開發幾個月。我們得到僅有的反饋就是當產品發布的時候。我們再也不能繼續按照那種方式工作了。不要用幾個月的周期，我們需要做沒有風險的試驗。不要對整個產品投100萬美元，而是需要用1萬美元看看它是否可以解決問題。如果我們對了，我們可以繼續以增量式驗證我們的假設。如果不對，我們則為公司節省了一大筆錢。

\\

當我與產品人員合作的時候，我總是纏著他們問他們對待辦目錄的價值有多少信心，包括問他們如何證實這些價值。如果信心不足，我們就計劃一個短的試驗，給到客戶然后學習。如果對了，我們就繼續。如果不對，我們就改變計劃。

\\\

查看英文原文：Q\u0026amp;A with Gil Zilberfeld on Agile Product Planning and Management

總結

以上是生活随笔為你收集整理的Gil Zilberfeld问答：敏捷产品的规划与管理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。