成為一個靠譜産品經理，必然要做好項目範圍管理，這既是對項目團隊的負責，也是對客戶的負責。為什麼這麼說，範圍管理又有哪些方法路徑？一起跟着這篇文章來了解吧，希望對你有幫助。
在一位産品經理的工作生涯中，隻服務于一款産品并不常見。反而在大多數時候，很多産品或服務是以項目的形式進行傳遞的。這就要求我們在工作過程中熟練掌握項目管理的方式方法，并将項目管理理論與産品經理工作實際結合起來。
下面我将從項目伊始的範圍管理開始，帶你領略網際網路行業的項目管理，希望籍此你也能掌握一定的方法論并運用到往後的工作中去。記住，隻要你想完成你手頭的項目，無論你和客戶的關系多麼親密，不要“寵壞”他們。
一、什麼是項目範圍
在日常工作生活中，評判一個人是否靠譜，有兩個很重要的評判因素“邊界感”和“分寸感”。做人做事沒有邊界感，從小的方面看容易冒犯他人，讓自己顯得粗魯莽撞；從大的方面看也容易越俎代庖，幹出不合規矩的事情。而缺乏分寸感，就會對事情的輕重緩急拿捏不清，重要的事情不做，反而在無關緊要的小事上鑽牛角尖。
項目的範圍，其實就是項目的“邊界”和“分寸”。項目範圍定義了哪些工作應該包含在項目内，哪些不應包含在項目内。做好項目範圍管理，就是確定做且隻做必要的事情，這些事是成功完成項目所不可或缺的。簡言之，能用6個包子填報肚子，就絕不吃第7個。
項目的範圍可以從兩個層面進行拆分了解：使用者需求和項目工作。使用者需求，就是使用者要求産品所必備的功能及特性；項目工作，就是為使産品能滿足要求，所必須完成的工作。舉個例子，把你自己當作“産品”，把追女孩兒當作一個項目來操盤。
你心目中的白月光對理想男友的要求是年少多金、風趣幽默、颀長健碩、博聞強識……而你為使自己盡可能靠近此标準，就開始健身、看書、交際、搞錢，最終你成功抱得女神歸，這就是一個成功的項目。而如果你一不小心逼自己成為億萬富翁，遠遠超出女神的要求并導緻對方自慚形穢而更加疏遠你，那恭喜你找到了更優秀的自己，但很顯然操盤了一個“失敗”的項目。
控制客戶預期，把握好使用者需求，将其梳理為具體的功能要點和參數特性，最終落實為項目團隊具體的行動。這就是項目範圍管理的本質。
二、範圍管理的意義何在
現代社會的各類組織，小到部門、小組，大到集團、工會，都是由“人”組成的有機體，都在積極的吸收外界能量，消化為自身成長的養分。是以，花最少的錢幹最優的事，一直是一個組織做事的底層邏輯。
項目範圍定義不清，往往是導緻項目失敗的首要原因。在啟動一個項目時，如果不能對項目要做的事情定義清晰，就是為日後項目傳遞時的推诿扯皮埋下伏筆。項目的範圍管理是制定項目計劃，做好進度把控的關鍵基礎。一個項目沒有做好範圍管理，隻會導緻攤子越鋪越大，最終無以為繼，虎頭蛇尾。
權責不清是大家在工作中最怕碰到的。這不僅僅是誰多做誰少做的問題，更會涉及到工作環節的銜接和工作成果的交接，進而影響項目的整體進度。
打個比方，小A是終端嵌入式開發，小B是背景開發，兩個人都覺得制定接口協定是對方應該主導的事情，都沒對這件事上心，最終導緻臨近傳遞時才發現終端沒有與背景聯調，影響傳遞進度。
而如果做好了項目範圍管理，就能夠确定項目的具體工作任務，有助于清楚的責任劃分和任務分派。像小A和小B的這種事情就不會再發生了。
對于項目發起方和項目經理而言，成本一直是敏感且重要的話題。一個項目在立項之初，就需要清晰準确的估算出所需投入的成本、所需協調引入的資源，以及所需的時間。
估算成本不是拍腦袋，需要準确識别裝置設施、人員配備、工作工時等，這些都和項目的具體工作息息相關。比方說研發一款智能手表，需要使用示波器等儀器測試硬體PCBA，如果在事先不明确這部分工作，就容易漏掉這些儀器，進而導緻固定投入估算不清。
總的來說，不對項目範圍進行清晰的定義，就無法明确項目的工作具體範圍和具體内容，就無法提高成本、時間和資源估算的準确性。
工作中我們常常遇到下圖所示的情況，客戶要求三個月做一幢豪宅，給了能做幾間平房的錢，我們用一年的時間反複推倒重建，最後傳遞了一個公廁。如果你讀到這裡能夠會心一笑，那證明你已經是有過幾年項目經驗的PM了，有一定經驗，但不多。
這個讀來令人捧腹的例子，向我們深刻揭示了限制項目範圍的三大要素：進度、成本、品質：
- 要求三個月完成，最終拖延一年。這是進度；
- 給了幾間平房的錢，實際因為反複重修，超出預算，最終隻傳遞了一間房。這是成本；
- 要求豪宅，最終公廁。這是品質
做項目不是做慈善，哪怕你為了夢想參與到項目裡來，也不能罔顧客觀實際。想要兼顧快捷、低廉、優質，那這個項目是不可能成功的。如果有客戶向你提出這等非分之想，不妨把這張圖發給他。
三、範圍管理的方法路徑
項目範圍管理的方法論就三個字——“做減法”。我們做且隻做能成功完成項目所需的全部工作。圍繞這個核心理念，我們将項目範圍管理拆分成六個步驟。
- 規劃範圍管理：指導團隊如何管理項目範圍，需制定項目範圍管理計劃
- 收集需求：挖掘真實需求，建立需求與可傳遞成果及項目目标間的對應關系
- 定義範圍：制定詳細的項目範圍說明書，明确驗收标準
- 建立WBS（工作分解結構）：明确範圍基準，分解工作内容，關聯唯一責任人
- 确認範圍：明确工作結果是否可以接受，完成驗收
- 控制範圍：管理實際的範圍變更。這一過程貫穿項目始終
要怎麼控制好客戶預期，如何把握客戶的真實需求，這些需求如何落地為具體可執行的工作？帶着這三個疑問，我們往下看。
1. 規劃範圍管理
在初創型企業或者傳統家族式企業，做項目很多時候都是“一言堂”，老闆說做那就做，老闆說加那就加。可惜如馬斯克或者喬布斯那樣的天才産品經理極度少見，你的老闆極大機率并非這樣的天才。很多時候，這種一言堂會把整個項目帶進溝裡。
規劃範圍管理這個步驟，更像是為項目，甚至是為企業制定标準。這一過程的輸出，也就是“項目範圍計劃”，不僅是項目工作開展的指導檔案的一部分，更能成為企業經驗的一部分，變成組織過程資産。
一般來說，規劃範圍管理這一步需要進行如下活動：
1）制定詳細的範圍說明書
這一步驟在很多時候和項目可行性分析、搭建需求池、建立項目章程等步驟合在了一起。隻要能詳細清晰的表達出項目範圍，不用拘泥于形式。
2）确認從詳細的範圍說明書内建立WBS（工作分解結構）的流程方法
一般而言，每個公司有其通用的一套規則，項目上沿用即可。若要建立一套全新的流程，則項目經理或産品經理應對産品研發的整個流程有着非常清晰的認知，知道哪個階段應該做什麼、需要哪些前置輸入，需要哪些産出。
3）确認準許和維護WBS的流程方法
WBS建立好後應如何評審，誰來參與評審，這些都要提前定義清楚。此外，應确認由哪個崗位來維護WBS，大點的團隊一般會專門設立項目管理工程師這個崗位，簡稱“項管”，來對WBS的整體排期和進度進行追蹤，小點的團隊就隻能産品經理或項目經理兼任這個角色。
4）确認對已完成的項目可傳遞物進行正式确認和接受的流程方法
項目的階段性産出如何進行驗收，誰來驗收，驗收的标準是什麼？千人千面，适合就好。
5）明确如何對詳細的項目範圍說明書申請變更
一般範圍說明書定義清楚後不會再改動，若的确需要變更，那一般都是非常重大的改動。需明确在發生哪些突發情況時，才允許對項目範圍說明書進行變更，這一過程需要嚴格謹慎。
四、收集需求并挖掘真實需求
不可否認的一點是，無論對誰來說，收集需求并挖掘出真實需求都是一件很難的事情。
- 首先，你的客戶有着與你不同的專業背景，你們很可能并非同一行業。假設你們在為一家醫院打造業務平台，你用計算機專業的思維，去了解一些醫療行業從業者的訴求，往往雞同鴨講，互相get不到點；
- 其次，基于每個人邏輯思維與表達能力的不同，語言的表達有其固有的損耗。客戶想的是100，傳達給你的是60，你轉達給開發的是40，開發能了解并做出來的不到20，這是很常見的态勢；
- 最後，某個人在某一時刻的想法，往往隻是靈光乍現，并非真實需求。客戶本質上是一群人，且你的甲方和最終使用者往往屬于兩個不同群體。但凡是群體，就不會有完全統一的聲音。如果在收集需求時隻考慮某個人的聲音，就必然會造成需求圖譜的失真。
收集需求的核心原則，為“具體化”、“書面化”、“可測量”。需求的模糊程度越低，執行時産生偏差的可能性就越低；需求描述的越具體，驗收時發生扯皮的情況就越少。一千個人眼中有一千個哈姆雷特，為盡可能的減少分歧，在需求收集階段就要盡可能做到明确、具體，可測量，并記錄在文檔内歸檔。
1. 收集需求和梳理需求
- 訪談：和客戶直接交談，來擷取資訊。資訊失真小，但效率較低；
- 問卷調查：書面問卷，閱聽人填寫。資訊失真大，效率較高
- 會議研讨：把行業專家和項目相關方都聚集到一起，大家坐下來對産品需求進行集中讨論與建議，了解大家對所提議産品、服務或成果的期望和态度。資訊失真小，效率高，對組織能力有一定要求；
- 群體創新：頭腦風暴，再用思維導圖等形式将大家的想法做分類梳理。一般适用于創新類或示範類的項目；
- 群體決策：在已搜集到的需求基礎上，通過一緻同意原則或相對多數原則來決定具體執行哪些需求；
- 标杆對照：抄競品；
收集需求的下一步就是梳理需求，需要建立需求與項目可傳遞成果以及項目目标間的對應關系。可以借用OKR的概念對這個動作進行解釋。O即Objectives，核心目标；KR即Key Results，關鍵成果。在需求收集這個環節，項目目标就是我們的O，可傳遞成果即為KR，需求即為完成可傳遞成果所必須的步驟。需要確定所有的需求點，最終都是為達成項目目标而做的，與項目目标無關的需求要果斷排除。
值得注意的是，并不是所有與項目目标關聯的需求都需要項目組去滿足，且需求是否被準許最終是由項目發起人決定的。在一個項目裡，項目經理隻是一個被授權調用資源的“打工仔”，項目發起人才是“幕後Boss”。
2. 輸出需求跟蹤矩陣
在很多網際網路企業，産品經理往往會搭建一個需求池，服務的是一個長生命周期的産品。這個需求池和項目的需求跟蹤矩陣有一定相似之處，可以對照了解。在項目需求跟蹤矩陣中：
- 首先需要明确項目的成本中心和項目背景、目标；
- 其次以可傳遞成果為标杆進行需求的細化拆解；
- 最終對需求進行較長的描述，說明預期效果，闡明可傳遞成果、對應責任人等
五、建立工作分解結構
收集、梳理需求并關聯項目目标，是回答了“做什麼事情”，“為什麼要做這些事”，高屋建瓴的為項目成員指明了前進方向。但是我們既要仰望星空，也要腳踏實地，需要把項目目标拆解成每個成員具體該幹的事情，才能把願望落地，讓項目接地氣。回答好“怎麼做這些事情”，是建立工作分解結構（WBS，Work Breakdown Structure）的核心所在。
1. 工作分解的意義
首先必須要說明的是，不是所有項目都必須按照項目範圍管理的條條框框來執行，也不是隻有嚴格遵循範圍管理的方法論，項目才能成功。日常工作中，我們不能陷入教條主義。對于重難點問題攻關型項目，或者開創前人未有之道路的創新型項目，就不存在工作分解這一說了。大家都在摸着石頭過河，誰也指導不了誰。這就帶來工作分解這一步能正常執行的前提：必須得有一個人對項目的整個過程有着非常清醒的認知，有過相關經驗，知道在什麼時間點應該幹什麼事情。項目經理就起着這樣的作用。
正如大家都喜歡“跟我上”而非“給我上”的上司，正确執行工作分解能帶來如下好處：
- 可以建立完整的項目保證體系，便于執行和實作項目目标；
- 通過工作分解結構，項目相關人員對項目一目了然，明白各自所處的位置、所要做的事情和所需承擔的責任。友善後續進行費用、進度、績效的跟蹤；
- 能夠明确項目各方面的界限，便于責任劃分和落實；
- 為項目溝通提供依據，可用于與項目幹系人溝通項目狀态，提高項目團隊整體溝通效率；
2. 工作分解的方法
不同組織建立工作分解結構的方法不同，有兩個常見的分解工作的次元：
- 基于項目的生命周期的各階段。如一個企業資訊管理系統的傳遞類項目，往往按照需求調研——分析設計——程式設計——軟體測試——産品驗收傳遞的流程來進行，需要針對各階段的主要工作進行拆解，如分析設計階段，可拆解為資料庫設計、系統接口設計、業務功能設計等；
- 基于可傳遞成果。同樣以企業資訊管理系統為例，可以簡化為OA系統、人事系統、營銷系統、裝置管理系統等多個版塊，需要對各闆塊進行拆解。如人事系統版塊可以拆解為職工管理、教育訓練管理、黨政管理等
在對大型項目進行工作分解時，除了具體的工作内容和責任人，還可能包含以下特定内容：
- 編碼辨別。特定的序号，用于劃分層級、進行區分；
- 假設條件和制約因素。即執行此項工作的前提，及可能影響工作進度的因素；
- 進度裡程碑。完成此項工作的标志；
- 所需資源。一般指軟硬體外部環境，儀器裝置等；
- 成本估算。一般包含人力成本和直接材料成本等；
- 品質要求
- 驗收标準
在工作分解結構裡，往往會人為設定一些管理控制點，叫“控制賬戶”。可以了解為項目節點，在這個節點上需要對範圍、成本、進度進行整合分析，并與預期效果進行比對，以明确項目進度和績效。
在實際工作中，若有專門的項目管理工程師參與統籌，是可以盡量細緻的對工作進行拆分的，在設定的項目節點也可以對項目進度及時複盤。若是人員配備不足，也可酌情減少拆解的力度。
我們在這裡談到什麼是項目範圍，管理好項目範圍的意義何在，做好範圍管理的基本路徑等，核心内容就是确立了範圍管理的方法論——“做減法”。談到面對客戶時，我們要合理控制客戶預期，無論你和他們關系多麼親密，不能“寵壞”他們。
規劃範圍管理是常常被人忽視，卻又極為重要的步驟，這往往決定了這個項目組的做事基調。靠譜的項目團隊，一定會“把醜話說在前頭”，并在往後的工作中嚴格執行。
正如“慈母多敗兒”，做好項目範圍管理既是對項目團隊的負責，也是對客戶的負責。成為一個靠譜的項目經理或産品經理，從控制好你的項目範圍開始。
本文由 @Smile 原創釋出于人人都是産品經理。未經許可，禁止轉載
題圖來自 Unsplash ，基于 CC0 協定
該文觀點僅代表作者本人，人人都是産品經理平台僅提供資訊存儲空間服務。