3) 意见反馈必须是可操作的. 让人无从下手的意见意义不大. 如果在提意见的同时提出一个方案以供参考就有意义的多. 但注意, 绝不能是命令的方式 (那是中青宝…). 比如前面的例子”I think he could make meetings transparent and shorter by having an agenda sent ahead of time…”就很容易操作.
4) (个人偏好) 在最近的两个评价周期中, 我给15个左右的同事(一半不直属我)写过意见反馈. 我把我写的直接分享给他们. 出于这种想法, 在我下笔时就少了很多冲动. 因为他们会读, 所以我无法做到背后捅刀. 因为他们要读, 所以我需要写得有意义, 容易理解, 并且加上很多例子. 并且, 我欢迎他们和我直接讨论. 如此一来, 他们也明白我写这些反馈的一片苦心是为了他们进步.
www.liushuye.com9 你可以比你想象的做得刚好
这不是说说而已. 我自己就有一个亲身的例子. 我们曾经认为把一个高得离谱的欺诈率降到所允许的范围内会很难. 的确很难. 但想想看我们最终牛逼了一把, 把它降到了比允许上限的一半还要低. 感觉很爽. 很长一段时间内整个团队士气高昂信心爆棚做事像开了外挂.
牛人们总是不断的超越自己. 给他们一个离谱的目标, 配以应有的工具, 适当的帮助, 足够的信心还有一定的时间, 他们会让你大吃一惊, 也会让自己大吃一惊. 这一点, 乔帮主是行家, 屡试不爽.
但做到这一点有一个前提 - 不能害怕犯错. 如果犯错是被要严惩的失败是不允许的话, 牛人们只能在框框中被圈养, 没有办法实现突破. 有一句话我经常挂在嘴上”ask for forgiveness, not for permission“. 在Facebook, 大胆行事犯错是容易被原谅的.
但反过来, 有一点要小心, 就像第7点所说的 – 你不能随便把一个离谱的目标交给一个人, 然后期待他来给你惊喜. 盲目带来的可能是惊吓. 你需要真正的牛人, 至少是潜在牛人. 而作为一个领导者, 你的一个任务是帮助他们, 鼓励他们, 来引爆自己的潜力点. Facebook不缺此类待引爆的牛人.
10 不要过多设计或者过早优化
有些工程师有一股出于本能的冲动想把自己的程序规模化, 甚至在这些程序还没看到大规模使用的曙光之前. 我在Facebook开始的时候, 也是冲动型工程师一杯. 但经历过几次失败的产品之后, 我牢记了这个教训. 不要过多设计或者过早优化. 把核心功能设计的简单精炼. 只有在看到产品有被大规模使用的趋势后, 才来增加功能或增加规模量. 有一个我做的产品使用的上限是200万月用户(当时Facebook整个月用户群是4000万左右), 但我的实现已经做了很多额外的功来满足更多的用户. 做的时候感觉很爽(感觉自己很牛, 感觉再多人用产品也不会崩溃), 之后感觉很惨.
但这一点不一定能适用于架构上的工作. 比如Friendster这个网站的失败就是其基础架构的性能长期无法应对急速增长的用户以致网站很慢甚至崩溃. 在用户增长高潮来临之前, 你应该已经在架构上做了足够多的前戏. 否 则搞不好就要像Friendster收摊子散伙. 但同时也要意识到, 你所看到的用户访问模式, 你的网站功能, 在你只有10万用户的时候, 可能和你有1亿用户的时候会很不一样. 所有太多太早太频繁的架构上的大动作可能会适得其反. 这一点上, 你要小心判断.
结语:
在Facebook的4年半很好玩. 我学到的感受到的远多于以上的十项. 但希望这个分享能对朋友们有点帮助. 同时祝所有的朋友在自己现在扮演的角色上都有好运.
