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

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，那才真的是叫浪費。

［PL的Project Management］Review是你的武器

Project management有一個威力強大的武器－－Review。

依project的life cycle，一般RD都會經歷requirement review、design review、code review、bug review，也會有schedule review、risk review、document review等等不同的review。Review的時間點可能是daily review、weekly review或是依事件發生點來review。而review的參與者至少有owner和reviewer，常常也會有其他相關人員或專家參與。然後review會有記錄，會有actions。

Review是一個同步大家的認知並達成共識的過程，也是一種認證和背書的行為，目的是為了藉由不同人角度儘早發現問題，降低做錯而重做的程度和次數。當然review是要付出代價的，先不論owner準備review要花的功夫，光review這個動作就會佔用owner和reviewer的時間。Review的代價是顯而易見的，大家都看得到，也感受地到，但是review的成果卻是隱性的，除非有人把成果量化並且做出比較，不然review的成果很容易被忽略。

［PL的Project Management］關於人月，你要了解的

PL要懂得將project量化，例如code size量化、bug數量化、開發人月的量化等等，量化的目的是讓你對project有較整體性的概念，進而可以較準確的預估project所需要投入的成本(如人力、時間)和產生的結果(如可完成的功能數量、schedule的milestone時間點)。儘管量化的結果不一定準確，但是不可否認地量化愈精細，所考量的因素愈多，則數據的參考價值愈高。所以PL懂得量化project時，就會對project的掌握度愈高。

［讀書樂］愛．無所畏

我喜歡看歷史小說，總會想像自己是故事主角時，會是什麼樣的反應，如果身處當時的事件中，我可能會是什麼樣的角色，又是否可能改變歷史的發展？但是歷史總是歷史，你回不了過去，不能親睹諸葛亮舌戰群儒，也無法身歷其境去感受赤壁火燒連環船的震撼場面 ，讀完歷史總是會有這樣小小地遺憾。

＜愛．無所畏＞不是在說三國的故事，只是在說一群在台東的大人小孩的故事，雖然孩子的書屋是現在進行式，可是這本書卻讓我有讀歷史的感覺，書中每個人都有故事，充滿人生的曲折，每一個篇章都像幻燈片一樣，短短的幾頁中濃縮播放了故事主角的人生重要轉折，仍然不禁會想，如果是我，又會怎樣？跟歷史不一樣的是，我沒有感覺到遺憾，因為他們還沒有結束。有幸見證了這樣的事情在發生，也有幸可以付出一點心力，更有幸可以握住陳爸的手，那雙粗獷、厚實、有力的手仍記憶在我的腦海裡。

他們不是歷史，正在發生，也持續在寫他們的故事。

［PL的Project Management］想知道Project在什麼狀態？前期問RD，後期問測試！

想知道project在什麼狀態？可以簡單的依SW process phases把project分成二個部份，
1. 前期問RD
　Requirement、Design、Implementation的主角都是RD，PL想要掌握project的schedule進度，了解project的風險，知道哪些地方是弱點，不能只看RD的report，不能只看project file的進度完成度，這些是表面的。實際的和表面的存在多少落差，要問RD才能知道。
　Report有時候是不真實的，因為不少RD都不喜歡寫report，認為浪費時間，或不知道怎麼寫，或有些就只是為了應付，不想PL/PM來煩他，可能有多報少或少報多的情形。

［PL的Project Management］Lead and Learn

Project總是讓你學到東西，不管你是新手還是老手。

對於事情，或許你有自己解決的方法，但是因為你是PL，你可能會聽到其他三種不同的解決方法，你要學習分辨出哪一種最適合（不一定是最好）。
對於人，或許你懂得排解自己的情緒問題，但是因為你是PL，困難低落時你要激勵別人，達成目標時你要鼓舞團隊士氣。人的情緒是複雜的，有時完全沒有規則可言，但是你接觸的人愈多，你經驗值就會愈高。

［PL的Project Management］一旦失焦，很容易失火

Project要有焦點，焦點是集中火力投入資源的地方。
焦點對了，project就可以個個擊破，愈來愈順手。
焦點錯了，project就陷入瞎忙困境，愈來愈沒力。
而PL是應該指出焦點的人，指錯了或不指，都是問題。

什麼才是焦點對的位置呢？

＊、焦點放在Project的目的和特性
　　PL最重要的目標就是達成project的目的，了解project的特性才能正確定位project的焦點。
　　例如對平台型的project來說，穩定性和通用性是最基本的要求。平台當然也是希望功能愈豐富愈好，有時候因為客戶的要求把個別客戶的特殊功能加入平台。在Requirement phase時很容易就不小心把一堆不同客戶的功能加進來，這時如果PL沒有考慮好這些功能之間是否具有高度通用性，有沒有衝突互斥的情況，誤以為平台的功能多就是好，失去了平台型project最基本的焦點－穩定、通用，可想見RD要花多少時間和代價才能處理好衝突互斥的問題達到穩定的要求，而且未來客戶開project時，也可能搞不清楚那些功能如何使用。
　　反過來客戶project追求的是獨特性和時效性，沒有特殊差異化的賣點，就沒有市場的亮點。即使技術仍不成熟，穩定性只有80分，為了Time to Market，也是可能要先推出的，如果PL是抱著做平台的心態，凡事都追求一百分，要求完美，很可能就失去了Time to Market的契機。
　　另外其實不管是平台或客戶project，schedule永遠都是老闆會給的壓力，如果PL以schedule為藉口而對平台型的project便宜行事，求快而不求穩，那是不可取的，因為所有不穩定的後果只是延後到客戶的project才爆發，那時的代價會比原本的schedule delay還嚴重很多的。

＊、焦點在解開未知的黑盒子
　　＜未知＞是project最大的風險，PL不需要擔心問題太多，因為至少那些問題已經曝露出來，問題的解決只是時間的問題。PL的焦點要放在解開所有＜未知＞的黑盒子，想辦法把問題都攤在陽光下。