這是我今年的第一場公益演講，直播課程二個小時對象是中國DevOps社群，所以PPT都是簡體字，這個時間長度已經是我的聲音所能負荷的極限了。所以講起來異常的辛苦，然後直播又是沒有觀眾的，即便是你問了一個問題還是得自己回答，講了一個笑話也不用等笑聲停下來才能繼續再講。就這樣一口氣要講二個鐘頭完全沒有停下來，好累! 這裡把內容記錄下來，因為有些主題蠻有時代價值的，值得再三玩味。(疫情的關係，今年台北DevOpsDays2021 我也講這個主題，又增加了一些資料，因此繁中、簡中的資料混在一起，請包涵)
顧問公司的策略會議
顧問公司在接到案子時，會先召開一種策略會議，它聚合了有相關經驗的顧問們大家共同針對這個案子來進行分析，給予主事者各種建議說明跟假設，讓主事者不是從零開始。它讓顧問在出門前已經完成了大部分的作業。
【破題】
開發者體驗DX是由於UX設計師表現傑出而來，他們成功的讓本來應該越來越厚的使用者手冊反而變不見了。讓使用者可以直覺地完成80%的操作工作卻完全不需要輔助說明，稱為直覺式設計，UX設計師針對使用者畫像(user persona) 假想設計出一系列的步驟，讓使用者直觀的完成它的工作，並預期得到一種良好的體驗，願意下次繼續採用我們的產品。我們把這個理念延伸到開發的作業上，開發者就是那個使用者，而他在開發過程中的各種感受就是「開發者體驗」了。
若說UX設計師的目的在讓使用者感覺良好，下一次願意再使用的話，DX設計師的目的就是讓開發者因為感覺良好，而能夠更好、更快速地完成任務。這種換位思考，讓人很容易理解它們之間的關係。
推廣開發者體驗的初衷
是因為自己還依稀記得初次寫程式時卡關的感受，將近40個年頭過去了，哪種刻苦銘心的感受你是一輩子也忘不掉的。因為不希望下一代的程式師還是有同樣的體驗，這種不好的體驗在這個時代其實是可以通過刻意的設計來避免改善的。老實說；沒有程式員應該單打獨鬥去面對所有的難題的，因為現在的產品都太複雜了，應該是團隊共同來面對一起解決的，這個理念就像 Component 被設計成可以繼承的功能一般，我們應該運用前人的經驗，用累積的方式來完成目標的。
過去我總是說；不管你有多少年的coding經驗，寫程式時還是必須從第一行開始。但我現在認為，你應該走另外一條捷徑，一條前人所堆積出來的便道，他能讓你更快達到目標，而不是從 0 到1。
推廣假設思維的初衷
因為它是一種比較聰明的思考方法。原由是這樣的；幾年前有一位老朋友，他的孩子考上大學第一志願了，但要透過面試才能錄取，他找我幫忙想辦法，我以為只要表現的比其他面試者更有潛能(就是看起來更聰明)，自然比較容易被錄取了。所以就開始教他如何運用假設的方式做快速解題練習，演練了幾次，你說他變聰明了嗎? 實在懷疑；但是在其他人眼裡，確實感覺他在思考應對上好像聰明了許多。這便是假設思維(hypothesis)的效果，它是一種快速求解的科學法則。也很適合用在專案上頭，是一種讓敏捷開發變得更加敏捷的方法。(如下圖；敏捷開發最小的單元是一個Sprint的時間，而假設思維則是一開始就去驗證假設，少了刻意蒐集需求的過程)。(註1. 一個運用假設思維解題的範例)
試問敏捷有哪裡運用到假設思維呢?
敏捷開發完全符合現代科學的精神(我稱之為「務實」)，因此幾乎所有的工具都或多或少擁有假設思維的蹤跡。其中我最喜歡的是影響地圖(Impact Mapping,註2.)，用得最多的則是空白簡報(Ghost Deck,註3.)它是麥肯錫顧問公司所使用的簡報製作技術，我的演講簡報都是這麼做成的。在這裡我把這二種方式都介紹給大家，先講一下簡報製作；
Ghost Deck簡報製作法，我這麼製作演講簡報已經很多年了，如果你聽過我的演講應該就不陌生了。請回味一下演講的框架，一開始是: I.「破題」。 再來是跳去簡報尾部的II.「看見全貌」，我習慣在看見全貌這一段把要講的內容簡約的描述一下(就是用圖形的方式，抽象的概述一下要講些什麼)，這是一種系統思維的作法。看見全貌可分成二部分: 一、看見整個session內容全貌，跟引導學員思考；自己在哪裡? 二、再來就是說明與這堂課程相關的資料來源，便利學員課堂後自己再進修。接著；就會跳回原本的 Agenda部分開始依序的講下去，也就是III.「開始講課內容」。最後是Q&A看板(也就是接受問問題的頁面)，然後顯示一般大會都會要求講師打出來的「謝謝觀賞」頁面，結束這場演講。我是專業的講師及顧問，對我而言快速解題是首要任務，因此麥肯錫及波士頓顧問公司這一套手法，在多年來與那些顧問群接觸時，大家都會互相分享自己的經驗，久而久之就冒出自己的東西來了，當然再加上不是那麼喜歡PPT的顯示方式，因此就寫了自己的 presenter了。
影響地圖整個的框架都是假設出來的
影響地圖的思維步驟是由目標(WHY)開始接著是誰(WHO)然後是他要如何幫你(HOW)最後是具體的作法(WHAT)。讓我們由「人」的部分開始想想有誰能幫你(或阻礙你)；在這個主題之下請問有誰可以幫助你(或阻礙你)? 把他列在目標之後。列完之後；就從第一個人開始思考他要怎麼幫你達成目標呢? 這部分屬於影響假設，是How的部分。我們假設這個人會做這件事來協作我能夠達成任務，具體的做法則是WHAT，也就是假設功能的部分。下圖是書中的範例，整個地圖就是由影響假設(Who-How)及功能假設(How-What)所組合成的。(註4. 影響地圖練習) 畫成圖形是為了透過視覺化的方式，建立商業目標與產品功能的關係，以及背後關聯的種種假設。
影響地圖《Impact Mapping: Making a Big Impact With Software Products and Projects》作者Gojko Adzic提出的一種思考分析的方法。
影響地圖整個的框架都是假設出來的，因為整個架構都是你自己所想像出來的(這便是為什麼把它說成故事的由來，說穿了是你自己針對解題的過程編了一個故事)，所以首要的工作是「驗證」。
除了影響地圖，敏捷工具裡”哪裡還有運用到假設思維”的呢?
其中看板方法可能是我們日常用的最多的一個。如果你的團隊有在使用看板，但卻從來沒有去設定半成品數(WIP,work in progress)或是設定了WIP的值，但總覺得有設跟沒設都差不多，那就是因為你沒有具體的去做假設，要在更改 WIP值的時候先做好假設，才能夠具體的看出成效。舉例來說: 你在”測試”的欄位裡將WIP值設定成1，也就是在這個欄位裡內同時只允許有一張工作單，後面的流程便都會卡住進不來一直到他被完成移出去以後流程才可以繼續。目的明顯的是你要追求好的測試品質，因此你假設了只要有一個BUG還沒解決，開發工作就不能繼續下去。會有什麼結果，歡迎讀者自己去試試看了。
DevOps的三步工作法的第三步
這是由Gene Kim 所創的實踐DevOps的三步工作法，其中的第三步、持續學習與實驗的具體實踐。意思是在開發運維的工作中運用假設的思維進行科學實踐(也就是觀察、假設與驗證)，來獲取知識並進而達到持續學習的目標。軟體開發與運維本來就是持續的在做嘗試錯誤的動作中推進的工作，由於資訊工作的環境往往存在著眾多紛雜的變數，經常是一件小小的更新或是一個細微的動作就能讓整個工作癱瘓下來，因此我們經常疲於奔命就為了一個細微而不經意的失誤，這種蝴蝶效應是一種系統的反應(屬於系統思維的範疇)，它教我們除了工作更專注之外就是要常常具備實驗的心態(對變數的主動探索)，用假設來預測前行的風險然後用驗證來踏實化具體的結果。
假設思維的知識體系
上圖中的四個工具正好構成一個簡單的可以將假設思維運用在開發上的開發者知識體系，運作方式說明如下: 在探索需求的初期運用影響地圖來設定各種假設(里程碑milestone)，然後透過看板方法來具體實踐，以設定各種半成品數(WIP, Work In Progress)值來實驗何者的流量最適合當前作業，並借助OKR的關鍵指標來激發團隊潛能，最後能夠達到具體實踐「觀察-假設-驗證」的DevOps三步工作法的持續學習與(科學)實驗的實踐。
運用影響地圖；這正是假設思維的優勢，就是一開始便依靠團隊的經驗來做假設。將傳統收集資料在進行分析的動作省了下來，但其實並不是不去做分析，而是將收集資訊與分析指向了純粹去驗證假設正確與否的具體方向上，而不是廣泛的收集資料，說穿了；就是「專注在假設的驗證上」，其他的訊息先放在一旁。這個動作讓我們能夠排除大量的雜訊，而聚焦在假設是否正確上頭。這正是假設思維所謂的「捨棄資料比搜集資料更重要」。也可以解讀為因為驗證出來的結果讓我們知道了該捨棄些什麼資訊。
運行看板方法；藉由調整半成品數(wip值)來驗證我們對流量瓶頸所在的假設，是造成看板方法能夠進行持續改善的有效方法。如果你的團隊在設定 wip值時沒有先進行假設議題的討論，那麼團隊對wip值的改變就會變得無感，因而覺得好像設定什麼樣的數值都一樣，讓運行的看板失去了改善的機會。說白了；原因是看板方法用假設的方式來設定流量瓶頸，然後再靠運行的結果來驗證假設。因為敏捷團隊多半以圍繞看板來作為站立會議的進行方式。因此從做假設再到驗證在時間上極為迅速，這一點；很容易帶起持續改善的效應。
用OKR關鍵指標的設定來激發團隊潛能
OKR最強大的效用是能夠激發個人潛能，而不是拿來打考績用的。尤其是當目標設定時的衡量指標。所以他很適合做為影響地圖驗證目標達成度的衡量指標。
以終為始 – 史帝芬.柯维
當我們遇到對問題一無所知時，也就是處於無知的狀態時，一種讓解題認知不容易偏頗的方式便是「以終為始」的思維方式了。而影響地圖便是一種以人為出發點的以終為始的假設思考法，將影響地圖所畫出來的圖形稱為是一棵假設樹(註4. 影響地圖練習)，其實一點也不為過。而這棵樹正是運用以終為始的思維方式所畫出來的解題故事的具象化結果。但說穿了；它只是一棵拿來說故事的樹，從影響的假設到功能假設，都只是故事的一個情節場景，它的意義還需要用驗證才能說明對或錯。
一個以終為始的有趣例子Rule of three: 「三重點法則」這個方法相當簡單，它是指在一天開始前，就寫下當天所必須完成的三件事，並且在時限內盡力地達成它們。這個方法能讓你認清每天的焦點，如此一來，你將不會只在枝微末節的小事上埋頭苦幹，而能把時間花在更重要的事情上。
快速解題 – 假設思維解題法
假設思維解題法是一種流行在顧問界的快速解題法。它是靠累積下來的經驗用敏銳直覺來解題的方法，加上不斷的思考「所以呢?」(so what)，反覆地自問「為什麼?」(Why?)(註5. So what, Why so?)
當你看到依靠經驗、敏銳直覺來解題，會是什麼樣的感覺呢?
會不會覺得不可思議呢? 這個可靠嗎?
不用懷疑，這可是幾家經營百年的顧問公司所一直在採用的法則，為什麼感覺上不是很靠普呢? 我一開始接觸這個方法時也總覺得有些虛虛的，但你若是有機會跟他們(顧問公司)一起工作就會恍然大悟，原來他們在做顧問工作時，看起來只派駐了寥寥無幾的幾個人，但其實他們都不是單打獨鬥的，公司裡有著累積多年的案例及資深顧問可以相互協助，假設思維是一群人一起質疑問題的方法，經驗讓他們解題不是由「零」開始，這是顧問公司的特色，也是他們的生存之道。
假設思維讓你的解題之路不用從零開始，具體功效如下:
- 假設的功效，加快工作速度、提高品質。
- 不管在怎麼覺得奇怪，也要以結論為起點進行思考。
- 在實驗中(從失敗中)學習，萬一錯了就從頭來過。
- 隨時隨地都能練習(運用影響地圖Impact Mapping建構解題的關鍵因素)。
- 專注；假設讓你專注於驗證一個較為單純的目標(知道什麼資訊可以捨棄)。
假設的依據就是以終為始，它讓經驗可以發揮功能。上圖中繪製了三條路徑，它們都可以讓我們由「確認目標」的原點一直走到「達成目標」的終點。
- 最下面那一條(青色線條)是描述傳統的解題方法，由收集資料開始，認為資料收集越多越好，然後再透過針對沒有遺漏也就完整的資料進行分析，相信怎麼做就能夠達成目標。這是一種忽略了時空變數的天真想法。
- 中間那一條虛線連接了確認目標到達成目標。這是一條線性的連接，我稱之為「故事線」，因為它是一條理想的直線，而我們都知道開發的過程通常會改來改去又變來變去，所以應該是一條曲折然後又彎彎曲曲的線條才是。所以才會叫故事線嘛! 也是一種以終為始的概念，請試著描繪你的故事，看起來好像可行但又有一點困難，不用擔心有影響地圖的工具就搞定了。
- 最上面那一條線，是一開始就擁有比較高的解題認知的假設思維曲線，它由多個假設串聯起來，它讓我們更快速的抵達成功的目標。就對解題方案的認知層次(知識)的增加而言最為快速，也就是說你可以學得最快。
(閒話；若是你家裡有學生或小朋友的話，假設思維是一種讓學習變得更快更好的方法，又為學得更快，你會覺得他們好像變聰明了)
開發者體驗 DX, Developer experience
回想你剛踏入資訊業，以菜鳥的身分進入公司的那一段時間，你的導師(mentor)是哪一位? 那段時間你是如何度過的，你的體驗又是如何呢? 試著想一想；這段旅程有沒有經過設計嗎?(又；它需要設計嗎?) 如果換過來讓你做mentor帶新加入團隊的工程師，你會怎麼做呢? 當然目標是讓新人能夠快速的進入狀況，盡快的能夠獨立作業。值得花一點時間來設計這個旅程嗎? 讓我們採用以終為始的思考方式，怎樣的過程可以讓新人快速進入狀況呢? 這個旅程便是開發者旅程(developer journey) 或許也可以稱為 DevOps journey，就更廣泛的涵蓋開發與維運了。
API First, 應用程式介面優先
- API First有二個面向，一個是對外的策略，提供合作夥伴或協力廠商可以取得公司服務的應用程式介面，無形的擴大了公司的規模(影響)邊界。另一個是對內的模組化分工。讓API成為內部界接的標準化語言，進一步讓API成為一等公民，成為團隊之間協作溝通的介面。無形間也讓內部協作能夠晉升到雲端的環境上。這也是進年來成長快速的公司紛紛祭出的政策，例如: 熱門的微服務也是實踐 API First的一種方式。
- 實施API-first 的基本优点:
- 相依性下降
- 安全化的抽象层
- 高效、迭代更新快
API 應用程式介面沒有標準格式
沒有標準；其實是標準太多，造成沒有一致的標準。依據美國 API 學院將API產品區分成五種樣式，供我們在設計相關API界面時參考，陳列如下。
來囉唆一下，設計API時首要考量的五個屬性：可擴展性、可用性、可變性、性能、可靠性，你可能會覺得我只是想提供協力廠商一份excel的資料表而已，需要考慮這麼多嗎? 簡單的幾個界面不就搞定了，有必要想那麼多嗎? 這便是設計初衷與演進過程不符合，無法預期加入的需求所造成的隔閡。設計確實是越簡單越好，但為了往後不可預見的變化以及未來維護上所需要工作，請考量這五個屬性吧。當你在開發API時應該考量的依據及實踐的方法:
廣義的開發者體驗
定義當 End User 是開發人員的時候，就應該以開發者體驗為首要的考慮因素。換句話說；在產品開發的生命週期裡，不管你是負責哪一個關卡的工程師，首先要確認的是你的客戶是誰? 誰才是這些個功能真正的使用者。因此在進行軟體開發時，請先確認誰是你真正的使用者? (就是那個抱怨最兇的人，請記得面對面給他一個熱情感恩的擁抱)因為他就是被你害得最慘的那位仁兄，他也給了你最多的回饋。另一個重點；就是一定要提供適當的回饋，不要在背地裡罵人，哪是一點作用都沒有的，想想那些荒唐又離譜的API 範例(範例和使用手冊不符、demo程式錯誤..等等)，就是因為沒有人回饋的結果。沒有回饋的話當事人怎麼會知道使用者是怎麼看待自己的設計的呢?(回饋也是一種管理的技術，請參考《回饋的技術》註6.)。回饋是一種後置的行為(後置；就是事情已經發生過了)，但若是你把假設思維加了進去，就成了「最好的回饋是能在問題發生之前提出預警。」，而Gojko Adzic 所創的影響地圖正可作好這就事。(例如: PO寫了一堆需求來請求我們回饋，這便是 所謂的Forward feedback，前饋控制)
一種絕佳的開發者體驗
我們都曉得當程式人員專注的在進行開發動作時，會進入一種所謂的「心流」的情境，這個時候千萬不要去干擾他，讓他專注的去完成他的工作，因為這個時候寫出來的東西最能反映出他的能耐的時刻，也是產出程式碼的品質最好時候。但我們也都知道要進入心流，是一種可遇不可求的情境。在這裡我退而求其次的建議一種 「偵錯的coding模式 」，因為程式員在偵錯的時候最為專注，而偵錯是一種最大限制理論TOC的過程，它運用的正是假設思維的過程，首先是發覺問題的假設；也就先假設真正出問題的地方(找到最大的限制點，可能是這裡或是哪裡?)，目的是盡快地找到出問題的原因(點)。找到問題後；再來便是假設改法了(來試一下，是這麼改還是哪麼改有用?) 這便是對假設的驗證。下圖中，左邊是偵錯的基本步驟，右邊是對應的假設思維。
小結
我總以為程式員在偵錯時是最高效的時候。一種全心全意的專注，或許是因為擔心自己錯得太離譜或是害怕因為自己的失誤會拖累到別人或團隊開發的想法。所以便出現了一種僅次於心流時刻的專注力。如果能夠把這種假設思維運用在開發上頭，coding的效能跟品質一定可以大大的提升起來。那是一種在撰寫程式時只專注於要驗證的假設的模式，也就是「我這麼做就足以達成這個功能嗎?」以假設為出發點，只思考能解題的功能，而不去思考其它的雜事(例如這個呼叫出去不知道傳回來的訊息會不會打死我的程式)，只單純的寫下足以解題的程式碼，把例外處理或邏輯分支等等的思考留到最後再來處理，現下只做最單純的解題。
(也就是暫時捨棄相關的資訊，只專注於可以立即驗證假設的訊息)
如下圖所示，在接受任務之初，就先假設哪個地方是我最無知的地方(通常就是看起最麻煩的地方，自己需要下功夫才能克服的地方)，也就自己最不瞭解的地方，先去詢問團隊有經驗的人然後再動手，這是運用假設來先發掘問題的方式(也是每日站立會議的基本課題之一；經驗傳承)。程式員拿到任務時，往往會選擇自己一下子就埋首於解題思考的過程裡；勇於面對問題的表現，而忘了自己做的工作只是團隊開發中的一小部份，你不是唯一面對問題的人，應該要有團隊共同面對問題的這種(系統)思維。更快的完成自己的工作意味著我們可以為別人爭取到更多的開發時間。這便是團隊開發時的開發者體驗，人人都是上游，也就是程式的製造者，而人人也都是下游，也就是程式的呼叫者，而把大家的體驗匯總起來便是團隊的體驗。所以要有良好的開發者體驗，就要學會回饋。當我們在下游時要記的回饋給上游他工做得好壞(是把我們害得多慘，還是幫了大忙，協助我們順暢的解題)，讓別人有機會去進一步改善、成長學習。當我們在上游時就是要重視他人的體驗，這種體驗就是開發者旅程(Developer Journey)，當然我們應該進一步稱之為 DevOps的旅程(DevOps Journey), 並致力於在產品的開發、運維時開發者都有著良好的體驗。
.
註1. 一個運用假設思維解題的範例
註 2. 影響地圖是由Gojko Adzic 《Impact Mapping: Making a Big Impact With Software Products and Projects》提出的一種思考分析的方法。
註 3. 空白簡報Ghost Deck. 是一種居於假設思維的解題方式，在確認得到真正的問題後，就啟動簡報製作。如下圖一是起手勢。把已知的資料填上標題及內容資料。半知半解的填入標題，再去準備資料。未知但是可以假設除標題的部分就加入空白頁(只有假設的標題，意思是待驗證)。
註 4. 影響地圖練習: 增加开发效能的影响地图
你會發現我在目標部分增加了 OKR的指標(為了增加激勵的作用)，並在最後加上衡量的部分(有衡量的結果，我們才能持續改善)。
註 5.So what, Why so?
麥肯錫顧問公司開發出一套「MECE」邏輯思考方式，全名為Mutually Exclusive Collectively Exhaustive，有助於思考與釐清任務的主線與邏輯，藉此分類找到影響目標的關鍵因素，執行者亦可透過這套邏輯架構，理解主管發號施令所傳達的訊息，讓工作效率事半功倍，值得職場工作者學習參考是MECE的方法，是一種邏輯思維的方法。但要做到全無遺漏且互不重複地拆解資料之外，還要從整理好的資料中，找出「其中到底是怎麼一回事」，並且確認「真的是這樣嗎」，也就是遵循科學的態度，在你認為已經把邏輯關係整理清楚之後，既須問自己「So What？Why so？」。 為芭芭拉.明托女士所創的邏輯思維法則。
So what? 其中到底是怎麼一回事?
- 是指從整體資料或經過分類整理的內容中，萃取出可以回答問題的重點。
Why so? 真的是這樣嗎?
- 是針對「So What？」所得到的結果，再去追問「為什麼會有這樣的結論」，並且以手邊的資料做進一步的驗證、確認。目的是持續的檢視這些解決方法，質疑有沒有事實或依據；如果沒有，那就不是正確答案。
註 6. 《回饋的技術》作者中原淳，一本教你如何做好回饋的技術手冊。
Ruddy Lee 分享空間 