多專案管理-資源管理(3)

在產品專案的規模不斷擴大的時候，我們更加強調崗位和角色的專業化分工。但是在專案和團隊中仍然存在著可以兼職多種角色的通才，他們的業務和技術都比較全面能夠勝任專案團隊中的多種角色。而多專案管理中過的資源替代正是由於存在這種可以兼顧多個角色的人員而產生的，資源替代的目的仍然是為了解決在瓶頸和關鍵資源出問題後的替代解決方案和措施。

在考慮多專案的資源平衡和資源衝突的解決時候，我們需要首先建立資源替代關係。資源替代存在單項和雙向的多種關係。比如在軟體開發中業務需求分析人員可以兼職做測試人員的工作，而測試人員往往並不能做需求分析，這就是一種單項替代。而對於設計和編碼往往就是一種雙向替代，編碼可以做部分設計，設計到了編碼階段也可以承擔部分編碼工作。建立了資源替代後就能夠幫助我們更好的分析哪些是瓶頸資源，瓶頸資源即是哪種不能被任何其它資源替代的獨有資源，這種資源在資源分配中必須進行優先分配。

前面考慮的是研發過程中的單個活動或任務的資源替代，如果是研發過程中的整個階段都需要完全替代則就類似於生產過程中的替代工藝路線的概念了。也就是說單個活動上的資源進行替代後需要引起上下游上相關活動資源一起替換，相互之間才能夠協調。資源替代改變了傳統的無限申請資源的思路，而是需要我們多去考慮如果更加有效的去提供資源的使用率。研發效率的提高一方面是資源生產率的提高，而另一方面就是資源利用率的提高。

如果一個3個月的專案收尾的時候釋放資源，但是隻能夠釋放3周時間，3周後專案的一個新階段或二期就會接著開始。而需要這個資源的其它專案往往需要2個月，這個時候仍然存在了資源衝突和無法利用的問題。因此前面我們提到資源週期的粒度最好能夠細化到周，而專案的週期也需要考慮和資源的最小粒度週期如何配合。這就涉及到了在組合專案選擇的時候，不能全部都選擇大型和長期佔用資源的專案，往往還需要選擇些時間靈活和週期較多的小專案配合，這樣的話一些較短的資源空閒時間段就能夠很好的得到利用。

迭代式的版本規劃和開發已經是我們在應對大型專案中常用的方法，這不僅僅是為了降低專案的風險，更重要的就是通過迭代將大專案這種粗粒度進行了細分，細分為了多個細粒度的小專案，而這些小專案都有明確的產出和價值創造，小專案由於專案週期較短自然對某些資源的佔用時間也會較短，這樣就更加利於我們充分有效的利用資源空隙時間。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/15027599/viewspace-465952/，如需轉載，請註明出處，否則將追究法律責任。