當我們的研發團隊組織架構搭建完畢後，接下來需要思考的是，如何讓這個架構跑起來、跑得快、跑得穩。此時，我們需要定義出一個高效的研發流程，還要儘可能降低研發過程中所遇到的風險，確保在流程的每個環節中都不能出錯。
在定義具體的研發流程之前，我們需要從整體入手，先把研發流程體系架構定義清楚，便於讓團隊從全局上把控整個過程。接下來需要從局部入手，將研發流程中所涉及的操作步驟羅列出來，便於指導團隊完成具體的工作。
現在我們就從整體開始，對研發流程的體系架構進行探討。
研發流程體系架構
高效的研發過程應該具備“多線程”的特性，彷彿多條並行流淌的河流，上游是業務，中游的是產品，下游是技術，流量取決於業務，流速取決於產品和技術。
需要說明的是，這裏的“業務”其實包括兩類人：一是公司內部使用產品的業務同事，二是公司外部使用產品的最終用戶。爲了便於描述，下文統一將他們稱爲“業務需求方”或“業務方”，簡稱“業務”。
根據我的上篇文章可知，整個研發工作流程體系架構是職能團隊與項目團隊的有機結合，團隊職責清晰且協作高效（如圖 1 所示）。
圖 1：研發流程框架圖
在職能團隊中，產品委員會的產品專家們將業務需求統一記錄到“需求池”中。需求池中的每一個需求都要描述業務的當前現狀，還要包括業務對產品的未來期望。每隔一段時間（一般是 1~2 周），產品委員會將根據需求池中所記錄的需求細節加以討論，並將優先級較高的需求進行立項和排期，項目團隊可知曉近期需要實現的業務需求是什麼，整個團隊的方向感也更加清晰了。
需求池中一個典型的需求可包括以下字段：
- 需求名稱：用一個關鍵詞描述，最多15個字。
- 需求來源：該需求來自於哪裏？包括：業務、運營、財務、法務、市場、其他。
- 業務痛點：爲何要實現該需求？即業務當前的現狀。
- 需求描述：該需求具體是什麼？即業務將來的訴求。
- 渴望程度：期待何時可以上線？包括：本週、本月、下月、本季度、下季度、未來、或具體截止日期。
- 需求類型：包括：新功能（從 0 到 1）、優化（從 1 到 100）。
- 需求規模：包括：大（兩週以上）、中（一至兩週）、小（一週以內）、未知。
- 備註：可寫下對該需求的補充或疑問，以便深入交流。
- 附件：可通過相關文檔對需求進行補充描述。
- 創建人：該需求被誰創建？
- 處理狀態：包括：未處理（默認）、處理中、已處理、關閉。
- 優先級：包括：A（重要&緊急）、B（重要&不緊急）、C（不重要&緊急）、D（不重要&不緊急）、X（待定）。
- 負責人：該需求由誰跟進？
簡單情況下，可使用電子表格的方式來維護需求池，比如：Numbers、Excel 等，當然也可通過在線方式來管理，比如：石墨文檔、金數據等。
需要注意的是，需求池對公司全員共享，由產品委員會管理並維護，其他人員只能閱讀但無法編輯。產品專家們首先需要和業務需求方進行有效溝通，深刻理解他們的業務痛點與未來期望後，才能將這些需求入池。
從需求池中挑出的高優先級需求將分別“流入”對應的項目團隊中，在項目的執行過程中難免會遇到技術上的遺留問題，然而團隊不希望因爲這些問題而導致項目工期受到影響。因此，這些技術遺留問題將被列爲“技術債”，技術委員會中的技術專家們將對這些技術債加以管理和跟蹤，在後期會有針對性地解決這些技術問題，償還這些技術債。
瞭解了研發流程體系架構後，下面我們進入具體的研發流程操作步驟。
研發流程操作步驟
將需求轉化爲項目，是一個複雜的過程，如果只是一個體系架構，恐怕也只是空中樓閣，因此我們有必要對整個研發流程體系架構進行細化，爲其設計具體的操作步驟，以便讓整個流程可以順利落地。
我們可定義了以下 10 個操作步驟，將需求轉化爲產品，將產品轉換爲項目，將項目順利上線（如圖 2 所示）。
圖 2：研發流程操作圖
以上 10 個階段，涉及到不同角色的人員，每個階段需要包含當前所需完成的任務，也涉及到相關例行會議。我們可將這份操作步驟打印下來，發給每一位研發人員，並貼在會議室的牆壁上，每日站立會的時候，團隊都能看得見它。我們會慢慢發現，每個項目團隊都有相同的工作習慣，大家還可不斷優化這份操作步驟以及其中的相關細節。
需要注意的是，產品經理在需求調研階段，必須瞭解業務的當前現狀，搞清楚業務痛點是什麼？我們不妨這樣做業務調研：如果沒有這項功能，業務同事需要花多長時間、多少人力來完成自己的工作？當前的獲客成本是多少？訂單轉化率是多少？產品經理需要將這些信息和數據記錄下來，並豐富到需求池中。此外，在每次啓動項目之前，需要得知該執行項目的目標是什麼？如何來驗證這個目標？
我們需定期對已上線項目進行復盤，可通過“覆盤四步法”來完成：
- 審視目標：當初設定的目標是什麼？目前達成的現狀是什麼？差異是什麼？
- 回顧過程：回顧整個過程是如何進行的？大致分爲幾個階段？每個階段發生了什麼？
- 分析得失：哪些方面做得好？哪些方面做得不好？爲什麼？
- 總結規律：再次做同類事情應該怎麼做？對未來工作有何指導？有何規律、原則、方法論？
使用以上項目流程與覆盤方法，可確保以正確的方法將事情做正確。但是，只能解決研發內部的閉環問題，似乎無法解決研發和業務之間的外部閉環問題，也就是說，研發和業務之間的高效協作問題還需進一步探討。
研發與業務如何協作？
這個問題也許在許多企業中會存在，畢竟業務和研發的工作性質不同，關注點也不同，因此考慮問題的方式也會不同。
業務心中可能會這樣認爲：爲何我們提出的需求，研發總是遲遲不解決？
研發心中可能會這樣認爲：爲何我們上線的功能，業務總是遲遲不反饋？
我們似乎遇到了一個“死鎖”問題，彼此都在等待對方。業務提出需求，得不到及時響應；當研發響應後，卻得不到反饋。久而久之，業務和研發之間會失去信任，從而嚴重影響企業的可持續發展。
這裏我向大家介紹一種新玩法，它能讓業務和研發得到更好的閉環，而且讓雙方的協作過程變得更加順暢。我們稱這個方案爲“特贊之聲”（如圖 3 所示）。
圖 3：特贊之聲
在公司內部，我們製作了一種叫做“特贊幣”的虛擬貨幣，其實它只是普通的磁鐵，幣上貼了一個自制的圖案而已。我們給業務部門發放固定數量的特贊幣，爲了避免“通貨膨脹”現象，我們一次性不會發太多幣，後期可根據實際情況適當增發。
當業務部門遇到痛點時，可在痛點卡片上手動填寫具體痛點，並用特贊幣將卡片固定在白板上。此時需要消耗一個或多個特贊幣，如果一次性使用多個幣，表示優先級更高。項目上線後，當業務部門提供使用反饋後，將得到一個特贊幣，提出的反饋包括對已有功能的稱讚或吐槽。
也就是說，提需求要“花錢”，提反饋可“賺錢”，這樣可確保業務所提需求都是最大痛點，由於幣數是固定的，因此需要通過提反饋來獲取新幣，這樣研發和業務自然就建立了有效循環。
除了痛點和反饋以外，公司全員也可以提出腦洞，也就是對產品的奇思妙想，腦洞被產品委員會採納後，可贈送一定數量的特贊幣。痛點會使用特贊幣將其吸附在白板上，反饋和腦洞可使用普通磁鐵來固定。
使用特贊之聲，我們得到了以下收益：
- 業務人員：業務痛點得到更好的重視，得以更快速地解決。
- 研發人員：產品價值得到更好的體現，產生更高的成就感。
- 彼此雙方：業務與研發不再孤立，從而形成了完美的閉環。
寫在最後
沒有人願意在一個複雜的流程上投入自己更多的時間，流程是幫助我們更規範地做事情，目的是避免犯錯誤。因此，在流程的定義上，我們可以先簡單後精細，簡單才便於操作，精細才易於管理。
以上我們提到的研發流程十步驟，對於大家而言只是一個參考模型，大家需要根據自身實際情況，作出合理調整，流程才能發揮出最大的作用。否則，它可能會變成一種負擔，反而約束了我們前進的速度。
研發流程是團隊的行動規範，是大家共同智慧的沉澱，流程高效，產出才能高效。
作者簡介
黃勇，現任特贊科技 CTO，圖書《架構探險》作者，開源項目作者，技術大會講師，企業培訓師。十年以上互聯網軟件架構與技術管理經驗，擅長敏捷開發，推崇“輕量級”架構思想。喜歡閱讀，熱愛交流，樂於分享。