顯示具有 training talent 標籤的文章。 顯示所有文章
顯示具有 training talent 標籤的文章。 顯示所有文章

9/30/2016

企業巫醫 - 實習生的三贏




巫醫通常會告訴病人事情的「權衡」:是想要錢還是健康?是想要貢獻祭品還是得罪惡靈?當需要獲得健康,當然就要犧牲其他東西。

許多事情的確是如此...總不能要馬兒跑,又要馬兒不吃草。

不過,對於需要創造性思維的現代企業,權衡在於真正的目標,和創意的達成方式。把馬車換成內燃機驅動的汽車,就是革命性的方式讓移動的東西大幅加速而且不用吃草。

企業實習生也是如此。

高明的策略,就可以達到三贏。普通的策略,就會犧牲某些地方。愚蠢的策略就是三輸。

以資訊科技產業來說,三贏的情況是:


對企業組織來說:有低成本的方式,獲得高潛力的「人力」。讓工讀生能先處理簡單,可學習,重複,但是可改進的工作,使團隊成員專注在複雜的開發活動上(註1)。藉此了解這些工讀生未來的潛力,同時也能透過有效分工,提升績效和產出。還能順便展現企業的社會責任決心。甚至,透過實習生循環來訓練組織內部未來的領導人才。

對社會來說:降低新鮮人「嘗試錯誤」的成本,增加投入的生產力。

對新鮮人來說:提早知道自己的興趣和能力。在還沒踏入職場之前,至少對工作有所體認,瞭解軟體工作真實的一面。無論未來是不是要從事同一行業,踏實並且正確的工作經驗,都能引導未來的發展。

普通的情況是:


對企業組織來說:在暑假期間,統一由HR辦理招募活動,發配到各個部門,和夏令營一樣在兩個月期間和團隊一起合作,可能有產出也可能沒有。

對社會來說:讓大學生研究生在暑假能有除了閒晃打電動之外的選擇。

對新鮮人來說:可能像參加夏令營一樣,但只要有認知,還是能學到很多。


有三輸的情況嗎?


會有三輸的狀況,通常是乩童式策略規劃,和不正確的預期:

乩童式策略就像是有件困難的事情,是在我們的智慧能力尚且不能了解,所以我們就去問乩童,而乩童也不懂,但是他可以「起乩」,透過起乩,從其他地方得到智慧,來回答問題。在各個部落的巫醫也都有類似「起乩」的行為。即便只是實習生策略也會有淪落到乩童式規劃的可能。而這樣的策略結果等於是靠運氣,運氣好的時候甚且可會收到好的效果,但不可能永遠都是好運氣。

對企業組織來說:只是因為「聽」企業巫醫起乩之後,覺得弄幾個工讀生來好像很不錯。因此,就隨便找幾個進來。但由於沒有組織,沒有計劃,就只能做沒有意義的工作。更有可能還會故意製造的沒有意義的工作給工讀生。參考這裡

對社會來說:浪費了人力

對新鮮人來說:對企業造成不必要的負面印象。也沒有真正學習到工作的意涵。



如何達到實習生的三贏策略



達到三贏的方式,當然是以事實為基礎,避免乩童式目的,達到漸進式目標。

以資訊科技,或者,軟體開發相關企業來說,掌握以下事實,就容易達到三贏。

(1) 培訓是必要的:

的確有很多自動自發學習,又很聰明的學生。但是稍稍有計劃的訓練,可以大幅降低走錯路的時間。而培訓不只是「教」而已,找一些主題讓實習生自行學習也可以。

(2) 長期:

對資訊科技相關的工讀生來說,

A: 一個禮拜來兩天,連續6個月。

B: 全天候,但只有2個月。

這兩個方案看起來實際工作時間似乎一樣,但是,最後能達到的學習效果和產出,永遠是A比較好。因為,資訊科技並非勞力型的工作,而是思考智慧型的工作。當實習工讀生對技術產生興趣時,自然而然會再額外的時間,補足在技術和知識上的不足。而且,考慮到前期的培訓時間,超過6個月以上的實習才能可能達到三贏。

(3) 務實:

讓工讀生參與真正任務,但由基本開始。讓實習生去撰寫核心模組,是本末倒置的行為(註 2)。但只讓工讀生去打掃辦公室也沒太大意義 - 除非這是一間專業清潔公司。以軟體開發而言。以下幾件事情都是比較適合的切入點。

A: 簡單的執行測試計劃(test case):是最容易入手,並且也比較能直接產出貢獻的事情。

B: 驗證文件:例如將api文件中的範例依照手冊執行看看會不會有意外,也是產出貢獻的一種。

C: 專案助理,協助收集進度,現況,簡單統計目前在版本控制系統(例如git/cvs/p4)裡的程式碼增減狀況...。這些看似助理類型的工作,可以讓工讀生對軟體專案的進展有很完整的概觀。

(4) 實習生的週期循環:

工讀生從開始招募,訓練,到離開,最好是6-18月之間。必須要簡單完成的循環規劃。實際的例子如:

A:  招募大三四研一二的資工資管資科相關學生。
B:  為期最短6的月 每週來兩天 時薪固定為XXX元。
C:  到期根據實際表現可能會續約一次。大部分會續約。
D:  座位和電腦設定已經事先準備好 (已經有check-list)。
E:  主要先進行測試相關工作,但偶爾做點瑣事(例如訂下午茶)。
F:  每年的都是由某資深工程師負責,今年負責人為某甲。
G: 合約到期離開的check-list。




(5)利用實習生培育未來的領導人才:

成熟的企業組織通常趨於緩慢成長。也就是說,除非有人離開,不然從升遷為基層主管的機會將會越來越少。然而,在團隊培育領導人才,卻是必然進行。讓有潛力的團隊成員,負責整個工讀生的循環週期。藉此,歷練作為領導主管會經歷的所有關於「人」的大小事情。畢竟,並非所有技術專精的人都適合當領導者,而透過執行實習生的策略,不只培育了實習生,也可以培育團隊的未來領導人才。即便最後發現某些技術專精的人不適合作為領導者,風險也比較低,畢竟他僅只負責工讀生,不是突然之間負責領導整個開發團隊。

很多時候,即便實習生不能達到原本規劃的要求,光是能夠陪為組織內部未來的領導人才就已經十分划算!






註1:「簡單,可學習,重複,但是可改進的工作」和之後提到的「無意義的工作」截然不同。以軟體開發中的測試工作而言,雖然某些情況需要大量人力測試,但是,更多狀況是當工讀生了解測試的意涵之後,大多數都能改進測試的方式,在某種程度達到自動化測試。而「做出」自動化測試程式,對工讀生來說就變成可學習到很多的工作。

註2:但也不能排除剛好招攬到一個天才中的天才的可能性。因此如果真有這樣能力的人,應該直接讓他轉成正職。




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


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



在每年不可計數的企業管理勵志書籍中,有越來越多把「時間」視為判斷事務的重要標準。想當然,個人「時間管理」變成一種必要的技能。然而,更近一步是在越短的時間,達到越驚人的效果,從早期的「24小時學會某東西」系列,到「7分鐘運動燃脂72小時」,都是試圖在短的時間內達到CP(註1)值最好的結果。


時間似乎是最終的敵人?


也許,在某些時候,「搶先一步」是競爭的最佳方式。不是大的打敗小的,而是快的打敗慢的(註2):就變成企業主事者認定的最好成功方式。畢竟,如果可以用很少的投資(小),只要用比較少的時間(快),好像就可以打敗大但是慢的競爭對手?聽起來永遠不吃虧阿!再者,兵法有云:故兵聞拙速,未賭巧之久也。似乎,只要速度夠快,總比慢來的好?

更近一步的說,許多人逐漸視時間為最終測量維度。例如Compete Against Time,就將時間視為在商業上,衡量事務的最重要方式(註3)。甚至有人認為應該是唯一的度量方式

就經濟學始祖亞當斯密1776年的說法,企業組織價值的來源主要由三種事情組成:資本,土地,勞力。土地:泛指一切自然資源,勞力:泛指人類的智慧和努力。任何商品的價值,都是由這三者的其中一種,兩種,或者三種組合起來。

時間快轉到2016,隨著全球化經濟發展,資本以及自然資源,對於企業的影響已經遠遠不如「勞力」,更確切的說,是人的努力強化資本和自然資源的運用。即便現在存在著比1776工業革命初期更自動化的設備,更能節省人付出肌肉的努力,但面對更趨複雜的環境,人類的「智慧腦力」似乎需要付出的更多,某些人需要付出更多的腦力,讓其他人少動點腦?而最終,變成某些人在相較短的時間,付出較多的腦力,產生較好的結果,可以大幅讓商品的價值領先市場的其他人。


總之,各種訊息「似乎」都顯示,即便時間不是最終的敵人,也是先要處理的「衡量指標」


以廣大勞工而言,衡量生存的指標,就從古時候的「每天能耕多少田」,轉為「每天能在工廠做多久」,而再變成「每天在電腦前面完成多少工作」。只要能在越短的時間完成越高品質的工作,就會越有機會加薪升遷。


然而,事實上只有極端少數的人,能夠妥善駕馭自己的時間,也因此,「時間」變成企業巫醫用來恐嚇部落子民的惡靈之一。


巫醫有三種方式來處理「時間惡靈」

一:加速 - 跑的比它快


各種企業巫醫的,也在強化此信念,教導讀者「加速」用來增加巫醫的崇拜。

例如,最有生產力的一年超強時間術早上三小時完成一天的工作時間整理術... 請隨意搜尋類似標題,一定可以找到超過100種以上的方式,書籍,甚至mobile app。

這些加速的書籍,有些的確是有用的個人經驗,就像南美巫醫累積了數世代的經驗,分辨有效的草藥一樣的有些用途。然而,通常僅能適用於巫醫自己。關於「加速時間」,就像投籃命中率一樣,可以學習,可以練習,但是因為環境的因素,每個人終究有其極限。

事實上,「加速」全然是靠自己的經驗和能力,就像大部分的感冒是靠自己的抵抗力痊癒一樣。採用巫醫的建議手法,確實有幫助,只要自己意識到這樣樣的手法是在幫助自己的經驗與能力即可。過度崇拜「方式與手法」,會容易走火入魔。(參考:2013年的9個todo app)。




二:有效利用 - 80/20法則的極端利用


光是加速,能取得的效果總是有限。頂多取得20%-30%的進步就很了不起。唯有改變方式,甚至改變目的,才有可能取得3倍或者10倍的改變。

從「加速」改為「有效利用」,就成為在2008金融危機之後的顯學。

例如:為什麼菁英都是清單控Scrum一半的時間做兩倍的事少但是更好其實工作不必這麼累 ... 一樣有成千上百的書都屬於此累。

這類型的「找重要的事情做就好」的書,其實真只有這個重點,那就是掌握80/20法則,先做重要的事情,你的職業生涯就是彩色的。

但是,企業巫醫沒辦法告訴你,在你身上哪個20%是最重要要做的事情。誠實的巫醫永遠只能說「施主,這要問你自己阿」。而拐彎抹角的巫醫會用「斷捨離」,「時間矩陣四象限」,「人生優先清單」等等技術性的手法,告訴你,你還是得自己找到那重要的20%。


三:心靈層面 - 永遠都有的一招


幾乎所有的企業巫醫都會的一招:將所有的事情,推移給心靈與精神層面。

例如:心靈慢活療癒慢活從容的力量慢一點成功又何妨被討厭的勇氣...

就心靈層面觀點而言,這些巫醫也許可以帶來平靜,而平靜讓人的思慮或許可以更周延,並降低更多的壓力。但是,這些巫醫雖然好意的想要讓世界變得更美好,但是絕大部分的人類是社會性動物,試圖全然擺脫外在的影響,等於是要人類放棄天性。當企業組織內變得越來越快速,光是一個人在裡面「慢活」是難上加難。




那結論呢?


請參考下篇:企業巫醫 - 時間乃最終之敵人? (下) 。




註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小時以上,但可以確保該網站不會受到你的爬蟲程式太多影響。








9/13/2016

數據分析從零開始 - (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中。

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


外部取得資料



8/14/2016

Scrum (實況) - 瞭解事實才能領導專案






近年來在符合Agile精神的各種專案方法論中,Scrum應該是最簡單,也是最熱門的。

雖然簡單,但要掌握其精神,必須對抗長久的習慣,而這並不容易。

目前市面上也衍生各式各樣Scrum架構的作法和細節,從一開始的User Story到sprint最後的檢討會議(retrospective)都有琳琅滿目的作法與工具。假如只能選一個最重要的精神,則「實況:瞭解事實」是最最最根本的Scrum精神。(註1)

Scrum架構中,理解事實有很多層面。在此以「角色」「衡量效率」「固定時間」作為範例。



1. 角色


實況(Scrum)只會有三種角色

1. 產品擁有人(Product Owner)
2. 團隊領導 (Scrum Master)
3. 團隊成員 (Scrum Team)

而最根本的Scrum務實精神,在角色所扮演的任務中展露無疑。

也就是:

(A) 只有產品擁有者,才能排定產品功能的開發順序(product backlog)!

(B) 只有團隊成員,才會決定每一段時間,哪些功能會完成!

換言之,什麼事情先做後做,交由最接近市場的人 - 也就是產品擁有人 - 來決定。但是那些事情要花多少時間,是由做事情的人 - 也就是團隊成員 - 來決定!這個作法完全奠基於事實,並且適用於絕大部分的情況。

這和傳統專案有很大的不同。許多專案的時間預估,都不是做這件事情的人來預估。自然就一定不可能預估的準確。

不過,在許多「精采的成功個案」中似乎常常會有一個超強的產品經理,能主導市場,產品進度,甚至使得專案團隊有突破性的創新結果:典型的個案就是第一代iphone直接由賈伯斯(Jobs)作為產品經理帶領開發。似乎就是產品擁有者,主導進度的鐵證?

然而,事實上絕大部分的產品經理都不是賈伯斯。可是,大部分的企業,卻可以雇用到接近賈伯斯擁有的研發團隊品質!!因此,絕大部分的情況下,將產品研發功能相關執行與時間預估,交由團隊成員,才比較可能產出和市場預期的結果。除非該產品經理很確信自己跟賈伯斯差不多,並且也能提出「具體證明」。(就如同大部分的資深程式設計師,都能提出具體的證明 - 程式碼,佐證他的經歷一樣)



2. 以結果來衡量團隊效率


在實況(Scrum)中,一個項目完成的定義就是「完成」。而團隊的速度,取決於每個sprint可以完成多少項目。當然團隊一開始的完成事項的速度,大概很難和自己預估的一樣。

然而,過了兩三個Sprint之後,團隊速度應該已經「固定」,而這個完成工作的速度,就變成「事實」。

要看研發團隊速度在這時候很簡單,打開燃盡圖(burndown chart),算一下每段時間 - 例如每週或月 - 可以完成多少單位,自此之後,要估計時間,只要能有效估計每個功能(user story)規模大概多少單位即可。

這個事實,原則上不會改變。然而,產品擁有者確有權限可以在必要的時候改變事實。他有兩種選擇:(a) 更換產品功能。(b) 改變團隊。

更換產品功能可能是縮小功能規模。例如原本app支援facebook, linkedin, google+的帳號登入,考慮市場都在台灣,因此就先做facebook登入即可。

當然產品擁有者也可以改變團隊,重新組織團隊,更換成員。但一旦改變團隊,就必須重新啟動新的sprint,而也會重新產生新的速度。



3. 以取得事實來固定會議時間


Scrum(實況)的會議,必然鎖定會議「目的」以及「時間」。在事實的基礎下,兩者有很大的關聯。

以每日會議為例-- 不管是不是站著開會,一定是一天工作的開始,最多只花15分鐘。成員輪流以1-2分鐘「說明」三件事:

(a) 從上次開會到現在完成了什麼,沒有完成就說沒有 
(b) 今天打算做什麼,而且有什麼會完成 
(c) 遇到什麼困難需要ScrumMaster協助。

這三件事情,只是說明,若有問題,也是對說明的問題,絕不應該討論。要討論是開會之後,相關人等,聚集在適當的地方,最好是某個人的電腦前面,開始幫忙解決。

通常最容易花時間就是遇到困難的時候,大家紛紛都想提議見幫忙,但這並不是「這個會議的目的」。每天5-7人聚在一起,是為了將大家對狀況的認知統一,僅此而已。因為一旦開始討論困難,很有可能變成A和B熱烈的討論起來,其他5個人在滑手機發呆。Scrum Master要根據決定好的目的和時間,具體果斷的打斷討論,讓會議前進。

或許有些人會認為,這樣會破壞創造性思考和創意思維。然而,事實上無止盡的會議才是破壞創造性思考和創意的元兇。在每日會議之後,Scrum Master可以根據遇到困難的情況,重新找適當的人,並且到適當的地點 -- 也就是電腦前面,手腦並用的解決問題,而非在會議室空談。

其他在實況(Scrum)框架中的會議,像是Sprint啟動會議,Sprint結束會議,Sprint檢討回顧會議等等也都是一樣。必然是在特定的目的,特定的時間完成。


將能專注控制的事情完成,才能把時間與思維,留給創意。





註1. 因此,敏捷開發中的Scrum方法,中文翻譯應該叫做「實況」,至少也比google翻譯為「爭球」來的好。

註2. Scrum的學習可以參考這裡-> 學習Scrum,或者->Scrum認證

8/06/2016

Scrum 認證!? 不要再浪費你的錢了!


管理類型的證照無用論,早在軟體工程界提倡Agile Movement的時候就逐漸存在。

以目前看起來取得成本最高的PMP在資訊科技的評價為例:比較客氣的說法像是這篇:雇用有PMP的專案經理需要更進一步了解其能力。而比較不客氣的說法會像是幾篇:PMP毀了專案管理,或者PMP證照無用。(註1)

而這幾年Scrum的方法論,因確切執行之後確實對軟體產品開發有顯著效益。隨之就有各類型推廣,教育,甚至認證產生。

然而,花大錢考Scrum真的有意義嗎?


(1) 認證市場


技術專業認證,絕對有其必要性,例如:醫生執照,律師執照,CCNA,SCJP,TOEIC,甚至,職業大貨車駕照,乙級中廚檢定...等等。擁有此技術執照,表示你至少「會」做某些事。

然而,非技術執照,只證實「考過」某些考試,一旦考試內容和實際會到的問題有差距,該執照就沒有太大意義。只能代表你對某些考試的努力成果。專案管理,企業經營方面的執照就屬於這類。這類型執照如果成本不是太高,倒也無妨。高收費的認證?等於是浪費錢。

一旦有高收費的認證,自然就會有認證教育訓練市場。教育訓練本身是好事情,可以讓人學習成長,但是,教育訓練本身如果是應付考試,意義就降的很低。


(2) Scrum高收費認證為何沒用?


迄今,Scrum認證有很多種類,單就Scrum Master而言,網路上隨便找,都可以找到以下七種,請參見下表。


證照名稱考取成本 (以台幣計算)組織
Certified Scrum Master$30,000 (含16小時訓練課程)Scrum Alliance 
 Professional Scrum Master I 
 Professional Scrum Master II
$4,500

$7,500 
Scrum.Org
Expert Scrum Master$3,000EuropeanScrum
Certified Scrum Master$3,800 (不含訓練課程)
$4,500 (含8小時訓練課程)
GAQM
Scrum Master Certification$13,500ScrumStudy
Agile Scrum Master$5,880EXIN
Scrum Master Accredited Certification$900Scrum-Institute


筆者考過並取得最貴的認證以及最便宜的認證。其價格差距很大(三萬台幣 vs 九百台幣)。單就「考試內容」而言,最便宜的考試內容甚至還稍微難一點點。而最貴的CSM (ScrumAlliance)其實也就是台灣各教育機構最努力推廣的認證。

就考取認證作為職場價值這點來說:

1. 如果是沒有任何軟體專案經驗者,透過高收費教育訓練考取最貴的收費認證,基本上,和只自學而通過最便宜的認證,在Scrum基礎知識上根本沒差別。而在Scrum實務運作上,也沒差別:都屬於完全沒經驗。


2. 如果是有數年軟體專案經驗者,「有無證照」對於專案管理來說,只是履歷表上的一撇,一旦遇到真正的艱難問題:在Scrum上採取正確作法的經驗和收獲,遠比考證照的收穫大得多。因此,昂貴證照和便宜證照也無任何差異。

3. 沒有駕照,就不能合法開車。但沒有Scrum證照,在務實的企業中,只要你有足夠實務經驗,足夠證明支持你的能力,根本沒有問題。反之,如果有Scrum證照,但無法足以匹配的經驗,能力,而再加上創意不足,那麼甚至是有害無用。



(3) 建議作法


如果有想考Scrum相關證照,有三個強烈的建議:1.「自我學習Scrum」2.「確切運用Scrum」3.「考最便宜的」

1. 自我學習Scrum:

學無止盡,無論是Scrum還是其他未來可以出現的方法論,都值得一學。但更重要的是,如何自己學習。任何教育訓練都很有用,但也不可能完全取代自我學習。

自我學習的方式可參考這裡:如何學習Scrum 。以及這裡:如何成為Scrum專家,或者:scrum的缺點,或者 :Scrum三件必要的事

2. 確切運用Scrum觀念與作法在軟體專案中:

任何專案管理上的知識技能,如果不能有效運用在專案管理上,當然就沒有意義。以Scrum的每日會議(無論是不是站著開會)來說,其基本觀念在於:

「限時」 - 15分鐘
「事實」 - 只描述做完的項目,和下次打算做完的項目。(註2)
「困難」 - 只說明困難,不是要在每日會議上解決困難。

也許現實會讓Scrum Master或專案經理有所調整,但如果調整的方式不能切中Scrum觀念,則取得昂貴Scrum證照也沒有任何意義。(例如每日會議花超過40分鐘,肯定不符合任何一種Agile專案方式)

3. 以實力考最便宜的證照:

不可否認,還是有不少人認為一旦履歷表上有幾個証照,似乎會多一點點面試機會。另外,也有些有專案管理經驗者,自我學習Scrum想要有個目標來證實自己。

以這樣的立場,其實考取最便宜的證照即可。而最好是在沒有任何準備的情況下,抱著隨便考的心態。如果這樣考過了,表示Scrum的基本知識已經深入腦海中,考不過其投入成本也不高。

剛出社會的新鮮人,如果覺得萬一在面試時,有人對便宜的證照有疑慮?你可以客氣的敦請他去考考看,了解一下其考試的品質。





註1: 我們不是反對PMP。事實上,在其他工程領域PMP有其必要性。例如:cern的LHC是一個橫跨數十個國家,涵蓋土木,電機,資訊的龐大工程,PMP條列的九大項目,五十多種可能的文件在此就有點必要性。本文反對的是,以PMP(或其他管理證照)來判斷一個專案經理有沒有能力執行資訊軟體相關專案

註2: 何謂做完?(definition of done)也是Scrum team需要在專案開始前定義好的。

註3: coursera.org 提供各種課程修業完成認證,目前沒有ScrumMaster,但是有類似Agile Management的課程,上課是免費,不過,取得認證約為3000~5000台幣之間。

7/29/2016

犯錯怎麼辦 - 光是道歉是沒辦法解決滔天大錯的



人非聖賢,每個人,在任何時間地點,都可能犯錯。而一個人的職業生涯長達數十年,多少都會做出各種的蠢事。

錯誤也有各種不同的情況,細微小錯自然可以迅速改正,但如果犯下滔天大錯,不見得是道歉能夠解決。

最好的情況當然是「永遠不犯大錯」,透過個人本職學能,讓工作不會出現大錯。

但天有不測風雲,有時候錯誤的來源並非是能力不足,只是純屬於結構性意外,更可能屬於前人留下來的問題和漏洞,但無論如何,錯就是錯,大錯就是大錯。

鑄下大錯最好的做法的三步驟是:「面對」「處理」「學習」。但最後最重要的是,發揮創意把劣勢轉為優勢。


(1). 面對 - 承認錯誤,負起責任


如果是自己做的蠢事,道歉當然是必要的。如果不全然是自己做出來的,有時候也需要道歉,例如:企業產品發生問題,而你剛好是產品的負責人,雖然並不是你直接造成問題,但由於你是當時的負責人,自然要負起道歉的責任。

承認錯誤道歉僅只是第一步。負起責任不是簡單的口頭道歉,或者是土下座而已。所謂負起責任是要能「做出」行為。

既然是滔天大錯,道歉之後,隨即就是「妥善應對計畫」。這個計畫,一定要讓受影響的人清楚明白的了解。做計畫要快速,不見得完美,但是要全面,可以使用心智圖來協助達到全面性。

妥善應對計畫就和所有的計劃一樣,計畫的過程(planning)可能比計畫的本身來得重要。計畫的過程會大幅降低「連環出錯」的可能性,計畫的過程會讓「處理方式」變得有效,計畫的過程更可以讓受害的一方的影響降低。

舉例來說,如果某購物網站,因網站管理員操作不當,不小心刪掉資料庫中所有訂單,如果你是該網站管理員,首要之務當然是通知相關人等,道歉再道歉自己發生的錯誤。接下來,擬定「妥善應對計畫」:(1) 評估受影響的客戶數量,試圖從log或其他任何蛛絲馬跡中推估有多少訂單被刪 (2) 評估受到影響的金額,以及已經結帳後如果想退款的快速方式 (3) 首頁建立道歉網址 (4) 建立快速反應小組,提供電話與email讓受影響的客戶聯繫 (5) 相關社群網站或產品網站如果也受到影響需要找負責人協助  (6) 每日固定時間固定地點呈報修復進度 (7) ....這些應對計畫的細項可能有更多,但重點在於,有計劃自然能穩定人心,讓事實可以持續前進,而不會有錯誤的骨牌效應。




(2). 處理 - 誠實處理,控制損害


有計劃之後,接下來就是按計劃處理。處理原則如下:

(1) 誠實

不掩飾,但也不誇飾問題的嚴重性。誠實的處理可以挽回補償的事情,承認並道歉不能挽回的事情。在能力範圍中承諾最大的努力,但也不答應自己根本辦不到的事情。誠實的說明自己的能力不足,但也不能推託自己應該盡的努力。 

(2) 損害控制

既然是滔天大錯,大概一定會有很大的損害。按照計畫,盡可能將造成的錯誤損害降到最低。

(3) 小心骨牌效應

無論是壓力過大,或者環境本身的變化,錯誤常常是一連串發生的。處理錯誤最怕的是一錯再錯。例如,發生重大意外,投入直昇機救援,而直升機又發生重大意外的機率其實明顯的高於一般直升機普通飛行(參閱論文)。

(4) 不馬上釐清責任

此階段的重點在於執行計畫,控制損害到最低。而不是追究問什麼發生,是誰的錯!

(5) 記錄,檢討,修正計畫

即便計畫的執行很短暫,並且很急迫,也不要忘記簡單的紀錄,隨時檢討補救計畫的本身。並隨時修正計畫的執行。畢竟planning本身才是重點,而非plan。



(3). 學習 - 建立不貳過的絕對能力


當處理問題到一定的程度。無法在減低損害,但也不會讓損害繼續發生時。就是檢討學習的階段。

在這個階段,能補救都已經補救,無法挽回也都無法挽回。因此,是要檢討並且未來不會再發生的最佳時刻。檢討的方式有很多種,比較正式的做法為「post-mortem會議」。

會議進行方式採三階段,(1) 事實說明 (2) 事情經過的改善 (3) 避免再發生的作為


(1) 事實說明:


由犯錯的人或者代表人,從事件的開始說明到今天為止發生的事實。僅只是說明事實,並且釐清事實而已。

例如,購物網站不小心刪除訂單,過程可能是因為要釐清報表問題,以commandline方式進入資料庫,由於新增加一筆測試訂單資料,想要刪除資料時,執行delete的動作過程中,竟然忘記加上where condition。

事實說明過程可以提問,但目的是把事實釐清得更清楚。因此不需要問說:「為什麼當初你不這麼做」,也不應該說「你那時候腦袋在想什麼怎麼這麼蠢」之類和事實無關的話。



 (2) 事情經過的改善:


指的是「妥善因應計畫」執行過程中,有哪些可以改善的地方。基本上就是前段所述「處理」過程中的的檢討。如果有紀錄,則應該可以很快找到哪些地方還可以改善。


 (3) 避免再發生的作為:


這個階段就是重要的釐清責任階段。這個錯誤單純是人為錯誤?還是系統性錯誤?環境天災?釐清的過程要伴隨著「為了避免再發生而做的事」

單純人為錯誤:把某個人解僱就之後就不會發生?或需要靠某個檢驗機制?或讓檢查的本身加入SOP?或者過於粗心的人不適合做這個工作?怎麼樣定義何謂粗心的人?

系統性錯誤:這類型的大錯是不是歸咎於之前某人的設計不良?系統設計如何改善?系統性錯誤出現比率高不高?如果不能避免有什麼簡單方式可以大幅降低損害?是不是該雇用高手中的高手做好系統?

環境天災:特殊大地震或者異常天候?很低的機率才會發生?是不是要特別有處理方式?還是因為機率太低,可以視情況見招拆招?還是機率比想像中的高?

可以將所有「行動」逐一列出來討論。

最後,一定要「行動」。沒有行動的檢討,就不具備任何意義。而既然是滔天大錯,就必然一定要行動,才能做到不貳過





I never lose, I either win or Learn: Nelson Mandela

最後,比較罕見的另一個重點:個人的創意與技能,要能將錯誤的劣勢轉為優勢。畢竟既然滔天大錯已經發生,能補救檢討都已經完成之後,有創意的將劣勢轉為優勢,是犯錯的個人最應該想的事情。

例如:一個遊戲app的廠商,推出新版本時,在伺服器端發現可承受的連線數量遠低於預估,導致於許多新玩家無法玩新版本遊戲,而舊版本又已經自動更新成新版本。當然許多新玩家會不滿,但如果遊戲廠商在處理過程中,額外彌補玩家的損失(送出高等級寶物之類),其彌補的方式有額外的創意,這類型錯誤甚至可以額外吸引新玩家加入,這就是一種以創意和技能,將錯誤的劣勢轉為優勢的可能。








7/28/2016

心智圖 - 進入職場第一個必備技能



在畢業之後,投入職場的那一瞬間,假如你突然失去記憶,喪失所有技術能力,你最希望先恢復什麼能力呢?

相信一定是「學習各種技能的能力」「連結不同技能的能力」「延伸整合技能的能力」這類型的選項。概念上類似神燈可以實現一個心願,稍微有智慧的人,第一個願望,一定是希望有無限多的心願。

「心智圖」mindmap是最簡單,最容易學習的能力,可以用來連結學習延伸其他的技能的基礎。它應該是踏入職場第一個必備的技能。

心智圖極端簡單(請參見心智圖wiki),不過就是把心中想的主題畫在一張紙的中間,把跟這個主題相關的重要「事情」「項目」「動作」...等等,用線連在一起,而後還可以再延伸這些「事情」「項目」「動作」到其他細節,或者其他主題。

雖然心智圖很簡單,有不少人宣稱在高中就已經會用,但實際上熟練地使用者卻很少。

下面這張圖就是在撰寫這篇blog的後所畫的第一張心智圖:

這篇文章所用的第一個心智圖

心智圖的繪製,沒有任何特殊技巧可言,它只是想法的延伸。換言之,心智圖本身無法代替思考。但他可以讓抽象思考具體化,讓你更容易有全面的視野來觀察任何主題。這和哈利波特裡面的儲思盆有異曲同工之妙。只是你不需要去念霍格華茲,也可以學會使用心智圖。

經常利用心智圖,對職涯發展有莫大助益。然而,在台灣職場上,卻並不常看到有人使用心智圖,更常遇到某些特殊事情發生之後,才想到「當時如果用心智圖做紀錄會不會好一點」的情況。

其中一個主要因素是:缺乏練習,以至於當下沒「聯想」到有此工具。


有三個工作項目,是最好練習心智圖的機會:


1.  即時會議記錄:


即便有超強的打字能力,有意義,並能快速呈現重點的會議記錄,遠比把所有人講的的話一字不漏的記下來來得重要。臨時的會議,有結論的會議更是如此。

一邊開會,一邊將主題相關的人事物,用心智圖快速連結起來,可以在開會的過程中,掌握要點,避免會議「歪掉」,減少會議常見的三大毒瘤:「會而不議,議而不決,決而不做」


會議還沒開始,先畫出主題以及會議之後的行動
做法很簡單。首先:如果你是主持會議的人,會議還沒開始前,先在白板中間畫個圓圈,中間寫會議的目的。接下來先把「Actions」先畫出來。在會議一開始,就確保會議結束前,一定會討論出作法。如果你不是會議主持人,可以畫在筆記本上,這樣確保會議結束前,萬一Actions的圖形之下,沒有任何行動,也沒有人提及要有會後行動,你也會「主動提出」。

接下來,在與會人士慢慢來到之前,先把會議的背景,要討論的事情大綱,畫在主題的周遭,並稍加分類。以簡單的圖像表示與會人士。


會議即將開始前,先將背景以及可能討問的事項在白板列出來。以簡單的圖像代表與會者的討論。

隨著會議的進行,白板會越趨複雜,當然可以簡單的照相紀錄過。

會議的目的,當然是為了「議」- 也就是為了討論。而討論最佳的方式,莫過於把彼此的思維,投射到可以視覺化的地方。心智圖是最簡單,成本最低的好方式。





2.  分析與設計:


有複雜問題的時,可用以分析。例如:專案資源不足,遇到瓶頸,解釋複雜的人際關係等等。

有需要進行的事情時,可用以分析。撰寫技術類型的文章,就很適合先使用心智圖。

以這篇文章為例,在撰寫之前先以心智圖繪製草稿大綱,然後經過一些考量修正,先修改心智圖大綱到自己滿意的程度,在開始撰寫內文。
這篇文章的最終心智圖草稿,和第一張圖有些不同

各類流程,事物的互動,也是很適合使用心智圖分析。以旅遊為例,如果你沒有精美的行程設計,使用簡單的線上心智圖工具來繪製旅遊計畫,是方便又好用的方式。
以線上工具繪製的東京旅遊計畫




3.  任何超過3分鐘的技術問題討論:


程式設計師,專業白領階級員工常常會有「技術討論」。而技術討論光用嘴巴講效果很差。一圖勝千言,簡單的流程圖,循序圖,物件圖,永遠勝過長篇大論。

UML需要比較長的學習與練習,而心智圖卻很簡單。特別是用於觀念討論,大方向的設計(註1),



app使用者登入討論大綱
以mobile APP為例,在討論技術上,也許有程式設計師,在討論之前,先花上幾天搞個極為細緻的流程圖(例如這個),但很多時候只需要只需要三分鐘,在白板畫個圖就搞定。以右圖而言,顯示這個APP在使用這登入的討論大綱


簡單的東西,通常可以運作得更優雅良久。心智圖並非萬能,它僅只是簡單。掌握心智圖的簡潔,快速,利用它來簡化,分析,記錄事務絕對可以讓職涯事倍功半。





註1: 資訊科技比較完整的分析圖形工具還是以UML比較適合

7/24/2016

為自己工作 - 契合組織目標



雖然這幾年,創業蔚為風潮,但在台灣,大部份的人還是受雇於組織或企業。

「為自己工作」這句話看似自私,但其實所導引的結果才是對企業組織以及對個人有利。至少,對白領階級的知識工作者是如此。(註1)

表面上,大部份的人似乎並不是為自己工作。實際上,會去工作的原因是可獲得報酬(報酬涵蓋:薪資,技能知識學習,個人成長,成就感,社會參與感...等等),因此,無論表面原因為何,也無論自己是否有認知到這個事實,即便是受僱用者,絕大部份的人是為了自己,或者自己的家庭,而工作。

然而,在職場上常聽到各種抱怨心聲。其中有很大部分,其來源是沒有認知到自己是「為自己而工作」:

例如:

  *  工作很無聊學不到東西
  *  自己的價值不受到老闆重視
  *  對公司貢獻超級高,但是相對報酬卻很少
  *  做事人少,出嘴巴的人多 (特別是在政府單位)
  *  組織方向不正確,快要完蛋了

抱怨不是大問題,但失去自我方向之後,就很難在職涯上突破。個人的工作目的,必須要「由自己想辦法契合組織目標」。否則,就會有「不是為自己而工作」的念頭。一旦有這種念頭,很快的就喪失信念以及工作熱誠。

誠如前述:「為自己工作」這句話看似自私,但其實所產生的結果才是對企業組織以及對個人有利。

如果真切的認知到事實是「即使是受雇用,但自己其實是為自己工作」則進一步更能在工作上展現能力,切合組織目標。也更能給予組織更多的價值。因此,認知事實,才是生涯展開的最重要的事情。前述的理由就根本不會存在。

例如

  *  工作很無聊學不到東西:請隨意google一下就知道,企業組織雇用員工,不是為了讓員工學東西。而是解決問題或者產生新的價值。而工作學不學得到東西,也請google一下,都是取決於自己而非工作的本身。

  *  自己的價值不受到老闆重視:員工的價值就像在擺在口袋裡的針,只要你夠尖,有一天一定會穿刺而出。如果你覺得不是被擺到口袋,那就找到一個會擺你到口袋裡的組織。光是抱怨是沒有意義的。

  *  對公司貢獻超級高,但是相對報酬卻很少:先確定是自己的貢獻真的超級高。以業務員為例,許多大企業的業務,其業績是靠著大企業的品牌和產品,而非個人能力。以程式設計師為例,其程式產出,絕大部分是靠團隊能力,而非個人能力。

  *  做事人少,出嘴巴的人多 (特別是在政府單位):也許你的生涯規劃就是要去這類型地方?如果是這樣,也沒什麼好抱怨。如果不是,就趕快離開,也沒什麼好抱怨。

  *  組織方向不正確,快要完蛋了:在一個快沉的船上,就是你發揮能力的時候。如果你自認為是個策略舵手,當然應該矯正組織方向。如果你覺得自己是在大組織裡的小螺絲,那麼你為何能「判斷」組織方向不正確?或許是你的判斷不正確?無論如何,你永遠有離開組織這個選擇。



在大部分時候,人總是可以找到契合組織目標的方式?主要有三種:「自然篩選」「個人規劃契合組織」「創業」

1. 自然篩選


當然,企業組織會自然的篩選「契合組織目標」的人。自然篩選的程度與經濟學上的「看不見的手」有過之而無不及。

例如:一個長期處於保守狀態的組織,自然而然會留下不積極的人。一個以退休津貼優渥的組織(例如公務員),自然而然,就會吸引「為了退休而工作」的人。當然,當一個人拼命念書,絞盡腦汁的通過高普考,一進去公家機關就數饅頭等著退休,自然就不會抱怨「工作無聊學不到東西」以及「自己的價值不受老闆重視」,畢竟,進來這個組織的真正目的,其實是為了退休...。

反過來說:一個新創事業,自然而然會吸引想要透過自己的能力,積極開創一片天地的人。而「退休津貼」就不可能是工作的首要目的。但工作是否有趣,組織方向正不正確,就成為關鍵因素。

雖然,個人沒辦法影響「自然篩選」,但如果你的工作目標,和「自然篩選」的目標不一致,當然會工作的很痛苦,而抱怨連連。

解決自然篩選的方式有三種:(1)離開 (2) 改變自己 (3)改變環境

其中,離開是最簡單的。辭職換新工作,自己創業,創業失敗後再創業等等,都是離開。

改變自己很難。但潛移默化之下,很多人會因為自然篩選的環境而改變自己。

改變環境其實難上加難!但是,一旦有機會做到改變環境,你就擁有一個難以言喻的經歷。這個經歷對職涯有絕對的幫助。



2. 職業生涯規劃契合組織


傳統企業組織都知道,激勵員工很重要。但組織出錢出力,費盡心思的「各種激勵」其實遠遠不如讓員工的生涯規劃契合組織目標。

就前段所述,其實無論如何,自然篩選會讓組織留下契合其目標的員工。但這需要起碼數年的時間,而前提也是組織沒有大的變故。 如果組織 - 特別是營利企業 - 的目標和其展示的行為不一致,自然篩選會失衡,要達到平衡。

因而「以個人力量做出契合組織的規劃」才是最簡單,最容易,最能獲得三贏的選擇。

除了工作內容外,每個人常遇到工作上乍看之下不可伉儷的因素,而認為自己無法契合組織目標。在你還沒有丟出辭呈之前,可以執行的個人能力與選擇非常的多。這些選擇都可以有機會做出契合組織的目標。

例如:

* 每天都做無聊的工作:既然是無聊的工作,表示是重複簡單類型,試著將這類工作最佳化,並自動化(註2)。 不知道怎麼自動化?那就去學阿,在工作中學習成長,並透過自動化的貢獻,不但提昇自己的能力,也讓組織獲取更多價值。

* 工作太多,常常超時加班,生活品質太差:所有企業組織,其存在的目的,絕對不是要員工加班完成目的。其存在的目的都是為了獲利。隨著組織分工,以及各種環境變化,容易產生以「加班」的方式來解決問題。這完全可以避免,請參考:解決專案困難的最爛方式; 如何提高工作效率; 80/20法則。也可以網路搜尋一下任何增加工作效率的方式。

重點在於去做!Just Do It!不去做,永遠不知道加班問題能否解決。

* 加薪升遷不如預期:如果是在大企業工作,加薪升遷的確常常不如自己預料。但如果你確定自己有這樣的價值,一段時間一定會被發現,如果不被發現,在離開之前請先想清楚「自己是否真有這樣的價值」?想清楚的方式也很簡單,可以去試著去應徵其他組織,看看有沒有其他組織願意提供給你更好的薪資福利。如果沒有,表示在當下你的確無此價值。如果是在小企業,薪資福利可能無法有大幅成長,但小公司能提供的通常是更多的自由和自我成長。既然你已經自然被篩選到小企業,或許本來就不是很期待制式的加薪升遷了吧。


* 組織做犯法或遊走在法律邊緣的生意:趕快辭職離開!越快越好。你確定你想要加入犯罪組織或者遊走在法律邊緣?!


3. 創業

創業,當然就是為自己工作,當然也一定會契合組織目標 - 因為你就是組織。倘若你創了業,卻因為各種原因,去做不是你訂立的目標的事情,那等於是沒創業。(註3)

不過創業成功難非常高(參考如何確保創業成功)。富貴險中求,高風險當然比較能伴隨高獲利,如果生涯的志向在此,盡可能參考已經成功的典範,或許能降低失敗機率。







註1: 藍領階級的勞動工作者可能不全然適用。

註2: 同註1

註3: 當然,也許你是共同創業,或者持有股份很少,那麼請視為在組織為自己工作,不要視為自己創業。


7/18/2016

解決軟體專案困境的最爛方式 - 加班





「加班」是解決軟體開發專案困難的常見方式,但也是最爛的方式。(好方法?請參考:解決專案困境的三個方式)

負責控管專案進度的主管或專案經理,如果只會用「加班」這招來解決問題,那就不適合做軟體專案經理。

長期,非自願的(註1)加班沒辦法真正解決問題的各種經驗實證,早在許多談論軟體專案的書籍中存在。例如:人月神話Peopleware約耳談軟體與熊共舞等等。從來沒有看過有任何「專案管理理論或實務認為加班有用」。

最根本的原因在於:知識工作者(軟體工程師),其產出和付出的「超額」時間根本沒有關係,也因此,加班從來都不會解決真正的問題。

既然如此,為什麼加班文化仍然存在?

常見原因有:

1.  短期效應


特定目的的短期加班:例如參加週末創業活動,或者,產品銷售大會之前的熬夜修正demo問題等等。這些特定的目的,固定時間的活動,確實會讓人拼了命「加班」完成目的。但是,短期效應絕對不能當作一般專案管理的方式,大部份的專案都不是百米賽跑!


2.  專案經理本職學能不足,利用要求加班來展示苦勞。


專案經理沒有其他辦法,只會加總人時。因此,即便人月神話從初版印刷上市(1975)到今天已經超過40年!仍然有不少軟體專案經理即便看過人月神話這本書,仍然不可自免得繼續要求加班。因為,如果有加班,即便專案失敗,以往也被認為「沒有功勞也有苦勞」。

但是,以現在環境變化迅速,一個軟體企業中,如果「一直都只有苦勞」,被淘汰的速度遠比過去還要快得多。



3.  模糊的合約。


在某些糟糕的情況下,銷售可能會簽下模糊的合約,當專案經理看到合約內容時,其解讀方式和客戶「截然不同」。在各種專案經理訓練課程,以及各類商管叢書裡,都會說「要良好溝通」,但實務上,當專案經理手上已經拿到不合理,而且驗收條件極為模糊的合約時,幾乎不可能以「溝通」來解決。如果專案經理,誤接燙手山竽,而又沒有足夠的創新能力和技術能力來解決時,通常會誤以為軟硬兼施的「加班」,或許可解決這個問題。

但是,如果這次不能非加班的方式解決,下次就不可能有更好的方式。其後就落入惡性循環。可以google一下「台灣  接案公司」看看目前的現實情況。


4. 心靈激勵。

無論是「要有創業家的精神!」,或者是「我們在做全世界最偉大的軟體」,甚至是「世界的和平,人類的未來就靠我們了」。而又有太多人誤以為,只要有正確的心靈激勵,軟體工程師就可以像電影劇情,日夜匪懈的工作,還能有創造性的思考解決問題。


5. ...很多其他的理由。


如果你是專案管理人員,之前要求成員加班的理由到底是什麼?如果你是軟體開發人員?曾經被哪些理由要求加班? 




既然如此,到底什麼是解決軟體專案困難的好方式?
除了可以參考這裡之外,還有三個原則:


1. 永遠都有選擇 - 「Say No」也是一個選項!


認為不正確的事情就應該說「不」。在正確的時間點不說,只會拖延,就不是個好的專案領導者。


以組織層面的角度:

就專案經理本職學能而言,一旦發現自己不是個好的專案領導者,應該要對自己說不,迅速辭職,改當一個好的程式設計師,或許是對專案最好的幫助。

就專案目標而言,倘若使用這的需求不確定,就應該選擇不做,或者選擇先做mockup,讓使用者確定需求,才不會浪費時間。

資源 - 特別是人力而言 - 在企業組織中,永遠都是有限。而良好的管理是透徹於在有限的資源中做有效的分配。加班不會讓分配變得有效,只會讓無效的分配繼續無效。

以技術層面的角度:

技術永遠有選項。一個複雜的功能,可能有起碼5種不同的實作方式,到底是選擇複雜但是有趣,還是選擇簡單,但是堅固耐用?就要視情況而定。

無論什麼事情,一定有選擇,絕對不會有「我們只能加班」這個選項。



2. 專案擁有人,必須參與專案!


近年來流行的Scrum,有一個必要的要點:專案擁有者(product owner)在每一個sprint之後要檢視產出。這個要點非常的重要,遠比正確做好燃盡圖,每天站著開會來得重要100倍。

專案擁有人,需要參與專案的每一階段進展,確實了解專案的人把時間用在哪裡,並且確實了解,每一個sprint產出都是專案擁有人最想要的產出。如此才能確保「做出對的事情」。

如何讓專案擁有者參與專案,就變成專案管理者「一定要做」的事情。

會把PMP的教材背的滾瓜爛熟 -- 溝通管理計畫書是要建立蒐集擷取散布各處的資訊,以及最終處置專案資訊的流程 -- 但實際讓連每一小階段讓專案擁有者「確定產出是他要的」都無法實際做到,簡直沒有任何意義。

在每個階段發個制式的email,裡面塞了很多複雜的圖表資訊,只會讓專案管理者「誤以為」一切都很順利。把確認每階段產出是他要的這件事情越往後延,風險就越大!


3. 磨利斧頭!


技術上的學習,會讓事情事半功倍。太陽底下沒有新鮮事,你所遇到的困難,可能已經有另外17個人遇過同樣的困難,而其中也許有9個人已經解決,解決的人之中有5個把相關資訊放在網路上。只要有正確的英文閱讀和google查詢能力,並能固定的自我學習,充實自己(參考如何充實自己),通常都能以更好更快更有效率的方式,解決軟體上的問題。

但是,千萬不要把「沒有時間學習」當作理由。當你的斧頭已經鈍到無法砍樹,還試圖用鈍斧頭砍樹來表現自己的努力,這是完全沒有意義。學習的目的就是磨利自己,將知識與技能銳化,才不會以無意義的舉動,做無意義的事情,加無意義的班。






註1: 凡事皆有例外,遇到天災人禍等不可抗力情況而加班其實算合理,不過即便如此,也應是極短的時間。例如,颱風天放假,隔天需要額外的工作時間。自願性質也絕對不會是長期,例如自己去參加創業週末,某種程度是自己為了自己額外工作,但頂多是一個週末,也不可能連續10個週末都在進行這樣的活動。

相關文章:
-->  換工作的面試-軟體工程師如何展現價值
-->  靠感覺做專案管理 - 鐵定失敗
-->  如何提高工作效率:三個務實的快速步驟
-->  心智圖:職場的第一個技能
-->  你確定知道專案進度嗎?
-->  80/20法則之軟體專案的三個運用重點