前微軟工程師現(xiàn)身說法:原來Windows是這樣開發(fā)的!
兩天前一位前微軟設計師談論了公司是如何決定在 Windows Phone 中使用漢堡菜單來大幅取代樞軸式 UI 的,這位設計師稱這個決定得到了大量數(shù)據(jù)的支持,同時也是設計組共同討論的結果,許多非常聰明的團隊成員都贊同這項決定。
現(xiàn)在又有一位在 Windows 團隊工作了超過10年的前微軟工程師現(xiàn)身說法,為我們解釋了卓越的創(chuàng)意是如何被糟糕的執(zhí)行糟蹋的,以及糟糕的創(chuàng)意是如何通過可行性論證并最終成為上市產(chǎn)品的。
他寫道:我曾經(jīng)是一名 Windows 工程師,也參加了那些會議。
通常會有一些性格外向且頗具魅力的項目經(jīng)理宣布,功能團隊已做出了一個決定。最終,這項決定是關于功能性,或者適用范圍,或時間線,偶爾也關于功能去留問題的妥協(xié)。最初構想的功能特性是朝以下方面發(fā)展的:快速、適應性、可配置性、直觀性、自我記錄,最重要的是用戶友好性。
通常情況下這些設計都由具有功能批準權的用戶與合作伙伴進行審查。在這個階段的產(chǎn)品,即下一代 Windows 系統(tǒng),是非常了不起的產(chǎn)物,請相信我的話。而在產(chǎn)品發(fā)布過程中,一連串的決定不斷對 Windows 的功能性等各方面進行削減,以至于到正式發(fā)布時,最終產(chǎn)品已與最初構想的產(chǎn)品大相徑庭。
問題是,在整個流程中,這些決定看起來并不糟糕。決定是由項目管理團隊、開發(fā)人員與測試人員經(jīng)過仔細審議達成共識后作出的。這些工程師在會議中花了大量時間來權衡他們的選擇、評估每項決定的優(yōu)缺點、策劃出可能的影響,并最終從多個競爭選項中選出最佳選項。(或者決定也可能由上層管理傳達下來,但結果是一樣的)整個過程是簡單細致的,同時保證了照顧到會議室中所有團隊觀點后得出的最佳結果。
那么問題也來了:誰沒有參與到?jīng)Q策會議中來呢?在這個階段,通常時間周期為4到6周,根本沒有時間去咨詢用戶。
理論上來說,幾乎所有微軟工程團隊中的成員都算是用戶的代表。項目管理者們在規(guī)劃時已經(jīng)了解了用戶的想法,所以這些功能可以預測他們的每一項需求。測試者最先覺察到用戶的不滿意之處。合作伙伴則有些像用戶,但他們更有錢,同時也更有影響力。至于開發(fā)者們,他們實際上并不關心用戶。
實際上來說,這個流程并不奏效。因為 Windows 工程團隊中根本沒有人真正與用戶接觸過。他們實際上在傳遞著一位通用型用戶的理想化形象。
功能團隊就是根據(jù)這種占卜板式的模式進行咨詢的,接著又仔細地將所有空中樓閣式的想法全部合理化,然后就成為了一項決定。但這個決定終歸來說還是基于工程團隊的想法與創(chuàng)意,而非用戶的想法,這僅僅是因為用戶并沒有機會未出席這些會議。
為一款產(chǎn)品維持多個用戶界面是一項額外的工作,我們沒有足夠時間去測試多重配置。其他競爭者比我們擁有更多的市場份額,如果我們只是復制他們,可能我們能做得更好。所有我們說的這些內(nèi)容都是真實的情況,所有這些都是支持最終決定的有力理由。但所有這些理由與論證均有微軟自問自答來完成。
在會議當天,項目管理會反復強調(diào)這項決定是多么有利于用戶。他們會列舉一些事實來佐證這項決策:我們不想提供過多選項來讓用戶無從選擇;只有3%的人還在用那種方式,很明顯需要進行轉變了;一致性對微軟有利,所以也一定對用戶有利。每個人都面帶笑容,紛紛點頭同意這項決定并一致認為這是最佳決策。接著會議順利結束,這項功能有了新的發(fā)展方向。
雖然最終結果與當初構想的有些差距,也可能用戶體驗更差,但編寫軟件是需要妥協(xié)的嘛。這是一項可以接受的妥協(xié),無論如何還不算太壞,也是最佳的選擇。如果真有用戶在現(xiàn)場,他們也會理解的。
以上就是我曾經(jīng)作為 Windows 工程師時的所見所感。在看過那則視頻后,我突然間感覺自己又仿佛回到了那個會議室中。
現(xiàn)在又有一位在 Windows 團隊工作了超過10年的前微軟工程師現(xiàn)身說法,為我們解釋了卓越的創(chuàng)意是如何被糟糕的執(zhí)行糟蹋的,以及糟糕的創(chuàng)意是如何通過可行性論證并最終成為上市產(chǎn)品的。
他寫道:我曾經(jīng)是一名 Windows 工程師,也參加了那些會議。
通常會有一些性格外向且頗具魅力的項目經(jīng)理宣布,功能團隊已做出了一個決定。最終,這項決定是關于功能性,或者適用范圍,或時間線,偶爾也關于功能去留問題的妥協(xié)。最初構想的功能特性是朝以下方面發(fā)展的:快速、適應性、可配置性、直觀性、自我記錄,最重要的是用戶友好性。
通常情況下這些設計都由具有功能批準權的用戶與合作伙伴進行審查。在這個階段的產(chǎn)品,即下一代 Windows 系統(tǒng),是非常了不起的產(chǎn)物,請相信我的話。而在產(chǎn)品發(fā)布過程中,一連串的決定不斷對 Windows 的功能性等各方面進行削減,以至于到正式發(fā)布時,最終產(chǎn)品已與最初構想的產(chǎn)品大相徑庭。
問題是,在整個流程中,這些決定看起來并不糟糕。決定是由項目管理團隊、開發(fā)人員與測試人員經(jīng)過仔細審議達成共識后作出的。這些工程師在會議中花了大量時間來權衡他們的選擇、評估每項決定的優(yōu)缺點、策劃出可能的影響,并最終從多個競爭選項中選出最佳選項。(或者決定也可能由上層管理傳達下來,但結果是一樣的)整個過程是簡單細致的,同時保證了照顧到會議室中所有團隊觀點后得出的最佳結果。
那么問題也來了:誰沒有參與到?jīng)Q策會議中來呢?在這個階段,通常時間周期為4到6周,根本沒有時間去咨詢用戶。
理論上來說,幾乎所有微軟工程團隊中的成員都算是用戶的代表。項目管理者們在規(guī)劃時已經(jīng)了解了用戶的想法,所以這些功能可以預測他們的每一項需求。測試者最先覺察到用戶的不滿意之處。合作伙伴則有些像用戶,但他們更有錢,同時也更有影響力。至于開發(fā)者們,他們實際上并不關心用戶。
實際上來說,這個流程并不奏效。因為 Windows 工程團隊中根本沒有人真正與用戶接觸過。他們實際上在傳遞著一位通用型用戶的理想化形象。
功能團隊就是根據(jù)這種占卜板式的模式進行咨詢的,接著又仔細地將所有空中樓閣式的想法全部合理化,然后就成為了一項決定。但這個決定終歸來說還是基于工程團隊的想法與創(chuàng)意,而非用戶的想法,這僅僅是因為用戶并沒有機會未出席這些會議。
為一款產(chǎn)品維持多個用戶界面是一項額外的工作,我們沒有足夠時間去測試多重配置。其他競爭者比我們擁有更多的市場份額,如果我們只是復制他們,可能我們能做得更好。所有我們說的這些內(nèi)容都是真實的情況,所有這些都是支持最終決定的有力理由。但所有這些理由與論證均有微軟自問自答來完成。
在會議當天,項目管理會反復強調(diào)這項決定是多么有利于用戶。他們會列舉一些事實來佐證這項決策:我們不想提供過多選項來讓用戶無從選擇;只有3%的人還在用那種方式,很明顯需要進行轉變了;一致性對微軟有利,所以也一定對用戶有利。每個人都面帶笑容,紛紛點頭同意這項決定并一致認為這是最佳決策。接著會議順利結束,這項功能有了新的發(fā)展方向。
雖然最終結果與當初構想的有些差距,也可能用戶體驗更差,但編寫軟件是需要妥協(xié)的嘛。這是一項可以接受的妥協(xié),無論如何還不算太壞,也是最佳的選擇。如果真有用戶在現(xiàn)場,他們也會理解的。
以上就是我曾經(jīng)作為 Windows 工程師時的所見所感。在看過那則視頻后,我突然間感覺自己又仿佛回到了那個會議室中。
這位前微軟工程師的言外之意是,盡管微軟收集的數(shù)據(jù)與做出的決策并不總是完全正確的,但如果微軟內(nèi)部沒有人真正代表用戶,那么在有機會反饋時,我們當然就不應該再保持沉默了。所以,大家積極向微軟發(fā)出自己的聲音吧!