軟體開發過程的關鍵施行細則與人員職掌
前言
本文主要的目的，是從管理學的角度，來說明軟體開發過程裡各階段的關鍵施行細則，以及人員在開發過程中應有的職責。凡是管理階層，包括研發經理、專案經理、產品經理，甚至是不懂技術的更高階管理者，都可從中了解到如何確保軟體能夠成功開發出來。由於文中某些建議的步驟，是從作者提出的研發量化績效管理所衍生出來的，因此建議在看本文之前，先看完最後一節的研發量化績效管理，會比較容易了解。
邱奕南，2019/01/21
一、軟體開發的過程
完整的軟體開發過程約可分成下列幾個階段：
其中可行性與成本效益分析是屬於前置作業，檢討與改善則為後置作業（同時亦分散在各階段裡），一般軟體工程書籍所列的開發過程，通常都不會有這兩項，也因此常會被軟體開發公司所忽略掉，故本文特別明確提出這兩個階段。至於各階段裡最重要的成功關鍵因素在於審核，因為人員常會因疲累、惰性、粗心、盲點等等眾多因素，導致執行過程有所缺漏，審核是能夠確保產出品質的唯一方式。至於各開發階段裡如何進行審核，我們後面會再詳細加以說明。
另外，除了正式文件必須納入基準開發文件外，軟體開發過程中所有的暫存文件與資料也都必須保存下來，方便將來檢討與改善時使用。包括成本效益分析報告、需求收集時記錄的原稿檔、需求規格書各審的版本與審核會議記錄、時程預估人員對各工作的預估值、研發人員時程管制表、績效報告、改善計畫等等。
二、可行性與成本效益分析
可行性與成本效益分析的目的，在於確認技術上的可行性，以及所需的人力時程成本。這個階段對於標案型的軟體專案特別重要，否則常會出現專案接得愈多反而愈虧錢的情況。
可行性與成本效益分析的主要負責人是專案經理，其施行的步驟為：
以上步驟裡，最常被忽略的，是依據剩餘研發能量來決定是否接案。研發能量不足卻硬接案，往往導致研發人員疲於加班趕工，長期下來效率不升反降，而且也容易導致研發人員受不了而離職。此外，招慕新的研發人員並無法在短期內提升研發能量，甚至還會下降，因為新進人員需要時間進入狀況，且可能需要現行研發人員額外花時間進行指導。況且適合的研發人員也不是說找就能找到，因此最好事先推估可能的研發人力缺額，然後做長期性的招募。
專案經理在評估開發成本時，除了研發部門預估的研發人力成本外，應再加上專案的需求收集分析成本，以及其他諸如辦公室租金、器材耗損費等等成本。一般簡單的估算方法，是將研發人力成本乘上2～3倍做為實際成本，這是經由統計出來最可能的成本範圍。若專案經理自己有更好的估算方法，可以提出做為成本估算程序的改善。
審核
由於本階段屬前置作業，一般無需正式的審核，但應在制度中加以規範，確認業務與專案經理有按前述步驟進行接案前的評估。
人力時程成本的預估方法
前述步驟裡，最困難的便是研發部門如何準確估算出人力時程成本。因為在需求不明確的情況下，其實是很難準確估算的，但無論如何都還是得估算，才能夠得知專案大致的成本。在一般軟體工程的書籍裡，都會提出一些以過去專案經驗數據做為估算人力時程的方法，但這類方法並不適合於沒有大量專案執行結果的小公司。底下是作者另行提出比較可行的研發人員經驗值估算法：
上述步驟裡的各項公式與數據，應在專案完成後，進行檢討與改善時，比對原預估工作量和實際工作量的差異所在，重新加以修訂，使得預估成本能夠愈來愈準確。但長期而言，研發經理應建立起工作量資料庫，將各種工作依其性質分門別類後，記錄其實際的工作量，當新的工作和資料庫中某些工作類似時，便可以直接參考套用，減少人為估算的誤差。
三、需求收集與分析
需求收集與分析的目的，主要是確認產品或專案要做的是什麼（What）。由於這是後續軟體開發的主要依據，因此這個階段可說是非常的重要。軟體開發失敗的原因，十之八九都是在這個階段發生。例如軟體功能不符預期，大都是因為需求描述得不清楚或不正確；軟體缺少了某些功能，基本上也都是因為需求收集得不夠完整。
需求收集與分析，是專案經理或產品經理最主要的工作之一，因為他們是研發部門對外的窗口。關於這個階段應採行的步驟，請參閱拙著”需求收集與分析”一文。其中”推究”步驟中提到的因果關係分析，可參考檢討與改善一節。
審核
由於完整且正確的需求規格對於軟體開發非常重要，故需求規格書必須通過正式的多人審核會議，來確保其品質。關於這個審核會議如何進行，請參閱拙著”需求規格正式審核會議”一文。需求規格書通過審核後，即可轉交給研發部門開始進行軟體開發的工作。
需求變更
需求規格書通過審核後，基本上便不能再更動了。若客戶要新增或變更需求，專案經理應該儘量予以婉拒，特別是軟體已開發到後期的時候。萬一實在無法拒絕，便必須會同研發經理與系統分析師，針對需求變更會影響到的架構、模組、程式進行評估。若需求變更不會動到原有架構，且所需的成本在可接受的範圍內時，才能允許變更，否則應建請客戶另提專案來加以修正（即從需求收集與分析階段重新來過）。
四、擬訂軟體開發計畫
研發經理接到需求規格書後的第一件工作，便是擬訂軟體開發計畫。由於這項工作常被研發經理所忽略，故特別獨立成為一個階段來加以強調。擬訂軟體開發計畫的主要目的，是要重新評估出較為準確的開發工作量（因為需求已經明確），並決定各階段參與開發的人員。以下是一些相關的注意事項：
審核
軟體開發計畫是供研發經理自行掌控人力時程之用，原則上由研發經理自行負責，並不需要額外的審核。不過這份計畫書必須納入基準開發文件中，以供檢討與改善階段時使用。
五、系統分析
系統分析的目的，是找出解決所有需求的軟體架構與邏輯解，然後拆解成適合系統設計的獨立模組（或物件），最後產出軟體功能規格書。因為系統分析不適合分工，因此最好由一位系統分析師全權負責。系統分析的方法目前有結構化與物件導向兩種，由於太偏技術面，故不在本文裡說明。
審核
由研發經理指派另一位系統分析師進行審核，審核的基本要求為：
審核的方式應採用條列式表格，列出所有應確認事項供審核人員勾稽。將來在檢討與改善時，若發現問題出在系統分析部份，便應檢討審核的勾稽項目是否不足，並予以擴增。
審核通過後，研發經理應再度針對軟體功能規格書，重新估算更為準確的系統設計、程式撰寫、測試等階段的工作量，然後調整各階段的完成日期。
六、系統設計
系統設計的目的，在於決定模組應採用什麼方法完成，並制定出各模組間的呼叫界面與資料結構，最後產出軟體設計書。因為各模組所需的技術均不同，因此可由參與的研發人員自行挑選擅長或有興趣的模組進行設計，剩下沒有人選的模組才採用指派方式。
審核
由研發經理指派一到多位資深研發人員負責審核，審核的基本要求為：
審核的方式仍採用勾稽表，列出所有應確認事項供審核人員勾稽。將來在檢討與改善時，若發現問題出在系統設計部份，便應檢討審核的勾稽項目是否不足，並予以擴增。
審核通過後，研發經理應再依照軟體設計書，重新估算程式撰寫的工作量，然後調整其完成日期。
七、程式撰寫
通常是由模組設計人員負責該模組的程式撰寫，以及單元測試。單元測試應由模組負責人自寫單元測試程式，並採白箱方式進行測試。為避免研發人員未落實單元測試，在審核時，每發現一個錯誤，便應調降撰寫人員的部份績效值（例如酌減其完成工作量），以做為懲處。
注意人機界面模組一般需採用人工方式測試，且在撰寫程式時，應協同專案經理與美工決定顯示畫面與操作流程，切勿自行決定。
審核
由研發經理指派一到多位資深研發人員負責程式碼審核（Source Code Review），審核的重點包含下列幾個部份：
審核的方式均採用勾稽表，列出所有應確認事項供審核人員勾稽，不同的程式語言應各自有其勾稽表。將來在檢討與改善時，若發現問題出在程式撰寫部份，便應檢討審核的勾稽項目是否不足，並予以擴增。
模組負責人除了繳交模組程式碼外，也必須繳交單元測試程式，納入基準開發文件中。單元測試程式不必經過審核。
八、測試
本階段指的是整合測試（單元測試應在程式撰寫階段完成），基本上需包含以下三個層面：
審核
測試人員繳交測試報告、測試程式，由研發經理檢閱無誤後，納入基準開發文件中。測試過程中若有測試到任何錯誤，均應加以檢討其原因（為何前面階段未審核出來），然後進行改善。
整合測試完畢後，應將軟體連同測試報告，交由專案經理進行鑑定測試，確認所有需求都有被正確實作出來。通過鑑定測試之後，專案經理要安排研發人員到客戶處安裝軟體進行驗收測試，同時協調其他部門進行產品交付工作，例如使用手冊印製裝訂、軟體壓製、教育訓練、驗收等等。
九、檢討與改善
PDCA循環是品保制度中最重要的一環，藉由檢討執行過程的缺點來持續加以改善，以提升產出軟體的品質，無論是ISO或CMM認證都是必備的條件之一，因此特別以獨立的一個階段來加以強調。事實上，檢討與改善並不只侷限在軟體開發完成之後，在開發過程的各個階段都應持續進行。即使在軟體交付給客戶之後，客戶任何反應的問題，也都必須進行檢討與改善。
檢討與改善問題時，不可直接針對問題進行改善，否則只能治標，無法治本，必須找出問題真正的原因來加以解決。尋找問題發生原因的方法，一般都是採用魚骨圖，但文件裡要畫圖是很麻煩的一件事，故作者提出另一種變形的因果分析方式：
以下是作者的一個案例（正式需求審查會議檢討報告）：
編號 問題描述 引發原因 原來問題 1 議程時間超過預期 2,4,5 2 有離題的討論 6 3 會議中有提出新的需求 6,7 4 會議中人員流動頻繁 1 5 未能準時開會 - 一階原因 6 事前未充份閱讀需求規格書並反應問題 8 7 需求收集時未與人員充份討論 - 二階原因 8 需求規格書太晚發出 -
由於根本原因是需求規格書太晚發出，導致審核人員事前未充份閱讀，因此拙著”需求規格正式審核會議”一文的會前準備事項，便增列了”至少要在會議前三天便將需求規格書送交審核人員，並持續追蹤所有人員均已進行過預審”一項。所有制度流程，都是透過這樣不斷地檢討改進，才能愈來愈完善。
進行因果分析時，其最終根本原因通常都會指向兩個：一是經費不足，一是人力不足。這兩個根本原因基本上是無法完全解決的，故在改善計畫中可略過不理。
除了問題的檢討與改善外，研發經理在各階段工作完成後，還必須進行下列反饋修正的工作：
審核
檢討與改善的過程，通常由品保人員確認有按制度進行，若無品保人員，則由研發經理負責。而檢討與改善的結果，均由研發經理負責納入研發制度的改良之中。
十、人員職掌與研發管理制度
專案經理職掌
研發經理職掌
其中第一項是最困難的工作。為了準時完成軟體開發，研發經理視情況不免必須親力親為，於是軟體工程、資訊理論、技術能力，都是研發經理必備的技能，再加上管理知識，以及細心、責任心的人格特質，好的研發經理其實非常難求。但要切記是，研發經理不可因為參與開發，過於忙碌而疏忽了人員的管理，這是一般研發經理最常見的通病。要知道研發經理的責任在於提升整個研發團隊的戰力，雖然研發經理本身也是團隊的主要戰力之一，但仍必須從整體的情況去做折衷。因此在指派開發人員時，若研發經理也參與在內，最多只能佔用一半的時間，另一半的時間必須預留做為管理，或處理其他突發狀況之用。
此外，研發經理必須要有賞罰的實權才能做好管理的工作，包括徵人、起薪、調薪、開除（資遣）等。若只是有責無權，再厲害的研發經理也難為無米之炊。當然，若研發經理只會當好人，礙於情面不敢或不願開除績效過差又不改進的研發人員，一樣也不適合做為管理者。
研發量化績效管理
名詞定義：
管理方式：
這種以量化績效為導向的管理模式，可以簡化許多管理的工作，不必去考量人員是否遲到早退、加班、懶散等問題，只看人員是否達成績效即可。在作者的實戰經驗裡，已驗證是一種相當良好的管理模式，但前提是研發經理要有足夠的經驗與很強的責任心，按前述步驟確實執行，否則很容易流於形式（例如放任寬估工作量導致所有人員都績效良好）。