顯示具有 self learning 標籤的文章。 顯示所有文章
顯示具有 self learning 標籤的文章。 顯示所有文章

8/15/2018

Scrum: 三件不能少的事



Scrum是敏捷開發原則下,目前在軟體產業裡常見的方法論。而由於Scrum只是個方法論,並沒有所謂的標準,各個組織的應用方式皆有不同。常見的應用(practice),例如:spint-kick-off-meeting, daily standup, burn down chart, planning poker, retrospective。

零零總總的practice中,哪些最為重要當然眾說紛紜。考慮到Scrum的真正精神,以下三件事情是「最基本要有的」。也就說,如果這三件事情做不到,那麼其他事情做到也沒有用。


(1) 每個Sprint有交付具體產出


Scrum的Sprint都要有具體「可交付」的產出。sprint的開始,就應該以「結果」為計畫的導向,而此結果必須要是可交付的產出。

有些團隊會以Sprint長度不夠為理由,設定一個「並不能交付」的milestone作為該sprint的產出。如此一來會有幾個問題:(1) sprint結束的檢討,並不基於產出的事實 (2) kick-off下一個sprint的意義不大,因為前一個sprint並沒有真正可在市場衡量的產出 (3) PO會有充足的理由不參加demo以及下一個sprint的kick-off,畢竟這個sprint沒有有意義的產出,而如此一來PO就很容易不真正加入團隊。

Sprint不見得要固定長度,請參考這裡。 


(2) PO有確實加入Scrum團隊


Scrum團隊成員有三個角色,team member, scrum master, product owner。其中最容易不在的人,就是product owner。許多軟體開發團隊,product owner就是PM。但無論如何,Product owner必須要真實參與團隊。

所謂真實,指的是所有standup應該參加,在團隊運作過程,能夠回答該sprint的需求問題,並確實知道sprint中間「不應該做的事情」以及sprint開頭結尾「應該做的事情」

更重要的是PO加入團隊之後,DOD(definition of done)的標準才會具有「市場一致性」。舉例來說,不成熟的軟體研發人員常會對事情做完有不同的定義:
「程式寫完只是還沒review,所以還沒merge」
「程式寫完測試也沒問題,只是QA還沒通過」
「功能搞定了,QA也沒問題,只是還沒...」

PO確實加入後,可以讓事情做完的定義,統一在於「可準備交付到市場」。換言之,所有和程式設計相關的工作:測試,相關文件,環境設定,certificate等等都會以「可準備交付到市場」為原則。沒有這個原則,跑Scrum很難達到預計效果,要達到這個原則,最基本的就是PO需要確實投入團隊。


(3) 每個Sprint結束之後有確實地檢討(Retrospective meeting)


這世界上沒有完美的團隊,也沒有不用修正的軟體開發方法論。每個sprint的確實檢討,是修正團隊,讓團隊趨於一致的唯一方式,而非強加訴諸任何規矩。請參考這裡

確實的檢討並不容易,要做到兩件事情:
(a) 基於事實檢討   
(b) 不檢討不在場的人事物 


基於事實的檢討


檢討的內容必須基於事實,不是基於感覺與想像。感覺和想像的情況如下:
「我感覺好像有點慢」
「不知道怎麼講耶 但這個事情不應該這樣做」

事實的情況舉例如下:
「這個sprint我們沒有按照當時說好的DOD的定義,所以有XX與XX項目,本來說完成了,後來隔幾天又說沒完成」


不檢討不在場的人事物 


檢討確實是對事不對人,然而,事情都是人做的,不可能不檢討「人的做法」。不檢討「人的做法」只是鄉愿。

不過,要避免檢討不在場的人。
例如「因為UI/UX之前給的東西不正確,導致我們要重做某些事情」如果UI/UX是同一個scrum團隊,那麼檢討此項目當然可以。但要是不是同團隊就沒有意義。
因為,Scrum的檢討會議目的是產生「團隊要改善的項目」,而不是去讓非團隊的人改善。

Scrum的學習必然是從實際的經驗獲得,但經驗的獲得又必須從知識學習的取得為基礎,要成為看似不錯的Scrum專家不難,但要實際應用於專案中,並取得可重複成功的結果就不這麼容易了。





11/10/2017

技術迷思:是人類使用工具還是工具使用人類?



在知識頻道和各類文章中,都有對於到底是「人類馴化狗,還是狗透過改變自己馴化人類?」有些有趣的討論。也是因為太多先進國家裡,家庭中的狗,實在過得太幸福,以至於太多其他人類質疑自已,該不會是因為狗的訓練人而進化?

資訊科技工具 - 特別是近年來手機和網路 - 也會讓人有此錯覺。

人類創造手機與網路,但是從小活在資訊世代的人,在成長過程中,很大的情況是被「手機」所馴化。和同學朋友聚餐的時候,大家拿起手機拍照推文的情況屢見不鮮。隨時隨地都要看一下手機的,遠比當它響的時候才看得人多。隨著手機功能越來越強悍,壽命卻越來越短。....手機已變成超越原本功能,超越一切的存在。製造商推銷手機的方式,幾乎已經和手機原本的功能 - 也就是和其他人聯絡 - 無關了。

事實上,手機的功能密集高,導致於在地球上任何一支智慧型手機製作,都牽涉到上百萬人的投入。沒有任何單一企業,組織,能「自己從原物料開始,從頭到尾搞出一台手機」。(註:不過倒是有人可以從頭到尾搞出一台烤麵包機)

手機與網路,既然已經成為超過創造者的存在,就與時俱進的,造就類似宗教信仰般的崇拜,終極果粉(apple手機的愛好者)就是明顯的例子。

不過,並不推薦極端的阿米希式的全然拒絕方式,畢竟,現在沒有手機號碼只會造成自己的痛苦。避免工具反客為主,有幾個合理方式。

(1) 偶爾換方式或者不用它。


要證明自己戒酒的方式,就是確保自己有夠長的時間不喝酒。同樣的,要證明自己沒有手機資訊焦慮症的方式,就是一段時間(3天)完全不使用它,或者是一段時間(7天)只能每天用一次。推薦最好是去日本度假,雖然帶著手機,但是限制僅作為緊急聯繫用途。不但可以徹底放鬆身心,也可以去除資訊焦慮憂慮。

(2) 優先改變工具配合生活,不改變生活配合工具。


人類的高度適應力,讓人「本來」就會配合工具而生活。火車飛機的乘坐方式就是很典型的例子。認知到工具會改變生活,然而人類卻也能改變工具,讓工具適應自己。
古早之前,還是底片相機的時候,旅行者通常會以「親身感受」風景為優先,然後有空的時候才照相。在數位時代成長的人,旅行的時候很可能是以「數位相機的鏡頭感受」為優先,也就是說,看到美景先照相,看到美食先照相。反而讓自己的視覺和味覺的優先順序,讓給沒有感覺的擁有高檔鏡頭的手機。在你手上的手機是不會不見的,可是對於旅行的體驗和感受,一旦由「你的手機」先做第一時間的感受,旅行的意義就大幅降低。以後或許看別人的部落格文章也就夠了?


(3) 成為什麼樣的人,遠比擁有什麼樣的東西來得重要。


生活圈的朋友親戚同事,必然的會互相影響,包含購買的最新手機等等。這些都無可厚非,不過,只要記得單純可以用錢買的東西,都很容易單純而且簡單地失去。然而,需要努力學習得來的:例如知識技能經驗,卻幾乎會跟著一輩子。






10/17/2017

工作中速度與效率的迷思




孫子兵法:兵聞拙速 未睹巧之久也

媒體大亨Rupert Murdoch:不是大的打敗小的,而是快的打敗慢的


效率以及速度,在職場上的重要性應該眾所皆知。然而,速度並不見得會產生「效率」,當然也就可能沒有「績效產出」。

工作中的速度與效率常見有幾種迷思如下:


速度的相對論


在職場上,速度時常是相對的。

有個笑話最適合描述這樣的相對論:兩個好朋友去非洲野營,在帳篷睡到半夜,聽到有獅子在附近低鳴,似乎打算把這兩人當作食物。其中一人開始穿衣服鞋子,另一人惶恐地問「我們有辦法跑得比獅子快嗎」,已經穿完鞋子正在做熱身操的那位仁兄回答:「我不需要跑得比獅子快,我只要跑得比你快就好」

然而,相對論的確有其迷思與限制。例如,在大型企業中,或許你已經是個主管,相對於其他同事,你也有創意,而且你辦事速度也很都快,看似一切穩當。但是有一天,你所屬的部門被公司老闆出售給外國企業,而該企業也表明只需要技術人才,不需要主管階級時,你才發現原來速度的比較對象,不應該僅僅是在自己的組織之中。(沒錯,這裡說的是HTC最近的賣部門給google的事情)


過程與結果的本末倒置


速度應該是「過程」,而效率和產出,才是「結果」。

把速度當作結果等於是本末倒置。

所以,讓網頁的使用者回應時間,從2.5秒,加速到0.25秒,看似一個有指標性質的結果。但已產出的觀點來看,其實可能是要達到「服務更多使用者」「增加效率」或甚至「減少電費」這些確切結果的「過程」。

工作中單以「速度」作為結果的績效指標,很快就會導致局部最佳化的組織問題。


沒有目標的ASAP


當詢問同事/主管說「請問這件事情應該何時完成」,如果時常聽到ASAP-as soon as possible 越快越好,而沒有具體的解釋,其實是危險的指標。

沒有具體衡量的速度,可能導致幾種錯誤想法:

(1) 這是不計一切代價要越快完成越好的事情,即便犧牲性命也在所不遲,因為一旦完成就會有很美好的事情發生。這樣的想法過於革命性的危險,事實上,僅有極端少的事情是不計一切代價,連生命都可以不要的。

(2) 每個人的時間感受不同。也許CEO的告訴中間主管的ASAP,在當時他的心中是指3個月,而中間主管告訴工程師的ASAP,在他當時的心中是指3個禮拜,可是,工程師的感受可能是5天。最糟的情況是,工程師會誤以為ASAP表示可以犧牲品質,如同上段所述,是可以不計一切代價達到速度。

(3) 有太多事項都是ASAP時,表示根本沒有設定正確的目標以及優先順序。




附註,關於速度突破職場困境,請參考這篇

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 (獵人頭) 鑑定看看是否有效果。

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

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


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/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的缺點




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

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



在每年不可計數的企業管理勵志書籍中,有越來越多把「時間」視為判斷事務的重要標準。想當然,個人「時間管理」變成一種必要的技能。然而,更近一步是在越短的時間,達到越驚人的效果,從早期的「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:增加工作效率?聽起來和前述的巫醫有什麼不同?就想要達到的效果來說,有良心的巫醫和一般的醫生並沒有不同。最大的不同在於方法是不是合理,經過有效驗證,而且可以在未來檢討改善。



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台幣之間。