持續改善的迷失

.

持續改善.png

持續改善可以依循的模式

.

避免局部優化

我們常常以為持續改善就是朝著越變越好的方向前進,但其實;它就像學習一項新技能一樣,一開始總是會有表現的不到位的時候,也就是沒有加分反而變差,就像登山一般,從一個山峰到另一個山峰總是要透過相連的山谷一般,迂回前進是不變的道理。所以它跟我們想像中的『預測模式是不同的,如上圖中央的部分,我們很容易以線性的思維去預期達成目標的途徑。當然我們可以設定更高的目標追求更好的未來,然後靠努力的實踐朝著目標去前進,這是好的。但容易誤以為它是一種線性的現象,而造成了一種局部優化的結果,忽略了改變的過程,全貌一定會有波峰及波谷高高低低的起伏,歷程是挫折與成功兼併的,過程中我們是必須經歷一些失敗才可能有成長的機會的。

.

持續改善要避免線性的思維,而產生局部優化的現象。

.

適應是響應式的

適應是響應式的,用來響應環境的變化,屬於由外往內的改變形式。它是被動的。

.

預測是主動式的

既是持續改善自然是設定更高的目標,往往大家會思考以漸進式的;一種緩和的模式去實踐它,但若遇到需要創新式的突破時,這個時候勢必要採取一種全然不同的模式來進行持續改善(而非精實開發中的逐漸改善方式),在《管理3.0》書裏頭稱之為激進創新式的改善方式。也就是改善方式應該視目標距離作調整,將情境考慮進來,當距離較遠、需要創新理念時,或許該考慮較激進的跳躍方式,這正是三步工作法所謂的在失敗中前進的模式。

.

探索是交互式的

採取部分或完全不同於以往的作法,希望以不同的工作方式來增加對目標的體驗,不預設結果,端視狀態的變化作好度量及應變。收穫是體驗效果,不是因為環境也不是設想好的結果。

.

Technical Debt.png

探究技術債的影響

.

為技術債 Technical Debt留下足跡

為了求快,我們在開發上犧牲了選擇最佳解的作法,在設計上做了妥協,便累積下了開發上的負擔,便是所謂的「技術債」。結果是造成系統複雜度的提升,使得開發速度變得緩慢下來。它的由來可能是為了及時完成有期限的專案,或是程式員違反了開發規範,沒有依循開發規範而選擇了捷徑,自然累積下了開發速度變慢的因素。

做紀錄;要為技術債 Technical Debt留下足跡,以便於持續改善。凡是遇到有期限的開發工作或是程序員想走捷徑時(有時這種權宜是正向的),就應該立即開立技術債單據,記下時間、源由並寫下估算值,預估會產生多少工作量,然後貼到工作看板上的待解決工作區去,待團隊進行 回顧會議 時再拿出來做檢討(修正時數,統計負債額度)。運用負債額度來決定償還的時機。

.

結語

精實方法與 DevOps 都教我們要持續改善,一再強調它的重要性,但「持續改善」在字面上容易造成人們的誤解,讓人容易以一種緩和的方式去進行改善作業(雖然這麼作並沒有錯),但團隊成員沒有因為可以明確體驗到這麼作的效果而失去了激勵的效果,成果也因此而縮水了。成為奉行持續改善的迷失者,因此這裡陳列了三種實行持續改的實施模式;分別是適應、預測和探索模式(參考自Jurgen Appleo的管理3.0,第15章如何進行全面改進),希望大家在進行持續改善之前能先看清楚自身的位置,運用看見全貌的系統思維來思考改進的策略。

.

0036.png

全貌是變動的,看見全貌只是以一種約束的方式來讓自己更容易知道自己的所在

.

0037.png

確認自己在哪兒,才能看出問題的真正意義

.

 

持續改善的秘訣

治標還是治本: 另類的改善

我經常到處演講或作顧問,空閒的時候就拚命看書,哈哈!是真的用拚命的方式在追求知識。新知或較舊的新知都有,太多太吸引人的知識了,看著看著常常會引發你無限的連想,就這樣把半天、一天給耗掉了。有時我會好奇,為什麼上一次的顧問案自己沒能先看到這篇文章或想到用這種方法呢?!總是事後才找到好的解答,真是太愚蠢了。有一種想要再重作一次的衝動,但有趣的是,很少有完全一樣的情形可以把剛剛學到的經驗再來一次的機會。所以呢!只好把它寫下來了,寫下來或許還有機會幫到別人。

“顧問案"就是想辦法解決問題,把已經形成的問題化解掉,有時它是可以度量的,但許多情形根本沒得評估,業主也不曉得我們作了半天的成果,只知道看不到問題了(其實看不到才可怕,看到了才有機會治本,例如: 看板方法就是藉由視覺化的方式,一直在想辦法看到阻礙,然後再針對阻礙來做改善的一種持續改善的過程),更別談後續要怎麼銜接了! 其實,顧問案的後續動作才是治根,剛剛渡過的危機是治標的行為。但是;主管們,你真正該在意的是後續,只是很少很少有主管來跟我談後續該如何如何處理。一般就是謝謝,再聯絡! 不幸的是很少有再聯絡的。他們很少想到,這一趟顧問之後,我又學到了多少經驗,下一回再來的話,一定會更好的(投資報酬率會好上許多的)! 但,大多都沒有下一回了。

所以我總是喜歡留一手(別誤會了,留一手是指留下許多路徑,讓有興趣的工程師可以有所依循的),留下一些足跡讓團隊有許多改善的機會,那些送書的行為也是製造這種改善機會的一種方法。

.

改善的密訣 : 人跟流程

救急的時候通常只有事,為什麼會發生這種事! 應該怎麼來處理。何時可以處裡完畢…。當下,解決問題才是當務之急。但是真正產生問題的是人跟流程。一旦問題消失了,接著該處理的就是流程了。這一點很有趣,明明人才是最大的問題但偏偏必須留到最後才能處理,而通常你也沒有能力做到的,即使做到了,你也沒得知道結果。

.

怎麼處理流程的問題呢? 我的決定一向就是朝品質的方向做決策。這是不敗的原則,一般專案總因為時間的不足,就輕易的選擇犧牲品質,所以有很多決策都只為了快,快一點得到產品,快一點上市,快一點賺到錢。為了求快而偏離了正確的方向,所以該做的第一件事就是保證品質,讓產品或程式變得勘用,勘用才是不敗之地,只有勘用了它才值得我們去維護,所以就成了「從品質開始」。也就是;處理流程的問題就從品質開始。

怎麼處理人的問題呢? 只有少數的機會讓我有時間處理人的問題。人要如何來改善呢? 有一回雇主希望我跟所有部門的工程師一個一個進行面談,這真是千載難得的機會! 但我不知道工程師的心理是怎麼想的,所以我做面談時的第一句話是: 「我是來幫你的」。我們就從你的人生規劃開始談起吧! 在長年的顧問日子裡,我發覺只有當公司給予你的任務跟你的人生方向有越多交集時,工程師工作的效果才會越好。若能夠說服工程師在處理手上任務的短暫日子裡,能夠立志並全力以赴,大家才有雙贏的機會。

 

一種成功的秘訣 by David J. Anderson

跟大家分享我演講時常常引用的看板之父 David J. Anderson 的成功敏捷化的秘訣(A recipe for success)六步驟:

  • 專注於質量。
  • 減少進行中的工作 WIP。
  • 頻繁交付。
  • 根據交付速率(throughput)來平衡需求(demand)請求量。
  • 進行優先及排序。
  • 消除變異性的根源,提升可預測性。

(這一段資料在 Anderson 所著的"看板方法" 一書的第三章成功敏捷化的秘訣中)

.

能夠持續改善的秘訣是持續的看到成果,用成果做動力來推著自己持續前進。

成果就是預設的目標達成了。

所以要先設定目標,才可能持續改善。

.