心態是組織變革的關鍵

想要改變結果，就要改變讓你如此行事的心態.

主管的心態形成他的行為，被團隊解讀之後產生團隊的行為

.

心態是你的作業系統 (註1)

心態(mindset)就是你的思維和情緒，它們是一個人的底層作業系統。而人的心態就好比電腦的作業系統一樣，電腦需要作業系統才能運作，人的心態也是如此，你用它來產生行為並獲取結果。它掌控了你的決策、發言與提問。就像作業系統一樣，心態讓你快速輕鬆巧妙的採取各種行動，它的動作取決於你的核心價值與假設來設計行成你的行為，讓你能夠即刻行動，不用花太多時間去思考就做出種種反應，這都是靠心態所為。

 

當你遭遇問題時的反應，正是你的心態對問題快速解讀之後的反應，只是它居於後台，拿電腦作比喻，我們所表現出來的行為，則可以表述為被呼叫到的應用軟體，它們透過執行特定的應用程式來達成任務，而作業系統則負責後勤支援的服務。我們都知道過時的作業系統是很難跑得動新的應用程式的(組織實行新政策也是如此)，所以我們需要定期更新作業系統，而人的心態與行為也是如此，有時你想要改變行為以追求更好的結果，此時你必須更新你的作業系統，也就是要改變你的心態才是最有效的解法，才可以跑得動新的應用程式讓它能運行順暢。這個比喻就好像我們為了改善團隊的績效，採用了新的策略來解決問題，改變作了但卻遲遲不見成效，或是始終不能順暢的推行起來，其實是作業系統需要先做更新了，你怎能期待原先(舊的)作業系統能跑得動新的應用程式呢? 你的作業系統需要更新，也就是說是你需要改變心態了。

什麼是心態mindset？mindset就是你思考問題的方式。

常常聽見人們後悔地說：『哎呀，我要是當年多買幾套房就好了』。但如果現在有同樣的投資機會他還是會錯過的。這就是因為一個人的思維模式沒有改變他所做的決定其實和之前都是會一樣的。

.

組織變革；心態需要先做更新。

-羅傑.史瓦茲 Roger Schwarz.

.

. 心態 (圖一) .

. 行為 (圖二).

. 表現出來的 – 績效 (圖三) .

圖一、二、三即著名的「相互學習模式」

組織變革；需要先更新心態

心態要更新；應該要先更新領導者的心態? 還是先更新團隊的心態呢? 《打造卓越領導力》一書的作者羅傑.史瓦茲建議，應該是一起改變才是，也就是相互學習(mutual learning)的心態，具體的做法呈現在上圖中，先是心態改變(圖一)導致行為(圖二)的改變，最後帶來績效(圖三)的變化。

 

組織變革；說穿了就是想要改變團隊開發作業的結果，而要改變開發作業結果，就要改變讓你如此行事的心態，如果心態不變，又怎能期待再做一次時會有不同的結果呢?

.

人在生活環境改變時，首先要改變的是你(妳)的心態

.

基因影響我們的聰明才智與天賦，但影響一個人成功與否的特質，卻並非在出生時就固定。心態，才是影響個人學習、成長、人際關係、終身成就、人生道路的最重要關鍵。

卡蘿．杜維 Carol S. Dweck

.

小結

實行敏捷變革要從哪裡開始呢? 外商公司的習慣是換一組人來負責，或是以置換負責人的方式來做起手式，(一種換人做做看的理念)新人新氣象也自然讓人容易期待好的改變的到來。但中國公司就不一樣了，我們總是以改變組織的結構(合併或拆散重組一下團隊)或是引入新的方法論(Scrum、DevOps…)，只做事的調整，沒做人的調整，就希望在重組的情形下能夠產生好的結果，一種換湯不換藥的改組形式。也顯現出中國企業容易鄉愿的心態，把這整個現象歸咎於人情味濃也可以說得過去，其實基本上是文化的因素所造成的差異，但它並不是變革成敗的關鍵因素，在鄉愿的心態下我們依然能夠變革成功的。

因為變革成敗的一個重點在領導者的心態是否真的改變了，因為一個領導者心態的轉變，將容易造成整個組織文化的改變，因而影響到團隊行為的變遷，也就是上面第一張圖所顯示的，主管的心態形成了他的行為，而主管的行為被團隊解讀之後產生了團隊的行為，團隊的行為表現又看在主管眼裡加強了主管的心態改變，形成一種交互的循環，對於敏捷而言；正向的循環是採用相互學習模式，負向的循環則是採用了傳統的單向控制模式(註1)。因此組織進行變革，首先要改變主管的心態，而心態正是改變領導方式的關鍵。

 

.

勤於練習的心態

從小到大，我們在不斷試錯、學習新事物、練習新技能的過程中成長起來。人生中值得去做的每一件事情，都需要練習。但隨著年齡的增長，我們漸漸失去了“練習的心態”，許多練習過程變成一種痛苦和煎熬：我們只盯著目標和成績，內心充滿壓力和焦慮，因此在學習一項新技能時，經常剛開始就放棄，或者面對生活或工作的挑戰，無法耐心又專心地應對。

要知道；適當的練習不是苦差事，而是一個有意義的過程，可以幫助你發展出耐心、專注與自律這樣看似難以獲得的優秀品質。

湯瑪斯 M.斯特納 Thomas M. Sterner

.

如何改變心態

要想改變心態可能比實際上所想像的還要困難，如果想要因為組織結構改變了就能夠逼迫自己改變行事作風的話，效果或許要很久很久甚至永遠都不會到來，另外一個方法是開始改變自己與團隊產生行為與結構的心態。起手式是先去理解自己的心態，了解自己為什麼會陷入困境，理解自己為何在無意中讓團隊陷入困境的決策，同時思考接下來該如何脫困呢。動作是設法去更新你的作業系統，讓它能夠適應將要到來的改變，怎麼做呢? 答案是相互學習。藉由向他人學習和與他人共同學習來達成目標。羅傑.史瓦茲 Roger Schwarz有五個自我心態的假設提供我們參考(在你開始批評或懷疑他人的言行之前，請先思考):

• 我有資訊，別人也有資訊。
• 人人都會看到別人沒看到的資訊。
• 別人就算和我意見不同，仍然可能動機純正。
• 意見不同是學習的機會。
• 問題可能是我自己造成的。

《心態致勝》作者卡蘿.杜維克博士則提供(謝文憲老師整理出來的TMDS原則):

1. 你的事,就是我的事。Team Work and Trust 
2. 運用並管理資源。Manage Resources
3. 讓夥伴參與決策。Decision Making
4. 分擔責任與共享領導。Share responsibility and leadership

 

【註】參考:

1. 羅傑.史瓦茲Roger Schwarz所著的《打造卓越領導力》
2. 卡蘿．杜維 Carol S. Dweck 所著的《心態致勝》
3. 湯瑪斯 M.斯特納 Thomas M. Sterner 《練習心態》
4.  Mindset 心態、思維模式，例如: 著名的 《心態致勝》，簡體譯成:《終身成長》mindset=思維模式.

 

在不自在的情境下，自在地工作著

. 生活免不了種種的約束.

顧問工作；就是要在不自在的情境下，自在的工作著，

而團隊開發也是如此。

.

不自在；這句話會讓你聯想到什麼呢?

是不是想到一些讓你覺得臉紅的情境、讓你覺得尷尬的場面? 假設；這個時候你是在一個完全沒有人在的環境下，你還會覺得尷尬嗎? 如果一旁的人都是你的死黨、好友，一些無條件支持你的朋友，你還會覺得尷尬嗎?

 

讓我們來想一下；是什麼因素讓你覺得不再尷尬的呢? 它是一種自在的環境，它讓你的心裡覺得自己受保護著，沒有人會瞧不起你，不懂，沒有人會譏笑你，是這種感覺讓你卸下了心防，自然而然地你就不會再覺得不自在了! 而這種不會不自在的感覺，正足以開啟你快速學習的能力，它就稱為覺察性(Awareness)，它開啟快速學習之門。

 

自在的學習，在這種情境下，你會成長的最快

暴露自己不會的技能(技術)會讓你覺得尷尬、不自在，即便你的團隊就在身旁，那裡有許多人你可以請教，很快就能找到答案迅速就能弄清楚問題，但你還是會覺得不自在，因為這項技能你還不會。但實際上；你並不在乎，因為在你周圍的都是你的夥伴，這讓你能靜下心來，然後自在地工作著。這便是這句話的意義:

.

在不自在的情境下，自在地工作著

.

是這種心境讓你打開了束縛，所以你能盡情地去學習。因為你放掉了那些限制你成長的壓力因素，所以覺察力(Awareness)在這裡提升了起來，你可以沒有太多顧忌的工作著，學習效果便大大的提升了。這正是一個敏捷團隊所要追求的工作環境。工程師們不必要掩飾那些自己所不會或不足的地方，因為不會覺得尷尬，不必擔心被敲不起，所以打開了心智，讓自己很容易沉浸在學習的愉悅中，自然的提升了學習的效果。

 

顧問工作；就是要在不自在的情境下，自在的工作著

企業遇到自己無法解決的問題時就會想到要找顧問，因此顧問總是在最不好的時候出現，我們的工作要求自己要盡量的低調，最好是在完全不影響團隊的日常作業下就能看出問題，問題經確認後接著還要冷靜的分析並找到具體的解法。所以我們的服務來的快去得也快，工作時間很短暫，從熟悉環境、認識人員到識別問題，然後撰寫分析報告，從說服業者解題的方式到真正解題，通常會在二周到一個月的時間內，就告結束了。我們必須一直跟一堆問題相處，就是要在哪種不自在的情境下，盡量自在的工作著。這句話聽起來有一點繞口，也好像不太合乎邏輯，但這就是我的工作。有趣的是，我作診斷的方法，正是找出組織裡有那些是不合邏輯的地方，而通常那就是問題所在。

 

一般而言，都是老闆或主管找我們來作顧問的，所以團隊的配合度通常都很高，大家都很容易相處，但如果開始有那種不信任的味道出現時，通常也意味著你無法在自在的工作著了，也就是顧問工作要結束了。這種事情常會發生也經常由不得你，你也很難有扭轉的機會，因此顧問與團隊間的信任度相當的重要，有時還要更勝於主管與團隊間的互信。所以更要開誠布公。因為只有徹底的透明方可以減少那些無謂的猜疑。

.

主管「開誠布公」可以讓成員了解你，而心懷「好奇」則可以讓你了解成員。

– Roger Schwarz

.

如何才能製造出這種工作環境呢?

這是一種信任的信念，它讓你不在意也不認為自己會遭受到周遭人士的譏笑，所以就 open mind 了。這個道理一點也不難，就是設法建立一個能夠互相信任的團隊環境，身處在這樣子工作環境下的工程師自然能夠自在的工作與學習著。因為專案處理的過程其實就是一種學習的過程，工程師學習得越快曲線就越陡峭(中間那條藍色的一點鏈線，綠色虛線是PO的知識取線)，開發時程也就縮短了。因此我們要追求團隊能夠快速地學習。

.

工程師學習得越快曲線就越陡峭，開發速度也就越快

.

工程師必須迅速學會專案的 Domain Know how

年輕的工程師常把做專案時的精力集中在程式開發的技巧上，希望盡快追上流行中的新技術。但資深工程師都知道；工程師就是要隨著專案的專業知識，想寫什麼就要學什麼，學得越好越快程式就會寫得越吻合客戶的需求，學習的速度影響著專案開發的速度。上面那張圖示就在說明這個道理。中間那條藍色的一點鏈線是程式設計人員對需求的了解曲線，他上升的快也下來的很快(因為工程師若僅僅是為了開發程式而學習並沒有實際去運用它，快速學來的知識便會很快的退去)，而綠色虛線則是專案PO的知識曲線，它始終維持在一定的程度上。

 

在新專案啟動時，由於負責開發的團隊必須從新學會 Domain know how，弄懂了該領域的知識才有能力開始寫程式，因此那條藍色的一點鏈線開始的起始點總是很低，也就是說團隊在第一次開發全新軟體時，總是居於專業know how不足的清況下開始學習的，就是處於處處必須向人詢問、求助的尷尬情境下，此時主管是否能協助團隊製造出一個在不自在情境下，能夠自在工作的環境，便成了協助團隊快速學習的關鍵因素，對照到上面的圖示，就是協助團隊盡快到達 Ready 的狀態(綠色的圓圈)，這個 Ready 點；對需求而言稱為「定義完備」(Definition of ready)，對於工程師而言則是具備了足夠開始開發該軟體的專業知識，稱之為「基本的專業知識」(Basic domain know how)。這便是軟體工程師的工作歷程，正是所謂的「軟體開發實際上就是一場學習的歷程」，學習得越快專案就開發的越快。因此能否讓團隊「在不自在的情境下，自在地工作著」便成為加快團隊學習能量的重要因素了。

.

小結

你的信念成就你的行事風格，而你對事情的覺察性則決定了學習的品質。覺察性(Awareness) 會深受你是否對事情產生興趣所影響，也就是說你必須先產生興趣才可能從學習中產生樂趣，而這一點決定了你對這件事情的覺察性的高低。覺察性是一種態度，它會受到你(所接觸的種種)環境所影響，而程式開發總是會遇到你比較熟悉跟比較不熟悉的技術，工程師必須秉持著開放的觀念，不因為不懂而害怕被譏笑就裝懂(隱藏自己所不了解的事)，也就是不懂裝懂不敢提問，要知道沒有人生下來就什麼都知道的，那些很厲害的人物其實也都是從不懂過渡到懂的，只是他們學得特別快而已，而如何快速的學會，重點便在能否自在的處於學習的狀態，團隊在進行開發工作時學習是一件很重要的事，是主管的責任也是團隊共同的事，因此能否營造一個讓團隊能夠「在不自在的情境下(不去隱藏自己所不懂的事)，自在地工作著(快速的學習)」便是一件對團隊開發至關重要的事。

.

團隊成員彼此之間的信任度，決定了你是否能夠

在不自在的情境下，自在地工作著。

.

將經驗轉換為能力

. 經驗是不會自己落實成為知識的

大衛庫伯 David Kolb 的經驗學習環(1968)

.

David Kolb :『知識的獲取源於對經驗的昇華和理論化』.

.

反覆的嘗試，不見得帶來高品質的認知

小時候；因為不擅於背誦課文，因此經常被罰站在教室後面，所以只要第二天有課文要背我就會愁眉苦臉，媽媽見狀跟我說:「只要反覆唸上100次你就會記得了」。我一點也不懷疑拿著課本就到廁所去唸了100回。然後呢? 結果還是背不起來， 母親就再問我，是哪幾段讓你背不起來的呢? 我便在課文旁邊把它們一一畫出來唸給她聽，母親不厭其煩的把它們的意思解釋了一遍又一遍，說也奇怪，聽完它們的意思後，哪個段落就很順暢的背起來了。現在回想起來，是因為弄懂了那段文字的意義，便自然地把它們串接了起來，也就很快的背起來了。

 

經驗必須透過反思觀察，形成概念和推論，並在新情境中再去嘗試之後才會轉化為知識的，這是一種循環的過程(單純的只是去唸上100遍是無用的)。上圖是大衛庫伯David Kolb 著名的經驗學習理論(Experiential Learning Theory)。庫伯將學習的過程分為四個階段，包括具體經驗(Concrete Experience)、省思觀察(Reflective Observation)、抽象概念(Abstract Conceptualization)與主動驗證(Active Experiment)，這四個階段形成一個循環的學習過程，不斷的重複，使得知識更為精進落實並內化為我們的底層認知，因此成為我們遇事情時成為自己行事的依據(又稱為經驗學習環)。

.

人生就是一直不斷的解題的過程

.

人生便是一場不斷的解題過程

我們每個人，對這個世界都有自己的解讀方式。我們會依靠自己的經驗判斷產生不同的行事方式。這是透過經驗所累積起來的，它會因人而異而且深淺不同，只要不出問題，人們會傾向於持續採用這樣一套屬於自己的行事體系的。這便是我們經常聽到的，所謂的「底層認知」的問題。

 

底層認知(Underlying Cognition)是指可以隨著我們的學習而一直保持更新的基本認知。你怎麼學習，或者學了哪方面的知識理論，它便會對你底層認知的信念體系產生一種改變的作用。這正是心理學界所說的: 「改變你的信念，你才能夠改變你自己，改變你的生活。」

.

你學習哪方面的知識理論，它便會對你認知的信念產生一種改變的作用。

.

我們的成長過成，不管你是有意識地或是無意識的在處理各種問題，其實就是在持續改變你的底層認知。著名的貝尼斯定理說道: 「一個人的成長，有70%的能力提高是來自於實際工作當中，20%是來自於向他人學習，10%是來自於正式的培訓。」這一點說明了我們的知識大都來自於工作上的經驗累積。因此優化這一過程，就會優化你的學習成果。

.

覺察與責任感是啟動我們開始學習的重要因素

.

抱著學習的態度去感受每一次體驗可以幫助我們吸取教訓。這種學習風格帶給你的也許不是最輕鬆的生活，但是長期來看，將是最明智的。

-生活即學習

.

我們何時才真正開始學習的

在任何活動中，覺察力(Awareness)和責任感(Responsibility)是最重要的二種學習特質(註1. 《高績效教練》)。這二者都是一種態度，一種無形中影響你在經歷過程是否成功學習的態度，它凌駕於技術之上成為你學習效果好壞的重要因素。當我們擁有高的覺察性時，它將會提高我們的學習品質，而當我們擁有較重的責任感時，它將會提升我們的績效與自制力。責任感越重，對自己的要求也就相對的越高，目標自然就會訂得越高而更職級的具有自我督促的能力。這二者都是影響我們績效好壞的重要因素。

 

要如何才能學得更好呢?

其一、主動學習: 正是所謂的；動機是學習任何技能的第一步。而這動機來自於我們自己所賦予該項事物的價值與意義時，我們自然而然會更用心地去學習。第二、寓教於樂:在團隊的日常活動中能夠融合於娛樂中自然會減少人們對反覆的事務產生厭煩的感覺。例如: 我們常見的運用園遊會的方式來召開檢核會議。第三、學以致用: 指的是讓團隊把學習到的東西拿來運用。正所謂適切的學習，更能激發大家的學習興趣。例如在更新新技術時，先進行研習該項技術的讀書會方式，就會有事半功倍的效果。

.

科技日新月異，我們需要學得更好更快。

.

增強個人「底層認知」的有效方法:

是找出自己不足的地方，然後針對它加以學習、改善。

.

團隊在變革之前，應該先探討我們要解決什麼問題?

行事之前先弄清楚WHY? 也就是找到真正的問題。我們都知道客戶不一定知道自己要的是什麼? 但卻在描述需求的時候嘗試著去找自己的解答，答案自然是不專業的，也有可能模糊或誤導了真正的問題，客戶所描述的可能只是諸多現象中的一個，真正的問題你得自己弄清楚。因此無論在任何情況下，先探詢真正的問題永遠是解題之前的首要步驟。 尤其是在組織的變革中，在上位的主管對組織所面臨的問題與一線主管，就是那些直接面對問題的實務人員之間，他們之間可能在對問題的認知上有著相當大的差距。因此精實體系在探討真正的問題時，總是選擇由一線主管開始檢討起。

但說真的我們不可能把每一套的行事體系都學得非常完美；所以只要是能適合團隊運行，而且能夠起作用，基本上這就是好的行事體系。

.

將經驗學習環運用在團隊學習中

.

團隊學習的經驗學習環

Kolb認為經驗學習是一個動態的學習模式，它可以用來描述個人也是用於團體與組織之間的學習與發展模式。上圖右側是參考中華體驗學習發展協會的體驗學習環，描述的是修正後的經驗學習環(稱為體驗學習環)。與kolb教授的四步驟學習環並無太大差異，除此之外在過程上增加了What /now what/ so what的對於品質及衡量的質疑態度，並強調了它所產生的意義。

 

左側我加入了組織在變革中所可能採用的有形的措施，及無形的人的改變二部分。有形的措施我們可以由新的組織架構圖或是制度改變而看得見。但無形的部分；也就是在人的心理層面上，團隊的成員必須有所覺察Awareness自己在此次組織變革下的改變，並願意接受且承擔新增的責任劃分，變革才算真正的成功。

.

電影Inception的任務，改變費雪繼承父業的信念

.

結語

上圖可分成三層來描述，最上層是繼承者羅勃·費雪(Robert Fischer)右側是他父親已故的莫瑞斯·費雪(Maurice Fischer)，電影描述了父子之間有著相當的不睦情節。最下層顯示的是保險箱及羅勃·費雪以為的密碼；裡面放的是父親過逝的遺囑。中間層；顯示了保險箱打開後的內容，上層是遺囑、下層是羅勃·費雪小時候做的風車。這一幕；完全是羅勃·費雪自己所想像出來的，重點是要借助這一幕；強調父親將風車與遺囑放在一起，一樣重視它們的情節來詮釋對他的期望。藉此改變他的信念反過來選擇放棄繼承，並建立、決定開創自己事業的決心。這一點印證了心理學所謂的:「要改變你的信念，才能改變你自己」。

 

我們把相同的理念運用在組織的變革上，也就是團隊成員要能夠改變自己的信念，才能在變革時改變自己。而自我改善的要素則是提升「覺察性」與加深「責任感」，藉由改變這二種態度，讓自己處在組織變革的時後能夠學到最多。

.

一段來自 Devid Kolb 的詮釋說明

.

註

1. 經驗學習環 ( 體驗學習環 )
2.  經驗學習環的簡史
3. 參考書籍: 學習圈操作手冊：組織修練手法與案例分享

KPTA 回顧法

一個基於持續改善的回顧方法.

.

成功的串連回顧會議中的待改善、改進事項

.

在閱讀天野勝先生的《最快最短完成目標的OKR【圖解實踐版】》一書時看到KPTA回顧法，它被用來做為團隊運行OKR時的回顧會議使用，是一種持續改善的工具。殊不知拿它來用在SCRUM的回顧會議中，可以具象化待改進的事項(有一張可見的工作單)，雖然它不能被用來估時，像一般任務一樣被某個團隊成員拿來當成工作任務一般地完成。但它卻是大家的共同課題，每個人都可以在衝刺周期中運用閱讀、討論或其他可以達到改進效果的方式來完成(是一張所有人都要簽名的工作單)。也應該加入到每個人在這個 Sprint 中的基本工作，並在看板上從待辦事項欄一直移動到完成欄位。我稱它是一種「課題卡」，是團隊所有成員都必須花工夫去完成的課題。然後在下一次的回顧會議裡拿出來做檢討，是完成了還是待繼續改善。這一點可拿來彌補Scrum團隊在回顧會議裡經常是討論的有聲有色的議題，卻未曾在正常工作中予以有形的改善的缺失。說明如下跟大家分享。

.

圖一、第一次招開的KPTA回顧會議

.

第一次的 KPTA回顧步驟如下:

1. 列出Keep: 也就是寫出團隊覺得值得維持繼續這樣做的事項。
2. 列出Problem: 就是覺得做得不滿意，或還有進步空間的事項。
3. 列出Try: 針對 Keep所提出的，要求好還可以更好的進階方案，如果是Problem 則提出改善方案。
4. 選擇 Try: 依據優先序，選擇要執行的方案。
5. 決定 Action: 也就是具體實行的方法。將它放入看板的待辦事項中，運用特殊的顏色，稱為「課題卡」，是團隊每一個成員都須要花時間去完成的課題卡。

.

所謂的KPTA 回顧法；是使用 Keep保持、Problem問題、Try嘗試、Action行動這四個角度的思考模式來進行回顧的方法。上面的圖示是一種視覺化的模板，一種類似看板的實行方式，這種方式也便於運用好寫的便利貼來進行回顧。是一種一開始就能定調在持續循環改善的方式。它改善了一般回顧會議；寫出優缺點的所謂的揚善隱惡的問題，而是在思考「讓下一次變得更好」的方法。

所以「KPTA方法」 的自我提問都跟「下一次怎麼做會更好」有關，「 Keep 」就是下一次還可以繼續這樣做的地方（而不是單純的指優點或成功），「 Problem 」則是這一次發現但尚未解答的疑問（也非單純就是指缺點）。

 

而最重要的是把心思集中在「 Try 」上面，所謂的「 Try 」就是根據 Keep 與Problem 的反省結果，提出下一次如果這麼做「有可能」更好的改進測試！交到 Action欄位中，便是變成具體的在進行中的待改善的嘗試事項了(這一點；也能考慮用到 DevOps上頭，可以讓持續改善不至於淪為空談)。所以比較有一種做實驗的科學精神。最精彩的地方的是，這並非是去構想真正的解決辦法，因為事實上我們通常不知道哪個方法才是最有效的解法(例如: 團隊溝通沒有效率的課題)，唯有「先測試後才知道」。KPTA對於用來處理複雜的問題十分有效(例如交付軟體的自動化release作業)，因為它是我們很難一次就做對，必須依靠持續改善才能逐步提升效能。

• Keep (保持)：

順利、可持續進行的。歸納哪些部分是下一次要繼續維持的。

• Problem (問題)：

感到不滿意的部分、那些還有進步空間的事項。找出哪些部分是這一次還有疑問的。

• Try (嘗試)：

針對Keep和 Problem所提出的改善方案。提出哪些是下一次可以改進的。

• Action (行動):

即具體去實行。包括對象、時間、如何做、怎麼做等。就是要實際嘗試的行動，將它放入團隊看板的to-do待辦事項欄位中。

.

圖二、第二次以後的KPTA回顧會議

.

第二次以後的 KPTA回顧步驟如下:

就從上一回的 KPTA 進行確認開始。

1. 先確認Try 及 Action 欄位中所寫下的應該持續改善事項，將便利貼移動到Keep，也就是進行設定想要持續改善的項目。
2. 然後移除不需要的Try 及 Action項目。
3. 確認 Problem 內仍有待改進價值的問題，去除不要的項目。
4. 針對 Keep 欄位內的項目進行整理排序，明確化這次要改進的項目。

.

KPTA回顧方法的核心是Flow也就是所謂的「流動」，關鍵行動是「 Try 」的「測試」。為什麼是流動的呢？因為這一次的測試，如果發現了某些值得保持Keep的方法，那麼就會進入下一次 KPTA 反省的 Keep 中。同樣的，如果這次測試發現新的疑惑，就會進入下一次 KPTA 的 Problem 中。因此這裡面的內容會是持續流動的。

 

小結

「 KPT 方法」最厲害的地方是持續改善；它的自我提問都是跟「下一次怎麼做會更好」有關:

「 Keep 」: 是下一次還可以繼續這樣做的地方（而不是單純的指優點或成功）。

「 Problem 」: 則是這一次發現但尚未解答的疑問（也非單純就是指缺點）。

「 Try 」就是根據 Keep 與 Problem 的反省結果，提出下一次如果怎麼做了便「有可能」更好的改進測試！

要注意的是，這並非是構想真正的解決辦法，因為事實上我們通常不知道哪個方法才是最佳解法，唯有「先測試後才知道」。

「 KPTA回顧方法」有幾個地方值得我們借鏡，首先就是他「不去問優缺點」的特色，實行敏捷的團隊，每個Sprint結束時都會進行回顧，因此很容易在回顧會議中陷入討論優缺點的迷失，這容易造成隱惡揚善或是常常陷入自我否定的情境，反而忽視了我們真正的目的是在持續改善上頭，一個Sprint的衝刺過程中只是一次的優、缺點表現，其實並不是那麼重要，重要的是下一次怎麼做才會更好，而KPTA回顧方法 的反省方式則全部聚焦在下一次行動上，具有持續改善的效益，它吸引我的地方是可以幫助我們有效的將工作視覺化，並聚焦在持續改進的能力上。

 

再來便是讓改善行為具象化的課題卡；讓團隊待改善的行為有一張實質的卡片，一張所有成員在這個sprint 裡都要做上一回的工作單。他可以提醒大家在待改善的地方多花一點時間去關注它。讓一般的回顧會議不至於流為形式檢討而沒有具體去實踐。我在改善行為的具象化裡時做了課題卡。當然團隊在衝刺過程裡可以有許多的課題，而Scrum 的五大精神指標(專注 Focus、勇氣 Courage、公開 Openness、承諾 Commitment、尊重 Respect)不也正是團隊可以拿來加強敏捷性的最基本課題嗎?

. 

註:

KPTA回顧會議係參考自日籍作家: 天野勝先生的《最快最短完成目標的OKR【圖解實踐版】》一書；運用在改善OKR的KPTA回顧法。此法可能是天野勝先生所首創。

 

邏輯傾聽與影響地圖

.

互動思考是透過邏輯傾聽的一種動態過程

.

第一次聽到「邏輯傾聽」是2006年從船川淳志所寫的《一個人以上的思考術》書上所記錄的，寫的是2005年EQ倡導會上彼得.薩洛貝依 所談的互動式思考力(Interactive thinking) ，想解決的是「為什麼人們的對話沒有交集? 」的問題。而這個名詞最早出現在 2004年11月的日本經濟新聞社出版的”圖解商業現場活用思考力和人與人之間的互動力”。

.

依據金字塔原理繪製出清晰的邏輯組成

.

邏輯傾聽的基本能力包括: 知性、感性及理性三個觀點。知性包括了知識和思考力，所謂的知識，是指對於溝通所需要的理解，也就是對內容有著相當的了解。而感性則是指向與別人互動的能力，正是所謂的 EQ。至於理性則包刮自我的認知能力和自我管理能力，認知；也就是對於自己的認識，避免自身的偏見。

–船川淳志

.

運用影響地圖講故事

上面這張圖清楚的描繪出了邏輯傾聽的基本能力，但是如果你想向別人表達的話，他雖然展現了清晰的邏輯概念，但如果你嘗試用平鋪直敘的由上往下的直白方式來描述的話，恐怕很快就會讓聽的人昏昏欲睡，這時候你需要的是影響地圖，在陳述時針對不同的聽眾適當的加入協助你容易表達的故事情節，效果便會好上許多。

.

加入角色(講述的對象)後的影響地圖

.

※ 把金字塔三角形橫躺下來，加入角色，依人物角色調整他的影響的項目，便是影響地圖了

影響地圖的結構；主要問題之後便是「角色」，而角色的加入，可以讓說故事有一個很好的開始。因此在陳述金字塔的邏輯結構時能夠適當的加入角色，因為角色賦予了邏輯結構主詞，這對於故事的表達有很大的幫助。比如；如果講述的對象是自己的同事的話，講述時的感性程度就會高於理性的程度。原因是你與同事之間已經擁有了相當的認識與默契，反之；如果是完全不認識的陌生人的話，講述時的知識成分就要高於自我認知的理性成分。也就是說；表達的是好是壞其實是要針對不同的聽眾而做調整的。而影響地圖正是能讓你看清楚他們之間的影響。

.

金字塔原理有助於你的邏輯思考，而影響地圖則有助於你的表達能力。

.

結語

在遠距上班很稀鬆平常的時代裡，當你在電話或網路的那頭聆聽著對方侃侃而談的時候，怎麼做才能讓你弄清楚對方想說些什麼? 重點又在哪裡呢? 試問你是否能在腦中相對地逐步地建立起自己的邏輯思考架構呢? 如果對方表達的既凌亂又缺少邏輯的時候，你該如何提問才能弄清楚呢?我的原則是依據金字塔原理試著在紙上劃出三角形的結構來，做法是「一橫一豎」:

一豎是；結論先行，以上統下。

一橫是；歸類分組，邏輯漸進。

也就是；先回過頭來把問題寫下來，這個時候便有金字塔的頂端了。如果寫不出來，則我的第一個問題便應該是問你要總結的問題是什麼了(也就是；結論先行)。在其次是弄清楚，對方有哪些個理由可以支撐這個論點(以上統下，此時不是歸納總結就是演繹推論，這便是一橫了)。請記得在結尾時；依據劃出來的邏輯結構，為對方做一次說明來對正自己所畫出來的邏輯結構是否為對方的陳述，並要給予對方補述的機會，以減少遺漏。

.

麥肯錫的金字塔原理

.

參考:

1. 船川淳志所寫的《一個人以上的思考術》
2. Gojko Adzic的《影響地圖》

 

 

針對新進人員的10分鐘敏捷

.

一頁資訊的上半頁，以五個會議為主的流程說明

※圖形下方的五個問句，如何交付需求? 如何對需求進行排序? 如何讓進度透明化? 如何知道做對了嗎? 如何讓團隊自己管理自己?，是開發流程的五大課題，寫出來、採用疑問句方式是提醒工程師，敏捷在這上頭都有異於傳統的見解，都有獨到之處，值得工程師多朝這些方向去思考。

.

新人一定看過我

新人斷斷續續的加入公司的開發團隊，想要讓他(她)們知道敏捷是怎麼會事，但又很難一直在做敏捷的訓練課程，所以我挑了新人onboard的第一天來談一下敏捷，也就是新人報到的最後10分鐘；主要是讓他(她)們知道接下來團隊會有那些會議要開，它們的目的又是什麼? 請他們試著自己去弄懂。只有10分鐘，我分成二個部分來談，先談敏捷的流程，再談新人該有的觀念。

 

一張敏捷的流程圖

敏捷的會議是 4 + 1，4個制式的會議加上一個梳理會議(refinement meeting)。依目的和發生的時間，我把梳理會議排在第一個(1)；它是拿來支援某些工作需要先跑的會議，團隊可以先看到下個Sprint才要開發的東西。其次是(2) 計畫會議；由一大堆需求裡挑出來形成Sprint Backlog也就是這次要衝刺的需求。(3) 站立會議；非常制式、充滿掌聲、激勵人心並限定在15分鐘以內的會議，目的是團隊透明化、同步協作的短時間站著開的會議，儀式是圍在看板前，秩序是順時鐘或逆時鐘，由每個人輪流講三件事: 一、昨天做了些什麼? 二、今天準備做什麼? 三、有沒有遇到障礙? (最好是在心裡頭，加上今天準備學些什麼?來設定今天學習的課題)。 (4) 檢核會議；在團隊開發完Sprint backlog後，這是將成果展示給相關人員尋求回饋意見的會議，在這個會議裡團隊成員可以展示自己在衝刺Sprint裡所負責完成的功能，目的是用來檢核自己是否做對了嗎? 並尋求相關人員的回饋。(5) 回顧會議；這是Sprint裡最重要的一個會議，團隊針對先前開發的種種事情、工作做得是好是壞進行檢討，目的是記取教訓並回顧團隊學習到的珍貴資訊，同時作為接下來持續改善的依據。典型的敏捷隊團，是以學習為宗旨的團隊，大家在乎經過一個Sprint的開發衝刺後團隊到底學到了什麼?

.

敏捷最重要的一個會議是回顧會議。進行回顧的時候可以讓我們學到最多，

而敏捷所追求的正是學習型組織。身為新人；盡力去學習吧!

.

這是下半頁，用敏捷教練的角度跟新人談一下注意事項

.

其實我做了一份簡報檔做教材，但從來沒用過，它只是靜靜地躺在我電腦的桌面上，總覺得對待新人應該要更親切一些，就只發一張教材，運用白板用閒聊的方式度過這短短的10分鐘。

.

下半部是談新人如何適應敏捷團隊

「明天；第一次參加站立會議時請準備好簡短的自我介紹。」從親切的關懷開始，希望他(她)們都能有一個好的開始。

 

• 新人要記住Mentor的中英文名字，這是基本的禮貌。能夠即時呼喚出 Mentor的姓名是對他人的一種肯定，也是拉近人跟人之間距離的第一步。所以要求他們要寫下來，這在你第一次向 Mentor問問題時尤其重要，親切的呼喚可以建立起彼此之間的信任，很重要。
• 寫下你的職責。它絕對不是你的名片上的抬頭，而是團隊期盼你到來之後所能解決的問題。是主管的寄望也是團隊的期望，請在一開始就弄清楚該努力的方向，千萬別弄錯了，否則就可以等著和我約談了(這是我常開的玩笑話，但也確實發生過好幾次)。新人通常都很努力去學習，但由於要學的東西太多了，很容易就會走偏了、花了太多時間在不是那麼重要的事情上，這是最常發生的現象，要知道主管們的耐心往往比你想像的要有限的，所以第一天就希望你們能盡快弄清楚接下來要努力的路徑，以及別人對你的期望。
• 練習一種問問題的技巧。以便你能一直到處問別人問題而不會讓人覺得厭煩。這是提醒，也是希望妳能在等一下回家後，在餐桌上跟家人分享新公司給你的感覺，順便討論一下問好問題又不會得罪人的技巧。算是一種提醒。
• 從熟悉你四周的工作伙伴的姓名開始。要知道；記住別人的名字是一種尊重的行為，但不要在乎別人記不住你的名字。試想；我們是從什麼時候才會記住新人的名字的，應該是從有工作上的往來開始，我們才會記住他的，但新人要反其道而行，因為自己所到之處都需要別人的協助，還是用功一點記住周遭夥伴的姓名吧! (敏捷團隊大都是坐在一起工作，以便於互動)。
• 建立運用即時通訊的技巧。即時通訊軟體要越熟悉越好它可以加快你的工作效能。也給予別人從各種不同角度來協助你的機會。
• 要迅速融入團隊。協助他人、自動要求出公差，是融入團隊最好的一種方式。新人一定要試試這個方法，它有效的很。團隊成員裡記不住你名字的人就不會和你有互動，只要你主動協助他人一二次，大家就會很容易記住你了。
• 新人要多觀察，少開口。應該多保持沉默，在建立對團隊或組織的認知時，盡量不要受他人影響，科學一點，自己去體會會比較有意思的多。
• 弄清楚公司的的使命、目標、戰略。這是組織為何成立? 為什麼目標在奮鬥的依據，弄清楚了就可以藉以判斷公司為什麼會有這種規範的緣由，你也就會知道如何去適從了。

 

 

這篇Blog是寫給公司新進人員看的。新人onboard；我的這部分說明，一直是被排在最後一關，大概在下午四點到五點多的時間，有時還會拖得更晚。想想；新人在渡過一關又一關的說明後，記了一大堆不知道有沒有用的資訊，也不知道要用在哪裡? 應該已經很累了，我又快速的講了一大堆他(她)們不熟悉的東西，反問自己: 這有用嗎? 於是寫下這一篇文章，如果你看到了就回味一下吧!

.

Always 提升自己的效率

最後；我一定會問:『第一天上班要加班嗎?』然後肯定的告訴他(她)們絕對不要，公司也不希望員工平時加班，如果真要加班，反而會希望你以提升工作效率的方式來取代延長工時的加班方式。還有開放區有很多講敏捷 Scrum 的參考書籍，歡迎自己去閱讀不懂的就來問吧!

.

為需求加上故事

.

“我們無法通過智力去影響別人，情感卻能做到這一點。”

-亞里斯多德

.

說故事有多重要

為什麼技術人員需要重視故事呢? 原因在於，即使個別的訊息 (需求)看起來都很有邏輯，讓人看了一清二楚，但是只要這些訊息之間相互的關係不是那麼明確，接收者(客戶)所吸收到的程度就容易受限。即使你塞了再多的片段資訊給對方，也很難讓他確切的了解。這一點可以在檢核會議(Review meeting)時的客戶回饋裡看出來。客戶經常是現在沒問題或對單一的功能沒問題，但在最後串起來時卻能提出許多意見。

 

故事能賦予產品生命

敏捷對需求所陳列出的一個個小的使用者故事(小增量、迭代與尋求回饋的對象)，需要被串接起來成為更大的故事。PO需要對大故事的環境、演進最為熟悉用心，而團隊則負責弄清楚需求的故事細節與情境。如此才能讓產品有一個足夠量的故事來支撐它，而工程師能做的則是賦予一個一個功能的小故事，它是一個個心血的結晶而終將成為工程師們生命歷程中的經驗所得。因為故事裡帶有情感的要素，可以讓人們產生更多的聯想，而賦予了產品額外的生命。

.

故事可以將訊息組合成邏輯金字塔。重點在於能以明確的連接詞串起所有的訊息，就成了一個大道理。

–麥肯錫顧問公司的金字塔原理用於說故事

.

故事連結了片段的訊息

好的溝通需要有清晰的邏輯內容，更需要一個簡單的結構來引導聽者的思維。而故事可以將訊息組合成邏輯金字塔，並讓片段的訊息串成更完整的系統邏輯並讓產品的生命得以成形。

如果在開發的漫長週期裡，我們始終知道自己正在完成的是故事裡的哪一個片段，我們就會做得更好，程式裡也會更有感情、意境與創意也就更容易油然而生。

.

敏捷運用故事來描述需求

.

使用者故事不是故事

一個好的故事詮釋了一個產品被開發出來的意義，就好像賦予了它生命一般。如上圖；一個大的故事，在敏捷的需求範疇裡我們稱之為EPIC，有關他的長篇敘述最適合在啟動會議(Kickoff meeting)拿來打動人心，讓大家知道辛苦工作的目的也就是我們是為何而戰的。再小一點的故事可以稱為 Feature 他適合在梳理會議(Refinement meeting) 裡拿來說明這幾次短衝(sprint)的目的，有利於團隊在明確的目標下發揮更好的協作。

 

接下來是使用者故事(User story)，雖然名稱是使用者故事但她不是故事。她是敏捷團隊裡PO、團隊與Scrum Master拿來溝通用的共通語言。一般以3C的方式做呈現，也就是 Card卡片、Conversation溝通及 Confirmation確認。它不是需求的文件，而是引發團隊探討需求的手段。再來便是開發工程師將一個使用者故事Breakdown 成可工作的任務Task，它能夠在一天內完成是在好不過的了，因此以小時做估算，最後則是守住這些 Tasks 的測試案例或單元測試。

 

上圖中；故事的範圍結束在 Feature層, 但情感的注入則應該再下去，延續到使用者故事裡，理由是帶著情感、有意識下的開發行為能讓人表現得更傑出、更有創意。因此我們應該為需求加上情感加上創意。而透過的方式便是擁有一個可以活化她的故事。

 

.

演講時；經歷是最好的故事體裁，也是最有說服力的故事。

.

 

結語

早年學寫程式時都是看著開發文件；也就是所謂的 follow Spec依據規格書來寫程式。這種做法很制式很難有創意，偶而浮現出來的 idea 也會擔心是不是會偏出主題的路線，因此經常督促自己還是選擇保守一點的好、少搞怪。在開始進入敏捷領域之後，想法就變了。由於是小增量、多迭代的關係，目標變小了，忽然間就開始不怕搞怪了，而且會經常刻意的去嘗試一些新的想法，樂此不疲。

 

因此在做Scrum Master的時候；總是要求產品負責人 PO要把需求整理成故事，用一段帶著感情的陳述把需求涵蓋進來，運用故事的情境把團隊帶入開發的課題裡，讓工程師們聽完了需求就恨不得能夠立即為他們解決問題(也可以讓工程師反思自己是否有能力做到?)，大家對此都沒有意見，但照著做的PO卻不多，也沒看出來有多大的差異，因此久而久之就越來越少PO這麼做了。這對工程師是一種損失，它忽視了故事的力量也減少了許多可能的創意與樂趣。

 

記得為需求加上故事，請不用擔心會走偏了；因為

事實確實重要，但情感卻能將事實的意義傳達給你的聽眾。

 

-Annette Simmons

註:

1. 《你的團隊需要一個會說故事的人》by: 安妮特·西蒙斯 Annette Simmons
2.  影響地圖 Impact Mapping 是編劇、講故事的絕佳工具。
3. .電影: 神鬼獵人的影響地圖分析，適合拿來做劇情說明
4.  一個PO做需求描述的故事與使用者故事的拆解範例
5. .故事在描寫一家三口出遊的需求
6. .陳列出來的使用者故事

 

 

DevOps的邏輯思維與技術

正確實踐DevOps的方法，是先知道自己在哪裡，再設定目標並運用持續改善來達成它。

-符合邏輯的思考

.

DevOps是解決软件开发人员和IT运维人员之间的 沟通問題

.

DevOps的定義:

一种重视「软件开发人员」和「IT运维人员」之间 沟通 合作的文化、运动或惯例。也就是解決软件开发人员和IT运维人员之间的 沟通問題。

實行DevOs就是在解決組織內溝通的問題，若是溝通順暢了，開發自然變快、運維也就自然的順暢起來，而發布時間也就一直在加速了!

.

演講題目詮釋；我將用一個顧問的角度來看 DevOps.

.

講這個題目的原委

因為推廣DevOps的關係，連續講了幾年的系統思考System Thinking。始終有一種看不見效果的感覺，一種只看見自己的病但別人都無感的現象，學員們到底獲得了什麼，始終讓人存疑?最近；在一場讀書會(研讀的是唐內拉‧梅多斯的《系統思維》)裡突然感覺到這是邏輯思維不夠清楚的問題；才導致大家研究了半天的系統思維卻問題多多。其實是沒能清晰的辨識系統的基本組成元素(元素、連接及目標；組成系統的三要素)所致，自然無法深入去分析系統的運作方式。從基本元素element開始就弄不清楚了，所以；應該從這裡下手也就是奠定邏輯思考的能力。避免由於對邏輯思考上的不足，導致無法順利進入系統思維的領域，所以才想到這個題目: DevOps的邏輯思考與技術。

.

從邏輯思考的誤區開始說起，並參考麥肯錫的思維系列文件

 

.

在多變的世界裡要能看見全貌是一種奢望，但它是實踐系統思維的一部份。

.

追求由 Doing DevOps進化到 Being DevOps.

.

 

團隊成員具有清晰良好的邏輯思維，對團隊內部溝通無礙間接促成組織展現良好系統思維的基礎。

.

對演講內容，做一下概要總結.

.

看見全貌之後首先要衡量自己在哪裡? 如此才能知道自己距離目標有多遠.

.

我們在哪裡決定你在實行哪一種 DevOps的策略.

.

敏捷運用小增量、迭代與反饋來協助客戶解決問題.

.

DevOps 的目的在能夠更快速地提供客戶穩定的產品功能.

.

進行溝通時不可或缺的清晰邏輯.

.

造成溝通不良的主要原因是；模糊的前言與跳躍、不連續的思考方式。

.

以一個專業顧問(麥肯錫公司)的角度來審視如何實施DevOps.

.

其實DevOps在解決 IT 跟開發人員的溝通問題.但大家卻把注意力都放在 Doing DevOps上，反而很少人能做到 Being DevOps.

.

這裡要談的是「人」的問題，也就是成功溝通的邏輯思考的問題.

.

溝通就像在玩傳接球的遊戲一般，只是球被換成了訊息.

.

良好的溝通通常都會有三個基本要素: 清晰的問題、具體的答案與可以期待的行為反應或理解。

.

團隊存在DevOps中的位置決定著即將面臨的障礙.

.

目前你的團隊正在遭遇哪一種障礙?

.

這張圖在描述實體層面上的問題。由右往左；是在描述溝通瓶頸的二個Gap在哪裡，它們相關的物件(需求/發布計畫)，我們可以由能夠運用的工具語言看出，發布計畫在這裡缺少了專屬的語言，造成溝通上只有文件化的不利情境。由左往右看；則是先確定你在哪裡呢? 團隊是否已經在運用最下層所提供的工具呢? 還是商未採用，抑或是運用得不順暢，可以加以度量並尋求改善。

.

範例: 溝通的誤區 PO to 工程師.

.

範例: 溝通的誤區 開發 to 運維工程師.

.

溝通訊息的三要素: 問題、答案 和 期待對方的反應

.

探討如何由 Doing DevOps 走到 Being DevOps.

.

你是在Doing DevOps 還是 Being DevOps.

追求更快速的開發只是 Doing DevOps，為客戶適時的發掘與更新問題才是 Being DevOps.

.

由 Doing Agile 談起.

.

Lean 是數位化的基石.

.

從 Doing Agile 到 Being DevOps 是我們實施 DevOps 的終極目標.

.

運用麥肯錫著名的金字塔理論來審視實行DevOps的邏輯思維.

.

快速交付是我們追求的實質目標.

.

錐形才是合理的金字塔外觀(需求-開發-維運).

.

金字塔背後隱含的是業務的作業項目.

.

進一步；運用持續漸進的螺旋式曲線，更能符合由 Doing(實行) 到 Being(成為)逐步過程，而不是段落式的，先做完一個才再去做另一個. 這正符合敏捷的精神；小增量、多迭代、尋求回饋的模式。

.

一個快速發布的思維模式.

.

.

.

.

.

.

Being DevOps 所該關注的不是發佈有多快速，而是在客戶回饋或是回饋之前就自覺的發布更新.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

影響地圖是敏捷開發裡最適合業務人員介入的一環

.

.

業務帶回客戶需求的同時，衍生出第一個版本的影響地圖，它是影響地圖的發起線，它可能只是一行式的影響地圖，就戲稱它為「一行式的影響地圖」.

.

一行式的影響地圖就足以取的展開式的較完整的影響地圖.

.

一個有里程碑、有替代方案及事後評估衡量產出數據的影響的圖範例

.

將加強邏輯思考是為欲達成的目標，排列出影響地圖，並對交付做出預估度量

一個理想的影響地圖；應該有設定里程碑，並做到事前預估與事後衡量，並在回顧檢討時考量是否採用替代路徑。

.

註: 以上是即將余4/30發表於中國大陸 DevOps線上峰會主會場的一場演講內容.

節錄一下重點:

一、正確的DevOps思維；應該是審視你現在組織的狀態，再去尋求此刻應該克服的既有障礙。

二、由 Doing Agile 走到 Being DevOps，是一種系統思維的方式，它是在客戶回饋或更早之前就自覺的發佈更新的方式。

三、在技術上；藉由麥肯錫顧問公司的金字塔原理，以清晰的邏輯思考來克服組織溝通上的障礙。

四、推廣業務敏捷化的「一行式的影響地圖」。

 

 

 

系統思維下的 DevOps 和 Agile

.

主題: 系統思維之下的 DevOps 與 敏捷

.

大家所面對的 DevOps在範圍上都有一些差異，但重點是先知道自己現在在哪裡?

.

.

簡單的說明一下系統思維常見的誤區

.

避開誤區的思維方法 – DIE 法則

.

總結一下系統思維

.

DevOps vs. Agile

.

參考自 Guru99 網站，我只是做了一下翻譯

.

業務、產品部門與開發部門有許多協作的工具

.

但運維人士 Ops Guys 缺少一種與大眾溝通的共同語言

.

運維俱有前移與後移的雙向能力，敏捷只有前移功能

.

知道自己現在在哪裡，才能思考該從哪裡開始，因此實踐 DevOps從定位開始

.

不斷的讓自己處於透明、檢核與調適的情境才是應付多變環境的方法

.

讓團隊從看板開始，是一種絕佳的透明方式

.

強調多任務但單工作業的精實七大原則

.

提一下喬梁老弟的持續交付2.0的雙環觀念

.

感觸

從2010年起，我年年參加多種 DevOpsDays 的聚會，卻始終等不到運維人士專屬的共同語言被發明出來，拿它來讓 DevOps 工作運行的更加順暢。雖然這個語言到現在還不見蹤影，但是相信不久的將來一定會有的。

對於需求而言；我們有「使用者故事」User Story可以拿來描繪客戶的種種需求，甚至有影響地圖Impact mapping、用戶故事地圖 User Story map或使用者情境圖來協助分析、製作、探討需求。更有「測試案例」test case、測試計畫來協助開發人員守住程式功能或產品的品質。但至為重要的運維端到目前為止，仍然只有發布計畫Release Plan 來做為溝通的文件，少了一種大家容易溝通的共同語言，讓 Ops運作起來，少了一種融入整個開發到運維的通識協作語言。

.

一個好的需求遠遠勝過開發團隊做一大堆無關痛癢的工作

大家都知道；一個好的需求遠遠勝過讓開發團隊做一大堆無關痛癢的工作，因此協助製作、發掘需求的工具、技術一直再出陳更新，再多也不為過。

.

但是PO所端出來的需求Listing，仍大多落於"校驗活動“的象限。

但大家都知道；需求能夠落在"差異化活動“象限中，才最有意義。

.

感觸抒發於至 中華電信 演講主題為「系統思維下的 DevOps 和 Agile」前夕。

.

 

如何與自己對話

活化思考

傾聽自己內心的低語和牢騷有助於提升自我認知的能力(Awareness覺察)，連帶也會提高與他人之間的互動力。

-船川淳志

活化思考的利器，就是一問多答。

-問題，不會只有一個解答

 

.

在Gmail 設定 ”自我回饋” Tag

.

運用寄信給自己來與自己對話

我總是在演講時要求學員做到自我回饋，這是個人達到敏捷化的基礎，也就是「寄信給自己」。做法是；只要在email系統裡設定自我回饋的標籤(Tag), 接著只要點一下；便可以輕易的察看這些寄給自己的信件的「自我回饋」的訊息了。

 

目的是拿來反覆驗證、追蹤之前的解題方案或是想法如何? 這是一種運用在經過一段時間的間隔後，透過時間延遲的效應讓自己的思維有機會沉澱一下，然後再從新思考一次問題的方法，它讓我能重新的來面對問題一次，又多一次機會試著從不同的角度來思考解答。依據的是「反覆思考就會又答案」的理論。(註1. 活化思考的七個提示，參考自日籍作者，船川淳志的著作《一個人以上的思考術》)

 

---

我會有這種運用email 來做自問自答的習慣，最初只是為了把查詢自 Google上所得到的各種不同答案加以整理起來，讓他們重疊在一封郵件裡實在是再適合不過的做法了。它不但可以記錄下整個解題的過程，也能讓自己看到在怎樣的查詢條件下，所查詢到不同的解答。然後；一在地重讀它又可以進一步的增強記憶，對學習新事物也很有幫助。

久而久之卻發現，除了查詢資料的整理之外，也可以拿來像鬧鐘一樣的提醒自己，讓自己不容易遺漏事情。便開始嘗試紀錄事務的提醒。除了提醒；便是可以用文字來和自己對話，真是一點壓力都沒有，你可以坦承的檢討自己知道什麼、沒弄清楚什麼、接下來該計畫些什麼。雖然閱讀者是自己，但千萬不要因為是自己，就不在意是否打了錯字或是語意含糊不清，其實；這種做法最適合拿來檢視自己所寫下來的文字是否合乎邏輯了，幾次以後；便養成了在做演講之前的自問自答的課題。它可拿來檢視自己演講議題的整個邏輯程序，是否讓別人容易了解，又會產生什麼樣的疑問。

功能:  1). 資料整理和傳遞。2). 增強學習  3). 鬧鐘及事務提醒。 4). 思維邏輯的檢核。

(自己也因此；增廣了不少見聞)。

---

.

選擇面對自己

在跟自己對話的過程裡，一開始總是會感覺到自己的無知，然後隨著透過各種查詢的方式，一直加進來的各種資料與解答，慢慢的越來越多累積下來的知識。有時候追到最後；即便沒得到太多突破性的答案，也能換來相當的滿足感。久而久之；信裡面不是只有問題的解答了，開始有一些提醒自己該怎麼做事的警語，或是一些好的概念，一些想要提醒自己的、或是提醒學員的佳句，也不經意地累積了起來。這種寄信給自己的動作，透過自我對話的行為，讓人開始經常面對自己(出現錯別字時，其實應該更加在意，它隱喻了你在這裡會犯錯，而現在有機會先修正了，錯誤自然而然地消失，慢慢的讓自己變得更嚴謹了)。

.

---

人遇到痛苦一定會學習逃避，這是本能。逃避之後確實暫時變得比較不痛苦了，然而，痛苦並沒有因此而得到解決。解題；就要從面對自己開始。

---

 

依靠它來增加自己的覺察力

覺察Awareness是程式設計人員最不可或缺的能力。寫程式是一種寫越多就越不容弄清楚自己都寫了些什麼的工作。我稱之為程式設計人員的「困境」，程式行數越多我們落入的困境就越深，因為我們越難覺察自己都寫了那些邏輯，是否產生了矛盾的地方，而這些矛盾的地方便是日後會遇見的缺陷，也就是通稱的Bug。而覺察正是偵錯時最重要的元素。(就是客觀偵錯的基礎)

 我教導程式設計人員寫好程式的第一個要素是覺察(也就是先學debug後學寫程式)，它是你集中注意力、聚精會神、頭腦清晰時就會產生的東西。讓我們看看《簡明牛津詞典》Concise Oxford Dictionary對覺察（aware）所下的定義：「神智清醒、非無知、有知識。」我最喜歡《韋氏字典》Webster’s的補充說明：「覺察指的是：機警觀察或詮釋他人所見所聞與感覺後所得到的知識。」這正是程式設計人員運用清晰邏輯來解題的利器。

 

大部分的programmer都有一種強烈的自以為是的思維，這種過分自我中心的意識會使人扭曲看清自己真面目的能力，也看不清楚身邊的人，我們也極少能從同事、下屬甚至是朋友、家人口中聽見坦白、客觀的回饋意見(請參考: 卡普曼戲劇三角 – 心理學界的系統思維)。為了獲得回饋以便能夠提前知道錯誤來進行自我修正，為此我常年來運用寄信給自己的方式，養成了一種「自我回饋」的能力。目的就是想要盡力的維持自己覺察的能力。有時人們會稱它為自我概念。

 

---

自我概念 Self-Concept 即一個人對自身存在的體驗。它包括一個人通過經驗、反省和他人的反饋，逐步加深對自身的瞭解。自我概念是一個有機的認知機構，由態度、情感、信仰和價值觀等組成，貫穿整個經驗和行動，它能把個體表現出來的各種特定習慣、能力、思想、觀點等組織起來。

---

 

結語

在回顧會議裡，團隊有秩序地進行自我反省的動作，省思自己哪裡做得好，那些地方沒做好，依據回顧檢討的方式來改善自己。但自省並不能使你擁有更好的洞察力；要知道你的經驗往往是你自我認識的敵人；而他人又總是避免誠實地說出對你的看法。所以培養自我洞察的能力至為重要。我就是運用這種寄信給自己然後再反覆來回信的方式，用來加強思維以增進自己的洞察力的。

---

請問；收到自己寄來的信的時候要回覆嗎? 要如何回它呢?

答: 一定要回覆，而且要用心的回，不可以語意不清或有錯別字，你越是用心收穫就越多。

---

 

透過「寄信給自己，再回信給自己」，能夠觸發你的自我察覺能力。除了提升判斷資料正確性的能力之外，多做這種練習自然會進一步提升你的洞察力(驗證一個問題擁有多個答案的強化性思維能力)。

.

「我找到答案了 」跟「我找到許多解答」，後者將活化你的思考能力。

-持續搜尋正確解答的思維

.

寄信給自己不是PO文，PO文只會慢慢地將人洗腦成自戀又自大的 nobody。覺察的道路不會都是喜悅的，更多的是痛苦之後的體悟。請避免在信中稱讚自己，雖然那樣做可以讓人覺得快樂一些，但卻只是自我感覺良好，一種逃避面對事情的態度。

開始寄信給自己吧!

開始回信給自己吧!

 

註一、船川淳志的著作《一個人以上的思考術》

活化思考的七個提示:

1. 思考裡是沒有界線的: 反覆的思考就會有答案。
2. 一問一答、一問百答: 正確的答案只有一個。
3. 正反面思考的建議: 看事情一定要正反面都看。
4. 琢磨自己的用詞: 建議一個人玩接龍遊戲。
5. 改變思考模式:刻意選擇擴散和收斂、反應迅速和條理分明、抽象和具體。
6. 永遠保持冷靜: 對於看不見的問題提出三個疑問 Why? So what? What if?
7. 認識妳自己: 提升自我認知能力。