曾經在一間大型機構裏參與一個巨型項目，事實上項目本身並不巨型，或者說可以有很多方法令它不致變成如此。純粹是一個產品平台的換代項目，不過經歷多次人為影響，一個平台換代項目竟然要整個機構差不多一半的IT系統作出改動，二十多個用戶部門/sub-team需要參與，每周開一次項目例會要有二三十人來，一開就是一整個下午，在我首次接手這個項目的時候，對這種狀況當真有種嘆為觀止的感覺 ...
接手了項目一段頗長時間後，終於漸漸看出苗頭，了解這個項目的一些背景發展。（寒戰 - 梁家輝：第一步，你要學會它。第二步，從中找出一個線頭。）這個項目之所以變成這個模樣，主要原因就是沒有做好範圍管理 (scope management)，甚至可以說它是反其道而行，把本來應該是十數個項目放在一起，以一個項目來推行。這個項目無論從渠道、從產品，以至從客群來看，都有多種方法可以把它砍件，拆開幾個phase 進行，就算項目的理想有多遠大，只要把項目有效分割，分段進行，始終會可以完成，不知為何一定要一起推進，而每個細項則是龜速移動。我當時舉了「沙中線」作為一個對比，「如果沙中線一直未能通到中環，難道到紅磡的路建好也不允許通車？」，除了用「無知」和「好大喜功」來形容，也找不到更好的原因去理解這件事。（筆者註：在多次問題出現後，上星期鐵路通到啟德就已經通車了）
嘗試了幾次在不同階段希望遊說各方把項目重新砍件分phase，結果也失敗了，大概是沒有人願意承擔起當初「建成」這個項目的責任，或者沒有人願意說自己做不起這個巨型項目吧。最後我也放棄了遊說工作，基於我相信的「小改變 大改善」法則，我改為在這個項目做了一些「小改變」，可以說是沒有辦法中的辦法。
首先一個改變，是把項目分拆成多個條線，當中包括按產品劃分，按渠道劃分，按客群劃分
安排好了條線，就是安排團隊，每個條線按其domain加入product owner及相關IT人員組成主幹，工作目標為重新定義或細化需求，落實開發及測試驗收，各團隊則按自身需要編配開會時間跟進項目進度。這樣做，各團隊就可以重建自己的項目及職責範圍，合理定義工作進度，上面一層則主力監察有否出現沒有團隊跟進的灰色地帶，以及處理不同團隊出現相互有dependence 的情況。
做這幾個小改動的首要目標，就是要把工作分派出來，由專責團隊人員承擔。大家才是各自domain 的專家，最有資格去決定需求和系統方案，旁人加把嘴給些意見可以，但絕不能dominate這個討論。
另一重要作用則是減少開週會的時間，這裏本來就是不同的項目團隊，本身關連不大，放在一起開會是沒有意義的，只會浪費大家時間，把問題放在周會上討論，更加是風馬牛不相及（況且周會大多數時間也是個別數人討論個別幾個問題，效果有多好可想而知）。後來這些團隊索性直接在自己的sub-team 裏解決問題，解決了就完事，也不再在周會上報告，省回不少開會時間做更多正經事情。
整理這些經驗，嚴控項目範圍的主要目的：
1. 控制範圍，以便建立團隊
2. 責任與榮耀到人：團隊由具domain knowledge人員組成，並為製成品負責
3. 由團隊制定合理時間表，然後 commit schedule，最終合併成整體項目時間表
就這樣，PMP中的四大重點 - Scope, Schedule, Cost (人力成本), Quality, 就基本確立了
後記：
雖然進行了一番改動，畢竟項目整體範圍並沒有因此而收窄，而且這些改動也是在幾個dominator 離開之後才能正式推動，這個項目在進入UAT階段後，也經歷了慘不忍睹的黑暗狀況，這些經驗會在另一篇blog 繼續整理。
沒有留言:
發佈留言