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

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/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/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/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/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

7/02/2016

如何學習Scrum



如何學習Scrum?

端看學習Scrum的真正目的,有三種方式可供參考:(1) 網路資源 (2) 收費課程 (3) 實際經驗


(1) 網路資源


很簡單,費用幾乎為零。

下載這兩個pdf,接下來,先不要上網查專有名詞,也暫先不要查字典,好好的先花時間看完。

* Scrum-institute 的 training pdf
* m-plaza 的 Scrum Guide pdf

然後,隨意上網找一些相關資料閱讀佐證即可。也可以自己做個類似這樣的簡單學習計畫

不確定自己有沒有學會?可以考慮花29美金考一下證照看看,請參考Scrum證照這篇

假如是剛畢業的大學碩士學生,英文閱讀沒有太大障礙的話,大概8-16小時應該可以完成。


(2) 收費課程 <- 不推薦


也很簡單,但是要花錢,大概7,000~20,000不等。

在google搜尋[scrum 認證課程],出現起碼5個不同的教育機構,其價格從7,000到20,000台幣不等,時間通常大約是2整天左右。衡量自己的時間和財務狀況,挑選離家近的參加即可。

這類型的收費課程通常會協助考取證照。在此並不推薦這個方式考取非技術專業之證照。

(3) 實際經驗


非常難!要花的成本看起來很高,不過他通常伴隨工作經驗的成長。

(a)基本作法:


首先必須要先參與開發團隊一陣子,在此期間必須要先用方法(1) 網路資源。用以了解Scrum的基本精神。

然後,只要運氣不要太差,加上自己的努力,有朝一日會變成專案經理,或者是團隊領導者的角色。接下來,由於自己已經擔任領導者角色,就在自己領導的團隊中,以務實的方式執行Scrum。其中一定會遇到阻礙,每當你碾平一個障礙,就更多一層對務實的認識。

基本作法其實也是最佳作法,如果是一個已經有足夠技術背景的人,而有意識的朝這個方向前進,在台灣大概3-5年就可以有很好的成果。


(b) 突破性作法:

和所有專案管理技能一樣,當不能付諸現實的時候,技能的本身就沒有意義。就像籃球教練沒有籃球隊可以教,沒有籃球比賽可以參與的時候,籃球教練等於沒有付諸實踐的意義。

要有突破性作法的原因在於:

* 企業組織長久以來沒有真正agile的精神
* 在創新小公司任職,架構混亂,以完成事情為優先
* 自己並不是團隊領導,但希望能改變團隊
* 剛畢業,沒有領導管理經驗
* ...


然而,在這些外在因素不利的情況下,如何有Scrum實際經驗?(突破性方式的概念可參考這篇。)

簡要的說,自己起頭一個專案,無論是跨界虛擬專案,還是開源(open source)專案,還是到便宜的外包市場找南亞工程師加入的專案。當自己開啟專案時,自然就可以確定,如果要採行Scrum,不可能會有其他外界因素,所有成功與否的因素都在於自己。當然也是靠自己來碾平困難。

一旦個人的能力提昇,自然就越能貢獻現在的團隊,現在的組織,更容易體會團隊合作的可貴。






6/12/2016

靠感覺做專案管理 - 鐵定失敗



真實故事:


有近70個工程師參與的軟體專案的組長會議中,除了專案經理之外,另有8個負責領導開發不同模組的組長一同與會。

例行的報告進度後,專案經理看了一下大家,帶著遲疑的臉說:「在兩三個禮拜大家的模組就都完成了,如果沒有問題的話,應該整個系統同時也都弄好了吧?」

負責UI以及整合模組的組長,看著大家漠然不語,也只能硬著頭皮的說:「現在最大的風險在於:如果所有模組都在最後實現完成,那根本不會有人知道組合起來會發生什麼事,所以我只好老實的建議,要不就額外增加整合測試的時間,要不就要減少某些模組的功能讓他可以早點進入整合」。

但其實大家心裡有數,這麼多人在短時間開發出來的系統,不可能在短期間整合完畢。

未料,專案經理似乎沒有體會事實,他說:「接下來大家就要在努力一點,就快要搞定了」。

可能是心情不好,在加上長時間加班的火氣:某組長就說:「我們到目前為止的問題是在於我們不夠努力嗎?」。

專案經理當然說:「不是,我知道大家都很努力...」話未說完,該組長就說:「既然問題不在於我們不夠努力,為什麼叫我們更努力,就可以解決問題?」。

專案經理:「...」





許多失敗的專案管理者,在遇到困境時,只會用幾個永遠不會有好結果的方式,來試圖解決問題。常見的方式像是:無意義的加班,默許降低品質,虛報進度,哭訴人力不足要求增加人力。在緊要關頭,這些作法都不會有好效果。只會這幾種方式的專案經理,儘快離開管理位階,才會是組織最大的貢獻。

最有天賦以及領導力的管理者,通常擁有不可言喻的直覺,並能透過直覺透徹專案。很遺憾的是絕大部分的人不會有這樣的天賦,特別是作為軟體專案經理者。很難具備以敏銳直覺,完成複雜系統開發。

然而,專案管理其實不需要天賦,所有人都可以透過自我學習,了解專案管理的精隨,透過自身的努力作個稱職的專案經理。和所有重要的事情一樣,首先是要了解事實。在略具規模的專案,應該透過事實的呈現,來了解專案目前進度,可能的風險,遭遇的困難,以及解決方式。

而且,只有盡可能了解事實,面對事實,才能引發可行的創意行動。


事實的取得有三個面相:

恰當的衡量:


恰當衡量,是判斷專案經理的好與壞的關鍵之一。恰當:簡而言之,必須是可行,正確,有效,有意義,精簡的衡量。

近年來Scrum蔚為風潮,其中一個重要因素是對於進度的恰當衡量。通常專案進行了一段時間之後,burndown chart可以清楚的顯示,現在專案的進展,和是否可能在預定期限內完成。也因為burndown chart展示的是不可否認的事實,讓Scrum的團隊在取得洽當的衡量之後,做正確的因應。

不恰當的衡量,出現在幾乎所有失敗的專案場景裡。

有些專案經理會依賴WBS的圖表,來看進度是否得當,但WBS是固定的無法調整,即便調整,也很難追溯過去調整的細節。WBS在軟體專案中,很難達到可行,正確,精簡。

有些專案經理,會依賴團隊成員報口述「完成」來斷定進度,在沒有看到「實品」(例如程式碼,每天自動編譯測試的build等等),口述完成不是「有效」衡量。

最慘的專案經理,會透過大型,繁複,耗時的會議,逐一確定已經完成的項目,花在「了解事實」上的時間,遠超過「做事情」的時間。這種本末倒置的既不可行,也不精簡。它唯一的好處只是在於讓原本不懂的人 - 也就是專案經理,花上不可置信的時間了解事情而已。一個不超過10人的團隊,要是每個禮拜耗費總時超過4小時在這類型的會議上,就表示專案經理沒有對技術有透悉能力,儘快換掉專案經理會是對團隊最有利的作法。



承認不確定性:


沒有人可以預知未來,必須承認不確定性,並且把可能的不確定性當做事實加以處理。當打算推測不可知的未來時,用過去之已知事實,並加上不確定性。

例如:未來3個月團隊的總人時?假設團隊成員共10人,每個月22個工作天。則總人時推測為220人日時,等於表示沒有推測。這220人日,根本沒有把「過去已知事實」考慮進去。比較好的推測應該是,220人日,減到(1) 過去3個月,這10人的總休假生病天數。再減掉(2)可能的季節性假日,例如颱風。再減掉(3) 組織已知的活動,例如員工旅遊,大型會議等等。當然,這些以過去的數字推測未來不一定準確。但是,以過去的事實推測未來的不確定性,總比當做沒看到的好得多。

一般專案管理中,不確定性會用風險管理來衡量並且控制。正是「真正」的風險,就是坦然面對事實。

失敗的專案經理在每週的報告中,會把「人力不足」當做風險,試圖避免未來失敗的責任歸屬 - 畢竟已經先在每週報告中說了,目前人力不足是風險,但是就是沒給足夠的人力。這其實單純是專案經理試圖逃避未來責任的作法。

人力不足壓根就不是真正的風險!如果人力不足是真的,那麼專案時程規劃不正確,對技術掌握不足,專案經理沒有創意來解決問題...這些才是真正的風險!假如真有人力不足,它必定不是突然出現的可能機率,它是「已經存在的必然」,風險必須是某種可能會出現的事件,萬一出現,會對專案造成及大的影響。例如,在建築專案中,大地震就是風險,必須要規範出現的機率,但它很有可能不會出現。

把不正確的風險當風險,以及不把真正的風險當風險,都是不願意面對事實的畏縮專案管理者會做的事情。



理解認知偏誤:


在專案管理中,人類認知偏誤(Human Bias) 不可能全部去除,但可以盡量避免。根據事實原則,專案經理應該承認:認知偏誤的存在,盡可能減少影響,但也要理解,不可能全然去除認知偏誤,畢竟人非聖賢,也非機器。自認為已經去除所有認知偏誤,等於是一種認知偏誤。

去除是不可能,理解並且降低偏誤,是取得真正事實的最重要的方向。

例如:在code view的精簡會議中,常出現偏誤在於,極為資深的員工的程式碼,通常比較不會被挑出問題。但根據研究,只要運用程式語言超過2年以上,資深與資淺員工,在程式碼撰寫品質並沒有太大的不同(參見約耳談軟體一書)。要去除這類型偏誤,最簡單的方式是透過系統送出匿名程式碼(在尚未commit之前),要求成員利用email寫出自己的意見,而意見也可以是匿名。

高階主管為另一個例子:高層主管對團隊的了解,大部分來自第一線主管或二級主管。高級主管必須要認知,取的團隊資訊,必然經過過濾和扭曲。這幾乎是不可避免的事情,畢竟第一線主管或二級主管也是「人」。例如,如果發現有某團隊老是有問題,進度不佳,人力似乎永遠不足,高級主管如果找第一線主管了解原因,不會有第一線主管直接了當的說「是我的問題」。但是,一個團隊有問題,75%的原因是出現在領導者身上。去除認知偏誤的方式,除了越級訪談之外,高級主管不應該詢問一級主管的「看法」,而是直接詢問可以獲得的事實。例如:目前的問題,一級主管採用哪些「有價值的作法」來解決。

偶爾進行的團隊訓練活動,也可以將人類偏誤以討論的方式作為主題。讓團隊成員知道有偏誤的存在,自然就有可能減少偏誤的發生。



只要能根據「事實」,降低並去除認知偏誤,比較有機會在困難的專案狀況下,發揮團隊潛能,並且找到有創意的解決方案!畢竟,根據「事實」,一個營利組織必然希望團隊能帶給組織真正的價值,而非僅只是達成表面目的。





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

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

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








5/29/2016

非戰之罪?組織變動的三個因應作法



世界越來越小,變化越來越快。企業環境更是如此

從2015年底的弊案開始,東芝一連串的裁員新聞便在網路上出現(參考這裡這裡)。最近,由於有要徵約聘員工,通常是很難在約聘的職位上找到有經驗的軟體工程師,通常也很願意找剛畢業雖然能力不足但很願意學習的年輕人。可是,這位林先生卻是個例外。他是自願前來面試約聘職缺,而且有十幾年工作經驗的專案經理。經過詳談才知道,他也是東芝海外大幅裁員的其中一員。過往,林先生充足的筆記型電腦專案管理經驗,讓他幾乎沒有其他的資訊科技能力,對於軟體開發自然也是完全沒有經驗。環境的變動,不是他的錯,但沒有先針對可能變動而準備,會讓他失去工作之後的6個月內仍然難以找到足夠幫他解決房貸問題的方式。是不是雇用林先生?還不一定。每個人都應該針對不預期的組織變動而有因應準備,這才是重點。



在一個超過150人的組織裡,一般的員工其實很難對企業環境的變化做出正確的因應。更直接地說,組織重組(re-org)目的各有不同,但一定會順帶調整人員,而作為資訊科技的組織的一員,在重組時很可能會受到不預期的影響。

可能發生的最糟糕的情況是「被汰弱」,其次的情況是「改變工作」,最佳情況是「被留強」。

而作為資訊人員,軟體研發人員,除了隨波逐流,隨遇而安之外,對於組織的變動,能夠有正確的因應作法會是最好不過。



變動因素


組織變動的因素很多,而絕大部份通常都非單一個人所能控制(除非你是CEO)。

好的情況有:獲利太多,而跨大經營範圍;獲得額外投資;併購其他企業。

壞的情況像是:賠錢要砍部門;被別人併購;移轉工作地點到低成本的地方。

不好不壞的情況也很多:改變經營策略;將寶貴的人力資源移到別的地方;停掉某些產品研發等等;組織汰弱留強,調整人力品質。


對個人影響


組織變化對個人的真正重點在於「因組織變動產生的行為」,當然不外乎以下四項:

離開組織(資遣/開除/離職):無論是被迫,自願,或者被自願。

執行讓員工離開團隊的任務(執行資遣/開除):通常是中低主管的任務,也許是會執行讓人離開組織的任務,也許是更換工作內容以及更換部門。無論是被迫還是自願。

改變工作內容環境:做其他專案,升遷,換到其他部門,換老闆,更換工作地點,改變工作時間等等。

改變工作報酬:加薪,減薪,更改薪資計算方式,更改其他相關福利等等。


如果不是CXO,幾乎不太可能在很早之前,事先知道組織變動。不過,對於資訊的技術人員(程式設計師之類),即便是一般員工也能有比「隨波逐流」更好的因應作法:




做法一:事先因應。




首先,所謂事先因應,並不是事先知道各種變動因素發生。通常你知道變動因素發生的時候,一定已經是「太晚了」。

事先因應,指的是因應「黑天鵝事件」,也就是試圖因應未曾發生過的,但是一旦發生,會有劇烈變化的事情。但是,既然是黑天鵝事件,就不可能事先知道事件的種類,發生的原因,發生的時間地點。

事先因應指的是,培養自己,因應「未知」的事件。

作為資訊科技技術人員,相較於其他行業,培養自己比較簡單。剛出社會的新鮮人,當然就繼續學習新的技術,不管是程式語言,系統工具,開發流程,都有極大的學習空間。

稍微麻煩一點的是,工作7-10年左右,在可能不上不下的階段。這個階段,必須要先確實「認知」自己對現在組織的價值,並且透過這樣的認知,

乍聽之下很抽象。例如,你現在可能是軟體公司的技術小組長,帶領3-4同事進行軟體開發,這時候顯而易見的有兩個未來的選擇,(1) 你可以往技術方向前進,未來成為架構師(architect)或者技術長。這時候,培養優勢就在於,應該有意識的讓自己的知識範圍,隨著時間越擴展越大,並且不會僅侷限在這個組織之內。(2)你也可以朝向專業經理人前進。未來成為帶人的主管。這時候,培育的優勢方向在於:必須要同時兼備技術能力和判斷決策的能力。判斷決策能力的自我培養,必須要是有意識地進行。



找到自己的價值,發揮優勢,培育優勢。並且試圖擴展的優勢,讓它不僅限定在特定時段,特定組織,特定產業,甚至特定國家,。



做法二:創造選項。



至少在台灣,絕大部份的人,在任何事情上都有「選擇」。

有些選項,顯而易見。例如,有個選項是:覺得不喜歡組織的某些事情,就「選擇」離職了。

有些選項,因為認知偏誤,不容易看見。例如,有個選項可能是:覺得不喜歡組織的某些事情,就「選擇」去改變這個事情。

大部份的人,都可以輕易看出既有選項。但是,能「創造」選項的,或者看出非既有選項的。其實不多。

軟體技術上,能創造選項的例子比較多。例如,即便到今天為止,在很多企業仍有winXP的存在,但是他所使用的IE(8)很老舊。如果你的網站應用程式,一定要給這些企業使用,擺明著選項有兩種,一個是苦幹實幹,讓網站遇到IE8的時候,用比較老舊的javascript library,另一種是說服企業升級winXP。不過,只要稍微想過,很多技術人員都可以「創造」其他選項。例如部署新的firefox/chrome到winXP上。


然而,非技術的選項,能「創造」的可能性變少很多。但其實,這僅是受限於自己的目標錯置,認知偏誤,或者錯覺。

以組織變動的情況而言。也許你是「被自願」離職的員工,似乎也只有自願離開一途,但如果真的很不想被自願離開,首先需要知道你不想離開的真正目的,和你真正想要達到的目標。例如:或許是因為家庭因素,你需要穩定的收入,而非真的喜歡這裡;或許是你喜歡這個工作環境;或許是你一時之間找不到其他工作。原因可能有很多,但如果你的目標沒先想清楚,能創造的選項自然受限。

如果是因為家庭因素,你需要穩定的收入,而並非真正喜歡這個組織。你的目標應該是「在短時間能創造有穩定收入」,對於有技術背景的人,這並不難達到。難達到的是:「短時間創造極高收入」

如果是你一時找不到其他更好的工作。你需要「創造」找到更好工作的機遇。到linkedin上認識headhunter,加入open source社團,到社福機構提供技術能力當義工...等等都是可創造選項的機會。




做法三:根據事實。執行。

執行選項,特別是執行不那麼容易的選項,需要克服很多心理上的障礙。


特別是以非技術選項而言。突破個人心理上的障礙,執行最適合的選項是知易行難。

遺憾的是,沒有人能夠代替你執行。因此在此只能提出幾個參考點,協助克服認知與心理障礙。

(1) 只有自己才能負責自己的職業生涯。

(2) 軟體技術人員,在技術上都有過度自信的傾向。

(3) 沒有人剛生下來的時候是會寫程式的。

(4) 學習特定的軟體工具,平台,程式語言很重要。但要注意的是,不能把雞蛋放在同一個籃子裡

(5) 組織領導者(主管)的優劣與否的判斷很難。不過,試圖讓所有相關人等都滿意,大家歡喜的領導者,反而容易引導至糟糕的結果。




  





5/06/2016

80/20法則之軟體專案的三個運用重點




軟體專案的Scrum的一次sprint之後,照例的檢討會議(retrospective)中,張經理收集了成員的意見,經過投票整理與排序,發現"不夠專注在重點上"是成員們最希望改善的地方。於是,張經理發表他的見解:「看起來大家可能是覺得瑣碎的事情太多,沒辦法專注於工作,這次新的sprint開始,大家試著把心思專注在重要的事情上」,接下來,張經理開始順道交代其他事情:「呃,上次要給法務部門的3rd party版權清單,老馮你準備一下;明天我們要定個下午茶,小陳你有空的時候幫個忙...」。....於是乎,最希望改善的地方就從未改善過。


Pareto Principle,又稱為80/20法則,指的是80%的結果來自20%的原因。這個法則是取名字義大利的經濟學家帕雷托。他觀察到1906年義大利的80%總資產屬於20%的人口。而此一情況被學者們,在其他領域也觀察到重複類似情形,因此被簡約成此法則。

80/20法則中的數字,有時候,會和實際領域不同而有所改變。例如,絕大部份的軟體,其90%的執行期間,執行的是其中10%的程式碼(參見這裡)。


在軟體專案管理中,能掌握80/20法則,等於是掌握80%的成功。

以程式撰寫為例:最重要的10%程式碼,關係到軟體運作的90%時間,掌握最重要的10%的效率與品質,就掌握系統的本身。當然,80%的bug來自於20%的程式碼。(參考這裡

以測試為例:1000個測試案例(test case)如果能有效掌握哪20%的測試案例可以測出80%的潛在問題(bug),就可以有效縮小測試。

以人員管理為例:在有一定人數的情況下,30%的程式設計師完成70%的主要功能。而有追蹤問題(bug)的來源時,80%的問題來自20%的模組撰寫者。


因此,掌握並改善20%重點,是任何專案的成功關鍵因素。

不過,這件事情知易行難。以反面來看,作為專案管理人,如果整個專案過程的每天都忙得焦頭爛額,隨時都有不同的人來進行不同的會議,螢幕旁邊有數十張待辦的便利貼。這很明顯的表示你一定沒有掌握到20%的重點,而你雖然很努力的想要完成任務,但並沒有朝向正確的努力方向。更慘的是,假如你認為這種忙碌可以顯示自己在組織的價值與貢獻,這種想法做為專案的領導者只會害死大家。


每個專案都是獨一無二,因此每個專案的重點20%都有所不同。然而,掌握關鍵的「20%」倒是有三個共同切入點。


1. 目的 - 真正目的


軟體專案的真正目的各有不同:有些是新產品開發,有些是既有產品增加新功能,有些是客製化專案。大部份的情況下,其目的通常不是「技術目標」,而是「達成效果」。

例如,網路商店需要開發mobile app,其目的鐵定不是為了要有一個Android APP或是iOS APP,而可能是要讓客戶在智慧型手機上也能購物。但也有有可能目的是要讓客戶在智慧型手機上容易查詢訂單。當然也有可能兩者兼具。但無論如何,技術目標:也就是有Android/iOS APP,與達成效果通常有相關,但專案管理者必須清楚兩者的不同:

達成效果是勢在必行不可或缺,但技術目標永遠都有其他選項

網路商店不見得需要有APP才能讓使用者在智慧型手機上購物,可以使用符合智慧型手機規格的網站(所謂的響應式設計),讓使用者利用手機瀏覽器進行購物,也可以透過簡訊或者撥打電話的方式購物,開發APP只是其中一個選項而已。

掌握真正目標之後,列出這個目標中的所有使用情境(user story)中最重要的20~40%的功能,而軟體開發的重點就放在這20~40%重要功能。集中力量完成最重要的20%,才不會「先」耗費力氣在無謂的事情上,「最後」才做真正重要的事情。



2. 時間 - 不倒退的沈默成本


時間是不會倒退的(參考這裡)。軟體專案裡的時間成本一旦投入,都屬於不會退還的沈默成本。也因為時間無法退回,一旦投入就是投入。因此,必須要確定「先」運用時間在重要的事情上。

80/20法則的重點在於:計劃運用「未來的時間」,在有效果的事情上以達到80%的產出。

舉例來說,一個程式設計師,在早上抵達辦公室,打開電腦的第一件事情,應該試圖確認「今天什麼事情對我最重要」,而一個開發團隊,每天第一件事情應該是「今天團隊完成什麼事情最重要」。因此,典型的scrum都會在一早展開standup meeting(快速會議),以15分鐘的簡單開場讓專案團隊確保先投入在最需要進行的事情。

這也是一個聽起來簡單,執行起來並不容易的概念。有很多情況,團隊成員並未「徹底」實踐快速會議時的精神。

例如:某甲陳述:今天會開始開發模組A,預計今天會完成,而這也是他今天最重要的事情。然而某甲可能無意識地忽略掉昨天他的功能B的程式碼尚未簽入版本控制系統,因此實際上會議結束,其實他花了一早上在簽入程式碼,並且執行合併/建構系統。某甲並非不應該完成昨天尚未完成的事情,而是他對於「未來即將使用的時間」沒有腳踏實地的認知。

80/20法則運用在專案的時間管理上,最重要的精神在於「腳踏實地」,並且「確實展現事實」-- 缺乏這兩者,會讓80/20法則淪為壓榨程式設計師的幫兇。



3. 激勵因素與保健因素


激勵保健理論(參考這裡),將影響人工作時心裡的滿意度因素分為兩類:激勵因素與保健因素。簡單的說,保健因素是「沒有會死,但是有也不會很高興的因素」,激勵因素是指「沒有的話不會怎樣,但有的話會很高興」。

激勵與保健理論,乃是在軟體專案管理中,80/20法則運用的最容易忽略的一環。特別是在兩個面向上:(a)軟體團隊經營
(b) 技術決策


(a)軟體團隊經營:

保健因素(薪水,電腦設備,工作環境):無論加碼到什麼程度,對程式設計師的績效成長極端有限,然而一旦失去基本下限 - 例如減薪,則其他的激勵方式會突然失效。軟體專案負責人,應該在一開始,就先確保:保健因素是成員可以接受的。爾後專案執行過程,不要特別關注它即可。

激勵因素(個人成長,價值觀,成就感):激勵因素才是大部份軟體開發專案成員「願意保持工作熱誠」的真正原因。負責人或者領導者,應該將團隊經營的80%重點時間放在保持激勵因素。然而每個人的激勵因素皆有不同,因此了解團隊成員個別的「真正需求」,才是需要花時間的地方。

舉例來說,有些團隊成員可能會抱怨沒有雙螢幕,雙螢幕對於撰寫程式的確很重要,專案經理想辦法弄給他雙螢幕之後,千萬不要以為這樣就會讓他心甘情願賣命。雙螢幕只是保健因素,是必要取得,但不是重點。專案領導者在團隊經營上,應該花20%的時間快速搞定保健因素,而後,花80%的時間確保激勵因素的存在。

缺乏激勵因素的團隊成員,並不代表一定會離職,也不一定代表任務不能完成。一個能力很強的人,可能因為暫時沒有其他選項而在現在的位子上滿足最低限度貢獻。這樣成員,反而成為一個潛在的問題,他隨時有可能因為任何短暫膚淺的因素而離開,更糟的是不離開而成為團隊困擾。而這種情況並非是該團隊成員的問題,而是團隊領導者,沒有辦法找到並維持適合的激勵因素。



(b)技術決策:


既然是軟體開發專案,必然會歷經各種技術決策。80/20法則一定是技術決策的主要運用重點。

以功能而言,如果有A功能與B功能在短時間之內,只能選擇完成一個。則技術決策應該從幾個方向考量:

方向一:中大型軟體專案一定有20%的重要功能,會滿足80%的使用者需求。哪一個功能屬於這類。

方向二:如果A與B都滿足方向一,則考慮哪一個功能會直接滿足「專案目的」。

方向三:如果A與B都滿足方向一與二,則考慮兩者哪一個對於此專案是屬於保健功能(沒有會死的功能),哪一個屬於激勵功能(有的話會很高興的功能)。並且考慮專案目的,是屬於維護且保守的專案,還是開創性的新專案。開創性的專案自然優先考慮激勵功能;而維護型或保守的專案,當然要先考慮保健功能。



80/20法則的有效運用是判斷一個優秀的專案領導人的條件。以反面例子而言:有很多15年以上專案管理經驗的所謂專案經理,他所有的經驗可能都在於無謂的忙碌與焦頭爛額中度過,這樣的15年和1年沒有什麼不同。如果你是這樣的專案經理,為了團隊好,或許應該考慮轉換適合的工作跑道。