l

2012年10月1日 星期一

什麼是笨?

Oct. 01 11:17~13:06

image

 

前幾天讀了何飛鵬先生的《自慢3:以身相殉》這本書,書中提到作者自己早年在創業的時候一直失敗。在某個機緣之下,作者遇到了石滋宜博士,在聊天的時候石滋宜博士說:

什麼是笨?就是老是用同樣的方法做事,卻期待會有不同結果的人。

作者在書中提到:「這句話一語驚醒夢中人,過去四年來,我一直用同樣方法經營著《商業週刊》,卻每年期待會有不同的結果,這不正是我嗎?我何其笨啊!」

***

明天下午Teddy要參加ezScrum團隊在台南成大所舉辦的活動,介紹Scrum與分享Scrum導入經驗。介紹Scrum這一點沒什麼問題,之前已經講過太多次了。但是,對於第一次接觸Scrum的鄉民們,Scrum導入經驗分享要講些什麼呢?想來想去,只想到四個字擁抱改變

現在讓我們來探討一下「產出」、「工時」、「效率」這三者的關係。

螢幕快照 2012-10-01 上午11.36.01

 

  • 工時:假設1個人1小時可以寫20行程式,1天工作8小時可以寫160行程式。那麼如果1天工作14個小時,就可以寫280行。因此,增加工時可以提升產量(請先對這句話持保留態度,因為需要有一些前提成立才可以能達到此目的)。
  • 效率:假設1個人1小時可以寫20行程式,如果可以想辦法將效率提升到1小時可以寫40行,這樣1天工作8小時就可以寫出320行。

***

接下來探討一下工時和效率兩者之前的關係。在固定的產出之下(例如寫完100行程式),增加效率則可以減少工時。至於工時和效率的關係,可以從兩方面來討論。

螢幕快照 2012-10-01 上午11.51.21

  • 增加工時會減少效率:一般而言增加工時應該是會減少效率,因為人的體力與專注力有限,而軟體開發又是需要腦力與專注力的活動。因此,增加工時,尤其是長時間增加工時,將會降低工作效率。例如,長時間加班很可能會導致開發人員無法專心、腦袋空轉,或是因為bug變多以致於抵銷因為增加工時所產生的生產力。更慘的是,可能因為bug變多,或是設計品質下降,經常需要rework。看起來好像每個人都很忙,但很多時間都在瞎忙。
  • 增加工時會增加效率:有些老闆或是主管會有一種想法,認為員工在上班時間無法把預計的事情做完,是因為員工個人「能力不足或是經驗不夠」。所以,「採用責任制,留下來免費加班」,補足員工個人的經驗並且提升員工的能力,這也是理所當然的啊。因此,增加工時可以讓員工增加經驗值,可以提升未來的工作效率。

說真的,以上兩種說法個別看起來好像都有點道理

***

由於提升效率需要牽涉到很多「公司制度與文化」還有「管理能力」、「人員聘雇與淘汰」、「教育訓練」等制度面的問題,實施起來並不容易且短期的成效可能不明顯。所以,很多公司為了提升產出,就採用最簡單、省錢、也最不花腦筋的方法,那就是:「上班打卡制,下班責任制」。

螢幕快照 2012-10-01 下午12.06.26

 

老闆內心獨白:因為提升效率好傷腦筋,所以就用同樣的方法做事(效率固定),只要增加工時,應該就可以有不同的好結果吧!

石滋宜內心獨白:什麼是笨?就是老是用同樣的方法做事,卻期待會有不同結果的人。

***

現在逆向思考一下:如果要在工時固定的前提之下,還要增加產出(競爭力),那怎麼辦?只有想盡辦法來提高效率才得以生存下去啊

螢幕快照 2012-10-01 下午12.14.40

 

提升效率的方法很多,Scrum可以做到的幾個重點:

螢幕快照 2012-10-01 下午12.20.39

***

看到Teddy提倡XP所說的「每週工作40小時」(按時下班)這種作法,可能有鄉民會認為Teddy是那種「不食人間煙火的理論派」。其實Teddy在年輕的時候,也是幾乎每天都加班。晚上11點才離開公司趕搭最後一班公車算是家常便飯,在公司過夜也不是什麼新鮮事。那時候Teddy也是想:「自己年輕,能力與經驗不足,所以多花一些時間來彌補這些不足」。但是,手邊的專案有準時上線嗎?軟體的品質有變好嗎?做出來的產品客戶滿意嗎?很遺憾,答案多半是否定的。

當年Teddy除了「傻傻加班」這個致命武器以外,Teddy也會花時間看書。在自己看了很多書之後,能力好像有提升一些,但是這樣的能力提升,要擴展到整個團隊身上,卻是非常的困難。因此,Teddy心中的小惡魔的聲音就越來越大聲:

小惡魔:為什麼自己做的那麼累,晚上11-12點才走,而底下的其他人卻「早早下班」(晚上7-8點左右)?

小惡魔:這隻程式明明那麼簡單,為什麼你寫了這麼久還沒寫完?

小惡魔:大家上班真的都有在好好工作嗎?

當這種負面的思慮充滿自己的腦袋之後,這個專案差不多就要注定失敗,團隊也可以準備解散了。

***

回頭看一下Teddy剛剛說提到「增加工時會增加效率」這個因素。這個因素不是不可能達到,但是「增加工時」並非讓員工「老是用同樣的方法做事,卻期待會有不同結果」,而是要思考:

如何在增加的工時中,提升自己的工作效率。

敏捷方法強調開發團隊要有「穩定的步調」。固定工時,短時間看似減少生產力,但其實好處多多:

  • 讓有企圖心的員工可以有時間可以去思考、讀書、進修、兼顧工作生活。
  • 可以鑑別出「守本分」(效率不動如山)的員工與「持續成長」的員工。(這一點很重要)
  • 提升員工法定工作時間的專注力。
  • 反映出專案的真正成本。
  • 暴露出公司與團隊的不足之處,以謀求改善之道。

最後再補充一點,工時不是不能增加,在特殊情況下,短時間內增加工時是可以提高生產力。但無止盡的長期加班只會導致員工「上班的時間都在生活(都在打混)」。生命會找到出路,員工也不是笨蛋啊。

***

友藏內心獨白:很多人其實很難接受「水清則無魚」這個現象。

10 則留言:

  1. 例如那種廣告活動類型的公司,當他們要做網站的時候,無論多少人、多少事,deadline就是deadline,時間內就是要完成,客戶在意的只有目標能否達成,不管甚麼工時與效率,如此一來真的能夠套用Scrum嗎? 我挺懷疑的! 可否請 Teddy 釋疑? 謝謝!

    回覆刪除
  2. Hi 鄉民:

    (1) 我想大部分的客戶,可能都不管施工廠商的『工時與效率』,只管時間到了東西有沒有生出來。
    (2) Teddy關於 Scrum 的經驗主要在於軟體開發,『廣告活動類型的公司』並非 Teddy 專長 (趕快撇清)。
    (3) 我這一篇的重點在於 (a) 先嘗試把工時固定,可以強迫團隊把『流程上』、『能力上』、『公司制度面』等等的問題給『暴露出來』(b) 各個行業、公司、團隊的工作模式不一樣,需要自己找出一個適合自己的方法。但如果只是一味增加工時希望員工可以產出更多的產品,而非把時間花在思考如何提昇效率,在『軟體開發產業』來說,是很危險的一件事。

    Teddy 的能力有限,無法包山包海涵蓋每一個不同的產業啦 XD。

    謝謝。

    回覆刪除
  3. Dear Teddy,

    謝謝你的迅速答覆 ^_^

    軟體團隊在研發的過程中多多少少都會有『流程上』、『能力上』、『公司制度面』等等的問題,我覺得整體來說應該就是【公司管理制度】的問題,公司制度跟不上新形態的開發模式,也是白搭。

    對於你所提出的「固定工時,短時間看似減少生產力,但其實好處多多」的部分,我希望能跟你好好激盪一番:

    * 讓有企圖心的員工可以有時間可以去思考、讀書、進修、兼顧工作生活。

    => 以我個人經驗,有企圖心的員工,願意主動思考、讀書、進修的人,恐怕是少數! 大部分的人都只想兼顧工作與生活,這沒甚麼不好,只是強調了這點可能會反而降低生產力,而且還可能拉不回來,尤其是當前台灣的資訊慘業。

    * 可以鑑別出「守本分」(效率不動如山)的員工與「持續成長」的員工。(這一點很重要)

    => 這一點我百分百認同,而且真的很重要,不過這也要公司的管理制度配合,有適當的激勵與懲罰才有效果。

    * 提升員工法定工作時間的專注力。

    => 專注力往往決定於團隊成員個人的自制力,公司不封鎖 FB, Plurk, Twitter, MSN, Skype, Weibo, LINE, WhatsApp, ... 通常都會讓部分成員分心導致降低生產力,阻擋了這些社交網路存取,又會引發民怨,或因為無法透過網路向外人求助而引來負面效應。

    * 反映出專案的真正成本。

    => 專案的真正成本光從工時來看根本算不準,因為變數非常多。開發效率高的團隊成員通常比團隊中最低的還高出好幾倍。

    * 暴露出公司與團隊的不足之處,以謀求改善之道。

    => 同意!

    ------

    在傳統公司裡,或非技術導向的公司,導入 Scrum 我覺得應該是遙遙無期。

    而在技術型的公司,「增加工時會增加效率」這一個假設前提我覺得是有問題的,應該沒多少公司或主管真的希望刻意增加工時以提升工作效率,往往都是因為專案 deadline 趕不上才會加班,大家都是為了特定目標趕工的,並不是為了提高工作效率。

    再者,如果團隊成員每個人都能自我要求、自我提升、晚上回家都會主動看書提升軟體開發過程中的工作效率,為了專案deadline大家都能提前把工作完成(因為工作效率已經提升),那主管怎麼還會想要求加班。

    往往是專案時程離死線越遠,大家的積極程度也會越低,這是人性。或許透過Scrum可以改善人性面的瑕疵,也讓大家離死線很遠的時候也能積極點,但這真的不是件簡單的事,Product Owner 與 Scrum Master 對團隊的運作舉足輕重,一個不小心還可能會毀了一個團隊原本能有的產值,或許原本因為特定目標偶爾加班硬撐出來不錯的產能,但若因為 PO 與 SM 管理不當而導致團隊氣氛爬不起來,大家在趕工時又不願意加班,目標也不可能達成。當這種團隊氣氛蔓延至所有人身上,這個專案也差不多就要注定失敗,團隊也可以準備解散了。

    回覆刪除
  4. Hi 鄉民:

    難得有鄉民願意發表這個長篇的寶貴意見,太感動了。

    => 以我個人經驗,有企圖心的員工,願意主動思考、讀書、進修的人,恐怕是少數! 大部分的人都只想兼顧工作與生活,這沒甚麼不好,只是強調了這點可能會反而降低生產力,而且還可能拉不回來,尤其是當前台灣的資訊慘業。

    我也同意這些人不是多數,但是由於『齊頭式的加班文化』,讓這些人無法利用時間去培養實力,只會讓團隊的士氣與能力停滯不前 (明明沒事了卻不可以下班,還要在公司裡面假裝有事做)。

    ***

    * 可以鑑別出「守本分」(效率不動如山)的員工與「持續成長」的員工。(這一點很重要)

    => 這一點我百分百認同,而且真的很重要,不過這也要公司的管理制度配合,有適當的激勵與懲罰才有效果。

    當然很多事情是要公司制度的配合。Scrum 好的地方,只要你自己真的試過,就像是一面『照妖鏡』,好的、不好的都會被照出來。想打混的人會無所遁形,箇中巧妙之處真的要實施過就知曉 XD。

    ***

    => 專注力往往決定於團隊成員個人的自制力,公司不封鎖 FB, Plurk, Twitter, MSN, Skype, Weibo, LINE, WhatsApp, ... 通常都會讓部分成員分心導致降低生產力,阻擋了這些社交網路存取,又會引發民怨,或因為無法透過網路向外人求助而引來負面效應。

    個人自制力當然是專注力的基礎,但是很多時候,專注力會被很多『事件』給打斷。流程不順、跨部門溝通、回不完的無意義email、打嘴砲、無意識但定期會發生的會議、皇親貴族與大臣們的亂入...等等等,這些都不是光靠『個人自制力』可以應付的。

    我好像扯太遠了,原本我想說的只是:『經常性加班,隔天上班會很沒精神啦』。

    ***

    * 反映出專案的真正成本。

    => 專案的真正成本光從工時來看根本算不準,因為變數非常多。開發效率高的團隊成員通常比團隊中最低的還高出好幾倍。

    基本上我覺得軟體開發計畫,最大的成本應該就是開發團隊的時間,也就是工時。開發效率高的團隊成員通常比團隊中最低的還高出好幾倍,這我絕對同意,所以高效率的團隊所需的工時會比較短。但是『理稐上』公司付給高效率團隊的總薪資應該會比低效率團隊要要。我想講的是,一般軟體專案應該還是依據人/時來計算費用。

    ***

    我個人覺得,要不要導入 Scrum其實不是重點,重點是:
    (1) 一個公司認不認為自己需要改變?
    (2) 如果需要,有沒有推動變革的勇氣與決心?

    如果以上兩點都成立,要導入什麼『東東』,就看產業別的需要。

    任何改變都是困難的,有時候需要摸著石子過河的勇氣與決心啊。

    報告完畢。



    回覆刪除
  5. Dear Teddy,

    多謝回答 ^_^

    以下幾點討論:

    1. Scrum 我 Run 過,的確如您所說像一面『照妖鏡』,好的、不好的都會被照出來,沒實力又沒人緣的人的確很快就會被逼走。但沒實力(或沒生產力)又有人緣的人(例如很努力工作+每天加班),就會留在團隊裡,大家會幫助他快速成長,這些的確都是好處。但是 Product Owner 不斷面對客戶(擔心Scrum會帶來時程無法掌控的莫名壓力)與內部成員(期望Scrum給他們帶來的好處)的雙重壓力,讓他越做越辛苦,直到放棄!關於這點是否有好的方法?

    2. 專注力提升真的很難,光是公司裡的電話與其他雜務干擾,真的很難進入神馳狀態!你這有好方法嗎? ^^

    3. 軟體專案成本的確跟開發團隊的時間(工時)有很大關係,但客戶打從一開始在需求不明確時就要求團隊評估出工時,Product Owner 真的很為難,對上要對預估工時有所交代,對下要讓團隊接受客戶期待的工時,當兩邊喬不攏的時候,一樣會怨聲載道。你如何面對這種困境?


    你的最後兩個重點:
    (1) 一個公司認不認為自己需要改變?
    =>通常是需要的!因為問題一直存在!

    (2) 如果需要,有沒有推動變革的勇氣與決心?
    =>勇氣不是沒有,嘗試過後,PO 被客戶幹譙個半死,專案結束後成員全數離職,其實跟決心改革前好像還更糟糕,我們是真的很用心跑了一段時間,專案成員各個十分團結,也頗認同Scrum,但公司卻沒有好下場。不知道耶,可能是我太悲觀吧,一次失敗經驗就嚇到了,也許不適合用在【非產品研發】類型的公司吧。不知道你有何見解?

    我知道任何改變都是困難的,有時候摸著石子過河,是會沉的。 XD

    謝謝!^_^

    回覆刪除
  6. 不好意思,不是要跟你打筆仗啦,真心想跟你腦力激盪一下,我真的很想重拾 Scrum 的懷抱。 ^^

    回覆刪除
  7. Hi 鄉民:

    我昨天一整天都在台南,所以沒有時間回覆你。

    1. 但是 Product Owner 不斷面對客戶(擔心Scrum會帶來時程無法掌控的莫名壓力)與內部成員(期望Scrum給他們帶來的好處)的雙重壓力,讓他越做越辛苦,直到放棄!關於這點是否有好的方法?

    ==>『擔心Scrum會帶來時程無法掌控的莫名壓力』剛好跟我的經驗相反,在團隊剛開始導入 Scrum 的時候,的確可能會有3-6個月的適應期,在這一段時間之內,團隊的產出會有起起伏伏,比較不穩定的情況。但等團隊上手之後,我的經驗是,時程反而比較容易掌握。

    我覺得答案很簡單,就是你沒以沒找到一個好的 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。

    就這樣進行了6個月,Teddy 才覺得慢慢把團隊給帶起來。以上經驗提供你參考一下。

    回覆刪除
  8. Dear Teddy,

    非常感謝你的回答,對我幫助很大! 謝謝!!

    ^_^

    回覆刪除
  9. Dear Teddy,

    非常感謝你的回答,對我幫助很大! 謝謝!!

    ^_^

    回覆刪除
  10. 一篇不錯的文章分享:
    <頭腦>轉得又快又順而去做的一天能做許多事。
    http://blog.udn.com/oyt0915/31932271

    回覆刪除