2009年8月25日 星期二
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 。
先說專案 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 。
2009年8月2日 星期日
由醫龍看團隊管理
這是我許久以前的文章，轉 Post 於此。
我想我會不會太誇張了，看漫畫還可以想工作的事情，不過這是我看醫龍得來的心得，講講團隊管理吧：
成員各司其職
醫龍團隊裡並不是只有朝田一個人獨擔重任，團隊裡有其他人各司其職，每個人稱職扮演好自身的角色，讓團隊能力發揮到最大。
醫龍團隊有：
主刀：朝田龍一郎
第一助手：加藤晶
第二助手：伊集院登
內科醫師：藤吉圭介
麻醉科醫師：荒瀨門次
手術護士：里原美紀
這些成員在醫龍團隊裡缺一不可，它並不是全靠朝田龍一郎一人，而是整個團隊。一個好的團隊裡也應該有完整的隊員，清楚的工作分配跟職司，每個成員對自己的工作盡心盡力，為團隊達到最大利益。
第二集中，藤吉對朝田說：「隊伍裡面，應該還需要一位可以完整建立術後治療計畫的專業醫生吧？」「那就拜託啦！」
第六集中，朝田找來荒瀨也是同樣的情況，每個角色都要有人能夠稱職的扮演。
全心信任你的成員
第十集中，朝田於手術中問伊集院：「我很清楚你為巴斯塔下過多少苦工。既然你自己說不行，那我相信你。承認自己做不到一件事，也是一種責任。」這句話如果 不看前後文，可能很難了解背後的意思，但是當時的朝田是全心全意相信自己成員的判斷，沒有一絲一毫的懷疑。當然在實際面，也不是什麼事情都毫不考慮的相 信，而是在必要的時刻，你有沒有辦法相信你的成員能夠幫你完成任務，或者說你有沒有辦法信任一個成員來協助你的判斷。了解，而後信任，然後授權。「信任」 是一個團隊的出發點，是一個團隊的根基。雖然我也經常跟某人講：「相信你的成員」，但我自己也常常很問自己：真的可以百分之百做到嗎？很難，但勉勵自己去 做到。
第七集中，當荒瀨加入醫龍團隊後，朝田獨白：「好久沒有這樣了，可以讓我全心全意的動手術。」信任的極致。
每個個體對自我的信任，那就是「自信」了。伊集院回答朝田：「如果只是在加藤副教授做瓣形手術這段期間，那我有自信當第一助手 -- ！」
如何將自我對成員的信任，轉化為各個成員的自信心？這是考驗領導者的能力。
認同你的每一位成員
第九集中，朝田對鬼頭教授說：「因為我的隊伍裡，需要加藤這個人。」稍後又對加藤說：「我們這個團隊，非常需要你。」加藤心理的 OS：「我最希望的就是可以得到你的認同阿。」
跟「信任」一樣，「認同」在團隊裡有同樣的重要性，你「認同」每位成員的能力，也就是信任他的能力，每位成員也同樣全心「認同」跟「信任」其他成員的能力，更加「認同」與「信任」自己的能力，與對團隊的貢獻。把「認同」也放到你的心理，更放到你的團隊裡吧。
將團隊永遠放在第一順位
第一集中，庫雷梅斯如此說：「個人技術必須能融入團隊工作裡。那才是這裡的作法。」
朝田天才般的實力當然具有相當的魅力，但是朝田並非是只仗著自己能力並顧著炫耀的外科醫生，永遠將團隊擺在第一位，信任每位成員的判斷，那才是他讓團隊成功的不二法門。
積極培養有潛力的成員
伊集院登只是個實習第二年的年輕醫生，在大學醫院裡，他是個沒實力，沒經驗，沒權勢的小醫生，但是朝田看出他的潛力，而且更重要的是，朝田積極培養他，給他各種機會表現自己的能力，給他各種開刀學習的機會。當這些有潛力的人成長後，最後會成為團隊裡最強而有力的支柱。
加藤在第七集中說：「我們這個小隊，如果能給擔負未來的醫師帶來希望，那麼有兩個要求你得先做到。一個是，不管多困難的手術，你都要果敢的去挑戰，而且，一定要救回患者！再來，另一個。引導所有看過你動手術的醫生，讓他們邁向更高的領域 --」
加藤說出了一個領導者之於一個團隊所肩負的責任。
或許，可以由「醫龍」來出一本團隊管理聖經喔。不過我現在正處於自己是一個 team 的狀態，應該先考慮做好自我管理才對 :p
訂閱：
文章 (Atom)