- 普遍的軟體專案的風險：
- 先天的時程規劃錯誤（schedule flaw)
- 需求膨脹（requirement inflation)
- 人力流失（employee turnover)
- 規格崩潰（specification breakdown)
- 低生產力（poor productivity)
- 常見的五個普遍的軟體專案風險，只有最後一項真正跟員工的工作表現有關，其餘四項都跟做得多辛苦、多精明幹練無關
- 預先為無法捉摸的事物進行合理的準備，正式風險管理的核心，預先準備並不能讓妳為失敗開脫，只能在風險造成威脅時保有緩衝的餘地
- 時程規劃錯誤是指時間的安排有缺陷，這是時程本身的錯誤，而非專案執行的錯誤。時程錯誤不僅是真正的風險，也是五個核心風險中對專案衝擊最大的。
- 七個月的專案最後卻做了十二個月，生氣的高階主管很少會怪時程規劃的人，相反的，他們會怪人員沒有盡力
- 從專案的角度來看，刪除某些已經做好的功能，也算是一種需求膨脹，因為這同樣增加了額外的工作負擔
- 在規劃時程時，常會忽略需求膨脹的議題。高階主管也不會管，類似的說詞是：客戶要X，預估十個月後交付；若你發現還要X以外的東西，那就是你的問題了
- 處理人員流失，你必須知道：
- 公司技術人員的每年平均流動率
- 接替人員完全進入狀況時間（ramp-up time）的預估值。想辦法做好教育訓練與技術文件，降低進入門檻
- 規格崩潰往往溯及專案初期談判過程的失敗，而談判正是需求界定的中心
- 界定需求時，為了避免與利害關係人有衝突，常會將一些關鍵的、有爭議的的問題模糊化。被掩飾的問題暫時不見，不代表永遠不見。界定需求也許可以搞得模糊，但是開發階段可模糊不得。最糟糕的是，這些問題都是專案後期才會發生，這個節骨眼幾乎是將預算與時間耗盡的階段，常給專案致命一擊
- 閉口不談風險，並不會讓風險消失
- 在工作上，我們都被要求保有can do 的態度，問題就在這；討論風險是一種cannot do 的思維，往往風險探索會背離組織的主流意見。組織要有開放的文化，讓負面言論有說出來的可能
- 「明確過程」有明確步驟、可預測的程序，相當於white box 。經驗過程則相當於black box，是經由不斷的觀察與驗證後，以經驗來調整輸入，進而產生滿意的輸出
- 風險舒緩是預先採取的一套作為，萬一風險成形，便可有效的、快速的處理風險
- 有風險認知的管理者，會優先考量含有重大技術風險的部分，這非常合理，不過也有違大部分管理者的本性，因為會太早暴露他們在這場競賽中的弱點。這就是為什麼對如此棘手的問題，他們總是秘而不宣，一拖再拖
- 如果系統有哪個部分必須仰賴技術上的突破才能完成，就該把它納入早期版本，到時候就算突破不了，應變選擇也會擁有最大的彈性。假如夠早，也許私下承受一點損失即可；反之，若把相同的挫折放到專案後期，影響層面將會擴大到每一個人
- 漸進式交付是降低軟體專案風險的好方法，其是由三種artifacts所構成：
- 設計藍圖：顯示要識做的最低階模組或類別，以及彼此之間的關係
- WBS（Work Breakdown Structure)：顯示要完成的工作，以及彼此之間的相依關係
- VAT (Version Acceptance Test)：把產品的總驗收測試按照版本細分，顯示哪個測試可用在哪個中間產品上
- 冒險的積極程度必須由報酬而決定。你願意冒多少風險，端視你可以得到多少報酬而定
- 對複雜、不確定性頗高的問題，建立模型來估算各種變因對結果的敏感性，即為敏感性分析
- 軟體專案常會呈現規模不經濟（diseconomieis of scale）的特徵：若系統規模增加為兩倍，則實際系統開發耗費的心力會超過兩倍
- 擴大產品規模，成本增加的幅度就會更大；那麼縮小產品規模，便很可能可以大幅節省開支。刪除系統中屬於低價值 / 成本比的部份，也許是紓解時程和預算壓力最簡單且直接的方法
- 有些軟體專案，都是以專案的重要性來為死亡行軍的正當性辯護：這次的任務太重要了，請全體專案人員放棄個人生活、超量加班，就算是最後一滴血也要榨乾。但是，既然這個專案有這麼重要，為什麼公司不願意分配合理的時間與金錢來做呢？
- 公司很排斥將軟體專案價值量化，隱瞞做這個專案會產生的價值的期望值，如此才有可能在縮減開發成本的情況下完成專案，這是很重要的理由，「我們要把成本壓低，低到不論做出多少價值的東西都划得來」
No comments:
Post a Comment