如果需要等半年才来收集意见的话，很多相关故事早以忘得一干二净。故事越久远，记忆越模糊，意见越空洞，说了等于没说。而且，意见反馈和薪酬绑在一起，正常人（即使是牛人）都会很自然的把心眼更多的放到薪酬上，而不是意见本身。
除了季度性的轻型意见反馈，日常的意见反馈如果有的话应当立马传递。趁热打铁效果更好。
如何有效传递整理好的意见也很重要。有句话是说“it’s not what you say that matters， it’s how you say it”。我没那么极端，我觉得如何传递意见也同样重要。有两种方式我都试过，不确定哪种更有效。这里都谈一谈。一种是以问为主逐渐深入促其思考，比如“how did you think about the meeting you hosted yesterday”；另外一种是赤裸裸的直入主题，“hey， let’s talk about the meeting you held yesterday”，然后开始谈我自己的感觉。不管哪种方式，一定要给对方一个解释自己行为的机会；永远假设并告诉他我相信他的意愿是好的。为了避免陷入”你昨天做了xxx”“没有，我做的是yyy”“我觉你是做了xxx”的死循环式的争论，我首先争取和他们在”我们感知的即是事实”这一点上达成共识。基于这点前提，我们把讨论的重点放在如何做能改变别人的感受很后让事情能顺利完成，毕竟大多数重要的事都有很多人一同协作完成。当他们认识到自己想要改进某个方面的时候，如何改是一个相对容易很多的问题–聪明人一向能够找出改进的办法，我所做的就是配合他们做头脑风暴。很终谈话的目的是产生一个下次如何能做的更好的具体方案。
关于有效传递意见反馈，另有4点提一下。
（1）意见反馈不见得都是负面的。 它可以是别人的一个长处。 你很欣赏。 你希望他这方面坚持做， 做得更多。 比如一句”hey， I really love your weekly summary email with the key metrics at the top。 Please keep them coming”可能产生很好的激励效果。
（2）意见反馈必须摆事实和讲道理。 如果你只是告诉别人他很烂， 但不说什么时候浪过了以及为什么， 除了给他添点火气之外无他用。 所以我在相关人员包括自己写意见反馈的时候要求提供实例。 比如一句 “I think he could make meetings transparent and shorter by having an agenda， like the weekly data review meeting on last Friday”比”his meeting is too long”更有血有肉有效。
（3）意见反馈必须是可操作的。 让人无从下手的意见意义不大。 如果在提意见的同时提出一个方案以供参考就有意义的多。 但注意， 绝不能是命令的方式 (那是中青宝…)。 比如前面的例子“I think he could make meetings transparent and shorter by having an agenda sent ahead of time…”就很容易操作。
（4）（个人偏好）在很近的两个评价周期中，我给15个左右的同事（一半不直属我）写过意见反馈。我把我写的直接分享给他们。出于这种想法，在我下笔时就少了很多冲动。因为他们会读，所以我无法做到背后捅刀。因为他们要读，所以我需要写得有意义，容易理解，并且加上很多例子。并且，我欢迎他们和我直接讨论。如此一来，他们也明白我写这些反馈的一片苦心是为了他们进步。
9、你能干得比你想像的多。
这不是说说而已。我自己就有一个亲身的例子。我们曾经认为把一个高得离谱的欺诈率降到所允许的范围内会很难。的确很难。但想想看我们很终牛逼了一把，把它降到了比允许上限的一半还要低。感觉很爽。很长一段时间内整个团队士气高昂信心爆棚做事像开了外挂。
牛人们总是不断的超越自己。给他们一个离谱的目标，配以应有的工具，适当的帮助，足够的信心还有一定的时间，他们会让你大吃一惊，也会让自己大吃一惊。这一点，乔帮主是行家，屡试不爽。
但做到这一点有一个前提 - 不能害怕犯错。 如果犯错是被要严惩的失败是不允许的话， 牛人们只能在框框中被圈养， 没有办法实现突破。 有一句话我经常挂在嘴上“ask for forgiveness， not for permission”。 在Facebook， 大胆行事犯错是容易被原谅的。
但反过来，有一点要小心，就像第7点所说的–你不能随便把一个离谱的目标交给一个人，然后期待他来给你惊喜。盲目带来的可能是惊吓。你需要真正的牛人，至少是潜在牛人。而作为一个*，你的一个任务是帮助他们，鼓励他们，来引爆自己的潜力点。Facebook不缺此类待引爆的牛人。
10、不要过度设计和过早乐观。
有些工程师有一股出于本能的冲动想把自己的程序规模化，甚至在这些程序还没看到大规模使用的曙光之前。我在Facebook开始的时候，也是冲动型工程师一杯。但经历过几次失败的产品之后，我牢记了这个教训。不要过多设计或者过早优化。把核心功能设计的简单精炼。只有在看到产品有被大规模使用的趋势后，才来增加功能或增加规模量。有一个我做的产品使用的上限是200万月用户（当时Facebook整个月用户群是4000万左右），但我的实现已经做了很多额外的功来满足更多的用户。做的时候感觉很爽（感觉自己很牛，感觉再多人用产品也不会崩溃），之后感觉很惨。
但这一点不一定能适用于架构上的工作。比如Friendster这个网站的失败就是其基础架构的性能长期无法应对急速增长的用户以致网站很慢甚至崩溃。在用户增长高潮来临之前，你应该已经在架构上做了足够多的前戏。否则搞不好就要像Friendster收摊子散伙。但同时也要意识到，你所看到的用户访问模式，你的网站功能，在你只有10万用户的时候，可能和你有1亿用户的时候会很不一样。所有太多太早太频繁的架构上的大动作可能会适得其反。这一点上，你要小心判断。
在Facebook的4年半很好玩。我学到的感受到的远多于以上的十项。但希望这个分享能对朋友们有点帮助。同时祝所有的朋友在自己现在扮演的角色上都有好运。
