產品戰術可以簡化，但要保持順暢

導語：如果產品戰略是為產品發展指明方向，那么產品戰術就是有效地實現既定產品戰略的原則和方法。產品戰略與產品戰術關系緊密，相輔相成，缺一不可；本文作者分享了關于產品戰術的分析，我們一起來了解一下。

產品戰略包含產品用戶選擇、產品定位以及產品路線，而產品戰術管理主要有五大方面的內容：范圍管理（需求管理）、進度管理、質量管理、技術管理、文檔管理。

一、需求管理

用戶所有的需求都是合理的，但我們的資源是有限的，所以我們需要對用戶提出的需求進行管理，能夠弄明白哪些是不應該做的，哪些是應該優先做的，而還有些是要提前創造條件去做的。需求管理有一套完整的全生命周期，大概可以分為以下6個關鍵點：

• 需求收集：產品經理和公司領導及業務方對業務目標達成統一；
• 需求分析：產品經理和業務方及技術經理對技術目標達成統一；
• 需求確定：產品經理和研發人員及測試人員對細節交互達成統一；
• 需求評審：所有相關方對產品需求的五個共識達成統一；
• 需求推進：研發團隊和測試團隊按期完成產品功能的研發和交付；
• 需求變更：產品經理按照業務方及公司領導的變化要求協調研發團隊達成需求變化的調整。

在這里重點討論一下需求分析、需求評審和需求變更這三個主要環節。

需求分析：

產品跑得快，全靠需求帶，可見需求的重要性。甚至可以說產品其實就是需求被滿足的外在表現，需求是因，產品是果。需求收集，不論是來自用戶真實反饋，還是客戶的極度要求，更或是老板的個人愿望，這些需求真實存在，但卻不能直接構成指導產品開發的需求定義，因為我們需要對需求進行分析，辨其真偽，去其糟粕，需要升華。

我曾經寫過一篇文章：《他們是提需求的，不是做產品的》，也分析過我們做產品，特別是需求分析過程中的一些問題，很多產品人員不清楚需求分析到底分析什么！下圖是需求分析的維度，希望給大家一點啟示。

參考文章：《需求分析，需要有層次的分析》

需求評審：

需求評審是各方對需求進行確認的過程，達成統一認知和共識，使需求能夠推進實現落地。在需求評審的過程中，一定要說明清楚需求的背景、價值、意義，而不是純粹的需求講解，這樣有助于各方對需求的理解。

廣義的需求評審是讓相關方對產品需求的業務目標、技術方案、交互細節、需求責任人、排期計劃的五個層面達成共識。一般情況下，在我們內部我們會把這五個層面的共識拆分成需求評審和技術評審兩個階段完成，技術方案和排期計劃放到技術評審環節，以保證在確定的需求范圍下得出更合理的結論。

對于新項目或者大版本升級，設計需求范圍廣，功能比較多，建議需求評審多次溝通，已達到全面正確無誤了解，如下圖所示：

對于小范圍的需求評審，可以合并簡化過程，以提升效率。如果產品需求在方向和價值上存在巨大爭議和分歧，轉入到產品決策流程！

需求變更：

我常常在團隊內強調：我們擁抱變化，但又要控制變化。有變化才有活力，才有生命力，所以擁抱變化，擁抱創新。但是作為產品研發的過程我們有需要控制風險，而不確定性是風險的一種主要來源，所以需求變化不加以控制就會存在不確定性的風險。

需求變更制度是產品研發過程中不可缺少的制度，首先我們要定義需求變更的原因（比如新需求的加塞、業務不穩定導致、需求本身出現偏差等），同時對需求變更類型進行定義（比如功能需求變更、體驗需求變更、數據需求變更、業務規則變更等），這些會造成需求變更的成本不同，影響程度不同，同時是指導我們決定要不要變更，如何變更的重要依據。

建立好這些需求變更的規則和邏輯，最后確定需求變更的流程（如下圖），通過友好的協商、評估將需求變化進行控制，以保證產品研發過程的順利推進。

二、進度管理

大部分的情況下，需要產品經理具備項目管理的能力。也就是要把每一條產品線的每一個版本的整體進度都把控起來，讓版本能夠在計劃的時間段內順利上線。那是不是產品經理其實就充當了項目經理的角色了呢？

在一個敏捷的產品開發團隊，產品經理完全可以承擔項目經理的角色，因為敏捷團隊的項目管理相對比較簡單，而且團隊已經形成了固定的迭代節奏，工作的開展就像已經設計好的程序一樣自動的執行。這個時候只需要一個技術經理與其配合，一個把控產品進度，一個把控產品質量。老譚在之前負責一個互聯網產品團隊時，基本上是這樣的狀態。

但是在一個沒有迭代節奏的研發團隊，或者產品0-1的過程中，或者完全基于客戶需求導向的項目開發團隊，產品經理就不適宜承擔項目經理角色，因為項目周期長，需要投入項目管理的精力太多；而且項目的干系人也更多更復雜，需要有協調能力的人來處理；最主要的是項目的主要目標是交付，而產品的主要目標是產出，有時候二者存在難以調和的矛盾，過于產品化就可能會影響交付，過于考慮客戶交付，產品化程度就會被削弱，或者被延遲。

六大過程：

在一個以外部項目為主的公司，可能會有專職的項目經理的角色來主要承擔項目經理角色。而內部的項目團隊，一般由研發團隊或者開發團隊委派項目經理來負責。

在一個復雜的項目中，項目管理特別是進度管理是一件非常有技術含量的管理工作，需要很多的方法和工具，同時又需要人文和情商，有時候在一些大型項目中會看到雙項目經理存在，一個主外（偏商務），一個主內（偏工程）。以下列舉了項目進度管理的六個核心過程以及用到的方法和工具。

• 活動定義： 分解、模板、滾動波式計劃、專家判斷、規劃組成部分；
• 活動排序： 前導圖法（單代號）、箭線圖法（雙代號）、計劃網絡模板、確定依賴關系、提前與滯后；
• 活動資源估算：專家判斷、多方案分析、出版的估算數據、項目管理軟件、自下而上估算；
• 活動歷時估算： 專家判斷、類比估算、參數估算、三點估算、后備分析；
• 制定進度表： 進度網絡分析、關鍵路徑法、進度壓縮、假設情景分析、資源平衡、關鍵鏈法、項目管理軟件、應用日歷、提前與滯后、進度模型；
• 進度控制： 進度報告、進度變更控制系統、績效衡量、項目管理軟件、偏差分析、進度比較橫道圖、資源平衡、進度壓縮、假設情景分析、制定進度的工具。

計劃變更：

在筆者的從業經歷中發現，項目沒有按照最初始的計劃執行的十有八九，延期的項目更是遠多于提前完成的項目，我相信這對于很多做過項目管理的人來說也是司空見慣的。

究其原因主要有以下幾個方面：

自身評估有偏差。

網絡上流行一個計劃評估的段子，一個剛入行的程序員評估需要1天，一個三年工作經驗的程序員評估需要3天，一個架構師評估需要1周，這個評估結果不應該倒過來嗎？NO!一般是實際結果倒過來，是不是很有意思。因為自己主觀原因導致項目計劃需要變更，在領導或客戶那里往往通不過，實在完成不了需要變更，那就等著扣績效、扣項目款吧。-_-||
領導或客戶要求和資源不匹配。

領導和客戶往往對于項目進度是有期望或者有要求的，但是對于項目組來說，在項目范圍、時間不變的情況下，只能通過增加資源和成本才能保證。解決不了資源問題，計劃就很難按時完成。
項目范圍有變化。

般來講指假設其他要素不變，項目范圍越大，項目所要完成的任務越多，項目耗時越長；反過來，項目范圍越少，項目所要完成的任務越少，項目耗時越短。如果過程中擴大了項目范圍，如果可以同步增加資源，可以保持進度不變，如果解決不了資源問題，就只能變更項目計劃。
項目需求有變化。

雖然在項目前期我們采取了需求用戶確認和原型法等辦法控制系統范圍和客戶需求。但還是在系統開發過程中甚至是測試工作完成即將上線時，客戶還是提出了新的需求或者對原有需求進行調整，雖然沒有顯性的擴大項目范圍，但新需求以及需求變更都會帶來相應的工作量，甚至有的需求變化對于底層都有嚴重的影響，這也導致項目計劃需要變更。

在項目實施過程中，項目組要經常關注與項目相關的主客觀因素，及時發現和把握變化，認真分析變化的性質，確定變化的影響，適時進行變化描述。當變化了的各種因素影響到了項目的順利實施時，項目組織必須及時進行計劃變更，以確保項目目標的實現。

項目計劃的變更應征得項目主體的同意，項目組織還應及時向其反饋變更及變更執行情況。‍下圖是我們研發團隊內部的變更申請單，只要合理的變更我們基本上都不設障礙，但需要讓相關人員都要知曉，避免項目的混亂。

三、技術和質量

一個好的產品經理能夠成就一個好產品，但是一個使用不當的技術也可以毀掉一個產品，所以在產品戰術管理中，我們要重視技術管理和質量管理，一個攻一個防，共同把產品具體落地。

1. 技術管理

一般情況下，技術管理主要是組織級的，由CTO等同類崗位的人來負責，但是對于產品研發來說，不同的產品對于技術的需求也是不同的，企業級的產品和互聯網的產品對技術的選擇存在很大的差異。產品管理人員有很多是不懂技術的，而產品的成功又依賴技術，所以產品一定要和技術團隊緊密協同，更好的為產品的發展負責。那么技術管理主要包含哪些內容呢？

• 技術選型。
• 架構設計。
• 開發規范。
• 代碼審查。
• 技術攻關（特別是對于具有技術壁壘的產品）。

2. 質量管理

每個企業都“重視”質量，但很多企業都在測試環節、質量管理方面投入不夠，畢竟測試團隊和質量團隊無法直接產生生產力，往往我們在質量和成本之間平衡的時候，一不小心就變成了犧牲品。

真正做好質量管理，希望團隊要從以下幾個方面進行重視：

要將質量意識滲入到骨子里。

海爾張瑞敏砸冰箱砸醒海爾人的質量意識，三星李鍵熙焚毀三星產品燒出一個三星帝國。所以企業領導人、產品負責人要從意識和行動上重視質量，而不是喊著口號，打著算盤。
重視測試團隊、建立測試流程。

質量不僅僅是測試團隊的責任，是產品研發團隊所有人的責任，每個人都要參與到產品的質量和測試中來。

建立質量管理體系。

*后面我會針對產品研發過程中的技術管理和質量管理部分再詳細介紹，在此不再贅述！

四、文檔管理

產品研發過程很重要，但這個過程進展的程度，產生的成果如何體現呢？

• 產品本身即是最大的成果物；
• 產品的代碼是真正的資產；
• 過程中產生的必要的文檔是支撐產品長期發展的知識積累。

由于生產文檔并不是產品的目標，而是管理的行為，而生產文檔本身也會帶來額外的成本，很多公司特別是小公司是不太重視文檔的編寫和管理的。但是站在一個長生命周期來看的話，沒有文檔的積累，到了后期對于產品研發就是一場噩夢。

哪些文檔：

產品研發過程中的文檔主要包含產品文檔（PD）、技術文檔（TD）和管理文檔（MD）三大類，包括：

• PD.市場/業務需求文檔–新產品初期（業務分析、市場調研、產品規劃）
• PD.產品需求文檔（需求分析文檔、產品原型）

• TD.技術方案文檔（概要設計，詳細設計）
• MD.測試用例文檔
• MD.WBS工作計劃
• MD.各種評審文檔（需求評審單、技術評審單、發布評審單等）

協作>存儲

過去我們寫了很多的文檔，但是回過頭來想想，這些文檔一旦進入到文檔庫中，我們還會再去翻看它嗎？對于后來人，這些文檔是否又真的能派上用場？

過去我是反對把文檔單獨存放在離我們開發太遠的地方，更提倡文檔在git上，或者研發管理系統上都可以，這是我們經常用的工具，只有放在這些地方我們才能像看代碼一樣去翻看他們。另外，文檔盡量不要碎片化，一個技術文檔由于階段不同，參與的人不同，結果寫了十幾個文檔，不僅重復內容多，而且內容關聯性差，很難讓人去閱讀理解，逐步的就變成了擺設。

去年公司購買了石墨文檔，石墨文檔的核心精神不是存儲而是協作，而產品研發恰恰就是一個高度協作的活動，這樣就方便產品研發團隊共同的編寫的方案，有利于知識的共享和體系化。

所以讓文檔活起來，而不是死掉是文檔管理的核心思維！

五、總結

通過上圖可以看出產品研發是一個復雜的、多組織多崗位高度協作的企業活動；不論是大團隊還是小團隊，是大項目還是小項目，沒有規矩不成方圓，大有IPD的研發體系，小也有敏捷的研發體系，但不論是哪個研發體系，都沒必要照搬照抄。

只要保證過程的完整性，我們都可以根據自身實際情況裁剪簡化，既能指導我們產品研發有序進行，又不會成為過程中的累贅。

#專欄作家#

菜根老譚，微信公眾號：CGLT_TAN，人人都是產品經理專欄作家。經歷程序員、技術Leader、產品經理、研發Leader等多種崗位。現負責某科技公司整體產品研發，擅長企業IT架構及互聯網產品架構。

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

題圖來自Unsplash，基于CC0協議