瀑布式開發法的適用性
- 適用於定義清楚，可以被預測的問題
- 適用於不會遭遇什麼太大變化的專案
- 計畫導向的開發流程中，產品開發被歸類為製造：避免變化並遵循預先訂的流程
- 製造業的世界裡，目標是固定的需求量下，遵循一套定義清楚的循序化步驟，來重複完成相同的產品生產
變化與不確定性
- 客戶總是最後驗收時，提出種種的問題與建議：
- 客戶A：這個功能怎麼跟我想像的不一樣
- 客戶B：這裡怎麼沒有ＸＸ功能
- 客戶C：當初我不是這樣說的啊
- 客戶D：能不能幫我把這個功能改成這樣啊，那時候設計的時候我沒有考慮到這個問題
- 承包專案的我們，所保持的想法往往是
- 業務：我可能得跟我們的工程師溝通一下
- 工程師Ａ：基本上這個功能的修改會牽涉到其他功能，要改的話可能得全部重新撰寫了
- 工程師Ｂ：需求不是一開始就講好了嗎？為什麼還要改？
- 工程師Ｃ：這功能我花了10天才撰寫完成，現在怎麼說要重新設計了？
- 工程師Ｄ：加這個新功能得花蠻多時間的，我現在在處理其他案子，可能沒辦法馬上進行
- 工程師Ｅ：你當初不都跟他確認很多次了，這次又要換？
甘特圖
計畫導向開發，依循著分析、設計、實作、測試、維運的流程，然後製作出一張精美的甘特圖，一堆需求文件，將每個階段鉅細靡遺的設定好
- 甘特約在1910年發明了這種知名圖表
- 最早使用甘特圖的是第一次世界大戰時擔任陸軍軍械部部長的William Crozier
- 甘特圖成為了21世紀專案管理的既定標準工具
- 我們已經不再打壕溝戰，但是當年用於規劃壕溝戰的思維到現在卻依然流行
- 但現實中，有多少專案真正照著甘特圖進行，答案是幾乎趨近於零
- 我們花了大量時間製作的需求文件、規劃書、甘特圖一碰到現實，就馬上瓦解
- 許多管理者非但沒有廢止計畫或屏棄自己對計畫的想法，反倒還找人弄得一副計畫很管用的樣子
保持意見開發
- 大多數產品開發工作先天具有不確定性
- 產品開發的過程不像製造
面對需求不確定的情況，我們不應該過早制定決策，流程本身自然會告訴我們應該在何時制定決策
開發工作進行的第一天，我們擁有的資訊最少，因此決策的風險最高，所以為什麼我們一定要在開始，就要完成所有重要且無法回頭的決定呢？多數人應該傾向於在獲得更多資訊後所制定出的決策。
如下圖所示，我們傾向於延後承諾，在最後責任時刻之前，不做任何重要且無法回頭的決策，直到布制定決策之成本大於制定決策之成本的時候，我們才做出承諾
(結束)
沒有留言:
張貼留言