Barbee Davis, M.A., PHR, PMP — Omaha, Nebraska, USA
閉門造車的代價#
過去的軟體開發模式，往往是在收集需求後閉門造車，等到專案結束才揭曉成果。開發團隊以為使用者看不懂過程，不需要介入。然而最後的反應卻常常是：「你們花了很多心力，但這不是我要的……」
越晚發現問題，代價越高#
修改成本會隨著專案進度不斷攀升：
- 需要重新編碼（recode）、重新測試（retest）
- 影響周邊程式的整合測試，大幅延誤進度
- 若變更幅度太大，還得送交 變更控制委員會（Change Control Board）審批，耗費大量時間與預算
注意： 對開發者和專案經理而言完全合理的設計決策，在真實使用情境中可能造成嚴重混亂。
真實案例：5 百萬美元的教訓#
一家大型培訓公司花了 500 萬美元重新設計訂購軟體。舊系統有清晰的品項編號邏輯，例如：
4125— 學員手冊4225— 學員練習磁片4325— 講師手冊4425— 課程行銷大綱
全球 140 個據點的行政人員每天重複訂購相同品項，久而久之都能背出號碼，訂購效率極高。
然而新系統完全打亂了這套邏輯。同一本學員手冊從 4125 變成 6358，配套的練習磁片變成 8872，講師手冊變成 3392，而且每種品項分散在不同頁面。
結果：
- 行政人員必須重新查找每個品項，同時努力「忘掉」舊號碼
- 訂購速度急遽下滑
- 專案嚴重超時超支
癥結在於：開發團隊忘了考慮真正使用者的工作方式。
核心建議#
重點： 只要有任何可展示的成果，就應該讓使用者看到。儘早讓使用者與開發人員溝通，遠比專案完成後才返工來得更省時省錢。
身為專案經理，你的職責就是讓使用者「早介入、常介入」——讓問題在還能低成本修正的階段就被發現。