微軟早期的功能規畫方式,遵循傳統的「由上至下」(cascade)式的做法:先做好大區塊的功能大綱,再進行近一階的細部設計。 這種規畫的主軸是以功能(例如功能選單的階層項目)來作為劃分的界線。這種作法在早期功能不多的情形下還能運作,但是到了後期,功能的數目多得嚇人,有兩個問題就凸顯出來: 無法掌握使用者完成一項完整工作(例如在郵件中打開檔案,列印完畢之後再關掉程式)的流程,其中所可能產生的程式錯誤,會超乎預期地多。 操作的體驗,有可能因整合度不夠理想,使用起來很不流暢,結果產生很多客訴。 到了 Office 2007 到 2010 的時代,一種稱為「場景企畫法」(scenario based planning)的方法出現了,就是希望能解決前面所談的兩個問題。
微軟老兵看軟體開發#7:救人與自救/團隊間的競爭與合作/葉光釗
微軟老兵看軟體開發#7:救人與自救/團隊間的競爭與合作/葉光釗
微軟老兵看軟體開發#7:救人與自救/團隊間的競爭與合作/葉光釗
微軟早期的功能規畫方式,遵循傳統的「由上至下」(cascade)式的做法:先做好大區塊的功能大綱,再進行近一階的細部設計。 這種規畫的主軸是以功能(例如功能選單的階層項目)來作為劃分的界線。這種作法在早期功能不多的情形下還能運作,但是到了後期,功能的數目多得嚇人,有兩個問題就凸顯出來: 無法掌握使用者完成一項完整工作(例如在郵件中打開檔案,列印完畢之後再關掉程式)的流程,其中所可能產生的程式錯誤,會超乎預期地多。 操作的體驗,有可能因整合度不夠理想,使用起來很不流暢,結果產生很多客訴。 到了 Office 2007 到 2010 的時代,一種稱為「場景企畫法」(scenario based planning)的方法出現了,就是希望能解決前面所談的兩個問題。