文⊙李延華
軟體開發方法論的每個學派，都有一堆的理論基礎，不僅學習不易，而實作上也有許多的限制。那麼撇開深奧的方法論不談，軟體專案有沒有一些基本的準則，就可以提高「永保安康」的可能性？
鼎新電腦技術總顧問周忠信認為：「至少把握需求管理、專案管理、建構管理與測試管理四個最基本的原則。」對於一般的企業而言，以上4個重點就足夠了。
中山大學資訊管理系教授鄭炳強則建議：「能力優良的工程師、用戶需求的深入分析、確實的系統設計與風險評估。」
鄭炳強表示早年剛開始接觸軟體專案時，曾經經手幾個成功案子，反而種下失敗的因子，所以後來遭遇幾次嚴重的失敗，原因是缺乏風險意識與風險管理，以及對於技術能力的過分自信。所以鄭炳強強調：「光有技術其實是不夠的，軟體開發還有許多比技術更重要的東西。」
曾經有軟體廠商抱怨，某個公家機關標案的需求文件，內容竟然只有標題。對於軟體公司而言，若有風險意識，應該要拒絕此類的專案。
先做好需求分析，否則其餘免談
研究與開發CMM與PSP（Personal Software Process）的Watts Humphrey曾說：「在客戶催促的時候，大部分的工程師就會下意識地做他擅長的事情－Coding。」但若不能在一開始把事情「做對」，後面再多的努力都是白費。
寫程式只是實作設計的過程，跳過前一階段最重要的需求分析與系統設計的過程，是捨本逐末的行為。軟體開發就像開車，若未確認目的地的方向，便一路往前衝，或者抱著且戰且走的心態，便可能多走冤枉路。
IT工程師不如水泥工？先反求諸己
在建築業確認藍圖之後，便依圖施工，客戶不會說：「你先蓋給我看，不喜歡再拆掉重蓋。」但軟體領域，使用者卻有可能隨時在推翻之前的想法。
當水泥工表示：「水泥需要3天才會乾。」大家不會質疑水泥工的說法；但是軟體專案卻經常面臨客戶縮短工時的不合理要求。
IT工程師的專業不如水泥工嗎？目前軟體業正流行CMMI，廠商在努力調整體質的同時，卻也常抱怨：「廠商已經進步到Level 3了；而客戶卻還在Level 0。」對於客戶不合理的要求，或者想法改來改去的善變心態，寶發科技總經理胡佑長認同：「好的需求管理是甲乙雙方共同努力的結果。」（甲方：軟體購買者；乙方：資訊服務廠商）目前政府在大力推動CMMI-AM（Acquisition Module；籌獲模組）便是針對甲方的訓練，希望提升客戶端採購軟體應具備的相關能力。
不過，甲方的改變需要很長的時間，所以胡佑長提出更積極的建議：「乙方可以教育甲方。」甲方不了解軟體開發的「學問」，所以並不明白改變可能造成的影響，如果乙方有很好的流程，或可以提供量化的數據，便有機會說服甲方配合。
景華管理顧問資深經理李吟敏認為：「甲方是需要被教育的，但是怪罪甲方是單方面不負責任的行為。」需求的導出與確認是一門學問，臺灣從學校到企業，這方面下的功夫都太少。在國外的大學，需求分析稱之為「Business Analysis」是兩個學期的課程，每周都出一個題目，學生要學習分析與拆解，並提交完整的報告。
瞎子摸象才導致事倍功半
中山大學資訊管理系教授鄭炳強與學生開會時，都會要求學生記錄會議內容，整理成正式的文件；無獨有偶的，李家同也曾提到要求博幼基金會的小朋友看偵探小說，看完後寫出破案關鍵。會議記錄與讀書心得，都是釐清重點的訓練。使用者對於需求的表達是零散的，導出完整而正確的需求結構，是資訊人員應該具備的專業能力。
鄭炳強強調：「需求分析不只是資料搜集的工作。」純粹資料搜集的結果，就是一項需求對應一個功能，但若理解需求背後是解決何種問題，那麼也許只要10個功能就可以滿足100項需求。「報表」或「功能」只是滿足需求的「手段」而非目的，如果沒有了解背後的意義，就如同瞎子摸象，透過局部的印象，拼裝架構零散的系統，不僅事倍功半，而且開發出四不像的系統。
需求頻繁改變，很可能是因為始終沒有「搔到癢處」，需求分析不只是知道功能該如何運作（How），更要知道為什麼要這樣做（Why），才不會反客為主，被客戶牽著鼻子走。掌握領域知識（Domain Knowledge），贏得客戶的信任，就能主導專案的走向。所有的需求回溯到源頭，該掌握的是產業的精髓，知道客戶的痛才能對症下藥，否則頭痛醫頭、腳痛醫腳，只是治標不治本，才會如此的勞民又傷財。
e化若是競爭力的關鍵，改變是合理的
恆變是IT界唯一不變的現象，事前縝密的需求分析，可以避免大部分使用者說錯，或者開發者意會錯，所導致誤差的情況；然而另一個難解的問題是「Ｉ will know it,when I see it.」當使用者真正看到系統時，才能確認是不是自己想要的，或者又衍生出更好的想法。
鼎新電腦技術總顧問周忠信表示：「軟體界應該認清『變』是合理的現象。」如果e化是協助企業獲利的機制，那麼市場在變，沒道理要求客戶不能變。
若改變是必然的，那麼該著眼的是變更管理，以及讓客戶了解軟體開發的過程，認知修改的時間與金錢具體成本。軟體工程師的說服力不及水泥工，會被討價還價的原因，某種程度是因為軟體開發的過程比較抽象，是看不到也摸不到的。
新的需求引發額外的費用比較容易理解，而需求的修改就必須定義出變更的複雜性與影響的範圍，若能提出具體量化的數據或分析，使用者對於付費或延期交付的接受度便會提高。
