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

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

在這世界裡，「在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] 你能單靠記憶，繪出目前專案個模組之間大概關係，無須依靠其他專案成員？