Software Project Risks

軟體專案有這些風險: (軟體聖經)
1.先天的時程錯誤(schedule flaw)
2.需求膨脹(requirement inflation)
3.人力流失(employee turnover)
4.規格崩潰(specification breakdown)
5.低生產力(poor productivity)

個人經驗, 公司有不同文化, 專案也有不同屬性, 我遇過的上述情況若發生, 公司的處置對策如下: (S:Scenario, A:Action, R:Result)
S1: 遊戲專案, 時間快截止前發現遊戲不好玩, bug還很多未解決, 開會後決議
A1: 新增功能, 並延長時程
R1: 結果加開更多的功能, 大家脾氣越來越糟, 最後時間延長卻造成生產力下滑, 雖然產品最後還是上線了, 可是前前後後大約流失了一半的專案成員

S2: Web系統, 專案時間快截止前, 過程中逐漸發現很多功能需要新增後才能做到可上線並自動化的程度, 開會後決議
A2: 延長時程, 合理的功能還是得開發, 但堪用即可
R2: 最後延長3次, 上線後問題依然很多, 逐漸穩定, 但還無法做到很自動化, 管理介面也不夠多, 慘的是常常有帳對不起來需要手動並修改資料庫data的情形

S3: 同上情況, 但專案為協助其他部門開發, 算是跨部門的專案, 開會後決議
A3: 延長時程, 並限縮功能, 其餘由被協助部門承接後續開發與上線事宜
R3: 因為其實被協助部門就是因為人力吃緊所以請求技術部門協助, 協同開發案一結束, 接受轉移來的系統, 並無人員有能量承接, 此開發案仍然放在倉庫, 上線日期遙遙無期

以上的情況我感覺不斷地重演時程錯誤的問題, 需求都在過程中越見明朗, 規格也因此陸續增加, 但傳統公司礙於面子問題, 不肯對上司誠實交代"delay"的原因, 使得"說到做到"的次文化重於執行專業, 最後上了一個不是很好用的東西, 使用者使用意願低, 開發人員越來越自卑。這樣的惡性循環, 不知道要嘗過幾次教訓才會受教。