0.引子
作為一名摸爬滾打多年的產品狗，成長過程中難免"挖坑""埋葬"一些開發同學。因此，在本文正式開始前，我要對他們致以最崇高的敬意。
注：本文的主要目標讀者是互聯網圈人士，因此大部分詞彙和運作模式不做詳細解釋。
1.需求變更與其破壞性
需求變更，是產品經理和研發人員矛盾的最直接的導火索，因此我們首先要理解需求變更的原因。這裡歸納總結為3種：
原因1：認知不足，指產品經理、決策人乃至整個團隊沒有足夠的認知以面對即將發生的事情。例如，當團隊決定投入一個新項目或新領域領域時，若產品經理缺乏足夠的時間精力，或缺乏快速瞭解學習新領域的方法論時，必定有極大甚至致命的思維和視野盲區。在盲區中看到的方向、分解的目標、規劃的路徑和撰寫的需求，必然會為後續的項目進行挖坑無數。
原因2：外部變化，比如客戶需求變化、行業風口、降維打擊等。客戶需求變化在toB領域經常遇到，尤其是承接客戶定製化的需求，以及跨行業溝通時語境頻道不一致導致偏差。行業風口有太多例子，比如最近的疫情產生了遠程辦公和在線教育風口，周圍很多團隊把原本的規劃叫停轉而追逐風口。降維打擊發生頻率較少，往往在巨大的技術進步或商業模式創新下產生，比如智能手機幹掉紙質地圖，外賣幹掉泡麵。
原因3：內部變化，比如團隊人員變動，團隊意願與目標變動。原因3在大公司表現不明顯，小到團隊大到部門，其業務核心和戰略方向被公司高層牢牢釘死，且人員多有冗餘和互相備份，若大公司的需求變原因如此，那麼大多是由於公司級戰略調整、業務裁撤或關鍵人風險。而到了創業公司，原因3則經常發生，尤其是在經濟不景氣的時期，融資難讓無數創業公司把目標從擴張轉向了生存，甚至不惜提供外包服務。
從以上原因可以看出，需求變更往往是被動的，沒有人會無聊變更需求沒事找事。然而在崇尚快速試錯和擁抱變化的時代，需求變更只會越來越多，無法避免。這對個人、團隊和企業都形成巨大挑戰。
需求變更主要有以下幾大破壞：影響產品經理和決策人的個人威信與話語權；降低團隊成員的士氣；浪費團隊及企業的資源和時間機遇；toB領域的延期交付意味著對客戶信用的喪失。
限於篇幅，對破壞性點到為止，目的是為了引出一個概念：DevOps。
2.DevOps中產品經理的瓶頸
DevOps本身是一種開發理念，其目的是提升並行度，降低整體項目風險。這個理念已被廣泛運用於各大互聯網廠商，相信各位開發同學一定很熟悉，而產品經理往往對此不太瞭解，我同樣也沒有深刻理解。但接下來，我將以我過往的體會和經驗，試圖理清並解決這個問題：DevOps中產品經理的瓶頸。
首先通過幾張圖，簡要介紹一下DevOps。更詳細的解釋請感興趣的讀者自行搜索。
DevOps理念中包含了下圖中3種角色：開發，測試（QA），運維。
DevOps與傳統開發模式的區別如下圖。研發同學拿到確定且完整需求後，設計整體技術框架，並將其拆分為低耦合的模塊分別實現後，進行測試和部署。
正如上圖所示，DevOps能夠有效運作的前提是"確定的完整的需求"。然而需求變更又因各種原因頻繁發生，導致開發同學根據已經設計好的技術框架和拆分好的模塊無法很好匹配變更後的需求，嚴重影響資源利用效率，無法準確評估時間排期。在toB、平臺型等擁有複雜系統設計的產品中，這個問題尤為尖銳。
即使運用DevOps理念，也無法很好地應對需求變更。要想降低需求變更的影響，似乎只能靠產品經理的經驗沉澱和細緻分析，給出更可靠的完整需求。除此之外，是否有更好的解決辦法呢？
3.瓶頸的解決辦法
直接給結論：1.產品需求模塊化；2.需求模塊與開發實現的模塊建立關聯。
結論1，相信很多產品經理都能夠做到，以用戶視角撰寫的需求說明書，其中包含一個個獨立場景的"故事板"。工具方面，目前市面上很多，比如看板類的Trello、功能更豐富的TAPD、Aone等等，更何況功底好的產品經理，用紙和筆都能寫出優秀的需求說明書。因此，產品需求模塊化，這是一條產品經理都應做到的基本要求。
真正難落地的是結論2，我這裡直接給一張圖，描繪出我理想中的解決方案。
以上圖為例，該項目的所有事務已經拆分為低耦合的模塊，連接線表示各個模塊之間的關係。完整的需求包含3個故事，此時遇到需求變更，故事2變化，通過連線可以輕鬆找出後續受影響的一串工作。此時團隊成員可以輕易做出最優決策：產品經理輸出新的故事2需求說明書，其他同學並行推進不受影響的部分。
以上案例看起來很簡單，相信大家也都能理解這樣做的好處和意義，甚至在回想自己的項目中似乎也是這樣做的。但是，請大家仔細想一想，日常工作中是否有類似上圖的可視化工具，幫助大家建立並找到模塊之間的聯繫麼？至少在我所經歷的項目和環境中，沒有。
其實這種工具的本質是一種"連接器"，我會繼續找尋，同時希望各位讀者能夠賜教。
*註釋：關於"連接器"的定義，請參見我的上一篇文章：《釘釘人治，飛書法治，微信無為而治》，。同時要補充，連接器連接不同應用是基礎，能夠讓應用之間也能信息互通才是優秀。企業微信只做到了基礎連接，例如聊天和在線文檔是獨立的，對在線文檔的討論還是要回到聊天中進行；而飛書是一款優秀的連接器，它可以在文檔中針對某一個觀點直接展開討論，最終形成結論沉澱到文檔之中。
總結一下我的解決思路：在DevOps的基礎上，納入產品經理這個角色，一切事務模塊化，模塊之間建立準確聯繫。暫時就叫做PDQO吧，取產品、開發、測試和運維四個角色的英文首字母。
99.尾巴
希望本文能夠拋磚引玉，最終讓團隊中的各個角色消除隔閡，達成更好的目標。
閱讀更多 4heads 的文章
