工程管理

Engineering Management 聽起來是個艱難的管理詞彙，事實上也是。所有的軟體開發專案，都會有這麼一個天字第一號大挑戰: 控制時程。簡而言之，在 M 社的研發手法，就是透過 EM，決定什麼要做，甚麼不要做，來控制開發的總時間。講是很容易，但是當實際執行起來，是處處違反人性的。

話說當年本人的 profession剛從 engineer “升等” 成 engineering engagement 之時，心裡時很惶恐的。老實說，叫一個非科班出身的黑手擔起這個大任，壓力之大非同小可。還好 M 社處處有前輩高人，最直截了當的作法，就是到處虛心討教各個前輩的心法，看是不是能融會貫通成自己的一套。問了一圈下來，關於帶領團隊的方法，意見是五花八門，各種奇奇怪怪的理論都有，眼花撩亂，倒是對管理專案的手法，反而出人意外的相當一致:

“你一定要學會堅決心狠手辣的砍，絕不能心軟” 一位資深 PM 經理人這樣跟我說。砍甚麼? 砍功能 (cut features)。 為什麼這是違反人性? 我想全天下的 PM SDE SDET 的基本心態都一樣: 軟體要功能多才會有價值，有價值客戶才會用，客戶用才會買，有人買才會賺錢。但是功能的多寡與開發時間是互斥的，功能太多就不太可能準時；更糟的是，當時程延滯時，人的直覺反應是投入更多的資源想要加速，這樣反而會適得其反，增加更多的工作量，時間拖更久，形成負面循環。這時候就有人要出來扮這個黑臉，誰薪水高誰就要出來做這件討人厭的事 (原來經理人被怨恨是其來有自)。

簡單來說，EM 就是將計畫的功能或工作量減少到合乎既定時程，不管預計發展的功能有多吸引人，定期推出 (on time release) 的價值高於一切，會延遲時程的只有產品招回等級 (re-call class) 或資訊安全等非修不可的問題。

其實M 社也不是一開始就有這種文化，是經歷過好幾次的軟體開發危機 (那些產品大家心裡可以對號入座)，才磨出這種手法。其中最重要的推手，就是之前所提到 Steven Sinofsky，他有一項著名的宣言: Shipping is a feature，大家可以去網路上蒐一下，他把 PM 五樣重要的觀念說得非常清楚。當然，M 社 cut feature 的作法是有一定的程序，並不是大刀亂砍，這裡還牽涉到另一個重要的觀念 – 設定優先順序 (prioritization)。不過這一篇先給大家一個基本觀念，之後再來逐一談細節。