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

8/17/2017

如何學好工作英文 - 極簡計畫書



在台灣職場上,英文能力是工作能力重要的一環。英文能力不好,並非職業生涯就會失敗,也不是就不能賺很多錢,只是會「受到各種限制」。有正確足夠的英語文能力,會讓職業生涯有「更多選擇」。

除了在自己的職位上,有需要以英文讀寫和對跨國組織的溝通之外。還有兩件極為重要的
其是:

(I) 擴大其他知識學習的能力。當你可以順暢地閱讀聽取英文資訊時,你路上的知識來源,就遠比只會中文多了數倍。

(II) 擴大資源取得的範圍。當你可以流暢的使用英文,就可以把想做的事情,透過網際網路外包給其他國家。


就和其他計劃一樣,執行力永遠比計畫詳盡來得重要。而執行力是透過「限定時間」的「分階段」採用「正確方式」達成。


如果你目前還沒有自己的方法,或者,曾經試過自己的方法只是不太成功。那麼請考慮這個極簡一頁計畫書。

到此下載計畫書

這個計畫乃是參考(註1)的做法,與實務驗證改善而來。此極簡計畫適用於TOEIC 695分以下的上班族。


「如何學好工作英文 - 極簡計畫書」的使用步驟如下:

(1) 找到原因,定義目標


第一個,也是最重要的步驟是「坦白原因,定義目標」

每個人真正想學好工作英文的原因都不同。而真正的原因才是讓個人努力的動力。

找到自己想學好工作英文的真正原因。可以用消滅法,判斷這個原因是不是最重要原因。在計畫書中,將最重要原因填在80%欄,次要和第三原因填在16%欄與4%欄。將80%欄遮起來,想像一下,當這個原因消失之後,自己是否就不想精進工作英文了。如果這個原因消失,但是自己還是很想精進工作英文,表示不是真正原因,或者描述的不正確。

請填寫找到真正原因填寫於左上角。

目標是在未來一段時間(14週)預計取得的成長。

極簡計畫有兩個既定目標:

(a) TOEIC 800以上 
(b) 能以英文簡報10分鐘關於現在的工作進展 

另外,可以去掉目標(b),也可以自己制定目標(c)。但是,沒有特別原因的話,必須要留著TOEIC 800的目標。

在右下角的目標準備,就是為了確保自己已經報名TOEIC


(2) 學習材料準備


極簡計畫學習教材都是不用錢,而且對工作英文來說效果很好!

「起床後15分鐘」的教材是BBC網站,需要電腦或者手機才能使用。

「空閒的10分鐘」教材是一本英文書。


(a) 聽/說教材


聽和說請用BBC網站教材。這些課程都是以影音方式大約3-7分鐘。
請先設定好書籤於瀏覽器中,或者用手機也可以。實際學習方式請看: (3) 執行 


BBC英文學習課程:有用!簡單!又不花錢!

BBC English You Need
http://www.bbc.co.uk/learningenglish/english/course/english-you-need

BBC English At Work
http://www.bbc.co.uk/learningenglish/english/features/english-at-work


(b) 空閒時間的純閱讀:How to Read a book


建議直接列印出來。目標是看完第一,第二部分。約138頁,每天10分鐘閱讀一頁半左右。


(3) 時間分配


太長時間等於是挑戰自己的意志力,但是每天工作很累的人的意志力是有限的(註2)。

這個計畫是以3個月(14週)為目標時間,每週6天,每天僅25分鐘。這25分鐘,分成早上起床後15分鐘,和空閒10分鐘。

早上起床後15分鐘


早上一起床,要花15分鐘學習英文。如果你平常是9點起床,就改成8:45,如果是8點起床,就改成7:45,如果是7:30起床,就改成7:15。無論如何,一定是起床後的第一段15分鐘是在學習英文。早點起床學英文,絕對比晚點睡學英文的效果強太多太多!

空閒的10分鐘


在每天空閒的時候:坐捷運,上廁所,上班休息時間等等,花10分鐘閱讀。強烈不建議在睡覺前閱讀。這10分鐘最好是連續的10分鐘。

實際作法請看(3)執行。

在計畫書中央有個6x14的表格。在表格上有開始日期,下方有結束日期。直接填好開始日期以及14週之後的結束日期。

時間耗費其實很少,所以要確切執行,其實不會是時間問題,也大概不會是意志力問題。恐怕只是「習慣」與「執行技巧」的問題。

14周之後,無論如何,時間到就結束,並且以實際方式檢討結果。

(3) 執行!


當極簡計畫準備完成,接下來當然就是執行極簡學習計畫。
計畫執行非常非常簡單,所花費時間也非常非常少。

執行是每天,或者說每星期至少六天,做三件事情:
(a) 早上起床學習15分鐘以上
(b) 空閒時間閱讀10分鐘以上
(c) 把計畫書上的進度表格塗黑,並且自我檢查是不是有按照計畫進行

(a) 首先是起早學習15分鐘


所要做的事情是到BBC網站上,在BBC English You Need或者BBC English At Work選擇一個課程來「聽」。只聽不看,有聽不懂的暫時不理會。BBC的課程很短,大約5分鐘而已,聽完之後,在看上面的英文說明,還有不懂再查字典。

經過3-4天,如果你認為太簡單,BBC也有進階教材:

http://www.bbc.co.uk/learningenglish/english/course/towards-advanced

但是對於簡單的教材必須熟悉到「輕而易舉的理解」,才能進展到進階教材。而坦白說,倘若你的TOEIC成績不到850分,進階教材可能不太適用。

(c) 其次是每天空閒閱讀10分鐘:


找空閒10分鐘閱讀
教材是How to read a book。閱讀方法是印出來,在每天空閒的時候:坐捷運,上廁所,上班休息時間...等等,任何空閒的10分鐘都行,連續10分鐘閱讀。強烈不建議在睡覺前閱讀。


閱讀方式是,直接看完,中間看不懂的字先圈起來,如果可以的話,猜測一下不懂的字的意思。讀完一個段落,約1.5頁,閉起眼睛回想一下這一頁的意思,然後,再去查字典。切勿背單字,應該去了解整個句子的意義。

How to read a book是本經過設計的老教科書,用到的單字有限,其目的是在教學生「如何閱讀英文書」所以,當你看完這本書就可以一舉兩得,確保可以你的英文閱讀能力,真正往前進。

(d) 每天檢討:把計畫書上的進度表格塗黑,並且自我檢查是不是有按照計畫進行。

這個部分最重要的是,不要欺騙自己。請參考下一段(4)過程檢討。


(4) 過程檢討


極簡計畫書中央有個6x14的表格表格。每個格子代表一天,每天當你完成「早上起床15分鐘」和「空閒10分鐘」的學習之後,就可以把它塗黑。只完成一項就塗一半,都沒做就留空。

必須要把這個計畫放在每天都一定會看到的地方,例如辦公桌的某個小角落。表格上面只有開始日期跟結束日期,中間並沒有日期,但請不要趕進度,每天最多也塗黑一格!

如果有不預期的情況發生:例如連續兩天沒有按照進度進行。不要試著去彌補它!不要在某一天連續趕兩三天的進度,而是要找到一個方式,讓這不預期的事情,「以後」不要再發生。不彌補是因為過去的事情本就「已經過去」,和彌補錯誤比較起來,在極簡計畫中,更重要的事不讓錯誤再發生!


(5) 計畫結束


極簡計畫的概念是,無論如何,結束時間一到,計畫就結束了。

這時候必須要知道和原定目標有多少差距,如果TOEIC考了815就表示達成,考了790就表示沒達成。如果可以輕鬆地用英文解釋現在的工作狀態,就表示達成了。

然而,因為是你自己自定的目標,其實在計畫結束後,可以很清楚的看到過去14週以來的成果,即便沒有達到目標,應該會有大幅進展。也不見得要對自己太嚴厲。

重點在於結束之後,可以再次啟動下一階段的工作英文學習計畫。把握原來的極簡計畫的關鍵:限制時間,清楚目標,過程執行,檢討結果,並且不要花太多時間,當然就可以讓自己的下一次計畫效果更好。

到此下載計畫書


問題與解答:


Q1:可否修改計畫書?


Ans:極小幅度更動當然可以,例如把14週變成12週或者15週,把每天25分鐘改成30分鐘。但強烈不建議進行大幅更動。因為此計畫是經過設計與驗證,對絕大部分上班族是最能在耗費最短達到最大的工作英文進步。

Q2:我沒辦法早起學英文。


Ans:無論你現在做的是什麼樣的艱難工作,早起15分鐘通常是可接受的範圍。如果你沒辦法早起學英文,大概就表示你不太想或者不需要精進工作英文。

Q3:這計畫對我來說太簡單?


Ans:此計劃是用於大學研究所畢業後開始工作2-3年的上班族。如果你英文已經很好了(例如,TOEIC已經850分以上)當然就不適用此計畫。

Q4:此計畫對我來說太難?


Ans:如果你已經大學或研究所畢業,然而仍然覺得很難使用英文聽說讀寫,這計畫可能是有點難,但絕對不是做不到,只看你有沒有決心而已。

Q5:為什麼一定要去考TOEIC?


Ans:TOEIC是目前為止,比較有公信力的商用英文測驗,它並不困難,很適合「不準備」的情況下完全按照實力去應考。當然應考前還是要看一下題型,考試方式,跟考試用具。




參考:

* 註1:在義務教育的語言學習,大部分的人都認為沒效率而且也不實用,不僅只是台灣而已,而是放眼世界皆然。有本書可以參考一下: Fluent in 3 Months。這本書有中文版。

* 註2:意志力的研究有很多矛盾的地方,請參考這裡




2/16/2017

建立軟體開發團隊 (1) 計畫 組成




... of the 20,000 notable players for us to consider, I believe that there is a championship team of twenty-five people that we can afford, because everyone else in baseball undervalues them...(Moneyball 魔球)


軟體開發團隊的建立和運作,不可能有完美的狀況。但是,妥善的計劃,能大幅降低軟體團隊的運作風險,並且讓團隊成員專注於發揮專長和創意,減少不必要的浪費時間。

特別是浪費時間在於解決非技術性問題。


問題有可能來自各方面,例如:

(1) 目標極端困難。例如:要在3個月內完成類似AWS EC2的雲端運算平台。

(2) 目標不確定性極端的高。例如:團隊目的是要完成一個不知道誰簽訂的模糊合約。

(3) 團隊還沒組成,目標也還沒確認,就已經有時間壓力。例如:一個2-3個人合作的新創公司,剛剛獲取資金成立。

(4) 團隊的組成有時間壓力。例如:在大企業中,因為高層要求,一定要在某月某日找齊7個人組成團隊

(5) 團隊已經有部份是問題成員,在此同時還要因組織任務擴張而增加人力。

(6) 因為組織變動(例如企業改變目標,併購等等),讓某個團隊大幅流失人才,而需要重整補齊人力。

(7) 因為文化與跨國合作困難,導致前期人力大幅流失而需要重整團隊。


負責組織團隊的人,最最基本的認知就是:

軟體團隊組成這件事情:本身一定會有困難與挑戰。不具備困難與挑戰的軟體團隊,其實沒有存在的必要。(註1)


以下三個步驟可以供組織團隊負責人參考:

(1) 了解探索事實,盡可能將事實攤在陽光下


許多新團隊一開始就建立在「各種假設」上。例如新創團隊「假設大家對Scrum都有相關經驗」,或者「假設在3個月後可以找到2個優秀的iOS開發人員」,或者「假設大部分的使用者都有fb的帳號」,或者「假設3個月內某個模組可以先行開發完成」。

在許多情況之下,很多事情的確有假設,才能進行下去。

但是,在建立團隊的時候,除了瞭解背景假設之外,先確認事實才重要。

以下事情必須要儘早確立。

(a) 團隊目標願景:

可參考下節「確切定義短期中期目標」。如果是非營利組織,團隊願景就非常重要。因為這可能是召集成立團隊的最大動力。一般企業,營利組織,除了獲利之外,也可能會伴隨其他更遠大的目的。例如:「讓人類可以移民火星」之類的(註2)。

一個有崇高理想的非營利團體,也就不應該將盈餘拿來作為績效獎金。而是以團隊能達到的願景作為激勵人心的最大方式。(例如Kiva)

相對的,如果只是單單純純想賺大錢的公司,例如某東南亞賭場在台灣的軟體部門。也就不需要唬爛一個崇高的偉大目的,就只要讓團隊了解「大家來歡喜寫程式賺錢吧」即可。因為有正確的認知,才能集合正確的團隊。一個誠實的宣稱「大家來寫程式賺錢吧」的團隊,自然不會將社會責任活動當作是團隊成員想要做的事(例如:到沙灘撿垃圾,協助獨居老人),當然「培育企業人才」也不太需要,甚至Scrum裡面的「自己選取task來做」也根本不用,採用由上而下的軍隊式管理,讓工作以最有效率的方式完成,才是這種團隊的最好方式。


(b) 資源現況:

目前的現況是不可否認的事實,但許多人一開始的時候,會將現況和未來的希望混為一談。在此時此刻擁有的資源就是現況。

例如:現在有1個專案經理,以及1個剛剛到職的工程師,未來可以找10個人。...這就是資源現況。

但也有可能是:現在有1個專案經理,以及1個剛剛到職的工程師,未來可以找10個人,但是辦公室座位目前只有4個空位。...這也是資源現況。

更有可能是:現在有1個專案經理,以及1個剛剛到職的工程師,未來可以找10個人,但是辦公室座位目前只有4個空位。而團隊目前總薪資預算為1千萬台幣,其中還得包含筆記型電腦採用費用。扣掉已經到職的兩個人,年預算只剩下600萬台幣,所以可以找10個人,但是平均年薪只能為60萬,或者找6個人,平均年薪為100萬。...這也是資源現況。

作為一個建立並組織團隊的人,資源現況的瞭解和掌握,必須要越清楚越細節越好。實際上,絕大部分的情況下,只要稍微多花個幾個小時,就可以掌握到很多現況細節。


(c) 組成專長:

即使已經是軟體開發的專家,這仍然是一件需要擔心的事情。

如果團隊的短中期目標確定,組合的專長可能大致確認。然而,某些專長不見得是「團隊成員需要有的」,這些專長可能可以用「短期購買」取得。

團隊領導者在取得事實的階段,需要清晰可見的專長分佈圖。

以上圖為例:簡單地列出做一個購物網站可能需要的專長,並且也把目前團隊已經擁有的人才能力列在其上。未來在組合團隊時候就比較容易考慮周詳。

要注意的是,這樣的圖並不是要完全技術上正確,而是要做為未來計畫的參考。因此有可能一再修改,也不見得需要用了不起的繪圖軟體製作。


(d) 關鍵成功因素:

哪件事情做好了,會讓這個團隊成功。成功關鍵因素應該只有1-3個,不應該太多。 這個關鍵成功因素必須要很「實際」,能夠被「衡量」,當然也必須要是能「達成」。至於困難不困難就不一定。以xspace的火箭設計為例,他的關鍵成功因素不只是火箭能發射,還要能「掉回地球後,能自己站立,以便低成本回收」。

軟體開發團隊的「建立組成」的通常是願景能否達成的關鍵成功因素。然而,建立組成的本身也有關鍵成功因素。例如,在2個月內吸引3個具有5年工作經驗,並且容易合作的工程師到職。



....其他需要搜集以及展現的事實還有不少。完整清單請參考(註3)。當然,不可能花幾百天的時間,只是為了收集事實,只要在合理的時間內,盡量收集了解重要的事實。


(2) 確切定義短期中期目標



前段所述的事實如果了解的夠完整。定義短期中期目標就很簡單。

短期目標是1週到4週內「必須」完成的事情。中期目標則必須要能夠「完成一項的關鍵成功因素」。

以建構軟體團隊而言,八九個短期目標完成後,差不多就等於一個中期目標完成。

任何軟體開發計畫,必定會有目標,而讓團隊朝向「同一個方向」前進。所謂團隊,當然是一群人往同一個方向前進,才能叫做團隊。一群在同一個組織架構的人,或者在同一個老闆底下工作的人,不見得是一個團隊,很有可能每個人在軟體開發



(3) 根據目標擬定計劃和備用計畫- Plan B



兵法有云「夫未戰而廟算勝者,得算多也;未戰而廟算不勝者,得算少也。多算勝,少算不勝,而況無算乎!吾以此觀之,勝負見矣。」

計劃本身並不重要,但是做計畫這件事情很重要。

計劃要達到的目的要非常清楚。而且必須「至少」包含兩件事情!

*** 達到短中期目標的做法 
*** 實質建立工作環境與實際做法

建立軟體開發團隊的初始計畫至少需要涵蓋以下內容:

(a) 團隊目的,短中期目標

....請參考前兩段...

(b) 團隊組成

需要哪些專長的人在這個團隊。更重要的是,哪些技術背景的人的組成最適合這個團隊。最好的方式是將所需要的「實質技術能力」清楚地列個圖示,根據分佈圖,來劃分團隊組成。

切勿用想像的方式。




以上圖為例:這是一個打算建立電商網站的技術分布圖,和目前團隊成員(四個人)所擁有的技術連結。可以很清楚的看到哪些領域還沒有適當專長的人。也可以清楚地展示,團隊目前組成和未來最需要的地方。

這個草圖並非正確的描繪出細節,而且也把技術不相干的東西納入(例如裡面有個API doc,其實是還沒有去做的事情)。但整件事情的精神在於「視覺化」。透過視覺化,對團隊的變化才有整體性的考量和規劃,而不會落於枝節上。


(c) 團隊運作原則

近年來流行Agile的Scrum方式。可以參考這裡


(d) 初始化工作項目

當團隊的成員是逐漸到職,最初的工作項目是能夠讓團隊快速形成共勢。這看似枝微末節,但是是隱含的關鍵成功因素。

初始化工作項目,在新成員到職的前幾天,最好是鉅細彌遺。規劃了新成員第一天到第五天,「每天」要做的事情和達成的結果。並規劃前4週,要達到的大項目,以及前3個月的必須要的貢獻程度。

團隊是由一個個單一個人組合起來。將個別成員的適應期縮得越短,對團隊的組成越有利。

規劃前五天的細目,絕對不會讓這個新成員變得沒有創意,也絕對不會扼殺他的潛能。反而是讓他可以在極短的時間之內,先擺脫掉和「智慧創意」無關的邊緣事項。因為這些邊緣事項,如果在前一段時間沒有擺脫,之後會一直出來煩大家。

以下是某個電商開發團隊的前三天初始化工作項目,同時也是檢閱清單:

Day-1  
    - Mentor介紹工作環境,取得電腦和其他硬體設備
    - Mentor協助取得email和其他必要的帳號
    - 取得目前程式碼版本控制系統權限,確定可以clone
    - 確定clone目前的程式庫

Day-2
    - 取得目前的UI/UX設計文件,Mentor協助了解文件內容
    - 參加Scrum會議,理解Scrum雞與豬的原則 
    - 在Mentor協助下,建立自己開發環境

Day-3
    - 在Mentor的協助下,在自己的開發環境確定能修改程式/簽入(commit)/建立branch,最後產生自己的build。
    - 了解基本的測試項目

以上僅是3天的範例,這些看似細節,但要在三天之內完成也不並容易。


(e) 定期檢討方式

檢討方式可以參考這裡這裡

簡而言之,建立團隊的過程也需要被檢討。

例如:

新加入的成員,在當初面試的時候所呈現的能力,和實際上工作的產出,是否吻合。

新的成員對於非技術類型的雜事,是不是很快能找到資訊。例如git的位置,目前各個branch的狀況,自動化建構的方式,建立開發環境的方式等等。




註1:如果這個挑戰對負責組織團隊的人來說太過困難,最好不要接受這樣的任務。一個失職的程式設計師頂多讓專案推遲幾天,或者品質降低一些;但是一個失職的領導者,會讓整件專案崩壞。


註2:例如xspace

註3:建立軟體開發團隊的事實搜集清單

(a) 團隊目標願景
(b) 資源現況
(c) 組成專長
(d) 關鍵成功因素
(e) 關鍵風險 - 一旦發生就可能會失敗
(f) 關鍵技術 - 是否有必須具備的關鍵技術,需不需要招募這樣的人才
(g) 利害關係人 - 哪些人跟這個團隊有實質的相關
(h) 外在環境 - 辦公室設備 是否有遠端甚至跨國合作團隊等等






2/06/2017

Scrum - 團隊中永遠的反對黨



最近被問到的幾個問題:

   - 怎麼聚焦討論,譬如說有人很愛插話,或者有人很愛在會議室角落另開討論群,或者有人非常堅持己見,很愛先否決對方 ...

   - 有遇過非常固執的人,總是以否定句開頭去否定對方嗎 ?


   - 有人固執的反對什麼事情都反對


....


以Scrum/agile方法為核心的團隊有先天上的「平等」和「自發」的假設。Scrum假設人人都有某種能力,並且也假設,團隊成員對於「溝通」都有某種程度的共識和經驗。

然而,實際情況通常不太美好。

** 技術人員常常會因為麻煩,而反對業務上的決定
** 業務人員因為對技術不了解而作出自相矛盾的決定
** 開會時候常常岔開話題
** 因為不專心,很多人在開會時候搞不清楚情況
** 某些人常常提很多意見,而且實在太多意見!

任何由人組成的團隊,多少都有溝通問題。如果你是團隊領導者,或者Scrum Master,溝通問題一定是你必須要負責的問題!

Scrum溝通問題,就像處理bug一樣,最好的解決方式是「事先解決」。有三個基本共識必須要事先建立。

建立這三個基本共識,可以讓未來的溝通變得簡單清晰,減少不必要的誤會。

(1) 建立雞與豬的基本共識


專案管理中的「負責角色」有各種說法。RACI可能是近年最常見的。

** 負責人(R = Responsible),負責執行 
** 誰批准(A = Accountable),對任務負全責的角色,通常是負責人的老闆 
** 顧問(C = Consulted),提供意見或建議的人 
** 通知誰(I = Informed),被通知結果的人,例如其他部門的相關人等 

在Scrum專案中,可以被簡化成兩種人:雞和豬。(雞與豬的故事可以在網路上找到很多版本,例如這裡)


豬:負責做的人也是負全責的人

雞:所有其他人(當然必須是和這個專案有關的人)

在溝通時,所有雞都可以出意見,但是豬一定擁有真正決定權。畢竟是豬被切肉出來做火腿,雞只要下蛋而已。

就平等的軟體開發Scrum而言,任務是有自己選取。但是就實務上,專案管理者不但身兼Scrum Master可能還會身兼分配任務的角色。這時候,等於是分配「誰是豬」!

任何會議上,對「豬」的正面或負面意見都可以討論,但是最終決定必須要是「豬」。

例如,PM決定哪個功能要先做,而工程師都反對,原因是嫌未來會有其他麻煩的事情產生。然而,就決定功能的先後次序來說,「PM就是那隻豬」而其他所有人「都是雞」。

團隊必須要有清楚的認知,才不會有無謂的抱怨和繁瑣的溝通。而清楚的認知,是團隊領導者的任務。


 (2) 建立事實優先的基本共識


Scrum溝通,必須,而且只能,建立在事實上。

這也是為什麼每日例行會議只說明三件事情:哪些工作完成,接下來做哪些,遇到什麼問題。

假設有人在某討論會議中說「現在UI速度很慢,登入要等很久」。某種程度來說,可能是事實。但是,「慢」以及「等很久」,都只是形容詞,必須要請他提出何謂慢,什麼叫做等很久才能繼續有意義的討論。

或者,有人提出「如果先做A會讓之後變得很麻煩,應該要先做B」。這其實也是模糊的說法,A和B這兩個功能,如果先做A是會讓以後時程延後8小時?還是8天?還是8個月?這才是根據事實的討論。

然而,這種建立於事實的共識,Scrum Master必須要不厭其煩的提醒和導正,才能建立這種共識。



(3) 建立產出優先的基本共識


大部分的專案,都是需要產出某些東西。無論這個東西是軟體,或者硬體,或者某些解決方案。

在團隊討論中,要讓「為反對而反對」的人閉嘴的最佳方式,就是以「產出優先」而不是以「嘴巴講」優先。

例如,某工程師強烈反對A做法,希望改用B做法。最好的方式就是請這個工程師,作出他自己希望的A做法,用以和B做法比較。如果他說「沒空」或者是有「更重要的事情在做」,那表示他的強烈反對,也不是那麼強烈。

至於對於「只反對而不提出取代方案」的人,其意見大概也只是僅供參考。如果經過負責的豬判斷,其意見很好,當然可以欣然接受,加以改進(例如在code review的時候)。





如果尚未建立這三個共識。就已經發生溝通問題。團隊領導者或者Scrum Master仍然有彌補的方式。

不過,越早了解,並試圖解決溝通問題,通常成本越低。

那麼可能的解決方法有:


(1) 自己的問題?


如果你是一個領導5人以上的團隊領袖,無論你的名稱是Scrum Master還是專案經理,如果你認為團隊裡「大部分的人」都有溝通上的問題。

那麼真正有問題的人是你!!

但是也不要太緊張。這並不代表你是個無能的領導者。只是你的實際行為,讓團隊容易產生溝通問題。

問題的產生點可能是:

(a) 試圖面面俱到,顧及每個人的感受,而非先考慮事實。每個人都喜歡受人愛戴,但是在軟體開發團隊中,鄉愿和受人愛戴只有一線之隔。唯有根據事實,腳踏實地領導事情的進展,才是長久之道。為了顧全少數人的面子,或者僅為了顧及某一兩個老是抱怨東抱怨西的人的心情,對團隊從來都不會有好處,反而只會讓多數沉默工作者更難獲得信任


(b) 未掌握Scrum精神,只是掌握Scrum的作法。請參考這裡

(c) 其他,請參考:作為技術領導者的方式



(2) 解決老鼠屎


如果團隊之中,溝通問題老是產生於某個人。

除非此人是像高斯,愛因斯坦之類的天才中的天才,否則不應該容許有嚴重溝通問題的人存在於團隊。

這類型人有幾種表徵:

(a) 無論什麼事情都悲觀 
(b) 事情不分大小時常抱怨 
(c) 問題都是別人的錯  
(d) 常認為自己懷才不遇
(e) 不願意做某些無聊的雜物

其實,每個人或多或少都會抱怨,也會有悲觀的時候。此乃人之常情。但是如果非常嚴重,那麼這個人就會變成鍋子裡的老鼠屎。只要鍋裡面有一顆屎,即使被稀釋了幾萬倍,也不會有人想吃那鍋飯。團隊也是如此,一個負面老鼠屎,其影響範圍遠超過5個好隊友。

老鼠屎不見得就是錯的,他或許自己創業會變成一個好創業家。因此,及早讓不適合目前至個團隊生活的人離開對大家都有好處。

(3) 縮小範圍


當溝通問題發生,可以將重要的溝通,盡可能縮小範圍,讓溝通清楚簡單。

這聽起來是淺白無聊。但是,實際上在團隊之中,太多無聊的溝通錯誤發生,以致於這麼簡單的事情,仍然值得注意。

以Scrum而言:「DOD」什麼是完成,乃是基本的問題。即便團隊已經彼此合作過一段時間,仍然三不五時要確定一下什麼叫完成。

以溝通進度而言,必然將最近在做的事情,縮小其範圍到「最近的一個完成點」。 無法縮小表示根本不知道自己在做什麼。舉例來說,軟體開發中,如果有一個人的某A任務,需要20個工作天,那麼在3天的進度報告,絕對不能聽到「還有17天就完成」,而是要縮小範圍到:「下一個milestone會是明天,而預期也會如期完成」。因為,最近的一個檢查點(milestone) 如果不能如期完成,就代表未來的17天,很有可能也不會如期完成。反過來說,最近的一個milestone會完成,那麼未來就比較有可能如期完成。

縮小範圍也可以讓「雞和豬」的責任範圍展示的更清楚。

有個真實的案例:有個團隊舉辦慶功宴,由甲和乙兩位負責。甲很熱心的定好了餐廳,並且就「自認為剩下的事情乙會處理」,然而乙心理認為,既然甲定了餐廳,表示後續的小事情甲也會處理,畢竟許多事情和餐廳有關係。那麼到了慶功宴當天,當然除了餐廳定好之外,其他的雜物(例如當天如何報帳之類)一件都沒完成。

另一個真實的案例:有個軟體開發專案,大家都認為某甲的程式需要重構(refactorying)。但是,某甲認為他需要4周才能完成,因此遲遲不肯進行,大家也難以和某甲溝通。專案經理於是縮小範圍,先找某甲也認為很小規模的一個功能-原本預計一天-加以重構,透過pair-programming,確定某甲專注於這個任務上,最後只花了1小時。因為有這樣的證明,專案經理於是要求某甲先完成全部程式碼翻修,最後整體只花了2天就完成,雖然仍是麻煩事,但遠比某甲估計的4周來的快太多。其原因也很簡單,重構是繁瑣麻煩的事情,當然會被估計成很長的時間。





12/22/2016

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



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

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

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


為什麼?


績效評估要及時


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

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

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

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

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

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

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

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

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

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



轉職衡量要完整


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

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

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

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



那麼,年末可以做什麼?


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



1. 不設定一年為單位


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

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

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

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

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



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


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

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

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

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



3. 不等候重要的事情


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

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

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





參考:

努力的三個迷思

工作上學不到東西

因沒挑戰想要換跑道

工作太忙沒時間?

職業生涯的突破

成長的最好方式:檢討


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

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

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



11/24/2016

企業巫醫 - 如何拒絕或調整客戶不合理的需求




在各類型的軟體開發情境中,有時候開發人員會有機會面對客戶的需求。而最近就有一位研發團隊的工讀生,在即將離職時,問了一個經典的問題:

--------------
你們是如何拒絕或調整客戶不合理的需求?
--------------


問題的本身很經典,但是卻必須要追本溯源。

首先,需求(requirement)本身是很難被界定清楚,因為客戶也許也不能清楚的界定需求。Henry Ford 福特 - 福特汽車的創辦人,現代化造車的始祖 - 早在一百年前的名言,至今仍難屹立不搖:
--------------
“If I had asked people what they wanted, they would have said faster horses.”
"如果我問客戶要甚麼,他們會希望跑得更快的馬"
--------------


然而,「直接了當的詢問」仍然是基本的第一步。不過也要先確定問到正確的對象,問了正確的問題,正確地理解回答。透徹的了解問題,才能知道客戶的需求是不是真的不合理,抑或,其需求背後有另外的需求。接下來才能知道怎麼反應。

還沒經過深思熟慮就直接拒絕,很有可能是自己故作姿態,甚至是知識技能不足的表徵。(註一) 

反過來說,隨意「答應」客戶,風險也很驚人。因為也許答應了一件根本不應該做的事情,或者答應了一件其實客戶表達錯誤的事情。最悲哀的結果是雙輸:客戶與企業都受害,甚至三輸:客戶企業與社會三者都受害。

而這聽起來極端荒謬的事情,卻一直在企業界發生。


因為誤解客戶需求,或者不夠及時調整需求導致於雙輸的例子,在近20年內的有很多,隨便找一些範例如下:

* FoxMeyer的SAP引入案例(1,2)

* Waste的SAP引入案例

* 台灣戶政系統當機事件(1,2,3)




那到底要怎麼做?


1. 根據事實的正確溝通


抽象化的形容詞,對溝通不會有助益。

例如:「高可靠度的系統」「網路速度很快」「網站介面很好用」「滿足業務需求」「盡快完成」

抽象化的言語,在務實的書面報告中越少越好。當然某些摘要形式的報告,會很抽象,但隨後必定附上務實的參考依據。

例如:

「高可靠度系統」:已兩台伺服器互為備援的方式,達到高可靠度

「網路速度很快」:過去對外連線的速度是1MB,現在提高到1TB,因此網路速度很快。

「網站介面很好用」:過去每個月平均有150次客服電話,是在詢問網站某些功能要怎麼使用,現在每個月僅有10次。並且,每個月平均使用人數並沒有減少。


2. 透過具體內容決定接下來的執行事項



互相理解現在的情況是第一步。接下來要做什麼是第二步。

為什麼決定接下來要做什麼和「客戶不合理的需求」有關?

首先,合不合理的判斷本身就很難客觀。對某人來說不合理的事情,對另一個人可能完全正常。彼此價值觀的差異不可能在短時間彌平。但是「具體要做的下一個動作」卻是清晰可見,只要接下來的執行「事項」,確實都是雙方認為最重要的事項即可。

和第一段相同,具體內容必須是清晰可見的動作(action)

例如:

* 將第一批手機抽15%樣本共150隻,進行電池過度充電放電測試。並在N月N號之前,給出測試結果報告。

* 將iOS app送到apple-store進行上架審核。

* 在使用者帳號管理系統上,增加可以使用fb帳號登入的功能,在N月N號之前,給出設計文件。

不是清晰可見的動作,會造成很多不必要的誤解,而誤解就會產生不合理的需求。


不清晰的動作例子如下:

* 產線上的手機抽樣測試一下有沒有爆炸問題 -- (這是要多少樣本測試,一隻也可以嗎?要測試哪種類型的爆炸?太陽曬到玻璃破碎也算嗎?)

* 我們的iphone app要趕快上架了 -- (?是要上架到哪邊)

* 讓fb帳號也能登入系統  -- (是什麼時候要完成?只要登入就可以,細節我們自己決定就好了嗎?還是要先看一下設計文件)






3. 務實的密集檢討事實



這可能是最重要,但最被台灣企業所忽略,也最容易被企業巫醫上下其手的地方。

可參考這幾個地方:(a) 錯誤檢討,(b) 自我反省,(c) Scrum檢討


「務實」:指的是根據事實來檢討,而非根據感覺。即便是需求檢討也是。

例如:某中國企業要求網站系統必須能讓IE8使用。但是IE8上的javascript版本實在太舊,這樣的要求讓專案經理非常不高興,覺得根本不合理也太不可思議。

如果不務實檢討,那麼每次與客戶的會議,大概就在針鋒相對中度過。但是探究事實,其實是因為該企業內部系統無法擺脫WinXP,而又因為WinXP能使用的IE就是IE8,導致客戶有此需求。就網站廠商來說,當然不可能協助內部全面升級為Win10,但卻可以提供其他在WinXP上,仍然持續更新的瀏覽器(firefox)。


「密集」:指的是Scrum的精神。需要在一定時間(sprint)讓客戶看到,並且用到那段時間產出。確保客戶對團隊前進的方向是一致。也確保即便團隊方向有誤,也會在一定時間內被發現。

「事實」:有時候事實很難全面探究完整。有時候細節太多,即使都是正確的資訊也過於繁複。

巫醫在同樣的事實上,都會有不同的詮釋。例如:經過鞭打火烤病人之後,病人仍然掛了。巫醫的詮釋通常是:惡靈不願意離開病人,是天命所致。

而以「事實」詮釋「事實」才不是誤人一生的巫醫。當軟體開發團隊常常客戶不合理的需求。不應該隨隨便便將此視為「惡靈不願意離開,乃是天命」。而應該「改變」執行方式,應對不合理需求。如果巫醫不願意改變(註二),換一個醫生是根據事實最合理的方法。





註一:違法的需求,當然是要直接拒絕。這類型的基本常識,不在此討論範圍之內。
註二:如果巫醫很容易以事實說服,那就不是巫醫了

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


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



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


時間似乎是最終的敵人?


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

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

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

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


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


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


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


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

一:加速 - 跑的比它快


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

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

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

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




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


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

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

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

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

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


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


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

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

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




那結論呢?


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




註1:CP值,或者性價比,請參考這裡

註2:這句話很多人都講過,包含郭台銘和柯文哲。不過,這個名言最早應該媒體大亨:梅鐸所說。另外,這句話在2002年也是某本書的名字。

註3:將時間視為第四個空間維度來描述,請參考狹義相對論

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



9/14/2016

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


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

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

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

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

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

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

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

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

困難一:區別人力與人才


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

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

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

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

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


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

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

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

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


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

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

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


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

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

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

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



困難二:培育或取得人才


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

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

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

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

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

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

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

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

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

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

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


困難三:薪資獎勵


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

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

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

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

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

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

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

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



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


(1) 選擇


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

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

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

這也不是什麼新鮮事。

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

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


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


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

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


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


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

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

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


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

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


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

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






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

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




9/13/2016

數據分析從零開始 - (2)資料取得和前處理




既然要分析資料數據,自然要有資料數據才能分析。資料取得是必要的事情。

資料來源有很多種,取得並且事後處理的難易度各有不同。

但可以確定的是基本情況是:

1. 資料的時間,會遠超過自己的想像

2. 在開始進行分析之前,資料整理的所花的時間精力,也會遠超過自己的想像

3. 資料整理,幾乎不可避免

4. 資料整理,沒有捷徑也沒有神奇的密技,只能靠不懈怠的努力耐心以及經驗

5. 實際上有創意,有價值的數據分析,都不能免除資料取得和整理。 



第一手資料:


在「嚴格的一手資料」定義下,做資料分析的人真的拿到一手資料的機會極端的少。不過如果你是購物網站的大老闆,則購物網站上產生的營運資料,web server的log等等,對你而言就是第一手資料。

實務上最常看到的第一手資料,應該就是網頁存取日誌(web log)。在2016年網頁伺服器市場上,apache加上nginx仍然佔了半數以上,其他的網頁伺服器種類雖然也不罕見,但網頁的log格式反倒似乎都很統一,因此,以網頁存取來說,資料取得跟分析都已經存在既有的工具。剩下就看規模和個人技巧。

其他類型第一手資料就包山包海,以業務來說,發票檔案(invioce)當然是貨真價值的第一手資料。以軟體開發來說,git上所有的commit log也是第一手資料。

以現在軟硬體的成本之低,第一手資料原則上都可以盡量保持「原來的樣子」,頂多保存的時候壓縮而已,不太需要進行破壞性過濾處理。

要點一:使用shell 做基本的確認以及雜訊處理。


mac或linux可以用的基本文字處理的技術太多。伺服器的log最基本的處理方式,應該先用shell快速瞭解一下現況。

舉例來說:

以下指令可以把access.log中的第11欄,http response code列出來,並且簡單統計一下各return code的次數。


#cat access.log | awk '{print $11}' | sort | uniq -c
以上圖來說,結果就是有3個http return 400,有134個return 200,沒有任何500的回傳值。至於什麼是http return code,請參考w3規範

要點二:用excel做最基本統計檢視


過去許多excel版本都有筆數的限制(最多六萬五千多筆),2013之後就放寬很多(大約一百萬筆),請參考官方網站

即便有數量的上限,也非常值得資料中,先擷取樣本來試著分析。使用樞紐分析表,可以很快看到資料欄位彼此可能的關係,在未來進行分析時候是很有用的參考。

如果到現在你還不知道什麼是pivot-table(樞紐分析表),那表示你根本不懂excel。  怎麼使用樞紐分析,請參考官方網站的說明。下一篇,我們會用政府公開資料簡單做個樞紐分析表。


要點三:以自動化的方式產生濃縮的摘要(二手資料)


只要能取得第一手資料,盡量使用自動化方式,自動產生有意義的濃縮摘要,這個摘要就算是二手資料。

當然,這要配合要點一的shell文字處理,例如以下指令:


#cat access.log | grep "GET /login" | awk '{print $6}' | cut -d ":" -f 1 | sort | uniq -c

這可以產生簡要報告,說明登入(login)頁面每天有多少人次來使用,執行結果如下圖:

這圖上的執行結果顯示,9/12有15個人次,而9/13有2個人次。


現存二手資料的資料


所謂二手資料當然就是不是直接產生資料的來源的資料。資料分析採用二手資料的機會非常高。

所有組織外部取得的資料,絕大部分都算是二手資料。因此在下一節中會特別說明外部資料的取得處理。

要點一:取得過程的紀錄,以及基本分析


無論資料是自己拿或者這別人給,都需要紀錄取得的過程。

舉例來說,如果IT「自動」會給你一份,wifi的使用者登入時間,以及最後封包產生時間,你就需要有方式「自動」記錄這個過程。

如果是外部網站,也應該要記錄當時取得的方式,假設是curl取得,則用了哪些參數,執行多少時間等等。

基本分析則和前一節相同,先用shell和excel對資料有基本理解。

要點二:正確性判斷


二手資料很可能不正確,或者,對資料的解釋不正確,會大幅影響資料的使用方式。

資料解釋不正確:舉例來說,只要有用過就知道,政府公開資料很多都宣稱編碼是utf-8,但實際根本就是Big5(例如 房地產實價登陸)。

資料不正確:二手資料取得的資料本身判斷正不正確很困難,特別是在大規模的資料收集下,很難簡單判斷正確與否。而且有些資料的正確性,可能連第一手資料來源都不能保證(例如天氣觀測)

但是可以透過「多面向」的方式來探究單一資料的正確性。簡單的說就是多找幾種資料來交叉比對。舉例來說,如果你的天氣資料來自不同的網站,如下兩個圖:



雖然這兩個圖在同一個時間點的氣溫還是差了兩度,不過起碼是一個合理的範圍,因此大致還能知道資料是合理。

要點三:自動化進行轉換格式以及二次儲存


二手資料無論是什麼格式,幾乎都會被轉移格式,或者合併,或者改換儲存媒介。例如csv檔案,常常就被改為json格式並且存進nosql中。

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


外部取得資料