編輯導語：由于每個互聯網產品都有著一定的差異，所以每個團隊的產品流程其實都大不相同，也沒有一個完全的標準，但是大致上的研發流程還是有相似之處；本文作者分享了關于大型互聯網產品流程，我們一起來看一下。

最近因為工作需要特意整理了產品的流程，其中基本覆蓋了互聯網產品的主要節點，由于這個偏通用型，所以并不能說這個就一定適用不同類型或者不同階段的產品；尤其對于創業型或者敏捷型團隊，其推進的流程是相對簡單的。

這兒需要特意強調：不要迷戀流程！不要迷戀流程！不要迷戀流程！

當團隊需要靠流程來約束的時候，團隊戰斗力和自驅力已經受損了，流程往往是一種多個角色妥協的結果，而且流程使用不好，對于團隊殺傷力極大。

既然聊到流程，就多說幾句個人的觀點。

• 流程只是一個“約束”，是希望盡量讓大家協同效率變高；但是不應該讓團隊成員用流程來反向約束或者挑戰關聯角色，不應該成為一種“制衡”或者“甩鍋”的工具。
• 流程在使用中如果發現不對，當有“甩鍋”的苗頭，需要盡快調整。
• 業務在不同階段、團隊成員能力構成不同，產品流程可能差別很大。
• 如果大家的精力都在focus流程，那這個項目團隊勢必已經走偏了，可以預判業務沒有“增長”。

如下流程將大部分關節節點都有體現，其中并不是強制約束，可能不同階段的團隊在部分節點上的處理方式會有不同。

我們來詳細聊下這些節點：

一、BRD階段

核心點就是“需求來源”，不同公司情況差別很大，很多產品的需求其實來自于老板，經常甩一句“xxx老板的需求”，這種需求基本上也就不存在BRD的說法了，需要對接需求的同學能相對清晰的理解需求。

大家往往容易忽視這個階段的重要性，因為這個階段其實需要收集到比較關鍵的信息，比如需求背景、價值、上線時間預期等，這些都是接下來會直接影響項目排期的。

大部分公司項目資源都是有限的，所以往往都會涉及到優先級的PK；如果前期收集的信息相對完整，在中間決策的時候，就不需要再往前回推找人確認這些信息。

二、產品規劃

這個話題很大，需要通過單獨的topic來聊。

有幾個點需要注意：

• 產品規劃體現的是對于需求輸入和產品長期走向和資源現狀的綜合判斷，是一種綜合能力的體現。
• 產品規劃的大忌就是看似很漂亮很牛逼，但是不接地氣，落不了地。
• 規劃是一種動態的行為，需要根據產品推進階段和資源情況，以及市場環境變化或者組織結構的變化，而及時調整。

三、需求設計

即我們常說的需求文檔輸出——能否輸出高質量的需求文檔，也是體現產品經理能力的地方；需求文檔的核心在于讓開發和測試理解需求，通過這個文檔可以按照產品經理的要求交付功能。

個人的風格更加傾向實用主義，也就是用相對清晰簡潔的方式高效率的把文檔輸出，這個要基于對于開發、測試的理解能力的判斷，以及相互的配合默契程度的把握。

首先確保大方向和邏輯不要跑偏，關鍵細節需要盡量完整，但并不一定是每個地方都需要特別精細特別完整。完整的背后就是時間和精力的投入。

產品交互和流程建立一些基礎的規范，可以大大提升效率，這個需要日常的積累，構建規范，構建默契。

關于需求文檔模板或者規范，這個還是很有必要的，至少可以減少產品內部或者研發對于需求文檔理解的成本；但是這個模板不要太復雜，別規定的太細，可以先從粗后細；比如剛開始只需要明確需要包括：需求背景和目標、關鍵名詞解釋、核心流程圖、用戶量預期等（用戶量預期，這個對于研發比較關鍵，他們會根據這個指標或者節奏來制定合理的技術方案）。

四、需求內部評審

這個階段很有必要，尤其是一個初創或者還不是特別成熟的團隊，通過資深的產品來review下需求設計，會避免后面很多問題；往往很多較為初級的產品經理容易受經驗的限制造成設計的方案考慮不夠完整，容易出現邏輯漏洞，或者方案擴展性不強。

但是如果配合默契的團隊，并不需要單獨有這個步驟，一般都會潛在的“導師制”，也就是初級的產品經理一般會在設計方案的時候會先和自己的“導師”先溝通對齊方案，然后再寫文檔，避免后續修改返工。

五、提測后的走查

只要產研配合順暢，這個階段一般是不需要的。

將這個節點列出來，只是在有些比較重要的產品功能或者邏輯比較復雜的功能，產品最好還是提前介入會好一些；這樣可以及時發現問題，避免到后期因為人力或者工期或者溝通問題造成項目延期。

本文由 @七月專欄 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于 CC0 協議