為什麼你的產品團隊沒有矽谷的快？你可能用了假的敏捷！

敏捷，精益，幾乎所有的團隊都聲稱在運用這些流行的概念。但是你的團隊是否總是快不起來？總無法從敏捷管理中獲得應有的效率？你是否想過，也許你僅僅做到了形式上的敏捷，本質上仍在使用瀑布式管理？產品經理必讀書《啟示錄》作者，矽谷產品大師 Marty Cagan 為我們揭示了瀑布式管理的三大特徵，快來看看你的團隊有沒有中槍吧！

當今產品管理領域內，幾乎已經沒有人仍在為瀑布式的產品管理方式辯護，我們必須承認敏捷方法可能仍然有一些缺陷，但它至少比瀑布式管理缺陷更少。

然而，我也遇到過很多團隊，他們聲稱自己在踐行敏捷和精益管理方法，但當他們告訴我他們究竟是如何工作的時候，我通常不得不很不情願地指出，他們只是形式上的敏捷和精益，他們僅僅是將精益作為一個流行詞記了下來，但是當我們剝離掉這些形式，他們實際上仍然在實踐瀑布式的工作方式。

儘管關於這個話題我已經寫過一些文章，但我還是會經常遇到這樣的問題：究竟有什麼跡象能夠指出團隊是否仍深陷瀑布式工作方式的陷阱？

瀑布式工作方式有以下三個明確的特徵。其中任何一個都是瀑布式管理非常強烈的指標，但根據我的經驗，如果你在某個團隊的工作中找到一個指標，那你通常會發現所有三個：

1.將風險留到最後

如果整個團隊等待了幾個月，直到他們的工程師已經實際開發了某樣產品或功能，或者是某種近似於產品的半成品（通常被錯誤的認為「MVP」），才去審視這是不是某種可以被售賣的，用戶可以使用的，技術上可行的，能為業務服務的東西，這些風險都被留在流程的最後，而這正是瀑布式工作方式的傳統特徵。

我們希望團隊能夠事先解決以上這些風險後，再讓工程師花費時間和成本去開發某種可交付的產品。

2.需求驅動設計，需求驅動開發

如果團隊中的產品經理在定義（或更糟糕，收集）需求，無論是通過需求文檔或是用戶故事，然後將這些需求傳遞給設計師，要求設計師設計出滿足這些需求的用戶體驗（通過注釋文檔或注釋線框圖的形式），然後將這些信息在衝刺規劃階段提供給工程師，讓他們在這一階段構架實施方法，預估並進行開發，那麼這種序列式的產品定義過程正是瀑布式流程的核心。

而我們希望的是，通過協作的方式定義產品。產品，設計和開發一同工作，反覆討論，反覆溝通，得出一個有價值的，可用的，可行的，可經營的解決方案。技術的可能性能夠像其他方式一樣去啟發設計和功能。

3.關注產出

如果團隊的工作都集中在發布某個功能或項目上，這通常取決於產品路線圖上的許諾，而沒有團隊去為實際的業務結果去負責，那麼這就是瀑布式工作方式的第三個明確標誌。

我們希望團隊負責去解決潛在的業務或客戶問題，而不是僅僅去發布產品路線圖上的功能。如果該功能不能解決問題，那麼團隊需要去迭代這一功能，或採取另一種方法來解決問題。

有時敏捷團隊會探討「Done Done」這個概念，它通常是指讓事情達到真正可發布的狀態，不只是完成開發工作，而是包括整合，QA 和分發。以上這些是非常重要的，但還遠遠不是我要探討的內容的全部。對於現代產品，它還必須能夠解決潛在的業務問題，而那通常會涉及更多的工作和技能。

總結

有一種非常簡單的方法可以快速的評估你的團隊是否仍然以瀑布式的方式工作。只需去找出（在上個月或季度）一共定義了多少東西，然後實際（在上個月或季度）構建和交付了多少東西。

一個以瀑布式的方式工作的團隊能夠大致完成他們定義的所有事情。

而一個真正接受現代方法的，真正意義上超越了瀑布式工作方式的團隊，將在探索過程中嘗試比他們實際開發和交付的產品至少多兩倍的想法。一個真正優秀的團隊會給出一個更小的比例（但不是通過少交付，而是通過多嘗試）。

如果你在真正的去探索一個能夠奏效的解決方案，那麼你在做的就是產品發現。如果你只是簡單地確定你想讓工程師開發的東西，那麼你就仍在使用老舊的產品定義。

這就是為什麼我要推動團隊，無論他們更傾向於過程還是技巧，以確保他們專註以下三個大領域：預先處理風險，協作定義產品，注重結果。

2018 全球產品經理大會 | 官方網站，6月29-30日，北京金茂萬麗酒店

2018年，互聯網進入下半場，Whats Next？面對技術更新和產業變革，產品創新要如何把握互聯網下半場的機遇，鳳凰涅槃？

Boolan 攜全球30餘位頂級產品領袖與實戰專家，於2018年6月29-30日於北京舉辦【2018全球產品經理大會】，從前沿方法論到一線實戰經驗，全方位探討進入互聯網下半場的產品發展，創新，實踐，聚焦 "Product Next"。現在購票更可享7折優惠，立減2040！速來報名！

2018 全球產品經理大會 | 官方網站