Engineer Features

最近工作的關係，接觸到兩個專案，很不巧的這兩個專案都是由工程師(Engineer)所主導的，但是兩者所呈現出來的是很大的不同。

先說專案 A 好了，該專案有真正的 PM (產品經理)，也有方向，想做什麼樣的東西是很明確的，但是這個專案的 requirements 是由工程師出身的專案經理在主導 (我知道很奇怪，但是在我們公司，產品經理跟專案經理是兩個不同的職務)，最近看了這個專案的 requirement 文件，整份文件看下來，所有 requirement 文件中所描述的 "feature" 都是試圖解決產品本身的問題，或者說是技術上的問題，而且是以工程的角度來解決。如果這種情況是發生在程式設計上所謂的 refactoring 並無不可，事實上，當產品經歷一段時間的演進之後，適當的做 refactoring 是可以達到一種換血的目的，有助於以後長久的開發。但是這個專案並不適用於這種情況，它是一個大版本的演進，但並不是因為遇到瓶頸才要做的改變。

至於專案 B 呢，它沒有產品經理，一開始想做什麼也不見得很明確，純粹是一個 Proof of concept 的東西，這樣的東西一開始自然是由工程師們來進行，但是與專案 A 不同的是，專案 B 是以相反的方向來探究問題。這群工程師先四處觀察與訪談「問題點」，討論與思辨什麼是客戶所遭遇的「問題」，並藉由觀察到的「問題」來找尋「方法」來解決這些「問題」，再由「方法」來延伸出「工程技術」。最後專案 B 所呈現出來的結果就相當令人激賞，不僅受到很多人的稱讚，我想對該 team 來說他們也展現了該 team 的價值。

從這兩個專案來看， 從我自己的觀察以及以前的經驗，都是要盡量去避免所謂的 engineer features。工程師(engineer) 是個很特殊的「生物」(我自己也屬於這生物)，在想法上是非常著重「邏輯」的，但這「邏輯」往往是放在程式架構上的「合理性」，對於程式設計上總有偏好的 beauty，在產品設計或者程式設計上，能否達到這 beauty 往往會變成工程師最在意的因素，但是這樣的東西並不見得對客戶們受用，客戶們應該更關心的是產品能為他們帶來什麼好處，這也是客戶購買產品的動機，如果只是做對自身問題的改進，對問題本身沒有很大突破的話，對客戶來說，為什麼要掏錢出來購買此產品，或者是原本的版本用的好好的，為什麼要花錢在升級上。同樣的事情發生在今天我與一個 engineer 的對話上，我半開玩笑的對一個擁有 MacBook 的同事說：「ㄟ，Snow Leopard 出來了耶，升級版只要 29 美元，要不要買來升級看看。」，一般來說，工程師都喜歡科技嚐鮮，我就是例子之一，不過他卻很巧妙的回了我一句話：「新版本有什麼特別的地方嗎？如果沒有，我幹嘛花錢買個用不著的東西？」，我稍微楞了一下，查了一下 Apple 所宣稱的 Snow Leopard 演進，很多都是在強調新版本在效能上的演進，但是說真的，Mac OS 10.5 在效能表現上並不會讓我覺得太差啊，我也仔細思考了一下，我真的需要花這 29 塊美金來買效能演進嗎？這真是個好問題，不過老實話，我還是會去買，因為早就中 apple 的毒了。

其實除了 engineer features 外，在我的經驗中，還有一種 feature 是要特別小心的，我暫且將它稱之為 PM 或者是 Slaes features。PM 或者 Sales 在賣產品時，經常會將重點放在 feature list 上，往往會落入與競爭對手比較 feature 的迷思上，會有種「別人有，我也要有」的想法，而跟工程師相反的是，產品經理不見得對技術性的東西那麼了解，他很難理解為什麼相同的 feature 在自家的產品上反而會帶來危險，或者根本牛頭不對馬嘴，最後的結果是要嘛 feature 做不出來，或者做出來毫無意義。我以前做產品不時會遇到這樣的問題，如果又不巧是遇到沒 sense 的產品經理，可能花再多時間解釋也解釋不通，最後的情況是妥協，然後做個四不像的東西，最後成為產品的包袱。這樣的故事在世界各地應該是不斷的輪番上演著吧。

如果身為專案經理該如何處理這兩種截然不同的 feature？雖然我不是很有經驗的專案經理，不過我的想法是，對於 engineer feature，要有能力去判別，產品不是不能有 engineer feature，而是要思考怎麼轉化成為對客戶真正有意義的 feature。專案經理需要經常不斷的跳脫工程師的思考邏輯，以從客戶的角度來審視自己的產品。對於 PM features 則要有 Guts 去 say no 。