在 Amazon 工作發現跟台企最大不同:自己挑選戰場、學會提好問題、盛行讚美文化

 

【我們為什麼挑選這篇文章】準時下班、跟許多強者一起並肩奮鬥,這可能是很多人對跨國企業內部的工作想像,不過實際上在 Amazon 工作真的事這麼一回事嗎?本文作者  James Liu 從工程師轉職 UX 設計師,進入 Amazon 工作三年後觀察到許多跟台灣企業不同的文化。從他的經驗中,我們也能進一步訓練思考,並從自身文化中跳出看到不一樣的觀點。(責任編輯:鄧天心)

幾天前,加入 Amazon 的日子不知不覺滿三週年了。碰巧有位朋友也在這個時間問我,在 Amazon 做設計師有沒有什麼不一樣?剛好,利用這個機會好好來回顧一下自己在這 1000 多個日子的感受。不過,這些只是我個人待過的公司、團隊的經驗,並不代表全部。

長話短說,自己覺得除了從 50%的英文變成 100%的英文以外,其他的,真的沒有太大的不同。然而,既然朋友是問:「在 Amazon 做設計師有沒有什麼不一樣?」那我就從不同的地方先來分享。

知道如何問問題是一種基本工

會不會問問題,在 Amazon 是一個非常重視的基本能力,它受重視到在面試時,都被當作一個重要的考核指標。

我曾經聽過不只一次,來參與面試的人,各項專業能力都非常優秀,最後卻沒有被錄取,原因很簡單 —  面對面試官提出來的實作測驗,一個問題都沒有問,或者問了一些無關緊要的事,就開始作答 。這樣的案例並不是只有發生在設計師的面試,即使工程師也一樣。

也許是台灣教育使然,在唸書的時候,許多學生常常都是老師說什麼就背什麼,不管懂不懂、對不對,考試背出正確答案就好,因此,對於問問題並不怎麼在行。

離開了學校進入職場,因為鮮少有這樣的訓練,對於主管的要求提出問題,更是戒慎恐懼。再加上,鄉民們常說, 台灣私人企業、政府機關對於解決問題的方式,都是解決提出問題的人,似乎都在告訴大家,問問題等於找麻煩 ,因此,許多會議中,總是惜字如金,沒有被 cue 到,絕不講話,我也一直是這樣,不覺得有什麼問題。

然而,在從工程師轉換至設計師跑道之後,主管常常對我的設計,提出各種我事先從來沒想過的問題,讓我常為了自己沒搞清楚問題,就急著動手而犯了一些低級錯誤(rookie mistakes)感到無地自容。

為了避免再犯同樣的錯,便 強迫自己在每次開始設計之前,就把所有將來可能被問的問題,都先對自己問過一輪,回答不出來,就去問到答案, 經常搞到快要人格分裂。但是,也因為這樣,漸漸把提問的能力磨練出來。

從一位 UX 設計師的角度來看,對產品經理問對的問題,能幫助你的設計,確切滿足商業目標;對工程師問對的問題,能幫助你在已知的技術限制下,提出創新的方案 ;對使用者問對的問題,能幫助你深入了解使用者的渴望,提出不僅可用(Usable)且有用(Useful)的產品。

在 Amazon,人人都是提問高手,如果你沒有在專案開始前,把一些重要的事問清楚、搞明白,在設計提案討論會時,肯定會被問到啞口無言、腦袋空白,漸漸地,你的專業能力便會開始受到質疑。一旦失去了團隊的信任,將很難在這個團隊繼續待下去了。

Amazon 溝通文化:具體讚美

另一個 在 Amazon 感受最大的不同是,大家都不吝於感謝或給予讚美,而且,是非常具體的讚美 ,這也是從小在台灣長大的我,非常不擅長的一件事。過去,每當同事拿著設計來請我給意見的時候,總覺得,沒有讓他抱著一堆改善的建言回去,會讓對方覺得我不專業、吝嗇、留一手,所以,我都絞盡腦汁的挑出每一個可以給予意見的點,然後,帶著滿意的笑容看著同事,心想:「應該有讓你滿載而歸了吧。」

然而,在 Amazon 每一次的設計提案討論會,與會者一定都會從我的設計中,找到他喜歡的,並積極給予鼓勵、讚美,而且,是具體地說出哪些部分是他欣賞的,絕不會有那種「辛苦你了」空泛的口號。

漸漸地,我 慢慢體會讚美比批評(給建議),有更強大的力量,推動人們努力往更高的目標前進 。如果,一場會議下來,你只有收到一堆改善計畫,接下來,會先感到挫折,然後,再由挫折轉成憤怒 — 我浪費了那麼多時間努力,竟然毫無建樹!就算最後化悲憤為力量,往往也打了一些折扣。然而,如果在建議之前,有收到一些具體的鼓勵,挫折感或許會大大降低,一般來說很少會進一步轉成憤怒,提案者很快就可以整理思緒,開始著手改善計畫。

我發現,這樣的方式套用在孩子身上,一樣管用(菸~)

更開放的環境更要懂得挑選戰場

我在 Amazon 的第一位主管,是個貼心、笑聲很爽朗,做事實事求是的德裔美國人,從她身上學到了許多一身受用的觀念。記得一次在討論工作規劃時,她告訴我, 在 Amazon,不會有人告訴你什麼該做、什麼不該做,你必須懂得挑選自己的戰場(pick your battles)。以前在台灣,主管總會跟我討論每年的工作項目,甚至到這個月要完成什麼都規劃好了,很開心在這樣的溫室裡上班,每天幾乎只要照表操課就可以了。

然而,加入 Amazon 之後,好像從一個整天被鞭子抽的私立高中,進入了放牛吃草的大學,突然間,好多事都想要做、也有好多事都懶得做,一段時間之後,發現比較自律的同學跟自己的程度越差越遠,驚覺好多事應該做、卻也好多事來不及做了。

UX 設計師在 Amazon 是個稀缺的資源,總有一堆案子想要你的幫忙,即便你無止盡的加班,都不可能全部交付,然後,還有一堆很有趣的案子,你迫切渴望地想參與。如果你不懂得正確地把時間,投資在值得做的事上面,到頭來,在做年終回顧的時候,你會發現說不出一個滿意的成績(success stories),覺得自己又瞎忙虛度了一年

至於, 什麼才是對的戰場,什麼才是真正值得花時間的專案,我自己的衡量方式很簡單 — 我能為哪一個專案帶給最大的價值(UX impact)。即使在 Amazon,仍然存在部分人把 UX 設計師當成美化介面的工人,像這類的專案,每幫一次忙,就是在強化認同對方的觀點。

基本上,能不做就不要做,或者是用最少的時間去完成(有很多方法可以達到這個目標,將來有機會再說)。如果,你發現你總是在做累案子,是時候去找你的主管聊聊了,這種案子做再多,對你的能力不會有什麼提升,對整個設計團隊的價值,也不會有任何加分。

Amazon Treasure Truck,一個我也很想參與的專案。

講完了三點體會最深刻的不同,接著來說說,曾經以為應該會不一樣,後來發現到哪都一樣的問題。

到哪裡都有不尊重專業的人

就像前面所說的,即便在 Amazon 這樣的公司,還是會有不尊重專業的人,記得去年,我曾經一整個氣到在自己的 Facebook 上怒吼:「當初是哪個瞎眼的錄用你!」不過,面對這樣的人,在這些年訓練下來,大概已經有一套自己的 SOP 了。

首先,在專案開始的啟動會議(kick-off meeting)上,清楚的說明接下來計畫做的事、需要的時間,並慎重的解釋每一個步驟背後的原因,最後,一定要確認大家都認同。接著,每一個步驟開始前,都要讓專案相關人員知道,期間,盡可能讓他們一起參與,步驟結束後,一起檢討,這麼做的目的是, 讓他們「體會」你做事的流程 ,以及每一個步驟對專案成敗的影響。正所謂,身教重於言教啊(親身參與比聽一堆設計流程演講有幫助多了。)

最近才遇到一位資深工程師,特地在會議之後,跑來跟我說:「我從來就沒有想到只有三個畫面,卻要思考這麼多細節,原來,UX 設計真的不是想像中的動動滑鼠而已。」

當然,還是會有些人在經歷過這一切之後,依然不把你的專業當一回事,這時候,就是主管需要出手的時候了。在前一個團隊,碰巧歷經兩個做事風格迥異的主管,事情發生後,A 主管,跑去跟 K 產品經理(就是讓我怒吼的人)一對一解釋設計流程,並跟 K 的主管反應,然而,K 依舊我行我素,不當一回事。

接著,B 主管接管團隊之後,K 又在接近下班的會議中,提出設計需求,並希望隔天中午前能夠收到設計,B 主管只有簡單回一句:「這不是我們的做事方式,period!」好個鏗鏘有力的 period!在那之後,K 就只能乖乖照個我們要求的流程,送出需求申請了。

簡單的總結,遇到不懂你專業的人,邀請他體驗你的專業,讓他信服;遇到不管怎樣都不尊重你專業的人,必須會堅定的說不,必要時,當主管的必須硬起來。

在 Amazon 也要加班?

以前的公司,常有機會跟北美的同事合作,當時最大的誤會是:「老外都不加班的。」現在來到了溫哥華,我變成了那個最不想要的加班的「老外」。然而,非得加班的原因有很多,例如專案時程很趕、專案複雜度超過當初的預期、跟跨時區團隊合作…等等。

幸好,Amazon 絕大多數的團隊對於在家工作的態度是很開放的,現在的老闆就曾經跟我說過:「你也不是第一天工作了,再加上能夠進入 Amazon,應該也很清楚責任跟義務,所以,要在哪工作、要什麼時候工作,我真的不是很在意。」

平時花一點心思在專案進度管理,除了可以提高合作夥伴,對於你時程估算的信任感,也可以幫助你取得老闆的認可,讓你可以自由決定要在公司或在家裡加班,在家加班,心情上也會比較不那麼折磨,接著,再加上懂得挑選戰場的能力,就可以避免很多不必要的加班。

回想過去,很多時候加班都是把時間花在很多根本不急、不重要的事情上,而真正重要的事,也許是因為太挑戰、也許是因為沒那麼有趣,拖到火燒屁股了,只好加班趕進度。

如果,你所待的團隊,加班是常態,那需要停下來思考一下加班原因是什麼? 為了實現一個崇高的抱負?為了搶下一個重要的市場先機?還是為了改變世界(咦!)?又或者是因為時間控管能力不佳?花太多時間在當救火隊?還是老闆還沒走我不能走(啊~)?加班有時候是必要之惡,然而,加班要有意義,加班要有效率,不然,久而久之,疲乏了,能拖就拖,上班先看看臉書、跟同事哈拉哈拉,等到午休結束,再來看看今天想做什麼。

在家工作可以挑適合的飲料,幫助專注力(誤)。

別把 UX 當作專案的救世主

最後,這點由一位 UX 設計師來說,似乎很尷尬,不過,事實就是如此。不是公司文化的問題,至少,在我在待過的公司都一樣。如果,UX 設計師在參與專案時,抱著一副「我將用最佳的 UX 設計來拯救產品」的心態(我剛入行就是這樣),那麼,UX 設計師就是一個問題製造者(trouble maker),只會讓團隊對 UX 更不重視。

一個產品要成功,絕不可能單純因為良好的 UX 設計而達成,即便像 UX 被大家捧上天的 Apple,如果沒有超強的技術團隊、頂尖的市場行銷,跟賈伯斯(哈),它也不可能一直推出偉大的產品

這些年下來,幾次碰壁之後,我的心態已經轉變,我的參與,是為了幫助團隊更深刻的探索客戶需求是什麼?如何才能更有效地滿足客戶的需求?然而,在我的定義中,產品經理是我的客戶、研發工程師是我的客戶、客服人員是我的客戶,當然,終端使用者也是我的客戶,唯有大家一起合作,才有機會推出成功的產品, 設計跟研發不應該是敵對的陣營,大家都在同一艘船上,唯有產品成功,一切的努力才有意義

再者,有不少時候,UX 必須為了許多原因去妥協,善用各種用戶研究方法,去幫每一項設計方案訂出優先級別,同時,記住一個很重要的觀念 — 寧可犧牲功能完整性(scope)也不要犧牲使用者體驗(customer experience)。使用者很殘酷,他可以等你功能逐步完整,但是,萬一他的體驗很糟糕,通常就是一去不回頭,特別是在手機應用程式領域,開啟到決定刪除一個應用程式,一般只要八秒鐘。除非,你在產品提供服務的領域,是幾乎沒有替代方案,比方說,Amazon Web Services(哈!)

接著,就是坐下來好好跟團隊檢視,該如何妥協,最後,不管決定為何,都是團隊共同的決定,絕對不要在事後檢討時,把成敗責任歸咎於任何一個人。

即便 Bezos 說要成為全球最重視使用者經驗的公司,UX 仍不是最重要的。

結論

其實,還有很多、很多的事沒有講,有個是因為聽來的、有的是因為不是那麼明顯、還有因為我手酸了。不過,幾個感觸最深的點應該都提到了,而且,仔細想想也沒有真的那麼多不同。歡迎一起討論一下你聽到,或感受到的異同,大家一起交流一下。

__

(本文經原作者 James Liu 授權轉載,並同意 TechOrange 編寫導讀與修訂標題,原文標題為 〈我在 Amazon 擔任 UX 設計師的三年心得回顧 〉。首圖來源:flickr CC licensed)

延伸閱讀

Amazon 面試 SEO PM 超詳盡過程分享:不同領域主管對談、追問式提問

【年後轉職要懂潮流】Yourator 公布最火職缺:工程師、UI/UX 設計師、數位行銷專員

上台 PPT 簡報時間怎麼抓?結論開頭講,但別超過 30 秒


《TO》品牌活動「CONNECT」深度專題重磅更新! 

《TO》年度品牌活動 CONNECT 2020「5G 新經濟」新專題上線! 看台灣新創如何用 5G 翻轉各產業的傳統想像,打造意想不到的創新服務! 馬上報名 獲取最新深度報導。

點關鍵字看更多相關文章: