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

產(chǎn)品戰(zhàn)略包含產(chǎn)品用戶選擇、產(chǎn)品定位以及產(chǎn)品路線，而產(chǎn)品戰(zhàn)術(shù)管理主要有五大方面的內(nèi)容：范圍管理（需求管理）、進度管理、質(zhì)量管理、技術(shù)管理、文檔管理。

一、需求管理

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

• 需求收集：產(chǎn)品經(jīng)理和公司領(lǐng)導及業(yè)務方對業(yè)務目標達成統(tǒng)一；
• 需求分析：產(chǎn)品經(jīng)理和業(yè)務方及技術(shù)經(jīng)理對技術(shù)目標達成統(tǒng)一；
• 需求確定：產(chǎn)品經(jīng)理和研發(fā)人員及測試人員對細節(jié)交互達成統(tǒng)一；
• 需求評審：所有相關(guān)方對產(chǎn)品需求的五個共識達成統(tǒng)一；
• 需求推進：研發(fā)團隊和測試團隊按期完成產(chǎn)品功能的研發(fā)和交付；
• 需求變更：產(chǎn)品經(jīng)理按照業(yè)務方及公司領(lǐng)導的變化要求協(xié)調(diào)研發(fā)團隊達成需求變化的調(diào)整。

在這里重點討論一下需求分析、需求評審和需求變更這三個主要環(huán)節(jié)。

需求分析：

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

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

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

需求評審：

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

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

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

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

需求變更：

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

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

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

二、進度管理

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

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

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

六大過程：

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

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

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

計劃變更：

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

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

自身評估有偏差。

網(wǎng)絡上流行一個計劃評估的段子，一個剛?cè)胄械某绦騿T評估需要1天，一個三年工作經(jīng)驗的程序員評估需要3天，一個架構(gòu)師評估需要1周，這個評估結(jié)果不應該倒過來嗎？NO!一般是實際結(jié)果倒過來，是不是很有意思。因為自己主觀原因?qū)е马椖坑媱澬枰兏?，在領(lǐng)導或客戶那里往往通不過，實在完成不了需要變更，那就等著扣績效、扣項目款吧。-_-||
領(lǐng)導或客戶要求和資源不匹配。

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

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

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

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

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

三、技術(shù)和質(zhì)量

一個好的產(chǎn)品經(jīng)理能夠成就一個好產(chǎn)品，但是一個使用不當?shù)募夹g(shù)也可以毀掉一個產(chǎn)品，所以在產(chǎn)品戰(zhàn)術(shù)管理中，我們要重視技術(shù)管理和質(zhì)量管理，一個攻一個防，共同把產(chǎn)品具體落地。

1. 技術(shù)管理

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

• 技術(shù)選型。
• 架構(gòu)設計。
• 開發(fā)規(guī)范。
• 代碼審查。
• 技術(shù)攻關(guān)（特別是對于具有技術(shù)壁壘的產(chǎn)品）。

2. 質(zhì)量管理

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

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

要將質(zhì)量意識滲入到骨子里。

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

質(zhì)量不僅僅是測試團隊的責任，是產(chǎn)品研發(fā)團隊所有人的責任，每個人都要參與到產(chǎn)品的質(zhì)量和測試中來。

建立質(zhì)量管理體系。

*后面我會針對產(chǎn)品研發(fā)過程中的技術(shù)管理和質(zhì)量管理部分再詳細介紹，在此不再贅述！

四、文檔管理

產(chǎn)品研發(fā)過程很重要，但這個過程進展的程度，產(chǎn)生的成果如何體現(xiàn)呢？

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

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

哪些文檔：

產(chǎn)品研發(fā)過程中的文檔主要包含產(chǎn)品文檔（PD）、技術(shù)文檔（TD）和管理文檔（MD）三大類，包括：

• PD.市場/業(yè)務需求文檔–新產(chǎn)品初期（業(yè)務分析、市場調(diào)研、產(chǎn)品規(guī)劃）
• PD.產(chǎn)品需求文檔（需求分析文檔、產(chǎn)品原型）

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

協(xié)作>存儲

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

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

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

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

五、總結(jié)

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

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

#專欄作家#

菜根老譚，微信公眾號：CGLT_TAN，人人都是產(chǎn)品經(jīng)理專欄作家。經(jīng)歷程序員、技術(shù)Leader、產(chǎn)品經(jīng)理、研發(fā)Leader等多種崗位?，F(xiàn)負責某科技公司整體產(chǎn)品研發(fā)，擅長企業(yè)IT架構(gòu)及互聯(lián)網(wǎng)產(chǎn)品架構(gòu)。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議