顯示具有 搞定工作問題 標籤的文章。 顯示所有文章
顯示具有 搞定工作問題 標籤的文章。 顯示所有文章

4/20/2017

數據分析 - 獵人頭如何從Github尋找人才?


前陣子遇到某特殊的獵人頭hunter公司(參考:這裡),竟然是透過分析統計在github, gitbucket的程式庫,來找到軟體人才。

目前,github使用者數量仍屬商業機密,但估計約在2千萬左右(參考:這裡)。當然,使用者大部分從事軟體相關的行業。

資訊科技,特別是軟體的實際成果,容易在網路上展示。因此,如果要找到「軟體開發人才」,github是一個很好切入的地方。一般獵人頭可能會人工搜尋,但身為工程師,當然是寫程式找到大量資料。

從github找人,這做法有一些顯而意見的好處:

1. 有可能看到此人實際上寫的程式碼
2. 有可能了解最近此人的工作範圍
3. 很快找到此人的聯絡方式(email)部落格或其他技術相關資訊
4. 有可能找到此人合作對象
5. 有可能看出此人的英文語言能力

當然也有些顯而易見的缺點:

1. 當然找不到那些不在把專案程式擺道github的人
2. 此人可能只是擺放玩樂性質的程式
3. 只能有機會看得出技術能力,非技術能力仍然需要其他佐證
4. 資料範圍過大,很難逐一肉眼看完

雖然我不是獵人頭,但基於工程師的精神,就嘗試一下解決「資料範圍過大,很難逐一肉眼看完」的問題。看是否能透過程式取得並處理gitbub資料,找到潛在挖角對象清單。

實際上做的步驟如下:

1. 了解gitbub資料如何取得:


github提供api可供程式使用。和許多Web Service一樣,也有完整的文件,請參考這裡


2. 以程式取得少量測試資料

github的web api測試起來很簡單。舉例來說,如果你已經登入github,用以下這個URL request就可以找到,以javascript與nodejs為關鍵字的所有程式庫:

https://api.github.com/search/repositories?q=topic:javascript+topic:nodejs

當然,他的回應是json格式,需要簡單地用程式轉換。例如下圖,乃是搜尋和javascript相關,並且其位置在台灣的使用者:



測試資料回傳乃是json,調整格式成為csv,以便於日後在excel做簡單分析。


3. 了解測試資料內容


如果已經有在使用github,那麼對於回傳的資料應該很清楚其內容意義。

如果不太了解github,就需要找對軟體版本控制系統有些認識的人幫助瞭解其含意。

這上述的範例:「搜尋和javascript相關,並且其位置在台灣的使用者」來說,程式會刻意收集following(有多少人在跟隨這個人的更新),follower(這個人跟隨了多少其他人)。此外,程式會額外計算push和javascript相關的程式庫的次數,取名為work,表示和javascript的相關工作在過去一段時間的次數。


4. 撰寫簡單統計程式,大量取得資料


當然,這個程式就放在github上。請參考這裡

程式本身是python撰寫,需要有github帳號密碼才能使用。


5. 結果


以上述範例:「搜尋和javascript相關,並且其位置在台灣的使用者」大量取得資料並且「過濾可取得公開email」的人數一共是661筆。並且取最前面的199筆,給熟識的headhunter (獵人頭) 鑑定看看是否有效果。

目前的回應都是此資料非常有用。

3/31/2017

企業巫醫 - 向上管理的實務作為?



向上管理是個歷久不衰的名詞,它和「人格特質分析」「領導與管理」等名詞雷同,每隔一小段時間就會以各種形式,出現在企業巫醫們的討論中。

近期隨意查詢就可以找到不少相關文章: 向上管理(cheers雜誌),如何讓老闆聽我的反對老闆的六種方式向上管理的四步驟 ......

「向上管理」向來是一個譁眾取寵的話題,眾多企業巫醫仍然以泛泛之談,試圖教導並解決一個現實而又務實的問題。

企業巫醫,總是能選定看似重要的無法辯駁,共通的話題,而且此類話題完全視個人情況而有截然不同的作為。因此,企業巫醫可以提出極端空洞的說詞,卻又多少讓人覺得有趣。除了「向上管理」之外,「創業」「創意」「領導與管理」「人格特質」等等都是屬於這類。

實務上,「向上管理」不能是打算進行的行為,而是產生貢獻中的其中一個結果。換言之,追逐向上管理,等於是捨本逐末的追逐影子行為。

因此,先務實地做到基本三件事情,假如踏實的做到了,向上管理就不是問題,而是附帶的結果。

1. 真正了解關於自己的現況事實

事實現況聽起來簡單,要找到也很簡單,但是要承認自己的現況事實其實有點難。

事實必須是清楚的,不模擬兩可的。例如,假設你是NBA球員,去年平均上場25分鐘,平均得分14分,這就是事實。至於你的技術能力好不好,並不是「事實」的一部分。以資訊科技的相關工作來說:參與過專案是事實,寫過java/python程式是事實,取得JSCP證照是事實,有Scrum證照是事實,帶領過開發團隊是事實,參與open source相關研討會是事實。

然而,具有良好溝通能力不算是一種事實,喜愛資訊科技不算是一種事實,

現況也必須是清楚的,不可能模糊。例如,目前薪資是現況,工作年資是現況,是否有直接report的人(也就是是否為管理者)是現況,最近一年有沒有拿到其他公司的offer也是現況,曾經拿到比現在薪水高的offer也是現況。

然而,覺得自己薪水被低估不是現況,覺得自己不受到重要不是事實,幾乎大部分的感受也都不是現況的一部份。

請參考這裡這裡這裡


2. 讓自己的實際產出超乎期待 


二因子激勵理論,描述「保健因子」和「激勵因子」兩種個人激勵因素。而其實這也是務實的評斷自己工作的方式。請參考這裡

要確定自己的產出超過期待,必須要確定產出有「超出」。

以基層程式設計師而言,在過去一年該寫的程式功能都有如期完成,並且品質在一定範圍之內。這樣的工作內容並沒有「超乎期待」,只是滿足「現在的薪水」而已。

要超乎期待的方式有很多。最容易的方式,是在目前工作範圍之外,「額外」並且「主動」完成有意義的事。例如,以基層程式設計師而言,在過去一年該寫的程式功能都有如期完成,並且品質在一定範圍之內,並且,主動地在額外的時間舉辦小規模研討會,分享工作上技術的進展。另一個例子,以基層程式設計師而言,在過去一年該寫的程式功能都有如期完成,並且品質在一定範圍之內,並且,由於主動學習其他程式語言,因此在其他專案上也能做額外貢獻。


3. 建立短中期職涯計畫並確實執行


在資訊科技產業中,實踐長期職涯規劃幾乎是不可能(註1)。

然而這並不代表自己現在就應該隨波逐流,看主管決定什麼就做什麼。個人應該要維持短中期的職涯規劃。特別是短期規劃。

短期規劃,必須要和技術能力以及現在工作有密切相關。

例如:

「作為一個程式設計師,未來8個禮拜,要能學會Scala基本用法,並且提出現在產品裡用Scala做分析的計畫」

「作為一個QA新鮮人,未來4周,要能將現在100個手動測試的case,至少其中20個變成自動化測試。同時,原本的工作也不會拖延」

中期計畫乃是半年到2年左右。必須要是「可以明白斷定達到與否」的目標。

例如:

「作為一個QA新鮮人,在2年內我想要變成資深QA,斷定是否為資深QA是以是否升遷或取得其他公司資深QA的offer」

當你完成數個短期計畫,通常表示你也踏實的逐步成長。即便有些短期目標沒有照時間完成,也沒關係,幾次之後,仍然是踏實往中期目標前進。

重點在於:這些目標是你自己決定的,並非主管或其他人硬塞給你。而目標既然和目前工作有關,自然就會協助你在工作上成長。


......
如果你非常非常確定已經完成以上三點,但覺得在這個組織中的成長仍有阻礙,還是很需要「向上管理」,用以獲得好的評價,獲得升遷?這基本上是不太需要,因為你應該儘速離開這樣的組織才是最好的方式。




註1: 「長期職業規劃」和「個人理想夢想」並不同。個人理想夢想可以需要很長很長時間實踐,也可能只需要很短的時間,也可能和職業無關。當然個人夢想就需要長期投入,也可以規劃,也可以不規劃。不過,不投入自己時間的夢想,通常就是空想而已。

3/23/2017

企業巫醫 - 贅字 廢話 泥巴仗




在組織中,溝通合作是大部分的人一定會做的事情。

溝通合作說起來簡單,畢竟人類是靠群體合作而存活在地球上。不過,在企業內部的有效溝通並不如想像中的容易(註1)。

某些人在對話或文字表達上,有意無意的更增加溝通的難度。如果是無心的,僅只是造成困擾而已。但如果是刻意為之,會讓溝通困難,讓事情滯礙難行。

無論有意無意,溝通上常見三個問題:「贅字」「廢話」「泥巴仗」

在這三個之中,贅字和廢話很煩人,但真正要解決的是可怕的泥巴仗。


贅字


典型的例子,像是最近淡江大學解聘兼任教師的新聞:高教工會主任:「學校也一再地向(兼任教師)表示說,也是因為今年的8月1日,勞基法要開始適用於,未具本職的兼任教師身上,學校不想負擔這樣的人事成本,所以他們才會做了一個解聘跟不續聘的動作。」

有人稱這類型的贅字為「語言癌」。(註2)

凡舉「關於XXXX這個部分」,「做一個XXX的動作」,無意義的拉長語句都是。

當然也有些人認為拉長語句是「敬語」的表達方式(註3)。

此外,狀聲詞:「嗯」「唉」「阿」因為在對話中,有實質表達情緒的功能,所以不算是贅字。

不過,贅字真正的影響其實很小,只是太多贅字會讓聽的人很不舒服而已。



廢話


在說明事情,或者文件上,用過多虛浮的形容詞,掩飾無意義的內容。或者,重複不證自明的真理,用以掩蓋無法找到重點的對話。

在政府機關的公務人員出國報告網,可以輕易地查詢到充滿廢話的報告。

例如:一個公司是多面向的結合。(簡單的說,整句都是廢話)

例如:透過本次會議實際瞭解大陸生醫相關市場現況,就本所研發之核醫藥物推廣應用極具參考價值,可納入本所未來研發方向之參酌。 (簡單的說,出國去參加這個會議,最後只是參觀看看而已,沒什麼東西是真的影響組織的研發方向!)

另一個例子:不論是什麼樣類型的數位化工具,除了便利性外,都應兼顧到安全性,日後推動電子化政府的過程中,應與各級資訊安全主管機關做密切的合作,確保資訊科技的演進不會成為資安漏洞。(資訊科技本來就不應該是資安漏洞,各級安全主管機關本來也就應該合作,哪會需要出國參加會議之後才知道這兩件重要的事?)

當然,某些企業網站資訊,也是廢話很多。不過,大部分是似是而非的術語,構築專業能力的感受。

例如:透過嚴格的專案控管與扎實的系統建置專業能力,我們有信心提供客戶最安心、最可靠的大數據優質服務。(如果把形容詞拿掉,這句話其實很短:我們提供專案控制和系統建置的大數據服務。但更具體一點,就是:其實有案子我們就可以接來做,大數據只是個行銷名詞)

有時候廢話很煩人,因為要花些力氣才能抵達事實真相。廢話浪費的很多時間,不過如果採用Scrum方法論,在會議上只專注於現況和事實,應該不太可能會有廢話太多的問題。至於網頁資訊和技術文件,就應該盡可能去除廢話。

泥巴仗


最高級,並且更難應對的是泥巴仗。

特別是在中大型組織,中階主管通常都位於關鍵職位。而好的中階主管,仍具備本職學能(註3),會根據事實來溝通。也因此,優秀的中階主管通常會強調技術事實,產業事實,專案事實,資源分配事實...等等諸多事實根據,作為溝通以及決策的基礎。因此,反倒不會強調本身的溝通協調能力。因為這樣的能力,如同影子一般隨附在工作之中。

然而糟糕的中階主管,由於已喪失本職學能(註4),就會強調其「協調溝通」成為其最重要的工作。然而,不基於事實和邏輯的溝通,會變得混亂不堪。某些糟糕的中階主管,在遇到爭議性問題時,會用打模糊的方式,試圖讓大家在泥巴仗中度過。而最高階的泥巴仗,會用看似合理的邏輯,但展示對技術完完全全無法掌握的事實。

例如:這個影片,非常經典,看似誇張,但在資訊科技產業其實常常發生。在該影片中,真正做事情只有一個人,而中階主管遇到技術難度的問題會省略甚至推諉,不能體會真正的重點而死咬不重要的細節,而技術人員要探索細節又會說這是專家的工作範圍。當然該影片是太誇張了一點,但其實在中大型組織時常發生類似的事情。

另一個例子:在老大靠邊閃中的有名片段,first thing or second thing。主角完全是用打泥巴仗的方式,在黑幫大老會議裡,刻意激怒某老大。而其他大老反倒會覺得生氣的老大很沒風度,一開始沒發現主角在打泥巴仗。

在此徵求案例:徵求在資訊科技中,重要會議裡打泥巴仗的案例。 


混亂泥巴仗是很可怕,要對應泥巴仗有先決條件,就是這不能是在「只有兩個人」的情況下。換言之,會議或者文件,至少要有三個人在場才有機會擺脫泥巴仗。

只有兩個人的情況下,只要有一人刻意打泥巴仗互相把對方弄的髒兮兮的,而且這個人還是中高階經理,另一個人根本不可能解決。唯一的方式是,儘速逃離現場,在下次確保有第三人以上在場。

在有起碼三人的情況下,以下方式可以解決泥巴仗問題。


1. 不隨之起舞


泥巴仗成立的條件是互抹泥巴。例如,在軟體專案中,當大家在解決A模組為何落後時,如果有人反覆提及一些沒有直接關連的事情:也許是另一個專案也落後了,也許是某RD的溝通態度不好。這些都是泥巴仗的徵兆。


2. 以白板展現事實


人的思考和言語是線性,因此在看穿複雜問題時,光是在腦中想是很容易被泥巴仗牽著走。

最好的方式是,一旦發現「同時」討論兩件以上的事情,就應該在白板畫圖或者條列。

畫圖是最好的選擇,最簡單的可以考慮心智圖或者魚骨圖。一旦有人試圖混淆事情,只要指一指說明我們現在在討論這個點,等討論完有決定之後,再往下一個點前進。而如果兩件事情有關連,就用線條與另一個點來說明此關連。

這也是為什麼,幾乎所有優秀的資訊從業人員(無論是低階還是高階)在會議中都喜歡坐在白板附近。


3. 耐心


簡單的說,就是有耐心的條理事情。透過工具(白板或紙)讓事情呈現。當知道對方採用泥巴仗手法-無論他是不是故意,就表示事情不會很快結束,因此要秉持著耐心條理問題。更重要的是,把這件事情當做類似刷牙洗臉的小事,在處理過程中沒有心情起伏 - 當然就不憤怒生氣)。






註1:特別是為求避免衝突,每人的說的話和實際心裡想的都有差距(參考left hand column),這讓組織 - 特別是資訊科技組織 - 運作上增加不必要的難度。

註2:  並不是去除重複字眼,極端簡潔就是好事。在文學作品中,言詞的優美有時候會透過層層疊疊的語句產生,請參考這裡。不過單就企業組織的溝通 - 例如開會 - 應該和寫小說是不一樣的。

註3: 參考這裡

註4: 以資訊科技來說,最基本的本職學能是寫程式,其他可以參考這裡這裡


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) 如果升遷是你最重要的考量,應該離開這類型的工作環境


12/22/2016

企業巫醫 - 年底才績效評估或考慮轉職?已經太遲。



年末,巫醫們會試圖對迷惘的人們,提供某些指引。

因此,在各部落,社群網站總是有各式的「轉職衡量」,「績效評估」,「個人職涯規劃」,「獵人頭的建議」...等等相關文章。(註1) 

不過,就實際情況來說,假如你到「年末」才考慮這些重要事情,那麼已然太遲。


為什麼?


績效評估要及時


大部分的企業在年尾都有績效評估。但以個人職涯而言,這些事情,應該是每隔一小段時間 (例如一個月) 就應該自我有所評估,並調整未來的做法。

就好像今年初打算減肥20公斤,並降低體脂肪到20%以下,而直到年底才量體重體脂肪,基本上已經太晚。即便最後仍然達到目的,也可能只是運氣好。

無論層級高低,無關老闆是誰,無論組織狀態,每隔一段時間,個人應該就事實以及個人產出部分自我評估一下績效。更重要的是,了解別人(特別是主管)對自己的「真正評估」。

自我評估,必須要根據「事實」,與其他人的「衡量」。不應該根據自己的想像,以及感受。

舉例來說,如果你是個軟體程式設計師,每個月你都如期產出符合品質的程式碼,並且bug數量也很少,那麼確實是個好工程師。

反之,如果相較於其他軟體程式設計師,你的程式碼產出低於其他人,bug數量也多,即便你有參加福委會,搞了很好的尾牙活動,你的績效評估恐怕依然很糟。

但由於,許多績效評估是根據「相對績效」來判定。而由於人類有天生的偏誤,自我評估一定會趨向「好的結果」。

因此每一小段時間,你一定要試圖取得主管或其他相關人的「真正看法」。越嚴格的越好。如果在2016年2月,你知道主管對你的績效是不滿意的,那麼你還有很長的時間可以改變(註2)。但如果你是在2016年底年終考核,才赫然發現主管與你對績效的「看法」不同!那幾乎沒有翻盤的可能。

另一個重點在於:績效評估是為了自己的職業生涯,不是為了組織,也不是為了讓主管決定薪資。

如果你覺得,如果要做每月的績效評估,公司/主管應該要主動進行才對?那表示你根本不是個能獨力處理事情的人,同時也表示你的主動性太差,也很難自己成長。



轉職衡量要完整


年底並不一定是換工作的最好時機。只因許多人因為領到年終,所以剛好離開「忍受很久」的工作,所以一時間就似乎有很多職缺出現。然而,某個人忍很久的工作,通常表示下一個人也不一定好受。

換工作的考慮有很多,無論哪一種考慮,都需要基於事實(請參考這裡)。簡單的說,在這份工作遇到的困難沒有解決,下一份工作一樣會遇到。

完整的換工作衡量需要對自己在「事實」上的長期認知。包括過去一段時間有去哪些地方面試?並且被錄取?自己倘若離開這個組織,對組織有沒有影響?自己如果沒收入,可以支撐幾個月?

更重要的考慮是:自己真的想要的是什麼。



那麼,年末可以做什麼?


當然還是得進行轉職衡量,績效評估,個人職涯規劃,參考獵人頭的建議...等等。可是更應該進行的是「檢討自己」與「改變自己的實際做法」。



1. 不設定一年為單位


以個人生涯規劃而言。應該將「一年的結尾」。從新定義為「一個月」或者「一季」的結尾。

並自現在開始,設定自我評估的時間單位,例如一個月。

每個月直接詢問主管或者工作上最相關的人:「有哪些地方需要改進」「哪裡做的事情有問題」「這個月哪邊沒有超乎期待的表現」...。

對於調整職業生涯也是以比較小的單位取得回饋。

當然,這並不代表不能有年度目標,或者五年以上的願景。只是,檢視願景和目標的單位必須要有及時回饋的可能(註3)。而單指個人而言,每個人的記憶有限,根本不可能有效回顧12個月前發生的事情。因此採用Scrum的精神,以大約一個月為單位應該是最適合。



2. 不重複過去無效的做法


恆毅力是一本在誠品門口有超過5公尺橫幅廣告的書。作者以她數年的研究顯示恆毅力是成功的重要因素。

毅力耐心確實是朝著目標前進時不可或缺。不過,實際作法的調整也很重要。以創業為例,pivot幾乎是必要。

每過一段時間,應該就事實來檢討,目前做法是否達到效果。如果沒有,就應該衡量原因,考慮改變執行的方式。不見得一定要改變,但一定需要檢討。

改變當然有可能帶來風險,甚至會比沒改變的時候更糟糕。然而,不改變就沒有前進的可能!



3. 不等候重要的事情


誠如第一段所述,年末考核等到年末就太遲。其他和職涯有關重要事情也是,不應該年末才進行。

因此,今年年末可以設定未來「重要的事情」頂多等到下個檢討點 - 例如一個月後。

每個人所意識到的重要事情都不同,有很多時候心裡覺得一件事情重要,和實際上真的很重要是截然不同的事情。一個人的真正行為,才是斷定他認定重要不重要的指標。





參考:

努力的三個迷思

工作上學不到東西

因沒挑戰想要換跑道

工作太忙沒時間?

職業生涯的突破

成長的最好方式:檢討


註1: ....對... 這篇也不例外

註2: 所謂調整,一樣要考慮手邊有的選項:可以針對不好的地方改善,也可以試圖換個工作項目。甚且也可以換工作。

註3: 有些人可能會用「爬樓梯可以一步一步,但是要跳過鴻溝不能分步驟吧?」來辯解過短的時間區間會有其他問題。不過,這真的是問題嗎?跳過鴻溝的確是一次跳過,但起碼助跑的時間和助跑距離的測量,也是必要的前一步啊!



12/10/2016

企業巫醫 - 提昇效率的秘方



這裡有幾本書...


- The Productivity Project 最有生產力的一年
- Four hours work week 一週工作四小時
- The Art of Non-Conformity不服從的創新
- THE $100 STARTUP三千元開始的自主人生
- Do over(不確定是否有中文翻譯)
- Nomad Life遊牧生活


這些書籍有很直接的共通點:


(1) 個人經驗


和一般以二手資料的企業巫醫的書不同,這些書籍都是以「個人實際經歷」為主要組成。可能沒有精湛繁複的巫醫術語,但是「因為自己有做過」也比較容易說服別人。


(2) 專注,效率,生產力


這些書籍或多或少都強調個人效率的重要。基本上不外乎討論80/20法則,生理因素,心靈意志,工具方法等等。


(3) 個人品牌創業


這些書籍的作者,其實都是「個人品牌創業家」。個人品牌創業大約在2006-2008年之後,在網路上蔚為風潮。特別是在北美,這些個人品牌創業家通常都會有(a)自己的blog (b)自己的書籍 (c) 一個看似專精的知識領域...接下來通常就組合優勢開始以自己的名聲盈利。




為何強調效率與生產力的重要?


合理的推測,這類型的書慢慢也會在亞洲流行起來。雖然僅只以個人經驗與觀點來詮釋某個複雜的龐大主題,可能失於偏頗。但相較於純以「個人想像」和「無根據的推理」的企業巫醫書籍比較起來,還是踏實的多。


其中,「專注,效率,生產力」是三位一體的永不衰退話題。自從有工業革命開始,效率/生產力便是工業界主要獲利來源。在1995之後的網路時代,雖然「創意」與「變革」突然成為顯學,但究竟沒有效率,無法被執行的創意,等於是一種空想。創意變為有效可執行的事項,才有實務上的意義(參考這裡)



因此,能否有專注,高效率,高生產力的產出,變成知識工作者必備的能力。而也是「缺乏資源」創業者成功的關鍵之一(參考這裡)。

而也正是因此,「提高生產力的祕方」,在近年來變成出書的顯學,甚至也成為「被創業」的利基來源(註1)。


個人提升效率生產力的祕方


很遺憾,並沒有什麼祕方可以「簡單而且戲劇性」的提高個人效率或者生產力。至少,沒有不需要努力的祕方。

在業界確實有各種「顧問」,可以針對特定的個人,特定的案例,提供收費的咨詢服務(註2)。但最終,教練顧問只能提供指引,還是只有自己幫助自己。


先考慮以下低成本的「尋找自己的祕方」的三步驟,大概只要花2天:


(1)  4小時閱讀



花四小時專心看完以下五本書就好,應該都有中文版。

- Getting Things Done  
- The Productivity Project 
- The 4 hour work week
- Lean startup
- Do Over


這些書所提的做法都比較務實,然而,不見得適合每個人。單看一本書,也會讓你的視野受到侷限。花時間去找一堆書來選,也太浪費。請先看上述幾本即可。看書並將自己覺得有用的地方做些記錄即可。

其中一本看起來是在講創業?即便你一點都不想創業,它提供的方式仍然對一般工作很有幫助!


(2) 停止接受資訊一天


如果你花了4小時看完那五本書,應該可以體驗到讓腦袋休息的重要。找一個假日,無論採用什麼方式,停止接收資訊一天 - 電腦,手機,書籍等等一概停用。隨便去做點跟工作無關的事情。


(3) 檢視並決定提升效率生產力的做法


經過了4小時學習,又經過了1天的沈澱。是時候可以決定哪一些「做法」,是最適合自己。只要是最適合自己的做法,就是自己的祕方。

如果還是想不到好方法,可以參考這篇。這是經過看了那五本書之後,經過一天的沈澱,個人認為最簡單適合自己的方式。也許對讀者也是個好的參考。







註1:例如,隔一陣子就會冒出來的「增加記憶力補習班」「全腦潛力開發課程」「超級記憶力」.....不過最終的結果,通常是這些提供祕方的企業巫醫們,口袋裝滿無知大眾的錢,而這些花大錢上課的群眾,其生產力與效率卻鮮少聽過提升的例子.....至少從來沒聽過任何創業有成的人曾經說:「喔!對了我創業成功的祕方,就是上了XX人的腦部開發課程,讓我記憶力變得過目不忘喔」

註2:在台灣大多以企業開班的方式存在,但這種效果極端有限。而美國英國兩地,都有針對個人的「導師服務」。但其收費都很驚人,而且大概也無法遠端服務。例如這家seven coach。也有很多個體戶,例如這位John Spence


11/14/2016

因為沒挑戰想換跑道:先檢討自己吧!




新的一年,總是容易遇到討論換工作的事情。目前,台灣資訊科技領域整體仍然缺乏人才,因此要換新的工作是非常容易的事情。

真正的問題在於:什麼原因想要換工作?如何換?新工作或事業會不會比較好?自己到底想要什麼?

這些問題根深蒂固地存在每個人的身上。不會有一體通用的方式為所有人解答。

不過,如果單純只是因為現在的工作沒挑戰性,無趣而想要換跑道,還請以下三點簡單的自我審思一下。



檢討一:「沒有挑戰很無趣」的真正源頭


牌桌上的至理名言:「30分鐘後如果你還沒發現誰是冤大頭,那麼你就是冤大頭」。在企業中,如果你沒發現有任何值得挑戰的地方,那或許你自己就是沒有挑戰的真正原因。

當你的工作變得沒有挑戰,而且無趣的時候,請先確定問題的真正源頭。

是不是因為你的能力或者表現,讓你無法得到有挑戰有趣的任務?還是你的視野讓你看不出挑戰性?

還是這工作或事業的本身,真的沒挑戰性?你已經是有如NBA過去的Jordan或者現在的Curry已經快觸到這個事業和工作的極限?還是你抵達的是自我的極限?



檢討二:選項



選項,永遠是考慮決策的要件。

換工作或事業是一個好選項。但是,在既有的領域中,擴展自己的視野和能力也是一個選項。

換工作是個選項。在大企業中,換部門也是一個選項。換工作這選項中,嘗試新的技術領域是個選項,但是嘗試截然不同的工作類型(例如業務相關部門)更是更大的不同選項。

在現有工作內容中,改變自己的做法以求突破,也是一個解決的選項。

選項可能很簡單,也可能很複雜,而且還會參雜很多人的因素。去除自我偏誤,取得個人最想要的結果,比想像中的簡單。不過,要預設自己以及相關人等有完全的邏輯推理是很難的。(參考:沈思



檢討三:「沒有挑戰很無趣」有時候是真正的挑戰


在資訊科技的領域裡,多的是把原本看起來無聊的東西,重新找到價值並且延伸的例子。

如果你可以將無聊沒挑戰性的事情,轉成有價值,並且有挑戰的事情,等於是你證實自己絕佳的創意以及實踐創意的能力。

這樣的例子在不管在哪個領域很多,從很久很久以前的gmail,到近幾年的類似snapchat的app,許多都是一開始是沒很有趣,但是找到額外的創意之後,將舊有的東西突破。

隨著組織越來越大,表面上無趣的事情會越來越多,光是默默的忍耐並不會讓事情變得更好,只有把無趣轉換成價值,才能展現自己的創意能力。要怎麼做?可以參考這篇



參考文章:換工作的面試-軟體工程師如何展現價值




沈思
一個海盜集團中的5個海盜找到了100顆金幣,每一枚都一樣的大小和價值。 

由於海賊王想要這五個部下傷透腦筋,自相殘殺,規定他們分配金幣的方式如下: 

1。抽簽決定自己的號碼(1,2,3,4,5) 
2。首先,由1號提出分配方案,然後大家5人進行表決,當且僅當超過半數的人同意時,按照他的提案進行分配,否則將被扔入大海餵鯊魚。 
3。如果1號死後,再由2號提出分配方案,然後大家4人進行表決,當且僅當超過半數的人同意時,按照他的提案進行分配,否則將被扔入大海餵鯊魚。
 4。以此類推

 如果你是號碼1的海賊,應該怎麼分配金幣?

10/10/2016

軟體專案的現實:解決人的問題




無論是否採用agile的開發方式,所有軟體專案,最大問題的來源都是人。

人的問題,通常會極現實的影響專案的進行。然而,妥善運用agile的精神和Scrum的方法,有機會讓人的問題降到某個程度。

某個朋友,姑且稱為K,在專案扮演專案經理的角色,遇到以下狀況:

我最近有遇到一個問題,不知道怎麼辦,下面的人一直做不到我的要求,或者動作很慢,即便壓日期給他,他還是沒辦法達到,但實際上它任務並不多,只是開test case,我不太知道怎樣push他,我又不想來硬...他只有這個任務 平常又常常看他在上facebook, line....覺得要當一個讓人喜歡的lead真的蠻難的....


這個問題非常典型。

以敏捷開發(agile)來說,解決方式似乎也很簡單。首先專注於優先項目,接下來根據事實檢視工作,最後才考慮能力問題。


一:專注於優先項目


每個人在Sprint之中一定有正在執行的項目。確保每個人都是「專注」於目前最優先的項目是Scrum master最基本的任務。

即便不是採用Scrum也一樣。團隊成員必然在某個時間點有一個特定任務。專案經理或領導者(leader)當然必須確保,在這個時間點他只會專注在這個工作任務上。

對於剛剛成立的團隊來說,要確保團隊成員專注於目前任務上的方式很簡單:就是腳踏實地的「問」。在該成員一來辦公室的時候,就坐到他座位旁,親切的詢問他昨天早上在做哪些事情,昨天下午在做哪些,並實際上「看」到做的結果。就可以確定他是否專注,而能確定是否做到真正的效果。

整個詢問的重點都是在了解事實,而不是監督細節。因此每天頂多也只針對「需要幫忙的成員」,一起坐著看實際上的狀況。


二:工作檢視

以Scrum而言,每天的會議(無論是不是站著)就是為了統一工作情況檢視。完成就是完成,沒有完成即便是已經達到99%也一樣是沒有完成。當然,前提是在Scrum開始時有定義「什麼叫做完成」 - Definition of Done。

如果不是採用Scrum,則應該盡可能在團隊開始時,就先定義何謂「完成」。

以開test case為例,完成是指把要做的功能的test case詳述在某個測試文件管理系統上?還是只要先用excel或者wiki列出來即可?test case完成後是否要先讓團隊成員審閱,看看有沒有問題?要不要先估計每個test case執行會花的時間?test case的前置作業 - 例如建立測試資料等等,是不是也要涵蓋在其中?

當有完整的工作完成定義之後,要讓負責進行工作的人「決定時間」,而非「被決定時間」。

以軟體專案而言,任何超過2天的工作項目(task),都應該分階段完成。畢竟,就事實而言,一個人不可能「連續工作2天」,每天一定會停住工作,下班回家。而這些階段應該要有階段產出。以test case而言,假設有10個新的user story需要建立test case,則今天完成了4個,表示還有60%尚未完成。


三:能力分配

如果團隊成員的確很專注於工作,而且也對時間/產出有正確的體認。最後的問題就是「能力問題」

團隊成員的能力組成其實非常複雜而且麻煩,牽涉範圍廣。以軟體專案而言,能力並非只是撰寫程式,測試程式,理解規格等等。能否和其他人合作,也是能力的一環。

一個規模中等的軟體開發團隊(4-7人),如果有一個人的能力「極端」的差,確實會造成專案很大的問題。

在Scrum的情況下,這樣的問題在前兩三個Sprint應該就可以被控制。因為雖然他的產出差很多,但未來的sprint的進度,是以團隊能力來考量,因此Scrum master仍然可以有效掌握專案產出和進度。

在不是Scrum的情況下,可以先找到該成員的相對優勢。排定一些學習項目,來提昇該成員在這個專案中的相對優勢,並且在未來安排相對優勢的工作。值得一提的是,根據經濟學的「比較利益法則」,每個人一定會有所謂相對優勢:請參考這裡,和這裡

關於軟體開發團隊的個別能力,還需要注意以下幾點:


1. 每個人都會成長,但是....


每個人都會成長學習新知識和能力。但是!在中短期專案裡,必須先考慮個別能力與優勢。

換言之,團隊領導要像下象棋一樣,找到每個人的「專長」,能妥善組合專案,就是個好的領導者。

而差強人意的領導者,則是常常試圖規避個別成員的「缺點」,這樣比較不會出大問題,但也容易產生差強人意的結果。而最糟糕的領導者,則會把人當做圍棋,看到人非黑即白,見到專案漏洞時,看到有空閒的人就直接填塞。這在某些有數百個人的硬體專案或許可行(因為數量在此可以產生品質),但在軟體開發專案鐵定行不通。


2. 能力是綜合考量...


能力必須綜合考量「全方面」:例如是否好溝通,是否能處理複雜的設計問題,能否開放心胸的就事論事等等。不能僅僅考慮寫程式的能力。

另外,如果覺得整個開發團隊能力都很差。作為一個能自我思考的領導者,應該先思考自己是不是「問題的來源」,甚至要思考自己是不是根本不適合作為團隊領導。


3. 讓不適任的成員離開...


讓不適任的成員離開,某些時候是個可行的解決方案。特別是某些企業管理派別認為,投入時間在不適任的人身上,他有可能變得適任,也有可能不會改變,然而投入時間太多,會造成專案延誤。

以Scrum的角度來說,這個情況不太會發生,因為2-3個sprint之後團隊速度已經確立,無論適不適任,專案產出速度不太會再改變。因此剩下的問題僅在於「換個人會不會更好」。而以中短期(3-6個月)的軟體專案而言,讓破壞性的不適任者離開,當然是解決方式,但不見得要「找另一個人進來」。






相關文章:人才管理心智圖為自己工作...



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, 飛鼠裝的先驅,然而他過去的飛鼠裝實驗都沒成功過,就嘗試從艾菲爾鐵塔跳下,結果當然是...




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


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. 經過產品經理確認 才算?

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

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