管理者,你懂工程師嗎?

這些日子,接觸過幾次這樣的案例,我們有一個計畫書,我們有一個Idea,我們把腦袋想要的一切都寫在計畫書了,這是一份商業計畫書,下一步就是執行,我相信有過這個經驗的人,到這個步驟都會遇到一個問題,就是當執行後,發現執行結構和計畫中的預期,有明顯的落差。

為何呢?其實這是一個誤會,這不是落差,而是事實上,黑科技並不存在,即便你認為他是最簡單、最基本的功能,實際上,那只是開發出來的結果操作「簡單」不是製作簡單。

所以即便再簡單的東西,都會有最「陽春」的時候,當然這和腦袋中的陽春定義是不同,換句話說,就算表面看起來很神奇的黑科技其實也還是需要從底層建立起,科技發展會幫助加速我們建設的時間,但是很多時候我們無法避免要度過這種尷尬的階段。

而這時候管理工程師的角色就極其重要,在現在的管理團隊上,這個角色一般是PM或SM,即便有很多工程師不太喜歡PM或SM,但是他的存在,其實就是一個翻譯包,他需要翻譯把商業目標轉化成可執行並提供解決方案。

這個工作首先,必須要把商業計畫書的內容,翻譯成程式執行的過程,分析出難易度、可能遇到的問題、所需耗費的時間,某程度,就是要Full Stack工程師的思維,但是也要明白用戶需求和商業需求,平衡一下利弊,權衡一下重要性和時間效益等等,這個時候我們要考慮不同崗位的同事,而不是僅僅想某個細節,這部分關係到時程和工作量的分配。

可是不難發現,很多PM或SM是不懂的Coding,當然有的話可以節省一些溝通成本,但其實只需要搭配適合的工程師,配合一下和諮詢他們的意見,日子有功,基礎知識就會建立起來,如果你剛好要管理一個工程師團隊,而你剛好不太熟悉程式,即便日子有功還是有幾點值得留意的。

1,過去的經驗不等於未來都可以參考,要知道科技的變化速度比你換髮型的時間還好快。
2,可以詢問,不要懷疑。可以考慮,不要顧慮。
3,多瞭解不同領域的發現,可以的話學一下,不需要精通。
4,相信一句話,你不知道的比你知道的多,這樣你才會有足夠的量度聽取工程師們的意見。

管理工程師的工作就是需要懂得程式並且能合理分配任務,考慮的層面不能只有時間和結果,還要知道風險和方案的選擇。

負責人,不是控制人

管理是負責,不是控制,把任務分配出去之後就讓工程師們自己完成,當然前提是必須按照彼此協定好的規則,例如編寫習慣、代碼風格、使用工具,管理人也是要做一些工程師不願意做的事,例如寫文檔,跨部門溝通協調等等。

工程師最怕微管理,這只會打破他們的工作節奏和默契,而作為管理人最重要的是協助和觀察幫助每個人都能達成任務。

資訊斷層

這裡說的資訊斷層不是說教育,而是公司結構,軟體開發是一個很有趣的事情,新科技帶來的便利也是破壞和重建的過程,必然會有問題,可是大老闆或管理人不懂這個道理,就如《誰「殺死」了諾基亞?兩年後歐洲第一商學院教授找出了真相》一文所說的,中間管理層和高層有這個問題,團隊成員和管理人也會有這個問題,試想剛剛的第一點,團隊成員每個人或許都有自己專攻的領域,他們必定比你更熟悉,但是為求保險,推陳出新的科技往往不會被帶入團隊中,而最後的結果是什麼,就是永遠在用最保險的方法,做出一貫的產品,而領導再上頭舉起大喊創新的同時,其實公司真的有創新的空間嗎?創新淪為口號,只是為了變而變,變成行銷口號。

資訊獲得有很多管道,管理者最喜歡的管道就是參訪,參考別人的做法,那只是依樣畫葫蘆,小貓學虎走,其實仔細想,那些值得讓我們參訪的公司,他們是參訪誰的呢?我們為何不就能自己思考一下,為何不問問自己的團隊呢,或許有些人會認為,成功管理的經驗和值得我們學習,當然我是非常認同的,只是現在如果你要管教你家的孩子,你去問香港首富齊家之道,不會有人說你是不對,可是問題是,你不是李嘉誠;同理,去訪問google、去訪問facebook、問題是你不是google、更加不是facebook,甚至你公司還禁用它呢!

避免資訊斷層我覺得是科技公司很重要的一環,和你一起共事的人最能明白自己家的產品優缺點,鼓勵內部創意和小團隊開發,能夠增加趣味又可以改善產品,豈不是很好嗎。

敏捷開發,不是敏捷變動

敏捷式開發不是這文章的重點,只是想快速的釐清,敏捷式開發不是說工程師的身手很敏捷,想要你怎麼改就怎麼改,所以不要誤會,不要隨意開出下週要,明天要,下午要的需求,Item(scrum術語)最好是功能導向,目標產出,例如「看到我就自動開門」這個只是最終結果內涵卻是非常多步驟,一個Sprint做不完的東西就不適合放(參考第一點,合理的分配)

結論

管理人最容易掉進自己的思維窄門,例如一個從小到老都種地瓜的農夫,有一天你和他說種蘋果,他會懷疑為何不是埋在地上;一個善於用毒的人,行刺首先考慮的就是毒。當管理者在思考問題是以自己的背景作為考量的時候,基本上都是很危險的。管理者不能只專精一個領域,但是必須要知道怎樣才是專精,所以管理者也真的不需要和團隊比較誰比較專精,如同教練和球員,喬丹再厲害,也會有教練,但是如果你說教練和喬丹比賽,你覺得誰會贏呢?所以很多時候,角逐錯的方向就會導致第三點,之後團員都不會提供新的資訊,反正都是管理者說了算。

竟然有管理方法,目的就是有效率以及有一套大家都認同的步調,既然使用管理方法,就不要有第二點的行為,臨時起意破壞步調的行為。

當一個工程師,和管理一群工程師的差別是什麼?
當一個士兵在戰鬥,那只是一場毆鬥,
當一群士兵在戰鬥,那就是一場戰爭,
戰爭沒策略,多兵也沒有用。

如果企業不會管理工程師,再多工程師也是沒有用。