12/31/2016

企業巫醫 - 誰掌握你的升遷?



只有自己掌握了自己的命運。沒有別人。(註1)

升遷也不例外。只有自己掌握自己的升遷,沒有別人。

大部分無法獲得升遷的理由,都只是自己的藉口而已。常見藉口(註2)如下:

- 自己的努力沒被別人及主管看到
- 受到主管不公平的對待
- 主管不賞識甚至打壓
- 組織內制度有很多問題
- 負責的工作實在太艱難資源又少
- 負責的工作實在太簡單沒有挑戰性
- 景氣不好公司不賺錢就罷了,還在裁員
- 比我資深的還很多,很難輪到我


在大組織裡,個人升遷(promotion)仍然是職業生涯重要考量。因而,企業巫醫們的一些闡釋也頗有道理,例如這篇,或者這篇。但有些過於偏激,而且會舉一些憑自己想像的例子。這類型的巫醫頗多,在google上搜尋"升遷"就可以找到不少。


那麼,自己要如何掌握自己的升遷?


超乎期待:做出超越目前工作職掌的成績


升遷指的是企業組織認為你可以「增加」工作範圍或內容。而要讓企業組織,或者主管,要認定你可以承擔更大的工作範圍,最好的方式就是你「已經」做出超越目前工作職掌的成績。

超越工作職掌的方向有兩種,這兩種和雙因子理論/激勵保健理論(參考激勵保健理論)的概念相同。


方向一:保健因素


保健因素指的是,沒達成會有負面影響,但是有達成,且做得再好也不會是超越工作職掌的事情。換言之,有絕對的必要性,但是超過也沒有意義。

例如:

作為員工,準時參與會議,準時上班,按組織規定請假。
作為一個程式設計師,準時交付符合品質的程式碼。
作為客服人員,在時間內回復顧客問題。
作為專案主管,讓控制並管理團隊時程,沒有延誤

有些是屬於規定類型,有些是屬於職務範圍。這些都是歸類於保健因素。換言之「沒做到」是非常糟糕的!非但不用考慮升遷,甚至應該擔心被資遣。

要注意的是兩種對保健因素的誤解:


(a) 誤解一:消極應對


既然這並非升遷,或者有額外價值的項目,那麼也許我就做的勉強符合,60分就好。這樣的心態會讓這些的保健因素,很快的變成你自己的風險。保健因素的最佳處理方式是採用cynefin模型的「簡單因果」類型工作的處理方式。以最佳化,(或自動化)的方式處理。

消極應對,只會讓保健因素變得個人缺點,得不償失!


(b) 誤解二:這不是保健因素


在智慧型職業(例如程式設計師)最常出現的誤解是「這工作不是保健因素,我做到這件事情就是超乎期待」。

事實上,絕大部分的由上而下指派的任務,幾乎都屬於保健因素任務。

例如,你負責撰寫android app任務,根據自己的努力,確實在規範的時程內,以規範的品質上架完成。這「本來就是」你的任務。完成這件任務,的確是好事,但如果沒有做出超越任務的範圍,那就是預期內的職掌。既然是預期內的職掌,當然會取得預期內的「報酬」,例如薪水。自然也不會取得「額外」的報酬,例如鉅額加薪或升遷。

試想,你搭計程車,司機在合理的時間內,安全的把你載送到你要求的地點。你自然會付出正確的車資,不太可能付出「額外」的費用吧。



方向二:激勵因素


如果有做到,會讓人感到「很滿意」。

這個方向並不容易,但其實是「最能自己掌握自己升遷」的真正方式。

激勵因素根據工作內容而有所不同。以前述的搭乘計程車為例,如果計程車司機在車上「額外」提供一般計程車不會有的卡拉ok服務,並且未要求額外收費,在你開心的抵達要求的地點時,非常有可能自願的拿出額外報酬。

智慧型職業比較難找到激勵因素的方向。有幾個尋找方式可供參考:


(a) 參考方式一:擴增保健因素


這個方式比較基本。例如:一個app的程式設計師,被要求在6個月內完成app並上架,結果在5個月就完成,並且其品質也在要求的範圍內。對企業組織來說這個事件就算合理的「激勵因素」


(b) 參考方式二:額外的相關支援


類似計程車卡拉ok。例如:android app程式設計師,被要求在6個月內完成app上架。結果的確在時間內完成。並且,由於他採用react native,竟然也順便完成了iOS app。這就是額外的支援項目。


(c) 參考方式三:擴大 


主動執行擴大職掌範圍的任務。例如app程式設計師,其任務是開發app並上架,如果主動協助開發伺服器端,或其他功能模組,就算是擴大範圍。

更顯著的例子是:app程式設計師,其任務是開發app並上架,但主動組織團隊,做出新的實驗性質的計畫。那的確證實了擴大職掌和展示了領導潛力。




其他:


離開組織,以及自己建立組織-創業。 也是都是合理「自我升遷」的方式。

當然,離開組織之前,要先確定問題不在自己身上。如果問題出自自己身上 - 無論是能力或溝通問題 - 換到其他地方,也不可能解決問題,只是碰運氣而已。參考這篇,或者這篇,或者這篇

創業是自己造成升遷的最簡單方式。在那一夕之間,你就變成董事長兼CEO了。然而,能不能生存並獲利,又是另外一回事。創業需要另一方面的能力與知識。要成功並不容易,參考這裡,與這裡







註1:在某些地區,某些情況下,當然有不得已的時候。例如,如果你是生在阿富汗,伊拉克,索馬利亞等國家,確實很難掌握自己的命運。所以,本篇指的是一般在台灣的普通上班族。

註2:為什麼這些是藉口?請參考說明如下:

-- 自己的努力沒被別人及主管看到
-- 受到主管不公平的對待
-- 主管不賞識甚至打壓

(a) 短時間或許有可能自己的努力不被發現,甚至可能被瓢竊或者搶功勞。但長時間不可能!而且事實上,如果你真的能力極佳努力也夠,僅只是沒被看到而已?那你應該很容易可以找到更好,並且更容易看到你的能力和產出的地方!

(b) 爛主管的確有可能打壓好員工,但沒有人強迫你為某個主管工作,你當然可以離開。但是在離開之前,請先參考這本書(我愛白痴老闆)。也可以參考(得罪老闆怎麼辦


-- 組織內制度有很多問題

(a) 大企業制度上不可能完美,因為制度目的通常是為了企業生存。只要企業符合法律規範(在台灣是勞基法)就沒什麼好抱怨。並且,適應制度也是能力的一環。當然你也可以自創一個擁有好制度的組織。


-- 負責的工作實在太艱難資源又少

(a) 如果你覺得能力不足負擔這個工作,那不升遷的確是合理
(b) 如果工作真的太難,那應該自己去換個簡單的工作
(c) 所有企業組織的資源都是缺乏的,資源缺乏不是問題,只是現實

-- 負責的工作實在太簡單沒有挑戰性

(a) 如果你覺得工作太簡單,可能是因為主管覺得你無法負擔更重要的工作
(b) 也有可能對你來說工作太簡單,但是對主管來說你沒把簡單的工作做好,以致於無法給你有挑戰性的工作


-- 景氣不好公司不賺錢就罷了,還在裁員
-- 比我資深的還很多,很難輪到我

(a) 如果升遷是你最重要的考量,應該離開這類型的工作環境


12/28/2016

數據分析從零開始 - (4) 檔案儲存



數據分析的各階段,都有可能需要儲存檔案。而資料的來源,也有可能是已經存在某處的檔案。

(非檔案儲存?參考註1)

越重要的資料,就得更重視儲存的方式。而越是大量複雜的資料,就勢必要對資料存儲做好預先的規劃。

雲端儲存 - 巨量資料


近年來流行的Cloud Storage,通常是將資料以網路上傳(註2)至某個雲端服務公司。最典型的例子是Amazon提供的S3服務。AWS S3因為使用者眾,以至於其的S3 rest http介面,甚至演變成某種標準。許多類似的服務,或者儲存廠商,會以「相符S3 rest api標準」當作重要的功能或賣點!(註3)

顯而易見,雲端儲存具有管理上的優點。理論上,不用擔心備份,擴充,網路,電力,硬體更換...等等營運上的問題。

然而,巨量資料雲端儲存也有幾個顯而易見的缺點

1. 錢:雲端儲存的費用並不便宜。單以S3為例,2016年的每1T資料光是「存著」的費用,一年就高達276美金,相當於8832台幣。這還未計算上傳下載等操作費用。倘若要進行「長期保存」其費用相當驚人。也因此雲端儲存商針對長期保存的檔案也提供比較便宜的方案。然而,仍然是某種成本。然而,自行巨量儲存也要考慮費用,特別是

2. 營運:單純僅只使用雲端儲存,對整體營運的好處有限。並且,企業還是需要自行考慮檔案的有效使用問題。

3. 移轉:儲存到雲端之後,一旦量變大,很難轉換營運商。



雲端儲存 - 少量資料

至於極少量資料,例如10G之內。無論是企業或者是個人,都可以取得幾乎免費的儲存空間。

但也因為是免費空間,不太可能保證資料不會遺失。可是非常適用於新創公司,或者SOHO族。

最好是利用兩個以上的雲端儲存服務,儲存重要的檔案。

例如:利用googledrive + yandex.disk 儲存重要的檔案。這樣幾乎可以確保檔案不會因為單一基礎建設有問題,而導致重要檔案遺失。(註4)

實際作法:

(1) 尋找適當的工具或API,用以一次性整合這兩個雲端儲存

(2) 設定自動化方式,或者撰寫自動化程式

(3) 定時執行自動化備份,同時備份兩份到不同的雲端服務

Yandex disk的範例程式(參考這裡)



自行儲存 - 巨量資料


企業組織非常有可能需要自行處理檔案儲存。無論是因為技術因素或者法律因素。

傳統上儲存會用硬體商的解決方案,近年來多了分散式檔案系統可以考慮。

自行儲存,一樣要考慮錢(費用),營運。

1. 錢(費用)

    - 硬體費用:必須考慮長期硬體維護的費用
    - 軟體費用:授權或者購買維護
    - 人的費用:必須使用假設的最大值!

2. 營運

    - 如何讓其他系統使用
    - 有問題的時候怎麼辦
    - 備份與災難復原 


傳統巨量檔案資料,是購買netapp之類的硬體解決方案,配合網路架構,讓企業的巨量資料有集中管理的地方。2000年之後,分散式檔案系統因為效率和成本的關係,慢慢變成另一個可行的選項。

早期使用分散式檔案系統管理者,要跨越比較高的技術門檻,這幾年分散式檔案系統日漸成熟,管理也越趨方便。常見的有:(這頁wiki上有詳盡的清單。)

(1) glusterfs
(2) ceph
(3) HDFS
(4) mooseFs
(5) mogilefs
(6) GridFS
(7) Lustrefs


這些分散式檔案系統各具特色,大部分都可以無償取得使用權。然而,有些需要額外的知識或技能才有辦法長期維護。

因此,如果可預期的資料量,以及資料存取技術與成本,小於硬碟技術的成長。使用分散式檔案系統不見得有利。

硬碟的技術符合約略的摩爾定律。在1996年,每1G的硬碟約127美金,2006年,每1G的硬碟價格為0.3美金,但是在2016年,每1G的硬碟價格已經小於0.03美金。(參考這裡

除了價格逐年降低之外,存取速度也是逐年增長。如果預期資料成長量並不高,其實單就更換更換同價格的硬體設備搞不好也就夠了。

然而,巨量資料的增長往往遠超過預期,尤其近年來大資料分析蔚為風潮的情況下,盡可能保留資料便於未來使用成為企業組織對資訊科技的期待。也因此,使用分散式檔案儲存的組織越來越多。

選用分散式檔案系統,必須考慮:

(1) 使用目的和環境條件
(2) 營運計畫
(3) 實際測試


考慮雖然需要詳盡,但是這些「考慮」都是為了配合實際運作。因此,按照上述的考量,擬定可以「每日」有進展的「逐步」前進的計畫,是讓分散式系統成功運作的最好作法。

舉個例子:

(1) 使用目的和環境條件:要能夠簡單擴增(scale-out),並且能利用現有已經存在的NAS/SAN,而且非常容易營運與維護。檔案不需要striping,存取效能一般即可。

(2) 營運計劃摘要:一開始預計使用12台機器,共48顆硬碟。未來一年可能擴增到20台機器,80顆以上硬碟。總資料量可能成長為120TB。僅有一位開發維運人員(devops)。

(3)實際測試:實際分別以4台VM測試過glusterfs, mogilefs, ceph, Lustrefs。其中以mogilefs最為簡單使用。





自行儲存 - 少量資料


少量檔案的儲存,仍然附著在其他系統上。例如email上的附件,版本控制系統,wiki上的附件等等。

大部分的組織,很少著重於少量資料的整體計畫。大多數僅只為「安全性」的規範。例如客戶資料不得外洩之類。實務上,完全依賴個人行為。

現在,大部分的作業系統,都已經可以對其下的檔案做全文檢索(例如mac finder),而也都支援某種程度的備份功能。




摘要



巨量資料少量資料
雲端儲存 錢, 營運, 移轉考慮 
(1) 自動化
自行儲存(1) 傳統NAS 
(2)分散式檔案系統
考慮 
(1) 傳統備份 
(2) 全文檢索 





註1:非檔案儲存有傳統的RDB(例如Mysql, Oracle), Document DB(例如Lotus Notes), 有比較新潮的nosql (HDFS, mongodb, couchbase)。 這目前不在本文的討論範圍

註2:通常是指http。不過由於ftp在2000年之前應用範圍真的太廣,所以還是有不少雲端公司會額外提供ftp介面。

註3:參考這裡 -> http://www.s3-client.com/s3-compatible-storage-solutions.html

註4:為何選擇這兩者?google當然是不用說,因為它的基礎建設相當完整。而yandex則號稱為俄羅斯的google,很明顯由於是俄羅斯最大search engine,大概不會和google採用重複的基礎建設,因此選用兩個截然不同的廠商,可以降低風險。

12/22/2016

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



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

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

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


為什麼?


績效評估要及時


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

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

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

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

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

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

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

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

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

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



轉職衡量要完整


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

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

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

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



那麼,年末可以做什麼?


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



1. 不設定一年為單位


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

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

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

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

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



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


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

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

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

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



3. 不等候重要的事情


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

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

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





參考:

努力的三個迷思

工作上學不到東西

因沒挑戰想要換跑道

工作太忙沒時間?

職業生涯的突破

成長的最好方式:檢討


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

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

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



12/10/2016

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



這裡有幾本書...


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


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


(1) 個人經驗


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


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


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


(3) 個人品牌創業


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




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


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


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



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

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


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


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

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


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


(1)  4小時閱讀



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

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


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

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


(2) 停止接受資訊一天


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


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


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

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







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

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


12/05/2016

Scrum - 檢討完了...然後呢?




定時檢視目前的進度與問題,是所有專案管理都會做的事情。Scrum方法會在每個Sprint之後,舉行檢討會議(驗屍會議),找到在過去一段時間最需要改善的事項。


假設團隊依照正確的Scrum的事實認定原則,踏實的列出問題。接下來就應該「解決」它。誠如前篇,所有的問題必須要有歸屬「某人」。某些事情是「很多人」或者「不知道什麼人」,這種情況的歸屬就屬於Scrum Master。

稍微強調一下,只要Scrum Master稍微不注意,就會讓歸屬人這件事情變成互相指責,試圖鞭屍,對人不對事的謾罵。但是,如果不試圖歸屬某人,就常會讓問題懸空,無法真正解決。

只要確切的定義真正的問題,就等於是產生了一半的解決方法。

不過有些常見老問題,還是值得探索一下。

例如:

(1) PM/PO 常常在Sprint中間要求修改規格,甚至新增額外的項目...

(2) 某個人的產出和績效,明顯的比其他人差很多...

(3) 某個功能的實際時程遠超過預估,以至於某些團隊成員需要很大幅度的加班...



而常見問題都有其共通性,常見的試圖解決方法也有共通性。然而,以Scrum而言,Scrum Master在此扮演非常重要的角色,因為所有的問題,其有效解決方式,應該都和Scrum Master本身有關。


Scrum Master必須要掌握以下原則:

原則一:試圖做到完美是不可能


    完美的team不可能存在,每次sprint應該試圖解決最重要的幾個問題就好。

原則二:持續做同樣的事情,不可能產生一樣的結果


    參考愛因斯坦的名言:Insanity: doing the same thing over and over again and expecting different results.

原則三:任何創意方式都應該嘗試:包括「無作為」

    
    當定義好問題之後,下一個sprint應該要試圖改善問題。但是,改善問題的本身有時候需要「時間」,而由於Scrum每個sprint都只有4週,Scrum Master應該要將「無作為」當作某些問題的處理選項。畢竟,有時候過度反應某個未來可能不存在的問題,也沒太大意義。

但是也請謹慎區分「無作為」和「逃避」,這兩者只有一線之隔(註1)。
    



針對身為Scrum Master的人,在此提供一些解決問題的範例:

(1) 時間相關的問題


由於時間是軟體專案衡量進度的唯一單位。時間是最初,也是最後要考慮的事情。因此許多檢討事項都和「時間」有莫大關係。



--- 在Sprint中某些時間估計錯誤,導致加班 ---


這在專案前幾的sprint特別常發生。建議解決方式有:

(a) 探詢真正的需求點和重要的事情,移除根本不重要的工作事項

(b) 減低時間浪費,特別是大型專案中開會的時間

(c) 無作為:因為團隊已經了解問題,而且下個sprint估算也應該會比較正確,加班問題很可能自然消失。

(d) 厲行「最大時間」單位,假設是1天。換言之,工作項目超過1天,就需要分拆成不同的項目,或者不同的完成階段。這樣可以在比較短的時間內,很快發覺時間錯估的規模。


絕對不建議解決的方式是:讓某些人繼續加班;犧牲品質;謊報進度...



--- 某個人的事情老是做不完 ---


這個也很常發生。如果是該員能力無法趕上團隊。似乎是個很大的問題。然而,絕大部分的團隊都應該利用分工導致的比較利益法則(參考這篇),根據相對優勢來分工。

細節請參見下一節:(2)人才和人力的問題


建議解決方式有:

(a) 先確定他不是不想做。假設有個不想在這個團隊努力的人,無論再怎麼調整,也都沒有意義。應該用最快的方式讓他好好離開。

(b) 讓他做可以用時間苦勞換取績效的工作,而非需要能力才拿達成的工作 ,例如將其人力保留用於意外任務或者PM臨時修改需求 

(c) 找到他的相對優勢,換言之,Scrum Master要略為調整scrum的精神,改以指派的方式指定工作。但這點需要觀察並且徹底了解他的優勢才有辦法執行。


--- 團隊有意外任務 ---

這個問題也很常見,可能的解決方式有

(a) 無作為:經過一番思考,發現這只是意外,下個sprint應該不會發生

(b) 根據前sprint所耗在意外任務的時間,重新估計下個Sprint意外任務要花的時間

(c)  設定意外任務防火牆:可以找一個專門的人,處理所有意外任務。不得已的時候也可以找工讀生,委外人員等等。



(2) 人才與人力的問題


許多軟體開發的相關研究,都一再顯示,一個好的設計師和普通的程式設計師的績效相差很大。某些1980-1990之間的研究認為可能差距10倍,當然這個10倍厲害的程式設計師的爭論很多(註2)。但就一般的情況來說,超過5個人的團隊,就自然而言有人能力以及產出比較好,而有可能有某人能力和產出都比較差。

一個團隊裡,人力和人才必須要平衡,並且由Scrum Master在前幾個sprint的結果瞭解哪些是人力,哪些是人才。人力和人才的衡量標準在於「產出」而不在於「個人能力」。換言之,即便大家都認為他能力很好,但是某些原因,他的產出只有一般般,那麼他就不是人才,而是人力。

但是,無論是人才還是人力,團隊的組合的先決條件就是1+1>2,團隊合作可以讓整個團隊獲利。Scrum Master在發現團隊有某些人的績效和產出問題時,應該優先考慮分配工作上的比較利益法則。(台灣經濟學的入門書通常會用蓋木屋與磚屋的例子:參見這裡

要注意的是,過於追求表面上的公平,但是反而會團隊績效的降低。公平雖然重要,但是團隊合作產生的獲利更為重要。Scrum Master要能讓團隊追求團隊目標,而非追求個人公平。其方法有:

(a) 讓團隊成員看這篇文章

(b) 不要設定表面的績效衡量標準(例如:bug數量) 而是設定每個人不同的標準

(c) 所有不同的標準,朝向同一個目標。例如,在籃球比賽中,得分籃板助攻失誤阻攻...等等都是指標,而所有指標必須都要朝向球隊勝利才有意義。而不應該對每個球員設定同樣的目標。





(3) 目標的問題


目標指的是現在要做什麼,現在什麼事最重要,要達到什麼效果...簡單的說,每個專案都有其最終目標,但是在專案開發過程中,都有中間目標,PM/PO理論上應該會透過各類型中間的目標,達到(也有可能會修正)最後的目標。

然而,Scrum為了讓開發人員專注於工作,在一段短時間的Sprint是不允許修改目標。因此,如果遇到PM中間亂入,常常會造成團隊困擾。

但其實更為重要的是,如果團隊方向具有很大的不確定性,Scrum Master應該視其為「機會」,而非「威脅」。因為Scrum的天生優勢就是在於處理不確定性。


--- PM客戶或其他長官常常突然要求修改做的一半的規格---

(a) 無作為:因為這可能是專案開始的意外插曲,Scrum Master很確定下個sprint不會發生

(b) Scrum Master作為擋箭牌。在Sprint中間過程,用盡一切手腕,擋住所有需求修改,直到sprint結束為止。但是,允許PM重新開始一個sprint。

(c) 找個專門窗口作為擋箭牌。指定一個專門「被聯繫」的擋箭牌,將擋下需求,或者臨時修改需求這件事情是為他的工作項目。但是他所完成的程式碼,放在另一個branch(分支中),每個sprint結束之後,才檢討他的branch是否要合併。這個做法的依據在於,通常會修改的規格,都會被一改再改,與其影響團隊作業,不如將影響範圍降到最低。


--- Sprint產出PM不喜歡或不要了 那我們不是白做 ---


這樣的抱怨也很常見,它不是問題,而是Scrum天生所展示的優勢。Scrum Master只要解釋幾點Scrum基本概念即可:

(a) 我們頂多白做4個禮拜,如果是project結束才發現這件事情?那浪費的成本是高得嚇人。

(b) 如果是PM不喜歡,那麼起碼我們會了解什麼地方他不喜歡。如果他「不要了」表示這是PM在產品需求判斷上的錯誤,在檢討會議應該要求PM改善此項目。



如果有其他常見問題在這裡沒有獲得解答?也請用email與我們聯繫 support@talent-service.com。我們會持續修改這篇文章。





註1:許多事情好與壞都只有一抹微妙的界線。除了「無作為」和「逃避」之外,還有「足夠自信」vs 「自我感覺良好」;「自卑」vs「謙虛」...

註2:請參見這裡

註3:如果有其他常見問題在這裡沒有獲得解答?也請用email與我們聯繫 support@talent-service.com

12/02/2016

Scrum - 回顧。檢討?驗屍!



在Scrum方法中,每個Sprint結束要做事情是(1)實際交付產出 (2) 回顧檢討這個Sprint (3) 決定下個Sprint的開始。

其中,回顧檢討這個Sprint的做法,通常是一個2-4小時的Retrospective Meeting(回顧會議),再加上改善動作。


實務上,回顧檢討是sprint最難做得好的項目。


困難因素在於,人類有天生的認知謬誤。回顧檢討會議既然是人來召開,人來組成,當然很難確切找到此Sprint的需要改善的問題,並對症下藥。偏偏,絕大多數專案Sprint問題和人有關。

說得更直白的:

    - 所有專案團隊的主要關鍵問題,都跟人有絕對的關係。每個sprint檢討會議不去檢討「人」,就等於是兇殺案發生而不去驗屍一樣。

    - 所有未來改善項目,其改善效果和速度,也都和人有絕對關係。


Scrum基本作法


在大部分的Scrum教學材料中(註1),都很輕而易舉地說,團隊要在回顧檢討會議說,瞭解並討論三個項目:

(a) 這個sprint哪些地方團隊做得很好

(b) 這個sprint哪些地方團隊做得不好

(c) 下個sprint 團隊要做哪些事情使其變得更好



許多Scrum教學中,回顧會議都用一些簡單的方式:例如每個人提出3個意見,然後由Scrum Master逐一唸出,並且分類意見,接下來針對分過類型的意見投票,投完票之後再指定人選負責在下一個Sprint中改善。這個方式當然可以消除不少偏見和謬誤,但是容易忽略了「改善是需要針對人的行為而非針對事情」。


舉個某回顧會議中,團隊認為最需要改善的問題:

* 需求在sprint開始時還沒確定

這是個極為常見的sprint回顧問題,也通常是軟體團隊的困難。Scrum方法雖然試圖避免這個困難,但是還是非常容易在回顧會議中被提出來。筆者常看到會議記錄中,天真且單純的紀錄這一條問題....然後?也只是記錄而已。


這個紀錄有什麼問題?  ....有很大的問題!


大部分團隊,剛組成的時候,其Sprint檢討會議中,會不自由主的「避免」提出直接針對「某些人」的能力,做法,產出的問題。團隊會因為想要「努力團結」而避免針對人的討論。然而,除了超短期專案外,所有軟體專案,幾乎不可能「沒有人的問題」。反過來說,解決重要的人的問題,專案就會執行得更好。

回顧檢討要注重「人的問題」,並非單指某個人的能力不夠,也非某些人難以溝通。而是要透過實際的事物,探究人的行為造成的問題,而非問題的本身。「需求在sprint開始時還沒確定」是個血淋淋的事實。

但是,回顧檢討的重點在於,過去4周內,到底團隊成員知道是「誰做了什麼,或者沒做了什麼造成這個事實」,這才是重點。

正確的回顧檢討事實,可以是:


* 需求在sprint開始時還沒確定,因為Scrum Master沒有邀請Product Owner參加kick-off會議。

也可以是:

*  需求在sprint開始時還沒確定,因為Product Owner在kick-off會議沒講清楚,而團隊當時卻認為自己清楚需求,直到開始做了才發現不清楚,偏偏Product Owner之後就不參加每日例行會議。

也可以是:

*  需求在sprint開始時還沒確定,因為Product Owner在專案中間需求有改變,但是Scrum Master並未注意到大幅變更。


無論哪種回顧,都需要有「人」,「當時做的事情或這沒做的事情」,「產生的結果或沒產生的結果」。這樣的回顧檢討才會有意義。


但是,Scrum的方法論,看起來都是對事不對人。要如何在不交互指責的憤怒會議中,做到針對人的檢討,並能在下個Sprint還能持續團結合作?

如果你是專案經理或者Scrum Master,有三個基本的關鍵作法可供參考。(1) 先個人,再團隊。只內部,無外部。(2)  沒有問題,是最可怕的問題 。(3)實際事實,實際行為優先。



(1) 先個人,再團隊。只內部,無外部。


在會議開始之前幾天,先通知大家,回顧檢討會議的重點:先檢討自己,再檢討團隊,只檢討團隊內,不檢討團隊外。


(a) 先檢討自己的「行為」,再檢討團隊的「行為」。


並非要檢討個人的價值觀。例如,是不是很認真,很願意和其他人溝通...等等。而是自己先看自己過去做的「行為事實」,有什麼可以改善的地方。

例如:完成某功能程式碼之後,沒有先執行整合測試,就在某天每日會議報告已經完成,隔天發現,該功能有很多問題,還得修正進度,並且讓測試人員額外進行rollback。

另一個例子:這次sprint開始的時候,Scrum Master沒有堅持要Product Owner確定所有要完成的項目的需求,就讓Sprint展開。使得Sprint需要額外需求確認時間。

檢討團隊的行為,也和個人一樣。稍微不一樣的是,團隊行為通常是「個人行為」的組合。換言之,以「沒有人」為開頭的陳述就是團隊行為。Scrum Master或者專案經理,或者實際決定事情的主管,要特別注意,絕大部分的「沒有人」開頭的陳述,就要當作「自己」!

例如:沒有人發現在第二週自動測試的伺服器當機,連續好幾天的測試報告都沒有自動email出來,以至於團隊錯失及早修復bug的時間。

另一個例:沒有人提醒Product Owner開會的時間。



(b) 只檢討團隊內,不檢討團隊外


Scrum對於團隊有很嚴格的定義:做事情的人+Scrum Master = 團隊成員。

回顧檢討會議,必須要檢討內部,而不是檢討外部。許多檢討會議看似檢討內部,但其實是在檢討外部。

例如:加強和UX/UI部門溝通

這通常隱含對方不好溝通,我們只好努力跟他溝通。

又例如:公司有臨時交辦事項,團隊得分心處理

這隱含是更高階主管來的非專案任務,需要打斷專案時間。

這兩個例子並非不要改善。而是檢討回顧方式,會大幅「限制」或影響改善方式。與其他部門溝通問題,應該是具體列出過去4週,那些確切事情「被誤解」或者「理解錯誤」。根據實際的錯誤,來改變團隊對應的方法。

以UX/UI而言,釐清理解錯誤,可以用「雙方討論事情的時候,一定要至少要有mock-up」。

而以公司有臨時交辦事項為例。應該是「每個sprint預設的工作時間原本是160小時,下個sprint改為145小時,因為上個sprint臨時交辦非專案任務大約15小時」。這樣是以具體的事實,解決公司有臨時交辦事情的問題。

重點是:解決問題必須在「團隊內部能做的行為」,而非「希望團隊外去做的事情」。

會不會有回顧檢討的問題是「團隊內部解決不了」的事情?的確有可能,但是機率很低。團隊解決不了的事情,早就在sprint kick-off (開始會議)被隱含排除,所有團隊「認知到」的專案問題,幾乎都是團隊內部有方式解決或減少影響的。




(2) 沒有問題,是最可怕的問題。


有為數不少的專案團隊,在回顧檢討會議時,因為很多因素,無話可說。只好拿一些雞毛蒜皮的小事,或者看似重要但是不太重要的事情敷衍一下。

例如:

* 每週固定的下午茶太不健康,看能不能換健康一點的。
* 我們的螢幕太小,寫code很不方便。
* 每天站著會議好累,可不可以坐著
* 能不能有免費可樂
* 昨天code view有說code style要統一但是還沒有
* 我們可以固定一段時間來分享一下大家coding的心得

如果檢討會議的重要事項,全都是這類型的,那有三種可能(註3):

(A) 團隊有如NBA夢幻一隊素質極高,工作合作超級愉快,成果驚人。

(B) 團隊失去對專案的信心和動力,或根本不相信Scrum Master。

(C) 團隊絕大部分的成員經歷太淺,不知如何開始檢討。



--- (A) ---

如果你認為你現在的團隊是A,大概有49.99%的機會你是在欺騙別人。另外有49.99%的機會是你自己騙自己,或被別人騙。


--- (B) ---

如果你認為你所處的團隊是B,而你恰好是Scrum Master,或者是專案經理,或者任何領導階層。那你最最需要做的事情是「檢討改善自己」,而非「檢討改善別人」。一個團隊,大部分的人不願意說真話,最有可能有問題的一定是管理階層。

如果你認為你所處的團隊是B,而你非管理階層,也非Scrum Master。你可以先審視自己專案對社會的重要性。如果你是在核電廠,或者急診室,那你應該盡自己一切的可能,不計代價,不眠不休地改善現況。

然而,如果只是一般的軟體專案,建議你先就自己可以改善的地方檢討自己。確定當你看到不正確的事情時,會先審視自己的能力與做法。但也不需要強出頭,把自己當作革命烈士。畢竟,大部分的軟體專案並不是那麼重要。


--- (C) ---

這種情況似乎也常發生,但是解決方法很簡單。

首先Scrum Master應該在第一時間對於「雞毛蒜皮小事」,做立刻回應。對於每個小事的回應都是:下次不用等到sprint結束,中間任何時候都可以馬上找我講。這樣才會讓團隊成員養成自動自發,並容易判斷哪些事情很不重要。

如:

* 每週固定的下午茶太不健康,看能不能換健康一點的

...可以,馬上就換。以後一遇到這種問題,不用等到sprint結束,任何時候馬上跟我說或者寫信給我。

* 每天站著會議好累,可不可以坐著

...不行,因為站立會議的目的就是要讓你累。以後想到這類型問題,不用等到sprint結束,任何時候馬上跟我反應。

* 能不能有免費可樂

...可以,你馬上去買,發票給我。以後一遇到這種問題,不用等到sprint結束,任何時候馬上跟我說或者寫信給我。


* 我們可以固定一段時間來分享一下大家coding的心得

...可以,你馬上去發固定會議通知時間。以後一遇到技術分享的事情,只要不影響sprint時間,任何時候就直接去做,不用等到sprint結束。



(3) 實際事實,實際行為優先



Scrum的精神在實況與事實,而檢討的實況和事實在於「行為」而不在於「想法」或者「內心深處的感覺」或者「價值觀」。

這個概念非常重要。缺乏了這個概念,就容易讓檢討回顧會議,變成「互相責怪」會議。

然而,執行也很重要,執行不當,也會讓回顧檢討會議變成「互相責怪」會議。

首先會議一開始Scrum Master一定要強調,接下來的會議以事實優先,而事實當然是根據某人做的事情。在團隊成員互相不熟悉的情況下,要「反覆」的重述事實優先。並且在討論時,嚴守只看事實的承諾。

會議的形式此時就不太重要,不過:點名發表意見是個簡單的好方法。當然Scrum Master應該要自我拋磚引玉一下。

以下舉幾個常見例子:

成員J說:PM常常來叫我們改東改西,為什麼之前不確定好需求

這時候Scrum Master應該列出這個sprint完成的task。追尋到底哪些task的需求被改變,大約影響了多少工作小時。
當然成員可能會說他不記得,就請他大致猜測一下。然後再跟sprint的時間做比對。如果改動所花時間很少,那其實不是問題。如果改動時間比率很高,才是值得關注的問題。值不值得處理,要看比率原則。-- (註4)


成員A說:我覺得我的task太多,都做不完。


這時候Scrum Master應該立刻請成員A把過去一個sprint做完的Task列出,看看是不是有做完,並且完成這些task是否有加班,或者,其實他的task是由別人完成,但是每日站立會議中並沒有說明?總之,現場應該了解事實,而事實也一定能被了解,不能等到「之後」。因為每個Sprint只檢討這個sprint,也就是過去4周左右,不可能需要很長的時間了解事實,也不可能有「我現在忘了要回去找一下」



成員K說:負責前端的人的bug太多,有時候負責後端的人都得幫忙修復bug。


這時候,Scrum Master應該立即根據bug清單,看看前端的bug數量,和負責解決bug的人。假設前端bug數量在過去sprint中有100個,而99個bug是由前端的人解決,有1個是後端的人幫忙解決,而且也只花了1小時。那麼這個問題根本不成立。只是因為後端開發伺服器的人,會特別記得「例外事件」就會有別人bug多太多害我多花時間的印象。這事情比例上多寡,是不是值得處理就要看「實際情況」列出判斷。一旦列出來給團隊成員看,就很容易大家一起判斷。


成員F:我coding速度是沒很快,但是有些速度更慢的人,就完成比較少的task,好像不太公平。


這時候Scrum Master應該根據git或其他版本控制系統,列出團隊成員程式碼數量。配合完成的task數量,bug產生數量(表示code品質不好) 以及bug解決數量(表示解決的問題)大約比對一下,看看團隊的產出是否「差不多」。當然,不同的作業系統,不同的平台,不同的程式語言是不能這樣比較。

不過大部分的情況下,這個問題並不會被提出來。但是,這個問題會存在在壓力比較大的團隊成員中,並且有礙於團隊成長。因此,Scrum Master自己必須要有客觀的衡量產出的方式!即便沒有人提出這個問題。


成員L:我們對所使用的open source工具不太了解,導致於需要學習的時間。

由於這個問題很具體,Scrum Master只需要確定這件事情是否還存在。下個sprint還會不會有不熟悉的工具需要使用。



後續?

 Retrospective檢討回顧會議中,如果找到重要的事項應該要改善。當然就是Scrum Master或者管理階層需要去「執行改善」的時候。前述內容都只有「找到問題」而關於如何有創意的解決問題,還請參閱後續文章。






註1:網路上參考資料非常多,例如:這裡這裡 或者 這裡

註2:專案驗屍(postmortem)在許多人心中另有其定義,可以參考這裡,或這裡

註3:就只有這三種而已啊?確實有可能有別種,但是不太需要討論。例如:在某些軟體專案團隊的前幾個sprint,因為「蜜月期效應」的確真沒有大問題。也有很多軟體專案,本身的目標比較特殊:例如學校的畢業專案,或者政府國科會案,雖然要交付結果,但結果的本身根本不重要,當然也不有大問題。也有某些專案,並不適合採用單純的Scrum,所以無法使用檢討會議針對人進行檢討。

註4:Sprint的中途按照Scrum的精神本來就不能由PM/Owner隨意修改需求規格。但是,在這裡是Sprint的結束。如果Sprint中途真的發生臨時修改的事情,Sprint的結束當然要作為「事實」加以檢討。要注意的是,目的是檢討事實,而不是簡簡單單的說PM/Owner沒遵守「Scrum的規定」。Agile的精神中,團隊的溝通跟改善,遠比「規定」來的重要。由於軟體專案太常出現這類問題,所以後續文章也會有針對這種問題的建議解決方式。