專案管理是一門目前非常主流的學問
也是近20年都沒辦法有突破性發展的一門學問
為什麼會這麼熱門
就在於舉凡你想的到的計畫都可稱為專案
我曾經看過一個為專案下的很好的定義
『生活中遇到的一些複雜計劃，需要用圖解來說明；也許是方塊圖，說明計畫的目標，以及達成目標的必須完成的各個步驟，以及什麼步驟必須依照順序，什麼又可以並行。又或者用圖表，顯示每個步驟應該開始和完成的時間。這樣的計畫就可稱為專案』
而有一個讓專案管理熱門更重要的原因
問問身邊每一個參予專案的人吧
得到的往往都是失敗的結果
成功者也都或許是運氣好
因此可以看到越來越多的認證
希望透過制式化的管理加快SW development process的效率及速度
也越來越多的開發流程
希望能成為殺死存在SW project leader心中恐怖怪獸的銀彈
然而這一切就有如人月神話的作者所說
軟體開發很難在10年內有一個數量級的進步
軟體開發也不會有仙丹馬上解決大家的問題
然而軟體開發真的沒進步嗎？
當然不是
而是軟體的需求進展的更快
越多人需要更強大的功能、更複雜的系統
因此越來越多的人需要共同開發project
越來越多的function被involve到整個系統中
這都使得軟體開發越來越複雜
因為人力的增加
溝通成本是呈現數量級的成長
因為function的增加
開發時程的規劃也越來越複雜
越來越多的critical path
使得軟體開發仰賴著精確的時程規劃
一個不精確的時程造成的絕對不只是自己的delay
而根據制約效應更會造成整個project的delay
所以如何能夠得到正確、可依賴的project schedule正是專案管理人員的一大課題
目前有許多方法來盡量得到可信的schedule，下面將一一介紹
1. Lines of program:
這其實也是最早以前的時程規劃所用的方法，如字面所說，評量的依據主要就是程式的長度，其實這當然有他的道理，程式越長似乎也代表著需要寫code的時間越久。這在以前的時代是蠻正確的，因為以前的programmer得把程式刻成一張一張的程式卡，所以越多的程式碼也意味著需要更多的時間來做程式卡，即便是兩個相似功能的function，也因為得分別刻兩份而使得時間接近兩倍。然而現在的程式開發，透過模組化提高reusability，Object-oriented的概念，使得開發兩個相似的模組並不用需要到兩倍的時間，這樣的估算的方法已不再實用。
2. Feature point:
在此，不在仰賴program的長度，如前頭所述，program的長短在現今已無決定性的影響力，因此取而代之，使用feature point或許是一個比較好的選擇。所謂的feature point就是所有需要implement的feature，利用把整個功能細化的動作，我們可以盡量的將整個item細化成最小單位大小的數個小working item，再利用找出它們之間的dependency relation，便可以找出所謂的critical path，也可以知道project的最少完成時間。
一切都很完美不是嗎？如果是的話，那也不會有那麼多死在沙灘上的project了。雖然我們可以得到最後critical path所有經過的feature point，再利用它們的數量得到一個比較可信的schedule，可是有些feature point就真的是所謂的atom item，是不可分割的，面對這樣的feature，如果我們還是把它當一般的feature point一視同仁，那就會造成整個schedule的不正確，也因此我們以此方法為基礎，改良為下一個方法weighted feature point。
3. Weighted feature point:
所謂了Weighted feature point，就是給予每一個item加權，利用加權的方法來允許一些比較大的working item存在，而最後所要計算的不是feature point的數量，而是total feature point的weight。
說了這麼多，所以利用上述的方法我們就可以得到非常可信的schedule，將會確保我們的project走向成功的道路，
『停...3秒鐘到了，夢該醒了』
只要依賴上述的方法就可以得到可信的schedule就跟緣木求魚一樣，一個schedule的正確性不只依賴計算方法、機制，更重要的是人的問題。
有些人豪情壯志，估起schedule都彷彿全世界都不會有打擾他的事情產生，不會生病，不會請假，得到的schedule，你只能期望在那時間點可以得到可以work的第一版本SW，也許這都還有可能是一種奢求。
然而也有些人非常的保守，每一個working item估的都非常保守，得到就是一個完全不可能獲利的ship date；也許你的確可以在那時拿到一個非常穩定的產品，不過你應該也已錯過了最有競爭力的時間點。
簡單的說，任何的schedule都必須在積極和保守間取得妥協，一個可行且具有挑戰的schedule才會產生一個具有競爭力的產品。
而該如何面對一個浮誇且不確切的schedule，那又是另外一個課題了，也是所有project leader的痛。也許下次我們可以再好好討論這一點。
沒有留言:
張貼留言