顯示具有 learnning 標籤的文章。 顯示所有文章
顯示具有 learnning 標籤的文章。 顯示所有文章

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


9/14/2016

企業巫醫 - 人才管理...人才根本無法被管理


任何能在企業講幾個小時的顧問,都一定會說「在組織中,人的問題最重要」

雖然這句話說的似乎很有道理,但是等同於廢話。這和「颱風明天會來,所以會刮風下雨」一樣,人盡皆知,說了等於沒說。

但是只要是軟性的課程,例如:成功主管的教練技巧之類。都會開宗明義的,告訴虛心向學的主管們,「人的問題很重要」,並且在接下來的8小時,展示一些似乎有用,但很難執行;或者幾乎沒用,但容易執行的技巧,來讓經理們主管們理解:「人的問題很重要 - 但是也實在太難  - 請自己好好體會,好好努力吧」。比較好的顧問,會拿自己豐富的失敗經驗(註1),用作為警惕 - 這樣還算有價值。但只靠講話的顧問,就只能如同電視名嘴一樣,以幽默的方式打發大家的時間。

既然知道困難,也應該認知困難的地方,透過承認困難,踏實的因應困難,才能在人才培育與經營上找到對組織有用的創造性作法。

對於眾多企業巫醫來說,讓事情變得越複雜,越困難,越不能解決,自然就容易強化巫醫的效果,並且萬一巫醫的作法不靈驗的時候,也容易找到推卸的方式。畢竟,是惡靈不願意配合你的祈求,不是巫醫的錯。

如果你恰巧是資訊科技的主管:無論是軟體開發團隊經理,或者資訊部門主管,只要你負責「管理」團隊,則團隊的人才經營策略,應該會是你最先要考慮的。

無論組織有多大,無論你的職位有多小,無論人資部門的策略是什麼,無論工作壓力有多大,無論專案團隊所使用技術多神奇......無論任何理由,團隊的人才經營策略,應該是團隊主管首要考量的事情!

每個困難,作為負責管理人才的主管,都應該試圖做出合邏輯的,可執行,有創造力的解決方式:

困難一:區別人力與人才


人才之所以難管理,是因為「人才」根本無法被管理。「人力」才能被有效管理。

所有大型組織,很難真實區分人力跟人才。即便是做機械性動作的生產線員工,在效率和品質上仍然有極大的差別。從早期豐田Toyoto的全面品質管理(TQM)開始,到1999年許多人的智慧統整出精實製造(Lean Manufacturing):揭示了一件明顯的事實:

「實際做事情的人,才是真正知道怎麼做的人」

但是,這個事實卻也隱含著另一件事情:

「在實際做事情的人之中,有些人才,才是真正知道怎麼做才好的人」


但人力跟人才很難區分。以資訊科技為例,任何可衡量的指標,都只能短暫有限的區分人力和人才的差別:無論是寫程式的速度品質,完成任務的完整度時間,程式維護的難易度,對新技術學習的速度等等。這些可衡量的指標,可以很快挑出老鼠屎,可以有效的找到連人力都不算的冗員,但卻很難在短時間裡認出千里馬。

把所有可找到的指標,綜合起來,確實比較可以找到潛在性的人才。但是所花的時間成本太高,而且利用指標的做法,很可能會無意間讓組織朝向「指標」前進,而非「目的」前進。

例如,以軟體專案為例,如果指標是「完成code行數」,配合「每千行code發現的bug比率」,則有可能會產生一個大而無用的系統,程式碼很長,而且根本不會被用 - 當然也不會有bug。

任何在人才策略上,所使用參考的指標,最好都是「隱性」指標,而且必須是簡單有用,常常可以反覆檢驗。例如,這個員工,過去12個月,曾經「主動」提出並且「實作」過哪些軟體專案重要的模組。或者,這個員工,在過去12個月,曾經「主動」做過哪些和軟體品質相關的事情。


此外,以過去的貢獻和產出為區分的標準:這在軟體產品開發上是一個稍微可行的做法。但是,所謂的過去貢獻,不應該是過去35年的貢獻和產出,頂多是過去3年的貢獻和產出。而也必須要確保,這些產出,能有效被歸屬。

舉例來說,一個軟體團隊有10個工程師,共同完成一個很了不起的產品,然而因為市場的關係,產品銷售不好,最後也停止銷售。這10個工程師,仍然擁有產出的貢獻歸屬。但是!這個軟體專案的專案經理,就應該承擔產品錯誤的責任歸屬。然而,由於大部分的產品經理都能言善道,因此,最常看到的是產品經理拿著過去失敗的經驗,拿來宣稱他「從錯誤中學習」,「得到寶貴的開發經驗」,更糟的是宣稱「產品的方向沒問題是公司策略改變」。

從錯誤中學習當然是寶貴的經驗,但是「必須真有學到,然後在爾後,因這些錯誤經驗而成功」。單只有「失敗的經驗」對未來毫無意義。請參考飛鼠裝跳傘(註2)。


在科技軟體產業,最踏實地的區分出人才的方式是:

(1) 面試時以情境實例面試法,了解他過去「做過的事情」,而不是未來「想要怎麼做事」

(2) 衡量工作情況是以「做出來的結果」,而不是以「講出來的結果」,當然也不是以待在公司時間長短,請假的多寡,發表的意見等等...

(3) 盡量試圖找出人才,而不是找天才。換言之,每個人都有某些能力和特性是組織所需要的,只要這個人可以把能力和特性「貢獻並且產生」出來,那麼他就是人才。反過來說,如果他會10種程式語言,還專精6種作業系統,並且還可以解決NP compete問題的難度。但是,卻因某些因素,沒辦法貢獻他的能力到組織或專案中,那麼他依然「不是人才」



困難二:培育或取得人才


資訊科技產業大部分都會宣稱自己很願意培養人才。少數倒是很誠實地說,他們想要直接用挖角取得人才 - 特別是最近幾年的中資企業。

由於培育人才表面上會遇到「培育後被人挖角」的風險。並且,取得人才,表面上通常能在比較短的時間,開始貢獻到企業。因此,許多在成本上沒有限制太多的企業,對於中階人才使用直接取得,也就是挖角,的機會越來越大。

這兩者都有很大的困難,但就資訊科技的角度而言,無論打算培育,或者直接到人才市場找到最適當的人,都不可能避免要「人才培育」。

資訊科技人才無法由人力資源部門統籌培育,必須要由技術性的部門執行,但是技術性的部門卻不見得有空,也不見得會知道重要性。

因此,常見情況是:「我們是on job training,有問題盡量問」。

代表事實就是:「我們不會,也沒有時間訓練你,將工作交給你之後,你就要自己想辦法學習,並且搞定它,當然有問題資深的人如果有空就會回答你。過一段時間你能生存下來就是好員工」

這表示,這個組織對人才培育的策略是......沒有策略,完全看個人造化和運氣。當然,最後的組織在人才運用的結果也是看造化和運氣。

對於規模夠大的組織,其實是可以用所謂沒有策略的方式,因為人數夠多的情況下,某些人才常常能夠單靠自己的能力,脫穎而出。但是在這種情況下脫穎而出的人才,很容易就會被其他組織「取得」。

雖然人才培育很困難,但是比較腳踏實地的做法是:

(1) 對剛加入的人,無論資深還是資遣,根據組織的現況,給予1-3個月的足夠學習期間,訂立學習計畫,在還沒有正式給予任務之前,有對整個團隊,先有全盤性的了解。

(2) 對於已經在組織很久的人,盡可能就現有的專案,進行延伸學習,這個延伸學習不見得是要去上課,可以提供他們「考證照」的經費,讓他們透過「考證照」來主動學習。請謹記:考證照不見得要考很貴的,因為重點不是在於證照本身,而是在於學習。


困難三:薪資獎勵


對於白領技術人才而言,薪資獎勵難以取得真正效果。

首先,傳統的增強理論,對人才:完全沒用!完全沒用!完全沒用!

但是對人力或冗員倒是有些效果。但企業組織為了表面上的公平,通常會試圖制定一體適用的政策,因此,大部分的傳統企業,或多或少都會運用蘿蔔跟棍子。

薪資獎勵,無論有多驚人,都屬於保健因素。換言之,如果不滿意,就很難留住人才,但如果滿意了,也只是「錢有到位」如此而已,一旦不能滿足激勵因素,換言之就是「心委屈了」,仍然無法用薪資獎勵來留住人才。

但反過來說,用夢想,希望,成就,甚至改變人類的命運等等「自我實現」的理念來作為取代薪資獎勵,恐怕也絕對行不通,因為激勵因素和保健因素,兩者無法互相取代。參考:雙因子理論

大型組織中的某部門,或者某團隊負責人,通常也無法對薪資有大幅改變的權力,頂多是在年度考核的時候,決定某個人加薪的多寡,或者紅利的多寡。薪資獎勵,對有足夠規模的公司而言,整體結構早就是固定的,第一線主管僅有調整的空間。因此即便可以透過薪資獎勵來激勵員工,也不可能巨幅調整。即便可以巨幅調整,也不可能長期滿足。

因此,資訊科技根本不可能用薪資獎勵的方式激勵人才,留下人才,讓人才持續對組織貢獻。

既然不可能,就要換別的方式:



不大幅使用薪資,也能激勵好人才的方式:


(1) 選擇


提供選擇,或者讓團隊了解選擇。

早在2008年,Zappos就已經設立了離職獎金。讓想要離開的員工,更容易選擇離開。因為,一個勉強留下工作的人才,肯定不會認真付出,他就會成一個人力,更慘的是會變成冗員。而組織要花更多的時間成本。

在台灣作為第一線主管,大概很難說服人力資源部門執行這麼激進的作法。但是,在職權範圍之內,可以清楚的告訴成員,離開組織是一個選擇,當然很歡迎你做出「貢獻」組織的選擇。大部分的人才,在被鼓勵自由選擇的情況下,一旦做出留下的選擇,其貢獻一定會是「人才」的貢獻。

這也不是什麼新鮮事。

從1945-1962年間,不斷重複進行蠟燭實驗。到最近一本很紅的書:如何讓馬飛起來,之中提到的Amabile所做的獎勵 vs 選擇研究。都不斷指出,有創造性的工作,在事先已經知道有獎勵的情況下,其實績效比較差。

以下摘錄自「如何讓馬飛起來」一書:


60名大學生,他們將參加一項人格測驗才能拿到學分,測驗過程中,研究人員假裝錄影機壞了,無法繼續進行。然後她告訴其中一組,稱為「無選擇─無獎賞」組,他們必須完成拼貼畫來代替測驗。另一組「無選擇─有獎賞」,必須完成拼貼畫,但是可以得到2美元。詢問第三組「有選擇─無獎賞」,是否可以做一幅拼貼畫,但沒有任何獎金。再問第四組「有選擇─有獎賞」,是否願意做一幅拼貼畫,拿2美元獎金。為了加強獎金效果,她在獎賞組創作時,把兩張紙鈔放在他們面前。最後全部的作品由一組專家進行評審。這次實驗裡,獎賞果真激發出最有創意的作品──來自「有選擇─有獎賞」組;但最沒有創意的作品,也與獎賞有關──來自「無選擇─有獎賞」組。沒有獎賞的兩組,得分在兩者之間。就創作而言,選擇改變了獎賞所扮演的角色。創意表現最差的那一組,問題顯而易見:他們感受到的壓力最多。
「無選擇─有獎賞」,正是大部分上班族工作時的實際處境


但是,如果這個獎勵,是事先有選擇性的,也就是可以選擇,那麼績效會更好。文中所提到上班族工作的情況是,無選擇-有獎賞。

其實第一線主管,是有機會加以改變:只要坦然的羅列選擇,不斷的提醒團隊成員:「這是個全然自由的世界」,「你可以去你想要去的任何地方」,「我絕對不會阻止任何人離職,甚至會幫忙寫推薦信」,當然也要提醒:「我不想要任何人離開,在這個團隊我們會讓每個人有機會成長為人才」,「雖然我不能保證薪水,但我能保證你必有成長」


(2) 人才合作 vs 人力合作 


團隊如何合作,是主管最能影響團隊的事情之一。簡單的說,資訊科技團隊必須要能先考慮彼此優勢,透過發揮彼此長才合作;而不是考慮彼此的劣勢,透過避免發生問題的方式合作。

只要參考經濟學上的比較利益法則,找到團隊成員彼此間比較利益的優劣,就有機會讓大部分的人「變成」人才。

但如果在工作分派是以「剛好誰有空」這種區分方式,就會讓大部分的人變成「人力」。


(3) 成長優先 vs 產出優先

人才的成長培育優先,或者產出也就是績效優先?乍看之下是二選一的問題,其實是必須要獲得雙贏的問題。


作為第一線主管,必須要透過培訓以及帶領的方式,有效讓人才成長,透過人才成長,讓產出更有效率。

如果面臨二選一的情況,在短時間當然選最適合的。但是中期長的規劃,必須一定要能滿足兩者。






註1: 通常不太會有成功經驗的分享,因為在人才管理有真正成功經驗的人,很難有機會變成企管顧問。

註2: Franz Reichelt, 飛鼠裝的先驅,然而他過去的飛鼠裝實驗都沒成功過,就嘗試從艾菲爾鐵塔跳下,結果當然是...




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中。

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


外部取得資料



9/02/2016

數據分析從零開始 - (1)事前準備



當你打算從零開始,變成一個有足夠能力的資料工程師,一開始會需要準備基本工具。而隨著時間過去,自然而然你會瞭解並且學習到更多工具。

在此提供簡單的確認清單(Check List),讓在打算開始學習並應用數據分析時的準備參考。

1. 電腦


既然是資料分析,電腦自然是必備工具。

最推薦的是Mac的notebook,如果沒有太大的經濟壓力,最好買記憶體越大的越好。13吋MacBookPro,RAM 16G價格大概四萬八。其他可以考慮dell的linux desktop


選用Mac或者OS為Linux的電腦有許多原因,內建的終端機(terminal)可在bash等環境快速執行各類型資料處理的前期工作。現在windows也有powershell,並且至今技術工程師在對比unix/linux的shell時,常常會有各種爭論。

不過,就打算從零開始的數據工程師,別想太多,就選unix/linux吧!

2. 作業系統


無論你的電腦是桌上型還是筆記型,無論他原本是什麼作業系統。你都需要一個Linux作業系統。在MacOS上可以安裝VirutalBox或者VMware來執行Linux虛擬機器(VM)

3. 基本知識技能與其標準


雖然說是基本,但真要搞定以下知識與技能需要很長的一段時間,就從零開始的情況而言,「盡你所能」的了解以及練習是不二法門。


(1) Linux基本操作:在終端機(或者Shell)中,完全了解以下幾圖中的指令的意義:
(圖一)


   (圖二)

   (圖三)

(2) 網路工具自我學習與操作:能有耐心的看完這篇AWS CLI,並且能用AWS CLI上傳檔案到S3。在整個過程,僅使用官方文件,不在google上搜尋非官方說法。

AWS有提供許多免費工具,用在資料分析上非常適合。但是如果你有PB等級的資料,在AWS上做大數據分析是非常花錢的。

(3) 程式設計基本能力:利用python或任何程式語言,將台北市的住宅竊盜公開資料處理分析加總之後,列出各區的竊盜案件次數表。這裡要注意編碼(encoding)的問題。
如下圖:

(4) 英文閱讀能力:

其實英文閱讀能力對數據分析,甚至其他技術學習是非常重要的基礎。如果不習慣閱讀英文,而老是只查中文網頁,那麼就等於少了60%的網路知識存取。

如果對自己的英文閱讀能力有疑慮,可以先試著不查字典看完這本書:How To Read A Book,這本書用詞遣字相當簡單,而書的本身就是「增加閱讀能力」的方式。因為是本很老的書,應該很便宜,或許早已經沒有版權?

9/01/2016

企業巫醫 - 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的學歷可能會創造出一個一個的企業小巫醫,在組織裡三不五時的拿一些最新的企管叢書,當做驅趕惡靈的樹枝,到處鞭打真正在做事情的人。


企業巫醫相關文章:

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

實習生的三贏

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

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

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認證

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/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法則之軟體專案的三個運用重點


7/12/2016

如何充實自己:大量閱讀的三步驟




閱讀是充實自己的最簡單,便宜,有效的方式。

閱讀不需要花錢去買書,以新北市的居民為例,只要就近找一個新北市圖書館的分館登記成為讀者,就可以線上借書。如果在該分館沒有,還可以運送其他分館或者總館的書到你最近的分館領取。方便到幾乎沒有藉口不閱讀。

閱讀是許多人的休閒活動,在躺椅上一邊讀喜歡的書,一邊吹著微風,是悠閒人生的象徵。小說文學,遊記漫畫,在這個情景下是再好不過的書。

但如果為了充實自己,那麼大量閱讀是有很大的幫助。

所謂大量閱讀和傳說中的超強速讀並不一樣

傳說中超強速讀,則是存在某個不太認識的人身上的特殊技能,總是會人試圖花錢去學習這個從來學不會的特異功能。

大量閱讀是在同一個主題下,透過不同作者的觀點來建立自己在這個主題下的知識。大量閱讀是閱讀超過7本以上同類主題的書,並且透過前人的知識,建立對這個主題的全面性概觀。


步驟一:選定主題,取得大量書籍



為了充實自己的大量閱讀,需要有個主題。例如:「創業」。也可以將主題縮小或者放大。例如:「精實創業」就是縮小範圍,而「企業管理」就是放大範圍。

有了主題自然就要去取得書籍。除非很有錢,否則大量書籍會先從圖書館借。現在圖書館幾乎都有線上查詢的網站。在線上查詢網站,查詢該主題。


以「精實創業」為例,在新北市圖書館網站,竟然只查詢到兩本。基本上除非主題過於偏僻,這種情況太不可能,當改為「lean startup」查詢之後,就找到了52本,雖然裡面有幾本不太相關,不過數量也已夠多。稍微瀏覽一下書名和簡介,就直接利用線上借書功能,盡可能借到不能借為止!通常是10本左右。



切記!!先別在網路上搜尋這個主題!!


由於撰寫網路內容的成本非常非常低,確實有可能搜尋到片段知識,但對於充實自己的角度來說,弊大於利。除非已經對這個主題有一定熟悉程度,只是需要找到特定問題的答案,否則在這個階段完全不適合利用網路!



步驟二:閱讀


等拿到那幾本書,就要開始閱讀。

大量閱讀的「閱讀」要從目錄開始。假設相關主題的書共有10本,先將這10本書的目錄,大致瀏覽一遍。根據自己的感覺,先列出哪些「章節條目」是重要的,那些可能是不重要的。對於某些「條目」 如果有很明顯的「正反面意見」就要特別留意,這個條目可能很重要。

目錄瀏覽過,就表示應該產生基本的心智圖筆記(參見步驟三)。現在請排序找到前三本要讀的書,將三本書依序讀過。

接下來,在記憶中,將這三本書的重要關鍵項目,轉折點,列在心智圖筆記中。這時候心智圖可能會一改再改。鉛筆會是最好的選擇。

當心智圖筆記大致完成,檢視自己的知識,看看對哪些條目有更深入的興趣,將剩下的7本書,以「條目」的方式閱讀。剩下的書,不需要每本的從頭看到尾,但是,可以針對有興趣的項目,或者重要的項目,特別橫向閱覽所有關於這個條目的章節。當然在過程中,如果發現這7本書裡面,有寫得非常好的,當然也可以從頭看到尾。



步驟三:心智圖筆記

專案管理的心智圖筆記


雖然說是步驟三,但是其實在閱讀的當下,就應該先做筆記。而心智圖,是最好做筆記的方式。

在閱讀的開頭,可以先把「主題」畫在中央,然後把書本的「章節條目」根據自己的興趣以及自己的分類方式,「記錄」其關聯性。這樣的紀錄,並不一定以章節名稱。以右圖為例,這個圖示紀錄「專案管理」這個主題的心智圖,其中右邊第一項「Practical way」指的「實務做法」,因此從專案計畫,執行,產出,結束,都被分到這一類。

注意!心智圖筆記的關聯與分類,乃是根據讀者(也就是你)的想法和關聯而來,他並沒有所謂對錯,他是讓你的心緒能夠抽離。除非你有鄧不利多的儲思盆,否則,這是目前已知最簡單最快速能讓你的思維視覺化的方式。






參考:如何充實自己:三個務實的快速方法



7/06/2016

如何提高工作效率:三個務實的快速步驟





Give me six hours to chop down a tree and I will spend the first four sharpening the axe. 

 - Abraham Lincoln

白領工作者,或者,知識工作者的工作,追根究底是利用智慧知識和經驗,做出一些行為。例如:行銷經理,就是擴大產品的市佔率;軟體工程師,就是產出程式碼;業務員,就是賣出產品; 言情小說作家,就是寫書;專業經理人,就是領導管理團隊完成任務。

只要是知識工作者,不管用什麼方式衡量工作效率,理論上都可以持續提高。

就概念上來說,工作效率來自於三大方向,(a)技術與知識,(b)環境,(d)心理層面。

技術與知識。需要靠學習與經驗累積,而正確的學習和正確的經驗累積更為重要。請參考這三篇相關文章:自我學習的方向片段知識的危害工作中學不到東西

環境。如果週遭都是工作效率極高的人,自然而然就會主動提高效率,然而環境有點運氣成分,大部份的人很難控制周遭環境。

心理層面。從馬斯洛需求階層論,到赫茲伯格的雙因素理論,心理與管理學界不乏各種相關的研究以及結論。但知識工作者,可以先參考Ted的這篇


工作效率,絕對會和「超過」的工作時間呈反比。長期的加班對絕大部份的知識工作者而言只會降低效率,拖延成果,殘害自己與家庭。尤其是對剛進入職場的新鮮人,提升工作效率是最最最最重要的事情。工作效率的提升,會伴隨知識技能的成長,更多的時間運用,以及對組織產生真正的價值。高效率地利用時間,可以產生對職業生涯的正面循環;低效率的長期加班,則會產生很難逆轉的惡性循環。


只要願意嘗試,每個人都可以利用以下三個務實的步驟,持續並快速提升績效。做法很簡單,只需要筆記本和筆:

(1). 15分鐘每日計畫


每天開始工作前,先不要開電腦收email,而是拿出筆記本和筆,把今天最重要的幾件事情寫出來,分類事項,決定今天要先做什麼,要完成什麼,參考這篇的分析。切記先完成重要且緊急,以及重要不緊急的事情。

每日計畫只是簡要列出「打算完成」的項目,並且花一點點時間,沈思哪些真的可以完成,哪些是在80/20法則中最重要的完成項目。 也可以加上一些「保留」時間,用以處理意外。

(2). 15分鐘檢討改進


每天結束工作「後」。拿出筆記本,看看今天開始計畫的事情,哪些完成,哪些沒完成,哪些真的重要,哪些其實後來發現不重要。自己檢討一下自己的判斷為何不正確,為什麼該完成的事情沒完成,並且,簡要記錄一下,完成的項目大概花了多少時間,未完成的事項是因為什麼原因。


(3). 15分鐘重點學習


改進檢討結束後,找一小段時間,再把筆記本拿出來,看一下那些比預期晚完成的事項,哪些是因為自己的知識技能不足,導致太晚完成。列出這些項目。特別是找到「厲害的人一下子就可以做到」的事項。舉例而言,excel的PivotTable是資料分析的最基礎的方式,也是做big-data模型時,小規模測試的最好參考,會妥善利用PivotTable的資料專家,會比不會用的人更節省時間的驗證自己的模型。

在筆記本列出需要學習的項目,每天花15分鐘,在網路上學習這個技術或知識。每天只要專注於「一個能提升效率的事情」就綽綽有餘了。




知識工作者最悲慘的情況,莫過於努力了好幾天去做一件完全不需要做的事情,或者完美的執行一個完全不對的方式。

如果還沒有找到最適合自己的方法,請按照這三個務實的方式,每天花不到45分鐘,在2-3週之後一定會有顯著的效果。




這篇文章的乃是根據以下書籍參考,匯整,並且實際執行之後的結果。
- Getting Things Done  
- The Productivity Project 
- The 4 hour work week
- Lean startup
- Do Over

6/03/2016

剛畢業準備加入開發團隊 - 三個必要的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. 經過產品經理確認 才算?

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

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