顯示具有 培育人才 標籤的文章。 顯示所有文章
顯示具有 培育人才 標籤的文章。 顯示所有文章

11/12/2016

Scrum - 專案壓力來自於無法掌握的命運



一個壓力實驗:

有兩個籠子(A,B),都連結同一個電極器,各有一隻老鼠。A籠子中,有一個燈號和按鈕,當燈號亮起時,如果在數秒內,A老鼠沒有按下按鈕,則就會產生高壓電極,讓A,B兩籠的老鼠都被電的很不舒服。不過,如果燈光亮了,在時間內A老鼠按下按鈕,則A,B兩籠就都沒事。B籠的老鼠則是全然被動的,只要A老鼠能做好他的工作,B老鼠就沒事。當然,經過幾次電極之後,A老鼠很快就學會了一旦看到燈亮,就應該儘速去按按鈕。

過一段時間之後,哪一隻老鼠的壓力大?

經過健康檢查,A老鼠幾乎看不到壓力大的特徵。而B老鼠,則出現各種癥狀:高血壓,胃潰瘍,成長障礙等等不一而足。

(以上內容取自:數位痴呆症:作者Manfred Spitzer)


軟體專案的壓力和該實驗有異曲同工之妙。真正的壓力來源不在於事情有多難,而是在於自己「全然」隨著命運擺佈,無法控制。以A老鼠的情況來說,他仍然是被關著,而還得三不五時瞄一下燈是不是有亮,一旦亮了就得趕快反應。

然而,「至少有一件事情」A老鼠可以控制:他可以決定自己要不要被電極。B老鼠則是沒有一件事情是自己可以決定。因而壓力無從擺脫。

Scrum(實況)是根據事實,固定的時間,以及有效團隊分工來達到敏捷開發的精神。而在此基本精神內,每一個角色都有「至少可以全然控制」的事情,不但可以正確減低無法掌握命運的壓力,更能組合出正確的團隊合作方式。


Product Owner(產品擁有者或產品經理)


在傳統的「瀑布開發模式」,或者,系統整合商SI的「隨意無止盡需求模式」中,產品經理會就所有應該要做的事情列一個驚人的功能清單,交由專案經理負責領導開發。接下來的18個月,產品經理就在B老鼠的壓力下度過,即便有檢查,也不知道產品真正的進度。而18個月後發現意外的機率...已經不是機率而是必然。

而過於認真擔憂的產品經理,更有可能在每一段時間,修改需求,讓開發團隊變成B老鼠,不確定哪個需求改變的命運降臨。

在Scrum中的產品擁有者(Product Owner)擁有非常簡單而清晰的責任,這個責任用非常簡單而清晰的方式減低他的壓力:「撰寫並排序需要完成的使用者情境」。

專案開始時,產品經理會撰寫數個使用者情境(user story)並且排定優先順序,而每個sprint開始時,團隊會告知這個sprint(4周)會完成到第幾個story。產品經理等候4周之後,檢查這些當初答應的story是否有如預期完成,並且在下個sprint開始時,或確定,或重新排列,或增加,或減少接下來要完成story的優先順序。

產品經理仍然不會去「做東西」。然而他確實全然掌握階段性完成,並且確定每sprint開頭都能選他最想要的事情先做完。因此,產品經理確實能掌握這個產品每一段時間的「樣貌」,而不是在最後關頭才求神拜佛,或者要求加班。甚至,在sprint的中間階段,若有必要,產品經理可以要求sprint停止,重新開始新sprint,用來調整後來才發現不正確的優先順序(priority)


Scrum Master (開發領導者)


過去一個團隊的技術領導者,帶領團隊解決技術困難並協調各類工作。他常常會是夾在產品經理(或客戶)以及開發成員中的角色。

在傳統模式下,他若非變成一個技術獨裁者,用以壓迫成員前進並反抗大幅需求改變,就是變成試圖面面俱到的好好先生,用以彌平不同角色的紛爭。「能良好溝通」這個字眼會常出現這個角色的工作描述(job description),但事實上,困難的專案,不會因為一個很能講話的專案經理,就變得簡單。最後最常出現的結果是:專案經理總是能有效呈現「自己的貢獻和功能」,但無法反應在專案成功。換言之,常常看到自己從來不失敗的專案經理,曾經領導了很多壓根不成功的專案。

Scrum Master並非傳統的專案經理,其責任和角色也有很大的不同。而他能有效掌握的事情,也能讓他減少原本專案經理的壓力。

Scrum Master 掌握「會議」。他可以確保每日會議只「說明三件事」:完成了哪些事情,接下來要做什麼,有遇到什麼困難。確保每個sprint開始的會議,領導團隊能完成哪些使用者情境(user story),並且確定這幾個要完成的事情,產品經理都有完整而合理的描述。他雖然沒有掌握全部18個月會完成的事情,但是透過掌握每一個sprint,腳踏實地的一個一個完成優先要完成的事項。

Scrum Master 掌握「真實進度」。透過領導決議「和未完成」以及以事實展現的燃盡圖,Scrum Master掌握過去真實進度。因而可以有效推測未來進度,並有足夠的證據顯示給產品擁有者。因此,才能有足夠的「動作權力」成為A老鼠:仍然在籠中,但掌握部分真實權力,以減少壓力。


Member (團隊成員)


傳統模式下,團隊成員經常是壓力末端。所有的壓力最後承受的出口。所有過勞死最可能發生的地方。傳統上最常出現的是:「某功能我們在要X月X日之前出來!」「現在馬上改做XX不然沒辦法驗收」。

而傳統的產品經理和專案經理 - 無論是軟性還是強硬 - 通常不得已的把壓力直接轉嫁給團隊成員。

但是,在Scrum中團隊成員,決定使用者情境:「真正完成的所需要的時間」。而這個權力,僅代表一個事實:由做事情的人傳達做事情的時間與結果。成員不再在決定什麼事情先做後做,只要決定現在在做的事情,什麼時候可以完成,以及「真的去做他」。換言之,Scrum團隊真正的A老鼠,其實只有團隊成員,只有他才會真正的按下按鈕。然而,如果Scrum團隊不能掌握分工負責的精神,團隊成員很快就變成B老鼠:不是被無謂的壓力掌握自己的命運,就是試圖跳脫牢籠。






10/20/2016

Scrum - 務實的彈性,千萬不要削足適履




夫所以養而害所養,譬猶削足而適履,殺頭而便冠 ......除小害而致大賊,欲小快而害大利

--- 淮南子說林訓


雖然說Scrum的方式與工具十分簡單,能務實並且彈性運用比照著字面嚴守方式來的重要。不過「務實彈性」和「削足適履」有時候只有一線之隔。


形式主義的削足適履


某些形式主義分子在執行Scrum上,會嚴守大部份framework的要求:每日站立會議,燃盡圖更新,user story和PM確認...等等。達成基本要素,似乎就是必要的事。

但是實際檢視其內容,偶爾會有怪異之處,而這些怪異之處,總是自然生出個理由:「因為我們team比較不一樣,所以有不同作法」。但其實以軟體開發來說,每個team統統都不一樣,而是否能有不同的做法,乃是看有沒有掌握agile的精神而定,而非把不一樣當作理由。

常見的怪異之處有:

* 每日會議除了堅持站著開之外,其他完全不堅持,會議中仍然會試著討論專案問題與技術解答。

* 在幾個sprint之後,仍然無法得知專案團隊的速度,因此仍然常有在sprint快結束時強迫加班的情況

* Scrum Master或者team leader會指定工作項目的完成時間

* 出現一些時間長達3天以上的工作項目,但卻又無法更細分階段或者細項。

* 在sprint結束的檢討會議(Retrospective Meeting)似乎都是在檢討別的單位的合作問題。


這些怪異的狀況都是削足適履的表徵。Scrum的精神在於實況並務實,因為「要Scrum」而做出怪異的行為,還不如乾脆不要使用Scrum作為開發方法論。



務實彈性的例子:以功能為sprint


sprint的基本精神在於每個sprint之後,都會產生可「交付」的結果。一般情況而言,專案的每個sprint時間長度是固定的,以符合Scrum的time-boxed精神。

但如果一個軟體產品已經是5.0版,功能趨於穩定,未來的挑戰,其實在於更快速正確的回應市場變化,則其實可以將time-boxed改為feature-boxed。




上圖取自:http://comsysto.files.wordpress.com/2010/06/scrum_cycle.png

簡單的說,每個sprint的開始,由產品擁有者(PO或PM)選定一個「最最最高優先」的user story。只能有一個,不多也不少。接下來的流程,和一般的Scrum相同,break down開發細項之後,由專案成員評估時間。

略有不同的地方在於,評估確切完成時間之後,就是這個sprint需要的時間。因此,可能是2週,也可能是4週8週。完成的定義當然是變成「可以交付的產品」。因此可能是5.0.1版。

假設sprint plan會議完成,決定是5週,之後就和一般Scrum一樣,在5週之後準時交付產品給產品擁有者。而產品擁有者應該會「立刻」將產品放到市場,看看這個「最最最高優先」項目有沒有達到預期的市場反應。下一個Sprint當然也是選擇一個「最最最高優先項目」,可能會花2週,也可能會耗時8週。

對於已經成熟軟體產品,這樣調整的最大好處是,快速取得市場反應,而非等9-12個月之後產生一個6.0的大改版。

產品擁有者(或者PM)自然會對自已的判斷有完整的責任歸屬,畢竟,如果幾個sprint都交付了產品經理認定的最最最高優先項目,而是市場反應卻不怎麼好,那麼產品擁有者當然要負起責任,花更多的精神來瞭解市場,並且將市場需求轉化為適當的user story。


每一種務實的調整,都有其優點和缺點。

「以功能為sprint」的例子中,最大的缺點在於,稍微控制不當,就會變成傳統瀑布開發模型。而時間估算稍有不當,就會容易延長專案難以收拾。因此每一次務實的彈性調整,都應該在sprint之後的檢討會議上,確實檢討改善。


參考:Scrum的缺點




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

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


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

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

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

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


(1) 認證市場


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

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

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


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


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


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

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


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

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

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


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

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



(3) 建議作法


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

1. 自我學習Scrum:

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

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

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

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

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

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

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

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

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

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





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

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

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

7/29/2016

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



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

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

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

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

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


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


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

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

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

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

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




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


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

(1) 誠實

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

(2) 損害控制

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

(3) 小心骨牌效應

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

(4) 不馬上釐清責任

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

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

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



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


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

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

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


(1) 事實說明:


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

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

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



 (2) 事情經過的改善:


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


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


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

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

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

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

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

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





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

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

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








7/28/2016

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



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

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

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

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

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

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

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

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

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

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


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


1.  即時會議記錄:


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

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


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

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


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

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

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





2.  分析與設計:


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

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

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

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




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


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

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



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


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





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

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