產品管理流程思考：互聯網產品流程的碎片化

什麼使得一款產品從0到1？

不同人而言，有不一樣的理解和篤定。如是說來，興緻萬分，十分有趣。人們通常是先相信某種東西，而後再去找證據來證實自己的觀點。

有人覺得，技術水平是一款產品的基礎條件；

有人相信，資金能力是一款產品的必要前提；

有人堅持，溝通技巧是一款產品的實現助力；

有人認為，人是一款產品的核心要素；

很多人，很多認為…

顯然，我是無法反駁上訴的任何一條觀點的，難道說技術、資金、溝通、人對軟體毫無裨益？然而，是否有維繫全部產品要素的紐帶存在？

我相信，一定是存在的並且為大多數人所知。做產品以來，一直有人問我，你覺得對產品而言，最重要的是什麼？坦白講，我的內心是抗拒的，產品本身就是一個複雜的綜合體不僅得益於源於一個複雜的過程，不論如何回答都無法達到一個平衡。

產品管理流程（Product Design Process）簡稱PDP，特別不喜歡使用【項目管理】這個詞，平時的工作中我很少提及，因為我覺得項目管理傾向於專註項目本身，過分強調關鍵節點，輪廓很清晰。愚認為產品管理是完全覆蓋項目的管理的，並且用於項目管理所不具備的優良特質，產品管理是一個價值導向、有溫度的過程，不是錙銖必較，不是須臾推諉，不是閉門造車…

經典的軟體工程提倡採用線性的工作流方式，應用範圍最廣、最有名氣的莫過於——瀑布模型（waterfall model ），又被成為經典生命周期（classic life cycle）。

瀑布模型提出的是一個系統的、順序的的軟體開發方法，從用戶的需求規格說明開始，通過計劃、建模、構建和部署的過程，最終提供一個完整的軟體並提供持續的技術支持。

是不是是曾相識？好像在哪見過？是的，該方法到目前未知，還有很多公司在遵循，暫且忽略一些弊端，該模型真的是經典之最，沒有之一。

由於現實的壓迫，實際的項目很少嚴格遵循瀑布模型的順序，因而後期對該模型做了不少改變，比如V模型、增量模型、原型開發模型。一些比較前衛的互聯網公司，大多採用了【增量過程模型】持續交付，各個公司依據自己公司的實際情況可能存在細節上的差異，但總體的思想是別無二致的。

現代軟體又提出了一個用於開發和維持複雜產品的框架 ——SCRUM，是一個增量的、迭代的開發過程。SCRUM的五個價值觀：

如果你對SCRUM有所了解，其實就能知道SCRUM的兩個重要觀點：敏捷開發、XP編程，讓其看起來更像是一個偏向於軟體開發的概念。

我認為，事實上確實是如此的，將開發人員前置需求、過程化是一個很有先見的做法。

當然，現實終究是相對比較骨感的，對人員素質和團隊結構的要求都近乎嚴苛，而現在公司的人員簡直就是流水般順滑，因而採用SCRUM的產品管理理念的團隊知之甚少。

古語有云：不以規矩，不成方圓。如果說沒有一個相對範式的產品流程，那麼0到1的產品過程必然是不可言喻的，而其中的關係人更是苦不堪言、無意言表。或許這正是大多數產品死在路上的重要原因，大多數技術人員對產品人員印象很差的最初來源。

下述流程是一個經典的【瀑布模型+增量模型】的複合流程，其有兩個關鍵要點：一是流程的線性，二是執行的交叉。之前我已經在《產品經理必修課之產品設計流程[完整版]》一文中做了詳細說明，下面將概述關鍵要點，不再贅述：

2、概要設計

3、技術追蹤

4、回歸迭代

產品設計流程將整條產品線上的人員都串聯起來，將產品過程「數據流」化，可謂氣貫長虹、如夢般絲滑。產品流程將產品從各個原本獨立的實施過程聚合成一個統一的變現行為。

這幾年的產品經歷，確實是屬於自己的幸運——遠勝於畢業之初進入BAT的機會，如果說沒有最初的時光，我想可能不會有今天的這篇文章，而我也不知道自己在哪做著什麼？甚至，也就少了一個產品經理與你們淌這趟「渾水」了…

產品驅動的團隊，產品的需求範圍由產品經理敲定，而一個技術驅動的團隊，產品的需求版本完全依據技術的資源/能力進行削減，既定的產品規則被肢解，很是無可奈何，任花落去。就這樣認命呢？這可不是一個產品人該秉持的態度，拾起來…

無流程的尷尬並不是產品經理面對的問題，大部分團隊/公司都經歷著同樣的煎熬，想要流程卻又礙於現實，沒有流程又只能走向OUT。既有的產品流程又無法滿足團隊的期待，那麼該做些什麼？於我個人而言，是經歷過這樣的尷尬和陣痛的，試探性的調整了產品管理流程，終究得出一個新的嘗試：碎片化的產品流程。

名詞解釋：碎片化，Fragmentation；去中心化，Decentralization

碎片化的產品流程提出了兩個關鍵的理念：碎片化、去中心化，也是個人這幾點對產品的概念從建立到打碎到重新建立的過程。

產品設計的遵循一定的範式，比如：需求管理、需求文檔、原型設計、UI設計等等，無論跨入一個怎樣的團隊，與怎樣的同事協作，這些要素都是相對不可或缺的，是產品經理最基本的輸出。

然而，各自的表達方式存在明顯的差異，這樣的差異體現在時間和空間之上。

舉個栗子，產品需求文檔（PRD）的輸出形式存在多樣的形式，有專業的文檔、有直接原型標註、甚至有直接以交流代替文檔的…

因而，所屬的產品流程需要被打碎，在恰當的時間、恰當的方式重新組合，甚至會做一些自適應的調整和優化，這就是所謂的碎片化。

傳統環境下，一個公司/組織都是圍繞一定的信仰/中心去運轉的，互聯網類的公司也無法倖免。大致分業務驅動、運營驅動、產品驅動、技術驅動，各種公司格局都是由公司所處的成長階段決定的，而不同的格局也註定公司走向何方和做多遠。

上述的經典的產品流程可以認為是產品驅動的格局下的順序流程，很明顯產品處於一個中心的位置，一切都圍繞產品展開。

對於一個產品經理而言，這樣的格局不可能一層不變，升職、跳槽都面臨著角色的轉變，因而打破中心化的概念，嘗試多中心的理念，將不同產品碎片置於不同的場景之下，相信你會有不一樣的收穫。

最後，我還是想問：為什麼需要產品流程？本質上而言，產品流程是一套人為制定的規則。這套規則的存在並不是要求人們去嚴格的遵循和信奉，而是對過程的督促，最終的目的都是為了解決問題。

如果說，產品流程阻礙了問題的解決，請果斷重構TA；

如果說，產品流程破壞了團隊的節奏，請立刻改變TA；

如果說，產品流程影響了你的心情，請暫時忘記TA；

如果說…

或許正如所遇見的那樣，【無流程】是一個現實問題，或者說是一種趨勢。請記住：在那之前，你還有團隊、公司…

我相信：不給別人添麻煩，是對別人最好的尊重！

王偉，@簡書-互聯網產品小王。一個會講故事的產品人，喜歡做菜、樂於家務、懂生活的工科男，將理想照進現實的佈道者。

本文原創發佈於人人都是產品經理。未經許可，禁止轉載

推薦閱讀：