軟體開發之專案管理﹣經驗亂談（一）

     最近因為承接了某大型軟體開發案，時程開發案停滯無法前進，幾乎承接軟體開發的程式設計師都無法繼續進行，開發團隊內部士氣低落、出現小爭執，每個人多少產生一些憂慮，還好這次組成的團隊都是真的經驗老道的，抗壓性極強大無比，隨時都可以因為專案的政治因素、技術因素，而內部激勵改變......,

        剛好最近也抽空看了前陣子買的一本極度暢銷書 「人月神話」﹣40週年紀念版，就開宗明義的說，專案管理最大問題之一就是所謂的 「專案時程安排的重要性 」，儘可能的初期規劃時程、所需人力都在合理範圍，不過當過專案經理的人都經歷過，合理時程範圍可以說是神話一般，客戶端的壓力、預算壓力，所以為了可以接到客戶的訂單，打死都要充胖子 ，即使明明開發時程明明需要 二 年也會變成縮短（甚至一半時間為 一 年），而這樣的死刑是每天都上演在軟體專案裡，很多專案主管都認為等到開發時程延遲，就快點花錢找新人、找武林高手，可是呢？？？？結果呢？？？專案時程延遲的越來越嚴重，人力預算也投入了，怎麼效果沒預期那樣，第一，當多加一個人力，溝通的時間是相對增加的；第二，即使再厲害的武林高手，也是需要一段時間去了解現行軟體的框架、領域知識（Domain-KnownHow)，這前題下是之前SA分析的文件、SD開立的規格都是有高水準的，但通常都是...客官們你們知道的 ，有些專案更本因為時程的壓力，程式開發人員根本早就不遵守規則，UI界面層出現存取SQL語法、長長的if...else...程式碼，這種狀況下，資深高手也只能.....時間還是延遲，打掉重練，不然只能跟上帝禱告吧！

     [人月神話]很清楚的表達，無止境的加入人力已經延遲嚴重專案裡，不會比知道時間估算錯誤，坦然面對調整後續的專案時程規劃，來的有效率。

再來成功的軟體專案，都是需要成熟穩定極佳的框架，這可以達成開發一致性、有效率，專案管理溝通過程是需要透過文件來溝通，而不是省略該有的分析文件用口述的方式，這是莫大的災難啊！軟體專案你偷工減料少了那些該做的事前工作，相信我後面一定會加倍奉還 ，軟體專案真的就是類比開發建設案（蓋房子啦），你設想你少了好的建築圖、設計圖，然後口述跟A工人說你去怎麼做、B工人你怎麼做，大家各自做各自自己認為的樣子，結果.....失敗中的失敗.......

網智數位﹣軟體開發