孤鳥與萬人迷

前一陣子在社群網站看到很多人討論一個主題，原PO敘述所遇到的一個軟體工程師，雖然不善溝通但是能獨立作戰，即使不熟悉的技術也能苦K完成任務，頗為這位工程師抱不平。反觀許多人能言善道，個人產出雖然普普，在職場上反而順遂。許多人開始議論老闆和人資不識才，千里馬難遇伯樂等等的說法。

職場混久了，知道這種現象稀鬆平常，更不限於軟體開發的產業。不過這裡有個有趣的焦點:在軟體開發中，「埋頭苦幹」到底好不好?

回顧在M社的經驗，我所遇過的神等級開發工程師，木訥寡言的人非常少。特別要說明的是:由於M社夠大，所以有許多頂尖的人才不需要兼任管理職(對，很多人不喜歡當官)，所以理論上這些神人不太需要討好別人。不過據我的觀察，這些神人都有一些特點:平易近人、脾氣好、很樂意與人交流、遇到再白癡的問題也不會動氣(哈哈我自己問過不少這樣的問題)。

基於好奇，曾經有個機會請教當時M社的總人資長，要如何才能找到這些高EQ的人才?她語意深長地回答:她這輩子還沒有看過能測EQ的工具，但是工程師是群聚的生物，如果有個人身邊有很多工程師圍繞，她就會想辦法去把這人請來。這是我第一次被點醒群聚力量對軟體開發的重要性。

另一方面也許這跟軟體系統的規模和複雜度有關:以Office為例，後來幾乎已經找不到與其它功能沒有關係的功能，所有的coding都跟其他的feature crew甚至產品有關聯，為的都是讓使用者體驗更流暢。只是開發的工程師的負擔就增加了，沒有人能夠「搞定自己餐盤裡的東西」就能交差了事，硬逼著大家要跟別人解釋自己負責的功能不可。

而且以整個開發周期來說，除錯就佔了一半以上的時間。雖然每隻臭蟲還是有負責的工程師，很少看到一個人就能解決的問題；我看過的最高紀錄是一個bug轉過15次手，並不是相互踢皮球，而是要解的眉眉角角就是要那麼多隻手，為了飯碗，誰敢置身事外。

最後的關鍵因素是:技術的變化實在太快了，沒有一個單一個人能掌握所有的面向。首席架構師能訂的只是大方向大框架，最後要實際要落地的幾乎都是拼裝和妥協的結果。再逐次疊代改進。市場沒有辦法等待慢慢琢磨出最佳做法。

即使是局外人，也可以想像這樣的開發壓力有多大，多容易產生衝突(所以早期M社常給人這樣的印象)；而且這並不全是無知或是專制老闆級經理人造成的，要做出好產品就是要這樣。這樣的環境下，自然天才自走砲型的人就越來越少，擅長溝通而且能聚集眾人綜效的人才能勝出。

最近有一些機會了解到國內硬體產業中的軟體(或直接就說是韌體吧)開發內容，多半以獨立任務居多，所以埋頭苦幹是有空間的。但話說回來，如果有心想轉型到以軟體服務為軸心，有許多人才需求的觀念和想法恐怕要有基本的改變，不然可能白忙一場。