十分鐘活用專案管理07 – 範圍管理 Scope Management

2015-08-21_000455

傳統的PM只管專案,不管產品,所以可以學醫生很大聲的說:手術(專案)成功,但是病人(產品)死了,因為產品好不好是產品經理他家的事。而傳統專案經理也不好幹的是,要團隊正式跑專案前瞎掰準備好全部的工作事項。

範圍(Scope)又可以細分為產品範圍(Product Scope)和專案範圍(Project Scope)。

產品範圍就是完成的產品、服務或結果,要哪些特性(Features)跟功能(Functions)。而專案範圍是要完成產品範圍的話,需要做哪些工作,專案管理聖經PMBOK中也把範圍管理局限在專案範圍。

但身為新一代的敏捷開發團隊,怎麼可以不管產品死活呢。所以在敏捷開發中談範圍,第一個是找出產品需要的Features跟Functions,然後才談要完成需要哪些工作。具體呈現在Product Owner負責的產品待辦清單(Product Backlog)上的Items ,和開發團隊負責的衝刺待辦清單(Sprint Backlog)上的Tasks。

所以成功的範圍管理,是問如要創造成功的產品、服務或結果,那這些需要什麼功能或特性?而要完成這些功能或特性,需要做哪些工作?并控制好只做這些工作,把時間花在刀口上。

工作分解結構(WBS – Work Breakdown Structure)

從上到下拆解完成專案所需的功能和工作。把晚餐為例子,假設家裡有媽媽,爸爸,小明,小莉。work break down

Scope Management Processes

No 流程 說明 舉例
5.1 Scope Planning

範圍規劃

產出如何定義、確認和控制專案範圍的計劃 定出規則:晚餐要吃什麼由媽媽提出。不同意的人就換他煮。分量以吃的完,不留隔夜為原則。
5.2 Scope Definition

範圍定義

產出專案範圍說明書 媽媽說晚餐是蔥花蛋一盤,麻辣豆腐一盤,空心菜一盤,白斬雞半隻,白飯四碗
5.3 Create WBS

產出WBS

產出工作分解結構(Work Breakdown Structure) 買食材:蛋一打,蔥一把,空心菜兩把,麻辣豆腐跟白斬雞外帶
煮飯:煮白飯,洗菜,煮蔥花蛋,炒空心菜,煮白飯,加溫麻辣豆腐
吃飯:每人一碗白飯,菜擺盤子上放餐桌中間
洗碗:4個盤子,4個碗,4雙筷子
5.4 Scope Verification

範圍驗證

讓範圍被正式接受 媽媽提出的大家一致通過,因為沒人想要煮。
5.5 Scope Control

範圍控制

控制專案範圍的變更 媽媽買菜時發現蔥太貴了,把蔥花蛋變成煎蛋。又接到電話爸爸要加班不回來吃,就不買麻婆豆腐。剩下來的菜和飯給爸爸帶隔天便當。

常用工具

1. 排序

把功能和特性需求從1,2,3,4,5…….照重要性順序排列下來,然後按照順序施工。很簡單,很有效,但沒多少人做(老師講都沒人在聽)

2. 莫斯科分析(MoSCoW)

把想到的功能和特性,找重要利害關係人分類

  1. Must Have: 打死都要有, 沒有的話,產品就別想上線
  2. Shall Have: 最好要有,沒有也可以上線,有上線我會很感恩
  3. Could Have: 有也好,沒有也沒差,你很閒就做,不過做了我也不會感激你
  4. Won’t Have: 不會有,等下次發佈我們再來談

3. Kano 模型

把使用者的需求分為

  1. Basic 基本型需求:
    1. 連這都沒有,沒水準,下次不來了。
  2. Performance 期望型需求:
    1. 一分錢,一分貨。我花錢就應該有。
  3. Excitement 魅力型需求:
    1. 太令人驚訝了,連這個都有。

隨著時間推移,一個需求會從魅力型,變成期望型,最後成為基本型,所以東西做不完啊。

4. INVEST原則

每一個要開工的產品工作事項(Item)要符合INVEST原則

  1. Independent 夠獨立
  2. Negotiable 凡事皆可談
  3. Valuable 有價值
  4. Estimate-able 可估計
  5. Small 夠小
  6. Testable 可以驗證做完了

5. MVP(Minimal Viable Product)最小可行性產品

投入最少的資源,用最短的時間,把產品推到市場上,盡快取得使用者反饋來決定下次應該推出的功能。

常見迷思

1. 範圍打死都不能改

在一般專案中,時間、經費、人力等等因素都比較難變動。反而範圍是最容易、也最應該被討論和修改的。

2. 多做多好

做出超過的範圍,專案術語叫幫專案鍍金(Gold Plating)。不是越多越好嗎?這是錯誤的認知,成果要超出使用者和利害關係者的期望,但不是做超出專案所需要範圍的工作。

圖片來源:

醫龍第一集

https://christiandenard.wordpress.com/2010/02/16/work-breakdown-structure-of-making-dinner/

作者: Yves Lin

Trying being agile in the fun way. 喜歡并相信敏捷,期許能帶入一些不同的思維,能讓華語圈不只軟體產業,都可以更敏捷。

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s