快速學習技能 - 解決職場困境

快速學習工作上需要的技能，而技能與知識同時成長，是在職場上能空出時間，進而控制時間的最好方式。

在這世界裡，「在N小時內學會XXX」的書籍研討會不在少數。這些都很有參考價值，然而，學習是非常「個人化」的事情。例如：國高中花很多時間在補習班的學生不在少數，但真能夠發揮補習的目的 - 也就是考上最好的學校 - 卻僅有少數。

有些書籍，宣稱找到共通的方式可以在N小時內，學習「任何」技能。並且當然以自己過去一年學習到的技能，作為鐵 證 (參考文末的註1)。不過，共通的方法都僅能參考，每個人終究都還是需要找到自己的方式 - 只要是真的想學。

在職場工作，會遇到的困境很多，有很大一部分是「人」的問題。但無論哪種問題，如果你是個「技術上的狠角色」，你就有很大的機會撇除人的問題。即使無法排除，擁有更多技能，就表示有更多選擇 - 大不了就是離開現在的環境。

技能的快速學習，首要之務，應該是找到自己的方法。

在還沒找到之前，或者，自己現有的方法似乎有所侷限。倒是可以考慮以低成本的方式，嘗試一下各個企業巫醫所提供的方式。

重點在於：有方法遠比沒方法好！

以下是幾個常見共通步驟與確切花費時間：

(1) 原因與目標確立

不知為何而戰，當然容易半途而廢。

有些原因很清楚，例如：目前會寫java，而現在因為工作需要學習Scala。有些是個人喜好，例如：常喜歡去日本旅行，想學基本對話比較方便。有些則是好奇性質，例如：聽說Big Data大數據分析很紅？不知道到底是那是什麼。有些技術是「執照類型」：例如開怪手，駕駛遊艇。

無論是哪種原因，需要一個簡單的目標，例如：學會Scala，了解Big Data，學會日文會話，學開船等等

不應該花太多時間在目標確立，最多0.5小時。

(2) 階段性成果確立

長期預測是很難，而且接近不可能。因此，快速而踏實的方式是計畫階段性成果。

階段性成果指的是一個「可以衡量的」，「有意義的」，「可展現的」，「務實的」極短期目標。

所謂極短期，是指20小時之內：也就是禮拜一到禮拜五，每天2小時，連續兩週。

這並不是指，超過20小時就是太多，也非20小時就能夠變成專家。而是必須要讓自己在20小時內「有所成果」。

舉一些例子如下：

Scala：撰寫網路爬蟲程式，可針對wiki做特定字串資料檢索和統計。

日文會話：用日文會話辦理飯店check-in，詢問餐廳資訊和找路。

Big Data大數據：選擇並且看完三本大數據的科普書籍。

學開船：考取動力小船執照。


階段性成果的確立，其實和每個人對該技能瞭解程度的不同而有所有不同。了解的越淺，就會訂出越模糊的階段性成果。但其實無妨。因為這只是第一階段的成果而已。

其實，要能確立階段性成果，某種程度已經完成一個小型計畫。計劃本身是死的，「做計劃」這件事情才是重點。這個階段應該花費3-4小時的時間。

(3) 找到練習與取得知識的方式

取得知識和練習的方式非常重要。這方式必須要同時符合「階段性成果」和「目標」。

要快速學習知識和技能，必須「專心花一點時間」得先找確切練習方式，取得知識材料，和額外獲得協助的地方。

取得知識最踏實而且快速的方式，其實還是圖書館。先考慮，或者試用一下圖書館堆書法(參考這裡)。

然而，許多技能是需要練習的。例如：寫程式，學日文，Linux操作等等，就需要找到最適合自己的練習方式。

以學會寫Scala程式而言：即便只是做個簡單的網路爬蟲，仍要再細分小階段，先準備環境，簡單了解語法，知道怎麼使用Scala來執行http get...等等。每個練習的動作，都是為了達到階段目標。

以學日文會話而言：最好而且便宜的方式應該是「馬上去找」語言交換。其次則是去借幾本基本會話的書，再加上幾個app/網站。(註2)

當然，有些技能最簡要的方式，還是花錢受訓，例如「動力小船駕駛」。這反倒是最簡單的，只要有決心即可。

除了花錢受訓之外，這階段恐怕需要額外的時間，預計6小時是合理的。


步驟(1)到(3)，最好是不要花超過8小時，也就是一個假日的時間。

(4) 練習與取得知識

這一階段的重點在於「專注」。如果計畫是兩個星期，共計20小時，則這時候，就該專注於自己決定的方式，無論如何，都要在兩星期/20小時之後來檢視成果。

這也是為什麼，設定階段性成果時間不能太長(註3)。

如果的目標過於抽象，例如要「瞭解什麼是Big Data」，在這段練習與取得知識的過程，就會變得更加含糊不清。以因此，階段性目標才會設定成「看完三本科普書籍」，這樣才能檢視成果。

要讓自己專注的方式有很多：短時間專注可用番茄工作法。長時間則需要計畫與經驗，而目前你在看的這篇文章，實務上就是在解釋，如何將學習技能知識時間專注於學習。

在這個階段，根據計畫的不同有不同的時間。但是切記「越短越好」。如果不確定時間長短，那就以10個小時，每天2小時為準。

(5) 自我評量

必須要有客觀方式自我評量。

因為是自我評量，當然一定要確實。

以學習Scale的第一階段：完成網路爬蟲為例，如果在20小時內完成，那麼就可以有信心的說學習Scale已經前進很多。

以學習日文會話來說：如果可以和日本人測試對談飯店用語，那就表示階段性成功。

再次強調：快速學習技能的階段性成果，必須要以務實為主。許多人在學日文一開始是以背熟50音為第一階段。但這其實不太務實。因為死背永遠是無聊的，而且即便你可以把50因背得滾瓜爛熟，在日文能力 - 特別是會話 - 的務實進展也等於零。

(6) 收成：前進或者換目標

達到目標後，請隨意犒賞自己。

而接下來，就是要決定往下一個階段前進，或者更換目標。

這時候的更換目標，並不是半途而廢，畢竟你已經前進了一段務實的路。這和達不到目的而放棄，無論在心態上，還是事實上都有很大的不同。

往前進的時候，記得也是重複設定一個「短期可達到」的務實目標。

例如：

學習scala，已經完成網路爬蟲程式，接下來的目標是在Spark中，以scala撰寫一個可分析http log的分散式程式。

瞭解Big Data大數據：已經看了三本書，接下來的目標是找一個有意義的主題，寫一篇部落格文章。

這樣的快速學習，真的能解決困境嗎？

快速學習能讓你在職場上，取得更多的「選擇性」，讓你對事物有所掌控。這才是針對困境的真正解決之道。

或者也可以跟我們聯繫取得困境的快速協助。

---

註1: 有幾個例子

   * Fluent in 3 Months: 三個月內可以流利的學會任何語言。作者甚至示範了中文學習，對外國人來說，學非拼音文字真的難為了他們。

   * The First 20 Hours: How to Learn Anything FAST. 作者示範了如何快速學會各類不一樣的技能：瑜伽，寫程式，風帆板，圍棋...但個人覺得比較難以置信的還是「新鍵盤佈置：colemak 」

   * The 4-hours 系列：作者Tim Ferriss寫的幾本書。內容從健身到創業都有，其中都會涵蓋快速學習的方式。

註2: 請參考Fluent in 3 Months 一書

註3: 當然如果你是想考動力小船執照，由於上課時間是固定，當然沒辦法「更快」。

不玩一樣的遊戲 - 準備面試的真正技術

程式設計師如何在面試中展現真正價值：最好的方式當然是不要跟其他人玩一樣的遊戲，也就是在面試中，找出幾個能突顯自己技術能力的要點。針對這些要點，做延伸性的準備。

不管什麼原因，當一個軟體工程師下定決心要換工作時(註1 )，面試通常是免不了的。

作為軟體工程師，鐵定會上網搜尋各種「面試技巧」文章。

例如：常見面試問題的最佳回答：這篇或者這篇。也有些人會說，面試除了回答問題，更重要的還是會問對問題，例如這篇。

但是，人資與主管，通常比面試者更知道這些所謂「標準問題」。也很清楚面試者可能會去找的「標準答案」。這些面試技巧文章只是一再重複大家都知道的常識，多複習這些常識是有很大的好處，至少可以避免緊張或者不必要的誤解。

但常識不會是關鍵。


在面試的時候，除了回答標準問題之外，最重要的是「確實展示自己的價值」才是關鍵。

軟體工程師/程式設計師的價值展現，其實第一時間點是在「看履歷表」的時候。短暫的面試時間是在「檢查履歷的正確性」。假設面試者的履歷寫的中規中矩，沒有什麼誇大，也沒有過度謙虛(註2)，會讓你進入面試階段，就表示在履歷表上展示的技術能力是公司願意接受的。

面試展示自己的價值，通常是在幾個關鍵點。而這些關鍵點，都是「面試之前」可以先做好準備的。

(1) 應答技術問題
(2) 解釋過去做的事跡
(3) 詢問技術相關的問題

(1)  應答技術問題

大部份的軟體工程師工作，通常都會有程式考試題目。只要你在Leetcode, topcoder之類的網站，用你本來就熟悉的程式語言，多練習幾次，應該就不會太離譜。事實上，技術問題不可能考得過於艱澀 - 因為公司組織通常沒這麼多閒功夫在一個面試者身上。

其他的技術問題應該要根據你在履歷表上的專長做「延伸性」的準備。延伸性準備，才是展現價值的最好方式。

例如，倘若履歷表上你的專長是WebUI，那麼你就得延伸準備到HTTP：至少了解一些重要的header。如果你的專長上有寫Linux，那麼就必須準備回答曾經使用linux做過什麼事情？

如果曾經在linux上架設web server (nginx, apache...)，至少也得知道設定檔在哪裡，如何開始停止服務，如何列出執行的行程(process)，如何在不得已的時候強迫結束服務。當然，如果你會回答kill -9，最好確實知道為什麼是-9。

應答技術問題的不僅只是「防禦性」告訴面試者你的能力。而透過簡要地回答，「順便」展示自己對技術能力掌握的額外價值。就以上述kill -9為例，以筆者過去15年，面試超過400個人經驗，在履歷表上寫「熟linux」的起碼也有150人。這些面試者，八成都知道kill指令。然而，僅有不到10個人，知道為什麼要用kill -9，並能說明kill預設single 15是比較好的選擇。

在回答簡要技術問題，只要能有正確延伸性的回答，就能展現與他人不同的價值。而這絕對事是先可以準備的。

(2) 解釋過去做的事蹟

只要有2-3年工作經驗，面試時，一定會被詢問過去做了什麼。

因為，要了解未來一個人在組織的貢獻，最好的方式是看他「過去貢獻了什麼」。以下是一些解釋過去事蹟的要點。

＊＊ 妥善呈現事實而非感受。

當你已經離職時，過去的事蹟就已經成為「歷史」，而你可以準備的是「妥善呈現歷史的事實」，切勿扭曲或用「感受」呈現。

例如：「在那個專案裡面，幾乎事情都是我在做」。這其實是你的個人感受而非事實。事實必須要用無可扭曲的方式呈現。

又例如：「這個專案扣除html/css之外，前端javascript在git上大約有3萬行左右，其中兩萬五千行是我commit而且到專案結束也都是我負責維護」。這只是說明在程式碼上的「事實」，你並沒有貶低別人的貢獻，因為也許那其他5千行極端重要也說不定，但你也呈現了以code base而言，你的貢獻在事實上絕對不低。

＊＊過去事蹟，絕對可以，而且也絕對需要在面試前妥善準備。

因為，你對過去自己真實貢獻越了解，就越能掌握過去事實。越能掌握過去的事實，就越能表示自己在技術上更有未來潛力。

例如，假設你是IT部門員工，過去都是協助內部系統上線，這些系統其實也是外包商提供。在面試時，被詢問做的內容，如果只是簡短回答「將公司委外開發的系統上線」當然也是可以。

但如果你在事實上，也會做「自動化檢測系統」「建構上線風險評估」「上線後的使用分析」「成本分析」以及「有沒有達到預期目的評估」，這些才是IT真正產生價值，並且與眾不同的地方。

最好的情況會是，公司之前並沒有此做法，而是你主動完成這些有價值的事，讓公司變得更好。可是，如果你已經離職，來不及產生事實 (當然也不可能去捏造說謊)。那麼，至少還是可以說「當時其實應做自動化檢測系統」，雖然那時候沒有完成，但你也可以在面試前自己做一個小規模的自動化檢測系統，而在面試的時候就可以大大方方的說，當時雖然沒做，但是自己覺得應該要做，所以主動在事後做了。

當然這表示你需要在面試前付出時間準備。這樣的付出不會是沒有代價的。即便這次面試沒用到，你所做的事情是不會消失不見，只要是你做的「技術上正確」的事情，未來一定會對你的職業生涯有所助益。

(3) 詢問確實的問題

通常面試的最後，都會給面試者問問題的機會。

許多文章中，的確會說明問問題的重要，例如這篇。有上網查過的面試者，也了解不該問一些瑣碎小事，上下班時間，或者公司基本福利，因為這些問題只是等於打發時間。雖然沒有害處，但是也沒有價值。

軟體工程師最適合的就是詢問有價值的技術相關問題(註3) 。而這些問題也可以讓你稍微判斷此公司的狀況。

基本問題

一些很基本的問題，可以簡單展示你對軟體專案成熟度，也可以讓你了解這個公司的狀況：

* 請問目前是用什麼樣的版本控制系統，管理程式碼？

    該組織用什麼樣的版本控制系統不重要，無論是git, svn, cvs, p4...都可以。重點在於，的確還有些組織連版本控制系統都沒有。

* 請問目前組織是使用哪種專案管理方式？

    最近幾年是流行Agile/Scrum，

* 假如我有幸錄取，前三個月你希望我能完成哪些事情？

    這個問題代表自己的積極程度。主官如果對這個問題講得過於籠統抽象，很有可能該面試官(主管)並非實際的技術管理者。

* 團隊最近一次做code review是什麼時候？
* 團隊的bug追蹤流程目前大概是怎麼做的？
* 目前自動化測試的涵蓋率大約是多少？

    這些問題是展現自己對軟體開發的成熟度。特別注意的是，如果這些問題被籠統的回答，也不需要追根究底找別人麻煩。


進階問題

可能會引發進一步討論，也可能被反問，所以要事先準備被反問時的技術回答。

例如：

* 就現在的資料和面試的情況，您個人覺得會錄取我嗎？

* 最近一次在團隊裡面遇到最大的技術困難是什麼？

* 組織如何判斷成員的技術產出？

高級問題，

很有可能被認為是反過來刁難面試主管的問題。必須斟酌採用。例如： 

* 目前軟體專案程式碼的entropy有多高？

* 目前自動化建構和測試是採用哪些工具，涵蓋率有多高？

* 就您個人而言，最近在組織內學到新的技術是什麼樣的技術？新的程式語言或者新的工具？

面試是可以事先作準備地，軟體工程師的面試準備，應該花時間以事實展現價值作為準備方向，而非準備一些大家都知道的常識或者花時間準備外在行頭口語表達...等等。當成功地完成許多面試，就可以在工作機會上有所「選擇」。

---

參考文章：
(1) Scrum認證！不要再浪費你的時間了
(2) 如何充實自己
(3) 畢業前六個月 建構職業生涯
(4) 年底才績效評估或考慮轉職 已經太遲了
(5) 因為沒挑戰想轉換跑道，先檢討自己吧

---

註1：要轉職換工作區分成「主動」與「不得已」兩種。不得已：例如公司倒閉之類，當然就不用討論。但是如果是「主動」，就要先想清楚「真正的原因」。因為這個原因，可能不會因為你換工作而消失。

註2：剛畢業的學生可能是怕履歷表太空洞，通常都有誇大的傾向。而在業界打滾數十年的老鳥，有時候會有過度謙虛的可能。

註3：當然不應該「窺探機密」，因此可以在一開始的時候先說「如果這個問題不小心牽涉到公司機密，請告訴我，在這個時間點我無意探究貴公司的機密」

數據分析 - 獵人頭如何從Github尋找人才？

前陣子遇到某特殊的獵人頭hunter公司(參考:這裡)，竟然是透過分析統計在github, gitbucket的程式庫，來找到軟體人才。

目前，github使用者數量仍屬商業機密，但估計約在2千萬左右(參考:這裡)。當然，使用者大部分從事軟體相關的行業。

資訊科技，特別是軟體的實際成果，容易在網路上展示。因此，如果要找到「軟體開發人才」，github是一個很好切入的地方。一般獵人頭可能會人工搜尋，但身為工程師，當然是寫程式找到大量資料。

從github找人，這做法有一些顯而意見的好處：

1. 有可能看到此人實際上寫的程式碼
2. 有可能了解最近此人的工作範圍
3. 很快找到此人的聯絡方式(email)部落格或其他技術相關資訊
4. 有可能找到此人合作對象
5. 有可能看出此人的英文語言能力

當然也有些顯而易見的缺點：

1. 當然找不到那些不在把專案程式擺道github的人
2. 此人可能只是擺放玩樂性質的程式
3. 只能有機會看得出技術能力，非技術能力仍然需要其他佐證
4. 資料範圍過大，很難逐一肉眼看完

雖然我不是獵人頭，但基於工程師的精神，就嘗試一下解決「資料範圍過大，很難逐一肉眼看完」的問題。看是否能透過程式取得並處理gitbub資料，找到潛在挖角對象清單。

實際上做的步驟如下：

1. 了解gitbub資料如何取得：

github提供api可供程式使用。和許多Web Service一樣，也有完整的文件，請參考這裡。

2. 以程式取得少量測試資料

github的web api測試起來很簡單。舉例來說，如果你已經登入github，用以下這個URL request就可以找到，以javascript與nodejs為關鍵字的所有程式庫：

https://api.github.com/search/repositories?q=topic:javascript+topic:nodejs

當然，他的回應是json格式，需要簡單地用程式轉換。例如下圖，乃是搜尋和javascript相關，並且其位置在台灣的使用者：

測試資料回傳乃是json，調整格式成為csv，以便於日後在excel做簡單分析。

3. 了解測試資料內容

如果已經有在使用github，那麼對於回傳的資料應該很清楚其內容意義。

如果不太了解github，就需要找對軟體版本控制系統有些認識的人幫助瞭解其含意。

這上述的範例：「搜尋和javascript相關，並且其位置在台灣的使用者」來說，程式會刻意收集following(有多少人在跟隨這個人的更新)，follower(這個人跟隨了多少其他人)。此外，程式會額外計算push和javascript相關的程式庫的次數，取名為work，表示和javascript的相關工作在過去一段時間的次數。

4. 撰寫簡單統計程式，大量取得資料

當然，這個程式就放在github上。請參考這裡。

程式本身是python撰寫，需要有github帳號密碼才能使用。

5. 結果

以上述範例：「搜尋和javascript相關，並且其位置在台灣的使用者」大量取得資料並且「過濾可取得公開email」的人數一共是661筆。並且取最前面的199筆，給熟識的headhunter (獵人頭) 鑑定看看是否有效果。

目前的回應都是此資料非常有用。

企業巫醫 - 向上管理的實務作為？

向上管理是個歷久不衰的名詞，它和「人格特質分析」「領導與管理」等名詞雷同，每隔一小段時間就會以各種形式，出現在企業巫醫們的討論中。

近期隨意查詢就可以找到不少相關文章： 向上管理(cheers雜誌)，如何讓老闆聽我的，反對老闆的六種方式，向上管理的四步驟 ......

「向上管理」向來是一個譁眾取寵的話題，眾多企業巫醫仍然以泛泛之談，試圖教導並解決一個現實而又務實的問題。

企業巫醫，總是能選定看似重要的無法辯駁，共通的話題，而且此類話題完全視個人情況而有截然不同的作為。因此，企業巫醫可以提出極端空洞的說詞，卻又多少讓人覺得有趣。除了「向上管理」之外，「創業」「創意」「領導與管理」「人格特質」等等都是屬於這類。

實務上，「向上管理」不能是打算進行的行為，而是產生貢獻中的其中一個結果。換言之，追逐向上管理，等於是捨本逐末的追逐影子行為。

因此，先務實地做到基本三件事情，假如踏實的做到了，向上管理就不是問題，而是附帶的結果。

1. 真正了解關於自己的現況事實

事實現況聽起來簡單，要找到也很簡單，但是要承認自己的現況事實其實有點難。

事實必須是清楚的，不模擬兩可的。例如，假設你是NBA球員，去年平均上場25分鐘，平均得分14分，這就是事實。至於你的技術能力好不好，並不是「事實」的一部分。以資訊科技的相關工作來說：參與過專案是事實，寫過java/python程式是事實，取得JSCP證照是事實，有Scrum證照是事實，帶領過開發團隊是事實，參與open source相關研討會是事實。

然而，具有良好溝通能力不算是一種事實，喜愛資訊科技不算是一種事實，

現況也必須是清楚的，不可能模糊。例如，目前薪資是現況，工作年資是現況，是否有直接report的人(也就是是否為管理者)是現況，最近一年有沒有拿到其他公司的offer也是現況，曾經拿到比現在薪水高的offer也是現況。

然而，覺得自己薪水被低估不是現況，覺得自己不受到重要不是事實，幾乎大部分的感受也都不是現況的一部份。

請參考這裡，這裡，這裡。

2. 讓自己的實際產出超乎期待 

二因子激勵理論，描述「保健因子」和「激勵因子」兩種個人激勵因素。而其實這也是務實的評斷自己工作的方式。請參考這裡。

要確定自己的產出超過期待，必須要確定產出有「超出」。

以基層程式設計師而言，在過去一年該寫的程式功能都有如期完成，並且品質在一定範圍之內。這樣的工作內容並沒有「超乎期待」，只是滿足「現在的薪水」而已。

要超乎期待的方式有很多。最容易的方式，是在目前工作範圍之外，「額外」並且「主動」完成有意義的事。例如，以基層程式設計師而言，在過去一年該寫的程式功能都有如期完成，並且品質在一定範圍之內，並且，主動地在額外的時間舉辦小規模研討會，分享工作上技術的進展。另一個例子，以基層程式設計師而言，在過去一年該寫的程式功能都有如期完成，並且品質在一定範圍之內，並且，由於主動學習其他程式語言，因此在其他專案上也能做額外貢獻。

3. 建立短中期職涯計畫並確實執行

在資訊科技產業中，實踐長期職涯規劃幾乎是不可能(註1)。

然而這並不代表自己現在就應該隨波逐流，看主管決定什麼就做什麼。個人應該要維持短中期的職涯規劃。特別是短期規劃。

短期規劃，必須要和技術能力以及現在工作有密切相關。

例如：

「作為一個程式設計師，未來8個禮拜，要能學會Scala基本用法，並且提出現在產品裡用Scala做分析的計畫」

「作為一個QA新鮮人，未來4周，要能將現在100個手動測試的case，至少其中20個變成自動化測試。同時，原本的工作也不會拖延」

中期計畫乃是半年到2年左右。必須要是「可以明白斷定達到與否」的目標。

例如：

「作為一個QA新鮮人，在2年內我想要變成資深QA，斷定是否為資深QA是以是否升遷或取得其他公司資深QA的offer」

當你完成數個短期計畫，通常表示你也踏實的逐步成長。即便有些短期目標沒有照時間完成，也沒關係，幾次之後，仍然是踏實往中期目標前進。

重點在於：這些目標是你自己決定的，並非主管或其他人硬塞給你。而目標既然和目前工作有關，自然就會協助你在工作上成長。


......
如果你非常非常確定已經完成以上三點，但覺得在這個組織中的成長仍有阻礙，還是很需要「向上管理」，用以獲得好的評價，獲得升遷？這基本上是不太需要，因為你應該儘速離開這樣的組織才是最好的方式。

---

註1: 「長期職業規劃」和「個人理想夢想」並不同。個人理想夢想可以需要很長很長時間實踐，也可能只需要很短的時間，也可能和職業無關。當然個人夢想就需要長期投入，也可以規劃，也可以不規劃。不過，不投入自己時間的夢想，通常就是空想而已。

畢業前六個月 - 建構職業生涯

在台灣的碩士生，畢業前六個月通常忙於論文。如果不考慮繼續就讀博士，畢業前六個月其實是建構職業生涯的最佳機會。

更確切的說：畢業前六個月是讓你日後容易取得理想工作的最佳準備期間！

為什麼需要強調在6個月前建構職涯規劃？

環境上有許多現實的情況，例如，大部分好工作機會，其主管都傾向雇用有經驗的程式設計師。然而，絕大部分剛畢業學生並沒有實際軟體開發經驗。

因此，剛畢業的學生如果剛好獲得一個適合自己，能夠成長，能夠有所貢獻的工作，那麼就會進入良性循環。這個工作會讓這個學生更容易找到下一個好工作，或者即便不換工作，也能在目前的組織中成長。


反之，剛畢業的學生如果找到一個不適合自己，到處瞎忙，只是以時間換取薪資的工作，那麼就進入惡性循環。這個工作會讓該學生不容易找到比較好的工作，即便勉強換工作，也得靠運氣。

如果不想靠運氣，也沒有富爸爸，也不想自行創業(註1)，則要做的事情很簡單：

(1) 考慮現況
(2) 設定短中期目標
(3) 建立事實

考慮現況

首先，最重要的是，取得一些關於自己的事實。是不是想要做關於軟體開發相關工作？想要做哪一類型的相關工作？是否知道自己還缺乏哪些能力？哪些地方的工作，可在短時間有巨幅成長？

如果想要當個程式設計師，要考慮的現況：

1. 能使用哪些程式語言：是真的會，而不是只寫過hello world和學校作業。並且有「事實」可以佐證。例如在github上的project，或者工讀經驗。

2. 能掌握資訊技術工具：是真的能掌握，而不是用過一兩次或者學校作業。並且有「事實」可以佐證。例如：工讀經驗，利用資訊工具做的個人專案等等。

3. 能掌握團隊專案合作方式：例如是否有Scrum相關證照(註2)。

4.....<其他還有很多請自行想像>

如果想要從事資訊業，但是一開始就做SA/PM類型的工作，在軟體開發職涯裡其實不太腳踏實地，不過，真不得已可以參考這篇：資訊科技學生畢業後只想當SA/PM (三個創意作法)

設定短中期目標

某些職涯教練，或許會建議新鮮人設定長期目標。甚且透過各種神奇的方式推展或瞭解自己的熱情(passion)所在：例如希望自己五年之後賺10億之類的。

大部分的長期目標雖然有趣，但是用處不大。設定可預計的中短期目標更為重要。

以6-12個月為期，讓自己在畢業前達某些技術性和非技術性目標，對未來職業生涯非常有幫助。以未來想要當程式設計師的學生為例，在畢業前六個月可以訂立以下目標：

* 開發並且將一個Android APP放在googlestore上：熟悉在android平台上開發APP，因此需要熟悉Java。

* 取得Scrum Master證照

* 閱讀3-4本關於軟體QA的書籍，並且運用在現在的專案上。(含建構測試案例，執行測試，系統化記錄錯誤，...)

訂立目標必須要是

(1) 有非常清楚的結果。如果目標是「熟悉java」，則最後有沒有達到此目標是非常模糊的，但是目標是開發android APP並且上架，就表示必須要寫java到某個程度才行(註3)。

(2) 可以在6個月之內達到。不要設定一個花10年才會達到的目標。如果真的有長期目標，當然可以設定長期目標，但是需要伴隨可以逐步前進的短期目標。例如，或許你想要成為java大師中的大師，這可能要花上數年，但必定可以有個6個月能達到的前期階段，例如：「不靠任何補習方式，就取得SCJP」

(3) 其結果會伴隨建立事實。請參考下一段

建立事實

在畢業前六個月，是最適合建立「事實」的時候。

建立事實，和畢業前花時間美化履歷表有很大的不同。

美化履歷表，是可以靠一兩個禮拜，找一些專業人士協助就可以很輕易的達到。但如果自己的「事實」不夠充分，再怎麼美化也沒有意義。

前一段關於短中期目標，只要你的短中期目標定義夠清晰。這些就是你要建立的事實。

如果你是在未來6個月即將畢業的學生，對自己的技術能力非常沒有自信，然而又想從事軟體工程師的工作，可以考慮建立以下三個事實：

* 透過自己決定的開發專案(例如Android APP)，徹底實踐品質管理(QA) 

     (a) 找一個不用錢的QT工具：可以參考這裡。
     (b) 在開發專案的過程中，徹底運用此工具，確保自己的專案品質。
     (c) 將結果詳盡記錄，就成為自己能當QA的事實

* 透過自己決定的開發專案(例如Android APP)，徹底理解並且妥善運用git(或任何版本控制工具)

      (a) 版本控制是軟體專案的基礎中的基礎

      (b) 需要徹底了解如何branch，如何merge，如何處理conflict

      (c) 其結果構成了解專案開發的基礎事實

* 取得Scrum Master證照

     (a) 參考這裡
     (b) 雖然大部分的管理類型的證照意義都不大，但是取得成本不高的情況下，展現了你至少是瞭解Scrum。

---

註1: 想要自行創業的準備不太一樣，首先要了解創業如何必然成功，再參考其他相關資料。

註2: 花大錢考管理類型證照其實不划算，但是可以考慮花小錢，請參考這裡。

註3: 對，我們知道React Native可以讓你不需要寫java，但是這裡只是舉例而已。

台灣博士生與大數據分析：如何評估對大數據分析的本職學能？

最近有個真實故事：

---

(為保護當事人，內容與細節均有所改變) 

台灣人F，目前就讀於某知名國立大學，已經是博士候選人。

最近為要爭取某一私立學校E的教職。在其履歷表上是以雲端計算大數據專家自稱。而E校的某系評會要求他面試15分鐘，用以評估他的能力。試教主題不限。

然而，F其實對大數據除了看過一些商管叢書之外，其實根本一竅不通。因此，他找了以前大學時候已經在業界工作的好友J，問了一些「技術問題」如下：

F：我聽說過spark，是不是大數據分析都用它啊？spark是不是個作業系統？

J：如果這是你的問題，那你壓根離spark太遠。後面就不要再談了。

F：哎喔，我覺得教學只是個演出啦，看表面而已。以你在業界打滾多年，就幫我個忙。couchbase是什麼？有什麼如果講出來會讓大家知道我很厲害的地方？

J：如果這真的是你的問題，你真的什麼都不懂啊，就算你去E校當教授，也是害了別人。

F：....

---

這個真實故事乍看之下太過駭人！但或許反映了學術與實務之間的鴻溝。

其實，台灣有許多學術界的人才，不但學術淵博，技術根底也厚。從數十年前的硬體產業蓬勃發展就可見一般。近幾年的軟體也是，許多教授幫業界「產出」能產生價值的知識性員工，並且也讓業界的知識持續推進。

然而，M型社會反映的層面，不指是一般在職場工作的人，在學術界中也越趨嚴重。

也有不少學術蟑螂。他們靠著極致的生存能力和夠厚的臉皮，穿梭在三流研討會，大企業策略部門，顧問性質演講，以及不在乎學生品質的大學院校中。

這些學術蟑螂做的事情，大概也不會真正傷害到誰，只是，也不會對任何人有好處。只要不是在「自己家裡」，一般人在路上看到蟑螂只會視而不見，也不太會去追打。

但是，如果是在自己家裡呢？

評估對大數據的本職學能，才能判斷來者是學術淵博的長者，還是費力在夾縫生存的蟑螂。如果是像E校一樣，原本的教授群並沒有這方面的背景，要如何在沒有足夠的知識情況下，判斷對方有沒有知識？這雖然有點難，但是，透過一些方式還是可以把誤判機會降低。

(1) 實際經歷探詢（情境實例面試法）

情境實例面試法很基本，但是事先有所準備。做法很簡單，只詢問「過去實際上」發生的事情，用以判斷被面試者現在的情況。而且絕對不詢問開放性問題！！

對於couchbase而言，就不會問「你對couchbase瞭解程度如何」或者「分散式資料庫你有哪方面研究」。因為這類型開放性問題，會浪費大家的時間。也會讓學術蟑螂有機會以混淆視聽的長篇大論，大打模糊仗來損耗面試者的判斷精力。

簡單問題像是：

* 請用1分鐘定義何謂nosql

* nosql的實作有很多，請舉一個你最熟悉的nosql平台工具，一個你實際最常用，最熟悉的就好(在此假設他回答couchbase)。

* 請問你實際接觸couchbase多久了？  (用判斷他最熟悉的工具有可能有多熟，如果少於6個月大概也等於是不太熟）

* 你利用couchbase為平台，撰寫並發表過哪篇論文？(學術界而言，沒有發表相關論文等於是沒有相關方面的研究）

稍微麻煩的問題像是：

* 你有沒有加入couchbase的任何相關的mail-list? (沒有加入mail list也沒關係，但表示其實只是單純的使用者，不會有太多深入的了解)

* 你利用couchbase為平台，撰寫並發表過哪篇論文中，所使用的研究資料量有多大？100G？10T？（資料量極小的nosql，並不代表不正確，只是代表不是大數據而已）

* 你用過哪些版本的couchbase（起碼要記得大版本編號吧）

* 你最近讀了哪一篇論文是以couchbase實作其研究？是大概什麼時候讀的，內容是什麼？


總之，事先準備好不能模稜兩可的問題，並且也定義好不能模稜兩可的期望回答。事先準備的問題也不需要太多，只要7-10提及可。這樣，比較不容易被蟑螂溜進來。並且，在準備的過程中，其實也會讓團隊（無論是學術還是技術團隊）對這方面的知識有基本的增長。

(2) 真實展示

簡單的說，就是請他拿一台電腦，展示一下他對大數據分析中最會「做」的事情。無論是撰寫程式碼，還是建立模型都可以。

真實展示其實很容易騙得過沒有相關知識的人。但是，如果事先已經提醒會有真實展示，可以簡單篩選掉連打開電腦都不敢的小蟑螂。

E校要求試教15分鐘，其實是真實展示的好方法。然而，盡可能展示「動手」而不僅只是「動口」。雖然君子動口不動手，但是蟑螂恐怕也是。

(3) 自我反省

當在一個地方看到蟑螂的時候，通常表示附近還有另外10隻蟑螂(也有人說是數百隻)，只是沒看到而已。會有蟑螂來面試 - 無論是工作還是教職 - 是不是這組織已經有很多蟑螂。更重要的是，自己是不是其中一部分。

自我反省是極端困難的工作，對生活優越的自己，在心理上也不見得好過。但是，在陰暗狹小的地方求生存，總是比不上光明正大的貢獻自己的能力。

請謹記，「自信心」和「自我感覺良好」只有一線之隔。或許，透過實際經驗探詢，先自我檢查自己，才是去評估別人之前，真正自己應該做的事。

數據分析從零開始 - (2)資料取得和前處理

既然要分析資料數據，自然要有資料數據才能分析。資料取得是必要的事情。

資料來源有很多種，取得並且事後處理的難易度各有不同。

但可以確定的是基本情況是：

1. 資料的時間，會遠超過自己的想像

2. 在開始進行分析之前，資料整理的所花的時間精力，也會遠超過自己的想像

3. 資料整理，幾乎不可避免

4. 資料整理，沒有捷徑也沒有神奇的密技，只能靠不懈怠的努力耐心以及經驗

5. 實際上有創意，有價值的數據分析，都不能免除資料取得和整理。 

第一手資料：

在「嚴格的一手資料」定義下，做資料分析的人真的拿到一手資料的機會極端的少。不過如果你是購物網站的大老闆，則購物網站上產生的營運資料，web server的log等等，對你而言就是第一手資料。

實務上最常看到的第一手資料，應該就是網頁存取日誌(web log)。在2016年網頁伺服器市場上，apache加上nginx仍然佔了半數以上，其他的網頁伺服器種類雖然也不罕見，但網頁的log格式反倒似乎都很統一，因此，以網頁存取來說，資料取得跟分析都已經存在既有的工具。剩下就看規模和個人技巧。

其他類型第一手資料就包山包海，以業務來說，發票檔案(invioce)當然是貨真價值的第一手資料。以軟體開發來說，git上所有的commit log也是第一手資料。

以現在軟硬體的成本之低，第一手資料原則上都可以盡量保持「原來的樣子」，頂多保存的時候壓縮而已，不太需要進行破壞性過濾處理。

要點一：使用shell 做基本的確認以及雜訊處理。

mac或linux可以用的基本文字處理的技術太多。伺服器的log最基本的處理方式，應該先用shell快速瞭解一下現況。

舉例來說：

以下指令可以把access.log中的第11欄，http response code列出來，並且簡單統計一下各return code的次數。

#cat access.log | awk '{print $11}' | sort | uniq -c

以上圖來說，結果就是有3個http return 400，有134個return 200，沒有任何500的回傳值。至於什麼是http return code，請參考w3規範。

要點二：用excel做最基本統計檢視

過去許多excel版本都有筆數的限制（最多六萬五千多筆），2013之後就放寬很多（大約一百萬筆），請參考官方網站。

即便有數量的上限，也非常值得資料中，先擷取樣本來試著分析。使用樞紐分析表，可以很快看到資料欄位彼此可能的關係，在未來進行分析時候是很有用的參考。

如果到現在你還不知道什麼是pivot-table(樞紐分析表)，那表示你根本不懂excel。  怎麼使用樞紐分析，請參考官方網站的說明。下一篇，我們會用政府公開資料簡單做個樞紐分析表。

要點三：以自動化的方式產生濃縮的摘要（二手資料）

只要能取得第一手資料，盡量使用自動化方式，自動產生有意義的濃縮摘要，這個摘要就算是二手資料。

當然，這要配合要點一的shell文字處理，例如以下指令：

#cat access.log | grep "GET /login" | awk '{print $6}' | cut -d ":" -f 1 | sort | uniq -c

這可以產生簡要報告，說明登入(login)頁面每天有多少人次來使用，執行結果如下圖：

這圖上的執行結果顯示，9/12有15個人次，而9/13有2個人次。

現存二手資料的資料

所謂二手資料當然就是不是直接產生資料的來源的資料。資料分析採用二手資料的機會非常高。

所有組織外部取得的資料，絕大部分都算是二手資料。因此在下一節中會特別說明外部資料的取得處理。

要點一：取得過程的紀錄，以及基本分析

無論資料是自己拿或者這別人給，都需要紀錄取得的過程。

舉例來說，如果IT「自動」會給你一份，wifi的使用者登入時間，以及最後封包產生時間，你就需要有方式「自動」記錄這個過程。

如果是外部網站，也應該要記錄當時取得的方式，假設是curl取得，則用了哪些參數，執行多少時間等等。

基本分析則和前一節相同，先用shell和excel對資料有基本理解。

要點二：正確性判斷

二手資料很可能不正確，或者，對資料的解釋不正確，會大幅影響資料的使用方式。

資料解釋不正確：舉例來說，只要有用過就知道，政府公開資料很多都宣稱編碼是utf-8，但實際根本就是Big5（例如 房地產實價登陸）。

資料不正確：二手資料取得的資料本身判斷正不正確很困難，特別是在大規模的資料收集下，很難簡單判斷正確與否。而且有些資料的正確性，可能連第一手資料來源都不能保證（例如天氣觀測）

但是可以透過「多面向」的方式來探究單一資料的正確性。簡單的說就是多找幾種資料來交叉比對。舉例來說，如果你的天氣資料來自不同的網站，如下兩個圖：

雖然這兩個圖在同一個時間點的氣溫還是差了兩度，不過起碼是一個合理的範圍，因此大致還能知道資料是合理。

要點三：自動化進行轉換格式以及二次儲存

二手資料無論是什麼格式，幾乎都會被轉移格式，或者合併，或者改換儲存媒介。例如csv檔案，常常就被改為json格式並且存進nosql中。

但重點是要「自動化」進行。雖然格式轉換或者改變儲存的形式，幾乎都有現成的工具可供匯入匯出，但是只要太多「人為手動操作」，都會讓資料處理越來越花時間，越來越難保證整個流程的品質。

外部取得資料

<<TBD>> ...請見下一篇

企業巫醫 - MBA無用矣

企業巫醫The Witch Doctors（中譯本為商周出版）是一本距今十一年的老書，但書中對於盛行於商業界的企業管理顧問的見解卻始終精闢。這本書的標題雖然聳動，但內容卻是不只是流於隨想批判，而是踏實的先提出數據，做橫跨時間與空間的研究，最後提出見解。破解在招搖撞騙的「大師」形象。

作者對「大師」的批評相當有建設性，幾乎在1990~2000年間的企管大師，都被他非常精闢而有建設性的評語跟分析過他們所提出的方法論：彼得杜拉克，麥可波特，愛德華戴明等等。而史蒂芬柯维，吉姆柯林斯則是被他列在不入流的範圍。


組織與企業經營的是合併藝術與專業的範圍，在因果模型中屬於複雜的範圍（參考這裡）。換言之，企業的大大小小的決策，與是否能達到效果，很難在事前看出，只能事後瞭解其因果關係。而有趣的，具有戲劇性的論點，逐漸就取代了嚴謹的研究。這讓迷惑於複雜邏輯的人，有了某種追尋的方向，從這個角度來看，「真正」的企管大師也知道這種現象，但他們一方面提出淺顯易懂的見解，另一方面也持續進行研究，這也讓大師的研究結果可供大家參考與學習。

「企業巫醫」則利用根本沒有人可能了解其因果關係，讓自己以有趣的方式解釋因果關係，從而謀利 - 開設顧問公司，提供考取證照方式，提供分析報告，寫書，演講等等。

萬一，自己解釋的因果關係沒發生，當然會拿另一套關係來彌補。就像在原始叢林部落裡的醫生一樣，當有疾病-例如嚴重流感時，會先說明和惡靈的關係，接下來可能拿某些植物的葉片猛力槌打你，打的你又痛又麻的時候叫你回家躺幾天。如果好了，證實的確是惡靈的問題，如果因此病情加重，併發肺炎，表示這樣的懲罰惡靈仍然不滿意，則會換一套方式，直到你痊癒或者死亡 - 當然死亡就表示惡靈趕不走(此段說明彷自企業巫醫一書)

在企管書籍，個人認為最最最有名的巫醫例子應當屬於「從A到A+」。用google搜尋「從A到A+」可以找到非常多人閱讀記錄，甚且有精闢的閱讀心得。該本書所說「嚴謹的長期觀察和研究取得」，分析好公司和「卓越」公司的差別，並且這些從數百家篩選出來的好公司中再篩選的卓越公司，肯定可以「永續經營」？

但是實際上根本不然。

2005年的研究就顯示A+公司，在1996-2005年間，就已經不太算是A+。不到幾年後：11家卓越公司倒了2家，9家之中僅有1家沒受到太大的金融海嘯影響。其中8家在2008危機期間甚至績效平均比其他SP500的公司還差。

從結果來看，從A到A+的理論根本沒用，但是，如同企業巫醫，作者後來竟然還寫了一本「為何A+巨人會倒下」用以自圓其說。非常典型的巫醫行為。

相對於企業巫醫，MBA的價值是否真正有用也很難說。某些研究都顯示，擁有MBA學位的CEO和沒有MBA的CEO在公司經營的成效上，沒有差異（參見這裡）。

然而，某調查顯示，擁有MBA學歷似乎對薪資有幫助(參見這裡），就這個角度來看，擁有MBA似乎還是有用的。但如果仔細看過這類調查，很明顯排除了MBA低薪，以及MBA本身的成本。

反倒已經有百年歷史的最最著名MBA產地的期刊 - 哈佛管理評論的一篇高學歷管理者的迷思。誠懇的點出問題：管理學位取得者，在學習過程中沒有學到真正學到務實的作法，而只是為了取得學位。開始工作之後，如果又沒透過工作經驗，學到新的技能，當然就沒用。

如果沒能對複雜的問題，保持清澄的理智，分析可能的問題，簡化並反覆查證因果關係，踏實的從不同的角度看問題，MBA的學歷可能會創造出一個一個的企業小巫醫，在組織裡三不五時的拿一些最新的企管叢書，當做驅趕惡靈的樹枝，到處鞭打真正在做事情的人。


企業巫醫相關文章：

如何拒絕或調整客戶不合理的需求 

實習生的三贏

時間乃最終之敵人? (上) 

時間乃最終之敵人? (下）

剛畢業準備加入開發團隊 - 三個必要的Scrum突圍方式

真實故事 1:

某個陰暗的冬天早上，悠晃進辦公室的當下，看到二十多個人圍成一個大圓圈。既不可能是營火晚會團康，也不會是祈福默禱活動。好奇的在旁邊觀察一下，在圈圈邊上的某個中年男子開始要求大家在這個stand-up會議報告進度，並祈許新採用的Scrum方法可以讓軟體開發有良好的發展。

真實故事 2:

某一次專案研討會中，演講者詢問與會人士，Scrum估計工時的時候，每個人每個工作天應該是多少小時才合理？新鮮人多半回答6-8小時。某些資管企管碩士生，大概讀了許多書，回答:「4小時」。而一個在軟體外包廠商工作的專案經理回答:「10小時」。

Scrum是最近幾年很流行的Agile(敏捷)開發方法之一。它的概念照理說簡單易懂，很容易在現有的團隊中採用運作，或許是因為趕流行？許多資訊產業開始以採用Scrum方法為榮。而各類型顧問也都開始教授Scrum，也開始頒發各種結業證書甚至Scrum Master的執照。就在短短數年之內，在台灣業界Scrum似乎無所不在，成功案例一個比一個容易找到。

但是就像其他簡單易懂的事情一樣。Scrum說起來比做起來簡單。實際實施的時候需要克服慣性與人性，克服與目標之間的各種障礙。但也因此，把握住Scrum的精神，最能夠讓畢業的學生以正確的方式加入軟體開發團隊 - 即便這個團隊此時並未實施Scrum。

追本朔源後，總是可以看出：太陽底下始終沒有新鮮事。Scrum最早正式出現在1986年的一篇文章中(Scrum最早的文獻)：透過個案的深入觀察，兩位日本學者對於有彈性，有效率的產品開發過程中發現一些相似的點：內建的不穩定性，自我組織的團段，互相重疊的開發流程，多面向學習，精微的控制，組織裡習得經驗的轉移..等等。文獻中的產品大部份都是硬體，例如汽車或者影印機。

乍看之下，和現在的軟體開發方法論似乎沒直接關係，但是，而後在經過其他學者的後續觀察歸納。這種以事實為基礎的彈性結構，遠比傳統官僚結構，更能在短時間達成高效率，甚且更容易產生創造性思考的價值。

理論歸理論，如何實踐理論在工作上才是重點。

近年來畢業的資訊科技背景的學生，的確在學校多少聽過Scrum，許多資管的學生甚至上了不少相關的課程。但就實務的角度，除非教授像這位荷蘭的老師（eduScrum）一樣，真心誠意的採用Scrum在課程的本身上，否則對剛畢業的碩士生或大學生而言，Scrum就只是個似乎看的到，卻無法做得到的事情。學界與業界間的藩籬，仍然巨大看似難以突破。

因此，提供以下有三個務實的方式，可以作為剛畢業的學生突破藩籬的參考。

1.理解事實

對於剛畢業的學生來說，理解事實，是基礎中的基礎，但也確是整個職業生涯需要不斷強化的地方。

以Scrum而言，每一個要做的事情 - 也許稱之為一項backlog - 在正在執行人的手上只有三種狀態：「還沒開始」，「進行中」，「已經完成」。

在每日stand-up，最常發生的是產生另一個狀態「快要完成」，也有可能混淆「已經完成」和「進行中」，更糟的是混淆「還沒開始」與「進行中」。

舉例來說，小馮在每日stand-up會議說：「訂單查詢功能已經差不多了，因為訂單查詢結果的排序雖然弄好了，可是分頁還有點問題，但是快要好了」。也許在學校裡和指導教授報告論文進度這種描述是可接受的。但是在Scrum的精神裡，這種描述不但沒有必要，而且會引發更多問題，因為，接下來大家就需要探究所謂快要好了，是還要多久？最簡單正確的描述應該是「訂單查詢功能正在進行中，原本預計2天完成，已經花了1天，接下來1天會繼續完成，目前估計和預估所需時間一樣是兩天」

重點並不在於咬文嚼字，而是在於對事情的清楚認知。當意識到一件事情沒有完成，在產品開發裡，終究是沒有完成。

每個人多少都有報喜不報憂的心態，也多少都希望別人對自己有好印象。因此，常會有自己也欺騙自己的時候。Scrum的每日Stand-up站立會議，僅說明三件事情：1. 從上次會議到現在完成了什麼 2. 在下次會議之前打算完成什麼 3.有遇到什麼困難。僅只三件事情而已，不多不少。

剛加入任何形式的開發團隊的人，能先確切的掌握和自己相關的事實，是看似簡單卻需要時間實現的基礎。

2.控制時間

既然Scrum是屬於Agile的方法論之一，當然符合最早的Agile 12項基本精神（參見這裡）。其中幾個精神和時間有莫大關係，例如，可用的軟體大重於詳細的文件，回應變化重於遵循計畫。而Scrum是最能達到的方式。

以團隊的角度，burndown chart(燃盡圖)是最能表達團隊目前能力，與專案時間預估的方式。他的做法極端簡單，請自行參考wiki。burndown chart展示了血淋淋的事實，可以透過過去一段時間的完成速度，有效預估專案可能的完成時間。由於這種做法去除了人類心態上的偏誤（例如：大家再努力一下，接下來某東西可能比較簡單...諸如此類），因此在沒有能力，沒有創意，沒有實務開發經驗的產品或專案經理的眼中，burndown chart只是拿來參考用，不能給長官看到。

以剛畢業的學生而言，最難的事情在於預估時間，特別是在比較長期複雜的任務。


解決方式為兩步驟：
  (I) 決定第一件要做的事情並且去做 
  (II) 額外增加研究項目(也額外增加時間)

(I) 決定第一件要做的事情並且去做  

對於很長的項目(backlog)，表示他可能隱含數個子項目，而每個子項目可能也不小。例如，讓系統可以支援facebook帳號登入。這可能就要分成數個項目。當然對於新鮮人，分拆項目可能會遺漏，但是，有分拆比沒分拆好，有估計比沒估計好。有分拆之後，如果有漏列項目，也可以清楚知道有漏列。有估計之後，估計的錯誤以後還可以作為其他項目的參考。
而分拆之後，就直接進行第一件要做的事情！確實的腳踏實地去做！不用等，也不用試著把項目分拆的很精細，估計得很詳盡。因為萬事起頭難，當已經開始進行，就很容易知道之前想法是不是正確，還有沒有遺漏。關於項目的分拆(breakdown)可以參考這篇。

(II) 額外增加研究項目

如果分拆之後，很明顯的仍然難以著手，就額外列出一個有限定時間的研究項目在最前面。換言之，花個固定的4到12小時進行學習與研究，將這件事情也列入整個開發流程中。時間必定要是有限的，畢竟絕大部份的產品開發，無論多困難，都還是在有限時間一定可以找到解決方案。

從另外一個角度而言，如果在有限時間無法找到合理的解決方式，對新鮮人而言或許你也並不適合做這個行業，可預見的未來裡，或許你會勤能補拙，試圖用更長的工作期間達到成效。但是這並沒有太大的意義。因為你並不拙，只是專長不在此，在有限的時間投入內，了解自己的專長不在此，或許更能幫助新鮮人找到最能讓自己發揮專長的地方。

3.確保產出

每個backlog表示一項「產出」。只要前兩個精神：理解事實跟控制時間，已經有效掌握，那麼這一項應該不會有太大意外。然而，對於剛畢業的學生來說，無論程式能力有多強，對於產出的完整性，常常會有誤解。不過這樣的誤解其實也很容易釐清。

一般軟體開發團隊，某人的某功能程式碼寫完之後，會經過以下階段：

1. 程式碼完成
2. Unit Test完成並通過
3. 簽入版本控制系統(commit)
4. 通過code review會議
5. 合併到產品主線
6. 通過自動化編譯建構
7. 通過自動化整合測試
8. 通過QA測試
9. 經過產品經理(Product Manager)確認

在Scrum一開始，便應該定義何謂backlog完成？
- 會是 1.程式碼完成就算完成？
- 還是 6. 通過自動化編譯建構 才算？
- 甚且是要等 9. 經過產品經理確認 才算？

有許多開發團隊，產出的本身是透過「默契」來達成。然而就新鮮人而言，一開始一定比較難取得「默契」。開口詢問，並且在三確定產出的「要件」是剛畢業的學生常忽略的要點。

參考閱讀-> 如何快速充實自己

80/20法則之軟體專案的三個運用重點

軟體專案的Scrum的一次sprint之後，照例的檢討會議(retrospective)中，張經理收集了成員的意見，經過投票整理與排序，發現"不夠專注在重點上"是成員們最希望改善的地方。於是，張經理發表他的見解：「看起來大家可能是覺得瑣碎的事情太多，沒辦法專注於工作，這次新的sprint開始，大家試著把心思專注在重要的事情上」，接下來，張經理開始順道交代其他事情：「呃，上次要給法務部門的3rd party版權清單，老馮你準備一下；明天我們要定個下午茶，小陳你有空的時候幫個忙...」。....於是乎，最希望改善的地方就從未改善過。


Pareto Principle，又稱為80/20法則，指的是80%的結果來自20%的原因。這個法則是取名字義大利的經濟學家帕雷托。他觀察到1906年義大利的80%總資產屬於20%的人口。而此一情況被學者們，在其他領域也觀察到重複類似情形，因此被簡約成此法則。

80/20法則中的數字，有時候，會和實際領域不同而有所改變。例如，絕大部份的軟體，其90%的執行期間，執行的是其中10%的程式碼(參見這裡)。


在軟體專案管理中，能掌握80/20法則，等於是掌握80%的成功。

以程式撰寫為例：最重要的10%程式碼，關係到軟體運作的90%時間，掌握最重要的10%的效率與品質，就掌握系統的本身。當然，80%的bug來自於20%的程式碼。（參考這裡）

以測試為例：1000個測試案例(test case)如果能有效掌握哪20%的測試案例可以測出80%的潛在問題(bug)，就可以有效縮小測試。

以人員管理為例：在有一定人數的情況下，30%的程式設計師完成70%的主要功能。而有追蹤問題(bug)的來源時，80%的問題來自20%的模組撰寫者。


因此，掌握並改善20%重點，是任何專案的成功關鍵因素。

不過，這件事情知易行難。以反面來看，作為專案管理人，如果整個專案過程的每天都忙得焦頭爛額，隨時都有不同的人來進行不同的會議，螢幕旁邊有數十張待辦的便利貼。這很明顯的表示你一定沒有掌握到20%的重點，而你雖然很努力的想要完成任務，但並沒有朝向正確的努力方向。更慘的是，假如你認為這種忙碌可以顯示自己在組織的價值與貢獻，這種想法做為專案的領導者只會害死大家。


每個專案都是獨一無二，因此每個專案的重點20%都有所不同。然而，掌握關鍵的「20%」倒是有三個共同切入點。

1. 目的 - 真正目的

軟體專案的真正目的各有不同：有些是新產品開發，有些是既有產品增加新功能，有些是客製化專案。大部份的情況下，其目的通常不是「技術目標」，而是「達成效果」。

例如，網路商店需要開發mobile app，其目的鐵定不是為了要有一個Android APP或是iOS APP，而可能是要讓客戶在智慧型手機上也能購物。但也有有可能目的是要讓客戶在智慧型手機上容易查詢訂單。當然也有可能兩者兼具。但無論如何，技術目標：也就是有Android/iOS APP，與達成效果通常有相關，但專案管理者必須清楚兩者的不同：

達成效果是勢在必行不可或缺，但技術目標永遠都有其他選項。

網路商店不見得需要有APP才能讓使用者在智慧型手機上購物，可以使用符合智慧型手機規格的網站(所謂的響應式設計)，讓使用者利用手機瀏覽器進行購物，也可以透過簡訊或者撥打電話的方式購物，開發APP只是其中一個選項而已。

掌握真正目標之後，列出這個目標中的所有使用情境(user story)中最重要的20~40%的功能，而軟體開發的重點就放在這20~40%重要功能。集中力量完成最重要的20%，才不會「先」耗費力氣在無謂的事情上，「最後」才做真正重要的事情。

2. 時間 - 不倒退的沈默成本

時間是不會倒退的（參考這裡）。軟體專案裡的時間成本一旦投入，都屬於不會退還的沈默成本。也因為時間無法退回，一旦投入就是投入。因此，必須要確定「先」運用時間在重要的事情上。

80/20法則的重點在於：計劃先運用「未來的時間」，在有效果的事情上以先達到80%的產出。

舉例來說，一個程式設計師，在早上抵達辦公室，打開電腦的第一件事情，應該試圖確認「今天什麼事情對我最重要」，而一個開發團隊，每天第一件事情應該是「今天團隊完成什麼事情最重要」。因此，典型的scrum都會在一早展開standup meeting(快速會議)，以15分鐘的簡單開場讓專案團隊確保先投入在最需要進行的事情。

這也是一個聽起來簡單，執行起來並不容易的概念。有很多情況，團隊成員並未「徹底」實踐快速會議時的精神。

例如：某甲陳述：今天會開始開發模組A，預計今天會完成，而這也是他今天最重要的事情。然而某甲可能無意識地忽略掉昨天他的功能B的程式碼尚未簽入版本控制系統，因此實際上會議結束，其實他花了一早上在簽入程式碼，並且執行合併/建構系統。某甲並非不應該完成昨天尚未完成的事情，而是他對於「未來即將使用的時間」沒有腳踏實地的認知。

80/20法則運用在專案的時間管理上，最重要的精神在於「腳踏實地」，並且「確實展現事實」-- 缺乏這兩者，會讓80/20法則淪為壓榨程式設計師的幫兇。

3. 激勵因素與保健因素

激勵保健理論(參考這裡)，將影響人工作時心裡的滿意度因素分為兩類：激勵因素與保健因素。簡單的說，保健因素是「沒有會死，但是有也不會很高興的因素」，激勵因素是指「沒有的話不會怎樣，但有的話會很高興」。

激勵與保健理論，乃是在軟體專案管理中，80/20法則運用的最容易忽略的一環。特別是在兩個面向上：(a)軟體團隊經營
(b) 技術決策

(a)軟體團隊經營：

保健因素(薪水，電腦設備，工作環境)：無論加碼到什麼程度，對程式設計師的績效成長極端有限，然而一旦失去基本下限 - 例如減薪，則其他的激勵方式會突然失效。軟體專案負責人，應該在一開始，就先確保：保健因素是成員可以接受的。爾後專案執行過程，不要特別關注它即可。

激勵因素(個人成長，價值觀，成就感)：激勵因素才是大部份軟體開發專案成員「願意保持工作熱誠」的真正原因。負責人或者領導者，應該將團隊經營的80%重點時間放在保持激勵因素。然而每個人的激勵因素皆有不同，因此了解團隊成員個別的「真正需求」，才是需要花時間的地方。

舉例來說，有些團隊成員可能會抱怨沒有雙螢幕，雙螢幕對於撰寫程式的確很重要，專案經理想辦法弄給他雙螢幕之後，千萬不要以為這樣就會讓他心甘情願賣命。雙螢幕只是保健因素，是必要取得，但不是重點。專案領導者在團隊經營上，應該花20%的時間快速搞定保健因素，而後，花80%的時間確保激勵因素的存在。

缺乏激勵因素的團隊成員，並不代表一定會離職，也不一定代表任務不能完成。一個能力很強的人，可能因為暫時沒有其他選項而在現在的位子上滿足最低限度貢獻。這樣成員，反而成為一個潛在的問題，他隨時有可能因為任何短暫膚淺的因素而離開，更糟的是不離開而成為團隊困擾。而這種情況並非是該團隊成員的問題，而是團隊領導者，沒有辦法找到並維持適合的激勵因素。

(b)技術決策：

既然是軟體開發專案，必然會歷經各種技術決策。80/20法則一定是技術決策的主要運用重點。

以功能而言，如果有A功能與B功能在短時間之內，只能選擇完成一個。則技術決策應該從幾個方向考量：

方向一：中大型軟體專案一定有20%的重要功能，會滿足80%的使用者需求。哪一個功能屬於這類。

方向二：如果A與B都滿足方向一，則考慮哪一個功能會直接滿足「專案目的」。

方向三：如果A與B都滿足方向一與二，則考慮兩者哪一個對於此專案是屬於保健功能(沒有會死的功能)，哪一個屬於激勵功能(有的話會很高興的功能)。並且考慮專案目的，是屬於維護且保守的專案，還是開創性的新專案。開創性的專案自然優先考慮激勵功能；而維護型或保守的專案，當然要先考慮保健功能。



80/20法則的有效運用是判斷一個優秀的專案領導人的條件。以反面例子而言：有很多15年以上專案管理經驗的所謂專案經理，他所有的經驗可能都在於無謂的忙碌與焦頭爛額中度過，這樣的15年和1年沒有什麼不同。如果你是這樣的專案經理，為了團隊好，或許應該考慮轉換適合的工作跑道。

軟體專案品質控制的三要點

老馮是軟體專案經理，在專案進行的某一天，被高層找去開會。高層：「最近雲端計算很火紅，你的專案既然是跟Cloud有關，看能不能早點完成」。老馮就問：「那可不可以auto-scaling的功能不做？」。高層：「沒有auto-scaling哪能算雲端計算平台，當然要做啦」。老馮就又不死心地說：「怎麼可能功能不減少又要早點完成？我們都已經是早9晚9在加班」而老馮心裡沒說的是，加班也絕對不是解決的方法。高層：「那就看你們的能力啦，不然我在多加3個人給你好了？」。老馮：「...」




專案管理過程中，品質是最容易忽略的項目。在狀況複雜的專案，品質常常是自動被犧牲的事情。在沒有良好控制的專案，品質是最容易被省略的事情。


品質Quality的定義其實有點複雜（參考這裡）。基本上，在軟體上，一個可接受的品質通常是指：功能如預期的正常運作，並且沒有不預期發生的壞事。

例如，一個手機購物程式，在你執行登入，往下捲動查看最近的商品目錄，點選商品，下單，這幾件事情都如預期的運作，就表示功能沒問題。從看到商品到購買，整個過程沒有讓你覺得很慢，那就算是沒有不預期發生的壞事。

又例如：當你點選商品之後，看到商品大的照片，接下來你就橫向擺放手機，照片因而旋轉之後，再轉回原來的正向，結果手機程式就當機直接跳出，這就表示功能有問題。當你點選商品到購買，整個過程讓你等得很心煩易燥，每個動作都要5秒鐘的等候，那就算是不預期發生的壞事。



軟體專業經理人，應該都知道一條鐵律：品質，範圍，成本，三者不可能兼具。

軟體專案的成本指的是：時間，人力，金錢或其他投入的資源。

軟體專案的範圍指的是：軟體的功能，規模，支援的硬體範圍等等，範圍修改自然就是功能增多或減少。


三者不可兼具，指的是要顧全某一項或者某兩項要素，就一定會犧牲另一項。例如：某APP可以支援google+ 以及facebook 帳號登入，後來因為時間(減少成本)考量，最後決定僅支援facebook登入。又例如，某APP原本可支援google+ 以及facebook帳號登入，後來又希望可以額外支援維博登入，這時候就決定花錢(增加成本)找外包廠商實作此功能。

軟體專案中，另一條鐵律是：試圖三者兼具者，會自動犧牲品質。例如：某APP可以支援google+以及facebook帳號登入，而後又想要支援維博帳號登入。專案經理想要在不增加成本，又不減少其他功能的情況下，又不增加實作時間。硬是要額外增加此功能的結果，必定是品質會自動犧牲。

不知道品質會自動犧牲的專案經理，必定不適合做軟體的專案管理者。

軟體專案品質控制有三個要點：

要點一：來源

品質的來源是整個開發過程，從一開始的計畫以及團隊組成，就已經決定了品質的一半。

一個簡單合理有效的計畫，可以控制改變，掌握進度事實。開發方法是不是採用Scrum並非最關鍵。重要的是，計劃中的開發方法是否簡單並合理的被團隊認知。

舉例來說，傳統SI常會有RFC，也就是需求變更的管理計畫。在開發過程中，如果有需求變更，基本應該是1.先填一份表格，2.在專案會議中與客戶討論，3.互相同意修改之後進行變更。換言之，有需求變更(RFC)管理的情況下，必定是前期的架構，設計細節，規格等等都先完成了，才會開始進行開發，因此，就不可能使用Scrum的開發方式。


假如團隊的組成是可以選擇的，那這件事情也是掌握品質的關鍵因素。

要點二：架構

在實作上，架構是另一個品質的主要關鍵因素。一個優良而且簡單的架構，比較有可能在多人而且複雜的開發情況下，獲取最容易達到的品質。

精煉的軟體架構設計表面上容易，實際上困難。架構的設計要素，眾所皆知：內聚力高，耦合力低，不同模組之間首重介面溝通。

然而，任何有3至5年工作經驗的程式設計師，都可以規劃出極為複雜的架構，普通並且沒有實務經驗專案經理，會容易「讚嘆」這種複雜的架構。這會在不久的未來讓品質很快降低。

實務上，只要沒特別的控制以及重構，正在運行的軟體的熵(entropy)值通常會隨著時間越來越高。同時也讓軟體品質越來越低，或要花很大的成本達到高品質。

要點三：創意

在品質控管中，創意是最被人所忽略。特別是在傳統的開發環境裡，負責品質的相關專業人員通常傾向於「找到問題」，事實上，這的確是QT或者QC的主要責任，但軟體專案中，作為QA(Quality Assurance)扮演的任務就不僅如此，而是在整個開發過程中確保品質符合規格（註一）。

而有創意的QA是第三個重要的品質來源。

普通的QA會執行QT/QC的任務，在開發過程中參與設計討論，並且撰寫測試案例(test case)。在功能完成之後，會認真執行測試案例，或者撰寫測試程式碼以便自動化測試，而在過程中找到並且記錄問題，並督促程式設計師修正錯誤。以上這些都很好，而且也沒什麼不對。

但是！當時系統複雜，時間壓力大，程式設計師能力參差不齊等等困難情況發生時，普通的QA流程並不會對「範圍」以及「成本」有所幫助，因此很容易被壓縮或者犧牲。

有創意的QA會根據專案的情況，找出最好的解決之道。而非死命地抱著舊有的測試流程，在確定有問題的情況下還不進行改善。

創意的可能行動有很多，但總之就是要有「行動」。空想的創意是沒有意義的。有創意的QA行動，可分為技術類型和非技術類型：

技術類型

例如：透過pair-programming主動參與開發；除了自動化測試之外，撰寫當介面改變時的監視程式；對於程式設計師的commit做自動化分析...這些都是透過QA的技術能力，提早發現可能的問題並提早解決。

非技術類型

例如：著重架構的精煉與簡化；改善測試流程；利用其他資源(例如業務人員)進行測試；改善code review的方式；簡化bug記錄以及追蹤方式...等等，這些都是透過ＱＡ的協調作業能力，縮短或減小品質差距。


簡而言之，絕大部份的軟體專案品質控制，其實是需要有創意的QA，才能突破既有限制，創造更多價值。而QA要有創意也並不困難，只要願意嘗試，通常都有很好的效果。


參考：沒有QA？如何確保軟體開發品質

註一：ISO對於QA的定義："part of quality management focused on providing confidence that quality requirements will be fulfilled"

你真的知道專案進度嗎？

只要是從事程設式設計相關工作的人，必然曾經參與某專案(Project)。專案的大小不一而足，有些只有幾天或幾週，有些橫跨數年。

如果有幸負責專案管理，則無論規模大小，掌握進度是除了管理利害關係人期望之外的第二重要的事情！！而實際上，要管理利害關係人期望的最好方式就是能有效掌握真實進度。

「掌握進度」之後，才能調整應變可能發生的意外，降低風險。


只要看軟體專案進度的「掌握方式」，就大致可以判斷一個專案經理的「本職學能」到什麼程度。

一個好的專案經理，可以單靠自己，就能足以掌握專案進度。

一個普通的專案經理，可以利用流程，規範，加上開發成員的協助在一個合理的時間範圍內，掌握專案進度。

一個很爛的專案經理，會利用各種會議，各種形式文件的填寫(WBS之類)，直接或者間接的資訊，花很多時間，仍然不能掌握專案真實的進度。


很遺憾的是，好的專案經理很少，好的軟體專案經理，更是極端的少。因為他同時需要具備技術能力，透悉問題的能力，以及有效的專案管理能力。

要點一：以時間為單位

非軟體專案管理上，掌握進度的單位有很多種，例如「以執行預算」或者「實獲值」來掌握進度。（請參見PMP相關網站)

以軟體專案而言，「時間」才是真正掌握進度的單位。

當詢問負責的程式設計師：「A功能進度如何？」，而他回答「只剩下UI整合，加上DB欄位定義調整，就快好了」。這樣的回答，對於掌握進度幾乎完全沒有意義。因為，該程式設計師可能在A功能花了1天，然而UI整合與DB欄位定義調整，可能還需要另外花上3天，換言之「就快好了」根本不是真的，基本上只完成了25%。但該程式設計師並不是故意要說謊，因為或許最難的就是那25%。

程式設計師若以困難度為考量，進度就像下圖，功能完成之後，就「快要好了」。

但如果以實際時間進度為考量，則如下圖，功能完成之後，只完成了25%。離「快要好了」有很大的距離。

大部份的軟體工程師，著重於困難度。這並非不正確，只是專案管理在掌握進度時，實質進度必然是以時間為考量單位。即便「這件事情很簡單」，也必須要考慮「簡單的事情還是要有人去做」。

要點二：產出的事實

直覺上，大部份的產出當然是程式碼。實務上，非程式碼的產出許多時候會超過想像中的多 -  特別對於比較沒有專案管理經驗的人而言。

基本情況

最基本情境是，根據規格要完成功能A。一開始，程式設計師寫好了程式碼，並且自己編譯(compile)並簡單測試之後，簽入(commit)到版本控制系統中，並且和其他相關程式碼合併(merge)之後，整合成新的版本，並且新的版本經過QA測試後也沒問題。這個功能A就算完成。

在這個情境中，寫程式(coding)可能佔了70%的時間，另外merge以及測試可能佔了另外30%的時間。

專案經理要掌握的「事實點」在於：整合成新版本並經過QA測試後也沒問題，至此，功能A才算完成。

進階情況

在一個稍微複雜的專案裡面，根據規格要完成的某任務，實務上可分為「功能A」與「功能B」。一開始，幾個程式設計師分頭完成自己負責的功能，並分別自己compile並簡單測試之後，功能A與功能B就commit到版本控制系統的不同版本線(code line)。此時，QA分別進行測試，沒問題之後，協調某人「分別」合併功能A與功能B到主線(main line)並且整合成新版本。在整合過程，或多或少有需要修改的程式碼，也許在合併工能A的時候沒問題，但是在合併功能B的時候有出現問題，並也修正完畢。最後新的版本經過測試也沒問題。至此該任務才算完成。

專案經理要掌握的「事實點」在於，最後新版本經過測試也沒問題。至此，某任務才算完成。

但是，這和基本情況不同的是，整個過程很長，從數天到數週都有可能。coding本身可能僅佔50%。而合併，測試，在合併，修改等等可能佔了另外50%的時間。

與前述要點一相同，專案管理者要能掌握實際上的進展，跟「未來還需要花的時間」。在複雜的情況中要掌握，除了最後的產出事實之外，中間的進度掌握，需要靠專案管理人員對專案本身實務的了解。

專案進度的掌控，大部份是由專案經理個人獨立可以完成。其中，技術上的要素就是能否「判斷產出的事實」

而以軟體專案為例，專案管理者如要能判斷產出的事實，必須要能做「自己獨立」做下列幾件簡單的事：

1. 在版本控制系統中(git, p4, cvs等)，找出過去一段時間的所有commit過的程式碼變更，誰去變更，為什麼變更。

2. 在最近的新版本測試中，看到哪些新功能確實增加

3. 自行檢查目前bug的清單，並且找出幾個關鍵的bug



假如你是專案管理人員，而你不認為上述事情是自己應該獨立進行，或者你認為上述事情會花太多時間，


請參見下節：除去迷霧。

要點三：除去迷霧

許多「非技術背景」的專案管理人員，常常用各式各樣的大大小小的會議，來獲取專案進度的掌握：每天早上例行會議，每隔兩天來執行bug review，每個禮拜來討論整合進度...開會的本身並不會「加速」專案進行，過多的會議，肯定會「拖累」專案進度。

如果你是一位主管或專案經理，而你迫使專案成員每天花超過10%的時間(也就是40分鐘左右)在正式的會議上，並且只是為了呈報「目前進度」。那麼，你實在是個很糟糕的主管，要麻，你就盡快辭職，要麻，盡快提升自己的專案管理能力，否則你的存在只是浪費大家時間。

了解目前專案的進度，等於是除去迷霧，看清事實。除去迷霧的方式，必須要是「貼近事實」與「清晰的技術檢視」。

貼近事實

事實有時候很容易了解。例如：app要可利用facebook帳號登入。此功能容易判斷有完成，或者沒完成。

但有些時候事實很複雜。例如：某程式設計師宣稱，app要可以利用facebook帳號登入，他需要花12個工作天完成。12個工作天到底是長還是短？如果覺得太長，是因為寫程式的人能力不足？還是既有的app過於複雜，所以要加任何新功能都很難？


按部就班的貼近事實是讓該程式設計師先行「分解」這12個工作天。讓專案管理人員了解，他打算如何利用這12個工作天。

如果該程式設計師說「我這個是大概估計，12天就拿來做這一個功能阿，你還要我花時間去分哪天做什麼喔！我哪來這個時間」。這表示事實是，12天根本只是沒有基礎的猜測，他可能22天才完成，也可能2天完成。

絕大部分軟體專案，程式設計師的某行動完成都應該至少可以以「天」為最小單位，(也可是以「小時」為單位，不過太細的單位也會造成不必要的麻煩)。

超過2天估計，就應該可以分成「兩個以上的事情」，超過12天的估計，應該是建立在至少6個以上的某行動完成。


不能分解行動，表示沒有計畫，也對此任務沒有任何基本了解。

假設該程式設計師將app如何利用facebook帳號登入分解為以下工作：

(1) 修改UI: 3天
(2) 登入的程式碼: 7天

(3) 測試: 2天


專案經理應該要能看出，這樣的WBS其實完全是在應付專案經理，對貼近事實沒有幫助。他等同是一樣沒有了解任務。

如果無法將此任務交給別人，專案經理應該參與「計畫」與「分解」的過程。和程式設計師一起坐在某台電腦前面，將android studio打開，了解登入在哪邊加icon，如何到facebook取得App ID，facebook sdk如何使用。

對於有技術領導背景的專案經理，頂多花上一小時，就應該至少可以分解此任務如下：

(1) 到facebook developer網站了解sdk：1天
(2) 申請App ID以及了解相關規定：0.5 天
(3) 登入Icon要和美工討論實作方式：0.5天
(4) 執行登入，取得session：1天
(5) facebook帳號與其他帳號在db處理的不同：2天
(6) 與QA討論測試方式：1天
(7) QA測試：1.5天
(8) 其餘模糊規格的討論，例如是否可登出：0.5天

加總起來可能僅需要8天。但重點不再於天數減少，重點在於此計畫已經破除進度迷霧。當這個計畫開始執行，到了第三天，如果該程式設計師已經開始撰寫登入程式，那麼表示進度和預測相同，但如果他還在申請App ID，表示進度落後，專案經理需要調整進度，或找人幫忙。但無論如何，絕對在計畫開始執行的前期就已經知道如何處理問題，而不是到12天之後，突然發現根本無法完成。


(Android如何利用facebook帳號登入，請參考這裡)

清晰的技術檢視

前述的app利用facebook登入，專案經理之所以能和程式設計師一起坐下來定好比較清晰的時間，其首要條件在於具備清晰的技術檢視能力。

簡要的說，能區分技術難度，區分使用該技術對於專案的影響，以及，使用技術可能產生的風險。清晰的技術檢視能力，會有效提高對整個產品或者專案的洞察力。雖然，洞察力可以經過訓練磨練取得相關經驗，但實質培養卻需要有意識地進行。

技術檢視需要對技術的深度與廣度，每個專案經理所需要的技術能力各有不同，以下有個簡單的軟體專案經理自我問題清單，回答「是」就得1分。

低於5分表示是沒有技術檢視能力的專案經理。
高於8表示是罕見的擁有技術檢視能力的專案經理。

* [Yes/No] 你可以自己從版本控制系統中了解專案目前大致規模：(行數, 檔案數, 平均每工作日增加的程式碼數量)，無須依靠其他專案成員嗎？

* [Yes/No] 你可以自己找出哪些程式設計師的程式碼常常會出現bug，無須依靠其他專案成員嗎？

* [Yes/No] 你每一週會隨意抽出幾個程式碼簽入(check-in)看看有沒有明顯的問題，無須依靠其他專案成員嗎？

* [Yes/No] 你會手動編譯專案，無須依靠其他專案成員嗎？

* [Yes/No] 你隨時知道目前技術文件(程式碼註解, api 手冊, 使用手冊)撰寫的實際情況？

* [Yes/No] 你知道專案成員實際花在專案的時間

* [Yes/No] 當某個進度完成時，你可以自己檢查該進度是否真的完成，無須依靠其他專案成員。

* [Yes/No] 你會用專案開發的主要程式語言撰寫工具用程式（例如查閱系統log之類），無須依靠其他專案成員？

* [Yes/No] 你能自己估計團隊能力和團隊完成某模組的大概時程，無須依靠其他專案成員？

* [Yes/No] 你能單靠記憶，繪出目前專案個模組之間大概關係，無須依靠其他專案成員？

如何組成團隊：三個步驟

分工合作，是人類社會進步的主要原因之一，也是幾乎所有人類活動的基礎（參見國富論：第一篇第一章論分工）

新創公司，資訊產業也不例外，建立一個好的團隊，是擴展未來的主要關鍵。雖然好的團隊沒辦法保證生意蒸蒸日上，一切順心如意。但是一個糟糕的團隊，卻是可以保證企業和組織的失敗指日可待。


市面上團隊合作的企管叢書，方法論，激勵理論，顧問大師...很多。但就和所有的事情一樣，越是很多人在談論的事情，越是困難。成功的團隊真實例子極為罕見。

萬事起頭難，「組織並成立團隊」是達到成功團隊的第一要務。許多人常依賴運氣，或者隨遇而安的隨意組成團隊，但其實組織團隊是一種可以學習的艱深技術能力。

資訊相關工作的人，如果有機會能扮演組成團隊的角色，並有意識的學習其中，將會是個人成長的重要關鍵。（無論未來是朝純技術領導方向前進，抑或管理方向前進）


有很多原因，會讓一個人扮演組織團隊的角色。也許是一個新的專案，讓你來領導專案，而恰巧專案開始的時候沒有既定的人。也許你是新創企業的創始人，你打算聚集一些人來開發創新事業。也許你是資訊相關科系的學生，因為課程需要必須組織團隊完成專案。

不管如何，如果你有「從頭開始找人選人，組織團隊，完成某件事情的機會」，請衷心的痛哭流涕的感謝上帝，這樣的經驗，在資訊科技領域裡是十分難得。

通常，由於各種背景壓力，組成團隊的方式通常就是先根據需要N個人，然後「儘速」透過各種管道，找到可能的人選，經過正式面試，或者非正式的聊天，就逐一邀入加入此團隊。這種方式沒有不妥，只是這樣的方式（如果算是一種方式的話）有很大的成分依賴運氣。如果不想依賴運氣，其實需要考慮的實務步驟也不多。


以資訊相關工作為例，組成團隊必須要有以下三個步驟：

步驟一：定義目標

--- Your goal shouldn't be to buy players, your goal should be to buy wins. And in order to buy wins, you need to buy runs.   (MoneyBall)

定義目標，必須要在團隊開始組成之前，就先找到並且定義完成...最起碼是團隊差不多組成的時候就應該決定。

定義目標並不容易。

例如，以類似的資訊系統外包案而言，有些明顯的目標是「在成本內完成專案並驗收通過」或者「在期限內通過驗收」。但是，倘若一開始的合約是低價得標，而且還是業務亂搶合約，那麼一開始就已經知道不可能在時間成本內驗收通過。則團隊目標必須要轉換，例如「完成專案過程可順便完成重複利用的元件讓未來標案能大幅降低成本」。

大部分的資訊團隊真正的目標並非「技術達成」。例如，「完成iOS APP線上購物」這通常不是真正目標，真正目標通常是「在某移動通訊市場上，讓使用者可以線上購物」。

在營利企業裡，大部分的真正目標通常關聯到增加收入或者降低成本。而在非營利企業（例如研究單位）團隊的目標有可能非常模糊。例如，一個碩士班的實驗室團隊，他的目標可能是「培養人才」，也可能是「讓主持的教授獲得升遷的點數」。

定義目標雖然不容易，但掌握以下三點可以除去大部分的誤差：

(1) 定義目標後，審視檢查這個目標背後是否還有目標。例如，籃球比賽目標，某球員目標是得30分。但其背後還有個目標就是球隊要贏球。在球隊沒贏球的情況下得30分可能沒有意義。

(2) 定義目標後，檢視此目標是否只是某個大目標的一小部分。例如，某些NBA的球隊，會談論是進入季後賽的目標，然而背後的大目標其實應該是拿到總冠軍 - 無論有多艱難。

(3) 定義目標後，檢視此目標是否因為其他條件未達成就失去意義？這時候所謂「其他條件」或許可能是目標。例如，一個團隊負責營運線上購物網站，其目標是「網站每分鐘必須可以提供10萬個使用者同時進行交易，7x24服務不中斷不當機」。然而，若此線上交易網站平均上線交易人數每分鐘才1人，即便營運團隊達到技術目標，商業目標肯定無法達成，則此團隊目標也沒有太大意義。不如改成「與業務團隊合作線上行銷活動，讓每分鐘平均交易人數成長XX%」

步驟二：組合優勢

--- The greatest improvement in the productive powers of labour, and the greater part of the skill, dexterity, and judgment with which it is any where directed, or applied, seem to have been the effects of the division of labour. - (Adam Smith)

無論用什麼方式找到團隊成員，資訊相關的團隊必然有分工，而分工必須要能讓成員發揮相對優勢。而每個相對優勢，都可以達到步驟一的目標之一。

構成團隊過程可能很多，但無非是找到某人，詢問意見，在某時間此人加入。然而，「加入之後做什麼」著重於考慮組合優勢。

台灣經濟學的入門書通常會用蓋木屋與磚屋的例子（參見這裡）簡單的說，組織團隊時，把成員的時間投入在相對優勢的工作上，可以達到1+1>2的效果。

實務上，分工時請考慮一下三點：

(1) 根據相對優勢來分工：盡量只考慮優勢，而不是先考慮缺點。

(2) 分工的結果，還是必須朝「真正目標」前進

(3) 整個團隊需要了解分工與分派任務的原因 

步驟三：產生運轉動能

--- All things are difficult before they are easy.


團隊組織完成，要開始運作，不會像籃球比賽一樣，十個人在場上，裁判吹哨跳球就開始。

團隊前進需要累積動能。就像騎腳踏車一樣，從靜止到穩定前進，會花比較多力氣，然而一旦穩定前進，就很輕鬆。

產生動能指的是團隊成員已經彼此合作，彼此鏈結工作，發生問題也可以彼此協調解決。

以資訊科技為例：

最常見也是最糟糕的產生動能方法是由專案經理透過一連串的方式 - 通常就是開會 - 持續讓事情前進。團隊成員花在正式會議上的時間比例只要超過10%(也就是每週超過4小時)就屬於這種類型。


最佳，但是最罕見的產生動能的方式是由每個團隊成員，透過自身的判斷，做會讓事情前進的動作。類似足球或者美式足球的比賽。在資訊科技團隊中，這種組合需要時間磨合成員，而且也須一點點運氣，讓團隊的成員大部分的能力都可以足以某種程度的獨當一面。

如果你剛好是資訊科技/軟體開發的團隊領導者，至少要先避免最差方式，並且透過你的領導能力，讓團隊慢慢的朝向最佳的方式前進。

實務上有三個重點方式：

(1) 資訊透明：讓所有進行的事情透明的讓所有人取得。要注意，資訊透明指的是針對確定的事實透明。非確定的事實就是所謂謠言，要緊記：謠言止於智者，起於智障！

(2) Scrum中的豬雞原則：請參考這裡。在組織產生動能過程，豬負責的事情就由豬來決定，雞只是提供參考意見。

(3) 檢討 retrospective：需要團隊自我檢討任何不正確或可以強化的地方，檢討並非開批鬥大會，目的在於讓團隊能更有效率的，以及確保團隊真的朝向目標前進。