一年一度或兩度的意見反饋在硅谷公司是非常常見的。它的目的不是設置起來給員工難堪，讓他們互相責難的。它的目的是希望員工對自己對他人有更全面的認識，以助進步。意見反饋有自我反饋和同事反饋兩部分。自我反饋是自己評定自己，完成了哪些目標，錯失了哪些目標，哪些方面做好了，哪些方面還待進步。但由于是自己踢球兼裁判，難免有偏頗。同事反饋，就像一枚鏡子，讓你看到180度之外的自己。在Facebook，360度的正式意見反饋是一年兩次，并且和薪酬掛鉤。但近年來，意見反饋和薪酬評定逐漸分開。比如我做的一件事就是季度性的意見反饋，時間和正式評定錯開。在那幾天中，我請求所有相關組的同事在自愿的前提下給我寫寫關于我直屬組員的意見反饋，短短幾句都行。我會收集，綜合，最后在1-1碰頭會時反饋給我的組員。
如果需要等半年才來收集意見的話，很多相關故事早以忘得一干二凈。故事越久遠，記憶越模糊，意見越空洞，說了等于沒說。而且，意見反饋和薪酬綁在一起，正常人（即使是牛人）都會很自然的把心眼更多的放到薪酬上，而不是意見本身。
除了季度性的輕型意見反饋，日常的意見反饋如果有的話應當立馬傳遞。趁熱打鐵效果更好。
如何有效傳遞整理好的意見也很重要。有句話是說“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年半很好玩。我學到的感受到的遠多于以上的十項。但希望這個分享能對朋友們有點幫助。同時祝所有的朋友在自己現在扮演的角色上都有好運。
熱門專題：