端對端的使用者體驗

接續前一篇的觀念，這裡繼續討論如何完成 end to end experience。這件事情最難的地方，就在於功能小組的責任區分，與體驗的完成，並不再同一軸線上。沒有一個單一單位能對體驗總負責，但是缺了一個單位總體驗又連不起來。就 M 社的工程管理而言，這就是最棘手的 “相依度”dependency 管理問題；老實說，在 M 社的二十年中，我是沒有看到完美的解決方法，每一個版本都有不同的 dependency 問題，也都是在黑暗中摸索，跌跌撞撞中完成。

我跟我們之前的團隊就有過慘痛的教訓: 有一次，我們的團隊負責一個手機的功能，這個功能是架構在一個以 PC 為主的 service 之上。雖然不是很核心的功能，但是台灣的團隊還是競競業業的將所有該有的研發過程都做好，spec 寫得很清楚，寫 code 與測試的時程控管也做得很到位，甚至進度還超前。每個成員該盡的本分都盡了，就希望安安穩穩把 feature ship 出去。

沒想到，到接近 code complete 的時候，PC 版本的功能反而傳出來要被 cut 掉。這一 cut 可不得了，這表示手機團隊整整一個 milestone 的心血會全部泡湯。要知道，M 社看的就是戰功，你的功能沒辦法 ship 出去，做得再辛苦績效還是零。這時候才了解，光埋頭苦幹是不行的，要隨時抬起頭來看看世界發生了甚麼事情。仔細探究原因，原來是 PC 版的 bug 太多，開發的功能小組擔心會拖累整個產品進度，打算揮淚斬馬謖。不得已，我們團隊所有 SDE 都撩下去，捲起袖子開始去接別人的 bug，後來總算穩住陣腳，雖然整個體驗簡化了很多，還是把PC 和手機的功能 ship 了出去。

後來我們的團隊學到了，要跟我們的功能相依度高的團隊合作，必須要 over communication，簡單的來說就是要管別人的閒事。後來的版本開發中，我們甚至會去monitor 別人的 bug 情況，先一步去看可能會對我們產生影響的問題，甚至主動表示幫忙。我的經驗是，像這種情況不可預測的變因太多，很難用既定的方法論或程序來節解決，最終還是要靠人與人的溝通，以及紮紮實實的解題能力。

要管別人閒事的文化，在文化層面中的確是個挑戰。想幫人與被幫的兩方，如果沒有一致的願景以及正面善意地看待，很容易發成衝突。這也是為什麼微軟的組織老給人互相指槍相向的印象。無論如何，既然這是工程上不可避免的作法，我們也只能盡量跟它和平共存。