淺談 API First

.

疫情時代;讓人以為全面數位化的時代來臨了,但軟體界卻掀起了 API First的風潮。

.

我的API設計理念大部分來自這本老書《软件框架设计的艺术》,它是 2008年NetBeans創始人Jaroslav Tulach 的傑作。2010年左右第一次看的是原文版,當時完全是一知半解,只因為有廠商要求設計API於是就找了一本書來學習如何撰寫API。近年來因為常常有機會往來大陸演講,姻緣際會的關係又看到這本書,這回是中文版由於譯者是認識的講師就隨意拿起來翻了一下序言;再次被感動到了,於是寫了這篇文章抒發一下。

比較傳統開發與 API First 開發模式(參考https://www.jianshu.com/p/036638afad4d)

.

Contract first; 先訂契約Contract 再並行做開發的工作流程。

.

API First (API優先)

在一份 Google 與牛津經濟研究院的 CIO 調查報告中,1,000 位分布全球的企業 CIO 提供了他們的想法。調查結果顯示,大多數的公司都已經採用了 API-first 的策略, 其中不少力求創新的企業,也都認為在 API-first的模組化思維能為他們解決日益複雜的軟體系統,而且具有更高的潛能。且普遍認為要從傳統的專案式思維轉變到API-first的思維,是一個文化上的轉變,不過一旦進行了這種轉變,企業可以在效率、速度、成長、彈性和適應未來發展上創造巨大的可能性。

本質上,API-First 體系架構是一種軟體設計的方法,它以 API 為中心,建立可以輕鬆互連的應用程式。API-First 開發出來的應用就像樂高積木一樣模組化、可重用、可擴展。如果你不是開發者的話並不需要掌握太多技術要點,但你一定要瞭解 API-First 對你的業務帶來的影響,因為這是一個以 API程式碼驅動型業務的時代。透過網路;所有的物件都將會被包含進來成為一個共同的生態系統。

API first Contract first

上圖中的 Mock(模擬、仿造)物件就是呼叫API的使用者與提供API功能的開發者之間事先討論好的契約Contract。雙方就依據這份契約去進行開發的工作,這是一種以終為始的設計理念,它讓二個開發團隊能夠同時間進行開發,也就是並行開發模式。說起來容易,但實作起來還必須有許多理念與共識才辦的到。

如何才能設計好契約呢?

完整的理念起始於需求的驗證,也就是運用MVP的概念來驗證Mock物件的正確性,對熟悉TDD測試開發法或是單元測試的程式設計人員而言應該都一點不陌生。但這對提出並規劃需求的PO或PM而言就比較抽象了。

具體的作法是;我們先運用設計衝刺(註Design Sprint)的概念來驗證產品的價值,然後在需求得到驗證後運用Mock物件來進行API first 的設計。這一點剛好和測試開發法的順序相顛倒。而這樣做的原因是為了提高契約(Mock物件)的正確性。因此稱為Contract first.

我還依稀記得自己第一次寫API 介面時的情景,一定是先把程式寫完了,得到程式可以正確的執行之後,然後才開始規劃 API,一邊實作API程式一邊訂API的規格寫文件,一種典型的傳統開發模式,因為被要求要出文件,又怕先寫文件會造成交卷時程式與文件兜不起來的現象,就在寫完程式之後才開始寫文件了。

API(Application Program Interface)應用程式介面;看似簡單的名詞,卻代表著重要的架構設計。從架構設計的角度來看(所謂的組成論),軟體系統就是模塊和介面。模塊(層次/組件)決定分工,介面決定交互(interactive)。API就是介面的定義。模塊間並不需要關心其它模塊的實現,只需要了解如何進行協作即可(請參考設計api時的第一個抉擇)。這樣將複雜度分散到各個模塊之中,使得整體系統更為可控。而API的本質,就是提供給模塊開發者使用的介面,是給人(Programmer)用的。API設計任務的核心就是保證使用者以較低的成本, 正確的使用介面來驅動模塊以完成他們的任務。而對於Public API而言,最大的設計挑戰則是如何把API一次就做對!或是退而求其次,如何設計的讓異動的時候損失最少。

何謂Mock 物件?

Mock : 用來模擬物件在測試期間吐回參數與驗證的部份。

何謂好的API ?

API允許應用程序相互“交談”和交互溝通,是物聯網時代的基礎,也就是說;所有事物都有一個介面來連接到網路上。讓人工智慧得以真正服務人群,間接地也提升了各種數據業務。就好像GUI一樣它也是一種介面,只是對象;也就是使用者是人類,而API的使用者卻是程式設計師,相同於使用者介面設計的UX體驗,換到工程師身上便成了DX開發者體驗了(Developer Experience請參考開發者體驗)。因此回答什麼是好的API就變得很直覺了,就是能造成好的開發者體驗的便是好的API。

.

實踐API first 的先決條件,就是要有好的開發者體驗。

.

API first 不只在技術領域上有意義(雖然它不是一個新東西),但它在商業上趨勢更是銳不可擋,這裡就不做陳述,有些值得參考的資料陳列如下:

  1. 軟體框架設計的藝術》by NetBeans的創造者(捷克) Jaroslav Tulach,人民郵電出版社 2011/3.
  2. 持續API管理|在不斷演變的生態系統中做出正確決策》作者: Mehdi MedjaouiErik WildeRonnie MitraMike Amundsen 出版商: O’REILLY。

有關設計API的幾篇好文章

Youtube 上的影片:

註. Design Sprint 設計衝刺

為 傑克.納普Jake Knapp、約翰.澤拉斯基John Zeratsky、布雷登.柯維茲Braden Kowitz 合著. 是Google官方認證!5天5步驟的高效率工作流程-SPRINT衝刺計畫。

設計API時的第一個抉擇

選擇性無緒; 就是決定使用者需要具備的基礎知識程度。

你要考慮到使用你的API的程式設計人員需要對你的工作了解到怎樣的程度,才能夠正確使用你所設計的API來完成他的任務呢? 這便是我們在設計API時必須做的第一個抉擇。這是一種DX設計的思維。

開發者體驗 DX, Developer Experience

狹義的定義;就是程式設計人員在使用API時的體驗。若對照到 UX 使用者體驗就是所謂的直覺式的設計(Operation without thought)。UX設計師會依據假設的使用者人物特性(persona)來決定他能夠接受並完成操做的基本模式,然後依據它來設計使用者可以完成任務的操作流程。我們把這個理念運用在開發者體驗上,便是設定程式設計人員,它需要對API的呼叫背景知識了解到怎麼樣的程度,才能順利的運用我們所設計的API呢? 在作API的設計時,我們稱這個決定為「選擇性無緒  」(selective cluelessness, 註1),也就是API的呼叫者需要了解API背後工作內容的知識程度。若API程式設計得當,程式人員就可以使用所謂的「淺層理解  」來學會如何呼叫你的API程式。

因此在設計API時,設計師面臨的第一個抉擇便是決定呼叫API的程式人員需要具有什麼樣的背景知識,才能順利的運用你的API來完成他的任務。

API設計要盡可能做到 無緒。讓開發人員可以在對系統在了解很少的前提下,仍然可以完成工作。

註1. 無緒 Cluelessness是由 Martin Rinard 所提出。他在OOPSLA, 2006的一場演講時指出:在開發和維護軟體系統時,應該避免讓開發人員深入了解系統。  」

無緒” 並不是一個貶義詞,這裡的意思比較接近無知(ignorance),指的是對API內容的了解程度。它是用來區別兩種層次的理解程度:

  1. 淺層理解:指對事物的了解程度僅限於掌握使用方法即可。
  2. 深層理解:指對掌握了事物背後的原則、規律、原理。

.

參考自《軟件架構的設計藝術》by Jaroslav Tulach.

所謂的「選擇性無緒  」的思維,正好符合軟體設計原則的 緊湊性Compactness 的特性。當一個程式具有緊湊性時,也就是具有「易於理解、使用、組合」等元件的特性。這些特性讓使用者幾乎可以不用閱讀文件,便可以自然而然的使用這些API,彷如直覺式操作一般。(要特別注意的是緊湊性並不等同於容易學習,好的學習需要按部就班、由淺入深,而不是一知半解)。

這個無緒的理念,運用在 DevOps 的協同合作上也很棒,我們應該視環境來決定Dev 與 Ops 的相互了解程度,而不是非要彼此通透融合才是。有興趣深入了解的人可以參考 軟件架構的設計藝術 一書的 第一章, 12~13 頁.

無緒cluelessness指的就是無知(ignorance).或許講無知會更容易理解些,但還是尊重一下譯者。

DevSecOps 宣言

DevSecOps由Gartner在2012年提出,推廣安全即代碼Security as Code, 強調安全Security是唯一不能僅僅採用API就能實踐DevOps的項目,你必須從工程師的安全觀念著手,只有態度的轉變才能真正的實踐安全準則。

DevSecOps模型及最佳實踐

Gartner在2016年發佈DevSecOps: How to Seamlessly Integrate Security into DevOps報告如上圖說明如下:

  1. 安全控制必須盡可能地可程式設計和自動化
  2. 使用IAM和基於角色的存取控制來提供職責分離 (AWS Identity and Access Management,IAM)
  3. 為所有應用程式實施簡單的風險威脅模型分析
  4. 掃描自訂程式碼、應用程式和API
  5. 掃描開源軟體
  6. 掃描漏洞和配置資訊
  7. 將Scripts/ Recipes/ Templates/ Layers 視為敏感的程式碼
  8. 評估系統完整性,並確保配置安全
  9. 在生產系統上使用白名單whitelisting,包括容器的實現的方式
  10. 若已遭入侵攻擊,應全面監控,構建快速檢測和回應
  11. 鎖定生產基礎設施和服務
  12. 如果使用容器,請確認並使用安全限制
  13. 底線 Bottom Line

最有效的DevSecOps程式從開發過程中最早的點開始,並跟蹤整個生命週期。從長遠來看,盡可能將安全控制自動化,以減少配置不當、錯誤和管理不善發生的可能性。

DevSecOps 宣言中英對照

  • Leaning in over Always Saying “No”

向前一步 勝過 說"不

  • Data & Security Science over Fear, Uncertainty and Doubt

數據和安全科學 勝過 恐懼、不確定性和懷疑

  • Consumable Security Services with APIs over Mandated Security Controls & Paperwork

基於 API 的性安全服務消費  勝過 強制性安全控制和文書工作

  • Business Driven Security Scores over Rubber Stamp Security

業務驅動的安全評分 勝過 橡皮圖章安全

  • Red & Blue Team Exploit Testing over Relying on Scans & Theoretical Vulnerabilities

紅藍隊對抗測試 勝過 依賴掃描和理論漏洞的測試

  • 24×7 Proactive Security Monitoring over Reacting after being Informed of an Incident
    24×7 主動安全監控 勝過 在獲知事件後做出反應
  • * Shared Threat Intelligence over Keeping Info to Ourselves

共享威脅情報 勝過 將信息留給我們自己

  • Compliance Operations over Clipboards & Checklists

符合規定的操作 勝過 通過剪貼板和檢查表

. Bob Martin 的< 程序員誓言 >可能是捍衛 Security 的一道最重要的防線。

主管的敏捷教練

Scrum 是一種經驗主義,所以團隊一定要接觸過、實施過才能有所體悟,那從沒有跑過Scrum 的主管怎麼辦呢? 主管要如何敏捷起來呢? 這裡有三招管理的工具,三種不同的方式,都是為增進主管的敏捷度,其實是可以彼此融合在一起實行的,就看你如何去實踐了。

Agile Submit ’21 的演講資料在這裡.

情境理論 Situational Leadership

做為顧問;在不同時期裡我對於管理者行為的觀察有著不同的體驗,很難講哪一種最有效。早期大家追尋著團隊自組織,都在想怎麼樣做才能讓團隊自己管理自己,總是請管理者後退一步, 退一步還不夠時就請他後退很多步。很少去思考就主管的立場它該怎麼做才能敏捷起來,才能也跟著他的團隊一起成長。這段時期Paul Hersey 和 K. Blanchard 的情境理論(Situational Leadership) 是我最大的支柱。

解決主管太忙的情境理論

情境理論的圖形在說明;主管在進行管理時應該視該下屬的能力與意願而採取不同的管理模式。當成員的能力較弱的時候;宜視他的工作意願而採取指令型(直接跟他講怎麼作)或是教練型(以教練的姿態教他怎麼作),這二種模式主管都會做得很辛苦。如果下屬達成任務的工作能力都很好的時候,便可以採取支持型的管理或是授權型的管理方式。自己只要參與討論,決策的工作就交給成員自己來做,而他們也能為自己的任務負責。所以當你的成員大部份變成你可以信任的支持型或是授權型的部屬時,你就不會哪麼忙了。反之;當你的成員大部分屬於教練型或指令型部屬,你會不忙才怪。因此你要設法培訓你的下屬,讓他們由右側的新手成員過渡到左側具有能力的成員,這時候主管因為需要的參與度下降,自然就不會那麼忙而比較輕鬆了。因此;除非你運氣好錄取了一批優秀的人才之外,培訓下屬能力的提升,便成了做主管是否能穩坐的重責大任了。

意見回饋是培訓下屬的最佳方法。

-麥肯錫的回饋術

.

※ 有關「主管忙與不忙」見仁見智的爭議很多,但是有一個跟敏捷相關的概念很有趣,哪就是主管越忙則代表團隊的自組織就越差,但主管自己的成就感卻越好

.

能夠培育英才的意見回饋

隨著自己敏捷程度的提升,我發覺有效的回饋可以塑造部屬成為主管想要的樣子。便在回饋上下足了功夫。

主管可以改變、掌握的回饋方式

主管可以用「意見回饋」的方式,來改變團隊的自組織模式。但那會一不小心便成了干預團隊的罪犯,所以發明了前置回饋的方法,它是運用做各種假設的方式讓團隊去證明他們的想法是對是錯,這種思維方法不但可以解決團隊與主管之間的意見分歧也符合科學的客觀原則,不管證明的結果是對是錯,大家都沒有了主觀,它可以開啟團隊客觀成長的里程。有時候證明假設是錯的時候;反而會讓團隊成長的更多。這個方法是來自波士頓及麥肯錫顧問公司對商業行為的顧問手法,我只是把它運用在敏捷開發的團隊上頭,效果也出乎意外的成功。

前置回饋;就是在事情尚未發生之前所給予的回饋。

結合情境理論與回饋時機的假設思維

信任與責任超越共識

敏捷必須實行在透明-檢核-調適的範疇中,在工作透明化之下,團隊成員才容易建立起互助回饋的工作模式。能夠扎實的把Scrum 會議開好,檢核和調適就不成問題了,他們會自然而然的形成一種團隊的文化,不管外面環境的變化,團隊依然能夠自我調適。這便是一個敏捷團隊所追求的文化形式。也就是一個對於專案開發能夠迅速產生共識的團隊,他們溝通無礙。對於專案一開始的無知(下圖中右下角的黑箱象限)能夠有效的採用小增量、多迭代與尋求回饋的方式逐步的增進對解題方案的認知深度。至於對那兩個盲點區塊的克服方式;當屬於你知道/我不知道或是我知道/你不知道的盲點模式時(右上角與左下角象限),可以運用我(你)提問-假設然後做好引導的方式來打通盲點,讓團隊能走進達成共識的象限裡。

信任與責任更勝於形成共識

當我在扮演Scrum Master角色的時候,總是努力的讓團隊能盡快達成共識,一旦團隊取得共識時,一切都好辦了,此時的專案開發經常順暢到不行,即便問題仍然不可預期的不斷出現;但團隊總能一起克服它,展現出一種自組織團隊的功效。

隨後我才意識到,信任與責任的模式才是王道。在與你信任的人合作時,溝通就像排球比賽時的場景,不論是得分或是失誤,相互擊掌是不可或缺的默契。

這三招的管理工具,有三種不同的理論,其實是可以彼此融合再一起的。就看你可以體驗到哪裡了。

註. 這三招把他們通通串接起來會是甚麼樣子呢。

主管的敏捷思維;領導、培訓與達成共識

心態致勝

為何主管的態度那麼重要呢? 因為主管的態度形成它的行為模式,看在團隊眼裡被解讀成(以為、認為)主管的意思是這樣的,因此形成團隊的行為,而團隊的行為表現看在主管眼裡,又因此形成主管的態度。這是一個循環的系統。一切始於主管的態度。這就是為何我一再強調敏捷主管要從改變態度做起。因為態度足以影響團隊的行為表現。

關注價值而非日期

-敏捷主管應該有的基本態度

為何主管的態度那麼重要

線上 Session PPTx.

播出時有學員提問: 若是主管在黑箱裏頭,也就是始終不能自覺或是聽不進去的時候怎麼辦呢?

回答: 能夠不帶情緒的溝通方式才是上策,建議運用假設思維的方式,勇敢的提出你的假設(疑惑),然後設法去驗證它,無論結果如何都能科學的得到驗證讓雙方釋懷。避免憑空想像,形成子虛烏有的錯誤想像(請參考: <五項修練>的左手欄)。

.

學員提問: 老師說主管要: 「關注價值而非日期」,但如果哪個日期非常重要的話,怎麼辦?

回答: 那就讓日期的對應價值能夠展現出來,例如: 8/15 是中秋節,月餅一定要趕在這一天以前做出來。

回饋的三個時機點

績效管理應該是「適時的回饋」,而不是「歷史回顧」。

Be careful of your thoughts, for your thoughts become your words; Be careful of your words, for your words become your deeds; Be careful of your deeds, for your deeds become your habits; Be careful of your habits; for your habits become your character; Be careful of your character, for your character becomes your destiny. (註1.)

Mother Teresa

依時間點做區分的回饋

請注意你的想法,因為你的想法將成為你的命運,所以你要與周遭的人分享你的想法並接受他們的回饋,那樣即能改變命運並使自己成為更好的人。

主管的回饋

請注意主管給你的回饋,那是他對問題發生以後,當時你的處理方式所造成的具體影響的一種 (感覺) 想法。他用語言或文字傳達給你,目的是希望這段回饋可以對你有所幫助。什麼幫助呢? 希望它能改變你未來的行為,並進而能養成一種好的習慣,讓你在未來的工作上能順暢的完成自己的任務。這是主管培訓下屬的一種方式,也是職場成長的一種特效疫苗,我們必須正面接受它並針對它產生具有相當意義的抗體。或許當時這段回饋產生了很多副作用,不管它讓你覺得有多沮喪,或是思緒上的矛盾混亂,最終你都應該抽絲剝繭的來正面面對它,讓它能具體的影響你的行為。首先;最基本的要求是改變你的言詞,事後的言行可以展現你的反省深度。然後要讓你的言詞成為你的行動(言行一致)。這便是成功的將回饋轉換成一種成長的動力的最佳方式了,不管上司是有意或是無意的指正,基本上;它都會改變你的命運。

善用你的回饋

敏捷的口訣:「小增量、多迭代與尋求回饋」,小增量是小步前進與迭代相配合就是一再的重複改善,前二步是以時間為考量。也就是持續改善。而回饋呢?

當PO來麻煩我們幫忙Review需求的時候你做到了嗎? 你是否做了一個好的回饋了呢? 這個時候的回饋,它尤其重要因為一切都還沒有發生,團隊還沒有開始背負完成任務的重責大任,我們其實是為未來的工作在做意見回饋,這叫作「前置回饋」(上圖中的第一種回饋時機)。請試著用80/20法則來看看手頭的需求。(8020法則;並不是只做20% 其餘80%就不用做了,而是指我們所做的20%功能裡,就已經足以涵蓋 80% 的使用者需求了,所以要把重點擺到那20%最重要的地方,作好這部分最重要,而不是全部都重要,因此你應該跟PO斤斤計較多花些時間討論的是這20%的需求。)

即時回饋 – 事情正在進行中的回饋行為

在Sprint的開發過程,團隊成員的彼此相互回饋,便是一種「即時回饋」。相互的叮嚀或許聽起來像是囉嗦,但是即時的提醒其實效果更勝於站立會議時的Comment。團隊開發必須重視成員在開發中的體驗,團隊開發有異於個人開發的地方便是你必須在意團隊的感受,因為它不只包含了人與程式之間的問題,還要考量到人與人之間的交互活動。團隊開發時經常是你的程式會去呼叫或是繼承他人的程式功能,這個時候它所帶給予你的體驗,便直接會影響你開發的順暢與否,所以即時的回饋可以起到很大的影響(拯救無數的偵錯時間),能夠避免掉許許多多錯誤的產生及時間的浪費,換句話說是一種好功德。它是讓團隊開發遠遠優於個人開發的地方(用四百接力來比喻在洽當不過了,四百接力時四個人跑出來的總和成績要遠遠優於個人最佳成績的加總)。展現出來的是團隊協作的好壞,因此應該由團隊所有成員共同來負責。

後置回饋 – 事情已經發生後的回饋行為

敏捷開發中的回顧會議(Retrospective Meeting)便是一種典型的「後置回饋」,也就是說事情已經發生過了,我們在事後針對大家所看到或是體驗到的現象來進行回顧。團隊依靠檢討的方式來分享自己的體驗,進而取得大家的共識願意一起來改善的機會。年度考績也是一種後置回饋,雖然我們都知道;績效管理應該是「適時的回饋」,而不是「歷史回顧」。但主管們總是因為太忙碌而做不到適時的回饋行為,然後才在年底的考績評核上指證下屬的錯誤,但事情已經經過一段時間的沉澱誰還能記得清楚呢? 因此這是一種最糟糕的回饋方式。因為事情已經發生了,團隊的感受最為深刻,最容易觸發反省而讓團隊成員學到最多東西。所以scrum 把它放在Sprint的最後面,是scrum的所有會議中最重要的一個會議。為Scrum Master負責引導實施。

前置回饋 事情尚未發生之前的回饋行為

當PO帶著這個 Sprint的需求來找我們的時候,你便有機會進行前置回饋了(請記得80/20理論)。長官們通常會在重要的專案開始時先強調它的重要性。藉以提昇大家的注意力,但其實這種作法幫助不大,此時最有效的方式是「假設思維」的做法。在事情尚未發生前預設歷程,並加以闡述說明。這便是說故事的力量了。運用說故事的方式,以終為始讓他深深刻印在團隊每個成員的心中,效果之大將難以計數。

以終為始的假設思維

讓假設來牽動你的開發方向

運用假設思維來引導你的前置回饋。假設一直是科學研究的基礎,我們依據經驗或創意巧思來提出假設,然後再針對這個假設進行驗證,證實它是對的還是錯的,藉此以對該問題獲取更進一步的相關知識或認知。這一點跟程式員做偵錯(debug)時的動作是一致的,首先要假設哪個功能最可能出錯,並在獲得具體資料證明是哪個功能出錯的時候,在進一步去看這個功能裡是哪裡出錯了。先以抽象的方式做較大區域的假設,先驗證是哪個區域出的問題,接著在細部的去偵錯抓出出錯的程式來。偵錯;是工程師表現得相當高效率的時刻,或許是害怕出錯的地方是自己負責的部分,所以因為這種心情而展現的積極,因此看起來效率就變得很高了。其實;是這種先假設在驗證的方式,造成偵錯過程變得高效率的。在學生時期我們就經常做實驗,步驟是先觀察再做假設,然後驗證假設。這是一種科學的方法(觀察-假設-驗證)一種快速取的認知的方式。為什麼它會快呢? 因為我們不是先做資料收集,再針對收集到的資料去做分析、過濾。而是先做假設,先過濾掉那些與假設無關的資訊,無形中減少了大量的雜訊資料,自然而然效率就變高了。

假設思維是一種經驗主義,經驗越多越是有機會做出好的假設,而顧問公司最不缺的就是有經驗的顧問,因此大部分的顧問公司都會運用假設思維的方式做到快速解題的高效能。而且這個方法也十分適合拿來培育年輕的顧問,它依賴資深的顧問在解題的初期就給予正確的方向,讓沒有經驗的顧問不需要由零開始。只要專注地去驗證假設即可。反觀主管與部屬的情境,資深者提出好的假設讓部屬在正確的方向及範圍內求取驗證,正好構成了前置回饋的模式。

情境理論四象限;P. Hersey 與 K. Blanchard ,1969年所創

自組織團隊的假設思維

當團隊的意見與組織的方向有所分歧時,此時主管應該進一步矯正團隊的動向呢? 還是退一步讓團隊自主呢? 這是主管再帶領運行敏捷化的團隊經常會遇到的難題,主管面臨的是該退一步還是該進一步的抉擇。一般的主管會以當時的情境作為考量的依據,若是團隊處於較成熟、能夠自主的情境下(上圖,第四象限, D4),則尊重團隊交給他們自己去搞定,才是充分授權的表現。反之;如果團隊處於熱心有餘而經驗不足的情境下(第一象限, D1),則應該以強制的指令直接修正團隊的決議,避免他們誤入歧途。但是;若以DevOps三步工作法第三步的思維來處理的話,就變成主管與團隊進行溝通,以提出一系列假設的方式來協助團隊研判自己的決策是否正確的衡量方式,這便是一種假設思維的解題方法,運用科學的思維來解題,明顯的來避免衝突的觀點,而是改以較為科學的驗證方式。讓意見相左的雙方都能以理性的態度來看待問題。這便是假設思維讓主管的敏捷性更加敏捷的地方,是既合乎邏輯又十分務實的做法。

註1. 中文對照

注意你的想法,因為你的想法將會成為言詞。注意你的言詞,因為你的言詞將會成為行動。注意你的行動,因為你的行動將會成為習慣。注意你的習慣,因為你的習慣將會成為性格。注意你的性格,因為你的性格將會成為你的命運。

: 德雷莎修女.

Be careful of your thoughts, for your thoughts become your words; Be careful of your words, for your words become your deeds; Be careful of your deeds, for your deeds become your habits; Be careful of your habits; for your habits become your character; Be careful of your character, for your character becomes your destiny.

意思是;注意你的想法,因為你的想法將會成為你的命運。所以我們應該;與周遭的人分享你的想法並接受他們的回饋,使自己成為更好的人。

談假設思維之下的開發者體驗

這是我今年的第一場公益演講,直播課程二個小時對象是中國DevOps社群,所以PPT都是簡體字,這個時間長度已經是我的聲音所能負荷的極限了。所以講起來異常的辛苦,然後直播又是沒有觀眾的,即便是你問了一個問題還是得自己回答,講了一個笑話也不用等笑聲停下來才能繼續再講。就這樣一口氣要講二個鐘頭完全沒有停下來,好累! 這裡把內容記錄下來,因為有些主題蠻有時代價值的,值得再三玩味。(二個小時的課程,主題太多文章寫長了,請慎入)

Agenda上有七個主題,首先是破題

【破題】

開發者體驗DX是由於UX設計師表現傑出而來,他們成功的讓本來應該越來越厚的使用者手冊反而變不見了。讓使用者可以直覺地完成80%的操作工作卻完全不需要輔助說明,稱為直覺式設計,UX設計師針對使用者畫像(user persona) 假想設計出一系列的步驟,讓使用者直觀的完成它的工作,並預期得到一種良好的體驗,願意下次繼續採用我們的產品。我們把這個理念延伸到開發的作業上,開發者就是那個使用者,而他在開發過程中的各種感受就是「開發者體驗」了。

若說UX設計師的目的在讓使用者感覺良好,下一次願意再使用的話,DX設計師的目的就是讓開發者因為感覺良好,而能夠更好、更快速地完成任務。這種換位思考,讓人很容易理解它們之間的關係。

當開發者感覺順暢,開發速度自然得以提升

推廣開發者體驗的初衷

是因為自己還依稀記得初次寫程式時卡關的感受,將近40個年頭過去了,哪種刻苦銘心的感受你是一輩子也忘不掉的。因為不希望下一代的程式師還是有同樣的體驗,這種不好的體驗在這個時代其實是可以通過刻意的設計來避免改善的。老實說;沒有程式員應該單打獨鬥去面對所有的難題的,因為現在的產品都太複雜了,應該是團隊共同來面對一起解決的,這個理念就像 Component 被設計成可以繼承的功能一般,我們應該運用前人的經驗,用累積的方式來完成目標的。

過去我總是說;不管你有多少年的coding經驗,寫程式時還是必須從第一行開始。但我現在認為,你應該走另外一條捷徑,一條前人所堆積出來的便道,他能讓你更快達到目標,而不是從 0 到1。

推廣假設思維的初衷

因為它是一種比較聰明的思考方法。原由是這樣的;幾年前有一位老朋友,他的孩子考上大學第一志願了,但要透過面試才能錄取,他找我幫忙想辦法,我以為只要表現的比其他面試者更有潛能(就是看起來更聰明),自然比較容易被錄取了。所以就開始教他如何運用假設的方式做快速解題練習,演練了幾次,你說他變聰明了嗎? 實在懷疑;但是在其他人眼裡,確實感覺他在思考應對上好像聰明了許多。這便是假設思維(hypothesis)的效果,它是一種快速求解的科學法則。也很適合用在專案上頭,是一種讓敏捷開發變得更加敏捷的方法。(如下圖;敏捷開發最小的單元是一個Sprint的時間,而假設思維則是一開始就去驗證假設,少了刻意蒐集需求的過程)。(註1. 一個運用假設思維解題的範例)

敏捷開發以一個Sprint為單元,而假設思維則從驗證假設開始

試問敏捷有哪裡運用到假設思維呢?

敏捷開發完全符合現代科學的精神(我稱之為「務實」),因此幾乎所有的工具都或多或少擁有假設思維的蹤跡。其中我最喜歡的是影響地圖(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建構解題的關鍵因素)。
  • 專注;假設讓你專注於驗證一個較為單純的目標(知道什麼資訊可以捨棄)。

假設的依據就是以終為始,它讓經驗可以發揮功能。上圖中繪製了三條路徑,它們都可以讓我們由「確認目標」的原點一直走到「達成目標」的終點。

  • 最下面那一條(青色線條)是描述傳統的解題方法,由收集資料開始,認為資料收集越多越好,然後再透過針對沒有遺漏也就完整的資料進行分析,相信怎麼做就能夠達成目標。這是一種忽略了時空變數的天真想法。
  • 中間那一條虛線連接了確認目標到達成目標。這是一條線性的連接,我稱之為「故事線」,因為它是一條理想的直線,而我們都知道開發的過程通常會改來改去又變來變去,所以應該是一條曲折然後又彎彎曲曲的線條才是。所以才會叫故事線嘛! 也是一種以終為始的概念,請試著描繪你的故事,看起來好像可行但又有一點困難,不用擔心有影響地圖的工具就搞定了。
  • 最上面那一條線,是一開始就擁有比較高的解題認知的假設思維曲線,它由多個假設串聯起來,它讓我們更快速的抵達成功的目標。就對解題方案的認知層次(知識)的增加而言最為快速,也就是說你可以學得最快。

(閒話;若是你家裡有學生或小朋友的話,假設思維是一種讓學習變得更快更好的方法,又為學得更快,你會覺得他們好像變聰明了)

狹義的定義是為了解API給程式員的痛,廣義的定義則是解整個開發過程的痛

開發者體驗 DX, Developer experience

回想你剛踏入資訊業,以菜鳥的身分進入公司的那一段時間,你的導師(mentor)是哪一位? 那段時間你是如何度過的,你的體驗又是如何呢? 試著想一想;這段旅程有沒有經過設計嗎?(又;它需要設計嗎?) 如果換過來讓你做mentor帶新加入團隊的工程師,你會怎麼做呢? 當然目標是讓新人能夠快速的進入狀況,盡快的能夠獨立作業。值得花一點時間來設計這個旅程嗎? 讓我們採用以終為始的思考方式,怎樣的過程可以讓新人快速進入狀況呢? 這個旅程便是開發者旅程(developer journey) 或許也可以稱為 DevOps journey,就更廣泛的涵蓋開發與維運了。

稱職的導師mentor需要擁有教學相長的思維

API First, 應用程式介面優先

  • API First有二個面向,一個是對外的策略,提供合作夥伴或協力廠商可以取得公司服務的應用程式介面,無形的擴大了公司的規模(影響)邊界。另一個是對內的模組化分工。讓API成為內部界接的標準化語言,進一步讓API成為一等公民,成為團隊之間協作溝通的介面。無形間也讓內部協作能夠晉升到雲端的環境上。這也是進年來成長快速的公司紛紛祭出的政策,例如: 熱門的微服務也是實踐 API First的一種方式。
  •  實施API-first 的基本优点:
    • 相依性下降
    • 安全化的抽象层
    • 高效、迭代更新快
API first的潮流下,衍生出來的AaaP,API as a Product

API 應用程式介面沒有標準格式

沒有標準;其實是標準太多,造成沒有一致的標準。依據美國 API 學院將API產品區分成五種樣式,供我們在設計相關API界面時參考,陳列如下。

美國API學院對API產品區分成五種樣式

來囉唆一下,設計API時首要考量的五個屬性:可擴展性、可用性、可變性、性能、可靠性,你可能會覺得我只是想提供協力廠商一份excel的資料表而已,需要考慮這麼多嗎? 簡單的幾個界面不就搞定了,有必要想那麼多嗎? 這便是設計初衷與演進過程不符合,無法預期加入的需求所造成的隔閡。設計確實是越簡單越好,但為了往後不可預見的變化以及未來維護上所需要工作,請考量這五個屬性吧。當你在開發API時應該考量的依據及實踐的方法:

協同開發是API界面設計的基本要求

廣義的開發者體驗

定義當 End User 是開發人員的時候,就應該以開發者體驗為首要的考慮因素。換句話說;在產品開發的生命週期裡,不管你是負責哪一個關卡的工程師,首先要確認的是你的客戶是誰? 誰才是這些個功能真正的使用者。因此在進行軟體開發時,請先確認誰是你真正的使用者? (就是那個抱怨最兇的人,請記得面對面給他一個熱情感恩的擁抱)因為他就是被你害得最慘的那位仁兄,他也給了你最多的回饋。另一個重點;就是一定要提供適當的回饋,不要在背地裡罵人,哪是一點作用都沒有的,想想那些荒唐又離譜的API 範例(範例和使用手冊不符、demo程式錯誤..等等),就是因為沒有人回饋的結果。沒有回饋的話當事人怎麼會知道使用者是怎麼看待自己的設計的呢?(回饋也是一種管理的技術,請參考《回饋的技術》註6.)。回饋是一種後置的行為(後置;就是事情已經發生過了),但若是你把假設思維加了進去,就成了「最好的回饋是能在問題發生之前提出預警。」,而Gojko Adzic 所創的影響地圖正可作好這就事。(例如: PO寫了一堆需求來請求我們回饋,這便是 所謂的Forward feedback,前饋控制)

先思考谁是你的使用者

一種絕佳的開發者體驗

我們都曉得當程式人員專注的在進行開發動作時,會進入一種所謂的「心流」的情境,這個時候千萬不要去干擾他,讓他專注的去完成他的工作,因為這個時候寫出來的東西最能反映出他的能耐的時刻,也是產出程式碼的品質最好時候。但我們也都知道要進入心流,是一種可遇不可求的情境。在這裡我退而求其次的建議一種 「偵錯的coding模式 」,因為程式員在偵錯的時候最為專注,而偵錯是一種最大限制理論TOC的過程,它運用的正是假設思維的過程,首先是發覺問題的假設;也就先假設真正出問題的地方(找到最大的限制點,可能是這裡或是哪裡?),目的是盡快地找到出問題的原因(點)。找到問題後;再來便是假設改法了(來試一下,是這麼改還是哪麼改有用?) 這便是對假設的驗證。下圖中,左邊是偵錯的基本步驟,右邊是對應的假設思維。

偵錯是一種最大限制理論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. 《回饋的技術》作者中原淳,一本教你如何做好回饋的技術手冊。

遠距上班的一分鐘看板方法

傳統上為了運作看板方法;得要先去找一塊板子、貼紙、分隔線…。要準備一堆器材才能開始運作看板,這是實體看板的不便之處。但;現在不需要了,因為免費的電子看板很多,即便只是使用手機也能運作得很好。雖然電子看板的功效要小於實體看板,但在方便上! 就是簡單又方便,只要連線就搞定了,實在沒有不用的道理。若是在Mapping 到WFH(Work From Home)在家上班的情境,實體看板就真的很難運作了,但採用電子看板就真得可以搞定了嗎? 效能怎麼辦? 這裡推薦給大家一分鐘看板。

一分鐘看板

何謂一分鐘看板? 是居家工作時的個人看板,是可有可無、又能像行事曆一般地隨時提醒你工作進度的看板,它不但能紀錄下工作的軌跡又能提供你事後進行反思、進行持續改善,你說對你有幫助嗎? 來試試看吧。

首先;在手機上執行Trello,選擇創建一個最基本的 「To do – Doing – Done」 看板,一個簡潔到不能再簡單的看板,它能讓人能一目了然,即使手機不在你身邊只要閉上眼睛稍微想一下就能意會自己現在在做什麼、接下來該做什麼了。若是用手機(那麼小的屏幕)就能讓你看清楚,想當然就是沒有手機的時候你也能清楚的記住它長成什麼樣子,也就是;目前你在進行怎樣的工作,做到哪裡?

填加工作卡: Trello + mail

如果有突發的事件發生造成你必須中斷手頭正在做的工作,就用email寄給自己的方法,email給 Trello 的看板(註1.),它會自動加入到 To do的待辦事項裡頭,接著判斷一下是要接受中斷,把新工作拉進Doing欄位開始進行呢? 還是先pending一下等做完手頭的工作在接著做它。如果選擇中斷,就做好註記,記下被中斷的工作做到哪裡了、進度如何?好回過頭來便利於繼續做下去,不至於每次都從頭開始。

運用自我反饋逐步改善自己(trello + email)

.

一分鐘看板如何提升居家工作的效能

在史蒂芬·柯維提出的成功者的7個習慣中,你覺得哪一個最難做到呢? 出人意料的調查結果,最難的並非是與他人合作或持之以恆之類的習慣,而是“要事第一”Put First Things First。因此日程規劃的難點在於,決定哪一件事是最重要的事? 因為既便你排好了優先順序,又總是會有些事情突然冒出來打亂你原先的規畫和節奏。

但幸好你正在 WFH,你隨時隨地的可以自行決定。這一點就跟一人公司(註2.)一樣,你得經營自己的一天工作,因此什麼是最重要的呢?

.

我們最害怕失去的東西,就是我們最珍惜的。

我們認為最有意義的東西,就是對我們最重要的事情。

.

運用Trello 規劃的一分鐘看板

.

一分鐘看板的運作

上圖是一個最基本的 「To do – Doing – Done」看板,填加卡片的方式是採用email的方式,目的是透過時間差加入卡片的方式,讓你有一點時間思考該立刻改換工作還是繼續手頭的工作,依據的是「何者對你的意義較大呢? 」,想好了就打開手機上的 Trello ,若決定是改換工作項目,就做好註記,把它小在email 裡頭然後寄給自己(所以你的email裡頭就多了二種信件,一種是寄給Trello的工作卡片,另一種是註記被你pending的工作進度、註解或說明。其實還可以多做一種回饋的email,註3.),寫下手頭上工作的注意事項,接著把新卡片從 To do欄拉進 Doing欄開始新工作,做完了就移到Done。上圖中的第四個欄位,我放的是以日期做標題的前一天所完成的工作,目的是檢視用,看了以後再寄信給自己做成回饋鏈。目的是透過 email 的方式來提醒自己衡量自己的工作成效。

.

不知道從哪裡開始?

如果你沒用過看板、不知道什麼是看板方法,下面是我的開始(記得第一次畫這張圖是在餐廳裏頭,用的是黃色可回收的紙巾),請堅守一次只做一件事,那是因為聚焦可以讓你心無旁騖做好你該做的事,多工只會害你失誤。而開始的第一步是排序。做你認為此時此刻應該做且最有意義的事。開始執行的方式事依靠 「 拖拉 」 這個動作。它的意思是前面的工作已經做完了(拉進Done了),如果還沒完成就不能再拉入新的工作;被擋住了(Blocked)。所以我可以開始拉進新的工作來做了,意思就是用線性化的流程被擋住的方式來實踐 「 單工作業 」 (請參考這一篇)。繪製下面這張圖,只需花掉你幾秒鐘的時間,但它卻可以把腦中的一維的 To do list 變成平面可視覺化的執行過程(請參考: 讓 To-do List 變敏捷起來),這便是看板的價值。

看板方法的秘訣是聚焦

小結

一分鐘看板的運作方式就這麼簡單,拿起手機就搞定了。當然你也可以藉著閉上眼睛就想好你的工作,但起步之前請先寄一封信給一分鐘看板。信的內容是你現在最想做、最需要做的事。家庭第一、健康第一。這二件事我總是把它們放在最前頭,所以居家上班時我經常會跑去做家事或是出公差去採購材米油鹽之類的工作。老實說;我一點也不以為意。因為持家不是老婆一個人的工作,是全家人共同的事。失去上班的工時怎麼辦呢? 哈哈!我是一個負責任的工程師,雖然被中斷了,但內心想過了,卡片也寄出去了,凡被中斷的就得補回來,何必在意呢? 必定家庭第一啊! 囉說一下;如何思考什麼工作最重要而不是最緊急呢? 從它對你的意義上來思考,這是最有用的方式。當你覺得放不下,哪就把它移到最重要的位置,開始做吧!

如果你有在用 Slack 之類的即時通訊軟體,可以在前進一步把它們結合起來,你會很訝異 Trello + Slack 可以把提示變成即時性的。讓居家上班仍能夠時時受到有用的提醒,這是跟自己協作的方式,但如果稍稍改變一下,便能變成和他人協作的方式了。只是複雜性相對的就變高了。等有機會再來聊它。

培養在腦子裡想像 To do-Doing-Done 的看板,需要經常練習,習慣了就會在想完之後作相互對照,拿起手機來看看是想得快呢?還是手機上的正確些,蠻有趣的;我經常在躺椅上做這件事,手上明明就握著手機,但硬是要用背得來驗證自己想像的準確。也算是動動腦的方法吧,它讓我對該做的事更不會遺漏,而且記憶的更深。試試看;蠻有趣的。

WFH: Work From Home 居家工作

居家上班或許將成為未來的一種常態生活。它打破了古老的公司經營型態。人類在遭遇病毒威脅下又一次的改變了社會生活的型態。這種工作方式我一點都不陌生,自己十幾年前就一直是自由工作者,是一人公司的老闆,是自己的總經理,但也負責發薪水、發年終獎金給自己。自己在經營自己的職業生涯時 ,經常要在面對家庭事務與工作之間做取捨,或許曾經覺得兩難,但時間久了就學會用它對我的 「 意義 」 來做衡量,相當的自我意識,但這不就是 WFH嗎?從前是工程師從PO手上接過需求,然後把它分解成一個一個的問題然後解決它。好像沒有太多選擇,也不太需要排序。現在你居家上班了,需求變得更多了,它混雜了公司的工作跟家庭事務,彼此之間經常會相互中斷,所以你一定要有一套處裡中斷的好方法。一分鐘看板就是在這樣的情境下產生的。運用手機上執行的 Trello 看板,用email的方式填加卡片,然後在打開手機做拖拉卡片(視覺化、單工作業)的方式做工作的切換或 pending。這麼做減少了被插斷事情所造成的凌亂,有看板做紀錄也提供了視覺化的效果,又有email 做時間差的回饋,無形中構成了一種回饋成長的循環。 而To do-Doing-Done 的看板,實則是在執行一種可有可無的看板(三步驟工作列表),由於WFH時我們就是會經常拿起手機來查看,各種訊息的變化,此時就當作是打開看板來排序工作事項,不是很好嗎?

雖然看板方法不建議把個人居家的事務與公司的工作混在同一個看板上。但現在碰到疫情勢虐,大家都採用遠距上班WFH的方式,因此勢必要有一套方法來維持原本的透明性和效率。所以簡單好用才是重點,請嘗試看看一分鐘看板

.

註 1. 我的Trello 一分鐘看板範例在此。

打開「以電子郵件新增看板內容設定」,這裡就會看到「你個人專屬的」電子郵件地址,把你的郵件寄送到這個地址,就會用你的名義增加一個卡片任務到看板中。只要拖拉一下就可以開始工作了。

註 2. 《一人公司 :為什麼小而美是未來企業發展的趨勢》 作者: 保羅.賈維斯 ,一人公司不只是「一人」的公司,一人公司是「質疑傳統成長」方式的企業模式。是作者從事十多年自由業後的心得,但實際上運用到現在疫情下大家都採用WFH的方式,便顯得意義不同了,就是請思考你要如何在居家上班之下來經營自己的職業生涯呢? 這真是值得思考的一件事,也需要一些智慧。

註3. 回饋 email: 請參考與自己對話

開發者體驗DX

重視UX的團隊換來更好的需求探討, 

重視DX的團隊換來良好的開發紀律。

(DX 如果你是第一次聽到這個名詞,簡介的 Youtube 影片在這裡 )

大家都知道開發人員既昂貴又難找,甚至更難以相處。企業通常會以豐富的福利、獎金和優惠待遇來專注於改善開發團隊的效能,但往往很少關注最關鍵的方面,也就是;開發人員能否有效地工作,他們享受工作嗎?這便是下文我們要談的開發者體驗DX(Developer Experience)。

DX真正的目的

UX有多重要已經是不爭的事實,但我們卻很少談論到DX,就是“開發人員體驗”。請回想每次我們嘗試使用新的開發工具,沒使用過的程式庫(lib)或是第一次呼叫新的API的時候,必須經歷的種種情境。首先;我們需要先決定要不要使用這種工具?甚至是該不該使用?它與我們的開發環境是否容易整合?這組應用程式介面(API)的靈活性不知道如何?出現問題時我們應該去哪裡找解答呢?這些都是我們每每都要問到的問題,這便是開發人員日常使用產品時的感覺,而過去這些個感覺都不會有人在乎的,我們也只能偶偶吐吐苦水,所有的不快也只能逕自往肚子裡吞或者留作茶餘飯後的消遣議題,當然就更不用談應該往何處去反應如何被改進了。而這些都是DX的範疇,也就是開發者體驗,它們也應該像UX一樣的被重視。

「好的開發者體驗DX,讓開發者可以快速透過API來打造所需要的服務,替你的產品或服務創造更大的附加價值。」

狹義定義指向開發者的API體驗,廣義定義則指向所有開發的作業

DX範疇的簡單判斷

當產品的主要用戶是開發人員時,開發人員體驗就相當於使用者體驗。DX 泛指有關使用產品、Lib、SDK、文件、框架、開源解決方案、通用工具及API等的開發人員經驗。因此在進行開發作業之前,請先確認一下誰是你的使用者,他的 persona又是如何? 我們應該如何設計才會讓我們的使用者覺得順暢愉快,甚至吐出一聲『哇』來呢?

.

誰是你的使用者?

DX;是在UX 風潮下衍生出來的開發者體驗 DX ,Developer Experience思維。它實質上不是什麼新觀念,只是我們一直未能正視它的重要性而已。而開發者在進行產品開發的流程時,實際上是有多個面向且有多種角色需要參與的,請看上圖的軟體開發週期。工程師在進行軟體開發作業時,當扮演什麼角色時就需要弄清楚所面對使用者是何種類型的人物(Persona, 人物誌),才不至於偏差了開發的方向及使用時的順暢度。

.

開發者體驗是瞭解開發人員如何完成其工作,並進而優化該體驗的實踐。

.

UX 與 DX有著同的體驗原則

毫無疑問;DX 的靈感是來自UX使用者體驗實踐,將開發人員視為使用者的特殊案例。好處是;我們可以應用 UX 原則及許多工具來改善我們對 DX 的理解,並且與任何 UX 的原則應用一樣,我們還需要考慮領域本身(扮演的角色),在這種情況下,這意味著它涵蓋了整個軟體開發的生命週期。因此,DX 其實是UX和一般開發原則的結合。

.

大多數成功的產品最終會演變成為 API.並逐漸形成一個API的生態圈。

.

AaaP; API as a Product = API即產品

重視應用程式介面API,開啟DX的大門

身為工程師我們多少都撰寫過程式來呼叫別人設計的API介面,目的可能是取得資料或是獲得服務。請問寫這支應用程式花了你多少時間呢? 撰寫的過程是順暢還是滿腹的怨言呢? 這便是一種最典型開發者體驗。API介面設計的好與壞的差別可能因人而異,每個人的感受不同,但隨後而來的流程體驗或是維護更新就可以看出設計者的功力了,對使用者介面體驗UX而言,我們會說設計者是否考慮到使用者會如何操作它,而對 DX而言則是程式設計人員會如何來呼叫它呢,好與壞真是大異人心。但這股趨勢卻是不爭的事實。

.

API即產品;是指「組織將API視為可衡量的產品」.

.

<Something>-as-a-service 是一個讓人心生敬畏的標語。聽起來就好像有一股新風潮即將對準著技術人員席捲而來的味道。讓我們來回味一段歷史;記得是從 1983年昇陽電腦提出「網路即電腦」The Network is the computer 開始,到1996年,Compaq公司首次提出了「雲端運算」Cloud Computing這個詞彙(現在雖然Compaq不見了,但雲端將永遠長存)。隨後AWS的雲端真正的成熟並成為一代雲端的霸主,並造成一股「軟體即服務(SaaS)」的風潮。而AaaP,API as a Product, API是個產品則是指「組織將API視為可衡量的產品」,也就是對待應用程式介面(API)的方式,與其它的產品並無差異的意思。講得白話一點,就是將API的原型、設計、部屬與管理視同為一個產品來開發維運。這也意味著,設計一個應用程式介面(API) 也應該從了解你的使用者開始。有趣的是;這個使用者不是其他的客戶而是開發人員(developer)。我認為這是一股 DX的風潮,DX太重要了,對一個時時處於壓力之下的開發人員,一個設計良好的工作情境可以提升多少效能,又能避開多少陷阱、多少不經意的缺陷呢。

Thouhtworks的 DX定義

小結

這篇文章的用意在推廣DX的觀念,也期待未來在人力銀行裡會出現這個需求的項目。市面上談UX的書到處都是,但卻找不到任何一本專門談DX的書,這意味著DX的觀念尚未普及,但對開發者而言這是何其重要的一種觀念,我們怎麼能不考量到使用我們程式、元件或程式庫、工具的程式人的感受呢? 反過來想;我們應該在設計之初就把那些使用時所可能導致的坑坑洞洞都避開來,用良好的設計來協助程式開發人員迅速解決他的問題。

.

希望程式員的日子不用過得那麼辛苦,同時希望那些苦過的人,能夠為後進留下一條更好的路徑,並未自己的未來創造一條康莊大道。

-個人的目的

.

DevOps 的崛起讓產品開發的速度得到了莫大的提升,其中最大的因素是我們把 Dev + Ops 了,但很快的我們發現開發速度最大的瓶頸是需求(還是20/80法則的規範沒做好),忽略了真正做好一個好需求勝過你開發再多的普通功能。因此UX設計師出現了,他們為使用者與機器之間的人機介面把關,設計出符合用戶的操作介面,讓使用者得以順利的完成他們的需求。但軟體的生命週期不只有用戶在內,其實開發者也佔據蠻大一段的產品開發週期,而維運人員更是自始自終的伴隨著產品的起落,實際上也不能被忽視。尤其在大家聚焦於開發速度的時候,你很容易就會發現,最大的限制(TOC理論)竟是在開發者身上,所以我們開始把焦點移向了開發者(developer)。要怎麼樣做才能讓開發者更快的完成他的任務呢 ? 加班不是一個好選項,因為人疲勞了效率也會自然的下降,而且產出的錯誤也會加多。答案就像UX為用戶設計良好的體驗一般,我們需要有DX的設計師,他們為開發人員設計一條順暢的開發渠道,讓開發人員也能順暢地完成他們的工作。這是DevOps 走到今天再次遇到的挑戰,改善開發人員的體驗就是加快開發速度的不二法門。 是時候了;我們應該讓資深的技術人員為後進的工程師設計一條Guideline,讓他們足以順暢的完成他們的任務。

程式設計是一種經驗主義,經驗越是豐富的程式師越能把程式設計得面面俱到,因此不同於UX設計師的一點是DX設計師可能更適合資深的工程師來擔任,這也可以為工程師的晉升之路增添更多的選擇,也就是成為一名優秀的開法體驗設計師

敏捷10字口訣是實踐DX的基礎

.

很多人都不知道敏捷是DX的基礎觀念,因為敏捷開發一開始就是為了程式開發人員而興起的,2001年參與草創的17位人士都是當代極端傑出的軟體工程師,目的也是為了協助工程師快捷的完成他們所被賦予的任務,這一點與DX的定義完全可以相輔相成。如果我們把敏捷的觀念深入DX之中,便能得到以下結論。敏捷以為;開發者體驗應該建立在簡單有意義的小增量之上(小範圍的簡潔設計, 極簡至上),而這個小增量應該是居於某種假設而來的(漸進式的設計,遞增式的完成任務),在迅速得到結果驗證(重視學習成果)並透過展示給相關的利益人員後尋求有意義的回饋得到改善,透過Sprint的開發經驗換來成長的喜悅,接著再邁向下一個迭代(持續改善)。上圖中的小增量、多迭代與尋求回饋正是這個意思。

DX的幾個重要優點:

  • 提供更高品質的程式碼
  • 提升開發效能,減少維運負荷。
  • 即時反應,即時滿足迅速上手,一種開箱即用的體驗。
  • 避免(擔心)新手會出狀況。
  • 持續改善;工作愉快,增長實質投入
  • 讓敏捷更加敏捷

提供更高品質的程式碼

開發人員工做的越是順暢當然所撰寫出來的程式品質有機會越佳,就跟良好的學習體驗一樣,學生習得的技能自然更加踏實。這種情形經常發生在我們選對了一個好的元件或是程式庫時,順暢的開發經驗讓人能夠簡潔的達成任務,就像是呼叫到一個開發者體驗設計良好的應用程式介面(API)一樣,程式員能夠迅速地透過範例的引導,快速的完成了呼叫程式的設計作業。這樣的體驗;自然而然產出的程式碼會有較高的品質。

UX就是讓使用者高興樂於使用它,DX則是讓工程師愉快地進行開發作業。

提升開發效能,減少維運負荷

就好比使用者用到一個好的體驗時,經不住的「哇」一聲說明了一切,同樣的當開發人員用到一個好的元件、程式庫或工具時,如果也能獲得同樣的感受則接下來的開發作業,自然就要順暢許多,效能也就自然的提升,而在維運上不知道可以減輕多少工作量。例如良好的錯誤訊息或是好的反例提示。這一聲「哇」就相當有價值了。

即時反應,即時滿足迅速上手,一種開箱即用的體驗

大多數時候,開發人員都在急著找到解決其面對問題的答案。這個解題過程的內心所受的煎熬大概只有親身經歷過的程式設計人員才能體驗。當我們急著找解答時當然希望能有開箱即用的效果,而不是讀完了 Readme文件的注意事項後,接著請你再去讀文件的格式說明,然後是初體驗說明。反之;應該是在 Readme裡頭就能包含初體驗及簡單的規格說明。讓使用者可以快速的上手,這一點就跟新進人員onboard時能多快上手一樣,新人花越少時間上手就表示貴單位的效能越好。

避免(擔心)新手會出狀況

我們總是在軟體出問題的時候,才想到工程師為何會犯這種無知的錯誤呢? 害得大家雞飛狗跳、人仰馬翻的。但事後也只是記下過錯,發誓絕不再犯。可是;我們可曾回過頭來探討工程師是在怎樣的情境下犯的錯誤呢? 我們要建立怎樣的DX 才可以避免這個錯誤呢? 這便是典型的DX的價值所在。從開發人員的角度去看產品的開發作業。也就是治本之道。

持續改善;工作愉快,增長實質投入

工作愉快才能迎來主動性的持續改善。這種改善方式屬於雙贏的形式,工作人員因為學習而成長了,然後在經營它的工作時便展現出成熟的風貌,能夠主動的改進自我,在公司與個人間展現出雙贏的局面。

這一點對於智慧型工作者至為重要,

敏捷與開發者體驗

敏捷開發原本就是為了軟體開發而設計的。2001年發起的17為工程師都是軟體工師。第一條宣言「個人與互動重於流程與工具」。就直接說明了使用者體驗的重要性。 而針對開發流程的真正使用者正是在不同階段扮演不同角色的工程師。所以敏捷以為;開發者體驗應該建立在簡單有意義的小增量之上,而這個小增量應該是居於某種假設上的,在迅速得到結果驗證後,透過執行(Sprint)的經驗換來成長的喜悅,然後再邁向下一個迭代。

讓敏捷更加敏捷

敏捷即務實,程式人員在進行開發作業時最重要的即是務實。例如: 大量的文件對coding起不了太大的幫助,應該適量(just enough) 即可,這就是務實。程式交付一定要經過測試尤其是自動有效的單元測試,而不是把測試的工作交付給測試人員,這也是務實的做法。擔心新人犯錯、擔心程式品質不夠好,要好就做好code review、就把自動化測試做好,這就是務實。敏捷的思維其實就是那些傑出的軟體開發者在教我們怎麼做好程式設計的工作,而開發者體驗DX正可以基於這些技能再加入人性的考量,就好比應用程式介面的設計,通常設計者都是已經會了而且對這項技能十分熟練的人,他絕對不能用自己的觀點來做設計,應該反過來思考初次嘗試這項技能的人會怎麼做,依據他的 Persona做判斷,引導他按部就班的完成初次的體驗。因此開發者體驗的加入可以讓敏捷更加敏捷,也就是基於那些敏捷化的 guideline 針對程式設計再投入更多人性的考量。

.

工程師個人崗位 -> 管理崗位 -> 初級經理人 -> 技術管理 -> 中層經理人 ->

資深經理/技術總監 -> 高級經理人 -> 首席科技官

(工程師的職位歷程圖)

.

以工程師的成長歷程來考量DX的重要性

這是一條漫長的職涯生活之路,工程師由個人崗位受到命運的安排接觸到管理崗位然後開始摸索著前進邁入初級經理人的境遇,或許是你捨不得放棄追求新的技術新知讓你持續做著技術管理 的職務直到成為中階層的經理人,你的眼界放寬了,對許多事能想得更深更遠了,便來到了資深經理或是技術總監的職位,隨著時間的推進自然就成了高級經理人,在更上層樓之後就在企業裡掛上首席科技官的抬頭。

如果你運氣好的話,始終可以跟到那些以身作則品格高尚的人士為伍,真慶幸你得以順暢的走在這條路上,你的體驗歷程可謂良好順利。若是中途遭遇到逼得你同流合汙又經常遊走在法律邊緣的工作或上司的話,一種隨時會陷入深淵的情境就不是一種好的體驗了。最後想強調工程師成長歷程也是DX範圍的重要一環,主要是考量到技術主管的養成經歷,其中人的品格也是一種不能忽視的重要因素, 而且是一種最不可或缺的要素。

.

註1. DX, Developer Experience 開發者體驗相關資料並不多,但有二個入口可以關注:一個是美國API Academy 有關API設計的推廣理念,裏頭常常會揭露到 DX的許多特性。另一個是 Thoughtworks 公司的科技雷達常常會出現較好的文章。

此刻我們正在公司內部推廣 DX 理念,我們入門的手法也是從最顯而易見的 API 設計開始,但推行開發者體驗DX應該更甚於此,最後附上 2002 的 Bezos issuethe API mandate(它傳奇般的改變了亞馬遜成為 AWS)供大家參考。

Bezos issuethe API mandate

如果你有興趣研究的話可以再參考《持續API管理》會更紮實些。

註2. 設計API沒有既定的規則,但有一些styles可依循,請參考:

註 3. 設計API的幾篇好文章

註 4. IEEE 的定義 (2012 年)

New ways of working such as globally distributed development or the integration of self-motivated external developers into software ecosystems will require a better and more comprehensive understanding of developers’ feelings, perceptions, motivations and identification with their tasks in their respective project environments. User experience is a concept that captures how persons feel about products, systems and services. It evolved from disciplines such as interaction design and usability to a much richer scope that includes feelings, motivations, and satisfaction. Similarly, developer experience could be defined as a means for capturing how developers think and feel about their activities within their working environments, with the assumption that an improvement of the developer experience has positive impacts on characteristics such as sustained team and project performance. This article motivates the importance of developer experience, sketches related approaches from other domains, proposes a definition of developer experience that is derived from similar concepts in other domains, describes an ongoing empirical study to better understand developer experience, and finally gives an outlook on planned future research activities.

註 5. 由 Youtube 上的影片,你會發現美國已經舉辦了好幾屆的 UXDX Seminars 活動了而去年日本也開始舉辦了,稱為: Developer eXperience Day2021。可以開始期待台灣的第一屆 Developer eXperience Day 了。

註 6. 推薦 軟技能 一本完全沒有程式碼卻是寫給工程師的 DX好書籍

主管;你很忙嗎?

想要加快團隊的開發速度,告訴你一個加快開發效率的秘密;就是把一個目標切成多個小目標;開發速度自然就會加快了。

-Ruddy Lee

《一分鐘經理人》三個訣竅

沒有不忙的主管,就沒有不忙的工程師了

如果你問主管最近忙不忙? 八九不離十;一定會回答: 忙死了。接著問他,哪你有什麼方法來解除你的忙碌呢? 他可能會落入一段沉思。接著反過來問:那你的下屬忙嗎? 最可能的回答是: 他們也忙得一塌糊塗。哪你有什麼方法來解除他們的忙碌呢? 身為主管,這可是你的問題了,所謂的忙中有錯這意味著過於忙碌就容易犯錯,不要等出了大問題時再來亡羊補牢就來不及了。

運用敏捷口訣詮釋新一分鐘經理人

.

解決忙碌;提升效率只是治標;治本之道則是適度的去完成真正的目標。

.

經理人要怎樣做才能不那麼忙呢?

答案是運用敏捷流程的核心觀念:「小增量、多迭代及尋求回饋」,做法則是對照到《一分鐘經理人》書裡頭的三個訣竅。如上圖所示三個訣竅的運用如下;先和下屬一起設定一分鐘目標(讓目標變小的好處是容易確認不會做偏了,也就是小增量、多迭代),確保每個人知道自己該做什麼,以及好的工作表現的標準;之後你會努力發現他們作對了什麼事,好對他們進行一分鐘稱讚(激勵、鼓舞士氣);最後,如果發現有人在工作上犯了錯,就對他們進行一分鐘更正(取得回饋後進行檢核、調適)。

.

敏捷口訣對照一分鐘目標、稱讚及更正訣竅

一分鐘目標 Goals

因為一直在做適時的調整3個訣竅,所以目標走偏了的機會降低了,也自然的減少了返工的機會,因此設定一分鐘目標是提高工作效率的一條最基本的途徑。這一點與時下流行的目標和關鍵成果OKR 很類似,這樣做可以讓人們每天回顧自己的目標,對比自己的行為,產生自覺而自我修正的機會。將目標訂小了(也就是小增量)可以讓工作進度更透明更容易發現錯誤,別人也更好給予回饋,既容易達成共識也容易進行確認跟修正(不會做到最後才發現做錯了)。能夠協助工程師在開發過程中進行知識的累積,也能有助於程式品質的提升。應該要:

  • 清楚闡明目標,取的共識。
  • 明確好的工作表現標準,對OKR而言就是制定關鍵結果(Key Results),還記得0.7原則嗎,好的關鍵指標本身就是一種激勵。
  • 每個目標用一頁紙描述,遵守簡潔易懂的Simple原則。
  • 經常性快速回顧目標,開始時要較頻繁的關注,當上軌道後就可以維持一定的關注頻率即可。
  • 鼓勵人們審視自己的表現是否與目標一致,正是OKR的每日回報。
  • 表現不一致就要敦促調整,千萬不要因為自己也不清楚答案就不置可否,應該鼓勵積極的去弄清楚它。
  • 一直到達成目標為止。

一分鐘稱讚 Praising

有效訓練部屬最重要的關鍵的是,當發現他們基本上算是部分作對事的時候,就給予(作對的部分)適時的鼓勵,激勵他們因為做對了。我們都知道要在新人入職時給予關察、關懷一直到他能上手,但是其實人人都需要激勵,這是人們表現更好的動力。實施時;

  • 稱讚正確行為。
  • 即時稱讚並具體說明原因。
  • 顯明的表達出你的喜悅,讓對方受到肯定。
  • 沉默幾秒讓對方體會。
  • 鼓勵繼續這種行為。

.

訴說這件事對在哪裡;比訴說這件事錯在哪裡要有效的多 -因為它能夠賦能。

.

一分鐘更正 Redirect

大多數經理人都喜歡把回饋(不滿)累積起來,也就是說,他們對下屬的錯誤行為不置可否,等累積到一起算總帳。這是很不好的習慣,但經理人卻總以為這是自己容忍的美德,要知道及時更正;在錯誤剛剛發生完後立刻進行更正才是最有收穫的時機。務必:

  • 重新申明目標並達成一致共識。
  • 確認既有事實。
  • 分析錯在哪裡。
  • 表達你對這個錯誤的感受。
  • 沉默幾秒讓對方審視錯誤。
  • 告訴對方你的實力其實比這個強多了,你很有信心。
  • 更正完畢整件事就過去了,千萬不要去累積他人的過失,反過來應該立即告知即刻更正才是良好的回饋。

小結

想要加快團隊的開發速度,告訴你一個加快開發效率的秘密;就是把一個目標切成多個小目標;開發速度自然就會加快了。 這個方法是我多年來到處作顧問不變的手法,它始終有效,請試著問你的團隊;為什麼? 讓他們自己去思考、討論為什麼。它讓共識變得自然而簡單,而簡單造就了效能。

(新)一分鐘經理人的三個訣竅,道理很簡單;實施起來其實也一點不困難。步驟如下: 首先;在專案開始之初要讓團隊看見全貌(影響地圖與使用者故事地圖就在做這就事)。團隊在知道全貌時才能意會到自己在哪裡? 也容易認知到自己缺少那些知識或技能才能夠完成任務。接著;就要善用小增量的觀念,將目標分成多個小目標(一分鐘目標;書裏頭運用 80/20原則來說服大家只要對重要的 20%做目標設定就可以了;無需另外設訂剩下的80%,可以將它們視為次要目標。這個觀點大家都很熟悉,但實施起來卻仍是100/100,所有的需求都一樣的重要。這裡換成敏捷的制定小增量原則,就務實多了),請謹記敏捷的小增量制定原則,也就是必須是「潛在可交付的目標增量」,它可以很容易收到利益相關者的回饋(避免做到最後才發現做偏了)。每個小增量盡量設計成對正到一個或數個開發的衝刺(Sprint)週期,並讓每個衝刺都是團隊驗證成功或失敗的時機點,成功或部分達成就應該對做對了的地方予以稱讚(一分鐘稱讚),失敗的地方取得更正的正向回饋,並進行更正(一分鐘更正)。

將新一分鐘經理人的三個訣竅融入敏捷開發流程中

新一分經理人溶入Agile

敏捷運用小增量、多迭代的方式,將大目標切割成小增量以多做幾次的方式來逐步完成目標。目的是讓開發者漸進的累積對產品的開發知識,同時間運用對需求增量的設計,也就是以「潛在可交付的小增量」,來獲取使用者的經驗回饋,用這種方式來修正產品對使用者的好用性,也就是增加價值。這與一分鐘目標正好不謀而合,而80/20法則也正好讓我們能夠聚焦在較重要的功能上,而不是對所有的開發功能都一視同仁,它能夠將開發的努力聚焦在最有價值的地方。

敏捷團隊的效能多半來自在開發過程中的激勵效應。這正是一分鐘稱讚發揮效力的時候,敏捷團隊在每日的站立會議時常常有許多掌聲或笑聲正是一種團隊的激勵效應,但 一分鐘稱讚更重要的一個目標則是引導,因為稱讚正確的行為往往能夠引發更多的仿效,能夠帶來更多正面的效應。

回饋 feedback, 對經理人而言是改正下屬行為或工作失誤的最好時機,能夠即時且確實做到才能獲取最佳效果。一分鐘更正則是經理人進行衡量之後正確回饋的時機點,相對的敏捷流程則是在檢核(Review)會議時針對產品開發的增量尋求回饋;讓團隊在衝刺完成一個或多個Sprint增量時可以有機會聽聽客戶的反應,藉以調整自己的設計。接著在回顧會議(retrospective)時透過團隊自己檢討的方式來改善缺失。這是一種團隊自我管理的表現。經理人則應視團隊或個人的情境予以協助(請參考情境領導理論)。

.

運用80/20法則 設定一分鐘目標

「你獲得重要成功的80%都來自於你20%的目標,所以我們只對那20%設定一分鐘目標。」

一分鐘經理人實施方法

.

一分鐘經理人具體實施方法

抱歉我把三分鐘變成五分鐘了。一分鐘經理人原本是三個訣竅,也就是設定一分鐘目標然後看是成功或失敗再去進行一分鐘稱讚或是做一分鐘更正。總計起來就是2 ~ 3分鐘。但在我實際實施時卻發現目標往往需要有衡量標準,而且最好是在設定目標時就與對方約好結果的評量標準,而這不就是 OKR了嗎? 因此;就把 OKR 的關鍵指標(Key Results)加了進來。但是在實施過程中,經常可以感覺到新經理人的不安情緒。為此;又把透明(可以看見問題)的手法加了進來,那就是運行看板背後的理論基礎,就是限制理論(TOC),讓經理人經常的去思考,目前系統最大的限制是什麼;然後就可以把目標修正到這個約束的方向上。因此有了下圖的實施方法。具體說明是: 以敏捷為基礎;也就是 「 小增量、多迭代與尋求回饋 」來設定目標 。接著是運用 OKR的觀念;在設定目標時就把激勵效果加了進來,那就是設定 「 0.3 正常工作/0.5 用心工作/ 0.7表現優異 的關鍵指標。最後是運用限制理論來持續 「 思考目前系統運作的最大限制是什麼? 」 也就讓系統能夠持續改善,也能避開落入局部優化的陷阱。

具體實施方法

.

若是主管想藉由持續的增加工作壓力來讓部屬成長,這是完全錯誤的觀念,因為潛能是藉由激發所產生出來的,增加工時的產能只會增加負荷換來倦怠,成效適得其反。

潛能就是能耐,要靠士氣去激發他而非壓力,

否則當壓力消失後 …

.

1.《一分鐘經理人》為 1982年為 肯.布蘭查 與 史賓賽.強森 所合著。

新一分鐘經理人》則於 2015 年誕生。小小的一本書,卻解答了經理人過於忙碌的處理原則。實施時只要對正到敏捷流程,效果即能自然浮現。(新版將第三個訣竅由One Minute Reprimands 改成 One Minute Re-Direct,也就是將批評改成了更正)。

2. 80/20法則 ;又稱為 柏拉圖法則 (Pareto principle)、關鍵少數法則、八二法則;它指出,約僅有20%的變因操縱著80%的局面。也就是說: 「 所有變數中,最重要的僅有20%,雖然剩餘的80%占了多數,控制的範圍卻遠低於「關鍵的少數」。 此原則在現今企業管理中廣泛被運用。例如:「80%的銷售額來自20%的客戶」。理察·科赫 Richard Koch 撰寫了一本「80/20」原則,展示了柏拉圖原則在企業管理和生活中的實際應用。

註 3. 溶入OKR的運用,請參考:

如果你的團隊已經在運用OKR了,便可以輕鬆的運用關鍵結果Key Results來判斷針對目標的達成是成功或是失敗,然後再決定該進行一分鐘稱讚或是進行一分鐘更正,唯一要注意的是回饋必須是即時的才會產生最好的效果。(經常有團隊在施行OKR時,覺得更忙、更沒時間做工作時,那便是沒能將80/20理論融入OKR的制定中,而那是實施OKR的基本思維,也就是你80%的成就,其實是來自你 20%的努力)。

將目標關鍵結果OKR 溶入到新一分鐘經理人

註 4. 80/20 法則,推薦80/20法則:商場獲利與生活如意的槓桿原理by Richard Koch,這本書的宗旨就是要幫助你不要那麼忙! 但如果你還是那個凡事都要做到 100/100(50/50是一種認為凡事有因必有果的線性思維方式,他把事件的聯繫看單純了。而100/100的思維則是一種更荒唐的思維, 他想要把所有可能的因素都做進產品的錯誤思維者,是一種天生的勞碌命者,也連累到他的周邊人員),然後又沒有時間磨刀的砍柴工的話,那便是一本放在沒時間看書的人士桌上的絕世武功祕笈,它會一點效用也沒有的。

IT主管的敏捷情境領導

Paul Hersey 於1969年所創,為領導者加入了環境因素

.

情境領導理論強調環境因素對領導效能具有絕對的影響。採用時勢造英雄的觀點,且組織的結構、氣氛、角色特徵及部屬特質,均是影響領導的情境因素。

-Paul Hersey

針對位於 S1 較低成熟度的人,稱為「教導」: Telling

領導者必須指出何地、何時和怎樣做。但不宜表現出過多的關懷,否則就可能被認為你是一個含糊、隨便支持後進的人,反而會不力於指導。

針對位於 S2 中等成熟度的人,稱為「推銷」: Selling

領導者仍需進行指導和指引,通過解釋原因澄清事實。要讓追隨者買帳才是。

針對位於 S3 中等較高成熟度的人,稱為「參與」: Participating

領導者和追隨者相互指引和指導,領導者的主要作用是促進和鼓勵追隨者們關心和參與。

針對位於 S4 較高成熟度的人,稱為「授權」: Clelegating 因為領導者把決策和執行的責任授予了追隨者,只需在任務外圍進行觀察即可。

.

主管;請後退一步

實施敏捷化時,主管最常聽見敏捷教練說的一句話:「請後退一步,讓團隊自己做決定」。目的是養成團隊自組織的習慣。為了讓團隊習慣自己管理自己的原因,敏捷教練只好站在團隊與主管之間,冒著被責難的危險勇敢地請主管後退一步,讓團隊自己處理他們自己的問題。一開始有很多主管都不能適應,尤其是一些現場經驗十分豐富的主管,越是難以適應。就像父母親對待孩子一樣,我們總是擔心他們因為犯錯而受到苦難,而忘了當年自己也是這樣成長過來的,孩子們總是在犯錯後學得最多,這種因為錯誤後的體悟,越是深刻對他人生的幫助就越大。對團隊也是如此,正如DevOps三步工作法的第三步所言: 在過程中持續學習與實驗原則。所謂的實驗原則指的就是 fail fast, fail safe的原則。(失敗;這是老闆們最害怕的東西,所以敏捷教練經常將失敗設計成 fail early,這就是為何有 Sprint 0的故事,它是拿來快速失敗用的,目的是讓團隊越早受到挫折,重新再起來的力道就會越大,也越能體會到敏捷的真諦。是融合團隊最有效的方式,也是讓一群人士有過共患難的難得經驗後,能夠順利團結合作建立互信的重要原因)

上面那張情境領導的圖示,最棒的地方是讓領導者「從關注領導者本身,轉向關注領導者環境」。考慮的環境因素是「情境特質 = 能力 + 意願」它說明了身為主管者,何時應該前進一步,何時又應該後退一步。

.

下面針對四種可能的情境質加以進一步的說明:

當工作能力低;工作意願高的時候(右下角象限: S1)

主管請前進一步,直接告知應該怎麼做,幫他做決定。一般發生在升任新職務的人士,屬於熱心新手的階段,有意願把工作做好但卻缺乏經驗,這個時候他的主管應該以告知型領導的方式來協助他,也就是指導多、支持少的情境運用。原則是;告知、引導、指示及建置。

當工作能力低;工作意願不高的時候 (右上角象限: S2)

主管也請前進一步,以推銷的方式跟他解釋應該怎麼做,說服他做決定。一般發生在對新任職務尚未完全勝任的養成期時段,這個時候主管應該以銷售型領導的方式來協助他,也就是指導多、支持多的情境運用。原則是;推銷、解釋、澄清及說服。這個階段往往是離職率最高的時期,他需要更多的關懷,多讚揚並做回饋可以提升效果。

當工作能力高;工作意願低的時候 (左上角象限: S3)

主管請後退一步,並以參與者或支持者的方式來跟他討論,但要把決定交給他,也就是讓他當責。一般發生在對職務已經十分熟悉的老手身上,這個時候主管應該以參與型領導的方式來協助他避免他養成逃避責任的惡習,也就是指導少、支持多的情境運用。原則是;參與、激勵、合作及承諾。這個時候就能看出主管平時能否以身作則的原則了。關懷時多做鼓勵是必須的行為。

當工作能力高;工作意願也高的時候 (左下角象限: S4)

主管也請後退一步,並以完全授權的方式交由他去進行,這個時候主管應該以授權型領導的方式來協助他,也就是指導少、支持少的情境運用,讓他養成獨立自主的習慣。原則是;授權、觀察、注視及履行。此時最適宜的協助是衍架式的教練方式(參考: 主管不能不懂的-鷹架理論)。並以追求最佳化為目標。

※ 中間那條貫穿四個象限的曲線;稱為 「領導行為曲線 」。Hersey 的解釋是你可以由成熟連續統一體( 統一體;指的是上面圖形中由四個不同顏色所組成的正方形框架)上的一點,然後從哪一點向表示領導行為的曲線連一條垂直線,在曲線上所產生的焦點,這一點就表示特定情況下最合適的任務行為和關係行為。

小結

主管;你是否還記得敏捷教練或 Scrum Master 請你後退一步的情境呢? 有時我們甚至會懷疑,如果我一直後退,當團隊出事的時候我要怎麼來協助他們呢? 其實在上面那些情境,有時你應該前進一步,但有時你又應該後退一步,依情境作判斷才是王道。情境領導理論的基本概念,包括領導的效能、領導的型態及被領導者的發展層次三個面向,其重要論點為:如欲發揮領導的效能,必須識別個體或組織的不同發展層次,運用不同的領導型態或採取不同的領導策略,惟其如此,始能達成領導目標,完成組織任務。

正是孔子所謂的: 因材施教

名詞解釋

準備度 = 工作成熟度(技能和專業知識)和心理成熟度(部屬的自信與自尊)。

Hersey 參考了馬斯洛 Maslow 的需求層次論與 Argyris「成熟-不成熟理論」的觀點而形成情境領導理論中的部屬準備度(Readiness, 也就是所謂的情境特質 )的概念。(Ready, R1~4請對照到上圖中的 Situation, S1~S4)

高準備度 中高準備度 中低準備度 低準備度
    R4     R3     R2     R1
有能力和有意願或信心有能力但無意願或缺乏安全感無能力但有意願或信心無能力和無意願或缺乏安全感

情境特質= 能力 + 意願 = 部屬的準備度 (Follower Readiness).

.

註 1. 請境領導 與 情境領導II

情境領導 (Situational Leadership) 是由 Paul Hersey 與他的研究生 Kenneth H. Blanchard 所共同開發出來的。著作是《組織行為管理》Management of Organizational Behavior (9th Edition) 之後 Kenneth 又進一步注入個人的情境展模式就成了 情境領導II ,將 R1 改成 D1, R: Readiness 為準備度, D: Developer 程度(仍是依據個人能力與意願,這一點未曾改變),在第一象限上(右下角) 便有了不同的說明。但一般都採用混和的版本,原本乃針對團隊,但在針對個人時採用 情境領導II 的說法就比較合適了。上面我自己畫的那張圖示,亦為混合版。至於個人發展歷程補充如下: