-
樓主 / 板牙
- 時間: 2009-6-22 15:30Coding 人生滿員了加不進去，只能發到這裡來冒泡。。。
Scope Management - 項目范圍管理說起來很簡單，通俗的說就是定義個項目要做的框架目標，不能超出范圍，也不能偷懶少做。但是具體操作起來卻是異常困難，這是每個顧問，商業和系統分析員，程序員，實施人員和team lead在做項目的時候都會遇到的一個大難題。
這裡概括了一些重要要素之後分享一些實例，讓我們來交流交流。
項目范圍分幾個階段：
1. 項目（產品）目標和需求分析
2. 項目范圍的估計
3. 項目范圍的監控
4. 項目范圍達標的階段總結(Deliverables)
其中，第二項對經驗的要求很高，而第三項對內部和客戶溝通的要求很高。這兩項難度最大而且有相關性 - 原因是很多公司裡做這兩項工作的不是同一個甚至不是同一部門的人。
那麼，根據什麼要素可以幫助我們知道項目的范圍是什麼？
1. 需求和設計文檔；
2. WBS - Work Breakdown structure 具體在project plan裡面
3. SOW - Statement of work - 項目合同 （如果是內部項目，通常包涵在需求文檔中）
一個問題可以會問：我只是一個實施或者編程的人員，這個我需要了解嗎？我只需要做就好了吧？答案是：絕對需要！！！
因為一個做的東西是否在范圍之內，通常是由這些人員反饋上來的，而很少由PM或者管理人員反饋出來，他們只是根據反饋來做決定而已。所以很大程度上，項目有時候的成敗與否或者質量高低，項目人員所有人都是一個整體，就是這個道理！
實例分析（真實例子）----------------
問題所在：
在給客戶做實施過程當中，發現某安全產品A如果開啟某功能的時候，另一集成產品B某一個功能不能工作，但是B的這個功能是必須的，是最重要的需求之一，不能省略。
解決步驟：
1. 實施人員以書面或開會形式反饋到PM，找出解決這個問題的options並列出所有的pros and cons, impact 和 cost (hours)。
2. PM列出所有options與客戶溝通並讓客戶決定option;
3. 客戶Option定了之後, PM立刻寫出正規的PCR (Project change request)讓客戶批准。
後話：
這個120個小時/人的PCR由於是產品內部功能造成，所以並沒有被客戶接受，但是這個PCR仍舊以 0$ PCR提交到客戶手中作為 Value-added effort被認可，實施人員也得到客戶的認可和thank-you letter。
-
-
- 時間: 2009-6-22 15:33
-
-
- 時間: 2009-6-22 15:39
-
- 時間: 2009-6-22 15:40
-
- 時間: 2009-6-22 15:41
-
- 時間: 2009-6-22 15:43
-
- 時間: 2009-6-22 15:44
-
- 時間: 2009-6-22 15:45
-
- 時間: 2009-6-22 15:46
-
- 時間: 2009-6-22 15:48
【原創】PM 體會 （續一）- 項目范圍管理及實例操作
）