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

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

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

為什麼需要強調在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，但是這裡只是舉例而已。

企業巫醫 - 誰掌握你的升遷？

只有自己掌握了自己的命運。沒有別人。(註1)

升遷也不例外。只有自己掌握自己的升遷，沒有別人。

大部分無法獲得升遷的理由，都只是自己的藉口而已。常見藉口(註2)如下：

- 自己的努力沒被別人及主管看到
- 受到主管不公平的對待
- 主管不賞識甚至打壓
- 組織內制度有很多問題
- 負責的工作實在太艱難資源又少
- 負責的工作實在太簡單沒有挑戰性
- 景氣不好公司不賺錢就罷了，還在裁員
- 比我資深的還很多，很難輪到我


在大組織裡，個人升遷(promotion)仍然是職業生涯重要考量。因而，企業巫醫們的一些闡釋也頗有道理，例如這篇，或者這篇。但有些過於偏激，而且會舉一些憑自己想像的例子。這類型的巫醫頗多，在google上搜尋"升遷"就可以找到不少。


那麼，自己要如何掌握自己的升遷？

超乎期待：做出超越目前工作職掌的成績

升遷指的是企業組織認為你可以「增加」工作範圍或內容。而要讓企業組織，或者主管，要認定你可以承擔更大的工作範圍，最好的方式就是你「已經」做出超越目前工作職掌的成績。

超越工作職掌的方向有兩種，這兩種和雙因子理論/激勵保健理論(參考激勵保健理論)的概念相同。

方向一：保健因素

保健因素指的是，沒達成會有負面影響，但是有達成，且做得再好也不會是超越工作職掌的事情。換言之，有絕對的必要性，但是超過也沒有意義。

例如：

作為員工，準時參與會議，準時上班，按組織規定請假。
作為一個程式設計師，準時交付符合品質的程式碼。
作為客服人員，在時間內回復顧客問題。
作為專案主管，讓控制並管理團隊時程，沒有延誤

有些是屬於規定類型，有些是屬於職務範圍。這些都是歸類於保健因素。換言之「沒做到」是非常糟糕的！非但不用考慮升遷，甚至應該擔心被資遣。

要注意的是兩種對保健因素的誤解：

(a) 誤解一：消極應對

既然這並非升遷，或者有額外價值的項目，那麼也許我就做的勉強符合，60分就好。這樣的心態會讓這些的保健因素，很快的變成你自己的風險。保健因素的最佳處理方式是採用cynefin模型的「簡單因果」類型工作的處理方式。以最佳化，(或自動化)的方式處理。

消極應對，只會讓保健因素變得個人缺點，得不償失！

(b) 誤解二：這不是保健因素

在智慧型職業(例如程式設計師)最常出現的誤解是「這工作不是保健因素，我做到這件事情就是超乎期待」。

事實上，絕大部分的由上而下指派的任務，幾乎都屬於保健因素任務。

例如，你負責撰寫android app任務，根據自己的努力，確實在規範的時程內，以規範的品質上架完成。這「本來就是」你的任務。完成這件任務，的確是好事，但如果沒有做出超越任務的範圍，那就是預期內的職掌。既然是預期內的職掌，當然會取得預期內的「報酬」，例如薪水。自然也不會取得「額外」的報酬，例如鉅額加薪或升遷。

試想，你搭計程車，司機在合理的時間內，安全的把你載送到你要求的地點。你自然會付出正確的車資，不太可能付出「額外」的費用吧。

方向二：激勵因素

如果有做到，會讓人感到「很滿意」。

這個方向並不容易，但其實是「最能自己掌握自己升遷」的真正方式。

激勵因素根據工作內容而有所不同。以前述的搭乘計程車為例，如果計程車司機在車上「額外」提供一般計程車不會有的卡拉ok服務，並且未要求額外收費，在你開心的抵達要求的地點時，非常有可能自願的拿出額外報酬。

智慧型職業比較難找到激勵因素的方向。有幾個尋找方式可供參考：

(a) 參考方式一：擴增保健因素

這個方式比較基本。例如：一個app的程式設計師，被要求在6個月內完成app並上架，結果在5個月就完成，並且其品質也在要求的範圍內。對企業組織來說這個事件就算合理的「激勵因素」

(b) 參考方式二：額外的相關支援

類似計程車卡拉ok。例如：android app程式設計師，被要求在6個月內完成app上架。結果的確在時間內完成。並且，由於他採用react native，竟然也順便完成了iOS app。這就是額外的支援項目。

(c) 參考方式三：擴大 

主動執行擴大職掌範圍的任務。例如app程式設計師，其任務是開發app並上架，如果主動協助開發伺服器端，或其他功能模組，就算是擴大範圍。

更顯著的例子是：app程式設計師，其任務是開發app並上架，但主動組織團隊，做出新的實驗性質的計畫。那的確證實了擴大職掌和展示了領導潛力。

其他：

離開組織，以及自己建立組織-創業。 也是都是合理「自我升遷」的方式。

當然，離開組織之前，要先確定問題不在自己身上。如果問題出自自己身上 - 無論是能力或溝通問題 - 換到其他地方，也不可能解決問題，只是碰運氣而已。參考這篇，或者這篇，或者這篇。

創業是自己造成升遷的最簡單方式。在那一夕之間，你就變成董事長兼CEO了。然而，能不能生存並獲利，又是另外一回事。創業需要另一方面的能力與知識。要成功並不容易，參考這裡，與這裡。

---

註1：在某些地區，某些情況下，當然有不得已的時候。例如，如果你是生在阿富汗，伊拉克，索馬利亞等國家，確實很難掌握自己的命運。所以，本篇指的是一般在台灣的普通上班族。

註2：為什麼這些是藉口？請參考說明如下：

-- 自己的努力沒被別人及主管看到
-- 受到主管不公平的對待
-- 主管不賞識甚至打壓

(a) 短時間或許有可能自己的努力不被發現，甚至可能被瓢竊或者搶功勞。但長時間不可能！而且事實上，如果你真的能力極佳努力也夠，僅只是沒被看到而已？那你應該很容易可以找到更好，並且更容易看到你的能力和產出的地方！

(b) 爛主管的確有可能打壓好員工，但沒有人強迫你為某個主管工作，你當然可以離開。但是在離開之前，請先參考這本書(我愛白痴老闆)。也可以參考（得罪老闆怎麼辦）


-- 組織內制度有很多問題

(a) 大企業制度上不可能完美，因為制度目的通常是為了企業生存。只要企業符合法律規範(在台灣是勞基法)就沒什麼好抱怨。並且，適應制度也是能力的一環。當然你也可以自創一個擁有好制度的組織。


-- 負責的工作實在太艱難資源又少

(a) 如果你覺得能力不足負擔這個工作，那不升遷的確是合理
(b) 如果工作真的太難，那應該自己去換個簡單的工作
(c) 所有企業組織的資源都是缺乏的，資源缺乏不是問題，只是現實

-- 負責的工作實在太簡單沒有挑戰性

(a) 如果你覺得工作太簡單，可能是因為主管覺得你無法負擔更重要的工作
(b) 也有可能對你來說工作太簡單，但是對主管來說你沒把簡單的工作做好，以致於無法給你有挑戰性的工作


-- 景氣不好公司不賺錢就罷了，還在裁員
-- 比我資深的還很多，很難輪到我

(a) 如果升遷是你最重要的考量，應該離開這類型的工作環境

企業巫醫 - 時間乃最終之敵人? (下)

上篇：企業巫醫 - 時間乃最終之敵人? (上) 

那結論呢？

就人類來說，時間是中性的。它不是朋友，也不是敵人。它不是惡靈，也非天使。

在有限的職業生涯，如果你找得到自己的方法駕馭它，那非常恭喜！這可是上天給予的重大天賦之一。

如果始終在瞎忙中度過，或許試著混合數種前面的巫醫建議方式，可能會有些幫助。

但有幾個重點...

1. 考慮事實

企業組織為求營利的天賦，自然趨向去做幾乎任何可能產生商品競爭力的方式。以時間為衡量標準，恐怕是在天然資源和資本取得已經趨近最佳化的情況下，最合理的方式。

如果你覺得在企業組織工作時，自已的時間被無聊的瑣事白白浪費，氣的想要出來創業....那麼，你一定要先考慮是大部分的人，是自己無法控制時間，而非被別人浪費。這種情況下出來創業，會讓你本來每天花8小時幫某公司做事，變成每天花16小時，幫自己的公司做事。

時間既然是中性，增加效率當然是可行。加速？聽起來跟前述的巫醫有什麼不同(註4)？

重點在於：無論是個人還是組織。找到真正的目的，比產出效率重要。

而真正的目的在於考慮真正的事實。企業巫醫有許多手段和方式，都可以協助你找到「真正的事實」。

以個人生涯規劃而言，最終，這個事實也有你自己才能夠斷定。

然而，以在企業組織內部工作，真正的事實，或者是真正的目的，必須要來自「團隊目標」和「組織目標」。

2. 兵貴神速 v.s. 後發先至

重點在於：長期累積比短暫績效重要。

當企業組織可以在某個產品推出時領先，當然要持續領先推出其他產品，或者領先產品的其他服務。在這世界上有太多的先行者，無法保持領先而被後來者居上。兵法也有云：「後人發，先人至，此知迂直之計者也」，後發先至，其實是兵貴神速的對應。


個人工作上也是如此。快速完成的工作，如果不能累積優勢，就浪費了速度。以軟體工作而言，快速完成功能固然重要，但是功能上的完整以及品質，卻是快速的「基礎」。因而，採用敏捷開發的任何方法論，都不能以快速作為藉口，直接放棄功能上完整或者品質。

後發先至的基礎其實也在於「快速」。但是，個人快速的反應，其實是長久實力的累積。例如，對營運Linux平台十分熟悉，有很多年踏實經驗的工程師，自然在對應新的Linux雲端營運(例如AWS,Azure的Linux虛擬機)就比較容易適應。而過去僅在windows平台上有營運經驗的IT人員，如果整個系統要搬移到Linux為基礎的平台上，就算他可以很「快速」完成一部分，也不見得做的完整或者達到好的品質。

3. 時間乃最終之敵人 ...除非...

時間從很多角度來說確實是最終的敵人。它雖然是中性，但是它永遠都會流失。它的離開是必然而且無情。無論這禮拜天你做了什麼，禮拜天一定會過去。

因此，現實的說，時間乃最終之敵人...除非......讓它變成「敵人的敵人」。

以近年來的新興網路企業而言：

無論有沒有特別認知，事實上都試圖以「時間」來建立其他對手的進入障礙。若非以極高的成本獲得市場佔有率，讓其他競爭對手花更多時間才能開發產品，就是以需要時間累積的功能作為競爭主軸。

以個人的生涯規劃而言：

剛踏入社會的新鮮人，勢必缺乏實務經驗，無論是在爭取好的工作機會，或者是已經在企業裡面爭取好的表現，都不能是以「經驗值」來作為依靠。

以經驗值產出「工作表現」，大部分情況下新鮮人是無法和老鳥相提並論。但是相對於工作N年的老鳥比較起來，在「時間」上新鮮人擁有更多彈性。所謂時間，切記並非加班時間，而是「第一次就做對事情」的時間，透過學習和利用比較新的知識範疇，新鮮人可以比較快跳過錯誤的嘗試，在某些未來有發展潛力的範圍，有更驚人的表現。這時候，時間就會是朋友而非敵人。

相對的，已經工作了7年以上的老鳥。如果老是只能靠吹噓過去已經結束的專案經歷，無法產出對應的經驗值，那麼這七年時間就變成是最大的敵人。只是看到最新的技術，就隨意一頭栽進去學習，則時間就會是資深工程師的敵人，因為通常資深工程師的彈性時間實際上比較少。

資深工程師，在工作上必須要找到能夠善用這七年的成功或失敗經驗的地方，並試圖累積更多。即便是想要打掉重練，也應該透過經驗的累積，重練的更快，更好，甚至自動化。找到可以累積的地方，這時候，時間就是朋友而非敵人。

以作為組織內部的部門主管，專案團隊領導者更是如此：

當領導者使用以下手段時，是把時間當做敵人，(然而，要打敗時間實在太難)

* 加班
* 在軟體專案延遲時利用人月計算方式增加人力
* 以未來的產能估計時間，而非以過去的事時估計
* 以各種理由拖延專案，包含把責任推到別的團隊身上
* 專案過程並未檢視真實進度
* 假裝使用agile敏捷開發，實際上還是waterfall
* 不正視事實
* ....(還有很多)...

那麼不採用以上手段還有什麼可以做的呢？當然很多！如果你是領導者，但是想不出來其他方式，那麼你可能不適合擔任困難任務的領導者，因為「時間」永遠是你的敵人，而幾乎沒有人可以打敗時間。

---

註1：CP值，或者性價比，請參考這裡。

註2：這句話很多人都講過，包含郭台銘和柯文哲。不過，這個名言最早應該媒體大亨：梅鐸所說。另外，這句話在2002年也是某本書的名字。

註3：將時間視為第四個空間維度來描述，請參考狹義相對論。

註4：增加工作效率？聽起來和前述的巫醫有什麼不同？就想要達到的效果來說，有良心的巫醫和一般的醫生並沒有不同。最大的不同在於方法是不是合理，經過有效驗證，而且可以在未來檢討改善。

數據分析從零開始 - (3)外部取得資料

...續<上篇>...

外部取得資料

最常見的就屬於在網站上資料取得。最近由於透明化政府政策越受到重視，可供老百姓取得的資料就越多，當然可供作為資料分析的運用就多得不得了。

直接取得可程式化資料

資料本來就提供給外部取得用以計算，例如：政府開放資料。資料好不好用，是另外一回事，但起碼大部分的情況下，這類型的資料只要能下載就足夠應用。

有些資料可以api的方式取得，通常需要申請權限，典型的像是facebook graphic api，musicbrainz api，wiki api等等。

假設需要的資料都可直接程式化取得，那真要感謝上帝。資料數據分析就少了一大堆痛苦的事情要處理。

有個重要的技巧：利用Shell以及試算表對資料做基本驗證。這和前篇雷同。不過在此以試算表為例。

外部資料取得如果已經是整理過的，必然可以用很簡單的方式驗證。即便你沒有Excel，也可以先利用google的googledrive產生樞紐分析表。

作法很簡單。以前陣子最有名的資料：不動產時價登錄為例，

(1) 首先，到內政部網站下載公開資料

http://plvr.land.moi.gov.tw/DownloadOpenData。
它提供了很多資料格式，不過請下載csv格式。

內政部雖然是一番好意，提供各種格式資料。但坦白說，只csv格式是真正正確容易處理。其他格式根本是多餘而且難以直接利用，它的xml並沒有定義namespace，會讓需要合併處理xml時，要重新定義所有的node。

(2) 選擇其中一個csv上傳到googledrive，上傳之後是預覽狀況，請參見下圖：

(3) 按下右上角的：使用『google試算表』開啟

這時候會把csv格式自動轉換成google試算表內部格式。請注意這個格式，並非excel。

(4) 在試算表上選擇「資料」，並選取出現的「資料透視表」。要注意的是，這裡雖然是資料透視表，但是其實下一個畫面名稱就變成樞紐分析表了。

(5) 樞紐分析表出現後，是空的。在右邊選擇想要的欄列。之後就可以自動展示簡單分析的結果。

下圖的例子是以桃園的區作為列，建物型態作為欄。並且在「值」的位選擇平方公尺的單價的平均值(Average)。這個基本的分析可以很快的看出來資料的特性。舉例來說，在這段期間，屬於廠辦的交易就只有龍潭區。

間接取得資料

許多有用的資料，都要自己寫程式來取得。特別是，這類型的資料雖然公開，但不期望也不希望被程式大量取得，例如統一編號查詢。這種資料通常會用captcha來阻擋，不過現在破解captcha的工具和機率越來越高，現在比較重要的網站都改成以「請點選以下哪幾張照片裡面有老虎」這種方式處理。

在1996年之前，間接取得資料的通訊協定有很多種。但是，現在http幾乎已經統一可公開間接程式化取得「資料」的所有方式。而也因此，所有間接的，可程式化的取得資料大概都只需要專注在http。

簡單的說，只要 

(a)熟知http crawler (爬蟲)技巧 

(b)程式化處理html 或其他格式文字

就大概可以解決75%以上的問題。

建議的步驟為：

步驟一：找到正確而適當的目標。

不是所有外部資料都是好資料。倘若你想要蒐集在台灣關於醫療方面的問答資訊。或許你會先透過google隨意查詢一下，接下來，你可能會看到 verywed.com 有很多有趣的訊息和網友經驗。如果你就真的覺得上面的資料有用，那麼你等同是蒐集了眾多無法證實的資訊，造成資料嚴重的可信度問題。

雖然google也並未對所有資料的可信度加以查證，但它的演算法可以利用交互連結，以巨大的資料排比最可能的結果，而巨量資料在很多時候，可以彌補質的問題。

個人的爬蟲和資料蒐集，當然不可能做的和google一樣。至少從零開始的時候是不可能。因此，有意義，可信的資料來源變得很重要。

以前述的醫療資訊而言，台灣衛服部的台灣e院網站所提供的問答資料更具可信度。因為，回答問題必然是「具名」的醫生，當然其專業和可信度比「不具名的網友」高很多。

台灣e院看似複雜，但簡單來說所有的Q&A檔案歷史，都可以由一個ShowDetail.php加上簡單的參數以GET方法取得細節。每個網站的作法都不一樣，仔細觀察每個查詢按鈕，加上一些經驗與知識，絕大部分的網站都可以找到某種規則。比較複雜的網站，請善用瀏覽器的「開發人員工具」。

步驟二：以curl或其他工具，先行測試

在mac或linux上都有的curl指令，是在撰寫爬蟲程式之前，最方便先測試的小工具。

在很多時候，甚至可以利用curl配合wget，可以連程式都不用寫就抓取一整個靜態網站的資料。

例如，以下指令可以取得q_no=111521的網頁資料。（參見下圖)

#curl http://sp1.hso.mohw.gov.tw/doctor/All/ShowDetail.php?q_no=111521 -o onepage.html

步驟三：以script撰寫能處理與轉換儲存資料的程式

以台灣e院為例，要取得所有Q&A的歷史檔，只要知道「大概」最後的q_no編號，再寫個簡單的python程式即可。

要特別處理的地方只有：

(a) 不存在的編號：每個網站處理不存在的resource方式各有不同，以台灣醫院為例，仍然會在http reponse中回應200，但是內容改變

(b) 編碼：這個網站使用big5，但為了未來處理方便，最好先轉換成UTF-8。範例中使用requests取得網頁之後，理解編碼並且轉碼。注意!大部分的big5會被誤以為是ISO-8859-1因此要先強行指定為big5之後再轉換

(c) 轉換格式：當然不會想要整個網頁存檔，只想要問答內容。範例中使用lxml的xpath的方式直接取得所需要的element內容。

程式碼參考如下：

#!/usr/bin/env python3 # -*- coding: utf-8 -*- import requests import time import sys from io import StringIO from lxml import etree from datetime import datetime for i in range(34500,34520):         time.sleep(3)         print('working on'+str(i))         url='http://sp1.hso.mohw.gov.tw/doctor/All/ShowDetail.php?q_no='         r = requests.get(url+str(i))         r.encoding = 'big5'         htmlstr = r.text         if htmlstr.count(u'不存在</h1>') > 0:             print('ignore '+str(i))             continue         parser = etree.HTMLParser()         sio = StringIO(htmlstr)         tree = etree.parse(StringIO(htmlstr), parser)         question = tree.find(".//li[@class='ask']")         allq =""         for t in question.itertext():             allq = allq + t         dr = tree.find(".//li[@class='doctor']").text         ans = tree.find(".//li[@class='ans']")         alla = ""         for t in ans.itertext():             t.replace("\n","")             alla = alla+t         oneResult = {'a':alla,'q':allq,'dr':dr}         print(oneResult)

步驟四：考慮儲存地點

網頁可以儲存為靜態檔案，也可以分析欄位後，儲存在傳統資料庫，但近年來更流行存在nosql中。

可選用的nosql非常多，mongodb, AWS的dynamodb, elasticsearch, couchbase...都可以。

前述的範例，倒數第二行：

oneResult = {'a':alla,'q':allq,'dr':dr}

其目的就是在於轉換為python dict之後，很容易處理為json或者直接利用各nosql的sdk，存入到儲存地點。

步驟五：慢速進行

大部分的網站其資料當然是公開讓廣大網友使用。然而，程式化使用，例如利用爬蟲大量下載，通常是網站管理員不會特別注意到，然而爬蟲程式的確有可能讓網站變慢。

作為一個自治網路世界的好公民，首先應該先了解該網站是否有robots.txt，也就是定義爬蟲程式的規範。如果有，那就應當遵循。如果沒有，應該要在爬蟲程式中，適度的停一段時間。

例如，以前述範例來說，在for迴圈中使用time.sleep(3)，讓每一個http request都等3秒鐘之後才進行。這樣雖然有可能讓爬蟲程式本來需要1小時就完成，變成足足3小時以上，但可以確保該網站不會受到你的爬蟲程式太多影響。

努力才會成功：三個錯誤方向

有努力不見得有收穫，但沒有努力就沒有收穫。因為努力是通往成功的唯一道路。

然而，對於努力有很多錯誤的認知方向。

以下列舉最常見的三個錯誤方向：

錯誤一：「用力」就等於「努力」

「努力」和「用力」是兩回事。

試圖只用雙手去移動開一整座高山是「用力」；研究各種方式和技術，挖出一條筆直的隧道是「努力」。

在專案遇到困難時，千篇一律的超時工作，無止盡加班是「用力」；探究各種技術的突破，讓專案有進展是「努力」。

在傳統企業推廣資訊科技應用時，苦口婆心的淳淳告誡是「用力」；透過強迫的方式，逼使使用者改變習慣是「用力」；透過各種巧思，讓人願意自己使用新系統是「努力」。

錯誤二：努力一萬小時就會成為天才

小提琴家Auer曾回答學生說：「用手指練琴，可以練一整天，但是如果用頭腦練習只要一個半小時」（參考這篇）

「努力」是需要花時間，然而，努力更要花的是思索以及驗證事物的本身是否朝著正確的方向。瘋狂的往錯誤的地方磨練一萬小時，不會讓錯誤變成正確。那努力一萬個小時變成天才，指的是有用頭腦的一萬個小時，而非不經思索的一萬小時。

但是，努力所花的時間容易被人看到，而且容易讓人產生「同情」。因而，在企業中長時間加班的人，很容易被表揚；在專案延誤時，帶領團隊不眠不休努力，容易被認為是負責任；讓專案順利完成，讓系統保持為定沒有問題，容易反倒被認為沒事做。如果你是領導者，切記不要過度獎勵沒有功勞也有苦勞的情況。

錯誤三：努力的筆直前進

如果目標與達到目標的方式是錯的，努力就變成可怕的慘狀。許多人常被一個故事所誤解（掉到奶油桶的青蛙）認為只要堅持下去，也許事情會有轉機。然而，故事裡的青蛙其實已經採用正確的方式 - 也就是一直游蛙式。如果青蛙使用更有持續性的方式維持生命 - 也就是水母漂，那麼無論如何不可能攪動成為乳酪。

幾乎任何情況下使用googlemap規劃最短時間的路程，絕大部份都不會是筆直：最短時間的路徑，通常不是最短的路徑。

努力的目標要正確：確定努力的目標是你真正想要的目標。

努力的方式要改進。努力的增加知識與能力，讓進行的方式可以朝向最正確的路徑，而不是看似最筆直的路。

在盈利企業裡面，整體努力目標應該是合法的獲取利益；然而，在企業裡面投入工作的個人，在工作上卻應該是根據自己的工作內容訂立正確的目標，如果是業務當然是獲取訂單，如果是生產部門，也許是極大化產量，也許是平衡品質與成本。但是，下班後，目標應該是自己的目標，例如陪伴家人之類。

一個業務，無論採用什麼方式當他的業績，一年後沒有達到目標，當他要「繼續努力」的時候，一定要採取別的方式。繼續堅持用舊的方式，也需要「努力」了解為什麼舊的方式可以持續使用，而不應該改變。

大部份的專案，目標通常都已經定好，然而執行的方式卻應該根據實際的情況改變。例如：在前期中期發現有重構(refactoring) 的需要，就應該先考慮重構，而不是試圖先達到某個帳面上的milestone。

大部份的辦公室日常活動，其價值都越來越低，努力的方向不是增加手指打字的速度，也不是加班完成任務，而是朝向去除完全不必要的事情，簡化或自動化簡單的事情前進。

---

沈思：

努力而失敗的例子太多，可以找到在你的工作領域上的例子嗎？

資訊科技學生畢業後只想當SA/PM (三個創意作法)

很多畢業生，資訊相關系所，擺明就不想要寫程式，但是卻又想要加入資訊科技產業。老實說如果是做行銷(Marketing) ，業務(Sales)，或者支援類型工作(admin, finance)倒是也無不可。

只是很多資訊科技學生，似乎想要當SA(系統分析師)或者PM(專案經理)，也許只是覺得名字好聽，或者認為：既然是資管學生應該做點管理工作也不為過。

這種想法其實很危險，也不可靠。

系統分析師(SA, System Analyst)扮演的角色在各公司都很不同，有些很像是業務助理，有些是專案經理的小跟班，有些是扮演IT對外採購的角色，不一而足，單看是去哪個公司。

而專案經理(PM, Project Manager)情況可能稍微好一點，顧名思義就是：負責某一個或者一些專案的進行。20年前PMP證照流行的時候，專案管理本身被視為一門複雜的學問，當然在軟體或者新創網路科技產業，PMP那套不太可行，Agile/Scrum/XP 等等方法論興起，讓PM多少都不太可能單純只做管理。

不管如何，缺乏實務經驗(指的是起碼3-4年努力寫程式的經驗)就去做SA/PM等同於是碰運氣，就算花大錢去取得PMP證照以及其他相關證照，也沒什麼用。這就像是從來沒打過籃球的人，想要當NBA籃球教練一樣幾乎不可能。

雖然很不贊成這樣的事情，但與其碰運氣，不如提供實務作法。

(1) 創意一：讓自己真實變成SA/PM (要花一點錢)。

在學校的專案課程中，讓自己變成PM然後讓某同學變成主Co*(註一) 是絕對沒有用的。任何有經驗的主管，一定看得出來你只是負責動動嘴巴，補補文件。

你可能需要付出一些代價，例如100美金，然後想一個app的好主意，到outsourcing網站，像是upwork.com，雇用一些印度，巴基斯坦工程師，實際上幫你寫程式，這時候你100%是PM，你控制了整個專案的進行，負責製作需求與控制工程師進度。更好的是，這還是個跨國專案。

不過，實際上這樣做出來的東西，失敗率很高，特別是假如這次你第一次當PM - 這裏的PM同時兼具Project和Product。因此，對此創意方式要有正確的期待，也就是說事情的成敗並不是重點，而是在此過程經歷了什麼。這非常接近NBA例行賽開打之前的練習賽，練習賽獲勝固然可喜，但比勝利更重要的是團隊的磨合以及戰術的演練執行。

註一： 主co = 負責主要coding。這個名詞是最近幾年面試學到的，意思差不多就是這個專案課程，程式都是我寫，事情都是我做，其他人出嘴巴。

(2) 創意二：組織同學來做專案

等一下，前一段不是說在學校專案當PM然後某同學來主co是絕對沒用的嗎？為何這裡又說要組織同學來做某專案？

不一樣是，組織同學來進行非課堂的任務，遠比修課需要的專案來得困難，但是更實際。

第一種可能是，到市場上接專案本身到不是問題，因為一開始取得專案的目的，並不是獲得高額利潤，因此價格競爭是有可能的，畢竟你的目的是要取得成為SA/PM的事實，並不是真的要從專案獲利。

然而，業主可能也知道，這種情況下的專案可能不見得做的很好，因此價格競爭有時候也沒太大用處。

第二種可能是，自己找事情來進行。十幾年前BBS風起雲湧的時候，大部份架設BBS的人，都並非學校課程，也不是因為賺錢獲利，只是覺得好玩有趣。架設BBS讓當時的學生取得寶貴的UNIX（FreeBSD等）的營運經驗。如果想當PM，也可以自己找事情，組織同學來進行。不過通常這種情況需要是以技術強度來領導，因此遠比接專案困難。

(3) 創意三：尋求業界導師

由於linkedin和其他社交工具的發展，很容易可以找到業界資深的學長學姊。只要是在他們時間允許的範圍，很容易可以請求協助。當然，每個人的時間有限，所以最好的方式是，互相幫忙，互蒙其利。當你在與不太熟悉的人聯繫上之後，可以用交換的方式，讓他們指導你，並且為你的成就背書。

舉例來說：你可以作為業界導師的私人虛擬助理*(註二)一段時間，幫他處理非機密的相關業務，例如，調查研究競爭對手產品，處理文件，處理linkedin或者其他socail media的日常文章，業務聯繫等等。而作為交換的是：他可以指導你實務專案上"他實際上做了什麼"。數個月後，你甚至還可以取得業界導師的背書以及推薦。

另一個做法是尋求成為學徒的機會。學徒制度是一個非常古老的學習方式，在某些情況下，學徒制度非常有用。如果你是一個剛進學校的研究生，尋找指導老師是最重要的一件事。而如果你是一個畢了業就想要當SA/PM的人，找到正確的業界導師，會讓你事半功倍。

我們會在未來的文章探索學徒制與軟體專案發展的關係。





* (註二)：關於虛擬助理，請查Virtual Assistant

---

沈思 

如果本文對你沒幫助，還請與我們聯繫取得免費協助。

1.  再次強調，在沒有技術背景的情況下，最好是別真的想做SA/PM

2.  如果真的想做，那麼務必考慮這三種方式。

3.  當你想要什麼，執行的方式如果是「碰運氣」或者「期望別人給」永遠都是最糟糕的選項，想要什麼最好是先構思自己要怎麼取得。

關於技術領導者-team leader 的三個基本概念

資訊科技產業裡面，常有稱呼為小組長，team leader的人，通常負責帶領小團隊前進。這裏簡單說明一下技術領導者的三個基本概念：

(1) 什麼是資訊科技的技術領導

傳統組織隨著人數的增長，通常自然會產生階梯(金字塔)型的結構。然而，這類型的結構把階級當作激勵員工的方式已經不太流行，反倒是以虛擬小組形態，組合不同的小團隊來完成階段性任務，已經逐漸變成常態，特別是在資訊科技領域。

因此一個專案任務，視其大小，需要某一個人負責帶領1-7個人，完成一件任務，而這1-7人並不直接在這個負責人的管轄，也就是另有管理經理負責。這種人，在此稱呼為技術領導人(tech-lead, 小組長, scrum master…總之有零零總總的不同稱呼) ，但其定義僅如下：

                (1) 領導完成任務或部分任務

           (2) 領導1-7個人

           (3) 並非這些人的直屬上司

台灣的學生第一次有機會作為軟體專案技術領導，可能是在學校進行專案的時候。屆時，雖然教授會給予方向上的指導，但事實上是由學生完成，數個學生所組合的團隊可能有各種方式選出一個”組長”。

投入職場之後，運氣好(或者運氣不好)在兩三年內可能會負責帶數個比較新進的同事，主要目的仍是完成某任務，如果組織比較扁平實際的主管也許不會直接帶領新同事，此時，所謂的資深工程師，就很快面臨必須做一個技術領導的挑戰。並非每個人一出生就是個好領導人，但是如果沒有意識到作為技術領導的重要性，則很有可能造成三輸的局面：新人很快陣亡；主管不滿意帶人的績效；自己也不高興。而成功的帶領同仁完成任務比較可能達到三贏：新人很快能貢獻給團隊；主管的期待被滿足；更重要的是自己在技術以及領導力上有所成長。

(2) 技術領導與管理階層截然不同

作為技術領導者，因不是直接管理工程師，所以只能透過領導以及可信服的技術能力來帶領成員。因此，相較於實際管人經理有優點也有缺點：

        優點：

                * 無須擔負直接管理責任(不需要負責解雇人)

                * 不需要直接負責成員的心態問題以及生涯規劃

        缺點：

                * 無法使用職位快速以上對下的方式達成小型任務

                * 對於明顯有心態上的問題的成員無法快速汰換

                * 難以對團隊成員提供誘因

(3) 就業市場非常需要技術領導

一個好的技術領導者Team leader在就業市場上奇貨可居。

資訊科技的就業市場過去數年一直在成長，每年畢業的學生雖然眾多，可是就業市場似乎傾向於取得及時戰力。而有實質經驗的技術領導者，比主管經理的市場更大，因為主管經理不見得一定能夠帶領技術，也可能距離實務已經有一段時間，然而技術領導者需要帶領小團隊前進，正常的情況下本身就需要具備技術領先的能力。

更有甚者，現代組織都希望層級不要太多，扁平化在成熟組織幾乎是常態，People Manager - 也就是所謂帶人主管，通常直接帶領的人數會越來越多，也導致非直接帶人的技術領導，通常才是直接參與開發工作的領導者。

---

沈思

* 如果我已經是技術領導者，我要怎麼提升自我的能力？ -> 參考這裡