通過這篇文章，總結自己在工作實踐中需求管理的方法論——普拉姆方法?？偨Y這個方法論的特點是，用最輕量化的投入，與他人協作，并管理需求，推動需求上線。這套方法論組合了項目管理、敏捷開發的知識，希望能對大家有所幫助。本文適合0-2歲產品經理閱讀，產品大牛、敏捷管理大師請繞過。

本文大綱如下：

1. 為什么要做需求管理？

• 1.1 我們的工作是否像救火
• 1.2 需求管理是什么？
• 1.3 宗旨是什么？
• 1.4 結尾

2. 需求管理中的干系人和角色

• 2.1 什么是干系人
• 2.2 需求管理中的角色
• 2.3 如何識別干系人和角色

3. 需求管理的三個模式與公交模型

• 3.1 破解“越快越好“的局面
• 3.2 急診室的場景
• 3.3 讓需求管理運轉——公交模型
• 3.4 總結

4. 急診模式在需求收集中的應用

• 4.1 再談需求人和負責人
• 4.2 急診模式的應用流程
• 4.3 關于時間的把控
• 4.4 結語

5. 收集需求的模板

• 5.1 應用場景
• 5.2 模板樣式
• 5.3 結語

6. 需求池的核心：優先級和重要性

• 6.1 什么是需求池？
• 6.2 優先級——需求的分類和排序
• 6.3 重要性——優先級的輔助
• 6.4 統一的看優先級和重要性
• 6.5 結語

7. 排期站會——需求收集的最后一站

• 7.1 為什么要站著開會
• 7.2 排期站會的一般流程
• 7.3 排期站會的道具
• 7.4 結語

8. 登機模式與需求設計

• 8.1 何為登機模式
• 8.2 產品文檔要用共享文檔
• 8.3 結語

9. Trello的使用技巧——看板模式與需求研發

• 9.1 雞肋的郵件
• 9.2 看板與需求卡片
• 9.3 Trello的使用技巧
• 9.4 結語

10. 需求管理的證偽

• 10.1 遭遇危機
• 10.2 優化需求管理流程
• 10.3 優化需求池
• 10.4 普拉姆理論的缺陷

1. 為什么要做需求管理？

1.1 我們的工作是否像救火

總是做迫在眉睫的事情，會令人喪失目標?！镀绽吩瓌t》

我在工作中體會到每天忙東忙西的處理需求，雖然每天都很充實，但確實極為耗費精力，時間長久就會缺乏動力。

上面講的是個人的角度，如果一個組織或者團隊面對大量的需求，在處理需求的時候，沒有節奏和規劃，會產生消極的影響。從小的方面看會影響團隊士氣，往大的方面看，會影響組織實現既定的目標。

我的工作環境是，作為后臺產品經理，處在業務運營團隊和技術團隊之間，要作為一個橋梁，保障業務運營團隊從我這里輸出高質量的需求，也要保障具有不同知識背景團隊，能過通過需求，高效溝通，快速推進需求上線。
于是，我就通過工作實踐，形成了自己的管理需求方法論——普拉姆方法。

存在即有標識?！镀绽吩瓌t》

為了便于總結和歸納，我給這個方法論起了個名字。在需求管理中，需求的名稱也是很重要的因素，之后會提到。

1.2 需求管理是什么？

我的定義是，通過協作，管理需求內容和進程，實現成功發布。

便于理解這個概念，在這里講一個海灣戰爭的故事。

在海灣戰爭中，美軍在前期并沒有派出大規模的地面部隊進行戰術打擊。而是，派出一批批的特種部隊滲透到敵人境內，偵查清楚敵人重要的軍事目標，并將精準坐標和信息，傳遞給后方。頃刻之間，海洋上的戰艦派出飛機和戰斧導彈對其進行精準轟炸，并取得戰術和戰略上的勝利。

在這個例子中，特種部隊是業務運營團隊，飛機和戰斧導彈是技術團隊。產品經理通過需求管理的方法論，用高效和輕量化的方式，去精準的做出需求，實現預期的效果。

1.3 宗旨是什么？

普拉姆方法的宗旨是積極主動，知識共享，相互尊重。

什么是宗旨？可以理解為這套方法論的價值觀。這套方法論的每一個細節，都應該遵循這個宗旨來實踐，并遵循這個宗旨發展和進化。

“積極主動，知識共享，相互尊重”的宗旨，是我借鑒了美國西南航空的價值觀。美國西南航空是美國航空業受到911事件巨大打擊的背景下，依然能夠盈利的廉價航空。在航空業極為復雜的管理模式下，使用廉價航空的經營方式實現盈利，還是令人十分震撼的。所以，閱讀了相關書籍之后，將美國西南航空的價值觀的精華，吸納為普拉姆方法的宗旨。

（1）積極主動

積極主動是核心，具體指團體之間的成員積極主動的承擔責任去做事情。

在《高效能人士的七個習慣》中，積極主動也被列為很重要的素質。在管理每個需求的過程中，每個人都要有擔當或者忽略角色的做事情。這也是敏捷開發中推崇的。一個產品經理在不同的需求中，可能既是梳理需求、輸出原型的角色，又可能是測試的角色。但是，團隊中每個工作的角色在變，通過管理需求達成的目標不會變。

請明確講清需求的目標！我會像戰士，即使身陷重圍，也會向勝利的方向戰斗！——《普拉姆原則》

（2）知識共享

知識共享，是指分享不同團隊的領域知識，減少溝通的未知區域，減少溝通中的誤解。

有一個Johari窗格的溝通理論，專門提到溝通分為四個區域，即開放區、盲目區、隱秘區、未知區。通過擴大開放區，來提升溝通的效率和效果。

同時，“公則生明”，即將信息公開透明，可以增加協作團隊之間的信任。比如，公開展示各需求的進度。

講個題外的故事，俞永福對產品經理說過，產品經理要有樹靶子的意識。自己的需求就是靶子。公司內部的任何人都可以打靶子。每個產品經理有責任，維護好自己的靶子，不被打漏。所以，產品經理自己要讓自己的需求健壯，不被打漏。

從另外的角度看，盡早的把問題暴露，可以最大的降低解決問題的成本，防止問題積累成一個“驚喜”。

（3）相互尊重

相互尊重，是指尊重每一個人的人格、勞動及輸出成果。

在管理需求的過程中，要與不同崗位的人打交道。每個人站在不同的立場，必然會有看待問題的不同角度。所以，大家在合作的過程中，要相互尊重。內在的思想是人格上的尊重，外在的表現是尊重別人的勞動成果。不要站在自己的立場和知識背景，去簡單評判別人的勞動。

對他人勞動的尊重，就是對他人的尊重。

1.4 結尾

這是文章的的開篇，濕貨很多?？赡芏际谴蠹抑赖某ＷR。不過，常識并不常用。把常識內化為行動之中，可以讓事半功倍，至少不會犯錯。

2. 需求管理中的干系人和角色

識別出需求的干系人，是需求管理中非常重要的起點。之后的需求管理活動要與干系人及角色，進行緊密的合作。

2.1 什么是干系人

干系人，是來自于項目管理中的概念。

項目干系人是能影響項目決策、活動或結果的個人、群體或組織，以及會受或自認為會受項目決策、活動或結果影響的個人、群體或組織。他們也可能對項目及其可交付成果施加影響。干系人可能來自組織內部的不同層級，具有不同級別的職權；也可能來自項目執行組織的外部?！俄椖抗芾碇R體系指南(PMBOK指南)(第5版)》

總結的簡單點，干系人是與需求相關的人或者組織。

而且干系人在需求管理中起到很重要的作用。特別是在做跟業務流程密切結合的需求時，找到并找對干系人極為重要。在需求中的每個人，都會從自己的立場出發提需求，可能會不經意間破壞別的業務線的流程，所以這個時候就需要產品經理從全局的角度去思考需求，或者找到那個能從全局思考的干系人去幫助找到需求中的障礙。

有人就會有角色，每個角色必然有不同的關注點，被忽略的關注點都變成了坑?！镀绽吩瓌t》

這里再擴展一點，就是需求可能存在二律背反的情況。也就是說，提一個優化改善的需求，可能會損害其他流程或角色的利益。有時，產品經理要找到需求的受害者，從而更全面的了解需求。

不害人的需求，不是完整的需求?！镀绽吩瓌t》

所以，找到和找對需求的干系人，對于需求管理非常重要。

2.2 需求管理中的角色

在《西游記》中，六小齡童扮演的角色多達16個，最知名的就是孫悟空，還有道士、和尚之類的角色。而唐僧的角色，就有三位演員扮演過。同理，在需求管理中，干系人是一個個的演員，而演員可以擔任多個角色。

以下是我在從事后端系統的工作中遇到的角色：

（1）需求人

顧名思義，真正提出需求并描述需求細節的角色。這個角色可以是任何干系人，畢竟產品經理是一個負責從四面八方收集需求的人。需求人一般要與其所在的部門聯系在一起，有助于判斷所提需求的立場。

（2）負責人

負責人也來自于業務部門。收集需求人的需求，從業務角度對需求進行梳理和判斷，并轉發給產品經理和研發同事。當業務團隊遠大于技術和產品團隊時，負責人的角色就非常重要。如果業務團隊的人數小于等于技術團隊時，可以省去這個角色。

負責人，就像一個漏斗和篩子一樣，初步篩選一遍需求。畢竟，評估需求也是要花費時間，特別是占用研發同事的時間。

（3）產品經理

需求管理的組織者、推動者。以“積極主動”的態度，與需求管理的角色進行溝通。

（4）研發經理

研發資源的管理者。在這里的研發經理，一般是帶四、五個人小團隊的級別。因為，他們能夠了解每個研發工程師的工作和能力，協助評估業務需求。

（5）研發工程師

實際參與研發需求的程序員。

（6）測試工程師

參與需求測試的測試人員?？梢愿鶕镜慕M織架構，增加測試經理的角色。測試經理的級別也是帶四、五個人小團隊。

在需求管理中，產品經理要當成一個橋梁，與不同的角色，進行溝通和協作。在后面，需求管理的流程和需求看板的管理方法，都會與這些角色緊密相關。

2.3 如何識別干系人和角色

了解所在公司的組織架構，以及團隊組織架構，是識別干系人和對應角色的關鍵。

產品經理可以根據組織架構，明確了解到研發和測試的相關角色。

同時，產品經理可以跟業務團隊進行溝通，了解業務團隊的業務背景和知識，以及團隊文化。

識別出潛在的需求人，才是真正的考驗。

以上，就是需求管理中干系人的相關內容。

3. 需求管理的三個模式與公交模型

普拉姆方法的運行流程包含三個模式：急診模式、登機模式、看板模式。本章將介紹這三個模式與公交模型的關系，提供一套應對”越快越好“類需求的方法。

3.1 破解“越快越好“的局面

在接到來自各部門的需求時，每個需求都會打上”越快越好“的標簽。站在提需求者（需求人和負責人）的角度，研發資源是稀缺的，老板的要求是急迫的，如果不表達需求的急切性，需求就排不上。

這就像飛機迫降之后，每個人都會帶著”越快越好“目的奔向出口，如果沒有空乘人員的指揮，最后大家慌不擇路的堵在出口，最終導致延誤了逃生時間。

處理工作的模式：劃散亂為規律，劃應急委預測?！镀绽吩瓌t》

所以，可以借鑒急診室的場景 ，來規劃”越快越好“的需求，讓需求管理有序的運行起來。

3.2 急診室的場景

產品經理面對的需求，就是來看急診的病人。病人都會覺得自己應該馬上得到最快的醫療救治。但是，醫療資源有限，只能讓醫生先救治最危重的病人，病情較輕的病人要先等待一下。這個時候，需要有一個預檢分診的流程，預先對病人進行判定和分診，從而讓急診室高效的運轉起來。

因此，借鑒急診室的做法，我們對需求增加一個”預檢分診“的預處理模式。從而對”越快越好“的需求，進行區分，在研發資源稀缺的情況下，讓真正緊急的需求獲得資源。

3.3 讓需求管理運轉——公交模型

設想一下，病人去急診樓就醫的時候，我們安排了”預檢分診“（預處理）的流程。那么就需要安排一個房間，讓病人們在那里等候，并安排醫生進行診斷。然后，病人根據預檢醫生的診斷，再從這里出來，去對應的診室去看病。

所以，要讓這個流程在需求管理中正常的運行，就需要采用公交模型。

公交模型，是我結合火車模型發布模式，起得一個通俗易懂的名字。

（火車模型發布模式是）以固定的周期持續發布產品，如果某項既定功能未完成，就挪到下個周期發布的開發方法——《啟示錄——打造用戶喜愛的產品》

公交模型，就像我要從到家到公司要換乘3趟公交車去上班，到公交站等車。每趟公交車之間都有發車間隔和到站時刻，并且周而復始的經過公交站。所以，我就按照規劃好的路線，從公交站坐車，再到下一個換乘站乘車。

從公交模型中，可以提煉出幾個概念：出行路線、發車間隔、到站時刻。

在公交模型中，出行路線稱為”需求管理流程“，發車間隔稱為”需求管理周期“。到站時刻，稱為”需求時間“。

（1）需求管理流程

需求管理流程，是指在需求管理中，按照順序依次進行需求管理活動。

需求管理活動按先后順序分為三個階段：

1. 需求收集
2. 需求設計
3. 需求研發

再強調一遍，這三個階段是依次進行的。先進行需求收集、在進行需求設計、最后進行需求研發。

每一階段的需求管理活動對應一個指導原則。指導原則就是急診模式、登機模式、看板模式。急診模式指導需求收集，登機模式指導需求設計，看板模式指導需求研發。

在文章的開頭，我用急診室的場景，介紹了急診模式。后續的章節中，我會介紹剩下的兩種模式：登機模式和看板模式。

（2）需求管理周期

需求管理周期，簡稱”周期“，是需求管理活動按順序重復出現，并完成需求管理活動的時間叫做需求周期。

普拉姆方法的需求周期，是80小時，即2個星期。80小時原則，來自于項目管理中的工作分解結構。根據項目管理的一般經驗，將一個項目中的工作，按照80小時的工作量進行拆分比較合理。所以，每一類需求管理活動按照2周的工作量進行。

換句話說，需求收集、需求設計、需求研發是三輛同時發車但路線不同的公交車，三輛公交車運行一趟的時間是2周。每個需求相當于是乘客，要根據路線（需求管理流程）在公交站等車。當然，每個需求的終點就是發布上線。

（3）需求時間

在需求管理活動中，進行某一項具體活動的時間點，就是需求時間。

一般，需求時間意味著規則。比如，需求設計階段的周二的下午2：00，需要開排期站會，這是一個約定好的時間，需求的相關方都必須要來。排期站會后面再介紹。

（4）運轉模式

如果一個需求從開始到發布上線的生命周期來看，公交模型是下面這個樣子。

從需求管理周期的角度，無數需求按照公交模型去運轉著。從參與到需求管理的角色來看，每一個周期中的需求收集、需求設計、需求研發階段，參與者的工作是連續可預測的。每個角色各司其職，讓需求管理順暢的進行下去。

3.4 總結

這章通過介紹急診室的故事，也就是急診模式，來引出破局”越快越好“類需求的方法，以及后面要介紹的登機模式和看板模式。這三個模式用來分別指導需求收集、需求設計、需求研發三個階段的需求管理活動。

同時介紹了推動需求運作的公交模型，讓需求管理活動具有預測性和規劃性。

本章之后，將依次介紹三個模式和三個階段對應的方法和工具。

4. 急診模式在需求收集中的應用

4.1 再談需求人和負責人

在《需求管理的三個模式與公交模型》中談到，需求就像來急診室的病人，只有經過“預檢分診”的過程，判斷出需求的輕重緩急，從而匹配出對應的資源。

那么，在實際的場景下應該如何應用急診模式呢？

首先回憶一下《需求管理中的干系人和角色》中，提到了角色有需求人和負責人。

• 需求人，這個角色來自于公司或者組織的任何方面，他們是提出需求的人。
• 負責人，這個角色負責收集需求，特別是業務需求。當業務團隊的人數，遠遠大于研發團隊時，這個角色非常的重要。

需求人和負責人在應用急診模式時，處在比較重要的位置。

4.2 急診模式的應用流程

急診模式的應用流程如下圖：

其中，圓角方形代表操作步驟，直角方形代表輸出物。

在這里復述一下整體的步驟。

需求人提交需求。提交需求的模板，之后的章節會介紹。

負責人收集需求文件，初步評審需求。在這里，如果需求存在不合理的狀況，特別是業務流程不合理，負責人可以將需求打回需求人重新整理。

產品經理、研發經理初步評審，并放入待排期列表。產品經理拿到負責人評審通過的需求，與開發經理進行初步評估，判斷需求是否可行?？尚械男枨蠓湃氪牌诹斜?。待排期列表的模板，之后的文章也會介紹。不合理的需求，也會打回。

根據待排期列表，需求人、負責人、產品經理、研發經理評定待排期列表中的需求，生成待開發列表。在這個過程，會應用一個工具——排期站會。這個工具，之后也會介紹。經過排期站會后，形成待開發列表。

在需求收集階段，以上所有步驟是應用急診模式的過程。

4.3 關于時間的把控

在《需求管理的三個模式與公交模型》中，公交模型下，會有三輛“公交車”，即需求收集、需求設計、需求研發。因為需求管理的時間周期可以是2周，所以每輛“公交車”的發車周期是2周。

換句話說，在需求收集階段，執行急診模式的操作步驟的時間是2周。

其中，需要關注幾個需求時間。

在需求管理活動中，進行某一項具體活動的時間點，就是需求時間。

（1）需求收集的開始時間和結束時間

關注需求收集的開始時間和結束時間，因為二者相減，約等于2周，或者說約等于2周的工作時間。因為每個公司的工作習慣不一樣，可能會涉及到固定時間點的例會等，所以，需求開始時間和結束時間設置要靈活。

同時，需求收集的開始時間和結束時間，要有一定原則性。產品經理要盡量影響需求人，不要趕在緊鄰結束時間提交需求。就好比，在現實生活中趕火車，總要提前一會兒到達車站，畢竟還要有檢票進站等環節。同樣，需求人在臨近結束時間提交需求，負責人評審需求和產品經理評審需求的時間，都不能保證，會影響需求的質量，以及之后的排期站會的質量。

所以，為了規避這種情況，可以在需求收集結束前5天，發送排期站會的會議邀請，以此提醒大家馬上就要排期需求了，趕緊提交需求。

（2）排期站會的時間

排期站會的具體內容和形式，后面的文章會提到。這里先提一下排期站會的時間。

排期站會的時間緊鄰需求收集的結束時間。換句話說，需求收集一結束，立刻開始排期站會。

因為排期站會，需要需求人、負責人、產品經理、研發經理及研發工程師參加，所以要多方協調一個大家都有空的時間進行。

排期站會的時長控制在一個小時內。

4.4 結語

本章介紹了在需求收集階段，應用急診模式的流程步驟。

之后將介紹，在需求收集階段的3個工具：

1. 需求提交模板
2. 需求排期列表
3. 排期站會

5. 收集需求的模板

本章介紹一套收集需求的模板。通過模板規范需求的內容，以及提升溝通的效率。

5.1 應用場景

模板應用在需求收集階段，方便需求人提供和描述相應需求，便于負責人、產品經理、研發經理等角色評審需求。
利用此需求模板，可以快速提取需求信息，便于存檔和查閱。

5.2 模板樣式

此需求模板在填寫上有如下說明：

（1）需求提交部門

填寫需求人的所在部門。

（2）功能使用角色

比如可以填寫業務主管、業務經理等?？梢允鞘褂谜叩穆毼幻枋?。

（3）使用頻次

單位時間內預計使用功能的次數。比如，10次/月。方便判斷此需求的優先級。

（4）提交時間

記錄需求提交的時間，便于使用“先入先出”原則。

“先入先出”原則，來自于倉儲的概念，指的是先進入倉庫的商品先出庫。比如，食品行業有保質期的要求，需要生產越早的食品，越早出庫。

再形象一點，把處理需求的過程理解為一根管子，新進入管子的需求，就先從另一頭流出。

因為需求對應的場景和業務可能會變化很快，如果積壓時間太久的需求，就變貶值，跟不上現有業務的發展，所以要應用“先進先出”的原則。

（4）優先級和重要性

這兩個概念下一章重點介紹。

簡單地說，優先級是對需求按不同的類型進行劃分。通常見到的優先級劃分是高、中、低，或者用簡單的數據代替。

• 優先級：是部門與部門之間的需求比較。
• 重要性：是對需求打分，對優先級的補充，是部門內部需求的比較。

（5）需求涉及部門

一個系統需求，會牽一發而動全身。通過填寫此需求可能涉及到的其他部門，來評估需求帶來的可能影響。
也能驅動需求人在提需求時，增加跨部門思考的維度，提升需求的可行性。

不害人的需求，不是完整的需求?！镀绽吩瓌t》

（6）系統功能位置

對于系統功能優化類的需求，可以注明原有需求的位置，或者想要添加的功能頁面。

（7）業務背景

或者叫需求背景?？梢韵胂笠幌?，如果需求是一部電影的話，是不是要介紹這個故事發生的時間、地點、人物等。以此類比，填寫相關的需求背景。

（8）預期完成效果

描述需求實現后，預期實現的效果。

（9）需求說明

以任何形式來描述需求內容。

（10）需求文檔

任何形式的需求文檔，都不如流程圖簡單明了，便于溝通。

5.3 結語

此文檔偏向于應用在后端產品或者系統需求。

如果是前端需求，可以根據業務需要選擇填寫。

6. 需求池的核心：優先級和重要性

本章重點介紹需求池中的核心：優先級和重要性。

6.1 什么是需求池？

需求池，顧名思義就是放需求的地方。需求像下餃子一樣，儲藏在需求池中。

在我看來，需求池是更像是一個游泳池，需求有不同的泳道。而泳道代表著需求的不同狀態。

需求的狀態一般包括：籌備中、待排期、待開發、開發中、待測試、測試中、待上線、已完成等。

每一種狀態的需求，可以匯集成一起。比如，待排期狀態的需求，可以匯總成列表樣式，叫做待排期列表。

所以，需求池是多種狀態的需求，以合適的形式展現的需求匯總。

結合，之前文章提到的內容，需求池列表可以是長成如下樣子。

當然，需求池中不同狀態的需求，可以用多種形式進行展現。比如，待排期的需求可以用列表的樣式進行展示。待開發狀態以后的需求，可以用看板的樣式進行展現。

6.2 優先級——需求的分類和排序

需求的優先級是再熟悉不過的名稱了。

優先級表現形式，一般是數字123、漢字高中低，或者字母ABC等。優先級可以用來給需求進行排序，優先級高的需求，優先開發。

同時，優先級也可以對需求進行分類。或者說，對不同的優先級給予一個不同的釋義。

舉一個例子：

需求優先級的定義，可以根據所在公司和組織、所經營的業務進行綜合評估和劃定。

但是，有一個問題，需求的數量一般會比需求優先級要多。所以，多個需求可能會同一個優先級，那么同一優先級的需求又該如何區分呢。

6.3 重要性——優先級的輔助

剛才說了優先級，具有對需求分類的作用。重要性是對優先級的輔助。

重要性是對需求進行打分，分數的范圍是1-100分。每個需求會被賦予1個分數，每個需求的分數是唯一的。

例如，需求A、需求B、需求C，分別賦予了97分、85分、90分。那么，根據分數從大到小進行排序，那么優先做分數大的需求。

如下列表：

需要注意的是，重要性的分數只是用來做排序，不代表其他信息。比如，重要性是100分的需求不是50分需求的2倍。

另外，在做重要性評分的時候，建議每個需求之間不要打連續的分數。比如，需求A的重要性打95分，需求B的重要性最好打92分。分數中間的間隔，用來插入需求。畢竟在工作中，有很多突發的需求會插入進來，以調整研發計劃。

6.4 統一的看優先級和重要性

從整體的角度看，優先級和重要性兩者的關系。

優先級和重要性是需求池的核心！什么是核心？優先級和重要性一旦確定，將貫穿需求的整個生命周期，所有的資源將根據優先級和重要性來被安排。

換句話說，如果是高優先級和高重要性的需求時，不管在需求的哪一個狀態，都會被優先分配資源。

優先級和重要性在處理跨部門需求的時候，尤為重要。原因在于，優先級可以用來比較不同部門之間的需求。因為優先級已經對需求進行了分類。

同時，重要性只用作一個部門內需求的比較，重要性的分數不能跨部門比較。比如，采購部門重要性100分的需求，與銷售部門重要性是90分的需求，在分數上是沒有可比性的。

（是不是有點暈了？先跳出來。）

優先級和重要性，只是處理需求的工具。更重要的是，如何給需求劃分優先級和重要性。

我覺得這些方法有很多，但是可以借用項目管理的一個概念——項目組合管理。

項目組合管理是指在可利用的資源和企業戰略計劃的指導下，進行多個項目或項目群投資的選擇和支持。項目組合管理是通過項目評價選擇、多項目組合優化，確保項目符合企業的戰略目標，從而實現企業收益最大化。

這個概念有點繞，只要關注一個詞——“符合企業戰略”。所以，劃分需求的優先級和重要性，是緊密圍繞著企業和組織的戰略。

而如何劃分優先級和重要性，可以看做是項目組合管理方法論的范疇?？梢允褂肧WOT分析、KANO模型等等，這些都是得到優先級和重要性的工具。

所以，在符合企業或組織戰略的核心目標下，通過項目組合管理的方法，先對收集到的所有需求標注好優先級，再對這些需求進行分組，形成需求組。分組的依據可以是部門，可以是項目。對這一組內的需求，賦予不同的重要性分數。因為需求組之間劃分的標準不同，所以不同需求組的需求，重要性分數不具有可比性。

因此，從實現企業戰略的角度，高優先級的需求在劃分給不同需求組后，可能并不會賦予很高的重要性。

6.5 結語

優先級和重要性，只是處理需求的手段。它們背后的核心要義是企業和組織的戰略目標。

7. 排期站會——需求收集的最后一站

上一章介紹了制定需求優先級和重要性。在此基礎上，可以組織需求方和研發方在一起開排期站會。一是評定進入到需求設計階段的需求，同時也是增進各方溝通信息的好時機。

7.1 為什么要站著開會

在敏捷開發中，站會是一個很有用的工具。在5-10分鐘的時間中，快速交流信息，推進項目。

之初，排期會議也是安排在會議室之中，大家坐著溝通信息。實際上，人一旦沒有緊迫感，就容易天馬行空的溝通起需求的細節。值得注意的是，排期會不是需求評審會。

一般，排期會上要評定20-30個以上的需求，每個需求討論3-4分鐘，將是個極為漫長的過程。

所以，讓大家站著開會，以一種不太舒服的方式，壓縮自己的思路，快速溝通問題。

7.2 排期站會的一般流程

舉行排期站會的一般流程如下：

（1）發送會議邀請

排期站會的舉辦時間是以固定時間舉辦。按照之前文章提到需求管理周期，一般是2周舉辦一次。具體的開會時間，要與各方協調，特別是避開例會時間。

與會人一般包含：需求人、負責人、產品經理、研發經理、測試經理等。

（2）在規定時間開會，提前公布討論需求組的順序

站會中討論的需求，會來自不同需求組（關于需求組的概念，請上一章:需求池的核心：優先級和重要性）。每個需求組對應著不同的人，為了避免浪費大家的時間，按照討論組的順序，讓對應的人按順序參加會議。

制定討論順序時，盡量要考慮每個需求組的數量，和需求組的重要性。因為，先行討論的需求，就會有優先獲得需求的優勢。

（3）按順序召集大家開會，首先介紹當前需求的開發情況

由會議主持人（一般是產品經理）介紹當前的開發狀況，特別是溝通時間點。

（4）評審進入下一階段的需求

主持人可以針對需求池的內容，溝通可以進入到下一階段的需求。

但是，主持人要控制住節奏，防止大家陷入需求細節的討論。對于一時沒有定論的需求，要標注出來，邀請需求相關方在會后討論。

7.3 排期站會的道具

（1）站會的場地

站會的場地可以選在工位旁，較大的過道或者走廊上。這樣便于參會人快速到達和撤離開會現場。也可以讓一些讓其他同事，快速參加會議。

（2）展示會議內容：電視/白板/看板

一般大家要圍繞著需求池來開會。而展示需求池的道具，可以一塊兒屏幕或者投影。這樣可以集中大家的焦點，和快速展示信息。

（3）倒計時器

在每一個討論模塊設置倒計時器，到時鈴響。提醒大家關注時間。

7.4 結語

站會的首要目的是公布信息，增進溝通和了解。

大家在開會的過程中，了解微信和郵件中以外的信息，增加對需求的了解。需求相關方的信任和了解。

8. 登機模式與需求設計

之前的章節已經將需求收集和急診模式講完了。本章介紹需求設計和登機模式。

8.1 何為登機模式

做需求，猶如坐飛機，通過各種渠道買好了機票，但并不是意味著馬上坐上飛機，而是進行check-in。

面對從各個部門提出來的大量需求，有時在需求收集階段，不能簡單快速的評估出全部細節。這個時候需要增加一個需求設計階段，對已經定好排期的需求，進行check-in，將機票轉化為登機牌，然后憑借登機牌，登上飛機。

這里的登機牌就是產品文檔，登上飛機就是進入到需求開發階段。

之前，在需求收集階段，收集到的資料大部分是可以歸為需求文檔，也就是描述：我想要什么，實現什么樣的效果。或者說，需求文檔不涉及到具體界面功能流程、交互設計、UI設計。

實際上，需求文檔也不應該涉及這些。原因是，提供需求文檔的人（需求人和負責人）并不擅長用非業務語言描述，同時也會增加他們提交需求的工作量，從而影響需求質量。

專業的人做專業的事。

什么是產品化？將需求轉化為可以投入資源的行動項?！镀绽吩瓌t》

這樣的話，需求設計階段，就需要講需求文檔轉化為產品文檔，真正將需求描述轉化為產品解決方案，轉化為讓研發同學可執行的方案。

當然也有特例，如果需求是業務邏輯的修改，不涉及界面操作，這時的需求文檔其實等價于產品文檔。

8.2 產品文檔要用共享文檔

這里并不討論在需求設計階段怎么書寫產品文檔，因為書寫產品文檔是用于溝通的工具，格式并不是特別重要。

這里要提的是產品文檔要采用共享文檔的格式。在之前，本人將寫好的產品文檔是以郵件的形式發送給相關人。但是，隨之而來的問題就是，更新和保存文檔，就變成了問題。

以郵件的形式，總會是存在漏看文檔，和不易查找文檔的方式。

所以，產品文檔要使用現在共享文檔的方式。國內已經有很多類似的產品，比如墨刀之類。我使用的是Google文檔。使用的原因是體驗好，功能完備。

使用在線共享文檔的最大優勢是，可以隨時保存，使用鏈接分享，隨時保持文檔的最新狀態。同時，可以多人共同編輯文檔，更新信息，減少溝通的成本。

同時，還能對文檔進行積累和保存。

8.3 結語

在需求管理的需求設計階段，對需求重新進行評估和設計，從而轉化為產品文檔，并使用在線共享文檔的形式，進行協作，減少溝通成本。

9. Trello的使用技巧——看板模式與需求研發

經過多個章節，終于到了需求研發的階段。這個時候，使用看板模式進行需求管理。普拉姆需求管理方法的介紹，也快接近尾聲。

9.1 雞肋的郵件

郵件已經成為公司最基本的溝通工具。但也是最雞肋的工具——食之無味，棄之可惜。

所以，在需求管理的方法中，盡量讓需求的形式或者載體，不僅僅依附于郵件，而應該采用多種形式。比如，在需求池中，需求就是以一行數據的形式存在。

在需求研發階段，采用看板模式，以卡片的形式存在。

9.2 看板與需求卡片

（1）看板

看板的管理方法，是一個來自于制造業的專門知識。

看板管理，是指為了達到JIT準時生產方式而控制現場生產流程的工具?！俣劝倏?/p>

這里只是才用如下圖進行示意，感興趣的讀者可以查閱相關資料，學習看板知識。

看板由不同的“泳道”組成，需求以卡片的形式，從最左端開始，運行至最右端結束。
一般“泳道”的劃分，可以按照需求的狀態劃分。也就是說，需求卡片從左向右的流轉，就是需求狀態的流轉。

（2）需求卡片

需求卡片是需求在看板中的載體。這里可以記載需求的所有信息。

但是包含如下信息：

• 需求名稱
• 需求的相關人：需求人、負責人、產品經理、研發工程師
• 部門
• 需求完成時間
• 需求描述

在開發需求的過程中，各需求的相關人不用再去尋找郵件，或者翻看電腦保存的文檔。

每個人都可以通過看板，看到每個需求的實時狀態。每個人都可以去拖動卡片。提前預知自己的工作量。比如，測試工程師就可以通過看板，大概預知有多少卡片在待測試狀態，從而預估自己的工作量。

當然，看板和卡片可以用采用多種形式展現。比如，用真實的板子和紙片進行管理。也可以采用電子虛擬的形式進行管理，比如使用Trello。

9.3 Trello的使用技巧

現在，有很多管理工具，在使用看板的方式。但是，綜合感受還是做得太復雜。而Trello的最大郵件就是簡單，而且兼容很多插件，可以靈活應對多種場景。

當然，Trello最大的優勢是免費。

Trello做為工具，本身極為容易上手，這里只是簡單介紹一些使用技巧。

（1）卡片

Trello的卡片功能非常強大。

這里要特別強調的是善于使用標簽功能。

標簽功能，像是辦公文具中的條狀彩色便利貼。對不同卡片進行分類。

因為Trello有搜索和篩選功能，在實際的應用中，可以將不同的“部門”作為標簽打在卡片上，這樣就可以對卡片進行篩選。

這里提示的小技巧是，將同一類的信息的標簽，賦予同一種顏色，以便于管理。比如，不同部門（如銷售部門、運營部門等）的標簽是紅色，不同系統的標簽是綠色。

另外，“附件”功能，可以添加在線共享的需求文檔的鏈接，便于查看更詳細的需求細節。

同時，可以利用“清單”功能，創建此需求的研發工作項目（WBS），使用@可以指定到具體的人。

（2）插件

使用Trello建議使用Chrome瀏覽器，因為在Chrome的應用市場中，提供了很多Trello的免費插件，增強Trello的功能。

• Card Color Titles for Trello：使用讓卡片的標簽，顯示出文字。Trello的自帶功能，標簽只能顯示一個色塊。
• Trello Card Numbers：展示Trello的每個列表一共有多少張卡片。在看板管理中，每個“泳道”是有限額和容量的概念，也就是說每個列表應該是有最多裝多少卡片的限制。如果一個“泳道”塞滿了卡片，就是會出現堵車。
• TrelloExport：可以將Trello的看板看片導出成Excel。
• True age for Trello card：展示一個卡片在一個列表中呆了多長時間?？ㄆ拖駧齑?，如果卡片長期在一個區域長期擱置，就會變成呆滯庫存，成為需求管理的負擔，應該盡快去掉。

9.4 結語

本章介紹了需求研發的看板模式，從而引申出了Trello的使用技巧。

Trello只是工具，關鍵還是背后的需求管理方法。

10. 需求管理的證偽

這是普拉姆需求管理的最后一章。最后，再聊一些關于需求管理的感悟。

10.1 遭遇危機

之前文章提到的需求管理方法，包括三個階段：

1. 需求收集
2. 需求設計
3. 需求研發

其中，每個階段分別對應了三個模式：

1. 急診模式
2. 登機模式
3. 看板模式

其中，讓整個需求管理流程順暢進行的是公交模型。也就是說，需求收集階段、需求設計階段、需求研發階段，變換成2周為一個管理周期的公交車，讓需求按照固定線路上車，完成需求的生命周期。

這樣的流程設計，可以讓需求得到充分的評估和討論。但是，缺點是一個需求給人的感知是經歷一個月以上的時間，才能完成。

同時，需求池區分了不同的狀態進行展示，其實存在重要性和優先級信息在需求研發階段逐漸模糊的情況，特別是在測試工程師面對需求時，對于需求的重要性和優先級就無法正確判斷。在有臨時需求插隊時，情況會更加嚴重。
在收集需求人意見的情況，對普拉姆需求管理方法進行優化。

10.2 優化需求管理流程

根據公交模型，將之前的三輛公交車（即三個階段：需求收集、需求設計、需求研發），去掉需求設計階段，縮減為兩量公交車（即需求收集、需求研發）。

這樣修改之后，需求的生命周期就會從結構上，最快縮短到4周以內，即在2個需求管理周期內完成。
同時對需求站會的開會時間，進行修改。將時間改在需求收集階段接近尾聲的位置，即每2周的周四開站會。這樣給人感覺就是開完會之后，排好的需求在下兩周就可以進行開發。

10.3 優化需求池

需求的優先級和重要性在任何階段都應該是不變的。比如，即使需求進入到了測試階段，高優的需求應該優先獲得資源。

所以，根據以上的思想，對需求池的信息進行精簡，主要是去掉狀態信息，讓處在研發、測試或者設計狀態的需求，全部放在一個列表中，根據優先級和重要性進行排序。

需求的狀態展示，就依托看板模式。

其中，Title是填寫需求名稱，Link是此需求的Trello卡片鏈接，可以快速將需求查看需求相關信息。Members是涉及此需求的需求人、負責人等。Label是指哪一個類別的需求，比如可以填寫部門。

這樣，只要沒有完成的需求，就可以處在這個需求池中，根據重要性和優先級進行排序，所有資源根據這個需求池的順序進行安排。

10.4 普拉姆理論的缺陷

用了將近10章的篇幅，將普拉姆需求管理方法的最佳實踐闡述完。但是，還有幾個問題，雖然有解決的理論，但是沒有經過實踐檢驗得出可行的方法。

問題一：如何評估工作量？

這是一個難題。在敏捷開發中，采用估點的方式，得到比較之后的相對工作量。但是，在實踐中卻是比較難實現?；蛘哒f，如何讓需求人和負責人清晰明確的了解所提需求的工作量。

問題二：如何確定需求完成的deadline？

由問題一引發出如何評估需求完成的deadline。在實踐中，需求人和負責人最想知道的是最終完成時間。但是，時間上進行會存在估不準的情況。畢竟，大家都不是先知。如何才能比較正確評估出完成時間呢？是不是要采用置信區間呢？

問題三：如何處理長期堆積在需求池中的需求？

資源永遠是有限的。所以需求池中的需求，可能會積壓很長時間。達到三個月的需求，應該是如何處理呢？如何說服需求人，去處理長期擠壓的需求。也許出現需求積壓的問題是需求缺少規劃。

最后

我所寫的都是屎，唯有一點要堅持。

我將實踐之后的需求管理理論寫出來，里面有肯定有很多紕漏和漏洞。

雖然胡扯的地方很多，但是有一個觀點，我一定會堅持。那就是普拉姆方法的宗旨：積極主動，知識共享，相互尊重。
不管任何需求管理的技巧，都應該圍繞這個宗旨展開，這是超越任何方法論的方法。

水平有限，希望對你有所幫助。

 

作者：wideplum，產品經理/PMP認證/工業設計碩士，微信公眾號wideplum，專注PM職業技能成長。

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