看板的流程管理

主管站在看板前該想些什麼呢?

看板可視化了主要的開發流程,但無論是設計得再好的流程仍然需要管理來輔助,因為它是不會自我管理的。團隊運作的主要流程當然應該由團隊自我管理(self management)。那主管呢? 組織與經理人則負責資源、人員與績效目標的管理,也就是說管理者要負責看板上看不見卻又佔著重要地位的事務。換句話說;管理者在看板前觀察看板事件時的角度是由支持流程與管理流程的角度做出發點。也就是一方面由巨觀的角度參考由目標、績效、資源與界面接口為重點來思考與解釋真正的問題。另一方面;要細膩的看著出問題的事件(工作單)並以上述四個特性去追蹤挖掘思考是哪裡出了問題。

除了主要流程之外,支持團隊正常運作的還有看板背後的支持流程與管理流程

流程管理

需要考量到人、事與管理上的問題:

  • 流程除了主要目標之外,是否擁有合理的子目標? 個人目標?
  • 當我們專注於流程效能時,是否忽略了人員的績效管理.
  • 團隊的壓力是否合理,是否有常態的循環,團隊是否得到了足夠的資源配置.
  • 流程中步驟與步驟間的接口是否進行了有效的管理。
設計再好的流程也需要管理來輔助

一個組織的工作其實是由主流程、支持流程與管理流程合力完成的。

《流程聖經》(註1.)

範例: 生活就是故事,把故事寫在卡片上,將從起床後到出門前的所有行為記錄下來,就是你的晨間故事。因為它是流程所以可以把它組成看板的型態,顯示如下:

早晨的故事流程

你可能會按照時間的充裕程度來選擇做不同的事情。並試著調整(限制)你從起床一直到整裝出門所花的時間。在以時間為基準時你會得到所有工作的優先順序,也就是排列出它們的重要性。一旦有了可視化的順序依據,你就能夠輕易的看出流程中最大的浪費、找出最有意義的事是什麼?最不可缺的是什麼? 這個時候便可用時間做基準調整出屬於你個人的最佳流程了。

上面陳列了你在早晨時的主要流程(primary process),其實;每張單子也就是每個工作項的背後,可能都還有用來支撐它的流程,我們可以稱之為支持流程(support process)。例如: 吃早餐;如果前一天沒有去麵包店購買麵包,則今天打開冰箱就沒有麵包可吃了。或是前幾天沒有去買鮮奶,冰箱裡就不會有鮮奶了。整個流程就會被打亂了。另外;針對多人的情境,當家人沒有相互配合好的時候,也會造成流程出狀況無法順利完成。例如孩子的學校有校外教學的時候,家長就要配合他的生活作息作調整,我們可以稱之為管理流程(management  process)。這便是看板方法在管理流程時的多角度考量。單一團隊所運行的看板流程就是主要流程,背後還有其他團隊需要協作的工作或服務資源調度,就是支持流程,而公司組織所提供的資源協助,便是管理流程。有時候它們都是可見的,也可以串接起來,例如 DevOps 中的開發與維運就能清晰的串接起來,成為主要流程一起來評估效能。但其他流程;一般都是隱形的成本,但也不能被忽視,一旦忽視了就會出問題。

小結

一個組織的工作其實是由主流程(業務、開發、維運)、支持流程與管理流程合力完成的。團隊運行看板方法只是其中的一環,為了看清全貌,我們可以把開發與維運流程相結合(就成了DevOps看板)或是把業務流程也加進來(BizDevOps),自然可以看的更清楚了。 這時你會發覺這些流程需要管理嗎? 想當然是的。要知道;流程可以自行運作但它需要細心的管理來維持或績效改善。這是管理人的職責。

由看板發生的種種情境去發掘團隊運作的好壞、正常與否

在管理流程時;我們可以由主要流程向前看到業務端時,往往可以發現外部有著更大的目標可以去設定去追求,適當的目標往往可以起到激勵團隊的作用。往內看到團隊成員的工作績效時,明白要落實績效管理才能有效的支撐流程的高效運作。因此我們不能忽略流程的管理;也就是看板運作的管理面。一般的管理階層通常都只是看到團隊在看板上的進度與效能的表現,但實質上我們需要進一步去了解為什麼?為什麼會這個樣子,這是管理者不該忽略的地方,經常去關心看板的為什麼,是我們進行平時績效考核的一種依據。也是各級經理人在運作看板時應該盡到的管理行為。

註1.《流程聖經》為流程教父拉姆勒&布拉奇的經典著作。企業轉型升級的助力之作。

看板方法 :以人為本,跨越邊界

軟體設計的開發應變力,關鍵在於「以人為本」。

《Agile Software Development》

軟體開發不同於產品製造,你無法用產品的分工機制來加快軟體的開發。當然;將看板運用於軟體開發上也應該與運用於生產製造上有著不同的重點。在講授看板方法時經常被詢問到:『團隊是否已經達到能力的上限了? 要如何得知呢?』其實真正應該關注的是團隊的士氣。

改善軟體開發的祕訣在於人,而不是製程。

Bob Martin

看板方法 Kanban Method

看板方法(Kanban Method)實踐的是軟體界的流程,它的目的是要你打破流程中關卡的邊界。如果你還是以Toyota式的思維在運行看板(TPS 讓產品的製程視覺化,而看板方法則是可視化知識工作者的工作流程),則很多地方都會將你帶到傳統開發的思維方向去。然而;軟體開發沒有傳統產品線在製程上重複的機械式工作。又前一次的工作量、做了多少時間並不能做為下一次工作效能的依據,所以說軟體開發就像是從事藝術工作一般,沒有一支程式會長得與任何其他程式一模一樣的即便它們有著相同的產出,程式的這種獨特性打破了傳統看板的執行規範。所以如果你還在強調步驟與步驟間的效能、速度那就錯了。你應該看的是全貌,整體(團隊)的效能才是你應該關注的。

看板應該關注的是人

應該關注的是團隊的士氣,而不是他們達到最大工作量了嗎?

燃盡圖縱軸是工作量,橫軸則是時間

燃盡圖不是效能圖示

它是團隊開發的進度警示圖。我們常犯的錯誤是『上回團隊做了多少故事點?』、『這一回團隊應該做到多少故事點?』這是一種錯誤的思維方式。軟體開發不比規律式的產能,人的因素始終佔著最大比例。可視化的「燃盡圖」目的是讓我們(每天都)能看到工作進度的全貌,同時知道目前自己在哪裡。完全是一種系統思維的模式,團隊可以在站立會議時看到產能運作狀態,就像接受紅綠燈一般的警示作用。圖上的數據也是拿來做為參考使用的,例如: 有人請了幾天假,那進度勢必會跟不上。如果我們想維持進度,則就要採取相對的措施才行。

小結

跨越邊界; 看板上的流程是用來跨越的,許多看板的使用者,不管運行了多久的看板方法卻從頭到尾都依據同一組流程來跑看板,這麼做就錯了。要知道;在同一個步驟內追求效率,致力於消除浪費,努力的提升效能降低半成品數(WIP),這是不夠的,正好犯了限制理論(Theory of Constraints,TOC)所謂的局部優化的徵狀。正確的方式;應該先嘗試運用不同的開發流程,在找出團隊開發上的最大約束之後(例如:單元測試或整合測試),再針對這個約束去擬定改善策略,以科學實驗的精神(假設-實驗-驗證)來發掘問題並改善問題,這才是運行看板方法真正的精神嘗試運行不同的流程。

早期TOYOTA時代的運用看板,是在追求產品製造過程的高效能運作。而 David J. Anderson 先生發明的看板方法(Kanban Method)則是運用在軟體開發上,適合做為敏捷變革前置運作的視覺化工具,它能讓團隊成員因為看見了自己在開發上所表現出來的效能,因而引發改善的意念,藉此激發團隊持續改善的意識。因此在運作上並非侷限在每個欄位的效能或致力於消除queue的浪費上頭,而是以人為本追求團隊開發的整體效能為依歸。

註 1. 《Agile Software Development》敏捷軟體開發為 Robert C. Martin 所著

註 2. 看板方法六大核心實踐

顧問的 20/80 簡報製作技巧 – Ghost Deck

Ghost Deck有人翻譯成「空白簡報」,但它並非完全空白。也有人以直譯的方式翻譯成「幽靈甲板」就有點像遊戲或小說的名稱,這裡就直接用原文了。它是一種簡報製作的快速起手勢。讓我們針對手上的既有資料快速勾勒簡報檔的整體架構,也就是用少少 (但要多少才夠呢?我想20/80法則或許不錯) 的資訊去發掘事件的全貌,隨後再逐步的去補足80%的資料內容。是一種非常符合敏捷精神的簡報製作法(敏捷開發以重復式由淺而深的增量方式構成迭代作業,如下面的蒙娜麗莎圖示),講求先構建輪廓,再逐步釐清內容的簡報製作方法,不論是麥肯錫顧問公司(McKinsey & Company)或是波士頓顧問公司BCG都依據 Ghost Deck的方式訓練旗下顧問運用這種方式來製作建議案。

在大部分簡報內容尚未蒐集完畢下;先構建架構

所謂Ghost Deck的概念,就是一堆沒有內容的投影片的組合。舉例來說,假設一場簡報有11張投影片,大部分的投影片都還沒有填入內容,有些投影片上面有文字,但只有填入講者想對聽者說的重點,或是講者想強調的論點,但沒有具體的說明。總而言之,其中包括了故事情節(storyline)之外,也包含想要傳達的重點,以及為了支持該重點所需要的資料或分析資料的圖檔。說穿了就是一個虛構的投影片檔。

Ghost Deck 的好處

這是一個先抽象化勾勒輪廓再具體化實作內容的概念。它不僅僅在整理思緒、決定哪些工作非做不可的事情時能順利派上用場不至於遺漏。更能基於假說思考來快速的組織簡報,無疑是顧問工作的利器。這種做法像極了敏捷開發以重復式由淺而深的增量方式構成迭代作業的效益。好像畫家作畫時,會先從輪廓開始,然後再逐步填入元素加深各個部分。這種先全貌後細節的好處是:

  1. 它可以協助更加清晰的思考。
  2. 它是一種對已知與未知資料的盤點。
  3. 對不足資料的盤點,讓我們不至於只關注部分重點而迷失了方向。
敏捷開發相仿於繪圖式完成作品的過程

先架構化在填入細節

所謂的將故事架構化,是指模擬整件事情是以某某內容與方式所構成的整體輪廓。這是一種結構化思維的過程,如果你的框架結構是合理的,接下來的步驟也會因此變得容易起來。你所創造的內容就是方案的大綱,而且它架構了一個故事,彷彿作畫一般,輪廓以概略說明全貌,再來才是去填入那些足以吸引人的細節元素。你的目標是讓聽眾或溝通對象能夠輕鬆的解讀,避免冗長敘述而容易造成錯誤的解讀。由於人們傾向依靠自身的經驗來解讀信息,因此能有一個清晰的輪廓可以避免在一開始就走偏了。

運用假說思考組織簡報

你作了一個假設,然後證明它是對的還是錯的。這種敘述問題的方式是最有說服力的了。在邏輯上稱之為演繹法。人們在面對未知的情境時,能夠依序的運用邏輯推理來產出結論,當然就容易被人們所接受。

結綸是由一個又一個的假設經過驗證而演繹出來的

小結

身為講師;早就已經習慣以做簡報的方式來進行學習。也就是理查德費曼Richard Feynman所謂的費曼學習法the Feynman technique (為諾貝爾物理獎得主理查德費曼所創造的一種快速學習方法)。以簡報來促發自我學習的效果尤其快速。但若是要拿來說服他人的話,就顯得凌亂無章了些。為了增強說服力,往往會再採用麥肯錫的金字塔原理將整篇資料由結論先行的方式輔之以歸納或演繹的邏輯論證來重新寫過。拿一個我典型的簡報演講跟大家分享:

開場-破題–自我介紹–跳到全貌–介紹演講全貌(圖示) –回去跳點–開始講內容

一場Keynote 可能只有40~60分鐘,演講者要介紹自己又要介紹今天的主題,又要有自己的風格,然後又希望能夠打動聽眾。想做的事實在太多;而時間始終是不夠的,所以我選擇能夠在聽眾(學員)心中留下一些印象、一些蛛絲馬跡這樣就夠了,讓他們在未來有機會遇到相關的問題時,能夠有跡可循就不虛此行了。所以我採用的是倒敘的流程,先介紹題目、介紹自己,然後就破題(結論先行),接著就跳到後面的「看見全貌」投影片(一般演講;正式結束的投影片是 Q&A問題看板頁),要求聽眾思考「後退一步的真諦」無論它現在正在做什麼,客觀的回顧一下,是加強反思的手法,希望帶來對學員有用的思考。接著會以圖示的方式,三言二語就把整個演講內容介紹完畢(全貌出來了)。隨後才是跳回去主題,開始我的演講。

Ghost Deck 就是一種系統思維的作法,講求先看見全貌的簡報製作技巧

《假說思考》作者: 內田和成 第三章 洞察事情的整體架構,介紹到了波士頓顧問公司 BCG 的空白簡報法(Ghost Deck)

麥肯錫顧問公司的 Ghost Deck 在這裡。

計畫是為了更少的開發

運用最小的開發功能爭取對客戶最大的價值

產品開發的真諦

用最小的開發成本為客戶製造最大的價值。上圖借自《用戶故事地圖》作者 Jeff patton 在使用前必讀的起始章節中的說明。它屬於對PO產品負責人的期許,核心概念是人們透過產品的製造、新功能及特性增強來改變這個世界,而促使現在邁進到未來的則是製造產品所依據的思維: 需求正在改變這個世界講得更清楚些;是成千上萬的產品負責人透過規劃需求的方法,製造出各種產品來促使人類改變生活方式進而改變這個世界邁向未來。

需求正在改變這個世界

– Jeff Patton

用戶故事地圖的目的

在《用戶故事地圖》裡 Jeff Patton 告訴我們:『用戶故事地圖真正目的是造成對需求認知的共識』。我們一群人圍繞著使用者故事地圖,從左到右描述著用戶會採取怎樣的操作步驟,然後再由上往下來討論上層的操作活動,再針對每個細節討論如何實作才能達成上一層的功能任務。然後從專案開始到結束為止,應該依據著需求的變化,大家持續更新著地圖上的任務。讓視覺化的全貌協助我們自始自終讓所有的人都能知道團隊已經完成那些任務現在正在進行怎樣的工作、專案的全貌長成什麼樣子而我們又在哪裡。換句話說;就是因為透明令大家都看見進度,而更是看見後能夠擁有相同的認知;達成了一致的共識。

使用者故事地圖;希望讓我們能夠在專案開發的過程中,一直看到需求被實現出來的樣子。並強調用戶故事最重要的不是寫下了什麼? 而是讓人在閱讀時會記得什麼? 就像度假時的照片一樣。

使用簡單的可視化使用者故事地圖來描述產品的全貌

計畫是為了更少的開發

產品開發的前提是運用最小的開發功能爭取對客戶最大的價值。並基於產品是由多個獨立或相依功能所組合而成的這個概念,運用一個使用者故事地圖來涵蓋多種不同的使用者,如上圖中的User Type, 也就是使用者類別。換句話說;針對某一種使用者類別就能夠運用產品功能規劃而採用使用者故事地圖工具預先畫出他會如何使用產品時所留下的足跡。再運用產出的使用者故事地圖作為依據進行功能提供的開發作業,而不同的使用者則只是不同功能組合的結果,所以產品功能在對照到不同的使用者類別時(由於不同的使用者對產品自然會有不同程度的需求),自然會產生需求的重要性排序,因此我們開發產品時自然就可以依照主要的客戶形象(persona)將產品功能區分成必要(must have)、應該要有(should have)、能有最好(could have)及不會有(won’t have)的功能區分,這正是著名的需求四類區分法MoSCoW(註1)。

By Dai clegg

需求分類MoSCoW的案例

英國國防部在2009年左右,為了減少友軍誤殺自家人的事件(註2),決定開發一套戰鬥識別系統(Combat Identification System, CIDS),避免悲劇繼續發生。採用的需求四分法是一個典型的放棄傳統計畫驅動開發改為價值驅動開發的作法。下圖中左側是傳統計畫型開發考慮的「時間-資源-需求」專案鐵三角。對正到右側的DSDM(Dynamic Systems Development Method)敏捷開發方式,差異在左側不可變的功能並預設可改變的是時間與資源,也就是專案開發必須完成所有的需求才算完成,右側則是站在開發者的立場,視需求功能是可調整的項目,並依此來配合固定的時間與資源量。

所有需求都要做是典型計畫驅動開發的思維

當PO無法抉擇需求的MoSCoW分類時 – 採用不同的使用者類別

計畫是為了更少的開發;這個道理大家都懂,但是你若以計畫驅動開發(傳統)的思維方式來規劃開發方法的話,就是會以在時程內完成所有的需求為目標。而忽略了不是所有使用者都會需要所有的功能的。因此請扭轉你的思維改以先完成哪些對使用者最有價值的需求,也就是價值驅動開發的思維方式。做法是:採用不同的使用者類別(persona)來區分需求,一定有一些需求是大部分的使用者都會用到的,這些便是屬於 Must Have的部分。也一定會有一些需求沒有那麼多使用者都會用到的,這些僅次於Must Have的需求,就可以排進Should Have的部分。至於那些看起來不是非要不可的需求就屬於 Could Have 的類別。在其他的便是Won’t Have了,也就是不會被列入開發工作的需求。

什麼都要是一種資源分配的問題。

適當的資源分配;

用之於時間;稱為效率。

用之於需求;稱為專注。

小結

主管在討論需求時經常是「什麼都要」,團隊(PO們)也就經常用這個來作為無須排訂需求優先順序的藉口。其實這是一種資源分配的問題。主管們經常考量的依據是該選擇專注於重要的項目的投資報酬率會比較好呢? 還是追求產品功能的完整性會比較划得來些。但其實真正應該考量的是以對客戶最有價值的投資是什麼為依據,而不是基於自己開發團隊的能力,因為這才是產品開發的本質。

鬨故事地圖能讓我們聚焦在使用者及其經驗上

註 1. Case Method Fast-Track: A Rad Approach by Dai Clegg

此為ORACLE經典 Case Method 叢書。出版於 1994/09.

註 2. 英國國防部在2009年投入開發的戰鬥識別系統(Combat Identification System, CIDS),CIDS專案目的是減少友軍誤殺自家人的事件。系統分成三期開發,所有需求以Dai Clegg 的MoSCoW分類方式進行。成功達成了敏捷小增量、多迭代的繪圖式開發方式。

參考自: https://idlsocweb.org/Documents/Symposiums/IDLS2009

註 3. 用戶故事地圖 User story mapping

用戶故事地圖作為一種對照需求開發工作是一種極為有效的規劃工具,越來越廣泛地應用於團隊開發實踐中。Jeff Patton 編著的《用戶故事地圖》以用戶故事地圖為主題,強調以合作溝通的方式來全面理解用戶需求,涉及的主題包括怎麼以故事地圖的方式來講用戶需求,如何分解和優化需求,如果通過團隊協同工作的方式來積極吸取經驗教訓,從中洞察用戶的需求,開發真正有價值的、小而美的產品和服務。

讓敏捷更敏捷的「假說思考」

身為敏捷教練;可能一輩子都會不停地在尋找能夠讓敏捷更加敏捷的方法(它可能就是我這輩子的無限賽局了)。其實可以推廣的理念很多,例如 Dan North刻意發現(Deliberate Discovery),就是一個讓敏捷開發更早開始的好概念。應該算是團隊在開始開發行為之前的前置處理動作吧。這種讓開發者在還沒開始動手之前就能先加強相關domain knowhow的做法(增進開發專案的相關知識),對即將到來的開發作業一定會有著某種程度上的幫助的(與prototype 或MVP應該有著一樣的貢獻)。波士頓諮詢公司BCG的「假說思考」在某種形式上也算是一個前置思考的方法,但要更讓人驚艷。

若能譯成「假設驅動管理」會更直覺些

我們習慣的思考方式

一般人在面對問題的時候,都會採取先搜集、分析資訊再做決策。也就是依據戴明博士的 PDCA循環(註1)做解題的動作。這樣做的結果往往容易花費大量的時間在做資料蒐集(尤其是在現今資訊過量的時代),卻未能及時的拿出解決問題的策略(敏捷化的團隊則是在收集了部分足夠開工的資訊後就啟動Sprint,這種啟動方式避免了過度分析資料的做法。說起來是一種快速啟動作業的開發方式)。但其實;在這個資訊爆炸的時代「捨棄資訊比搜集資訊更重要」。因此而衍生出來一種更快速的解題模式,它的做法是先構建假說,並在向前推進工作的同時,對假說加以驗證,然後持續探索解決策略。這是一種既科學又符合敏捷精神的作法;這種方式就稱為「假說思考」方式。

在VUCA的時代下,未來是多變、不確定的,因此無論多大規模的企業,都需要應對未來的一切變化。所以,應該培養並持續累積顧問式的經驗法則,如此便能在遭遇問題時立即(先)做假設,以快速的回應來爭去時效。這對任何企業的管理者來說,藉由累積的經驗來掌握假說思考方法都是至關重要的。

假說(hypothesis):未經證明而最接近答案的解答。

內田和成

假說思考: 就是先做假設,然後再去驗證它的對錯,藉此避免過度蒐集資訊,而浪費太多時間在做分析上。它是以結論為起點的一種思考模式。 從右腦大膽假設,再交由左腦細心求證。可分成二個先後階段: 首先藉由假說找到真正的課題。再續用假說尋求解決課題的最佳答案或最適決策。

假說思考:先採用假設解決實際問題

首先要有假説 – 第一條法則: 捨棄資訊比搜集資訊更重要

提出假説的好處是能加速解決問題的速度,而且能避免一開始就陷入資訊洪流中,藉著思考描繪問題框架(避免一開始就Google!)。有經驗的顧問們通常都能見微知著,從簡單的細節看出問題的模式(pattern),然後提出假説並釐清問題解決流程。不過就算是新手,也別害怕提出假説,一旦發現錯誤了,只要能心平氣和地修正就好,千萬不要死守假説或不必要的資訊。最後要相信,對顧問而言;假説能力遠比分析能力更重要,因為唯有能提出解決方案的人才能成為顧問因而立足商場,如果過度重視分析能力而身陷資料流沙中,便無法幫助企業解決問題。

在目標確定之後,透過大家Brain Storming ,列出種種假設,然後挑選最被看好的幾個依序去分析它們,再去驗證它們,如果錯了就換下一個來做,發現對了就挖到寶了,這麼做;怎麼說都比全部去分析、驗證要划得來許多,省下不少時間。是先快速做假設,看起來很盲目但其實對於一開始我們面對無知的探討實在是很科學的作法,能快速的過濾多做假設所造成的雜訊,也提升了許多效能。當你需要從許多需求中找到重點的好方法。

避免窮盡分析網羅思考

網羅思考vs假説思考。網羅思考就如同人機對弈時AlphaGo所採用的窮盡分析法,每下一步棋,電腦就得將所有的可能性都分析一遍,強調決策一定要基於完整的資訊和分析角度。這在超級電腦上或許行得通,但在瞬息萬變的商業市場上則是行不通的,一方面商業發展的可能性無窮無盡,另一方面它變化快速,而網羅思考耗時耗力,是無法滿足即時分析的需求而快速的產生解決方案的。

假說思考讓敏捷更加敏捷

假說思考的特色是;於一開始就從事物全貌切入,再來思考如何解決個別問題。這一點與敏捷強調以小增量、多迭代與尋求回饋的方式十分相似。敏捷避開了傳統開發法在前置分析上的時間浪費。但這麼做只縮小了在開發量上資源的浪費,並未減少需要收集資訊量的大小,若是再加上預做假說的思考模式,就可以大量減少資訊收集的範疇(對系統思維System Thinking而言;就是先運用假設來縮小系統的邊界),而在分析、求證上只針對該假設的範疇來進行,在時間上更符合小增量、多迭代的思維,然後在透過驗證假設是否正確的嘗試得到實質上的回饋。做為新假說的依據。所以說;假說思考的方式能讓敏捷更加敏捷,也更能聚焦在一個基於假說上的小增量上頭。也更符合科學精神。

假說思考是來自波士頓諮詢公司BCG的策略思維方法。(請參考内田和成所著的《假說思考:培養邊做邊學的能力,讓你迅速解決問題》,原著標題是The BCG Way—The Art of Hypothesis-driven Management) 是一種思維模式也是一種顧問需要養成的習慣。就是在解題時從資訊還相當有限的初期階段起,就不斷思考問題全貌與結論的方法。先做假說;這麼做可以有效的減少需要考慮的系統範圍,一旦系統範圍縮小了,就能讓我們更專注在小事件的驗證上,小範圍能便於快速的進行驗證,又能以逐步釐清的方式去看見問題事件的全貌。它符合敏捷開發小增量的核心觀念,讓我們專注的聚焦於小的驗證上頭,逐步去釐清問題的看見它的全貌。

要了解自己的第一步,就是做出一個決定 ;然後去質疑自己關於自己的種種預設,去積極考證我們在別人眼裡的樣子,去帶著一種積極的思維和接納自我的態度去追求真實。  

-《深度洞察力》,TASHA EURICH

傳統思維 vs 假說思維 的敏捷性

傳統開發法是認為仔細的分析後就能按部就班地完成專案。相對的;敏捷開發追求邊做邊學,再蒐集足夠開工的資訊時就快速的開工,以應對變化為常態的一種開發方式,進行方法是衝刺(sprint,全力邁進)的小增量、多迭代與尋求回饋的開發作業。傳統對問題的思考模式是認為資訊收集的越多,就越能確保決策會越正確。假說思考法則認為: 捨棄資訊比搜集資訊更重要。運用假說來縮小驗證的範圍,迅速的邁入求解的途徑。

假說思考的好處

1.  解決問題的速度倍增:     以答案為起點的做法,讓該做什麼變得清楚分明。

2. 能夠累積出解題的路徑,有效的「定位問題」: 如果在遇到問題的同時,就能夠在心裡建立「暫時的解答」,便可以很快的去「驗證這個暫時的解答是否正確」。

3. 假說無論對錯,驗證完後(/) 都能夠讓下步更清晰 : 如果目前假說是對的,可以深入分析,並試圖提出可能的解決方案。如果發現假說不對,便可以快速的換到下一個假說去驗證它。

4. 可以有效累績、運用過去的經驗 :「假說」是基於現有知識的最佳解,因此隨著你對於問題的相關領域的了解越來越深,或是日積月累解決問題的經驗越來越豐富,很有可能在一開始就提出了正確的假說。因此假說暫解是善用及累積經驗的好方法。

以假說(設)為基礎的思考方式,是一種以最短時間有效達成目標的方法

小結

敏捷開發Agile development不是一種快速的開發方法,它是應對需求多變的一種開發方法。目的是避免軟體在專案前期花費太多時間進行分析、文件製作的工作上,而在遇到變化時反而因為依循計畫而失去彈性的缺失。波士頓諮詢公司BCG的「假說思考」則更進一步的依據工作者的經驗先進行假說,有效的縮小了問題系統的開發範籌,雖然它是顧問公司所用的一種快速取樣驗證的手法,但在搭配以敏捷化的小增量、多迭代與尋求回饋的增量,就更能展現出它的效益了,也更能符合多變的VUCA時代的問題特徵。

假說思考法是一種顧問的策略模式。是一種吻合科學實驗的方法(若是你沒先做好假設就開始做實驗,當取得實驗數據時;反而會不知如何去詮釋)。它以為在問題出現的前期,即提出假説的好處是能加速解決問題的速度,而且能避免一開始就陷入在資訊洪流因為吸收過多訊息而造成分析上的時間浪費。這是一種基於捨棄資訊比搜集資訊更重要的實際行動。核心觀念是遇到問題時,先「想」或猜(依據經驗而來)有什麼可行的解法,接著再進行數據的收集與分析驗證。也就是所謂的「大膽假設、小心求證」的科學實驗精神。這與我們一般在做策略規劃的流程: 先分析再設定目標然後擬定對策的正規思考方式不同(1.現況、2.目標、3.分析、4. 擬定策略、5.資源投入與建議的五步驟解題流程)。假說思考法是直接跳到最後一步(步驟五、資源投入與建議)上,依靠顧問的直覺與經驗快速的給予解題建議。但它是一種暫時性的答案,還需要驗證,透過驗證才能確認問題的全貌與結論。

《假說思考法》作者內田和成在書裡的定義;所謂「假說」,是指在蒐集資料過程、著手分析之前先做的「暫時性答案」。「假說思考」可說是一種思維模式或是習慣,從資訊還相當有限的階段起,就不斷思考問題全貌與結論。換句話說;是一種刻意發現。 換言之,假說思考法的精髓在於”假設可能的答案”,而這個答案可能是整體問題的答案,特定步驟的答案或是支援論點數據的答案,而它只是一個”暫時的答案”。所以問題來了,如何進行此假設,或是如何提升假設的準確度與深度呢?這便是顧問公司所擁有的實力與經驗了。也就是我們常常聽到的麥肯錫顧問公司Mckinsey或波士頓顧問公司BCG這類的顧問公司,在為客戶提案之前早已完成了”70%的結果”,而這七成的結果其實就是從經驗或過往案例所推演出來的假說結果。說穿了就是依靠顧問們在實戰經驗中累積下來的相關經驗,正是敏捷開發中所謂的經驗主義下的快速產物了。

解決方案先行

所有的客戶都急切的想從顧問口中聽到解決方案,為了有效地說服客戶,我們花費大量精力去尋找合適的資料,繪製複雜的表格,製作大量的PPT,為的是用精準的數據來打動聽者。但這種方法並不怎麼有效,我們的溝通對象根本沒有時間和耐心來聽枯燥的報告,他們需要的是解決方案,而且立刻就想知道!因此假說思考法便顯得如此可貴。因此要持續累積經驗形成模式(pattern)才不會讓我們弄巧成拙。就如《極簡思考》作者Mike Ferriolo所言(註3. 推廣結構化思維);假設是一種實驗性的、可在未來分析中做進一步測試的觀察、現象或疑問。在結構化思維過程中,假設是你在第一步中為問題找到的答案,你之後將以它為核心進行分析,從而將其證明或推翻。不要擔心,在你把方案徹底想好前,你無須將結論與任何利益相關人分享,一些利益相關人直到你做完了全部論證才能看到你的想法。跟科學實驗相同,實驗室的初步假設往往與事實有著巨大的差異,但最終你卻端出了極具價值的原理。請記住,當你埋首於分析的時候,你並不能創造任何價值。

假說先行的思考方式;對於專案負責人PO或資料分析團隊Data Team而言,都是一種先定位後驗證的科學式思維。運用系統思維的說法是一種能讓我們面對眾多的選擇中縮減範圍畫出系統邊界再求證的做法。對專案負責人PO而言,在面對龐大的產品需求時,可以大膽的假設客戶只需要這些足夠的需求,就能接受我們的產品並感到滿意。因此而勇敢的排除了那些次要的功能,選擇依據假設先完成部分的功能,讓開發時間變得簡短了。然後在以客戶的回饋作為驗證,修正假設。若假設是不符合客戶的期望,再修正假設決定是那些功能需要既須開發來滿足假設。對於資料分析團隊言,則可以先鎖定假設,不致於被蒐集到的龐大資料所迷惑,以至於難以做成分析結論。並在持續收集到的資訊中驗證假設是否正確,並持續的修正假設來獲取結論。

註1. 戴明博士的PDCA 循環是針對品質工作按規劃、執行、查核與行動來進行活動,以確保可靠度目標之達成,並進而促使品質持續改善。這個過程也被人們熟知為:Plan-Do-Study-Act(PDSA)。是企業界早已普遍運用的一套「目標管理」流程,透過規劃Plan、執行Do、查核Check、行動Act四階段,確保每次的目標都能達成。

註2. 假說;Hypothesis亦可翻譯成假設,但是為了符合原著上的翻譯,這裡一律採用假說一詞。

註3. 極簡思考by Mike Ferriolo, 迈克·费廖洛。書中闡述的極簡思考法: 結構化思考。結構化思考是被假設驅動的,出於以下幾個原因。這個方法可更快地找出一個答案。你的假設將確定你論證所需要獲取的資訊,並指出哪些資訊與你最終的結論無關,以此能減少你花在無用分析上的時間。假設能讓你以事實為依據去找尋結論,也能讓你有能力找到事實來證明或推翻它。如果你推翻它,你將進入優化反覆運算的過程,直到找到一個可以證明為“真”的建議。你的假設越簡潔,其他人就越有可能理解你的回答和建議。

註4. 如何選擇一個正確的假設?

參考自內田和成的結構思考法

敏捷管理就是善用情境領導

主管需要成為“教練”嗎?

是的,主管需要成為團隊的教練。因為今天組織是以團隊運作的方式為主,已經不是主管一個人所能獨自完成的工作了。主管需要的是去瞭解他們的員工正在做什麼,但是並不是要像每位員工一樣能夠熟練地完成工作。再說;現在的員工並不需要一個權威人物來告訴他們或督導他們做什麼了。相反地,員工需要的是一個能夠傾聽、指導、訓練以及幫助他們的「教練」。身為教練這個角色的首要任務,便是能夠確保團隊成員擁有完成一流工作時所需要的資源。同時;還必須不斷激勵他們學習成長,為他們釐清責任和目標,使他們能提高工作績效,並且在組織內貢獻自己的力量。(參考: 《高績效教練》by: Sir John Whitmore)

主管需要的技能

成為你所負責的(主要)活動的通才。越是高層的管理者越需要是通才。你必須在這個領域上成為通才。也就是說;大多數的主管在他們所熟悉的特定領域內進行管理,只有如此你才能了解團隊成員們所遭遇到的困難。但就熟悉的程度而言;你只需要是一個通才。相反的;「人際關係」是一種能讓成員很好地與別人一起工作的能力,理解團隊的需求,建立良好的溝通,以及激勵他人的能力,這樣的人際技能,反倒是主管所不能或缺的。

.

主管每日實踐守則

.

由於主管是通過其他人來完成工作的,所以對於團隊而言;他必須擁有良好的人際能力來溝通、激勵、協商、授權和解決衝突。尤其是對工作上的概念(conceptual),雖然沒有必要懂得工作上的細節,但是能夠擁有足夠的概念,在就實際而言,這種「深入的概念」將更能幫助管理者做出更好的決策。尤其是對相關領域的熟悉程度,也就是需要有更充足的領域知識(domain knowhow),以建立足夠溝通的良好模式。
.

部屬發展模型(情境領導模型 II)

.

情境領導理論 Situational leadership theory

主張領導風格應該根據具體的情境而有所不同。保羅·赫塞(Paul Hersey;老師)和他的學生肯尼斯·布蘭查德(Kenneth Blanchard)所共同提出的理論。情境領導關注於所謂的員工成熟度。成熟度(readiness,D1-D4) 指的是員工能夠並願意完成某項具體任務的程度。赫塞布蘭查德定義了成熟度的四個階段:

階段1 = D1:員工既缺乏能力但滿腹熱情時。【熱心的新手

階段2 = D2:員工能力提升但仍需協助,且無意願從事必要的工作。【半生不熟

階段3 = D3:員工有能力但卻不願意做領導者希望他們做的工作時。【專家】

階段4 = D4:員工既有能力又願意做領導者希望他們做的工作。【獨自處理】

該模型主要在說明的是作為一位領導者,你應該怎麼去做。也就是針對不同的階段你該如何進行溝通,就是依據成員的行為反映來進行不同的溝通方式和類型。

隨後布蘭查德又提出進階的「部屬發展模型」Development Level of the Individual 4階段,以員工的工作能力工作意願,來判斷員工處於哪一發展階段,並據此將部屬個人的發展階段與主管的領導風格連結了起來。因為是藉由不同的工作任務來界定員工處於哪種發展階段,所以當某一項工作任務更換時,就得重新診斷員工的發展階段。(參考MBA智庫百科)

情境的S1-S4 相對於成熟度的D1-D4:

低能力、高意願 D1:部屬為新進員工時,雖然工作意願高,但對工作技術不熟悉。這時領導者應採取「指導型S1領導風格,協助員工。

能力平平、意願低D2:部屬的能力雖然有所進展,但在工作上還是需要幫助才能完成,遇到困難時,部屬工作意願跟著降低。此時領導者應採取「教練型」領導 S2,除了指導外,還要給予較高的支持行為,傾聽部屬的困惑。

高能力、意願不定D3:員工有足夠的能力,但欠缺獨當一面的自信,或不確定自己能不能做好,此時適合採用「支持型」領導S3,由領導者和部屬一起進行決策。

高能力、高意願D4:員工有充分的能力和意願,對自己的能力充滿自信,甚至可能比領導者更有經驗。此時領導者應該採用「授權型」領導S4,由部屬來決定工作的計畫和組織,偶爾過問工作的進展情況和遇到的困難即可。

結論

情境領導模式只是一種可以幫助團隊成員成長的領導方式的簡易判斷模式。強調的是領導者應該依據成員的「成熟度」來決定採用的領導方式。目的是幫助團隊成員的成長。只是一種易於運用的領導風格。藉由D1~D4的成熟度分析來決定領導者需要採用的管理模式,也就是 S1~S4情境運用。

敏捷教練也能依據這個模型,指導主管應該前進一步去協助團隊成員,或後退一步讓團隊成員自己做決定。也就是:

  • 當成員處於S1情境: 缺乏能力但滿腹熱情時,這個時候主管無法光靠引導的方式就能讓成員順利完成任務時,主管此時應該要勇於前進許多步,主動協助完成工作。
  • 當成員處於S2情境: 成員的能力提升了但仍需協助,且工作意願不足的時候,主管此時應該要前進一步,除了主動討論如何完成工作之外也給以適當激勵是十分重要的,並協助他做好正確的決定。
  • 當成員處於S3情境: 有能力但卻意願低的時候,此時主管應該要後退一步,主動與該成員一起討論如何完成工作,但將決策交予該成員。譬如: 下屬跑來請示應該如何完成工作時,此時主管對有能力完成工作者,不應該直接給予建議。反之;應該詢問該成員,準備如何完成他的工作,採取退一步的方式,引導他想出對策,不直接給建議。
  • 當成員處於S4情境: 既有能力又有意願做領導者希望他們做的工作時,主管應該後退許多步,授權下屬讓他能完全獨自完成工作,主管只需稍加留意即可。全權交予下屬自行做決策,只在必要時予以提醒協助。

應該授權或賦能到什麼程度與方式? 應該視(依據)成員的成熟度來決定如何做前進或後退的指導方式,並非一意運用引導(Facilitation)的方式,或是全然採用命令干預的方式進行管理的措施。傳統上;大多的主管只會採用一到二種策略來進行領導下屬的行為,赫塞和布蘭查德情境領導理論則提供了更完整的視情境決定領導方式,值得敏捷管理者參照。

.

參考: 《高績效教練》by: Sir John WhitmoreMBA智庫百科.

狹義與廣義的敏捷

敏捷開發是指向軟體界的新型開發方法,但敏捷 Agile 二字卻被普遍拿來應對世事多變下的一種變革方式(敏捷變革),在這裡做了一下區分,以狹義的敏捷指向軟體開發,廣義的敏捷指向我們在面對模糊不清與無知的情境下的敏捷性。

敏捷開發的定義

敏捷軟體開發(Agile software development),簡稱為敏捷開發,是一種從1990年代開始逐漸引起廣泛關注的一些新型軟體開發方法(著名的XP極致編程、Scrum框架…等)的稱謂,是一種以人為核心、迭代、循序漸進的開發方法。在敏捷開發中,專案以迭代的方式建構(切分)成多個子項目,各個子項目的成果都經過測試,具備集成和可運行的特征(也就是產出所謂的潛在可交付的小增量,目的是較具有意義跟讓客戶容易回饋)。這是一種原本用來針對軟體開發的改善方法,但由於世事多變而且越見複雜(有一種VUCA時代的描述,VUCA: Volatility易變性、Uncertainty不確定性、Complexity複雜性、Ambiguity模糊性的縮寫),人們逐漸意識到多變是一種不可避免的現象,因此很多組織便開始改變原本漫長的開發生產過程,轉而希望借助推行敏捷化的力量來加快適應的步調希望能藉此跟上市場多變的腳步。

敏捷狹義的定義;指的是針對軟體開發流程的改善。
敏捷廣義的定義;則泛指所有的行為規範。

.

何謂敏捷?

.

敏捷的狹義觀念 -應對需求多變

狹義的定義;指的是針對軟體開發流程的改善。敏捷是一種應對需求多變的開發方法。它並不是一種為了求快而開發出來的開發方法(敏捷開發為何比較快)。相對於傳統習慣於先做全盤的規劃之後在按部就班的開發方式,敏捷是以小步開發的方式,採用先輪廓再逐步細化的開發方式,透過客戶的參與與回饋,來讓描述產品功能的需求全貌越來越趨近於穩定。所以「小增量、多迭代與尋求回饋」便成為了描述敏捷開發時的代名詞了。

敏捷的廣義觀念  – 應對模糊不清與無知

廣義的敏捷定義則超越了軟體開發的領域,以提升敏捷性為主導,但相同的是仍然以透明、檢核與調適持續改善行為模式為核心。「低結論需求、多嘗試、多聽取建議」三個原則是針對我們的「無知」而來。這裡所謂的無知;指的是對問題的缺乏知識或是錯誤的認知。換句話說;當我們面對問題時,好的敏捷性可以協助我們減少在無知的情境下,因為過大的時程壓力而做出錯誤的決策。當我們在面對未來(陌生的工作)時,一種必然的無知時,希望這三個原則可以幫助你刻意的去發現正確的解題方式:

  • 低結論需求 Need for closure

當遇到問題時,能夠接受其中的不確定性,也就是能夠忍受心中在矛盾下所產生的不舒服,並克服對獲得結論的需求的急切程度,經驗告訴我們;當結論需求的程度越低時便是越能夠靜下心來做仔細的分析解題,反之;結論需求的程度越高者便是在當下急切於獲得對於問題的結論,越是急切的心,自然就越容易產生錯誤的判斷。這便是所謂的「敏捷性敏捷性越高的人,越傾向於能夠處於不確定的困擾之下仍然能夠仔細且穩定的工作著(延遲決策與看見全貌,請參考: 關於決策時的無知)。也就是更能接受問題的不確定性,更能克服因為不確定性所帶來的焦慮感。(參考結論需求量表,註1)

.

所謂「結論需求」,是指人的大腦多半無法容忍矛盾或模糊(因子),故而急需某種結論來消除焦慮。對這種需求結論愈高,固然可使一個人堅定不移地行動(因為有著很深的信念),但也更容易誤判。
by: Jamie Holmes

.

面對模糊不清事務的焦慮感容易導致錯誤的判斷

.

.

 碰到困難的時候,務必停下來徹底思考目前的狀況,想通透之後,再定出你自己的解答!

-葛洛夫給你的一對一指導

  • 多嘗試

嘗試是處理模糊不清時的最佳方式,它是一種學習的心態,一種勇於創新、實驗、冒險的精神(新新創業時的MVP方法,Google 的設計沖刺都是一種先嘗試的作法)。這種精神能夠接受失敗是最好的學習,也就是遇未知的事物時有意願去嘗試的科學實驗精神。當你面對無知時,最好的應對方式便是假設自己一定有不知道的地方,然後透過各種方式去發掘它,嘗試則是克服疑惑積極的運用實驗的方式來驗證它,因此要勇於嘗試。

知識的獲得經常是先抽象(模糊)之後逐漸弄清楚的,當我們遇到專案有重做一次的機會時,首先要考慮的是針對那些模糊不清的地方,設法透過實驗或其他方式嘗試把它弄清楚,以奠定重作一次的知識基礎再去做,自然會做得更好。

  • 多聽取建議

有別於特定的回饋方式(例如Scrum的檢核會義Review Meeting,針對的一個小增量的意見回饋), 在我們不知道自己不知道些什麼的時候(也就是處於無知的無知的時候),最便捷的方式便是從別人的角度聽取意見,由聆聽他人的說詞去審視,並嘗試用不同的視角去詮釋問題的原委,藉此來讓自己能夠更客觀的看清楚問題的全貌。

結語

應對無知的二個利器,限制理論與刻意發現。限制理論(Theory of Constraints,TOC)是一種系統思維,它是由以色列學者伊利雅胡·高德拉特所發展出來的一種全方面的管理哲學,主張一個複雜的系統隱含著簡單化。但是它一定存在著某種約束,這些約束造成他無法達到最高的效率,而我們只有透過持續的去發覺並解決最大的約束才能提升效能(註3,限制理論範例)。這是一種針對系統全貌下的持續改善思維。這種思維跟我們說,即便讓你一次再一次的進行重作相同的專案,你仍然會受到某些約束(無知始終是你最大的約束),它是限制你的效能無法無限制提升的最大約束,TOC這個系統思維工具的最大特色也就是在形容一個系統裡具有著相互關連的動態屬性,當你想要提升系統的效能時,只能持續的去發掘最大的限制(如果你處理的不是最大的約束時,你可能是在做局部優化的動作,對提升系統整體的效能將沒有幫助),然後改善它,接著再去尋找下一個最大的約束,繼續改善下去。

BDD之父 Dan North 於2003年提出了刻意發現(Deliberate discovery) 的概念,目的是用來應對專案開始時的無知(請參考「無知的無知」)。多年來的成果,是鼓舞了業界發展出來許多好用的工具用來協助我們發覺未知的困擾。下圖右側是精實開發的處理原則: 延遲決策與看見全貌來解決無知,上半部則是一些發展出來的實用工具。

一些前置處理的工具可以協助我們進行刻意發現

狹義的敏捷是用來應對軟體開發需求的多變時的處理方法,口訣是: 小增量、多迭代及尋求回饋。廣義的敏捷則是用來應對處裡事務時在情境上的模糊不清與無知用的,口訣是: 低結論需求、多嘗試多聽取建議。二者都能協助你提升敏捷性。至於何時運用它則看你所扮演的角色而定。但核心思想都是透明、檢核與調適。舉例來說: 如果你身為主管的話,透明對你而言就是開誠布公,檢核與調適則是能夠在授權後進行賦能的作為。

.

註1. 結論需求量表,為 唐娜.韋伯斯特(Donna M. Webster)和 克魯格蘭斯(Arie Kruglanski)於1994年所發表,共42道問題,下面節錄的是經過心理學家尼爾.羅伊茲(Arne Roets)和 愛連.馮.海爾(Alain Van Hiel)在2010年的15題精簡版。(可參考《無知的力量》page 115. 及 google圖書,《石頭湯實驗:文化隔閡為什麼如此頑固》)

給分區間:  1分: 完全不同意 6分: 完全同意

  • (  ) 1. 我不喜歡不明確的情境。
  • (  ) 2. 我不喜歡,可以有不同答案的問题。
  • (  ) 3. 條理井然、作息規律的生活適合我的個性。
  • (  ) 4. 要是無法理解生活中為何會發生某項事件,我就會很不自在。
  • (  ) 5. 如果團體中有人和其他人都意見不合,我就會很生氣。
  • (  ) 6. 我不喜歡落入無法預料未來發展的局面。
  • (  ) 7. 下了決定後,我會鬆一口氣。
  • (  ) 8. 遭遇麻煩時,我拚死也想趕快解決它。
  • (  ) 9. 要是沒法立即找到方法解決麻煩,我很快就會變得煩躁。
  • (  ) 10. 我不喜歡和行為難以捉摸的人在一起。
  • (  ) 11. 我不喜歡聽人說起話來模稜兩可。
  • (  ) 12. 建立前後一貫的生活常規讓我更能享受人生。
  • (  ) 13. 我喜歡確切、有條理的生活模式。
  • (  ) 14. 在形成看法前, 我不常欲徵詢別人的意見。
  • (  ) 15. 我不喜歡難以預料的情境。

填寫問卷後,加總起來得分在57分以上者,表示當下的結論需求高於平均值。

註2. 《無知的力量》作者: Jamie Holmes,書裡面描述無知與知之間的模糊因子以及我們如何來應對它。

註3. 工程師的機會成本,請參考限制理論的提水救火範例。

關於決策時的「無知」

人遇到問題,就是無法忍受心中的矛盾,一定得從矛盾之中找出一個脈絡來脫逃這種因為矛盾所產生的不悅,才會覺得舒服。而這種不斷的去解決這些困惑的動力,其實就是人們探索這個世界的方式。

-追求知識的衝動(結論需求)

.

.

知識的情境

如果全然「無知」因為完全不知道,自然對事情不會有任何感受,也就讓無感或是麻木佔領了心靈。如果真正「」道了;對於來來往往的資訊,可能會會心微笑或是產生認同領悟,心中會有一種篤定的喜悅。至於在無知與知之間則充斥著模糊,越是靠近無知就越是覺得模糊,若是模糊逐漸減少了便是更接近的領域了。全然的知或許是Dr. 米哈里(註1)所謂的「心流」吧!

所謂的知識;就是要帶領我們由無知穿越模糊並持續累積正確資訊再邁向知的依據。但模糊是個大泥沼,它會帶來猶豫、徬徨,在我們心中產生焦慮不安,

如果問題一日不解,困惑、疑慮就會持續佔滿心頭,這時候我們可能會說無知反而是一種幸福,這種矛盾的心態只有在我們找到問題的解答後才可能平復,也才能由模糊因子的降低換來較舒服的心態甚至是喜悅。

模糊因子決定決策品質

焦慮的心態是做決策時的一大陷阱,當我們處於時間緊迫或是承受重大壓力時,這個時候所做的決策,要如何維持一定的品質呢? 此時;對問題相關領域了解的程度可能是決定性的因子(或可稱為模糊因子)。基本上;人在責任感的驅使下,都會想盡辦法去降低對問題認知的模糊性,此時模糊因子的大小正好與決策品質的好壞成正比。因此設法降低模糊因子,才能形成好的決策品質。

在這個資訊爆炸的時代,我們缺少的經常不是相關資訊而是缺乏過濾相關資訊的能力。有一句對發明家的評語在這裡派得上用場,那就是擁有較寬廣的視野與願意深入理解的心。正是遇問題先看見問題的全貌,然後才去深入探索問題。這是降低模糊性的好方法。對應到精實原則(Lean principle)則是建議我們要盡量延遲決策(Decide as late as possible),避免直覺反應式的直觀決策方式,並以著眼整體(See the whole)的方式來處理問題。

.

無知的情境

.

面對未來,我們將必然的處於一種無知的狀態。當我們思考如何應對的策略時,也就是思考機會成本,其實就是在思考決策標準或價值觀。

.

小結

當你要做決策時,面對未來的不確定性,存在著一定不可避免的「無知」。你唯一能做的就是在做決策之前設法降低對問題領域的模糊性,也就是增加你對問題的相關知識。上圖是在描述無知的情境,介於「無知與知」之間的模糊會引發的一種心理狀態一般稱為「猶疑」或「徬徨」,這種心態會「放大」情緒。猶疑的人首先會感到焦慮,而焦慮會讓人更加痛苦想盡快解決問題(註3. 結論需求)。反之;解決問題的樂趣會令人帶來愉快。(短暫的無知是一種樂趣;很多好笑的惡作劇、幽默的笑話之所以好笑,都是從對事情的無知、論述的猶疑開始,在發現真相之後,才會讓人忍不住笑出來。)

當我們在全然無知和全然知道時,心情都很篤定,此時不會產生困惑。但一旦我們有一絲感想又覺得不是很清晰了然時,一種困惑的心情便會自然地染上心頭,這是一種對模糊知識所產生的猶豫、徬徨,它會讓我們感到焦慮,一種莫名的不快,我們會自然的催促我們趕緊搞定它的行為,就是試著去找出為什麼會這樣的原因。但是在模糊性過高的情境下做決策,往往會由於對訊息過濾的過於倉促,而做了錯誤的判斷。這是不智的行為。當我們帶著焦慮做決策時,若能夠後退一步,先看見事態的全貌,設法降低模糊因子,並在延遲決策的原則下再做決策。則因為無知的情境而做了錯誤機率就會顯著的下降了。

圖下方的「未意識到的無知」與「意識到的無知」係參考 安.克爾溫 (Ann Kerwin)的無知矩陣如下圖。她描述到顯性知識與隱性知識(必須實際經驗過才會擁有的資訊),當我們再處理未知的事務時,必須先確定這種模糊的未知是顯性知識(一種透過閱讀就能學習到的知識)還是我們應該做成模型(prototype或 MVP)才能確認的知識,以降低我們的無知(減少模糊因子)來做出更好的決策。

.

培養敏捷性(agility)是應對不確定性的最佳良方。

.

安·克爾溫的無知矩陣

.

註1. 《心流:高手都在研究的最優體驗心理學》為 米哈里.契克森米哈伊 1940年的作品。(Flow: The Psychology of Optimal Experience)

註2. 《無知的力量》為 Jamie Holmes 的作品。

註3. 人們急於尋求問題解答的特性稱為「結論需求」Need for Closure。當結論需求越高的人士,越是會急於下決策而忽略了去仔細推敲眼前資訊的可信度。他在感知到問題時的焦慮程度也會越高,越想要盡快盡快取得明確化的情境。

註4. 「歷史終結」 The End of History Illusion,描述的是人容易將過往設想成故事彷彿具備的情節,必然的朝某一個方向去發展。而忽略了過去、現在及未來都是未知待發展的。

安全的失敗 safe to fail

找一個會議來刻意讓他失敗,是一種絕佳的safe to fail.

.

讓會議失敗是一種safe to fail的好嘗試

.

開會是工程師工作時間的最大殺手

會議是任何組織都不可避免的一種意見交流、訊息傳播及溝通的活動。但對工程師來說會議卻是工作時間的最大殺手,我們都知道;工程師要在座位上專注而用力地敲擊鍵盤才有產能,任何打斷他們思維的事務都是干擾,都應該盡力的去避免。因此在專案成立之初將整個團隊一起關進一個隔離空間(成立所謂的戰情室);根絕任何(會議)干擾,將立即有效地提升團隊的產能(尤其對那些有deadline 的專案更有幫助)。

無心開會;專案在緊鑼密鼓時,工程師大都不會把心思帶進會議室,開會時;你會看到團隊大部分的成員帶著筆電進來開會,明顯的他們根本無心來開會,此時會議的效能想當然就不會太好了。做顧問時我會建議主管體諒一下,在會議剛開始時讓在趕進度的工程師,能有自由選擇是否參加(非必要)會議的特權。相對的;也可以看出團隊裡目前誰的壓力最大,最需要協助了。正確的作法是以先行溝通的方式來避免這種現象才是。反過來;讓工程師把腦子裡在想的事情不要隱藏著,公開出來;讓透明化使得大家能夠知道何時能夠幫你,才是聰明的工程師應該有的做法,讓自己融入團隊,與團隊成員分享協作才是上策。

會議太多是溝通不良的徵兆

幾乎所有的主管都整天不停地忙於開會,是受會議干擾最嚴重的一群。要知道運用會議來吸收或分享訊息實際上是成本最高的一種作法,團隊基於有許多事情我們必須知道就需要為此招開一個會議嗎? 如果能夠透過其他方法讓訊息快速共享不就可以擺脫這種聚集群眾來開會的形式了嗎。當然還有另外一種方法,就是你可以選擇相信、信任的方式,相信他們能做得很好而你不必知道它們是怎麼做的;這就是比較高深一點的團隊自組織了。

敏捷Agile以透明、檢核與調適的過程來解決組織溝通上的問題,要求以小團隊做出發點,並以固守時間盒(time boxing)的會議方式來簡約時間與資源,然後依靠每日一次的短時間的站立會議來實踐它。其中的Scrum框架更以簡潔易懂的流程方式擄獲了變革者的心靈,成功的改善了舊有傳統開發方式的缺失,讓流程更為靈活更為多樣性。

※《賦能》一書裡則以一、讓互信和目標共享。其二、以小團隊構成大團隊(信息共享、共享意識與自組織) 這二個宗旨來化解傳統組織層層節制的架構限制,解決溝通上的屏蔽,減少會議的干擾,追求高效運作的能力。

讓會議失敗

大家都知道怎麼開好會議(如何高效能的開會,是職場必備的常識),例如: 一開始就要講清楚會議的目的以及希望達成的目標。重要事項通常不是在會議上研議出來的,而是在會議前就先溝通好的,會議只是用來迅速達成共識用的。主講人的會前功課就是要讓大家都帶著有概念的方式進來開會,而不是臨場短暫的聽取簡報就做好決定該怎麼做的。我們經常會犯上知易行難的問題;現實中大家真正開起會來卻與認知完全不同。開會時,有帶筆電的、看手機的比比皆是,還有到場才問開會主題是什麼的? 到底是什麼原因造成大家都知道的最佳解卻沒人去依循呢?

這是一種典型的「霍桑效應」,人們在沒有被強迫、要求下或是沒有產生痛點的時候,惰性便會戰勝一切,容易將錯就錯不做決擇的一種怠惰的自然行為,就像是暑假作業一樣,不到假期最後是不會去做的,也就是暑假快要結束了那種急迫性才會敦促我們趕緊去做的。 所以要讓會議失敗。

因為;失敗學到的比成功還多。讓會議失敗團隊由失敗中學到教訓。打破大家將錯就錯的心態,開始選擇有效率、認真的參與會議,實質上,是協作出好的、有效能的會議。如果會議的一大目的是獲取共識的話,自然是獲得與會者的協作才是達成會議高效的基礎。所以要讓它先失敗,大家體會到痛點之後,自然容易痛定思痛選擇對的開會方式了。

.

「失敗」迫使人在事態背離盤算時,重新省思舊有的篤定信念,那些原先以為理解的事情成因,這時都不得不強行加上模糊因子來重新檢視了。

.

結語

會議開多了就很會開會了嗎? 答案恐怕是相反的(反而容易麻痺),一個敏捷的團隊除了5大制式會議之外,應該盡量減少會議的中斷,讓工程師能夠獲得充分的工作時間,效能自然會越好。但就是有一些非開不可的會議;試問我們能不開部門會議嗎?能不開主管周會、月會嗎? 需不需要開這些會議呢? 相較之下;需要斟酌的是機會成本;當不開會的損失可能要大於招開會議時的時間損失時,就應該要開。因此會議招開的效能才是真正平衡損益的關鍵,也就是高效的開會獲得最多損失最少。

回顧三步工作法的第三步、文化 Culture ;用意在增強對產品的信心,營造一種勇於創新、實驗、冒險的環境及高信任度的文化。其中頗為引起爭議的,就是實驗與冒險,這二者都是為了學習,而失敗時所能學到的通常都比成功時還要多得多,因此就有所謂的「安全的失敗」Safe to fail的說法。但除非你是在實驗室裡工作,試問誰願意失敗呢? 又有哪一個老闆能接受員工經常的失敗呢? 身為顧問經常會聽到來自CEO們的要求:『盡量不要失敗,如果一定要失敗的話麻煩讓失敗盡可能的縮小。』可見大家有多(都)害怕失敗。建議你: 運用失敗的會議來改善團隊的協作。

會議是一種團隊的協作。會議開得沒有效能或沒有達到目的,對於團隊而言是一種協作上的失敗,但這種失敗卻是最常被忽略的失敗,若是能在事後進行回顧,共同檢討失敗真正的原因,即便之前的會議失敗了,只要用心去回顧是什麼原因造成失敗的,此時的收穫恐怕能讓團隊學得更多獲得更多,而這不就驗證了「失敗時所能學到的通常都比成功時還要多得多。」 敏捷在成立新的團隊時,有經驗的 Scrum Master 通常會將接下來的第一個Sprint 改成一個星期,然後刻意的讓它失敗,也就是讓團隊的第一個協作的Sprint 沒有能夠達成它的預定目標,聽起來是沒有依循青年守則所謂的「好的開始是成功的一半」Well begun is half done的西方諺語。但其實這種失敗反而能讓團隊學到最多,對於團隊未來的協作十分有利,因此是一種刻意的失敗作業,也是一種典型的Safe to fail的模範。而刻意讓會議失敗,也具有異曲同工之妙

.

與成功相比,我們從失敗中可以學到更多;與讚美相比,我們從批評中可以學到更多。

-金.斯科特

.

三步工作法 The three steps.

.

如何解決軟體系統太複雜?

複雜性是不可避免的,這就是進化的原理。

.

考慮系統複雜性對開發速度的影響因素

.

(紅色區塊: 不利於開發速度, 綠色區塊: 有利提升開發效能, 黃色區塊:需適度選擇, 紅線: 造成下降, 綠線: 造成增加.星號: 改善重點, 倒三角: 危害重點)

.

這裡的解決複雜性,所指的是軟體開發單位如何提升開發速度,想方設法加快開發效能;這可能是所有的CEO們都夢寐以求的,因為有太多的需求在排隊等著要作了,但卻偏偏卡在這裡,一定要設法來加快開發單位的效能才是。身為顧問,我經常受邀去診斷研發單位為何效能不彰的問題,習慣上我都會私下先跟負責人強調:「一個夠好的需求,勝過作好無數個實用的功能。」在開發之前;多花一點時間排好需求開發的優先序才是上策。但怎麼說了卻無法激發當事人的反思(基本上從來沒有生效過)而有所改變。很快的他們就會要求各個部門配合我進行診斷作業,然後催促著要我交報告,急著作決策,那種急切心情很教人激賞,我又怎能辜負它呢。

上圖是參考 Targetprocess公司 Michael Dubakov先生在Blog上所發表的著作(註2. 原文),它是拿來分析軟體開發速度相關元素的極好的參考資料,這裡我僅僅擷取與系統複雜性有關的區塊翻譯成中文。加了一點實作上的考量(原文抽象度太高),但在右上角我加進了「架構設計」的影響,並給予它和程式技巧區塊一個AND的屬性。意思是好的架構與好的程式技巧都能消減系統的複雜性。而程式設計巧甚至會受到架構設計的制約(限制),所以我擅自加了一個綠色的區塊跟一個橢圓的符號。因為這也是我最常建議開發單位進行改善時的起始點(所以用三顆星來顯示)。

採用AND橢圓的符號是為了關聯性,因為人們經常只看到一個現象就快速的針對現象進行分析與改善的動作,完全忽略了與其他項目之間相關的交互影響,這是系統思維的基本要求;要看見全貌而不至於見樹不見林。
快速直覺的抉擇方式,往往缺少了深思熟慮

.

針對解決複雜統架構實作的通則

.

技術債 Technical debt

這個觀念是由Wiki之父Ward Cunningham先生提出來的,也是開發單位效率不彰最常見的元凶,就是只知道要求開發速度(註1. 技術債的真正定義,指工程師挑選了實踐非最佳解決方案或編寫非最佳程式碼的刻意決定,以便能夠更快地發佈軟體功能。),而忽略了自己正在提油救火,讓約束(限制你開發速度的瓶頸)變得更大了。給它二顆星是因為我們應該正視並支持工程師適時作正確抉擇的心態,勇於去挑戰技術債才是對提升效能作出最好的貢獻。

開發單位其實在邀請外部顧問作診斷之前,都已經作了自我改善的努力,而他們所作的努力也不是完全沒有效用,只是經常是改在所謂的最大的限制之前,因此看不到功效,成了一種無效的優化(局部優化,參考工程師的機會成本)。身為顧問必須避開重蹈覆轍,所以要先找到最大的約束才能開始解題(請參考限制理論)。

.

一個好的需求,勝過作好無數個實用的功能。

.

程式碼的黑洞

人類比病毒要複雜得多了(但這並不意味著人們可以更好地生存著,事實是能活的最久的是適應性最好的,而非最強大的)。寫程式是一種複雜性呈現指數型上升的拓普結構,一定會越寫越複雜的,當程式寫得越多,細部的邏輯就會越來越難以記得清楚也就越見複雜了,然後維護的負荷也跟著越來越大了。這是不變的真理,我們要學會(也只能夠)適應這種複雜性,然後避免寫出複雜的程式,寫程式時要努力去追求簡潔而不是快速,正是所謂的簡約至上。

學會刪減程式碼的習慣

程式碼一旦被發布出去後就很少有人會去刪減它了(執行的好好的,我為什麼要去改它,萬一改壞了怎麼辦),即便你覺得這段功能碼根本沒有人會去呼叫到它(所謂的死程式碼),你還是會留著它然後幻想有一天你會需要它(它一定會再被用到的,一種沉沒成本的謬誤)。所以我們在發布之後,就變得只增加程式碼而不會去刪減程式碼了,當程式員寫越多的程式就背負越多的維護債。這是一種非必要的複雜性(它會間接的拖慢你的開發效能),但你因為不敢刪除它因此就會一直背負下去,但其實刪減上線程式的習慣不但可以增加組織實施DevOps的能力,又能延續產品的生命週期,還能讓維護作業更輕鬆些,CP值極高。但要怎麼做呢?

上線後的重構作業

一般的重構作業指的是寫完程式後或在code review 之後立即進行「重構程式碼」的動作(重構程式碼時是既不修正錯誤,又不增加新的功能的一種行為)。它是用於提高程式碼的可讀性或者改變程式碼內部的結構與設計,並且移除死程式碼,使其在未來更容易被維護。在極限編程式設計(XP)中,重構需要自動化的單元測試來支援(馬丁·福勒的名著《重構》是值得經典的參考書籍)。但這裡所指的是更需要勇氣的在上線之後作重構的程式碼,目的是;刪減那些所謂的死程式碼,就是沒有被用到的功用、無人在使用的程式碼。它需要支撐的就不只是自動化的單元測試了,而是完整的 DevOps作業(經典的思維問題是: 漏改一行程式碼你需要多久才能修正它呢?)。

.

漏改一行程式碼你需要多久才能修正它呢?

.

讓新人快速入門的好方法,也是解決複雜系統開發、維護的良方;是

建立部門好的 knowledge Base 系統,運用好的文件資訊揭露系統的複雜性。

.

結語

作為改善開發效能顧問的雙管齊下手法;一是運用敏捷與精實(看板)來改善開發流程的效能。另一是深入商業領域探討對此領域(domain)的技術債。上圖中綠色的區塊;是指可以增加開發效能的行為。常用的起手式是實作看板;讓看見瓶頸就能知道如何改善的一種透明化的視覺驅動改善方法)。再來是對技術債進行盤整,這是因為許多開發部門因為專案時程太趕了,選擇長期忽略會拖慢他們開發效率的技術債(只增不減無視於技術債的存在,沒有將解技術債的需求排進正常開發流程),這是人為的因素,可以運用架構與技能(Skills)的提升來避免它。其它的綠色區塊: 嚴謹的開發紀律(敏捷所謂簡單規範)與短時間激勵(對團隊運用的激勵方法增加短時間的產能)則屬於管理上的措施,需要與主管一同配合實施(這屬於人事的問題,老實說;比較難有短時間的改善成效)。

紅色的區塊;是指增加系統複雜性的行為。給「不穩定緩慢測試」二個倒三角的原因是效能不彰的團隊多半是因為返工過多的原因(做一次整合測試要花上大半天的時間),說穿了;就是Bugs太多了。團隊花過多的時間在返工(處理同一件事)上。解題之道是重視測試讓測試變得快速而順暢,自然能讓團隊願意花時間去作測試,能更積極的去重視開發品質,有趣的是當你重視測試的時候,團隊的紀律會自然提升,這一點也有助於推行「嚴謹的開發紀律」的綠色區塊最後;是大家都喜歡的自由式coding(Cowboy coding),一種自由coding的模式,老實說;我們都是這麼開始的,一種可以充分享受coding樂趣而不需要背負任何責任的行為模式,可惜的是;現實中每一行的程式碼都有它必須正確完成任務的責任,我們要為軟體產品負責、對團隊負責所以責任大於自由,我們必須嚴謹的遵循程式員的開發紀律,遵守團隊code review裡的規範。

黃色的區塊;是指作多了反而降低開發效能的行為。例如過多的重構或是花太多時間在解技術債,都會降低開發團隊的效能。

要解決軟體系統太複雜的問題;需要在架構上、coding技巧上以及管理層面上進行改善,許多開發單位的主管都以為能夠雇用到更優秀的工程師自然就能克服更複雜的系統問題(有一點銀子彈的味道),乍看起來這個想法好像是對的,但在現實環境下這種想法是行不通的(可能有一點用),因為專案工作不是單獨一個人就可以完成的,開發團隊需要頻繁溝通才能協作或必須先問清楚(在複雜系統之下,光是要弄清楚應該找誰來問問題,這種問來問去的溝通本身就是最大的成本)就可以佔據掉任何一個聰明人的所有上班時間了,因此你很難只靠優秀的人才就能有效的降低系統太複雜的問題。你需要持續去進行改善,但在改善以前需先分析目前最大的瓶頸(約束)在哪裡,針對它來進行改善。若是順序弄錯了先改到最大瓶頸之前的約束,則對達成目標或提升整體的效能都不會有所幫助的(請參考限制理論中的關鍵鏈)。

.

工程師的溝通;就是你中斷我、我中斷你,彼此都無法專注的工作了。

工程師的會議;就是大家一起暫停coding的作業。

.

鍊條的強度取決於最脆弱的一環,而不是整體的強度

.

註1. 技術債的真正定義

這個觀念是由Wiki之父Ward Cunningham先生提出來的,技術債務是一種機會成本,工程師挑選了實踐非最佳解決方案或編寫非最佳代碼的刻意決定,以便更快地發佈軟件。如果工程師是在一種無知的狀態下,設計了不好的解決方案,就不能算是技術債,純粹是程式設計的技巧太差。

註2. 參考 Targetprocess公司 Michael Dubakov先生的文章,原圖如下: