不要“寵壞”客戶:談專案範圍管理

成為一個靠譜產品經理,必然要做好專案範圍管理,這既是對專案團隊的負責,也是對客戶的負責。為什麼這麼說,範圍管理又有哪些方法路徑?一起跟著這篇文章來了解吧,希望對你有幫助。

不要“寵壞”客戶:談專案範圍管理

在一位產品經理的工作生涯中,只服務於一款產品並不常見。反而在大多數時候,很多產品或服務是以專案的形式進行交付的。這就要求我們在工作過程中熟練掌握專案管理的方式方法,並將專案管理理論與產品經理工作實際結合起來。

下面我將從專案伊始的範圍管理開始,帶你領略網際網路行業的專案管理,希望籍此你也能掌握一定的方法論並運用到往後的工作中去。

記住,只要你想完成你手頭的專案,無論你和客戶的關係多麼親密,不要“寵壞”他們。

一、什麼是專案範圍

在日常工作生活中,評判一個人是否靠譜,有兩個很重要的評判因素“邊界感”和“分寸感”。做人做事沒有邊界感,從小的方面看容易冒犯他人,讓自己顯得粗魯莽撞;從大的方面看也容易越俎代庖,幹出不合規矩的事情。而缺乏分寸感,就會對事情的輕重緩急拿捏不清,重要的事情不做,反而在無關緊要的小事上鑽牛角尖。

專案的範圍,其實就是專案的“邊界”和“分寸”。專案範圍定義了哪些工作應該包含在專案內,哪些不應包含在專案內。

做好專案範圍管理,就是確保做且只做必要的事情,這些事是成功完成專案所不可或缺的

。簡言之,能用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 協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供資訊儲存空間服務。

頂部