作者：中華軟協品質委員會 陳皆成諮詢委員
三、帶兵要帶心
軍中有兩句話：「帶兵要帶心」、「練兵要練心」。對於公司高階主管而言，更應該瞭解此一道理。
任何制度的推動建立，必須去瞭解員工的心態及需求。並且針對員工的心態及需求，去謀求適當的「解決之道」。運用適當的溝通、觀念的灌輸、建立共識、採取適當的獎勵措施…等等，透過適當的「管理手段」來解決。
「軟體發展制度」的建立，是「管理」的問題，而非「工程技術」問題。有怎樣的體制，就會有怎樣的人及心態。因此，制度推動的過程中，「人事制度」似乎也要做某種程度的調整。否則，變成凡事皆「來硬的」，以「高壓手段」來推動，往往成功率不高，而且可能會有後遺症。
這裡所說的「人事制度」是較為廣義的，可包含若干內容：
‧人員升遷管道。 ‧人員輪調制度。 ‧職位的權責相符。 ‧獎勵制度。例如：考績、獎金、加薪、分紅、持股、…。
四、如何與人事制度相結合？
「軟體發展制度」如何與「人事制度」相結合？以下，我們提出三種可能的方法：
‧針對工作項目，設立相關職位。 ‧採行適當的升遷及輪調制度。 ‧採行適當的考核及獎勵制度。
(一)針對工作項目，設立相關職位
以美軍規範DOD-STD-2167A為例，在其一般需求裡，我們可以看到軟體發展過程中，有某些重要（較具獨立性）的工作項目要做，如「表二」所示。
表二：DOD-STD-2167A一般需求
|
功能項目
|
一 般 需 求 項 目
|
|
軟體發展管理
(Software Development Management)
|
●履行符合「合約」要求的軟體發展過程。
●執行／支援各項審查與稽核。
●準備「軟體發展計畫書」(SDP)，並嚴格遵循之。
●貫徹風險管理程序。
●遵守合約安全需求。
|
●確保分包合約產品符合主合約之要求。
●依據合約，與IV&V承包商相互溝通。
●建立並維護「軟體發展館」(SDL)之正常運作。
●實施矯正行動過程。
●準備各項問題報告及變更報告。
|
|
軟體工程發展
(Software Engineering)
|
●採用系統化及有正式文件記錄的軟體發展方法。
●建立「軟體工程環境」。
●識別並分析出各項潛在危害條件。
●考量「非發展軟體」的使用。
●將各個「軟體型態項目」(CSCI)細分成若干「軟體組件」(CSC)及「軟體元件」(CSU)。
|
●以文件記錄各需求項目的可追溯性。
●採用必要的或經核准的高階語言。
●實施設計與程式撰寫標準。
●建立各CSCI、CSC及CSU之「軟體發展檔」(SDF)。
●監控各項處理資源的運用及儲備容量的運用情形。
|
|
正式鑑定測試
(Formal Qualification Testing，FQT)
|
●在「目標電腦」(Target Computer)上執行FQT。
●準備「軟體測試計畫書」(STP)，並嚴格遵循之。
●建立「軟體測試環境」(STE)，測試STE中的各個項目。
|
●確立FQT各項活動的獨立性。
●以文件來記錄各「需求項目」到「測試個案」之間的可追溯性。
|
|
軟體產品評估
(Software Product Evaluations)
|
●評估各「交付產品」(Deliverable Product)。
●確立各產品評估活動之獨立性。
●內部協調交付前各個「交付項目」(Deliverable Item)的最後一次產品評估。
|
●準備及保存歷次之產品評估記錄。
●採用各項評估準則。
|
|
軟體型態管理
(Software Configuration Management)
|
●準備及撰寫下列工作之計畫文件，並履行之：
型態識別、型態管制、型態狀況記錄。
|
●準備記錄「交付項目」的儲存、處置、與交付之方法與程序之文件，並履行之。
●準備各項針對「基準」(Baseline)變更的「工程變更建議」(ECP)及「規格變更通告」(SCN)。
|
|
軟體移轉支援
(Transitioning to software support)
|
●使用買方的硬體及軟體，以提供可再產製及可維護的程式碼。
●準備將「交付軟體」(Deliverable Software)轉移到支援階段的各項計畫。
|
●在指定的「支援環境」裡，進行安裝與檢測，並依合約要求提供訓練與後續支援。
●按照「合約資料需求清單」(CDRL)的要求，準備「運作及支援文件」(Software support and operational documentation)。
|
有些公司在建立「軟體發展制度」時，便會根據較為重要（較具獨立性）的工作項目，設立對應的職位。例如，參見「表三」所示。
表三：各職類工作人員
「軟體發展制度」所要求的
工作項目 |
對應的職位
|
|
‧專案的規劃與管理
|
‧專案經理
|
|
‧軟體工程發展
|
‧分析師
‧設計師
‧程式師
|
|
‧軟體品保
|
‧軟體品保工程師
|
|
‧軟體鑑定測試
|
‧軟體測試工程師
|
|
‧軟體型態管理與資料管理
|
‧軟體型管工程師
‧文件資料管理員
|
|
‧軟體移轉支援（軟體維護）
|
‧軟體維護工程師
|
每一個職位（頭銜）並非一成不變的，因為每個人都可能會輪調或升遷。
這些職位被設立的同時，也同時被賦予其應擔負的「權」與「責」。其優點是：
‧每個人皆有明確的專業及專職，不會角色模糊或混淆。 ‧同工同酬，不同工則不同酬。 ‧權責相符。
假設，某一家公司，每個人的職位（頭銜）是「主任工程師」、「工程師」、「副工程師」、「技術員」…。在這種情形下，這些人被分配在「軟體發展制度」裡所扮演的角色，可能一會兒是「專案經理」，一會兒又是「程式師」，一會兒是「型態管理工程師」，一會兒又是「測試工程師」…，每個人的角色都是不明確、模糊不清，甚至可能相互混淆。
乍見之下，似乎每個人都是「十項全能」、「百般武藝精通」，然而深入去瞭解之後，卻發現，在軟體工程的各類工作項目裡，每個人都不是專職、專業的。而衍生出來的問題便是：(1)同工不同酬；(2)權責不相符。
就以「同工不同酬」而言，一位「主任工程師」與一位「副工程師」，兩個人所扮演的角色都是「程式師」，工作內容完全相同，然而兩個人的薪水卻可能差異很大。（※註：要解決此一問題，必須另外訂定一套合理的績效考核及獎勵辦法──依據職等或薪水的高低，被賦予不同的考核標準，薪水較高的人會被賦予較高的績效要求。）
若以「權責不相符」而言，其中最嚴重者，便是「專案經理」。「專案經理」，有可能未被賦予任何「實權」（考績權、獎勵權、懲處權…）。一個沒有「實權」的「專案經理」，如何指揮得動其他專案成員來執行工作？
因此，在此情況下的「軟體專案」最後常常會成為「一人專案」或「兩人專案」。因為「專案經理」指揮不動任何人的結果，就只好所謂「唸經、掃地、兼撞鐘」，專案工作從頭到尾自己做。
此外，「專案經理」尚有可能必須面對另一個難題：「有責者無權；有權者無責」。沒有「實權」也就罷了，但是專案的成敗卻還要「專案經理」擔負全責。而專案經理的上層主管，則是握有實權，但卻不必擔負專案成敗的責任。
這種「有責無權；有權無責」的結果，便可能會形成「有功無賞，有過則擔」──專案成功時，「在上位者」記功嘉獎（頂戴光環）；專案失敗時，「在下位者」記過處分（代罪羔羊）。
(待續)