2015/11/08 第392期

Performance review

在大公司工作的人都很熟悉这种半年一次(或一年一次)的 performance review。你评价自己在过去一段时间表现如何,同事之间也互现评价。本文详细描述了具体如何操作。

创业公司一般发展到万不得已了才实行这种 performance review 的机制,因为这很耗时间,员工其实也普遍有抵制的情绪。很多公司往往都要用贡献几天甚至一周的时间让全公司来做这件事。

四口之家的旧金山蜗居生活

我这个标题取得似乎有点悲观,其实原文是挺乐观正能量的。作者写了住小studio的心得体会,生活小窍门,以及喜怒哀乐,很真实,住在旧金山城里在创业公司工作的年轻人基本都是这样的。

Google 里的工程师质量在下降吗

这是 Quora 上的匿名答案(讲公司坏话当然要匿名了~),可能有偏见,但一些点还是不错的(也能应用到Google以外的大公司)。不管多好的大公司里,你碰到那种“这么垃圾竟然也能被招进来”的人会很多。

大公司里有成熟的infrastructure,作为个体,大部分情况你只要从code base复制粘贴代码,运行一些神奇的命令,代码就神奇地被部署到某个地方,神奇地运行起来。也不用理解为什么会这么神奇。很多在大公司里被宠坏了的工程师们离开了公司里封装得很好的api就写不了代码。

The cloud wars

对 Cloud 这场战争里的主要玩家们进行了点评,主要是“Seattle race”(微软 与 亚马逊的对决),没硅谷什么事。

其实可以换个角度来对比,看看每家的明星用户都有谁,然后对比一下这些明星用户的名气与规模,间接就能对比各家Cloud的实力了(似乎有点伪科学~):Amazon的用户有Netflix,Airbnb,Yelp等;Google的有可口可乐,Best Buy,Snapchat等;微软的有GE Healthcare,NBC,Xerox

谨慎地把用户提出的功能请求加入产品里

不要用户说他想要A功能,你就真的立刻马上不加思考地加了A功能。要把用户说的话翻译一下(声音大的未必是真用户),理解他们的需求,不要停留在功能表象上。

“Don’t just give clients what they ask for — solve their problems.”

Rework 这本书里在处理用户请求方面也讲得很好。刻意地放弃一些用户(伪用户),你不能迎合每个人。也没必要把每个用户的功能请求记下来。如果真的是民心所向的功能请求,用户们会不断地告诉你;如果只是极个别用户的古怪的请求,可以忽略。