Oct. 01 11:17~13:06
前幾天讀了何飛鵬先生的《自慢3：以身相殉》這本書，書中提到作者自己早年在創業的時候一直失敗。在某個機緣之下，作者遇到了石滋宜博士，在聊天的時候石滋宜博士說：
什麼是笨？就是老是用同樣的方法做事，卻期待會有不同結果的人。
作者在書中提到：「這句話一語驚醒夢中人，過去四年來，我一直用同樣方法經營著《商業週刊》，卻每年期待會有不同的結果，這不正是我嗎？我何其笨啊！」
***
明天下午Teddy要參加ezScrum團隊在台南成大所舉辦的活動，介紹Scrum與分享Scrum導入經驗。介紹Scrum這一點沒什麼問題，之前已經講過太多次了。但是，對於第一次接觸Scrum的鄉民們，Scrum導入經驗分享要講些什麼呢？想來想去，只想到四個字「擁抱改變」。
現在讓我們來探討一下「產出」、「工時」、「效率」這三者的關係。
- 工時：假設1個人1小時可以寫20行程式，1天工作8小時可以寫160行程式。那麼如果1天工作14個小時，就可以寫280行。因此，增加工時可以提升產量（請先對這句話持保留態度，因為需要有一些前提成立才可以能達到此目的）。
- 效率：假設1個人1小時可以寫20行程式，如果可以想辦法將效率提升到1小時可以寫40行，這樣1天工作8小時就可以寫出320行。
***
接下來探討一下工時和效率兩者之前的關係。在固定的產出之下（例如寫完100行程式），增加效率則可以減少工時。至於工時和效率的關係，可以從兩方面來討論。
- 增加工時會減少效率：一般而言增加工時應該是會減少效率，因為人的體力與專注力有限，而軟體開發又是需要腦力與專注力的活動。因此，增加工時，尤其是長時間增加工時，將會降低工作效率。例如，長時間加班很可能會導致開發人員無法專心、腦袋空轉，或是因為bug變多以致於抵銷因為增加工時所產生的生產力。更慘的是，可能因為bug變多，或是設計品質下降，經常需要rework。看起來好像每個人都很忙，但很多時間都在瞎忙。
- 增加工時會增加效率：有些老闆或是主管會有一種想法，認為員工在上班時間無法把預計的事情做完，是因為員工個人「能力不足或是經驗不夠」。所以，「採用責任制，留下來免費加班」，補足員工個人的經驗並且提升員工的能力，這也是理所當然的啊。因此，增加工時可以讓員工增加經驗值，可以提升未來的工作效率。
說真的，以上兩種說法個別看起來好像都有點道理
***
由於提升效率需要牽涉到很多「公司制度與文化」還有「管理能力」、「人員聘雇與淘汰」、「教育訓練」等制度面的問題，實施起來並不容易且短期的成效可能不明顯。所以，很多公司為了提升產出，就採用最簡單、省錢、也最不花腦筋的方法，那就是：「上班打卡制，下班責任制」。
老闆內心獨白：因為提升效率好傷腦筋，所以就用同樣的方法做事（效率固定），只要增加工時，應該就可以有不同的好結果吧！
石滋宜內心獨白：什麼是笨？就是老是用同樣的方法做事，卻期待會有不同結果的人。
***
現在逆向思考一下：如果要在工時固定的前提之下，還要增加產出（競爭力），那怎麼辦？只有想盡辦法來提高效率才得以生存下去啊。
提升效率的方法很多，Scrum可以做到的幾個重點：
***
看到Teddy提倡XP所說的「每週工作40小時」（按時下班）這種作法，可能有鄉民會認為Teddy是那種「不食人間煙火的理論派」。其實Teddy在年輕的時候，也是幾乎每天都加班。晚上11點才離開公司趕搭最後一班公車算是家常便飯，在公司過夜也不是什麼新鮮事。那時候Teddy也是想：「自己年輕，能力與經驗不足，所以多花一些時間來彌補這些不足」。但是，手邊的專案有準時上線嗎？軟體的品質有變好嗎？做出來的產品客戶滿意嗎？很遺憾，答案多半是否定的。
當年Teddy除了「傻傻加班」這個致命武器以外，Teddy也會花時間看書。在自己看了很多書之後，能力好像有提升一些，但是這樣的能力提升，要擴展到整個團隊身上，卻是非常的困難。因此，Teddy心中的小惡魔的聲音就越來越大聲：
小惡魔：為什麼自己做的那麼累，晚上11-12點才走，而底下的其他人卻「早早下班」（晚上7-8點左右）？
小惡魔：這隻程式明明那麼簡單，為什麼你寫了這麼久還沒寫完？
小惡魔：大家上班真的都有在好好工作嗎？
當這種負面的思慮充滿自己的腦袋之後，這個專案差不多就要注定失敗，團隊也可以準備解散了。
***
回頭看一下Teddy剛剛說提到「增加工時會增加效率」這個因素。這個因素不是不可能達到，但是「增加工時」並非讓員工「老是用同樣的方法做事，卻期待會有不同結果」，而是要思考：
如何在增加的工時中，提升自己的工作效率。
敏捷方法強調開發團隊要有「穩定的步調」。固定工時，短時間看似減少生產力，但其實好處多多：
- 讓有企圖心的員工可以有時間可以去思考、讀書、進修、兼顧工作生活。
- 可以鑑別出「守本分」（效率不動如山）的員工與「持續成長」的員工。(這一點很重要)
- 提升員工法定工作時間的專注力。
- 反映出專案的真正成本。
- 暴露出公司與團隊的不足之處，以謀求改善之道。
最後再補充一點，工時不是不能增加，在特殊情況下，短時間內增加工時是可以提高生產力。但無止盡的長期加班只會導致員工「上班的時間都在生活（都在打混）」。生命會找到出路，員工也不是笨蛋啊。
***
友藏內心獨白：很多人其實很難接受「水清則無魚」這個現象。
例如那種廣告活動類型的公司，當他們要做網站的時候，無論多少人、多少事，deadline就是deadline，時間內就是要完成，客戶在意的只有目標能否達成，不管甚麼工時與效率，如此一來真的能夠套用Scrum嗎? 我挺懷疑的! 可否請 Teddy 釋疑? 謝謝!
回覆刪除Hi 鄉民：
回覆刪除(1) 我想大部分的客戶，可能都不管施工廠商的『工時與效率』，只管時間到了東西有沒有生出來。
(2) Teddy關於 Scrum 的經驗主要在於軟體開發，『廣告活動類型的公司』並非 Teddy 專長 （趕快撇清）。
(3) 我這一篇的重點在於 (a) 先嘗試把工時固定，可以強迫團隊把『流程上』、『能力上』、『公司制度面』等等的問題給『暴露出來』(b) 各個行業、公司、團隊的工作模式不一樣，需要自己找出一個適合自己的方法。但如果只是一味增加工時希望員工可以產出更多的產品，而非把時間花在思考如何提昇效率，在『軟體開發產業』來說，是很危險的一件事。
Teddy 的能力有限，無法包山包海涵蓋每一個不同的產業啦 XD。
謝謝。
Dear Teddy,
回覆刪除謝謝你的迅速答覆 ^_^
軟體團隊在研發的過程中多多少少都會有『流程上』、『能力上』、『公司制度面』等等的問題，我覺得整體來說應該就是【公司管理制度】的問題，公司制度跟不上新形態的開發模式，也是白搭。
對於你所提出的「固定工時，短時間看似減少生產力，但其實好處多多」的部分，我希望能跟你好好激盪一番：
* 讓有企圖心的員工可以有時間可以去思考、讀書、進修、兼顧工作生活。
=> 以我個人經驗，有企圖心的員工，願意主動思考、讀書、進修的人，恐怕是少數! 大部分的人都只想兼顧工作與生活，這沒甚麼不好，只是強調了這點可能會反而降低生產力，而且還可能拉不回來，尤其是當前台灣的資訊慘業。
* 可以鑑別出「守本分」（效率不動如山）的員工與「持續成長」的員工。(這一點很重要)
=> 這一點我百分百認同，而且真的很重要，不過這也要公司的管理制度配合，有適當的激勵與懲罰才有效果。
* 提升員工法定工作時間的專注力。
=> 專注力往往決定於團隊成員個人的自制力，公司不封鎖 FB, Plurk, Twitter, MSN, Skype, Weibo, LINE, WhatsApp, ... 通常都會讓部分成員分心導致降低生產力，阻擋了這些社交網路存取，又會引發民怨，或因為無法透過網路向外人求助而引來負面效應。
* 反映出專案的真正成本。
=> 專案的真正成本光從工時來看根本算不準，因為變數非常多。開發效率高的團隊成員通常比團隊中最低的還高出好幾倍。
* 暴露出公司與團隊的不足之處，以謀求改善之道。
=> 同意!
------
在傳統公司裡，或非技術導向的公司，導入 Scrum 我覺得應該是遙遙無期。
而在技術型的公司，「增加工時會增加效率」這一個假設前提我覺得是有問題的，應該沒多少公司或主管真的希望刻意增加工時以提升工作效率，往往都是因為專案 deadline 趕不上才會加班，大家都是為了特定目標趕工的，並不是為了提高工作效率。
再者，如果團隊成員每個人都能自我要求、自我提升、晚上回家都會主動看書提升軟體開發過程中的工作效率，為了專案deadline大家都能提前把工作完成(因為工作效率已經提升)，那主管怎麼還會想要求加班。
往往是專案時程離死線越遠，大家的積極程度也會越低，這是人性。或許透過Scrum可以改善人性面的瑕疵，也讓大家離死線很遠的時候也能積極點，但這真的不是件簡單的事，Product Owner 與 Scrum Master 對團隊的運作舉足輕重，一個不小心還可能會毀了一個團隊原本能有的產值，或許原本因為特定目標偶爾加班硬撐出來不錯的產能，但若因為 PO 與 SM 管理不當而導致團隊氣氛爬不起來，大家在趕工時又不願意加班，目標也不可能達成。當這種團隊氣氛蔓延至所有人身上，這個專案也差不多就要注定失敗，團隊也可以準備解散了。
Hi 鄉民：
回覆刪除難得有鄉民願意發表這個長篇的寶貴意見，太感動了。
=> 以我個人經驗，有企圖心的員工，願意主動思考、讀書、進修的人，恐怕是少數! 大部分的人都只想兼顧工作與生活，這沒甚麼不好，只是強調了這點可能會反而降低生產力，而且還可能拉不回來，尤其是當前台灣的資訊慘業。
我也同意這些人不是多數，但是由於『齊頭式的加班文化』，讓這些人無法利用時間去培養實力，只會讓團隊的士氣與能力停滯不前 （明明沒事了卻不可以下班，還要在公司裡面假裝有事做）。
***
* 可以鑑別出「守本分」（效率不動如山）的員工與「持續成長」的員工。(這一點很重要)
=> 這一點我百分百認同，而且真的很重要，不過這也要公司的管理制度配合，有適當的激勵與懲罰才有效果。
當然很多事情是要公司制度的配合。Scrum 好的地方，只要你自己真的試過，就像是一面『照妖鏡』，好的、不好的都會被照出來。想打混的人會無所遁形，箇中巧妙之處真的要實施過就知曉 XD。
***
=> 專注力往往決定於團隊成員個人的自制力，公司不封鎖 FB, Plurk, Twitter, MSN, Skype, Weibo, LINE, WhatsApp, ... 通常都會讓部分成員分心導致降低生產力，阻擋了這些社交網路存取，又會引發民怨，或因為無法透過網路向外人求助而引來負面效應。
個人自制力當然是專注力的基礎，但是很多時候，專注力會被很多『事件』給打斷。流程不順、跨部門溝通、回不完的無意義email、打嘴砲、無意識但定期會發生的會議、皇親貴族與大臣們的亂入...等等等，這些都不是光靠『個人自制力』可以應付的。
我好像扯太遠了，原本我想說的只是：『經常性加班，隔天上班會很沒精神啦』。
***
* 反映出專案的真正成本。
=> 專案的真正成本光從工時來看根本算不準，因為變數非常多。開發效率高的團隊成員通常比團隊中最低的還高出好幾倍。
基本上我覺得軟體開發計畫，最大的成本應該就是開發團隊的時間，也就是工時。開發效率高的團隊成員通常比團隊中最低的還高出好幾倍，這我絕對同意，所以高效率的團隊所需的工時會比較短。但是『理稐上』公司付給高效率團隊的總薪資應該會比低效率團隊要要。我想講的是，一般軟體專案應該還是依據人/時來計算費用。
***
我個人覺得，要不要導入 Scrum其實不是重點，重點是:
(1) 一個公司認不認為自己需要改變？
(2) 如果需要，有沒有推動變革的勇氣與決心？
如果以上兩點都成立，要導入什麼『東東』，就看產業別的需要。
任何改變都是困難的，有時候需要摸著石子過河的勇氣與決心啊。
報告完畢。
Dear Teddy,
回覆刪除多謝回答 ^_^
以下幾點討論：
1. Scrum 我 Run 過，的確如您所說像一面『照妖鏡』，好的、不好的都會被照出來，沒實力又沒人緣的人的確很快就會被逼走。但沒實力(或沒生產力)又有人緣的人(例如很努力工作+每天加班)，就會留在團隊裡，大家會幫助他快速成長，這些的確都是好處。但是 Product Owner 不斷面對客戶(擔心Scrum會帶來時程無法掌控的莫名壓力)與內部成員(期望Scrum給他們帶來的好處)的雙重壓力，讓他越做越辛苦，直到放棄！關於這點是否有好的方法？
2. 專注力提升真的很難，光是公司裡的電話與其他雜務干擾，真的很難進入神馳狀態！你這有好方法嗎？ ^^
3. 軟體專案成本的確跟開發團隊的時間(工時)有很大關係，但客戶打從一開始在需求不明確時就要求團隊評估出工時，Product Owner 真的很為難，對上要對預估工時有所交代，對下要讓團隊接受客戶期待的工時，當兩邊喬不攏的時候，一樣會怨聲載道。你如何面對這種困境？
你的最後兩個重點:
(1) 一個公司認不認為自己需要改變？
＝＞通常是需要的！因為問題一直存在！
(2) 如果需要，有沒有推動變革的勇氣與決心？
＝＞勇氣不是沒有，嘗試過後，PO 被客戶幹譙個半死，專案結束後成員全數離職，其實跟決心改革前好像還更糟糕，我們是真的很用心跑了一段時間，專案成員各個十分團結，也頗認同Scrum，但公司卻沒有好下場。不知道耶，可能是我太悲觀吧，一次失敗經驗就嚇到了，也許不適合用在【非產品研發】類型的公司吧。不知道你有何見解？
我知道任何改變都是困難的，有時候摸著石子過河，是會沉的。 XD
謝謝！^_^
不好意思，不是要跟你打筆仗啦，真心想跟你腦力激盪一下，我真的很想重拾 Scrum 的懷抱。 ^^
回覆刪除Hi 鄉民：
回覆刪除我昨天一整天都在台南，所以沒有時間回覆你。
1. 但是 Product Owner 不斷面對客戶(擔心Scrum會帶來時程無法掌控的莫名壓力)與內部成員(期望Scrum給他們帶來的好處)的雙重壓力，讓他越做越辛苦，直到放棄！關於這點是否有好的方法？
＝=>『擔心Scrum會帶來時程無法掌控的莫名壓力』剛好跟我的經驗相反，在團隊剛開始導入 Scrum 的時候，的確可能會有３－６個月的適應期，在這一段時間之內，團隊的產出會有起起伏伏，比較不穩定的情況。但等團隊上手之後，我的經驗是，時程反而比較容易掌握。
我覺得答案很簡單，就是你沒以沒找到一個好的 Agile Coach 來輔導。這好像生病需要看醫生一樣，有些小病自己買成藥吃一吃也許就好了，但是『大病』不看醫生，然後自己買藥吃發現沒用，再去怪藥不好，這種作法是於事無補滴 XD。
2. 專注力提升真的很難，光是公司裡的電話與其他雜務干擾，真的很難進入神馳狀態！你這有好方法嗎？ ^^
答案同上 XD。
3. 軟體專案成本的確跟開發團隊的時間(工時)有很大關係，但客戶打從一開始在需求不明確時就要求團隊評估出工時，Product Owner 真的很為難，對上要對預估工時有所交代，對下要讓團隊接受客戶期待的工時，當兩邊喬不攏的時候，一樣會怨聲載道。你如何面對這種困境？
『但客戶打從一開始在需求不明確時就要求團隊評估出工時』--> 哪就想辦法把需求弄清楚一點，清楚團隊覺得可以估算為止啊。
我知道這種說法你會覺得『不可能』，但你要先回頭看看你公司與專案的 Context、Problem、Force 各是是什麼，再分析你要採用 Scrum 這個 Solution 之後，對於原本的 Force 是否有辦法解決。也就是說，套用 Scrum 之後你的 Resulting Context 是什麼？這個 Resulting Context 是不是你能接受的？如果不行，要如何調整 Solution...... ( 你如果有上過 Teddy 的 Pattern 課程就比較知道要如何分析問題)。
每家公司、客戶、專案、團隊組成、資源等等的狀況都不一樣，我無法給一個『標準解答』啊。
***
你的最後兩個重點:
(1) 一個公司認不認為自己需要改變？
＝＞通常是需要的！因為問題一直存在！
(2) 如果需要，有沒有推動變革的勇氣與決心？
＝＞勇氣不是沒有，嘗試過後，PO 被客戶幹譙個半死，專案結束後成員全數離職，其實跟決心改革前好像還更糟糕，我們是真的很用心跑了一段時間，專案成員各個十分團結，也頗認同Scrum，但公司卻沒有好下場。不知道耶，可能是我太悲觀吧，一次失敗經驗就嚇到了，也許不適合用在【非產品研發】類型的公司吧。不知道你有何見解？
『我們是真的很用心跑了一段時間，專案成員各個十分團結，也頗認同Scrum，但公司卻沒有好下場。』
=> 就說你們要花點錢找『Agile Coach 』來幫你們導入 Scrum。台灣很多公司都想『省錢』，什麼都要自己試，但是有沒有能力可以靠自己就搞好。在『省錢至上』的原則下，自己嘗試的結果，很多時候是以失敗收場。結果不但沒省到錢，反倒是浪費更多錢。
我知道任何改變都是困難的，有時候摸著石子過河，是會沉的。 XD
--> 找對人，成功的機率才可以提昇啊。
Teddy 第一次幫忙導入 Scrum 的經驗，對方可是花錢請 Teddy 每天都到公司和團隊在一起。每個 sprint 開始 Teddy 以『Agile Coach』的身分參加 sprint planning meeting，然後每天早上到對方的公司參加 Daily Scrum。Sprint 結束的時候參加 sprint review, retrospective meeting。
就這樣進行了６個月，Teddy 才覺得慢慢把團隊給帶起來。以上經驗提供你參考一下。
Dear Teddy,
回覆刪除非常感謝你的回答，對我幫助很大! 謝謝!!
^_^
Dear Teddy,
回覆刪除非常感謝你的回答，對我幫助很大! 謝謝!!
^_^
一篇不錯的文章分享：
回覆刪除＜頭腦＞轉得又快又順而去做的一天能做許多事。
http://blog.udn.com/oyt0915/31932271