軟體工程師的職稱頭銜重要嗎？

軟體工程師根據所在的環境不同，通常有不同的職稱頭銜。例如：程式設計師，工程師，技術經理，架構師，策劃工程師，平台工程師等等。對應於英文可能會有：programmer, engineer, technical manager, architect, principle engineer, platform engineer。 在大組織中，升遷可能是職稱上的轉換，例如在前面加個「資深」，大家就都知道你被升遷了。

對於轉換新的工作來說，職稱頭銜是否重要呢？

1.以工作的本質來說不重要

就技術為主的軟體工程師來說，(假設並沒有直接負責管理員工)，職稱頭銜幾乎不重要，更重要的是做事情的內容和能力的展現。

假如在一個組織裡，一位新進員工的職稱是「sr architect資深架構師」，但他的工作內容實質上是對客戶提案，撰寫業務報告。則其實他是做接近pre-sales或者sales-consultant的工作。在未來無論是組織內部還是他要對外尋找工作，通常還是評估實際做的事情為主，並非職稱。

2.以團隊角度來說可能很重要

職稱是公開的，一個團隊組織裡如果有工程師，資深工程師，資深架構師這三種不同職稱的人：一般來說，大部分的人會傾向遵循同意資深架構師的意見。特別是剛組成的團隊或者互相不認識的團隊。畢竟，職稱的功能有時候類似制服，當你在路上看到穿著警察制服的人，在需要協助的時候自然而然會傾向找穿警察制服的人幫忙。

然而，就軟體開發組織成長來說，職稱的重要性是伴隨組織成長的缺點。這個缺點和人類的認知偏誤有很大的關係：團隊貢獻中，絕大部分的人會認為自己佔比重比較大，因而，在決定升遷或者其他公開獎勵時，一定會有很大比例的人覺得自己沒被升遷是不公平的。

團隊貢獻中，大部分的人會認為自己佔比重比較大：許多實驗（參考這裡）都說明，假設一個團隊的總貢獻是100分，有10個人自己評估自己佔的比重，並且加總起來，很容易就超過150甚至250，但這實際上是不可能的。

也因為大部分的人都有這種偏誤，導致於職稱很多時候對軟體開發團隊有負面影響。如果有重新建立軟體開發團隊的機會，可以採用「無職稱」或者「自選職稱」的方式。

3. 無職稱頭銜讓團隊與夥伴的三贏

當組織沒有職稱時，無論是中期還是短期發展，組織成員會更專注於「實質工作產出」而非「表面變化」。這對組織，對團隊成員，甚至對組織外的人都有好處：

- 對組織的優勢

在組織內，成員都知道自己「做出的事情」才是決定自己的「職稱頭銜」，而非「職稱頭銜」決定自己「做出的事情」。自然而言，團隊成員就會以提高自己的能力和對組織的影響力，並且使用的方式不會是以頭銜和權威。升遷和加薪兩者同時都變成機密，再也不會影響其他人的心情。

當組織要招募人才時，組織會更專注於了解應徵者「過去做的事情」，而不是過去有的頭銜職稱。過去我們面試的時候，常常在履歷表中看到非常驚人的頭銜，但是實際上做的事情可能非常基本。

無職稱會讓面試的效率提高，錯誤率降低很多。

- 對團隊成員的優勢

當團隊成員想要換工作時，在他對外面試的時候，很容易就專注於展現自己的產出。而非說明自己的頭銜。

同上一小節之說明，團隊成員專注於工作的本身而非頭銜的表面公平性不足時，更能發揮自己的潛力和提高產出。

- 對組織外部的優勢

其他外部組織在遇到沒有職稱的人前來面試時，更容易專注於尋找人才得要件。換言之，本來評估能力和是不是適合，本就不應該和職稱有關。已經有人自己不帶著職稱頭銜前來面試，就更容易避免錯誤。

企業巫醫：手寫的工作筆記，讓你跨越困難

筆記本加上一支筆，大概是最便宜，最容易改善工作的工具。

網路上有非常多「如何做筆記」的相關文章，特別是如何做學習筆記(例如這裡,這裡,這裡)。在職場上，特別是知識工作者，幾乎都有做記錄的必要，然而由於資訊工具的改良，許多人會改用手機，平板，電腦來做筆記。畢竟數位化還是資訊快速膨脹的主流。

在此並非建議走回頭路。數位化記錄，絕對是必要而且有幫助。企業裡面的知識庫，wiki以及追蹤工作工具(jira, redmine, trello等等)，絕對是讓組織整體提高做事的透明度，持續傳遞經驗知識的最好方式。

然而，對於個人職涯發展而言，還是建議要透過工作筆記，來提升職涯發展，增加自己的能力與視野的人，最好還是擁有一套自己手寫記錄的方式。

原因如下：

(1) 手寫的學習效果遠遠超過打字

有太多太多研究顯示，手寫的理解與記憶效果，遠遠超過打字。請參考：這篇，這篇，這篇，這篇。或許有人會說，工作筆記又不是學校筆記，但如果深究這些研究會發現，其實概念相當一致，也就說，手寫某件事情，會增強對這件事情的「理解力」，「創造力」與「想像力」，然而打字卻不會！而廣泛知識類型的工作也是，職場上對事情的理解和掌握越高，越有想像空間，當然工作本身做得越好。

(2) 成本低

當然，現在平板也可以手寫，所以廣義地說，如果習慣的話，平板也是可以。然而，再貴的筆記本，其運用成本，仍然比平板低。除了價格之外，運用成本包含環境限制（例如要充電）。

(3) 手寫讓思考聚焦

無論是用哪種輸入法，即便是最簡單的注音，只要一段時間，每個人的打字數度都會遠超過手寫速度。然而，正因為如此，手寫可以讓頭腦有思考聚焦的功能。腦中會自己思索，應該聚焦的關鍵，進而思考關鍵的意義，這對掌握工作的要點，並且讓一個人在繁忙工作中，找出一條正確的道路有絕大的幫助。請參考這篇。


那麼，要如何做工作筆記？

(1) 立刻買一本

假設你沒有筆記本，也沒有做工作筆記的習慣，那麼就「現在馬上去買一本」。習慣的建立是需要時間。不建議去買很貴的Moleskine筆記本，即使是代購團購的Moleskine也是頗貴。當然它的質感，可長期保存，書寫良好，硬殼和收納設計都首屈一指。不過其實隨便到文具店買不到一百元的即可。

(2) 上班中隨身攜帶，隨時紀錄

聽起來簡單，但要養成比帶手機更隨身的攜帶是有點難。無論是開會，還是座位自己位子上，確保重要的事情，都應該即時簡單的紀錄。筆記本應該是隨著時間紀錄。而且，並不限制記錄內容。如果是開會，建議使用心智圖的方式記錄。
提醒一下，筆記本並不僅止手寫手畫，也可以將重要的檔案email，直接列印貼在筆記本上。未來當重新檢視工作時，有莫大的幫助。

紀錄的內容以「事實」為優先，同時當然要記錄時間。工作記錄並非你自己的日記。雖然，這是自己私人的紀錄，但最好不要紀錄感想或情緒；而是確切記錄事實，因果，困難，解決方案，效果等等。

除了記錄之外，筆記可涵蓋「簡單計畫」，也就是「本來打算如何做」。例如，在工作中發現你對某技術不了解，於是你就在筆記本中草草紀錄一行「學習某技術」。隨即在這行字下面，就可以做得簡單的計畫，例如：1. 10分鐘上網查詢。 2.問一下某某同事。 3.在本週末練習此技術。

當你有任何打算做的事情，拆解成為執行的行動，簡單紀錄，日後就很快可以檢查這些行動是否完成，或者計畫是否要改變。

要注意！工作筆記是幫助你「動起來」的最好方式！

(3) 每月摘要，自我檢討

工作筆記，最最最重要的功能就是，每個月找個20分鐘的時間，將過去一個月自己做的筆記認真看過。然而透過紀錄，回答自己以下問題：(a) 這個月我有做幫助公司組織哪些重要事情 (b) 這些事情做完了沒 (c)隨便換個人也能做這些事嗎？ (d) 過去一個月我有沒有學到新事物(e) 有沒有遺漏重要的事情還沒進行。將這些問題，自我回答到筆記本中。
這種檢討方式，特別適合在坐捷運的時候進行。


筆記本加上一支筆，大概是最便宜，最容易改善工作的工具。如果你認為自己的職涯發展受到侷限，或者遇到困難，而你又沒有做筆記的習慣的話，那麼其實不妨一試，只要長期累積必有成效。

企業巫醫：電商發展史代表人物貝佐斯(書摘)

中文譯名貝佐斯傳，第一次出版於2014年，在此前2年2012正是AWS成長最快速的驚人階段。許多台灣的軟體工程師認識亞馬遜(amazon)並非從零售業開始，而是從雲端服務開始。然而要瞭解自1995開始的網路電商發展，就不能不認識亞馬遜這家公司，而要認識亞馬遜(amazon)就不能不了解貝佐斯此人。因此，原書名The Everything Store(直譯為什麼都賣的商店)翻譯成貝佐斯傳，還頗為適切。

作者是商業週刊的記者(Brad Stone)，但此書很明顯的並非歌功頌德的講述一個厲害的人的生平。書裡穿插了貝佐斯Bezos的生平，和亞馬遜本身的起伏歷史。作者認真的考究當時發生的事情，留給讀者事實，但也不會一昧的鄉愿，冷冰冰的陳述數字，作者也會事實比較，不帶太多評論的給讀者參考。

Amazon發展歷史：亞馬遜成立於1994年，但是網站正式上線於1995年7月16日。並在1997年五月正式成為股票上市公司，當時股價18美金，在這快速成長階段，貝佐斯從各產業挖來各種空降人才，特殊的高選人標準蔚為趣談。1999年到2001年之間的網路泡沫化確實讓亞馬遜受到挫折，裁員與關掉物流中心都在此階段發生。然而，熬過第一次網路泡沫之後，亞馬訓似乎已經知道如何在複雜龐大的電商世界成長，透過併購可能的競爭對手(並購清單請參考這裡)，堅持「最低價策略」，研發Kindle電子書，讓亞馬遜在2008年金融危機時幾乎不受太大影響。2011年員工人數達到3萬人，然而2016年底已經成長到56萬人！

亞馬遜的經營策略是堅持給顧客最低價，換言之，犧牲供應商的利潤，打破任何約定成俗的現狀，是一直以來為人詬病之處。在書中講述很多和供應商衝突的例子很值得讀者細細參考。不過，在此更想探討的是其選人用人與組織管理的

特殊的人才選取與工作價值：

無論是前員工還是現在的員工，都會認為貝佐斯本人，幾乎代表了整個亞馬遜的意志，曾經在1999年找另一位執行長，然而隔年七月就離職，除那段時間之外，這24年來貝佐斯本人就等於是亞馬遜。

而他的做事風格極度鮮明，最著名的例子是，他認為「亞馬遜的員工必須要努力工作，聰明工作，長時間工作，而且不能三個只挑兩個」(You can work long, hard, or smart, but at Amazon, you can't choose two out of three) 這看似不合理的宣稱其實是在1997年才開始，在此之前，早期員工記得他說可以三選二。

他要的都是即時高手，而不要近來學習的人。然而，他選擇的人才，卻又通常不單只是該領域的人，而是他認為有突破性想法與實踐性的人！

此外，「勤儉」也是亞馬遜強調的守則。相較於矽谷其他公司，總部位於西雅圖的亞馬遜員工福利相對少很多。對員工錙銖必較的例子很多，例如：到職的時候發給一個背包，一台筆電，一些資料，然而離職的時候這些統統都要繳回，連同那個背包！

在2014年之前，溫良恭儉讓不存在於貝佐斯心裏，透過酸溜溜的語言咒罵員工是常有的事情。經典語錄有「你這個人到底是懶惰還是無能」「你為什麼要破壞我的人生」「對不起我今天沒吃傻瓜藥丸」「你自己講出這種話，自己不會驚訝嗎」等等。然而絕大部分的員工，無論離職於否，也無論喜不喜歡貝佐斯，都同意一件事：那就是貝佐斯的確很聰明。並且在2014年之後，由於企業變大，這類型不尊重人的對話也減少。

對於重要職位的僱用，貝佐斯會特別設立一個角色參與面試「bar raiser」直接中文翻譯是：提高標準者，基本上這個角色是用來提高進入標準。換言之，希望所有參與面試的面試官，都應該找應徵者是「比自己好的人」。但這個bar raiser本人是經過挑選，並不是每個人都可以擔任，而每個重要的職位，都需要有一個bar raiser參與。此人並非應徵者的主管，也可能不整個甄選過程出任何意見，但卻可以說對任何應徵者說「不」。很明想的是希望企業人才越來越好，而非越來越平庸？

然而，這樣的選人標準卻和福利相違背，在過去，普遍認為貝佐斯是所謂「傳福音」的角色，信他者就會加入，並且做牛做馬，不信者最好遠離這個環境。當然最近數年由於亞馬遜膨脹很快，這樣的標準不見得能在持續下去。

這本書的啟示？

購買在此。從有網際網路以來，貝佐斯幾乎是網路零售發展的最佳討論對象。他確實有遠見，也願意打破既有框架。然而，他也和越王勾踐一樣，可以共患難，難以共享福。不見得每個人才都適合這樣的環境，不過，不浪費時間的投入，根據事實來做判斷，不讓自己做限制的精神，才是這本書為何值得一讀的原因。

企業巫醫：就業大環境不好的問題該如何解決？

曾有一次面試某碩士畢業社會新鮮人，他說：「許多企業找碩士實習生，都是讓他做高中生能做的事情」。

然後詢問說那麼為什麼大學或碩士在學的學生，願意去做這種高中生會做的事情的。畢竟，在台灣決定選擇實習也是學生的選擇，並非被強迫的。他的回答是：「大環境的問題，市場情況，不能怪學生，他們很多都涉世未深，不知道這些工作沒學習成長。既然是實習，企業就應該有"習"的部分。現在大環境是這樣，並不代表這樣是對的。」

接下來又再請教他，如果你是企業主，這些實習生比較無趣的工作，如果不找碩士實習生，應該找誰來做，他回答是：「可以找私立大學的學生」

其實觀念無所謂對錯，對於這位新鮮人的想法，每個人大概都有不同的解釋。然而有件事情倒是很重要，當環境不好的時候？應該要什麼方式解決？

(1) 個人永遠都有選擇

相較於生在阿富汗，敘利亞，烏干達之類的戰亂地區，大部分的台灣人都有選擇。特別是如果你上網看到這篇文章，就表示你能上網，同時也就表示你可以取得的資訊知識範圍遠比任何30年前的人多幾億倍。

當然，選擇多寡因人而異，但是當你心裡想著：「好像只能這樣」或者是「我這樣的背景就很找到更好的」或者是「不知道該怎麼辦」的時候，也許應該更廣泛的思考有哪些選擇。

有經濟壓力（貸款，家人等等）的時候選擇是比較少。大概不可能離開一個自己很不開心的工作，畢竟還是需要收入。但你仍然可以選擇「自我學習」。

為什麼要「學習」？很簡單就是因為要增加選項

(2) 如何增加自己的選項

不可否認的是，祖上積德的人，一出生選項就比較多。然而，選項少的人也不應該因此唉聲嘆氣。與其花時間抱怨大環境，不如花時間增加自己的選項。

最簡單，而且最沒有成本的是：到公立的圖書館借書，透過閱讀來增加知識。擺脫經濟壓力的最重要的關鍵，而且增加選項的關鍵應該是自己的知識和技能。

不過，學習知識技能也有不同的方式。有些學習時間長，有些較短。舉例來說，如果你突然之間想變成醫生，那麼至少也得花上7年，而且重讀醫學院幾乎是唯一可能。但如果你想成為一個手機遊戲專案經理，卻是有可能從零開始：先主動自願參與手機遊戲測試，再主動閱讀和QA有關的書籍，並開始投遞遊戲測試工作，例如這裡。透過變成遊戲產業的一份子，逐漸增加自己的知識能力...這樣確實是可讓沒有相關技術背景的人，進入遊戲開發的世界。

其他自我學習的議題可以參考這裡。

(3) 不要自我設限的方式

許多人會自我設限，而自己限制自己，是無法面對大環境的其中最最最大的原因。
自我設限的情況例如：

「這個是某部門的人負責的，所以我就不想碰」
「我英文不好啊，所以就不考慮外商的工作」
「家裡有固定開銷，所以沒辦法亂換工作」
「我本來就不會讀書，不喜歡讀書，看到書就想睡覺」
「不知道怎麼開始」
「我就只能先這樣，不然也不能怎樣...」

這些即便都是事實，也對自己沒啥幫助。

然而，想要突破自我設限，最根本的方式是從累積「短期，有成效的事情」開始。例如，英文不好，就買本哈利波特1的英文版，每天花15分鐘讀一頁。累積習慣之後，再開始增強聽力。重點在於「每天只有15分鐘」，一次投入太多，非常容易放棄。

其次，找同伴一起。這就像是慢跑或健身活動，總是一群人比較有效果。人類畢竟是群居動物，在群體中容易自我約束自我成長。

最後，尋求資深的人意見。這也是為什麼網路上，常常有匿名發問，查詢資訊的原因啊。

企業巫醫：20分鐘搞定「工作做不完」的問題？

上班族常會遇到的老問題是：「工作做不完怎麼辦」

工作做不完是個老問題，解決問題的方法也很簡單，然而簡單事情不見得容易做。更重要的事情是：你需要正確的檢視現況，才能真正解決問題。因為每個人的「工作做不完」的實際情況都不同。舉例來說，假設你是在無良的黑心老闆血汗工廠，那麼你的工作做不完的解決方式應該是儘早辭職，而非增加效率。

以下步驟確保可以幫助你解決這個問題：

步驟一：暫停！休息5分鐘！ 利用15分鐘進行計畫

1. 休息5分鐘

除非你的工作是急診室或者核電廠這類人命關天的地方，一般的上班族，一旦遇到工作做不完，慌慌亂亂急急忙忙的時候，其實第一件事情應該先放空自己。找個安靜的地方(萬一真找不到可以藉故離開辦公室幾分鐘)，先盡量將自己的思緒清空，沒辦法放空冥想的話，打個手遊也可以。當你的思緒紊亂，壓力暴增，往往會使用直覺處理事情，使用直覺處理並沒有錯，但如果「只靠」直覺處理，就會失去成長和學習的機會，更糟的是，直覺處理事情通常和情緒結合在一起，關於這點請參考腦的結構，杏仁核。

所以讓自己休息五分鐘！

2. 計畫15分鐘

休息之後，拿出紙筆，先對現況做計畫。
列出事情的四個象限：重要/緊急矩陣(參考這裡) 。
如果你已經熟知這個事物分類方式，那就可以直接挑過這段，並思考自己為什麼不做這件事？

 2.1 重要且緊急：

 就是要專注處理的部份

 2.2 不重要但是緊急：

 要犧牲，或者交給別人，或者是忙碌狀況。但通常這種事情都是工作做不完的主要來源。最好的方式是縮小事情的影響。常見不重要但緊急的事情，不外乎老闆索取各種資料，感覺很急，

 2.3 不重要且不緊急：
  千萬不要去做它！普通上班族通常不小心會落入去做不重要且不緊急的事情，而且還不自知。最常遇到的事情是：對小事情花時間做無謂的討論。

 2.4 重要但是不緊急：

  千萬不要忽略他！忽略這裡，就無法徹底解決工作做不完的問題！

步驟二：按照計劃：逐一解決重要緊急的事

在計畫中，條列的重要與緊急的事情，要「逐一」處理。先不要想要同時處理，做個清單，搞定一個事情打個勾。

這聽起來簡單做起來很難。

有幾個簡單的執行要點可供參考：

(a) 自己找到專注工作的場地。很多工作其實不限定工作場合，只要你事先跟老闆講好，其實是可以嘗試找不會被打擾的地方好好專心把事情搞定。例如，在主管同意之下，中午三小時在公司附近某咖啡廳寫程式。在近年來開放式空間流行的狀況下，這點相對重要！

(b) 不要隨時檢查email與短訊。除非你的工作是急診室醫生或者某些人命關天的意外處理者，否則不應該時時檢查聯絡工具，你應該是控制工具的人，而非被工具控制的人

(c) 設定解決的定義。緊急而重要的事情的「回應」不代表解決。解決事情要像是恐怖片裡的殭屍，當你沒有徹底將它打爆頭，它很有可能會再爬起來咬你一口。

步驟三：重新檢討計畫，找到提高效率的方式，專注於重要但不緊急的事情規劃和執行

為什麼要專注於重要但不緊急的事？因為重要的事情如果都先處理好，可以大幅改善「未來還會有工作做不完的問題」 而且同時減少重要且緊急的事情發生。畢竟很多重要緊急的事情，就是當初重要但不緊急的事情一路拖延導致後來變緊急。

因此，這步驟用以確保可以有計劃地執行「重要但不緊急」

有幾個方式可以確保自己不遺漏「重要但不緊急」的事情

(a) 隨時檢查中期目標：組織通常有偉大的長期目標(例如登陸火星)，但也由於通常太偉大，所以必須要逐步以中期目標達成。個人應該將中期(3~18個月)目標當作為重要的事情，而非最近短期目標。因為，短期事物常常會被迫打斷修改，就會容易淪落於被時間追趕而非控制時間。

(b) 每天排定固定時間處理「重要但不緊急」 即便是1小時，長期下來也會有效果。萬一不得已要加班，應該要加班處理的並非緊急的事，而是重要的事！

(c) 其他 (有空再說明此處)

步驟四：按照計劃，完成重要的事 ，並執行提高效率的方式

倘若已經執行到此。就可以考慮提高效率的方式。
其中最重要的方式就是「提高本身知識與能力」

提高工作效率有很多種方式，請參考這裡，或者這裡。

步驟五：檢討成效，修改計畫

每個計畫都應該確實被檢討，自我檢討當然很好，不過，秘訣是請你認為做得比你更好的人幫你檢討計畫。

倘若這篇文章有某件100%保證有用的方式，那麼「請一個你認為比你厲害的人幫你檢討你的計畫和成效」是最最有用的一點。

建立高度自我激勵之軟體開發團隊的三個方向 (軟體主管的31堂課)

1999年美國的籃球夢幻隊1992 dream team 是所有籌組團隊的人遙不可及的夢想。他們除了籃球技術精湛，經驗豐富之外，更重要的團隊都有拿到奧運金牌的唯一目標，此一目標會讓他們自我激勵，根本不需要額外的刺激。這樣的團隊組成似乎可遇而不可求，在軟體開發的世界幾乎鮮少看到例子。

無論如何，建立能高度自我激勵的團隊，是主管最重要的工作之一。如果你是團隊主管，你必須認識到這是你最重要的任務。

自我激勵會造成工程師的職涯成長，而看得到自己的職涯成長，是能驅動效率的最好的因素(註1)。

軟體開發工作，通常是需要高度的心智活動以及集中的創造力。要造就高強度心智活動，幾乎很難單純由「薪水」或者「物質獎勵」來滿足工程師。加薪獎勵與升遷固然非常重要，但它能維持的效果頂多3-6週，之後所有的工程師都會認為這樣的加薪獎勵與升遷是「理所當然」，並且很快地將獎勵拋諸腦後。這不是說工程師都不懂惜福，而是研發工作本來就很大部分的來源會來自成就的滿足感，而成就的滿足感幾乎是加薪升遷無法長期提供的(參考 1)(註2)。非營利事業有可能天生就存在這樣的激勵因素，例如，慈善組織試圖拯救世界的所有窮困兒童，研究組織試圖大幅延長人類生命到200年...然而這些組織一般都有極為獨特的目標以及具有個人魅力的領導者。

一般的營利組織以及軟體開發團隊如何建立一個能自我激勵的團隊呢？

有三個方向：(1)選對人 (2)找交集 (3)自我導航

(1) 選對人

在選用人才時，就先確定此候選人是正面思考，能自我激勵，自我成長。因為要維護一個人的正確態度，比要矯正一個人錯誤態度來得容易太多。

換言之，選擇已經能夠自我激勵，並且確定此候選人在他過去工作經驗中，已經有自我激勵的事實。

不要選擇個人技術能力很好，但卻在自我激勵上面有非常負面的紀錄。因為，要培養技術能力並不難，但要改變人類的思考模式實在難上加難。現存的coach教練式領導，不過也就只是希望透過引導，造成行為上的調整(參考富比世, 英文版？)，要引導到行為心態的調整，教練(coach)幾乎必須要和學員長期合作才有辦法做到。

選擇的重點在於透過過去的實質發生的紀錄，而不是透過詢問未來的問題。這個做法在選人時非常重要，選擇能高度自我激勵的人才，此人必須在過去工作時，已經展現高度自我激勵的情況。例如，你可以詢問面試者：「請問你最近工作上遇到最艱難的狀況，或者壓力最大的狀況，當時你是怎麼處理的」。這個問題重點在於"最艱難"以及"當時怎麼處理"。有時候面試者可能說沒遇過太艱難的情況，那麼也可以詢問"普通難"或者"壓力普通大"的情況。一個工作超過3年以上的人，當然可能運氣超級好，從來沒遇過艱難狀況，然而絕大部分的人，都可以說出幾個艱難狀態。這時候，不需要太早評斷，也不用加入討論，而是要徹底瞭解，在這個狀態下，面試者通常會表達過去的事情和想法，暫且將其想法放在一邊，妥善記錄事實。最後再由事實來判斷。

舉例以下的對話為例：

主管：「請問你過去遇到工作壓力最大的時候，當時是怎麼處理的？」

面試者：「之前在HXC工作時常常加班到很晚，要趕專案當然覺得壓力很大。怎麼處理喔？就想說當練功啊，學到東西我就要離開了」

主管：「當時你如何判斷已經學到東西然後可以離開了」

面試者：「呃？...就那時候我負責的app都推出去了」

此例的事實是。面試者因環境工作時程長壓力大，處理的方式是轉換心態-當練功，並且設定好離開環境的方式。請記得在此並不判斷好壞，而僅是記錄而已。然而，設定好離開環境的方式並不是以學到東西為主，而是做完東西。光是這樣可能還不足盼對此人是能積極自我學習還是消極無法激勵，需要更多挖掘過去的行為的討論才會確定。

(2) 找交集

我們不可能知道別人腦袋在想什麼，每個人都有所謂 left-hand-column，即便已經選擇最能高度自我激勵，自我成長的人才進入團隊，而且他們也都是非常坦誠並努力工作的人。但我們要知道每個人都有不能說，不想說，或者不適合說的事情。 
有些領導者會試圖找出這些事情，但其實有沒有找到不重要，重要的是「重視left-hand-column的存在」。

一個好的領導者，會找出交集。確保雖然人人有不同想法，但整合個人，團隊以及組織的交集，大家可以獲得三贏狀態(win-win-win)往同一個大目標前進！

當然，一個能力好而且能自我激勵的成員，可以自己找到此交集。不過身為領導者或主管，應該要時時注意：每人對這個交集其實都不太一樣。但好的團隊的每個人，應該都有部分交集。

最底線是：一定要避免三輸的局面。聽起好像很荒謬，但軟體開發的世界偶爾常聽到雙輸或者三輸的狀況。不必要的長期加班，幾乎都會造成雙輸或者三輸。長期加班必然會造成人才的耗損，幾乎也不能避免地造成團隊無法緊密成長，所以起碼就是雙輸，最後也常常造成組織本身無法長期經營，那就變成三輸了。

要建立能自我激勵的團隊，找到每個人不同的交集點。如果真找不到，則很有可能該人才並不適合這個組織，如果一半以上的團隊成員你都找不到目標的交集點，或許你本人並不適合當領導者。

交集點的例子很多，某些有資深能力好的工程師，除了團隊環境之外，或許可兼顧家庭是職涯的重要考量。因此，彈性的工作時間，和受到控制的可在家工作，就會是這類資深工程師(註3)的「left-hand-column」而這可能是最容易取得交集的地方。做法很簡單，就是讓資深工程師自行定義產出和目標，

(3) 自我導航

自我導航(Autopilot)是指團隊成員知道自己為什麼要做，知道該做什麼，知道怎麼做，知道什麼時候做。而更有甚者，他知道自己什麼還不會，所以需要特別努力學什麼。

一個能自我導航的工程師鐵定是資深的工程師，他會自我衡量自己在團隊中的「交集」也會自己「選擇」適合成長的環境。換言之，根本不需要煩惱這樣的成員。

對與已經是自動導航的工程師，僅僅只需要「教練式引導」(coaching) 。領導者或主管，應該必須對coaching有一定程度的了解，如果還不了解，現在就是學習的好時候。

在此最底線是千萬不要micromanagement -  也就是枝微末節都要管。大部分的資訊工作都是高度腦力工作，枝微末節都要管意味兩種可能
(1) 團隊成員根本無力勝任這樣高度腦力工作，而你組出這樣的團隊表示你也不適合作為建構團隊的人
(2) 團隊成員可以勝任高度腦力工作，但你身為管理者想要插手，表示你並不了解高度腦力工作的統御管理方式，所以你大概也不適合作為建構團隊的人。

要怎麼樣知道領導者管理者是不是「微觀管理」？只要看他實際做的事情就知道，當時「實際要做的事情」超出「本身的意義」就是這類型。

舉例來說，上班有規範時間，並非微觀管理，沒有規範在大部分得時候反而浪費大家的時間。然而，毫無彈性的硬性規定人必須出現在辦公室的時間，其實就超過規定上班時間的意義。對軟體開發團隊來說，上班時間規範是為了讓團隊容易一起面對面討論，互相砥礪解決問題。例如組織定義9:30~18:30是工作時間，然而，因個人因素不在範圍之內，例如想要8:30~17:30只要該成員能確保他的scrum團隊夥伴都知道他和大家時間略有不同即可，成熟的團隊的紀律來自「自我認知和團隊合作」，並不需要管理枝微末節。同樣的，「規定現在要加班」也是某種程度的管理枝微末節，順便強調一下加班其實是解決問題最爛的方式，尤其是被規定加班。

抱歉 沒有什麼神奇的快速方式！

組織理論其實並沒有捷徑，也沒有什麼神奇的快速絕招。然而只要方向正確，忍耐個幾個月都會看到成效，但是簡單的路總是難行。當然，特定快速的環境 - 例如非常新的新創產業，還不確定能否獲利 - 似乎不值得這樣長期投資？也有不少人主張時間不等人？然而，對大部分的資訊產業來說，大部分的情況是跑馬拉松而非短跑。

技能與績效的考量:

在這裡省略一件很重要的事情！
我們並沒有討論技術能力和工作績效，但其實在軟體開發團隊中個人技術能力與個人工作績效是非常非常重要的！沒有好的能力與產出，要怎麼激勵自己恐怕都沒太大用處。然而，績效和能力應該比較容易在面試與履歷表中檢核出。因此才不在這裡討論。

---

註1:  要使團隊有高效率，自我激勵是最好的方式 。然而其他方式也存在，例如鞭子與蘿蔔。
註2:  但是如果薪水實在太少，不能滿足基本需求，就不在此討論範圍之內。
註3: 不過要特別注意，資深和年紀沒有絕對關係。必須要是做事態度資深，而非年紀資深。

企業巫醫：創業初沒準備好 就先別找工程師（讀書心得）

Don't hire a software developer until you read this book是一本有趣的書，它的副標題是：學習如何管理應用程式的開發流程，確保你的手機程式，網站，網路應用的產品會成功做出來。

這本書和一般的企業巫醫做法略有不同，它只專注在一個單純面向，就是「非軟體人員如何建構軟體開發團隊，並且做出自己要的產品」。實務上，它是一本工具書。裡面的Pro Tips直接而且不廢話的指出應該要的做法。

這本書花了好幾個章節，大致闡述了近年來軟體開發的相關技術與運用，並把重點放在非技術背景的創業者，如何組織建立軟體開發團隊，並且讓團隊往期待的方向前進。

做得到書上的內容的人，大概就是程式設計師心中的好老闆，或者是好ＰＭ。

然而，這本書其實也非常適合給「程式設計師」閱讀

它展示非技術人員領導軟體產品開發「真正關心」的地方：也就是實際產出。至於開發人員使用的程式語言，使用的軟體工具，甚至想要把產品做的完美...這些都是不是考慮的要務。

例如，在書中說明新創產品開發常犯錯誤的幾條

(1) 為求完美把錢燒光了：

MVP需要的是最小規模的產品以及最好的品質。但太追求完美因而增加太多附屬功能，在作者來說是一種無法控制的浪費

(2) 輕忽看似很小的需求規格改變

例如某些開發人員會說「這不會花太長時間，只是把按鈕從這邊移到那邊」。開發人員當然會負責搞定，但是要求預估時間是創業家一定要做的事情

(3) 忽略測試

測試的重要性應該不用多提。然而非技術人員很容易忽略測試的重要。

(4) 即將上線前做需求改變

對作者來說，這等同於自殺任務。其實資深的軟體工程師在內心深處都很清楚這點，但是創業者或PM想要自我毀滅的時候，又有多少人可以阻止？

(5) 開發中後期增加人力以加速開發

在人月神話這本書中有很長的篇幅描述，很多時候增加程式設計師只會讓專案速度更慢。



此外，一般開發人員也可以透過這本書獲得Lean-Startup的精神概念與實務上Agile開發的整合。
舉例來說：它說明了Agile原則，以創業者的角度，來看agile的各種方法論對軟體開發的好處。並且也拿實際工具(Trello)，展示一個創業者實際對開發團隊該做的動作，連同移動Task Card都說明很清楚。MVP，如何做出最小可行規模的產品。從創業者的角度，來看這些工具，其實更可以讓軟體工程師知道專注於最小變動需求的好處。

Scrum: 三件不能少的事

Scrum是敏捷開發原則下，目前在軟體產業裡常見的方法論。而由於Scrum只是個方法論，並沒有所謂的標準，各個組織的應用方式皆有不同。常見的應用(practice)，例如：spint-kick-off-meeting, daily standup, burn down chart, planning poker, retrospective。

零零總總的practice中，哪些最為重要當然眾說紛紜。考慮到Scrum的真正精神，以下三件事情是「最基本要有的」。也就說，如果這三件事情做不到，那麼其他事情做到也沒有用。

(1) 每個Sprint有交付具體產出

Scrum的Sprint都要有具體「可交付」的產出。sprint的開始，就應該以「結果」為計畫的導向，而此結果必須要是可交付的產出。

有些團隊會以Sprint長度不夠為理由，設定一個「並不能交付」的milestone作為該sprint的產出。如此一來會有幾個問題：(1) sprint結束的檢討，並不基於產出的事實 (2) kick-off下一個sprint的意義不大，因為前一個sprint並沒有真正可在市場衡量的產出 (3) PO會有充足的理由不參加demo以及下一個sprint的kick-off，畢竟這個sprint沒有有意義的產出，而如此一來PO就很容易不真正加入團隊。

Sprint不見得要固定長度，請參考這裡。 

(2) PO有確實加入Scrum團隊

Scrum團隊成員有三個角色，team member, scrum master, product owner。其中最容易不在的人，就是product owner。許多軟體開發團隊，product owner就是PM。但無論如何，Product owner必須要真實參與團隊。

所謂真實，指的是所有standup應該參加，在團隊運作過程，能夠回答該sprint的需求問題，並確實知道sprint中間「不應該做的事情」以及sprint開頭結尾「應該做的事情」

更重要的是PO加入團隊之後，DOD(definition of done)的標準才會具有「市場一致性」。舉例來說，不成熟的軟體研發人員常會對事情做完有不同的定義：
「程式寫完只是還沒review，所以還沒merge」
「程式寫完測試也沒問題，只是QA還沒通過」
「功能搞定了，QA也沒問題，只是還沒...」

PO確實加入後，可以讓事情做完的定義，統一在於「可準備交付到市場」。換言之，所有和程式設計相關的工作：測試，相關文件，環境設定，certificate等等都會以「可準備交付到市場」為原則。沒有這個原則，跑Scrum很難達到預計效果，要達到這個原則，最基本的就是PO需要確實投入團隊。

(3) 每個Sprint結束之後有確實地檢討(Retrospective meeting)

這世界上沒有完美的團隊，也沒有不用修正的軟體開發方法論。每個sprint的確實檢討，是修正團隊，讓團隊趨於一致的唯一方式，而非強加訴諸任何規矩。請參考這裡

確實的檢討並不容易，要做到兩件事情：
(a) 基於事實檢討   
(b) 不檢討不在場的人事物 

基於事實的檢討

檢討的內容必須基於事實，不是基於感覺與想像。感覺和想像的情況如下：
「我感覺好像有點慢」
「不知道怎麼講耶 但這個事情不應該這樣做」

事實的情況舉例如下：
「這個sprint我們沒有按照當時說好的DOD的定義，所以有XX與XX項目，本來說完成了，後來隔幾天又說沒完成」

不檢討不在場的人事物 

檢討確實是對事不對人，然而，事情都是人做的，不可能不檢討「人的做法」。不檢討「人的做法」只是鄉愿。

不過，要避免檢討不在場的人。
例如「因為UI/UX之前給的東西不正確，導致我們要重做某些事情」如果UI/UX是同一個scrum團隊，那麼檢討此項目當然可以。但要是不是同團隊就沒有意義。
因為，Scrum的檢討會議目的是產生「團隊要改善的項目」，而不是去讓非團隊的人改善。

Scrum的學習必然是從實際的經驗獲得，但經驗的獲得又必須從知識學習的取得為基礎，要成為看似不錯的Scrum專家不難，但要實際應用於專案中，並取得可重複成功的結果就不這麼容易了。

企業巫醫：應該要在同一間公司待多久？

一個在就業市場工作的人，到底應該在一間公司待多久才算「正常」。就產業的不同，自然有截然不同的答案。就資訊科技領域來說，過於頻繁地更換工作，會讓求職者更難找到好工作。

何謂頻繁更換？當在現有工作遇到瓶頸，自己有機會透過自身能力改善瓶頸，然而卻選擇離開就算頻繁。

真要講個數字的話：
* 工作7年以上，在最後7年的職業生涯中，但不在任何組織中待超過2.5年，就會被列入低優先考量 - 並非完全不考慮，而只是不優先聯絡。
* 工作3-7年，但不在任何組織待超過1.5年，也是屬於低優先考量。
* 工作3年之內，其實到不用太在意。

理由是 考量「大部分的情況」，而非考慮「極端情況」。

大部分的情況是：

工作7年以上，但最後的七年，沒有在任何組織待超過2.5年，表示曾經換過起碼4~5個工作。然而資深的工程師，通常其工作內容是比較困難的，並應該能展現其架構設計與實作的經驗。可是，如果其架構設計，並沒有被「市場驗證」那就很難用各種方式評斷他的真實能力。講得更直白的是：也許這位資訊工程師，雖然有Ｎ年工作經驗，但搞不好每次都挖洞給別人跳，自己拍拍屁股就走了。或者是，也許他工作能力其實普通，但「自我感覺太好」因此老是覺得自己應該找到更好的工作。而更重要的事實是，他的確離開了，這事實也表示這4~5個工作並沒有「留才」的意願。兩年半是最低限度檢驗一個工程師，在技術上能取得「市場驗證」的時間，兩年半表示工程師至少經過兩次以上的績效考核，並且其工作的正面負面評價也容易以事實檢驗。

極端情況是：這位資深工程師運氣太差，雖然各方面能力都好，但就是遇人不淑，常常遇到公司倒閉。或者有不得已的家庭因素。

許多企業巫醫都有各種不同的見解（請參見最下面的參考文章），但整體來說，職涯長短雖然因人而異，但最好不要把自己視為特殊例外。而應該以市場上的事實，來推估自己職涯最適合的況狀。

舉例來說，有些人認為只要沒有成長學習性，就應該換工作，但是過去七年沒有一個工作做超過兩年半，難道表示這五個工作的內容「統統都學精通」？如果老是遇到不好的工作機會，是否就表示「自己對專業工作機會的好壞判斷有問題」而專業機會的判斷，通常也是資深工程師應該要具備。

就業市場的事實是過於頻繁換工作「通常」表示有問題，頻繁換工作的大部分人是屬於通常，而非特殊例外。


參考文章：
* 在一個公司裡為何要待十年的十個好理由
* 在一個公司待太久不好嗎？
* 在同一公司內部發展職涯才聰明
* 在同一間公司不要待超過四年喔
* 你在公司待很久了嗎
* 在一個公司待太久會對職涯不利嗎？

軟體工程師：換工作時如何談判薪資

是故勝兵先勝而後求戰，敗兵先戰而後求勝 - 孫子兵法

軟體工程師：換工作時如何談判薪資

已經拿到Offer就沒啥好談了

軟體工程師在經過繁瑣面試之後，一旦從某公司HR（人資）拿到offer，其實薪資談判已經結束。在台灣，無論是本土還是外商，大多數都會由既有資訊：也就是履歷，面試評核，薪資市場參考，工作本身價值等等，給出一個數字，這個數字在給出之後，就表示此公司認定的市場價值。

薪資福利經過「談判爭取」有可能改變嗎？當然有，也因此許多企業巫醫，都會提供一些意見，例如包裝。但以軟體工程師而言，頂多是幾個%的差距，這樣的差距，遠不如這工作本身的意義來得重要。

另外一方面，倘若拿到offer時，無論經過什麼方式爭取，竟然可以取得15%以上的薪資差距，通常表示這個組織並不確定這職位應該帶給組織什麼樣程度的「價值」，換言之，組織裡面很可能因人設事。如果是在研究機構，這可能是一件好事。但如果是在盈利企業，可能是個警訊，表示用人主管與人資並不確定公司政策，更有甚者，公司其實沒有政策！

談判薪資的兩方向

因此，所謂談判薪資，其根本在於：在還沒談之前，就已經站在談判成功的立場。

方向一：人才市場。

同樣是軟體工程師，即便在同個城市，也因不同產業有極大的差別。在台北，如果求職的方向是傳統產業的IT部門，其薪資就大概不如銀行業的IT部門。

同樣的產業，在不同的地理環境也有極大的差別。同樣是智慧手機應用程式開發，在印度外包城市班加羅爾，其薪資就遠不如新加坡。

同樣的產業，同樣的城市，同樣類型的工作，也會因為企業組織的市場定位而有所不同。組織急於擴張，自然就會提出高於市場的薪資水準。

方向二：個人價值

所有人都知道，「自己很厲害的話，薪水自然就會高，就容易找到薪資高的工作」。然而，許多軟體工程師常忽略價值的兩個重點：

(a) 其他人所認定的價值才是個人價值

自己認為自己很有價值，不見得是真的，很有可能是自我感覺良好。根據其他人所「實質認定」的價值才是真的。舉例來說，一個有N年工作經驗的軟體工程師，過去9個月，都只能找到月薪3.5萬的工作，那麼他在市場上實質價值就是月薪3.5萬。反過來說，如果一個有N年工作經驗的軟體工程師，他已經在目前的公司服務N年，最近的薪水是月薪10萬，然而，過去9個月他四處尋找更好的機會時，始終都沒拿到offer，或者拿到offer但是遠少於月薪10萬。這就表示他很有可能在現在的工作薪資是overpay，也就是目前企業可能高估其價值。

(b) 對組織有意義之產出才是個人價值

在徵才的過程中，偶有軟體工程師會覺得「自已都做一些沒有成長性的工作」或者透露「這工作無法讓自己持續成長發展」

這當然表示龍游淺池，組織可能受限於先天環境，沒辦法給這個軟體工程師更大空間。然而，這必須是此軟體工程師對組織已經有「大幅超乎期待」的產出，並且有「實質事實」才行。

建議的行動

作為軟體工程師，如果對你現有的薪資不滿，或者在目前工作領域上做得極度不開心。建議有以下實質行動

(A)  面試自己想去的公司

面試會讓你有機會知道「其他人」對你的價值判斷

(B)  把現在的工作做到超乎所有人的期待

如果無法做到這點，怎麼會知道自己的價值是提升的？又怎麼會知道下次換工作時，薪資談判已經處於不敗之地？

(C)  找到自己喜歡的市場缺口

這幾年來許多軟體工程師會前往中國，或其他成長中市場。這當然也是一種薪資成長的方式。然而，市場的缺口不見得只有成長中市場，即便在台北，也有許多職位和產業有明顯的軟體人才缺口。

找到自己喜歡的市場缺口，或許是個突破的行動。

舉例來說：過去半年來，DevOps在新創和有對消費性市場服務的公司就是個很大的缺口，此外，大數據在銀行產業似乎也是同樣缺口。

---

The history and talent market of crawler for online-store

This article contains a brief of history of product comparison of online-store and short survey of 8 TW’s organization
Crawler and full indexing of web for online store became a pretty mature technology in Taiwan. There are not much technical difficulties to build a decent crawler. The real key points are (1) patient (2) patient and mature engineer mindset (3) patient and customization on specific needs.
Almost every local companies leverage the same technology stack.

History

Price comparison requires web crawler and full text indexing search engine as foundation. Therefore, this brief of history shows not only the evolution of technology in past 23 years (#1) but also the overview of talent market in Taiwan.
Taiwanese started to build web crawler since 1995, the earliest local crawler is yam (1995) and kimo (1997). Kimo was acquired by yahoo in 2001. During 1995~2001, the technology of crawler was limited by environment itself. Meaning, network bandwidth and data-center cost were the main reason to limit crawler. Full index search engine was still task which need sophisticated knowledge in both data structure and file structure. Talents at early internet stage sometime worked more on infrastructure and basic implement of algorithm. For example, almost all EC need to host their own email server (#2) In university, the algorithm, math, protocol or conceptual classes were major thing students need to learn.
After 2000 dot-com Bubble, crawler and product listing in Taiwan grow slowly. However, many tools and platform emerged during 2000 to 2010. Firstly, stable version Python 2.0 released at 2000, Lucene (search engine) became top leave Apache project at 2005. However, the most critical service should be “google” in this period of time. Soon google’s service started to impact Taiwan, just a few years google became the most biggest crawler and web indexing around the world. It is still the best crawler and indexing service at this moment. Gradually PChome, yahoo store grows their own store-hosting during 2000~2008. Talents in this stage had more changes to focus on business requirement. There were more and more students in University learned application development, software engineering and software project management, those are the keys in eBiz to make things happened. Google, FB and AWS started impact the web development world since 2005, there were some interesting free service opened for example google shopping API(#3) In 2010, the elasticsearch’s first release created a whole new world. Although elasticsearch was just leverage Lucene as search engine and focus only on how to make this engine scalable and easy to use, it did help all engineers to focus only in building application, instead of reinvent the wheel. So does other big-data platform/tools, for example hadoop. The talent markets of software engineers also changed in Taiwan after 2010. There were more and more open positions purely looked for software engineers. Most engineers could easily implement their idea and to test their idea toward real world in an amazingly short of time. This also drive eBiz startups. Since there are useful and dedicate tools which make internet technology not rocket science anymore. The only drawback here was that some talents engineers will look for “more interesting” job in commercial world for example machine learn or AI. However, only very few engineers will do the cutting edge task, most of them on those “more interesting” job are actually try to invent the wheel not the business focus.

Talent position in history

Nevertheless, engineers’ skill set and how to be handy with tools and not limited in tools are the major difference between talent and normal engineer. It is also critical to have a few engineers’ leader who had went through different stage of internet and also some young talents who can make things from existing tool soon. It seems a 3-4 engineers team size could fit our target. One is pretty senior and lead 2-3 young talent or even just graduated. Companies in Product-Listing

The 8 organization

The 8 companies we survey shows to build a fair product comparison website is not secret anymore. However, to build a good one still require patient and fine tune on every detail. Feebee has more engineer resources, however, the visits numbers is not a target which NO2 to NO3 can’t reach. After interviewed with ezprice engineers and also gather information from Linkedin. We could easily understood that current crawler (python), full-indexing (elasticsearch) and NLP (jieba or others) are pretty mature. A team with 2-3 mature engineers and has 2-3 months to leverage tools could build a decent product.

URL	Visits (4month)	Names
https://feebee.com.tw/	38M	firstweb 第一網站股份有限公司 ( http://sitetag.us)
https://biggo.com.tw/	20.8M	樂方股份有限公司 Funmula
https://iguang.tw/	17.2M	ShineWant Tech. Co., Ltd. 嚮網科技股份有限公司
https://www.findprice.com.tw/	11.2M	環通資訊股份有限公司 UCS Inc.
www.eprice.com.tw/	9.2M	億普媒體股份有限公司Eprice Media,Inc
https://ezprice.com.tw/	2.4M	EZpriceCo.,Ltd. Taichung
https://www.lbj.tw/	2.38M	Personal website
https://www.pingle.com.tw/	0.5M	Reddoor Media Group Co. 紅門互動股份有限公司 (dotmore.com.tw)

---

Comments 

#1. 23 years is from 1995 to 2018. 1995 was the year which first “easy to get” consumer OS (Windows95) released.

#2. Email server hosting was never easy and it did make trouble for EC in early internet age. However, that also created opportunities for mail hosting service around the world. Gmail should be one of the best but mail.com and zoho.com were also good.

#3. https://www.programmableweb.com/api/google-shopping-search

#4. at 2005, Apache Lucene became a top-level apache project and latter on it almost become a core of all free full-index engine.

在多個工作機會中的選擇

只要有數年工作經驗，一個還不錯的軟體工程師，在轉職的時候，應該都有可以拿到3個以上的錄取通知。然後，從中選擇一個最好的工作變成另一個快樂的問題。

如何在獲得錄用的公司中選擇？

扣除掉工作距離，家庭因素，法律因素之後(註一)，有以下幾個方向可供在多個工作機會中選擇的參考：

(1) 優缺點列表

將你的選擇寫在紙上，例如Ａ，Ｂ，Ｃ三個公司。並且將你認為的優缺點條列出來。

這雖然是很基本的做法，但將腦中的思緒，用另一個方式呈現，會讓思考者以較高而且抽象的角度思考選擇性問題。

大部分的人，會列出條列項目大概是：使用的技術，工作內容是否有趣，薪資，工作時間，壓力大小，未來發展性等等。

除了薪資與目前使用技術之外，這些項目大部分都「主觀的判斷」。盡可能在優缺點列表使用客觀的資料。

以未來發展性為例，一個成立不到一年的新創公司，無論其產品有多厲害，它的未來基本上有90%的機會會在2年內倒閉，這到目前為止是鐵的事實。而上市上櫃公司，未來發展性應該優先調查過去3年的財報來判斷，而非看目前的股票價格。

再以工作內容是否有趣為例：必須要是「你到職之後會做的工作」來判斷是否有趣，而非是這公司產品很有趣。因為，即使是資深軟體工程師，到一個新地方也有可能會先做最無聊的工作。

最後，壓力其實因人而異，但客觀的判斷也不可避免，應該以「過去一年有多少比例的人離職」這類型的數字做為判斷的依據。

(2) 自身能力所帶來的影響力

除非是你自己就是這公司的老闆，否則，當你加入一個工作時，透過自己能力的產出，對公司造成正面影響力，是唯一你能做得好做的開心的原因。其他皆屬次要。

某些工作的特性，讓軟體工程師本身的影響力比較低，舉例來說，所有傳統的IT工作恐怕都是如此。即便IT工作非常重要，但通常被歸類為「保健因素」：也就是沒有會死，但太好也沒用。

某些工作看似很重要，但由於組織結構龐大，讓資深軟體工程師發揮空間較有限。例如在超大型軟體公司，有上千名員工，即便是非常厲害資深的工程師，其實對組織而言相對重要性也低。一個超過千名工程師的公司，不會有任何一個工程師特別重。

小型公司對大部分的軟體工程師來說，都比較能透過自身能力，發揮較大的影響力。這也是為什麼過去數年，新創公司能蓬勃發展的原因之一。但的確也有可能，大型公司的某些小型部門，工程師反而會發揮巨大影響力，line的故事可作為參考。

(3) 未來的主管

英文俗語： people quit their bosses, not their jobs.  
在有多個工作機會選擇下，未來的主管是誰變成是重大的考量。

(a) 不知道是誰？

特別是超大型企業，新建員工會有「儲備培訓期」因此有可能在加入此公司之後一段時間，都不太能確定未來主管是誰。這在軟體開發的領域機會不大，尤其是對資深工程師來說。

(b) 考量的方式

盡可能以「事實」來考量，而非憑「感覺」。面試時通常會有問問題的機會，此時可以探究事實。基本的事實像是：團隊有多少人，最近三次加班是什麼時候，最近一次績效評估中，產出最好的員工做了哪些事情。感覺則是「這裡看起來好像很溫馨」，「面試我的主管看氣來很溫和」。

大部分的情況下應徵者期待的是「一個好主管」。然而，人非聖賢，要考量的其實是管理風格上最適合的主管。因此，詢問管理上實質作法，就是考量的最大因素。

當然，這些考量的事實，也應該呈現在比較的優缺點表格中。

---

註一：法律因素是指，即便有超高薪水，不合法的工作還是千萬別碰。

何謂：資深工程師

在招募人才過程中，經常被問到「資深工程師的定義是什麼？」

以軟體開發的角度而言，資深工程師有三個面向：

* 技術能力
* 實質經歷
* 團隊合作

聽起來簡單，其實不太容易。

技術能力指的是對「現在使用的技術的直接掌握能力，以及持續成長態度」。

實質經歷指的是「過去曾經做過哪些事，取得哪些成果」。

團隊合作和前述的實質經歷略有關係，不過指的是「處在組織裡，透過自己的能力對組織造成正面的影響」

在人才招募中的過程，在有效時限內，對應徵者針對這三個面向判斷是否符合「資深工程師」是有點難。有幾個方式可供參考。

技術能力

現在使用的技術的直接掌握能力。最簡單的方式是設計考試或者實做作業，根據其結果來判斷技術能力。典型的證照例如SJCP, CCNA都屬於此類。當然， 也常有組織採取直接面談的方式來判斷技術能力。

直接掌握的能力，當然不包含應徵者，自我宣稱說："這個我google的到"，或者，"我不記得但是查得到"。畢竟大家都可以查得到，既然都查得到就不是判斷的標準。

技術能力的判斷上：考試，作業，面試各有其優缺點。簡單的說，人為介入越多，就有不客觀的判斷；但是，無人介入的純客觀單純考試，難以判斷設計概觀等複合的技術能力。

使用半開放性的實做作業，加上2人以上，事先決定好的面試結構，應該是比較妥善的方法。不過，請避免幾個認知偏誤：(1)月暈效應 (2) 羊群效應 (3) 觀察者效應。這些偏誤，在技術面試時會特別嚴重，因為許多人會誤以為技術面試很「客觀」，但實際上，所有面試都很主觀。唯有特別注意偏誤，才能盡量降低主觀性。

月暈效應：因為某些光環，讓面試官覺得應徵者可能很厲害，而沒有去驗證事實。舉例來說，有三十年程式設計經驗，又做過某些驚人專案，就假設此應徵者「隨便學什麼都會」。又或者某應徵者可能是網路傳說的「大神」，就覺得他可能很厲害對團隊很有幫助。

羊群效應：面試之後的討論，如果有人先有意見，沒意見的人可能就會追隨之前的意見。

觀察者效應：因為外表或履歷表的直覺或第一印象，而讓面試官試圖尋找錄用或者不錄用的證據。而非客觀的先收集事實。

最後，在技術上持續成長態度很簡單，能認知到一個事實「當自己學的越多，表示自己不會的越多」，並且真有實質行為-固定閱讀也好，非工作之外寫程式也好，其他任何實質行為佐證對資訊技術有成長喜好。

實質經驗

所謂資深，當然表示在軟體開發類型的工作上，有很多經驗，並且這些經驗取得成果。

資深的實質經驗，通常包含「好事」以及「壞事」。更重要的是，經歷過的壞事，知道如何真正改善它。並且認知到，不是所有錯誤都是別人的錯，必然有自己的錯。

面試實質經驗也一樣要破除上一段的認知偏誤。就不再贅述。

團隊合作

資深工程師，能體會真正的團隊合作要素：(1) 技術溝通透明 (2) 控制進度透明 (3)  立基於事實的溝通

技術溝通透明是指：任何單純技術上的選擇，使用，表現，都是透明的。簡單的說，能真正了解技術完全不需要任何的隱瞞性。

控制進度透明是指：了解透明進度對團隊非常重要，並也了解：控制進度的單位是時間，而不是工作內容。

立基於事實的溝通是指：雖然許多事情必須要有假設和猜測，但就工作上的決定，必須要盡量立基於事實。舉例來說：「我覺得最近的release可能會有問題」這就是一種猜測的說法，然而：「最近的release並沒有執行回歸測試，所以我覺得可能會有問題」這也是一種猜測，但卻是立基於事實的猜測。

企業巫醫：強人不受環境影響，很遺憾大部分的人不是

TED眾多演講中，有位經濟專欄作家Tim Harford講了因挫折而成長的主題。

他用著名的科隆演奏會為例，告訴聽眾，一位爵士樂大師Keith Jarrett如何在一台誤送來的沒調音半殘鋼琴上，彈奏出驚艷的效果。科隆演奏會(1975)的錄音，甚至成為史上最暢銷的個人即興爵士鋼琴專輯。實際故事可以參考這裡。

演講者，接下來也提出在稍微困難的環境下：例如英文書本的字型都是粗體大寫，會讓學生為了解內容，刻意「用力」讀文字，讓文字內容更容易被思考和記憶。

些微困難的環境，可以讓大多數的人獲得進步，但極端的環境只有極端少數擁有高強度的技術能力和意志的人，才比較有機會不受環境影響，進一步從極端環境中創造更大價值。

以科隆演奏會為例，Jarrett大師是因為已經熟記樂譜到閉著眼睛都能彈，每個音調和效果對他來說都已經是無意識的動作。因而，演奏遇到即時問題時，他才有「閒暇」的即興創意產生，並實踐出來。一般演奏者，遇到半殘的鋼琴，鐵定是難以完全發揮能力。

在職業生涯中，每個人勢必都有自己擅長的領域，然而，實務上環境造就的問題，在大部分普通厲害的人，會產生難以克服的影響。而僅有在一些特定領域的強人，才能改變環境。

因此，在企業組織中，人通常會去「適應環境」和「控制環境」。就好像Jarrett試著去適應半殘的鋼琴，並且透過自己的能力，進一步控制它，讓它不成為發揮自己能力的阻礙。

幾乎所有的創業者，都是透過創造新的企業，來達到控制環境的結果。不過創業成功的機率相當低。

而在企業組織內工作的人，都需要適應環境，然而，適應了之後，鮮少有人不受環境影響。如果組織內部的氛圍是「保守」「部門壁壘明顯」「官僚」的話會更嚴重，這樣的環境，可能會直接影響一個人對工作的認知與態度 -  特別是剛畢業出來工作的人。最糟糕的是，即便這位新鮮人換了環境，可能還受前一個比較糟糕的工作環境影響。

要能不受環境影響，適應環境，進而控制環境的方式有許多種，但最有效的恐怕是「變成強人」，在專業工作領域上，要變成「強人」，遠比鋼琴大師容易許多。

在專業領域上，如何變成強人？

(1) 特定主題的實質經驗(深度)

無論是nodejs，VBA，還是對excel有非常深入的了解，都是一種特定主題。盡可能探究深入某個主題，當你認為這我已經會了，要試著問一下自己，「全部都很瞭解？」還是「我會用它做某些事情」。以簡單的excel為例，大部分的學生都會說自己「會」excel，但是大部分的剛畢業的學生恐怕連pivot table都不曾使用過。

(2) 和工作領域相關的學習(廣度)

在工作上，必然會遇到和自己工作相關，但可能是其他人負責的事情。這些工作領域，會逐步造就自己對工作上的廣度的了解。以程式設計為例，許多人都對SQL有使用上的了解，特別是由於MySQL, Oracle, MSSQL歷久不衰，程式設計師多多少少都知道SQL。然而，把SQL寫在履歷表上的程式設計師，其實有一半以上的人不了解OUTER JOIN。傳統上SQL的管理是屬於DBA的任務，但現在的程式設計師，越來越多會涉獵devops的領域，對SQL了解就是一個增加廣度的例子。

(3) 在目前工作貢獻

就像鋼琴大師一樣，必須要有「在目前工作上的產出」才是真正的貢獻。貢獻和能力並不見得有直接相關，但是，當具有深度與廣度的知識經驗之後，當然容易對組織有更大的貢獻。


簡而言之，持續學習，就是成為不受環境影響的強人的唯一途徑。

企業巫醫：市場領導者的鐵律 .(書摘)

Discipline of Market Leaders 市場領導者的鐵律。

不確定是否有中文翻譯書籍。

書中描述，要成為優良企業組織，必須將以下三件事，做到某種可接受的程度，並且必須要在其中一件事情變成市場的領導指。

(1) Operational Excellence 作業最佳化
(2) Product Leadership 優質產品
(3) Customer Intimacy 客戶關係


(1) Operational Excellence 作業最佳化

產出高效率，低價格，容易購買的流程與產品支援。盡其所能降低成本，盡量標準化，簡化各種控制，加上有精確的中央控制，與能做到整合性高速的管理系統，減低浪費。範例企業是Walmart和Dell。

(2) Product Leadership 優質產品領導

產出最好的產品或服務，專注於產品創新，產品開發，探索新市場的可能性。並盡可能追求未來的創新，領導未來的可能性。範例企業是Apple。

(3) Customer Intimacy 客戶關係

著重客戶關係管理，將執行面交由最靠近客戶的員工，縮短對客戶服務的距離，幾乎永遠以客為尊，願意在一般的產品或服務上，對個別客戶進行客製化最佳化，客戶滿意是最大的核心價值，影響所有流程。範例企業是Ritz Carlton(飯店集團)，IBM。


其他參考：富比世