微軟老兵看軟體開發#7：救人與自救／團隊間的競爭與合作／葉光釗
微軟早期的功能規畫方式，遵循傳統的「由上至下」（cascade）式的做法：先做好大區塊的功能大綱，再進行近一階的細部設計。
這種規畫的主軸是以功能（例如功能選單的階層項目）來作為劃分的界線。這種作法在早期功能不多的情形下還能運作，但是到了後期，功能的數目多得嚇人，有兩個問題就凸顯出來：
無法掌握使用者完成一項完整工作（例如在郵件中打開檔案，列印完畢之後再關掉程式）的流程，其中所可能產生的程式錯誤，會超乎預期地多。
操作的體驗，有可能因整合度不夠理想，使用起來很不流暢，結果產生很多客訴。
到了 Office 2007 到 2010 的時代，一種稱為「場景企畫法」（scenario based planning）的方法出現了，就是希望能解決前面所談的兩個問題。
用戶場景規畫法
這個做法也不是完全推翻傳統的方式，而是在進行細部規劃之前，每個大產品組的GPM總舵手，要先同意幾組重要的使用情境。甚麼是用戶場景？有三個重要的元素。
為了讓大家能很快了解，這裡舉一個假想的範例：
主人翁persona：25–30歲的上班白領，女性。開車上班。
操作需求與使用環境脈絡：在手機中尋找郵件中特定的Word 檔，開啟並瀏覽內容。
吸引主人翁使用功能的關鍵吸引點（Attraction Point）：使用語音就能找到檔案並自動開啟，無需使用手機虛擬鍵盤。
有了共同的情境，每個功能開發團隊就會想辦法讓自己的功能在這個框架下能最佳化。這三個要素中最難設計的就是Attraction Point：它不能過度幻想（手一揮就能變出小鳥之類的），還是要在SDE技術能做出來的範圍內；也不能描述地過分仔細，反而限制功能開發團隊的解題創作潛能。
通常GPM在開工之前，都要反覆討論這些場景，使用之前所提到的便利貼腦力激盪方法來思考；更重要的是，最後大家要對使用場景的優先順序產生共識，產品開發才會有穩定的基礎。
團隊間開發計畫的「相依性」問題
場景企畫開發法的進一步延伸，就是所謂的「端對端體驗」。要完成這件事情，最難的地方，就在於功能開發團隊的責任區分，與體驗的完成，並不在同一軸線上。
沒有任何一個單一單位能對體驗負起完全責任，但是缺了一個單位，總體驗又連不起來。就微軟的工程管理而言，這就是最棘手的「相依度」（dependency）管理問題。
老實說，筆者在微軟二十年，從來沒有看到完美的解決方法，每一個版本都有不同的dependency問題，也都是在黑暗中摸索，跌跌撞撞中完成。
我跟我們之前的團隊就有過慘痛的教訓：有一次，我們的團隊負責手機的某個功能，這個功能是架構在一個以PC為主的服務之上。雖然這功能不算是很核心的功能，但是台灣的團隊還是兢兢業業地將所有該有的研發過程都做好，規格寫得很清楚、撰寫程式碼與測試的時程控管也做得很到位，甚至進度還超前。每個成員該盡的本分都盡了，就希望安安穩穩把做好的功能遞交出去。
沒想到，到開發時程接近程式碼完成階段的時候，反而傳出風聲，說PC版本的功能會被砍掉。這一砍可不得了，這表示手機團隊做了整整一個milestone的心血會全部泡湯。
要知道，微軟看的就是戰功；你的功能沒辦法遞交出去，做得再辛苦，績效還是零。這時候筆者才了解光埋頭苦幹是不行的，要隨時抬起頭來，看看世界發生了甚麼事情。
仔細探究原因，原來是因為這項功能的PC版bug太多，開發該功能的功能小組，擔心會因此拖累整個產品進度，打算揮淚斬馬謖。不得已，我們團隊所有SDE都撩下去，捲起袖子開始去解別人的bug，後來總算穩住陣腳；雖然整個體驗簡化了很多，還是把PC和手機的功能交了出去。
幫別人，也是為了幫自己
後來我們的團隊學到一招：要跟與自己的功能相依度高的團隊合作時，必須要「過度溝通」（over communication），簡單的來說，就是要去管別人的閒事。後來的版本開發中，我們甚至會去監看其他單位的bug情況，先一步去看可能會對我們產生影響的問題，甚至主動幫忙解決。
筆者的經驗是，像這種情況，不可預測的變因太多，很難用既定的方法論或程序來解決；最終還是要靠人與人的溝通，以及紮紮實實的解題能力。
管別人閒事，在文化層面上的確是個挑戰。幫人與被幫的兩方，如果沒有一致的願景以及正面善意地看待此事，很容易就此發生衝突。這也是為什麼微軟的組織內部，老是給外界一種彼此針鋒相對的印象。無論如何，既然這是工程上不可避免的作法，我們也只能盡量跟它和平共存。