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

9/02/2019

Scrum的缺點 (成為主管的31堂課)



當手上有榔頭,看到任何東西都像釘子 -- Abraham Maslow 1966
------

過去數年來Scrum明顯成為Agile軟體開發裡最常被討論跟使用的方法。

當然也有不少文章討論scrum的缺點(請參考這裡)。然而,Scrum是個在agile development範疇內的方法論,它是個很好的參考軟體開發流程的工具,而這工具有其「特性」,無所謂好與壞,當然就無所謂優點與缺點。

然而,這些特性不可否認,需要對該工具有一定的認知,特別是一些「預設要知道的事情」,以免誤用。舉例來說,當你使用榔頭的時候,大概會知道它是用來釘釘子,而不是拿來釘螺絲。此外,你也會大概猜到,右手拿榔頭左手扶著釘子時,要記得不要敲到自己的手指。

以下Scrum缺點(特性),也是常見的陷阱僅供參考。


(1) 團隊成員對Scrum的了解必須一致,工作能力最好也要差不多。


Scrum的運作中,高度依賴成員的自主性。Scrum Master雖然很重要,但僅在於Scrum本身的運作。對於任務完成的定義以及任務的品質,還是靠所有成員的能力。

換言之,如果有人技術能力特別糟糕,或者技術能力雖好,但對於Scrum的運用與瞭解和大家都不一樣,那麼有可能會有意想不到的長時間磨合期。


(2) Scrum並不會真正加快速度,只是讓速度透明,讓大家專注重要的事情。

許多企業導入scrum的目的是為了加速產出。事實上,Scrum並不會加快「某件事情的速度」。Scrum會讓事情變得透明,同時也讓團隊進行的速度變透明,讓大家更容易專注於正確的事情上。

整體來說,Scrum會減少各種不必要的浪費,讓整個專案效率提升,但就個別事情的速度而言,Scrum並不會提升。換言之,軟體工程師仍然需要有自己的方式來提升個人效率。


(3) Scrum並不會解決工作內容的相依性 


傳統的專案管理方法論,常常會提供類似甘特圖的工具。然而,Scrum方法論專注於某件任務(story)的完成,而隱含著希望每個任務的相依性,會在團隊成員的「成熟考慮」下被處理完成。

換言之,有相依性的工作就是有相依性的工作,軟體開發團隊還是必須要有自己的方式解決相依性。使用scrum並不表示相依性消失,也並不表示當有個寫得很獨立的story產出時,就一定會跟其他工作無關。這些都還是得靠團隊來處理。無論是使用Jira還是agilefant還是任何工具,都應該有自己的處理相依性的方式。


10/14/2018

企業巫醫:20分鐘搞定「工作做不完」的問題?



上班族常會遇到的老問題是:「工作做不完怎麼辦」

工作做不完是個老問題,解決問題的方法也很簡單,然而簡單事情不見得容易做。更重要的事情是:你需要正確的檢視現況,才能真正解決問題。因為每個人的「工作做不完」的實際情況都不同。舉例來說,假設你是在無良的黑心老闆血汗工廠,那麼你的工作做不完的解決方式應該是儘早辭職,而非增加效率。

以下步驟確保可以幫助你解決這個問題:


步驟一:暫停!休息5分鐘! 利用15分鐘進行計畫



1. 休息5分鐘


除非你的工作是急診室或者核電廠這類人命關天的地方,一般的上班族,一旦遇到工作做不完,慌慌亂亂急急忙忙的時候,其實第一件事情應該先放空自己。找個安靜的地方(萬一真找不到可以藉故離開辦公室幾分鐘),先盡量將自己的思緒清空,沒辦法放空冥想的話,打個手遊也可以。當你的思緒紊亂,壓力暴增,往往會使用直覺處理事情,使用直覺處理並沒有錯,但如果「只靠」直覺處理,就會失去成長和學習的機會,更糟的是,直覺處理事情通常和情緒結合在一起,關於這點請參考腦的結構杏仁核

所以讓自己休息五分鐘!


2. 計畫15分鐘


休息之後,拿出紙筆,先對現況做計畫。
列出事情的四個象限:重要/緊急矩陣(參考這裡) 。
如果你已經熟知這個事物分類方式,那就可以直接挑過這段,並思考自己為什麼不做這件事?

 2.1 重要且緊急:

 就是要專注處理的部份

 2.2 不重要但是緊急:

 要犧牲,或者交給別人,或者是忙碌狀況。但通常這種事情都是工作做不完的主要來源。最好的方式是縮小事情的影響。常見不重要但緊急的事情,不外乎老闆索取各種資料,感覺很急,

 2.3 不重要且不緊急:
  千萬不要去做它!普通上班族通常不小心會落入去做不重要且不緊急的事情,而且還不自知。最常遇到的事情是:對小事情花時間做無謂的討論。

 2.4 重要但是不緊急:

  千萬不要忽略他!忽略這裡,就無法徹底解決工作做不完的問題!



步驟二:按照計劃:逐一解決重要緊急的事


在計畫中,條列的重要與緊急的事情,要「逐一」處理。先不要想要同時處理,做個清單,搞定一個事情打個勾。

這聽起來簡單做起來很難。

有幾個簡單的執行要點可供參考:

(a) 自己找到專注工作的場地。很多工作其實不限定工作場合,只要你事先跟老闆講好,其實是可以嘗試找不會被打擾的地方好好專心把事情搞定。例如,在主管同意之下,中午三小時在公司附近某咖啡廳寫程式。在近年來開放式空間流行的狀況下,這點相對重要!

(b) 不要隨時檢查email與短訊。除非你的工作是急診室醫生或者某些人命關天的意外處理者,否則不應該時時檢查聯絡工具,你應該是控制工具的人,而非被工具控制的人

(c) 設定解決的定義。緊急而重要的事情的「回應」不代表解決。解決事情要像是恐怖片裡的殭屍,當你沒有徹底將它打爆頭,它很有可能會再爬起來咬你一口。


步驟三:重新檢討計畫,找到提高效率的方式,專注於重要但不緊急的事情規劃和執行


為什麼要專注於重要但不緊急的事?因為重要的事情如果都先處理好,可以大幅改善「未來還會有工作做不完的問題」 而且同時減少重要且緊急的事情發生。畢竟很多重要緊急的事情,就是當初重要但不緊急的事情一路拖延導致後來變緊急。

因此,這步驟用以確保可以有計劃地執行「重要但不緊急」

有幾個方式可以確保自己不遺漏「重要但不緊急」的事情

(a) 隨時檢查中期目標:組織通常有偉大的長期目標(例如登陸火星),但也由於通常太偉大,所以必須要逐步以中期目標達成。個人應該將中期(3~18個月)目標當作為重要的事情,而非最近短期目標。因為,短期事物常常會被迫打斷修改,就會容易淪落於被時間追趕而非控制時間。

(b) 每天排定固定時間處理「重要但不緊急」 即便是1小時,長期下來也會有效果。萬一不得已要加班,應該要加班處理的並非緊急的事,而是重要的事!

(c) 其他 (有空再說明此處)




步驟四:按照計劃,完成重要的事 ,並執行提高效率的方式


倘若已經執行到此。就可以考慮提高效率的方式。
其中最重要的方式就是「提高本身知識與能力」

提高工作效率有很多種方式,請參考這裡,或者這裡


步驟五:檢討成效,修改計畫


每個計畫都應該確實被檢討,自我檢討當然很好,不過,秘訣是請你認為做得比你更好的人幫你檢討計畫。

倘若這篇文章有某件100%保證有用的方式,那麼「請一個你認為比你厲害的人幫你檢討你的計畫和成效」是最最有用的一點。

4/20/2017

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


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

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

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

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

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

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

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

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

實際上做的步驟如下:

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


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


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

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

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

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



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


3. 了解測試資料內容


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

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

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


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


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

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


5. 結果


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

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

3/07/2017

畢業前六個月 - 建構職業生涯



在台灣的碩士生,畢業前六個月通常忙於論文。如果不考慮繼續就讀博士,畢業前六個月其實是建構職業生涯的最佳機會。

更確切的說:畢業前六個月是讓你日後容易取得理想工作的最佳準備期間!

為什麼需要強調在6個月前建構職涯規劃?

環境上有許多現實的情況,例如,大部分好工作機會,其主管都傾向雇用有經驗的程式設計師。然而,絕大部分剛畢業學生並沒有實際軟體開發經驗。

因此,剛畢業的學生如果剛好獲得一個適合自己,能夠成長,能夠有所貢獻的工作,那麼就會進入良性循環。這個工作會讓這個學生更容易找到下一個好工作,或者即便不換工作,也能在目前的組織中成長。


反之,剛畢業的學生如果找到一個不適合自己,到處瞎忙,只是以時間換取薪資的工作,那麼就進入惡性循環。這個工作會讓該學生不容易找到比較好的工作,即便勉強換工作,也得靠運氣。

如果不想靠運氣,也沒有富爸爸,也不想自行創業(註1),則要做的事情很簡單:

(1) 考慮現況
(2) 設定短中期目標
(3) 建立事實


考慮現況


首先,最重要的是,取得一些關於自己的事實。是不是想要做關於軟體開發相關工作?想要做哪一類型的相關工作?是否知道自己還缺乏哪些能力?哪些地方的工作,可在短時間有巨幅成長?

如果想要當個程式設計師,要考慮的現況:

1. 能使用哪些程式語言:是真的會,而不是只寫過hello world和學校作業。並且有「事實」可以佐證。例如在github上的project,或者工讀經驗。

2. 能掌握資訊技術工具:是真的能掌握,而不是用過一兩次或者學校作業。並且有「事實」可以佐證。例如:工讀經驗,利用資訊工具做的個人專案等等。

3. 能掌握團隊專案合作方式:例如是否有Scrum相關證照(註2)。

4.....<其他還有很多請自行想像>

如果想要從事資訊業,但是一開始就做SA/PM類型的工作,在軟體開發職涯裡其實不太腳踏實地,不過,真不得已可以參考這篇:資訊科技學生畢業後只想當SA/PM (三個創意作法)



設定短中期目標


某些職涯教練,或許會建議新鮮人設定長期目標。甚且透過各種神奇的方式推展或瞭解自己的熱情(passion)所在:例如希望自己五年之後賺10億之類的。

大部分的長期目標雖然有趣,但是用處不大。設定可預計的中短期目標更為重要。

以6-12個月為期,讓自己在畢業前達某些技術性和非技術性目標,對未來職業生涯非常有幫助。以未來想要當程式設計師的學生為例,在畢業前六個月可以訂立以下目標:

* 開發並且將一個Android APP放在googlestore上:熟悉在android平台上開發APP,因此需要熟悉Java。

* 取得Scrum Master證照

* 閱讀3-4本關於軟體QA的書籍,並且運用在現在的專案上。(含建構測試案例,執行測試,系統化記錄錯誤,...)

訂立目標必須要是

(1) 有非常清楚的結果。如果目標是「熟悉java」,則最後有沒有達到此目標是非常模糊的,但是目標是開發android APP並且上架,就表示必須要寫java到某個程度才行(註3)。

(2) 可以在6個月之內達到。不要設定一個花10年才會達到的目標。如果真的有長期目標,當然可以設定長期目標,但是需要伴隨可以逐步前進的短期目標。例如,或許你想要成為java大師中的大師,這可能要花上數年,但必定可以有個6個月能達到的前期階段,例如:「不靠任何補習方式,就取得SCJP」

(3) 其結果會伴隨建立事實。請參考下一段


建立事實

在畢業前六個月,是最適合建立「事實」的時候。

建立事實,和畢業前花時間美化履歷表有很大的不同。

美化履歷表,是可以靠一兩個禮拜,找一些專業人士協助就可以很輕易的達到。但如果自己的「事實」不夠充分,再怎麼美化也沒有意義。

前一段關於短中期目標,只要你的短中期目標定義夠清晰。這些就是你要建立的事實。

如果你是在未來6個月即將畢業的學生,對自己的技術能力非常沒有自信,然而又想從事軟體工程師的工作,可以考慮建立以下三個事實:


* 透過自己決定的開發專案(例如Android APP),徹底實踐品質管理(QA) 

     (a) 找一個不用錢的QT工具:可以參考這裡
     (b) 在開發專案的過程中,徹底運用此工具,確保自己的專案品質。
     (c) 將結果詳盡記錄,就成為自己能當QA的事實


* 透過自己決定的開發專案(例如Android APP),徹底理解並且妥善運用git(或任何版本控制工具)

      (a) 版本控制是軟體專案的基礎中的基礎
      (b) 需要徹底了解如何branch,如何merge,如何處理conflict
      (c) 其結果構成了解專案開發的基礎事實

取得Scrum Master證照

     (a) 參考這裡
     (b) 雖然大部分的管理類型的證照意義都不大,但是取得成本不高的情況下,展現了你至少是瞭解Scrum。






註1: 想要自行創業的準備不太一樣,首先要了解創業如何必然成功,再參考其他相關資料

註2: 花大錢考管理類型證照其實不划算,但是可以考慮花小錢,請參考這裡

註3: 對,我們知道React Native可以讓你不需要寫java,但是這裡只是舉例而已。


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周來的快太多。其原因也很簡單,重構是繁瑣麻煩的事情,當然會被估計成很長的時間。





1/11/2017

企業巫醫 - 統計與謠言



In god we trust all others bring data 

  -  W. Edwards Deming (全面品質管理TQM之父)


網路讓資訊傳播成本降到極端的低,同時也讓資訊品質降的極端的低。

謠言的成因有非常多。有些僅只是美麗的誤會,例如:十幾年前開始流傳的泰戈爾的詩。有些則是恐嚇類型的無風起浪,例如:誠品可怕迷魂盜泰國罐頭。有些只是試圖吸引人目光的搞笑惡作劇,例如:裝翅膀飛起來

最糟糕的類型,莫過於以「統計數字」造出看似符合邏輯的謠言。並且,從這樣的謠言中獲得利益。


許多時候,數據本身難以查詢正確性。而且由數字導引出的邏輯,更容易因人而異,因地制宜。從數字所引導的偏誤,有時候甚至比單純的謠言還可怕,因為它可能會在網路上留存多年,難以辯證。如果只是單純搞笑也就罷了,如果個人或者組織,以這類型的資料來作為決策的判斷依據,那下場可能非常慘。錯誤的資料,比沒有資料更糟。


不過,只要稍微留意,加上合理的好奇心,統計謠言是有機會判斷其可能性:


(1) 不解釋的數字


在各類文章或研究報告中,為求精簡,只會根據重要數字做衍生推論。然而,數字背後通常還有「未解釋」的數字,而這個數字可能更為重要。

企業僅21%的需要大學以上學歷為例。這篇文章,簡單說明勞動部的調查,僅有21%的企業需要大學以上的學歷。然而,這個數字有很大的問題。

也許,該調查隨機抽了100個企業主,其中只有21個企業主宣稱需要大學以上學歷的員工。

也許,該調查抽樣了企業主的「100個正在招募工作職缺總數」,這100個職缺中,只有21個是需要大學學歷。

這兩者有極大的差距。前者,可能這21個企業主,所需要員工數量高達2萬人,而另外79個企業主,所需員工只要79個人也說不定。而後者,正在招募的職缺,和「已經在職」的學歷也並未顯示。而單就此推論,僅21%企業需要大學學歷基本上過於簡化。

所有經過簡化,而沒有附上數據的真實來源的推測,其解釋很容易被扭曲。然而,被扭曲的解釋,當然比較有戲劇性,比較容易被注意。

勞動部網站根本也找不到這份調查。

此外,很多政治性民調也是屬於此類,涵蓋許多不解釋的數字。



(2) 接近完美的不可能


網路上流傳一份超過十幾年的Dr Ephrem Cheng研究顯示,越早退休壽命越長。(參考這裡這裡這裡)  

這份數據流傳非常之廣,被引用次數非常多,每隔數年也會在通訊軟體上流來流去。最近當然就是LINE上流傳的長輩文。

上面提供了一份數字,是退休年齡跟「壽命」的對照表如下。


retirelife
49.986
51.285.3
52.584.6
53.883.9
55.183.2
56.482.5
57.281.4
58.380
59.278.5
60.176.8
6174.5
62.171.8
63.169.3
64.167.9
65.266.8

不會統計的人也可以看出,在這個表中,越早退休,壽命越長。如果49.9歲就退休,那麼可以活到86歲。65.2歲才退休,就只能活到66.8歲。

以相關係數簡單計算,他的相關程度高達-0.96,換言之,這是一份極為完美的負相關數字。

這種過度完美個數字,應該要看研究論文的細節加以瞭解。例如他的樣本有多大?是什麼時候做的研究。就可取得的事實來看,他的樣本很小,並且研究的時間幾乎可以肯定在1990年以前。由於上述的年紀追蹤到80歲,所以研究對象大概是1930-1950嬰兒潮時代的人。

最重要的是,這些數字並非真實研究論文,卻在很多人的轉貼中,莫名其妙的被冠名「美國權威學者」。


這份研究數字會流傳很久的原因,是他剛好契合 (1) 這看起來是個學術研究 (2) 可以被直銷,財務規劃,人生規劃等等產業拿來利用 (3) 可以有趣的解釋它

除此之外,別無他因。雖然已經有些人發現不對勁,例如這裡。但是許多第一次看到此研究的人,仍然不明究理的轉貼。

如果想知道實際的退休年齡和生存年齡的相關性研究:請參考這篇研究。該篇的結論就交由各位判斷,但至少它的研究方式,數字細節,都解釋得十分清晰。

我已經透過管道寫信給該研究者Dr Cheng,懇請取得確實的研究資料以及統計方式等細節(說不定他也是受害者?)。至今2017/Jan/11尚未收到回覆。


(3) 邏輯上的不可能


邏輯上不可能,或者簡單的說「數字兜不攏」。

中國的2010的地方GDP就是邏輯上的懷疑問題。因為 中國31個省份的GDP加總起來,竟然遠超過全國GDP,而且高過很多。這在邏輯上是不可能的事情,因此自然就有合理的統計造假懷疑。

類似的事情也容易發生在沒檢查,而且其實也不打算認真做統計的相關文章上,例如這裡。因為在許多時候,謠言只是想要造成吸引人的目的,其真實性不重要,當然就也不特別檢查數據。所以自己造成自己數據兜不攏,邏輯上不可能的情況並不少見。

這和前兩者不同,邏輯上的不可能,可以單就資訊本身的內容加以探索,或者是再加上一些事實根據來檢視。因此,比較容易看出謠言的真實性。




最後,稍微提醒一下:廣告的統計宣稱,其實難以查證。例如高露潔的「大部分牙醫師推薦」如果不是公平會主動進行查證,一般市井小民根本無法查證屬實與否。





12/31/2016

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



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

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

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

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


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


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


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


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

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


方向一:保健因素


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

例如:

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

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

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


(a) 誤解一:消極應對


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

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


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


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

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

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

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



方向二:激勵因素


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

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

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

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


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


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


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


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


(c) 參考方式三:擴大 


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

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




其他:


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

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

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







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

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

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

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

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


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

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


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

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

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

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


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

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


12/22/2016

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



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

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

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


為什麼?


績效評估要及時


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

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

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

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

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

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

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

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

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

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



轉職衡量要完整


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

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

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

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



那麼,年末可以做什麼?


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



1. 不設定一年為單位


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

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

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

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

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



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


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

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

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

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



3. 不等候重要的事情


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

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

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





參考:

努力的三個迷思

工作上學不到東西

因沒挑戰想要換跑道

工作太忙沒時間?

職業生涯的突破

成長的最好方式:檢討


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

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

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



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

11/16/2016

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



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

--- 淮南子說林訓



誠如上篇,雖然說Scrum的方式與工具十分簡單,能務實並且彈性運用比照著字面嚴守方式來的重要。 

「形式主義者」嚴格遵守字面的意義,而非真實的意義,已經是很嚴重的錯誤。

但更糟糕的是「極端基本教義派」將學習到的Scrum技巧,視為不可侵犯的條款,凡是侵犯了條款視為大逆不道,非除之不可。 

Scrum是專案任務執行的技術與方法,它符合agile的精神 (註1),並且延伸出一套可供參考的作法。這套執行的技術概念中,定義了角色,專案進行的基本流程,進度控制方式。

 而最最最重要的Scrum重點(註2)應該是: 

1. 一段時間之後(sprint)會交付可被驗證,可使用的產品 。

2. 每段時間的產出,都是市場在當時最最最需要的 。

3. 這段時間之後,整個流程會被檢討改進。

無法掌握到以上最基本的三點,任何字面上的意義都沒有用。而Scrum基本流程都是為了掌控以上三點。 做的到這三點,就可以進一步掌握更重要的要素。有個清單可供參考。

極端基本教義的錯誤有很多種。

然而有錯誤並不可怕,可怕的地方在於極端基本教義派難以自省問題,因為他們的存在目的在於「迫使」其他人跟隨絕對不會錯的自己。 

Scrum終究仍是管理類型的技術,因此不會工程或科學一樣有細節標準可循。光是Scrum證照在市面上就有N種,更何況是各種細微技巧。 

極端基本教義派常會其中的技巧視為必須,反而遺忘真正的重點。 

更慘的是,極端基本教義會將補習班的奇淫巧技,是為基本重點,舉例如下: 


例一:堅持每天舉行「站立會議」,而且會議中唯一堅持的事情就是大家要「站著」。 


會議內容倒是五花八門,從討論問題,到穿插最近公司要大家額外參加的同樂活動都有。Scrum的每日會議僅只講三件事:「上次會議到現在做完了哪些task」「到下次會議之前打算做完哪些task」「目前遇到什麼重大問題」! 


例二:估計時程的撲克牌,堅持使用點數來估計task。但從來也不檢討時程為何不準確。 


不可否認Scrum撲克牌是有用也有趣的觀念。但是,它並不是唯一最好的估算時程方式。

事實上,只要是軟體團隊,經歷過2-3個sprint的團隊,在第3到4個sprint開始之後,直接以時間來估計時程更容易更確實!

因為絕大部分軟體的困難度是時間與執行問題,在撲克牌估計點數中都有個假設是:難度可能和時間無關,但就軟體開發而言,幾乎不可能! 

再者,Scrum撲克牌根本也不是Scrum獨有的,大約在2005年之前就已經有人提出類似的方式(註3)。當時需要以點數(point)而非確切的時間來估計時程,一部分的原因是:估計時程的人根本不是「做事情的那個人」! 

由於搞出以點數估計task難度,在以團隊速度推算時間這種以繁馭簡的人,在當時,他是為了是搞出另一套可以拿PMP的PDU/SDU課程讓大家來學習,並不是因為他有專案實例在此!因此,就目的而言,其實也不太能讓人苟同。 

撲克牌工具仍然是好工具,非線性的點數分配仍然是好觀念。

但如何操作還是要看團隊在每個sprint結束檢討而定。 


例三:因為各種原因,沒有先執行最重要的事情 


所謂最重要的事情,就是最重要的事情。如果他是最重要的功能就應該先行完成。如果他不是,就不要現在去做。 

基本教義派最常以「這個sprint是4週,如果先做P2,下個sprint做P1就會比較快,不然先做P1可能sprint沒辦法是4週」作為技術上,區別功能先後完成的依據。 

 如果Product owner也認為是如此的話,那麼只有兩種可能:(1) P2其實是最重要,P1相較之下不重要,或者差不多重要。(2) product owner無法代表市場,了解事情的重要性。或者很難了解。 這兩者其實都會發生,也都無可厚非。因為agile的精神本來就在於適應變化。

但scrum團隊絕對的基本觀念就是:如果已經很確定這件事情真的是最重要,就絕對應該先做! 

而Scrum Master除了處理團隊問題,每日站立會議之後,要問自己的就是團隊是不是正在做「最重要的事情」,這遠比趕快更新燃盡圖(burndown chart)來的重要。確保團隊隨時都在做「當時最重要的事情」是Scrum Master「隨時最重要」的任務。




註1:agile基本精神如下:

(1) Individuals and interactions over processes and tools
(2) Working software over comprehensive documentation
(3) Customer collaboration over contract negotiation
(4) Responding to change over following a plan


註2:但是這三個重點,也是補習班沒辦法直接教的


註3:http://www.informit.com/store/agile-estimating-and-planning-9780131479418

11/14/2016

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




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

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

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

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



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


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

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

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

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



檢討二:選項



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

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

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

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

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



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


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

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

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

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



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




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

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

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

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

台灣博士生與大數據分析:如何評估對大數據分析的本職學能?



最近有個真實故事:



(為保護當事人,內容與細節均有所改變) 

台灣人F,目前就讀於某知名國立大學,已經是博士候選人。

最近為要爭取某一私立學校E的教職。在其履歷表上是以雲端計算大數據專家自稱。而E校的某系評會要求他面試15分鐘,用以評估他的能力。試教主題不限。

然而,F其實對大數據除了看過一些商管叢書之外,其實根本一竅不通。因此,他找了以前大學時候已經在業界工作的好友J,問了一些「技術問題」如下:

F:我聽說過spark,是不是大數據分析都用它啊?spark是不是個作業系統?

J:如果這是你的問題,那你壓根離spark太遠。後面就不要再談了。

F:哎喔,我覺得教學只是個演出啦,看表面而已。以你在業界打滾多年,就幫我個忙。couchbase是什麼?有什麼如果講出來會讓大家知道我很厲害的地方?

J:如果這真的是你的問題,你真的什麼都不懂啊,就算你去E校當教授,也是害了別人。

F:....



這個真實故事乍看之下太過駭人!但或許反映了學術與實務之間的鴻溝。

其實,台灣有許多學術界的人才,不但學術淵博,技術根底也厚。從數十年前的硬體產業蓬勃發展就可見一般。近幾年的軟體也是,許多教授幫業界「產出」能產生價值的知識性員工,並且也讓業界的知識持續推進。

然而,M型社會反映的層面,不指是一般在職場工作的人,在學術界中也越趨嚴重。

也有不少學術蟑螂。他們靠著極致的生存能力和夠厚的臉皮,穿梭在三流研討會,大企業策略部門,顧問性質演講,以及不在乎學生品質的大學院校中。

這些學術蟑螂做的事情,大概也不會真正傷害到誰,只是,也不會對任何人有好處。只要不是在「自己家裡」,一般人在路上看到蟑螂只會視而不見,也不太會去追打。

但是,如果是在自己家裡呢?

評估對大數據的本職學能,才能判斷來者是學術淵博的長者,還是費力在夾縫生存的蟑螂。如果是像E校一樣,原本的教授群並沒有這方面的背景,要如何在沒有足夠的知識情況下,判斷對方有沒有知識?這雖然有點難,但是,透過一些方式還是可以把誤判機會降低。



(1) 實際經歷探詢(情境實例面試法)


情境實例面試法很基本,但是事先有所準備。做法很簡單,只詢問「過去實際上」發生的事情,用以判斷被面試者現在的情況。而且絕對不詢問開放性問題!!

對於couchbase而言,就不會問「你對couchbase瞭解程度如何」或者「分散式資料庫你有哪方面研究」。因為這類型開放性問題,會浪費大家的時間。也會讓學術蟑螂有機會以混淆視聽的長篇大論,大打模糊仗來損耗面試者的判斷精力。


簡單問題像是:


* 請用1分鐘定義何謂nosql

* nosql的實作有很多,請舉一個你最熟悉的nosql平台工具,一個你實際最常用,最熟悉的就好(在此假設他回答couchbase)。

* 請問你實際接觸couchbase多久了?  (用判斷他最熟悉的工具有可能有多熟,如果少於6個月大概也等於是不太熟)

* 你利用couchbase為平台,撰寫並發表過哪篇論文?(學術界而言,沒有發表相關論文等於是沒有相關方面的研究)


稍微麻煩的問題像是:


* 你有沒有加入couchbase的任何相關的mail-list? (沒有加入mail list也沒關係,但表示其實只是單純的使用者,不會有太多深入的了解)

你利用couchbase為平台,撰寫並發表過哪篇論文中,所使用的研究資料量有多大?100G?10T?(資料量極小的nosql,並不代表不正確,只是代表不是大數據而已)

* 你用過哪些版本的couchbase(起碼要記得大版本編號吧)

* 你最近讀了哪一篇論文是以couchbase實作其研究?是大概什麼時候讀的,內容是什麼?


總之,事先準備好不能模稜兩可的問題,並且也定義好不能模稜兩可的期望回答。事先準備的問題也不需要太多,只要7-10提及可。這樣,比較不容易被蟑螂溜進來。並且,在準備的過程中,其實也會讓團隊(無論是學術還是技術團隊)對這方面的知識有基本的增長。


(2) 真實展示


簡單的說,就是請他拿一台電腦,展示一下他對大數據分析中最會「做」的事情。無論是撰寫程式碼,還是建立模型都可以。

真實展示其實很容易騙得過沒有相關知識的人。但是,如果事先已經提醒會有真實展示,可以簡單篩選掉連打開電腦都不敢的小蟑螂。

E校要求試教15分鐘,其實是真實展示的好方法。然而,盡可能展示「動手」而不僅只是「動口」。雖然君子動口不動手,但是蟑螂恐怕也是。


(3) 自我反省

當在一個地方看到蟑螂的時候,通常表示附近還有另外10隻蟑螂(也有人說是數百隻),只是沒看到而已。會有蟑螂來面試 - 無論是工作還是教職 - 是不是這組織已經有很多蟑螂。更重要的是,自己是不是其中一部分。

自我反省是極端困難的工作,對生活優越的自己,在心理上也不見得好過。但是,在陰暗狹小的地方求生存,總是比不上光明正大的貢獻自己的能力。

請謹記,「自信心」和「自我感覺良好」只有一線之隔。或許,透過實際經驗探詢,先自我檢查自己,才是去評估別人之前,真正自己應該做的事。












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個月)的軟體專案而言,讓破壞性的不適任者離開,當然是解決方式,但不見得要「找另一個人進來」。






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