顯示具有 學徒 標籤的文章。 顯示所有文章
顯示具有 學徒 標籤的文章。 顯示所有文章

3/07/2017

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



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

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

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


12/31/2016

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



只有自己掌握了自己的命運。沒有別人。(註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) 如果升遷是你最重要的考量,應該離開這類型的工作環境


9/25/2016

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


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

那結論呢?


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

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

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

但有幾個重點...


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:增加工作效率?聽起來和前述的巫醫有什麼不同?就想要達到的效果來說,有良心的巫醫和一般的醫生並沒有不同。最大的不同在於方法是不是合理,經過有效驗證,而且可以在未來檢討改善。


9/18/2016

數據分析從零開始 - (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小時以上,但可以確保該網站不會受到你的爬蟲程式太多影響。








1/19/2016

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




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

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

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


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

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

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

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

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



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



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

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

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


錯誤三:努力的筆直前進


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

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

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

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

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

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

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

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









沈思:

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


12/15/2015

資訊科技學生畢業後只想當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.  當你想要什麼,執行的方式如果是「碰運氣」或者「期望別人給」永遠都是最糟糕的選項,想要什麼最好是先構思自己要怎麼取得。





10/22/2015

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


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

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

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

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

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

           (2) 領導1-7個人

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

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

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

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


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

        優點:
                * 無須擔負直接管理責任(不需要負責解雇人)
                * 不需要直接負責成員的心態問題以及生涯規劃

        缺點:
                * 無法使用職位快速以上對下的方式達成小型任務
                * 對於明顯有心態上的問題的成員無法快速汰換
                * 難以對團隊成員提供誘因


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


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


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

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




沈思

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