編輯導語：作為產(chǎn)品經(jīng)理遇到的問題可謂是各式各樣的，日常需要處理的問題也很繁多，本篇文章作者針對產(chǎn)品經(jīng)理日常遇到的問題進行案例分析，講述了產(chǎn)品經(jīng)理應如何正確參與并引導開發(fā)評估的內(nèi)容，一起來學習一下吧。

作為產(chǎn)品經(jīng)理，你是否遇到過以下問題：

• 開發(fā)出來的功能和設(shè)計的規(guī)則不一致；
• 看起來很簡單的功能開發(fā)評估需要好幾天；
• 負責的項目經(jīng)常延期；
• 不知道開發(fā)進展。

如果出現(xiàn)以上問題，80%是因為開發(fā)評估工作沒有做好。

這篇文章將會結(jié)合筆者的實際案例，詳細講解如何解決上述問題。

注：本文討論的內(nèi)容基于特定的情況下，即團隊中沒有專職的項目經(jīng)理/敏捷教練，需要產(chǎn)品經(jīng)理兼任，即“保姆式產(chǎn)品經(jīng)理”，同時產(chǎn)品經(jīng)理的設(shè)計方案已通過評審。

一、產(chǎn)品經(jīng)理在開發(fā)評估會議中的定位

在中小企業(yè)，特別是以敏捷開發(fā)為主的團隊中，產(chǎn)品經(jīng)理往往需要承擔一部分項目管理的職責。

其中最重要的要屬需求評審后的開發(fā)評估工作了（若需求較簡單，可與評審會共同進行）。

在評估會議上，開發(fā)團隊會對本期需求制定實現(xiàn)方案，并會根據(jù)方案的難易程度評估具體每個開發(fā)活動的開發(fā)時間。

因為評估會議代表整個開發(fā)工作的起點，只要評估得準確，那么后續(xù)按照計劃執(zhí)行即可，能夠減少很多風險。

可是現(xiàn)實情況卻不盡人意，常常會遇到：

• 開發(fā)對功能規(guī)則理解有偏差；
• 需求遺漏或需求蔓延；
• 評估的工時和實際所用的工時差距過大。

并且這類問題往往在開發(fā)后期才會暴露出來，輕則導致改動方案，費時費力；重則導致項目延期，影響整體目標。

千萬不要認為開發(fā)評估會是開發(fā)的主場，作為產(chǎn)品經(jīng)理，需要對產(chǎn)品的結(jié)果負責，對于任何環(huán)節(jié)可能造成的風險都需要提前規(guī)避。

因此，在評估會上，產(chǎn)品經(jīng)理不僅要做一個“傾聽者”（了解技術(shù)實現(xiàn)方案）和“支持者”（對于開發(fā)不明確的地方提供必要的說明），更要做一個“引導者”。

雖不參與實際的開發(fā)決策，但需要在關(guān)鍵節(jié)點通過正確地引導保證評估過程的準確性。

這種積極的做法有以下好處：

• 降低項目開發(fā)風險；
• 建立與開發(fā)的信任；
• 從技術(shù)視角看待產(chǎn)品，了解開發(fā)知識；
• 鍛煉領(lǐng)導力。

下文將會從會議前（準備）、會議中（引導）、會議后（監(jiān)控）詳細拆解每個步驟。

二、會議前

1. 對本期需求拆解詳細的WBS

盡管經(jīng)過需求評審會，團隊成員已經(jīng)對設(shè)計方案達成了共識，但仍不能保證每個人都記住和理解。

因此在開發(fā)評估會前，還需要通過一種結(jié)構(gòu)化的方式全局呈現(xiàn)需求，這種方式就是WBS（工作分解結(jié)構(gòu)），也可以理解為詳細的功能列表。

對于產(chǎn)品經(jīng)理，功能列表肯定不會陌生，在需求之后原型之前，我們就會通過功能列表梳理產(chǎn)品結(jié)構(gòu)。

但此處的功能列表則需要拆解的越詳細越好，因為它是給開發(fā)看的，便于他們對要做之事有一個整體的了解。

同時又可以避免需求遺漏、蔓延和理解不一致的情況出現(xiàn)。如同去菜市場買菜，相比于提前列出購買清單，如果是到了菜市場才決定買什么，那大概率會多買或少買。

這里我用曾經(jīng)做過的在線答題功能舉例：

可以看到，給產(chǎn)品經(jīng)理自己看的功能列表會相對簡單一些，只需寫出大致的功能架構(gòu)，為后續(xù)的原型設(shè)計提供指引。

而給開發(fā)看的WBS則需要遵循MECE原則，將各功能分解地很詳細，并且需要把重要的規(guī)則補充完整，這樣有助于開發(fā)進行評估。

比如對于“切換題目”功能，如果不寫出“切換時需要自動保存答案”這一規(guī)則，前端人員僅看功能列表時就會忘記調(diào)用保存接口。

這里可能你會有不解：PRD也有詳細的功能規(guī)則，為什么不用，而是要重新做一個WBS？

這是由于兩者的形式?jīng)Q定的，WBS相比PRD最大的優(yōu)勢就是“直接”和“結(jié)構(gòu)化”。

從下圖可以看到，PRD文檔包含了很多內(nèi)容，產(chǎn)品經(jīng)理自己寫都需要花很久，開發(fā)同樣需要花很長時間閱讀（現(xiàn)實中更多的情況是開發(fā)不看文檔，遇到問題了再問）。

其次文檔形式不便于直觀地看出各功能的層級結(jié)構(gòu)，難以形成前后聯(lián)系。

而WBS是將PRD中最重要的“功能需求”拿出來，并細化到最小功能點，做到了需求不遺漏，方便開發(fā)做后續(xù)的活動拆分（下文會說明）。

同時產(chǎn)品的架構(gòu)、各功能之間的聯(lián)系和關(guān)鍵規(guī)則都在一張表里展示出來，大大提高了閱讀效率。

2. 提前安排開發(fā)負責人制定初步開發(fā)方案

會議是決策，而不是討論。

我們回想一下開需求評審會的場景，經(jīng)常有開發(fā)對我們的設(shè)計方案提出質(zhì)疑。

如果恰好是你沒考慮清楚，那么你會選擇跟他深入討論，還是會說“這個問題問得好，我記下來了，會后我再好好想想然后答復你，我們先看下一項？”

我相信大家都會選擇后面的方式，因為在會上討論，不僅浪費他人的時間，而且討論出的結(jié)果往往都是沒有經(jīng)過深思熟慮的。

開發(fā)評估會也是同樣的道理，當面對較復雜的設(shè)計方案時，作為“引導者”，要避免開發(fā)在會上就某個需求的實現(xiàn)方案進行討論。

一個切實可行的做法是在會前，同相關(guān)負責人直接溝通，請他們提供一個或多個初步方案，再拿到會上由全體開發(fā)進行決策。

例如我在設(shè)計閱卷規(guī)則時，不僅可按考生、試卷、題目分配，還可按試卷和考生、題目和考生綜合分配。

同時試卷類型還包括選題組卷、抽題組卷和隨機組卷，題目中還包含復合題，這都增加了開發(fā)在設(shè)計閱卷模型時的難度，可能還會改動已有的題庫——試卷模型。

顯然，這么復雜的方案不適合在會上討論，于是我先后跟前后端負責人約了幾次會議，形成了一個初步的方案。

這樣做不僅保證了實現(xiàn)方案的完備性（作為負責人，經(jīng)驗和眼界都會高一些），同時減少了溝通成本（溝通渠道=N（N-1）/2，N指參與溝通者的人數(shù)）。

接下來再開評估會議，有了開發(fā)負責人的背書，就會順利很多。

3. 促使信息對齊

經(jīng)過前面的兩步，你已經(jīng)為評估會做好了資源上的準備，接下來你可能會把WBS、PRD、設(shè)計圖、開發(fā)負責人提供的初步方案打包發(fā)給團隊成員。

然后信心滿滿的準備開會。可是事與愿違，在會上你會發(fā)現(xiàn)，由于每個人所站的角度不同、高度不同，仍然有部分成員因為理解不一致而進行無效討論。

因此在這個步驟里，主要目標是解決成員間信息不對稱的問題。

這里我提供一個經(jīng)過實踐驗證的、確保大家信息對齊的方案，可以用到各種會議中去，也可以根據(jù)實際情況進行調(diào)整：

• 將所有資料和解釋說明通過釘釘打包發(fā)給相關(guān)團隊成員，并督促未查看的成員查看；
• 在會議前1天，要求各成員針對會議資料必須給出反饋意見（無意見也要寫明），并收集留檔；
• 提前解答大家共同反饋的疑問；
• 在會議開始前，準備紙質(zhì)版資料，最少要能保證3人共用一份；
• 若會議前臨時有人員變動，或前期準備時間不充足，可在會前加入靜默閱讀的方式。

需要注意的是，心理學上有一個常見的現(xiàn)象——基本歸因錯誤，即當我們對一個結(jié)果做因果分析時，往往會將原因歸咎于傾向性因素（人格或態(tài)度等內(nèi)在特質(zhì)），而忽略外部環(huán)境的影響。

但其實環(huán)境才是影響人們行為的最重要的因素。

例如，如果你面對“仍然有部分開發(fā)成員因為不清楚需求而進行無效討論”的情況，是不是第一反應是這個開發(fā)不認真、不主動。

但不妨換個角度想想，其實是目前的一種工作流程造成了他還不清楚需求。

人是制度的產(chǎn)物，改變?nèi)瞬蝗绺淖冎贫群土鞒?，所以以上我提供的方法都是基于改變流程這一維度。

想更深入的了解這一心理現(xiàn)象，可查看我的另一篇文章《指責他人是愚蠢之舉》。

三、會議中

經(jīng)過了會議前三步的準備，團隊成員對需求范圍、設(shè)計方案以及初步開發(fā)方案都有了較深入的理解，接下來就進入到了正式開會環(huán)節(jié)。

前文說了開發(fā)評估會議是開發(fā)團隊對本期需求制定實現(xiàn)方案，并根據(jù)方案的難易程度評估每個開發(fā)活動的具體時間。

后續(xù)開發(fā)過程是否順利，是否能夠按時按量完成，都會受會議中產(chǎn)出的結(jié)果影響，因此重要性不言而喻。

在開發(fā)評估會議中，主要包括三個環(huán)節(jié)：

• ①確定開發(fā)方案；
• ②分解開發(fā)活動；
• ③評估活動時間。

當需求較簡單或開發(fā)方案沒有爭議時，可以跳過①環(huán)節(jié)，所以下文基于開發(fā)方案已確定的情況，主要對②③兩個環(huán)節(jié)進行展開。

1. 引導開發(fā)正確分解開發(fā)活動

“分解”是產(chǎn)品經(jīng)理必備的一種思維，上到業(yè)務目標，下到產(chǎn)品功能都需要分解成可執(zhí)行的最小單位，開發(fā)評估工作亦是如此。

倘若你的團隊沒有這種“分解”意識，直接根據(jù)功能或頁面進行評估，比如“下發(fā)試卷”功能：“需求是時間到后把試卷發(fā)給每一個考生，看起來比較簡單，就估1人/天吧”。

但實際在開發(fā)的時候才會發(fā)現(xiàn)，之前沒有考慮下發(fā)隨機組卷這種類型的試卷，也沒有考慮上萬人同時發(fā)卷的并發(fā)問題，導致按照之前評估的時間完不成，進而導致延期。

要想解決這一問題，要從思想上轉(zhuǎn)換：

功能是設(shè)計方案可分解的最小單位，而開發(fā)方案的最小單位是一個個的接口。

因此在評估前要做一件事：建立設(shè)計方案和開發(fā)方案之間的聯(lián)系，這就需要在前面的步驟中我們已經(jīng)做好的WBS。

還是拿“在線答題”功能舉例：

雖然WBS已經(jīng)把功能分解并按層級羅列了出來，但從開發(fā)的角度看還比較籠統(tǒng)，不能直接用于評估。

此時要引導開發(fā)繼續(xù)分解到接口層面：

• 對設(shè)計方案做整體介紹；
• 帶領(lǐng)開發(fā)對WBS中的每個功能/功能組梳理邏輯；
• 引導開發(fā)利用MECE原則列出所用后端接口；
• 討論接口細節(jié)；
• 確定前后端開發(fā)活動（任務）。

如果前期的準備工作做的充分，這個過程會進行得很順利，因為大家有共同的認知，容易達成一致意見。

允許對細節(jié)方案短暫討論，比如對于倒計時提醒，可以采用后端提供服務器時間，前端定時校準并計算倒計時，也可以直接由后端計算。

但是涉及到模型建立、表結(jié)構(gòu)設(shè)計、技術(shù)選型這類方案的討論，還是需要在會前決定好。

2. 引導開發(fā)準確評估活動時間

分解好開發(fā)活動后，接下來就要對每個開發(fā)活動估算時間。

大家可以回顧一下在自己的項目中開發(fā)人員是怎么做評估的，我見過很多團隊，基本上都是采用開發(fā)負責人拍腦袋的方式進行估算。

這樣做會出現(xiàn)兩個問題：

1. 僅靠個別人員評估，可能造成評估不全面。例如試卷已生成，此時再改題庫中的題目是不會影響試卷的，因此往試卷中添加題目時，需要存入題目的副本，對于這種細節(jié)單靠個別人員評估很容易遺忘。
2. 評估人員和實際開發(fā)人員不一致，可能造成實際工時的偏差。開發(fā)負責人是基于自己的經(jīng)驗去評估的，沒有考慮實際開發(fā)人員的情況。

因此要想準確評估開發(fā)活動的時間，全體參與是必須的。但全體參與又會帶來另外兩個問題：

1. 因為每個人的經(jīng)驗不同、理解不同，如何就活動時間達成一致？
2. 如何避免“從眾效應”，導致估時不準？

這里我提供一個高效率進行群體決策的工具——估算撲克，產(chǎn)品經(jīng)理可以用其引導開發(fā)準確評估時間。

1）什么是估算撲克

估算撲克是一種迅速而精準地進行評估和規(guī)劃的工具。

和普通撲克牌一樣，也是由54張牌組成，兩張大小王分別用中英文描述了使用規(guī)則，剩下52張牌分為4組，可供4人使用，每人13張，由11張數(shù)列牌、1張“？”牌和1張“咖啡”牌組成。

“？”代表無法準確評估，“咖啡”牌代表要休息了。

數(shù)列牌可以是自然數(shù)排列（0-10），也可以是修正后的斐波納契數(shù)列（如上圖），其中0代表非常簡單，不需要精力就能完成。

2）數(shù)列的含義

撲克上的數(shù)字可以代表“工時”，也可以代表“故事點”（敏捷開發(fā)）。

代表工時很好理解，即估計每個開發(fā)活動需要花費的小時數(shù)（允許組合，如1+1/2=1.5h），是目前使用范圍最廣的方式。

但這樣做會有一個問題：每個人做一項任務所花費的時間都是根據(jù)自身情況決定的，比如挖一個10m3的坑，你需要用1小時，而一個小學生需要用8小時。

所以要如何評估挖10m3的坑所用的時間才合理呢？如果估1小時，顯然對小學生來說不可能完成，如果估8小時，對你來說就是浪費時間。

我們無法讓能力不同的人，就同一份工作的耗時達成一致，但可以做到對工作量大小的估算保持一致。

什么意思呢，不管誰來做這個工作，它的工作量、復雜度、風險都在那里，不增不減，因此可以轉(zhuǎn)而評估工作總量。

評估前需要定義一個單位工作量——故事點，比如我們事先定義挖1m3的坑為1個故事點，那么對于10m3的坑就是10個故事點，

實際中，可根據(jù)團隊情況選取數(shù)列表示的含義，也可并行估算。

3）估算工時步驟

1. 分牌：為每名參與估算的成員分一組牌（13張）；
2. 講解：產(chǎn)品經(jīng)理為大家講解需求并答疑（若在上一步驟中已經(jīng)詳細講解，本步驟可以省去）；
3. 估算：僅與該活動有關(guān)的開發(fā)成員估算工時，如針對“交卷”接口，由全部后端評估工時。
   待每個成員選好牌后同時展示出來，估算過程不可互相商討；
4. 若大家的估算結(jié)果相近（相差的數(shù)值牌不超過2張），取平均值；
5. 若差異較大，需要讓估算最大和最小的成員分別闡述自己的理由，大家溝通后重新進行估算。
6. 記錄估算結(jié)果

注： 一個完整的開發(fā)過程還涉及前后端聯(lián)調(diào)，可以拆成單獨的活動再由前后端成員共同評估。

同時由于工時評估關(guān)注細節(jié)——各活動已是分解的最小結(jié)果，工時不會太久，建議使用0-10的數(shù)列進行評估。

4）估算故事點步驟

由于故事點指的是工作總量，單獨對任意一個前后端任務評估都不完整，且不好統(tǒng)一定義單位故事點。‘

因此基于故事點估算的步驟會與工時估算稍有不同，主要提現(xiàn)在評估對象不同和確定單位故事點。

（1）關(guān)于評估對象

故事點代表了一個最小的、完整的功能所需的所有工作量，一個交卷接口不算完整。

一個涉及到前后端的交卷功能才算完整（這不代表前面的分解活動沒有用，恰恰是因為分解，才使得估算更準確）。

所以故事點的評估對象是一個完整的功能（用戶故事），同時在評估時還要考慮影響該工作量的所有因素，包括開發(fā)、聯(lián)調(diào)、風險點等。

（2）關(guān)于確定單位故事點

如果是剛剛建立的新團隊，在進行估算前，還需要尋找一個標的，建議團隊選取一個簡單的功能閉環(huán)代表1個單位故事點，并要達成共識。

例如把交卷功能作為1個故事點，在估算“保存”功能時，若開發(fā)認為“保存”功能的開發(fā)任務量、復雜度、風險和不確定性預計是“交卷”功能的3倍。

那么“保存”功能就應該為3個故事點。另外在以后的每次估算中，最好使用同樣的單位故事點，這樣有助于評估和提升整個團隊的生產(chǎn)能力。

按故事點估算步驟可分為：

1. 1. 確定單位故事點；
   2. 分牌；
   3. 講解；
   4. 多次估算：僅與該功能有關(guān)的開發(fā)成員進行估算，如
      針對“交卷”功能，由前后端成員共同評估，并對故事的點數(shù)達成一致；
   5. 記錄估算結(jié)果。

將所有功能評估完后，就可以得出總的故事點數(shù)，新團隊在第一個開發(fā)周期可以先不用考慮完成率，盡量做。

在周期結(jié)束后統(tǒng)計做完了多少個故事點即可，再通過兩三個周期的調(diào)整和適應，我們就可以較準確地評估出團隊整體的生產(chǎn)力和個人的生產(chǎn)力，為后續(xù)改進提供依據(jù)。

5）并行估算

根據(jù)前面的介紹，不難看出故事點估算側(cè)重于對整體的評估，關(guān)注結(jié)果，而工時估算側(cè)重于對細節(jié)的評估，關(guān)注過程，兩種估算方式互為補充，可以同時進行：

1. 1. 確定單位故事點；
   2. 分牌；
   3. 講解；
   4. 針對功能（故事）估算故事點數(shù)；
   5. 針對具體開發(fā)活動估算工時；
   6. 記錄估算結(jié)果；。

3. 開發(fā)活動分配和篩選

到了這一步，我們已經(jīng)拿到了每個開發(fā)活動/功能較準確的評估。

接下來就是由開發(fā)負責人將這些任務合理地分配給各成員，成員也可以主動認領(lǐng)，產(chǎn)品經(jīng)理無需干涉這一過程。

如果按工時估算，一般會給每個成員分配的活動時間占總工時的80%（每人每周安排32小時），剩下的時間留作應急。

如果采用的是故事點估算，會參考前幾次已完成的總故事點數(shù)。

不管是采用哪種估算方式，都可能會遇到所排需求超出團隊周期內(nèi)的最大工作量，此時就需要產(chǎn)品經(jīng)理根據(jù)需求的優(yōu)先級和關(guān)聯(lián)性判斷哪些需求可以移入下一個周期。

4. 會議通用

1）把控會議進度

• 控制會議整體時間：一次會議最好不要超過90分鐘，若需求過多，可拆分為多次會議；
• 控制會議各環(huán)節(jié)時間：拆解開發(fā)活動時可能會遇到無法達成一致的情況，要及時引導大家轉(zhuǎn)入下一個議題，會后相關(guān)人員再對未決議問題展開討論，避免浪費所有人時間；
• 控制討論內(nèi)容：開會時很容易討論著討論著就跑偏了，需要及時制止這種情況并把話題帶回來。

2）做好會議記錄

安排人員記錄會議過程中的確認事項、待辦事項，并整理產(chǎn)出文檔。

四、會議后

1. 跟蹤遺留問題

如果記錄了一些待辦事項，會后要組織相關(guān)人員進行落實，做到事事有結(jié)果。

2. 跟進開發(fā)過程

如果團隊中沒有項目經(jīng)理，那么項目跟進的工作就需要由產(chǎn)品經(jīng)理負責。

通過前面的評估會，我們可以得到已經(jīng)確認的開發(fā)活動、開發(fā)時間和開發(fā)人員，接下來就需要把這些內(nèi)容做成可視化的圖表，便于跟蹤和查看，目前常用的有甘特圖和項目看板。

甘特圖適用于：

• 基于工時的估算方式；
• 瀑布式開發(fā)模式；
• 無固定開發(fā)周期；
• 需求較多且不容易變更。

看板適用于：

• 基于故事點的估算方式；
• 敏捷型開發(fā)模式；
• 有固定開發(fā)周期；
• 需求多變。

在項目進行過程中，產(chǎn)品經(jīng)理需要每天檢查并更新活動進度，這樣可以及時發(fā)現(xiàn)偏離情況：

• 盡管經(jīng)過細致的分解和科學的評估，仍然不能保證活動評估時間與實際完全一致，這里面包含內(nèi)部原因（遇到技術(shù)難題、評估時忽略了細節(jié)等）和外部原因（疫情隔離等），如果會導致進度延期，產(chǎn)品經(jīng)理需要根據(jù)實際情況做出應對并及時上報。
• 若需要臨時增加需求，則按照前面的步驟再走一遍，評估出新需求的時間。如果新需求不復雜，那么可以跟開發(fā)負責人溝通，加在剩余時間內(nèi)；如果新需求比較復雜且優(yōu)先級較高，則需要考慮替換掉原來的某些任務（當然現(xiàn)實情況是都得要，那么就只能加班了）。

3. 過程復盤

在整個過程中需要和團隊及時總結(jié)經(jīng)驗和教訓，并形成切實可行的改進計劃。

這里請注意，還記得上文提到的“基本歸因錯誤”嗎？復盤是針對出現(xiàn)問題的流程/制度，而不是針對某人。

五、總結(jié)

• 產(chǎn)品經(jīng)理對結(jié)果負責，有好的過程才有好的結(jié)果；
• 保姆式產(chǎn)品經(jīng)理：做開發(fā)的傾聽者、支持者和引導者；
• 通過WBS引導開發(fā)正確分解活動；
• 通過敏捷撲克引導開發(fā)準確估算活動；
• 把控進度，及時調(diào)整。

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

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