孤鳥與萬人迷

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

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

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

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

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

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

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

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

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

results matching ""

    No results matching ""