跳不出框架

井底有二隻蛙。

蛙兄：看，上面的天空好大啊。
蛙弟：是啊，而且當你跳起來時，會看到更大的天空哦！
有一天下大雨，洪水氾濫，井水也滿溢了出來，二隻蛙被沖出井外。

抬起頭來。
蛙兄：天啊～天空不見了，世界末日來了！
蛙弟：是啊～怎麼會這樣，這是怎麼了！
於是二隻蛙不顧洪水，拚了命地游回井口，掙扎地想回到井底。
終於天晴了，水退了，二隻蛙好不容易再回到了井底。

蛙兄：看，上面的天空好大啊。

［面試系列］其實，我是花錢來上班的

因為上一篇＜誰面試誰？＞的情況，讓我在面試時談了很多我自己的想法，
其中有一個想法提出來時，對方都楞了一下，顯然是沒這樣想過。

是我花錢來做這個工作，不是公司給我薪資來做這個工作的。

很難理解嗎？其實不會，看圖就懂了。

［面試系列］誰面試誰呢？

圖片來源: http://www.radiobreizh.net/

最近在找人，所以安排了不少面試，但是幾次面試下來，卻有種角色錯亂的感覺－－從面試官變成了面試者。

剛開始還不會有這種感覺，但是隨著愈來愈難找到好的人來面試，愈來愈少人願意來面試，不知不覺中主客的立場已經悄悄地換了位置。在上一場面試中，我問了對方一個問題：＜你換工作的考量點是什麼？＞，回答：＜第一當然是薪資，再來就是老闆了。＞然後我說：＜那我們來互相interview吧！＞就在這個時刻，我意識到我才是來面試的。

你會選哪個?

圖片來源：http://www.theemotionmachine.com/

最近跟一位年輕人聊天，他之前在某知名科技公司當RD，有三年的工作經驗，最近在找工作，也已經拿到二個offer，算是有競爭力的。那二家公司的狀況如下：

Ａ公司：薪資較高，工作環境較好，會加班，升遷機會少。

Ｂ公司：薪資可接受，工作環境較差，但不太加班，要去的團隊是新成立的，所以有升遷機會，雖然老闆很不錯但不太穩定，中途可能換人。

問他想要去哪家公司？回答還沒決定。

問他自己想要什麼？停了一下，然後回答不知道。

［PL的Project Management］別讓自己成在最大的bug

圖片來源：http://www.uwosh.edu/deptblogs/career/files/Linkedin.jpg

PL/PM不是魔術師，project也不是黑布蓋起來的箱子，真的不需要搞神秘。

有些PL/PM以為掌握的資訊愈多又愈少人知道，就有愈能鞏固自己的權力，其實這樣的PL/PM已經成了project最大的bug，只是不自知罷了。

打仗時通信是非常重要的，通信設施是敵人優先攻擊的目標，為的就是癱瘓對方的溝通管道，讓彼此孤立不能協調，自然戰力大減容易個個擊破。做project就跟打仗一樣，PL/PM就是通信中心，就是統帥，有統帥自毀通訊的嗎？如果有，除了合理懷疑他是敵軍的臥底之外，不用說，他就是最大的bug了。

［成長系列］知道。做到。難！

很多事我們不會去做，是因為我們不知道，所以我們努力學習、追求知識，填補不知道的空白。

但是有多少事情是早就已經知道，也不是不能做，卻不去做的呢？

減肥，想過多少次了？嚐試過幾多次了？有一次成功嗎？

股市，你知道克服人性的貪婪，才能成為5%的贏家，結果呢？

多少後悔，是來自於當時明知該如此，卻不如此的？

也許當你驚覺，跟你同期的朋友已遠遠地把你拋在後頭，你才會意識到不是自己知道的太少，而是自己做到的不夠多。

［成長系統］別做一成不變的事

picture from ngonapoom.wordpress.com

一個工程師如果都在做一成不變的事，幾年之後，就會變成一個＜公務員＞工程師。

一成不變或許可視為一種專注，一件事做了五年後你也可以是專家，但如果你做的這件事的門檻不高，新人花個二年也可以達到跟你差不多的水平，你還會認為你這個專家值錢嗎？

有些公司的制度是會限制工程師發展的，把工程師當成工廠流水線上的作業員一樣來使用，一個工程師就只專注地做產品的某一部份，例如手機的camera driver，然後就負責每支手機產品的camera driver，幾年後，你會很懂camera driver，做過很多camera module，有能力處理很多camera相關的問題，但是你最多就只懂camera driver，你不會懂藍芽，也不懂Wi-Fi，而公司的運作方式也不需要你去懂其他的東西。當你對你的工作駕輕就熟，你的工作成了一個舒適區，你也不想改變，然後成了像公務員的工程師，再過幾年，年齡不知不覺成為你的障礙，你已經跨不出你的舒適區，而且已經沒有機會留給你，因為機會只留給成本更低、學習能力更好的年輕人。看起來像是公司害了你，也許是，但進這家公司是你的選擇，把工程師做成像公務員或是作業員也是你的選擇，不是嗎？最近接觸了幾個類似的個案，看清楚的人直接轉換跑道，看不清楚的可能換了一家公司，只是已經習慣了的想法如果再不改變，過幾年後是否還有換公司的本錢呢？

［PL的Project Management］什麼！版本出不來！

每到出版本build load的日子，PL/PM總是緊張兮兮，實在是因為常常狀況會很多，要不是RD來不及解不完bug，就是build load會fail，也可能版本出來了，但是一開機就當機，想罵人還不知道要罵誰，得先想辦法找出兇手才行。

其實build load時不只是PL/PM緊張，RD的壓力也很大，因為build load時間就是deadline，RD要在deadline前解完bug上code。Build load的時間一般都會安排在大半夜，因為這樣一大早VT就可以拿到新的版本好展開一整天的工作，所以常見一堆RD加班到大半夜趕著在build load前上code，也造成build load前一二個小時會有大量上code的情形。如果build load時間到了，卻還沒來得及解完bug上code，那project delay的大帽子很可能就會扣到自己頭上，頭髮又不知道要掉幾根白幾根了。前公司會每天用mail highlight bug和bug owner，build load前更是會列出MUST Fix的bug。RD通常還可以忍受每天被highlight，但是最怕的就是好不容易解完手上明天凌晨要build load的MUST Fix bug，正在開心地吃晚上便當時收到mail，發現自己突然又多了幾筆MUST Fix的bug，掙扎著是要當做沒看到，還是咬著牙吞口水認了。若在星期五，那跟女朋友的約會又要泡湯了。

［讀書樂］權謀至尊司馬懿

＜權謀至尊司馬懿＞這是本值得推薦的書，我自己是看了再看，作者對每個章節歷史事件的描述總可以讓你陷入思考，對比自己的過去經驗，彷彿歷史又重演了一遍。

有興趣了解歷史的，作者對事件的看法分析，會讓你有不同角度的視野。例如曹丕上位後發動的東征，歷史是孫權獲勝了，但是作者的看法是曹丕也嬴了，因為曹丕藉著戰爭解決內部問題掌握住權力，這才是曹丕最需要的。不同的角度切入來看，檯面上的、檯面下的，誰負誰勝出很值得玩味。

權謀是這本書的重點，權謀是為了達到目的，也是體現了人思想行為的方式。目的＋思想＝＞權謀＝＞行為，歷史事件可以看得出行為，從行為可以了解使用的謀略，但是思想需要對個人有足夠的了解才行，像諸葛亮之於周瑜、司馬懿之於孟達，然而目的在明裡的和暗裡的都是耐人尋味的。歷史就在拼拼湊湊中還原，但是現下的處境卻是要認真觀察，邏輯思考才能知道如何應對。知己知彼其實也真不是件容易的事。

看書時跟職場經驗連結也是很自然發生的事情，當時的我選Ａ是必然的，那現在呢？思想不一樣了，或是目的不一樣了，Ａ選項已經不是唯一或最好的選擇了。反省檢討，才能再成長吧。

不論你想了解歷史，看懂權謀，還是自我成長，這本書都是值得一看的。

［PL的Project Management］續談Review

延續上一篇［PL的Project Management］Review是你的武器，再從其他角度來談談review這件事。

１、是浪費還是節省？
　　Review是需要人和時間的，reviewer至少一位，是否需要多個reviewer，可以視重要程度調整，像project前期的requirement phase和design phase、key feature、跨team合作複雜度高的，就值得多投入幾個reviewer。
　　Requirement phase要的是明確的需求，沒有模糊空間，而design phase要有清楚易懂的設計，並且確實可行，還要讓介面明白與其他人溝通合作沒有問題。過去開發平台時，在requirement phase和design phase我自己小team內的人都是reviewer，5~6個reviewer也許多了，但對於平台的基礎建設我們願意這樣做，而且其實佔用reviewer的時間並不多，owner 3~5天的工作量，reviewer花1~2個小時offline review加上1個小時review meeting就可以review完了，約多花了20%左右的人天成本做review。而投入的20%成本找出來的問題，可以期待節省未來5倍以上的debug時間(上一篇我多花了5人天review，至少節省了23人天的debug)。
　　在project schedule上，一般PL/PM如果沒有review的觀念，看到RD在working item上列OOO review和XXX review等等，會很緊張，因為他看不到review所節省下來的debug時間，只看到的schedule多了20%。而通常project schedule從requirement、design到implementation是較可以精確估算的，所以PL/PM甚至老闆會誤以為project在implementation結束就可以等著準備量產了，所以會非常計較那多出來的20%，認為project因此delay了20%的時間，而忘了verification的測試階段才是真的見公婆的時間（如果公司內部的VT權力不夠大，那就只好遞延到客戶的測試才算公婆了）。有個真實的案例，該project的人天成本分布比例是(requirement+design+implementation phase) : verification phase = 1 : 3，而且在bug數比是內部project : 客戶project = 5 : 4 (以前project平均是5 : 1)。數據其實也容易取得，大部份公司對bug都是有控管記錄的，用點心檢視一下就知道了，project phase的時間點也有清楚的milestone，加上每個phase投入的人力就可以計算出人天成本了。我們先不管project management方面的問題，很明顯地該project就是忽略下圖藍色曲線代表的成本觀念，在前期requirement phase和design phase投入的成本cost是最最最便宜的，所以不在這時間多撿便宜多抓bug，那才真的是叫浪費。