工程師的疑惑
最近在豆瓣關注了一個網友，發了很多關於工作的片段化判斷。例如關於站隊抱團問題、關於新舊技術的迭代、關於怎麼包裝結果去獲得晉升。看到他的帖子，就像看到我的一個朋友，他在工作的早期也遇到了這些問題。不過他後面通過換公司，一定程度上少了很多類似的困擾。
這位網友，看起來像是在字節工作。我很好奇，宣揚坦誠清晰的字節，爲什麼還會有站隊鬥爭的問題，爲什麼還會有過度包裝成果以換取晉升的問題。因爲正如前面分析過的《戰略歷程》所言，公司不是給員工提供政治鬥爭的決鬥場，而是一個提供交付、提供產品服務給到客戶的地方。
工程師與團隊
這個問題的起源，我仔細想了想，大概是作爲geek的工程師，在面對團隊中的人的關係時，表現出的正常的困惑。就這個問題，我的那位朋友，多少也遇到了（雖然沒有字節老哥誇張）。我的這位朋友會好奇，什麼樣的團隊是能夠產出優質產品和服務的團隊。作爲工程師，我們的能力上限在哪裏，團隊的意義是什麼。如何作爲一個受歡迎的工程師，融入團隊，帶領團隊營造出色的團隊氛圍。
帶着上述疑問，我閱讀了《極客與團隊》一書。這本書的起源，是谷歌開發者們，就版本管理的開源社區發生的事，總結而出的經驗。關於geek、關於怎麼運營好一個開源社區的。後來逐漸抽象成了，作爲工程師，如何藉助團隊的力量，如何避免那些害羣之馬，如何培養出色的團隊文化。
工程問題都很簡單，但人際關係卻很難把握。這對於刻板印象下，呆板、木訥的程序員來說，可不是一個好消息。然而一個人的力量始終有限。只有藉助團隊，優秀工程師的能力，才能得到放大。相信聰明的工程師讀者們，有能力習得一些技巧。
沒有天才
在軟件開發領域，常常會流傳很多天才傳說。例如一個人寫出Linux、寫出語言框架這種。但要知道，他們其實只寫了一部分代碼，後續的工作完善，其實有上百名工程師參與。這件事要傳達的意思在於，軟件的成功不在於你的代碼多麼神通，而在於你能否很好的合作。忘掉那些單打獨鬥造神的故事吧，即使比爾蓋茨、喬布斯他們，在早期也是好幾個人搭夥做起來的。
在程序員裏面，流行這樣一種思維：我得把代碼藏好。這就說到很多大廠的開源項目。網上會批評國內的一些大廠，能賺錢但很少開源代碼。不過也有人指出，它們不開源不是因爲這是核心機密，而是因爲代碼寫得太爛了... 在程序員裏，也會有這種思維。其實這就是沒有安全感的一種表現。害怕被別人看笑話被批評，或者是同事看到自己的代碼想法，搶先發布了我的特性。
分享是有好處的。這點我的體驗也是如此，很多模型框架，幫助了我們獲得快速的起步。分享給別人，你能夠發現自己是不是在重複造輪子。也能夠快速儘早地檢驗方向。對於團隊來說，這也可以強化公車因子（即通勤公車上困多少人，會影響到項目）。越多的人瞭解項目，公車因子就越大。
團隊纔是王道
想必看我文章的同學都多少經歷了一些軟件開發項目。你一定會發現，這東西是集體項目。如果你的節點很小，那很可能就是個單點項目了（這種項目很危險，上期的文章也有講應對策略）。
經歷過不同團隊的你也一定發現，有些團隊待得很難受。大家相互提防，各說各話。在一個會議上，遲遲得不出有效結論。你做的東西別人不信任你，你也不想用別人造的垃圾輪子。而在硬幣的另一面你會發現：大家彼此都很友善，溝通的節奏很頻繁，在會議上也能得出有效結論。在完成工作後，對方還會感謝你的付出。
這兩種文化氛圍，我的朋友都呆過。第一種人員流失嚴重，變動巨大，但那幾個把持領導位置的leader卻穩坐釣魚臺。第二種，即使團隊做出了廣受世界範圍喜歡的產品，大家仍然保持謙遜，保持尊重和信任。一開始，我以爲是因爲第一種的考覈方式有問題。它們會在每月進行績效考評，需要數字來說明你的貢獻。在這個過程中出現了很多“虛假”數字。對業務毫無幫助卻能分到大額獎金。後來我發現，自己其實只看到了表面。真正驅動它們考覈差異的點在於，背後的團隊文化。
在第二家公司裏，大家提倡的是有話直說，以理服人的文化。同時，由於扁平化的架構設計，沒有來自title的直接壓力，大家能就事論事，進行充分的討論，以事實爲依據，推動事情發展。
出色團隊文化的三大要素
從上面的兩個場景，我們能夠提煉出出色團隊氛圍的三大特點：謙虛、尊重和信任。謙虛是放下自負，用平等的態度去對話，而不是論資排輩。尊重則在於，尊重對方作爲獨立個體的能動性。無論他是你的下屬，還是對接部門的一線同學。提出建設性的批評，而不是人身攻擊。信任彼此，不會爲了不出錯，而進行防守。相反，鼓勵從錯誤中學習：學到了什麼，下次將怎麼樣去改進。
小結
社交不是勾心鬥角或操縱他人，核心在於相互借力成就事業。保持一定的空閒思考時間，開放傾聽，將會是一種好的開始。
這部分只是個總起，後續將針對工程師與團隊展開講講。主要包括如何打造好的團隊文化，如何區分管理與領導，如何驅逐害羣之馬，如何應對不同類型的組織（向上管理）。
喜歡的朋友記得點個贊，明天同一時間不見不散。