產品開發流程建設的五個關鍵

產品同人一樣，都有自己的生命周期。從階段來看，不同產品的生命周期階段幾乎無異，都有研發、驗證、試產、發布、運營及消亡的過程。但如果展開生命周期過程中的所有細節，就會發現幾乎每一款產品在相同的生命周期框架下，都有不同的發展過程。這種不同就像不同的人在生命周期中存在巨大的差異一樣，由於出生背景、獲取資源的能力以及學習成長速度的不同，導致了每個人的人生歷程都不盡相同，結果更是千差萬別。今天，很多研發企業正在努力嘗試建設一套科學、高效的產品開發流程，試圖讓企業的產品能夠在整個生命周期中大放異彩，但結果卻不理想，大部分企業顯然還沒有找到建設高效產品開發流程的密匙。這密匙到底是什麼呢？答案眾說紛紜，標準不一。在多年的產品開發流程建設實踐中，筆者總結出了一些建設高效產品開發流程的普適性原則，歸納成為五個關鍵點，和廣大讀者一一分享，希望能夠給大家帶來啟發。

一、流程建設部門與執行部門的分離

很多公司沒有設置專職的部門進行產品開發流程建設，流程往往是公司某個領導苦思冥想的產物，發布後讓產品開發人員按照流程進行產品開發。沒錯，這樣的做法也能夠把產品開發出來，但是效率一般不會獲得大幅提升，而且流程執行過程中因為缺乏有效指導和監管，反饋和優化，會導致流程的執行流於形式，甚至會出現一些矛盾。這裡給大家還原一個筆者曾經接觸過的真實

案例：

某公司的產品開發流程是按照上述方式建設出來的，在某一個產品開發過程中，有一位資深的設計工程師在項目某個節點上需要填寫一份申請，該流程要求申請必須填寫三份表單，結果該資深工程師拒不執行，只寫兩份。在項目經理的協調下，該資深工程師與建設這套流程那位主管領導進行了溝通，結果不歡而散。一個堅持流程的要求不肯動搖，一個堅持這個環節不需要寫三份表單，流程設計不科學，拒不執行。最後經過更高層的領導協調後，發現產生矛盾的根源是設計流程的主管與該資深設計工程師存在矛盾多年，平時工作很少交流，而且經常是處於對立面，所以關於這個流程的糾紛的根源不在於流程是否科學，是否合理，而是人的矛盾，但凡是這個主管根據自己的經驗建設出的流程，那個資深工程師就不會有任何執行的意願。類似這樣的矛盾衝突其實在很多公司都存在，只是輕重不同而已，那出現這種問題的根本原因是什麼呢？筆者認為主要是以下兩點：

1. 設計流程的源頭沒有理清，到底該由誰來設計流程？我們必須認識到流程建設不是一個簡單的事情，不是畫一張圖就結束了，建設時需要思考效率問題、職責問題、執行問題……建設後還需要宣導推廣，而不是讓員工強制執行。所以要想做到這些，一個最基本的條件就是交給專業的流程建設人員來處理。

2. 很多公司把設計流程當成了終點，認為設計出一套流程，按其執行就萬事大吉。這種做法顯然無法發揮流程的作用，流程必須在實踐的過程中不斷地被優化才能逐步變得更加卓越，所以唯有把流程建設與優化當作一項長期的、持續性的工作才能讓流程發揮其應有的作用，正所謂「打江山容易，守江山難」，實現太平盛世更是不易，所以要想持續的進行流程建設與優化的工作，顯然需要一個專業且中立的組織來主導流程的改進工作。

這時候很多管理者又會找理由說「我們公司規模不大，沒有能力用一個部門來支撐流程建設這件事」。但如果是這樣，至少可以設置專門的流程專員來開展更專業的流程建設工作，哪怕只是一個負責人而已，重要的是要有專職的人員。至於這個人是否隸屬於一個專職的流程建設部門，其實不是最重要的。

二、執行部門代表參與流程建設

這個關鍵點不難理解，我們可以理解為流程是流程建設部門的一款產品，那用戶在哪裡呢？用戶就是使用流程進行產品開發的執行部門的所有人員。用戶參與產品設計是當下很受追捧的一個理念，很多公司都在研究如何有效地組織用戶參與到產品設計中，進而推出更符合用戶需求和價值的產品。開發產品如此，流程建設也是一樣。有了專職的人員和部門來建設產品開發流程後，必須讓專職人員深入到業務層面去思考如何建設並優化流程，而不是脫離業務，紙上談兵。

在建設實施過程中，由每個部門派出代表，共同參與集體討論和決策，最終輸出相關角色所達成共識的操作流程，如此設計出的流程才能在未來的產品開發過程中更好的落地，否則同樣會出現上述案例中的情景——「我做產品開發幾十年，憑什麼按照你制定出流程來執行呢？」所以，執行層共同參與流程建設至關重要。

三、準確地找到兩端，建設端到端的流程

流程建設猶如修建高速公路，目的是讓產品開發項目在上路之後全面提速。項目有一個重要的特點就是有明確的起點以及終點，所以要想項目始終在正確的高速公路上快速前進，就必須清楚兩個端點在哪裡，即清楚地知道產品開發項目從哪裡來，最終要去到哪裡。產品開發流程的起點端一定是面向用戶的市場，產品的創意以及項目的概念必須來源於用戶的需求。N 多共性的用戶需求經過整理和分析形成有效的細分市場，為此開發一款滿足該細分市場的產品，是產品開發流程建設的起點。而事實上，很多企業沒有搞清楚這個起始端，把產品開發的起點定義成了老闆或者決策層的命令，認為項目應該是從高層這裡發起的，顯然從這樣的起點出發的流程最終產生的結果一般都不盡人意。

產品開發項目的終點端又在哪裡呢？——交付滿足用戶及細分市場價值的產品。兩端本質上是一致的，即從用戶/ 市場需求出發，最終回到用戶和市場上。所謂的流程建設就是在兩個端點之間搭建高效的產品開發網路，把人、工具、方法、活動等要素緊密地聯繫起來，讓產品開發的效率不斷提升。找對兩端並圍繞端點進行流程搭建，可以起到事半功倍的效果。

四、自上而下，由粗到細，建設結構化的流程

事實上，每一家研發企業都有自己的產品開發流程，只是表達形式各異而已。有的企業用一張完整的流程圖來表達；有的企業用一份類似於制度的程序文件來表達；有的企業則採用了圖文並茂的形式來表達，既有流程圖，也配套程序文件。看上去，第三種表達形式似乎更科學有效，但實踐中我們發現採用了第三種形式的公司大部分依然在抱怨產品開發流程無法有效的落地，究其根本原因，是流程沒有結構導致了落地效果不佳。那何為結構化的產品開發流程呢？最簡單的理解就是產品開發流程應該是自上而下、由粗到細，逐層的地進行表達，而不是試圖通過一張圖或者一份簡單的文件說清楚產品開發過程中的所有事情。一般來說，結構化的產品開發流程分為四層（如下圖）：

第一層 （產品開發流程概覽）：定義產品開發流程的階段、角色，以及每個角色在每個階段中所需要執行的關鍵活動；

第二層（詳細產品開發流程）：對每一個階段中的關鍵活動進行分解，分解到清晰的活動任務中，並建立起邏輯關係，明確每個任務的輸入和輸出；

第三層（支撐子流程）：例如在詳細流程中定義了類似於「產品需求評審」這樣的任務，但如何進行需求評審呢？只有對這個任務進行展開，詳細定義其組織、過程、具體的操作要求等，才能保證需求評審的過程可以落地執行，並且發揮作用。否則在沒有支撐流程的狀態下，詳細流程中類似這樣的任務定義就像空中樓閣一樣，只好看，不好用；

第四層（模板、表單、指導書）：例如在流程中定義「制定項目進度計劃」這樣一個任務，那如何具體執行呢？我們需要為不同的項目管理者建立一個相同的過程和準則，如需要使用Project 工具進行計劃制定，里程碑計劃和詳細計劃在什麼時間點需要以什麼樣的形式輸出，類似於此的操作指導以及相應的交付件的模板均屬於這一層。

是不是大家都需要按照這樣的標準分層來建設流程才能保證落地呢？也不盡然。但至少我們需要吸納結構化流程的核心思想，在產品開發流程建設時考慮結構化分層，至於分成多少層次以及如何定義，需要根據企業的實際情況因地制宜。

五、持續改善才能真正發揮流程的效用

流程建設一定是基於現有的做法、科學的理論以及他人的成功實踐總結出的一套「我們認為的科學的流程」，但坦白一點說，我們企業建設出的第一版流程往往都是漏洞百出，錯誤連篇的。要想真正發揮流程的作用，必須在流程實踐的過程中不斷獲取大量的度量數據及執行團隊的反饋，並基於度量與反饋對產品開發流程進行持續的升級和改進。對待這一過程，我們的口號應該是「沒有最好，只有更好」。但筆者在過往的培訓和諮詢過程中發現很多企業的做法恰恰相反，一旦推出一套流程，就想著一勞永逸，百年不變。久而久之，流程的執行更多只是一種形式上的體現，根本沒有發揮效用。

科學的做法應該是在流程建設與執行之間形成有效的反饋鏈條，流程建設職能負責制定、宣導、指導及優化產品開發流程；流程執行職能不僅需要按章辦事，還必須在每個項目執行的過程中反饋流程的缺陷和問題，再由建設部門主導流程的改進，不斷推出更先進的流程版本。如此循環，才可以讓產品開發流程實現可持續發展，並切實起到提升產品開發效率的作用（如下圖），而不僅僅是一份規範。

最後，領悟思想遠重要於學習形式，希望本次分享能在思想上引起大家的共鳴，至於如何在企業內展現這些思想，形式則可以是多變的。

文/中天華夏 顧問