在 Amazon 工作发现跟台企最大不同:自己挑选战场、学会


2020-06-27


 

在 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 工作发现跟台企最大不同:自己挑选战场、学会

讲完了三点体会最深刻的不同,接着来说说,曾经以为应该会不一样,后来发现到哪都一样的问题。

到哪里都有不尊重专业的人

就像前面所说的,即便在 Amazon 这样的公司,还是会有不尊重专业的人,记得去年,我曾经一整个气到在自己的 Facebook 上怒吼:「当初是哪个瞎眼的录用你!」不过,面对这样的人,在这些年训练下来,大概已经有一套自己的 SOP 了。

首先,在专案开始的启动会议(kick-off meeting)上,清楚的说明接下来计画做的事、需要的时间,并慎重的解释每一个步骤背后的原因,最后,一定要确认大家都认同。接着,每一个步骤开始前,都要让专案相关人员知道,期间,尽可能让他们一起参与,步骤结束后,一起检讨,这幺做的目的是, 让他们「体会」你做事的流程 ,以及每一个步骤对专案成败的影响。正所谓,身教重于言教啊(亲身参与比听一堆设计流程演讲有帮助多了。)

最近才遇到一位资深工程师,特地在会议之后,跑来跟我说:「我从来就没有想到只有三个画面,却要思考这幺多细节,原来,UX 设计真的不是想像中的动动滑鼠而已。」

当然,还是会有些人在经历过这一切之后,依然不把你的专业当一回事,这时候,就是主管需要出手的时候了。在前一个团队,碰巧历经两个做事风格迥异的主管,事情发生后,A 主管,跑去跟 K 产品经理(就是让我怒吼的人)一对一解释设计流程,并跟 K 的主管反应,然而,K 依旧我行我素,不当一回事。

接着,B 主管接管团队之后,K 又在接近下班的会议中,提出设计需求,并希望隔天中午前能够收到设计,B 主管只有简单回一句:「这不是我们的做事方式,period!」好个铿锵有力的 period!在那之后,K 就只能乖乖照个我们要求的流程,送出需求申请了。

简单的总结,遇到不懂你专业的人,邀请他体验你的专业,让他信服;遇到不管怎样都不尊重你专业的人,必须会坚定的说不,必要时,当主管的必须硬起来。

在 Amazon 也要加班?

以前的公司,常有机会跟北美的同事合作,当时最大的误会是:「老外都不加班的。」现在来到了温哥华,我变成了那个最不想要的加班的「老外」。然而,非得加班的原因有很多,例如专案时程很赶、专案複杂度超过当初的预期、跟跨时区团队合作…等等。

幸好,Amazon 绝大多数的团队对于在家工作的态度是很开放的,现在的老闆就曾经跟我说过:「你也不是第一天工作了,再加上能够进入 Amazon,应该也很清楚责任跟义务,所以,要在哪工作、要什幺时候工作,我真的不是很在意。」

平时花一点心思在专案进度管理,除了可以提高合作伙伴,对于你时程估算的信任感,也可以帮助你取得老闆的认可,让你可以自由决定要在公司或在家里加班,在家加班,心情上也会比较不那幺折磨,接着,再加上懂得挑选战场的能力,就可以避免很多不必要的加班。

回想过去,很多时候加班都是把时间花在很多根本不急、不重要的事情上,而真正重要的事,也许是因为太挑战、也许是因为没那幺有趣,拖到火烧屁股了,只好加班赶进度。

如果,你所待的团队,加班是常态,那需要停下来思考一下加班原因是什幺? 为了实现一个崇高的抱负?为了抢下一个重要的市场先机?还是为了改变世界(咦!)?又或者是因为时间控管能力不佳?花太多时间在当救火队?还是老闆还没走我不能走(啊~)?加班有时候是必要之恶,然而,加班要有意义,加班要有效率,不然,久而久之,疲乏了,能拖就拖,上班先看看脸书、跟同事哈拉哈拉,等到午休结束,再来看看今天想做什幺。

在 Amazon 工作发现跟台企最大不同:自己挑选战场、学会别把 UX 当作专案的救世主

最后,这点由一位 UX 设计师来说,似乎很尴尬,不过,事实就是如此。不是公司文化的问题,至少,在我在待过的公司都一样。如果,UX 设计师在参与专案时,抱着一副「我将用最佳的 UX 设计来拯救产品」的心态(我刚入行就是这样),那幺,UX 设计师就是一个问题製造者(trouble maker),只会让团队对 UX 更不重视。

一个产品要成功,绝不可能单纯因为良好的 UX 设计而达成,即便像 UX 被大家捧上天的 Apple,如果没有超强的技术团队、顶尖的市场行销,跟贾伯斯(哈),它也不可能一直推出伟大的产品 。

这些年下来,几次碰壁之后,我的心态已经转变,我的参与,是为了帮助团队更深刻的探索客户需求是什幺?如何才能更有效地满足客户的需求?然而,在我的定义中,产品经理是我的客户、研发工程师是我的客户、客服人员是我的客户,当然,终端使用者也是我的客户,唯有大家一起合作,才有机会推出成功的产品, 设计跟研发不应该是敌对的阵营,大家都在同一艘船上,唯有产品成功,一切的努力才有意义 。

再者,有不少时候,UX 必须为了许多原因去妥协,善用各种用户研究方法,去帮每一项设计方案订出优先级别,同时,记住一个很重要的观念 — 宁可牺牲功能完整性(scope)也不要牺牲使用者体验(customer experience)。使用者很残酷,他可以等你功能逐步完整,但是,万一他的体验很糟糕,通常就是一去不回头,特别是在手机应用程式领域,开启到决定删除一个应用程式,一般只要八秒钟。除非,你在产品提供服务的领域,是几乎没有替代方案,比方说,Amazon Web Services(哈!)

接着,就是坐下来好好跟团队检视,该如何妥协,最后,不管决定为何,都是团队共同的决定,绝对不要在事后检讨时,把成败责任归咎于任何一个人。

在 Amazon 工作发现跟台企最大不同:自己挑选战场、学会结论

其实,还有很多、很多的事没有讲,有个是因为听来的、有的是因为不是那幺明显、还有因为我手酸了。不过,几个感触最深的点应该都提到了,而且,仔细想想也没有真的那幺多不同。欢迎一起讨论一下你听到,或感受到的异同,大家一起交流一下。

__



上一篇:
下一篇:

热门文章

 58种「别有洞天」的照片墙排列法

58种「别有洞天」的照片墙排列法

 58种酱汁做法 很实用请父母保存下来

58种酱汁做法 很实用请父母保存下来

 58统一狮VIP会员前进大叶高岛屋享受停车优惠别错过!

58统一狮VIP会员前进大叶高岛屋享受停车优惠别错过!