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

作為產品經理，你是否遇到過以下問題：

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

如果出現以上問題，80%是因為開發評估工作沒有做好。

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

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

一、產品經理在開發評估會議中的定位

在中小企業，特別是以敏捷開發為主的團隊中，產品經理往往需要承擔一部分項目管理的職責。

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

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

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

可是現實情況卻不盡人意，常常會遇到：

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

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

千萬不要認為開發評估會是開發的主場，作為產品經理，需要對產品的結果負責，對于任何環節可能造成的風險都需要提前規避。

因此，在評估會上，產品經理不僅要做一個“傾聽者”（了解技術實現方案）和“支持者”（對于開發不明確的地方提供必要的說明），更要做一個“引導者”。

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

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

• 降低項目開發風險；
• 建立與開發的信任；
• 從技術視角看待產品，了解開發知識；
• 鍛煉領導力。

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

二、會議前

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

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

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

對于產品經理，功能列表肯定不會陌生，在需求之后原型之前，我們就會通過功能列表梳理產品結構。

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

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

這里我用曾經做過的在線答題功能舉例：

可以看到，給產品經理自己看的功能列表會相對簡單一些，只需寫出大致的功能架構，為后續的原型設計提供指引。

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

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

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

這是由于兩者的形式決定的，WBS相比PRD最大的優勢就是“直接”和“結構化”。

從下圖可以看到，PRD文檔包含了很多內容，產品經理自己寫都需要花很久，開發同樣需要花很長時間閱讀（現實中更多的情況是開發不看文檔，遇到問題了再問）。

其次文檔形式不便于直觀地看出各功能的層級結構，難以形成前后聯系。

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

同時產品的架構、各功能之間的聯系和關鍵規則都在一張表里展示出來，大大提高了閱讀效率。

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

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

我們回想一下開需求評審會的場景，經常有開發對我們的設計方案提出質疑。

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

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

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

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

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

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

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

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

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

3. 促使信息對齊

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

然后信心滿滿的準備開會?？墒鞘屡c愿違，在會上你會發現，由于每個人所站的角度不同、高度不同，仍然有部分成員因為理解不一致而進行無效討論。

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

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

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

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

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

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

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

人是制度的產物，改變人不如改變制度和流程，所以以上我提供的方法都是基于改變流程這一維度。

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

三、會議中

經過了會議前三步的準備，團隊成員對需求范圍、設計方案以及初步開發方案都有了較深入的理解，接下來就進入到了正式開會環節。

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

后續開發過程是否順利，是否能夠按時按量完成，都會受會議中產出的結果影響，因此重要性不言而喻。

在開發評估會議中，主要包括三個環節：

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

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

1. 引導開發正確分解開發活動

“分解”是產品經理必備的一種思維，上到業務目標，下到產品功能都需要分解成可執行的最小單位，開發評估工作亦是如此。

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

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

要想解決這一問題，要從思想上轉換：

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

因此在評估前要做一件事：建立設計方案和開發方案之間的聯系，這就需要在前面的步驟中我們已經做好的WBS。

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

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

此時要引導開發繼續分解到接口層面：

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

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

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

但是涉及到模型建立、表結構設計、技術選型這類方案的討論，還是需要在會前決定好。

2. 引導開發準確評估活動時間

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

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

這樣做會出現兩個問題：

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

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

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

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

1）什么是估算撲克

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

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

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

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

2）數列的含義

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

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

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

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

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

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

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

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

3）估算工時步驟

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

注： 一個完整的開發過程還涉及前后端聯調，可以拆成單獨的活動再由前后端成員共同評估。

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

4）估算故事點步驟

由于故事點指的是工作總量，單獨對任意一個前后端任務評估都不完整，且不好統一定義單位故事點?！?/p>

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

（1）關于評估對象

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

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

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

（2）關于確定單位故事點

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

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

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

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

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

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

在周期結束后統計做完了多少個故事點即可，再通過兩三個周期的調整和適應，我們就可以較準確地評估出團隊整體的生產力和個人的生產力，為后續改進提供依據。

5）并行估算

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

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

3. 開發活動分配和篩選

到了這一步，我們已經拿到了每個開發活動/功能較準確的評估。

接下來就是由開發負責人將這些任務合理地分配給各成員，成員也可以主動認領，產品經理無需干涉這一過程。

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

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

不管是采用哪種估算方式，都可能會遇到所排需求超出團隊周期內的最大工作量，此時就需要產品經理根據需求的優先級和關聯性判斷哪些需求可以移入下一個周期。

4. 會議通用

1）把控會議進度

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

2）做好會議記錄

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

四、會議后

1. 跟蹤遺留問題

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

2. 跟進開發過程

如果團隊中沒有項目經理，那么項目跟進的工作就需要由產品經理負責。

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

甘特圖適用于：

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

看板適用于：

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

在項目進行過程中，產品經理需要每天檢查并更新活動進度，這樣可以及時發現偏離情況：

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

3. 過程復盤

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

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

五、總結

• 產品經理對結果負責，有好的過程才有好的結果；
• 保姆式產品經理：做開發的傾聽者、支持者和引導者；
• 通過WBS引導開發正確分解活動；
• 通過敏捷撲克引導開發準確估算活動；
• 把控進度，及時調整。

本文由 @產品亂彈 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。