微軟老兵看軟體開發#2:微軟內部的腦力激盪法/葉光釗
將使用者需求轉換成產品功能的步驟與方法,在微軟我們稱product或feature planning,這可是個大學問。
將使用者需求轉換成產品功能的步驟與方法,在微軟中我們稱product或feature planning。這可是個大學問,即使我自己經驗再豐富,也很難用三言兩語講得清楚。不得已,勢必要拆成好幾篇來說明。在這一篇當中,先來談談在微軟內部,我們如何將大量而片段的資訊,收斂成系統與概念的步驟。
將使用者需求轉換成產品功能的步驟與方法,在微軟中我們稱product或feature planning。這可是個大學問,即使我自己經驗再豐富,也很難用三言兩語講得清楚。不得已,勢必要拆成好幾篇來說明。在這一篇當中,先來談談在微軟內部,我們如何將大量而片段的資訊,收斂成系統與概念的步驟。
讓用戶資料說話
現在微軟的產品規劃經理(Program Manager, 以下簡稱PM),將使用者行為歸納以及推導成產品功能的程序,很大一部份已經轉成資料驅動(Data-driven)的定量作法;這也是要歸功微軟的PM大神Steven Sinofsky先生,在Office 2003的開發過程中率先導入了遙測(telemetry)的功能;相當於現在的big data觀念。
這邊先講一下Steven Sinofsky在Office 2003中導入的遙測是什麼。對很多使用者看來,Office 2003是個平淡無奇的版本更新,除了兩個新產品InfoPath與OneNote之外,大多數的客戶並沒有Office大改版的印象。
透過網路回傳用戶使用情形,讓微軟掌握第一手用戶觀察資料,大大改變開發過程與PM工作內容。
但是對當時的開發工程團隊來說,這個版本的架構卻有革命性的基本改變:Office軟體開始自動記錄使用者端的錯誤資訊,還能進一步透過網路回傳使用資料;而這當然是在用戶同意的前提之下,有印象的人都知道這叫「使用者經驗改進計畫」,在微軟內部的code name叫做「DAD Watson」,就是福爾摩斯旁邊的跟班華生博士。
在此之後,微軟才有足夠的資訊,能進行系統化的用戶行為分析。
這樣的功能引入之後,差一點引發了PM的大革命,因為PM的工作大受影響。在此之前,軟體中大部分的功能規格與設計,都是PM「拍腦袋」(強國用詞)想出來的;誇張一點說,某項功能對用戶到底有甚麼好處、怎樣用起來最順暢,都是PM說了算。在有了遙測功能之後,微軟開始要求所有的設計都要有 Watson data分析做為依據,甚至很多功能的開發優先順序,都直接基於這些用戶行為來決定。
一度有許多PM相當恐慌,就怕自己的工作馬上要被Watson給取代了,因為之前很多PM在計畫階段做的事情,例如焦點團體研究、功能調查等等,不是消失就是大幅減少;更重要的是,PM深怕自己的決策權,從此被資料分析所取代。
現在回顧起來,這些疑慮當然都是杞人憂天;而且,許多事後諸葛亮還埋怨微軟推動這個改變不夠早,不夠快。無論如何,遙測技術重新定義了許多微軟內部職位的工作內容以及績效評估基準,後來甚至也大大改變了產品的設計取向。
眾人智慧仍然很重要
但是即使有了遙測資料,要從這些資料推導出軟體各項功能的雛型,還是需要人類PM的聰明才智與才能。
便利貼規劃法施行簡易,但能快速凝聚共識,得到行動方案。
既然還是需要人類的腦力激盪,想來微軟應該也準備了多種厲害的數位工具系統吧?事實是,愈複雜的問題,愈要靠簡單的方法解決。我們最常用的手法,稱為「便利貼規劃法」(Planning with Sticky Notes),所需要的設備很簡單:一個白板(愈大愈好),數疊便利貼,幾支筆,連電腦都不用,就可以直接上工了,成本非常低廉。
「便利貼規劃法」在西方軟體公司是很常見的方法,但蠻奇怪的,在國內我很少看到有軟體公司用這種方法(甚至包含台灣微軟),不知道為甚麼。
便利貼規劃法
用這種方法一同進行腦力激盪的人數,通常不能太多,約略3到5人的小組最佳;實施的步驟也很簡單。
第一步:每一個人將腦袋中跟主題相關的想法、每一個idea,寫在一張便利貼上,愈多愈好,越發散越好。這一步有個重要精神,就是「沒有idea是笨idea」,所有的想法都要廣納進來。
第二步:所有人寫完之後,每人按順序大聲念出idea的內容,並稍作說明。有幾點很重要:雖然可以要求做澄清,但是嚴禁評論別人的idea 好壞,更不能攻擊。而且所有人一律平等,即使是VP或是GM也是一樣。
第三步:開始核心討論。每個人逐一將自己的idea貼在白板上,如果你覺得你的想法跟別人類似,就貼在一起。整個輪完一次,白板上通常就會出現大大小小的群組;接下來意見相同的人就可以給這個群組下一個定義或是名字,然後開始討論相關的行動方案(action items)。其他零零星星的idea,出主意的人可以決定加入別的大群組,或是邀請其他人加入。
這種方法的整個概念就環繞在「收斂」以及「共識」上面,熟練過程的小組可以在30–40分鐘內完成討論,得到相當不錯的結論。筆者本來以為微軟以個人英雄主義著稱,意見收斂應該比較困難;但是經歷過許許多多的討論後,我發現透過這樣的做法,總是都能聚合共識,真的很神奇。
這樣的程序應用很廣,我所見到最多的是用在軟體功能設計上面,也有人用在大型的願景規劃(Vision Planning)上面。進行願景規劃時,參加的都是非常資深的高階長官,但是運作方式並沒有任何不同,所有人都是一樣的平等。另外也有一些有趣的場景,像是有人在面試時,即使是只有一個人,也用這種方式來歸納自己的優點與缺點。
這種做法的成本實在太低了,真的很推薦大家動手試試;了不起就是浪費幾張便利貼而已。如果各位有一些心得,也歡迎大家留言分享,說說你用這種方法的經驗。