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

傳統上為了運作看板方法;得要先去找一塊板子、貼紙、分隔線…。要準備一堆器材才能開始運作看板,這是實體看板的不便之處。但;現在不需要了,因為免費的電子看板很多,即便只是使用手機也能運作得很好。雖然電子看板的功效要小於實體看板,但在方便上! 就是簡單又方便,只要連線就搞定了,實在沒有不用的道理。若是在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 如果你是第一次聽到這個名詞,恭喜你、妳了,這是一個好的開始 )

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

DX真正的目的

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

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

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

DX範疇的簡單判斷

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

.

誰是你的使用者?

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

.

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

.

毫無疑問;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的觀念尚未普及,但對開發者而言這是何其重要的一種觀念,我們怎麼能不考量到使用我們程式、元件或程式庫、工具的程式人的感受呢? 反過來想;我們應該在設計之初就把那些使用時所可能導致的坑坑洞洞都避開來,用良好的設計來協助程式開發人員迅速解決他的問題。

程式設計是一種經驗主義,經驗越是豐富的程式師越能把程式設計得面面俱到,因此不同於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 的說法就比較合適了。上面我自己畫的那張圖示,亦為混合版。至於個人發展歷程補充如下:

敏捷的專案排程 –目標驅動開發

1950 年受歡迎的定律《帕金森法則》

還記得暑假作業嗎? 應該什麼時候做呢? 是一開始還是最後一周再做呢? 帕金森說因為有日期的限制,所以你會把時間都拖完,直到最後不得不做時才想到該去做了,這是人類的本性。因此專案排程絕對不要以日期為排程的依歸,應該以有意義的增量做目標,團隊為了達成目標而努力,如此專案才有機會提前完成,並因為團隊表現良好而獲得足以激勵他們的獎勵。例如:月餅趕工,八月十五日不是目標,中秋節才是。

不可或缺的專案排程

專案排程使專案進度一目瞭然、可以提升工作效率,可以增加規劃管理的彈性操作。讓協作團隊或維運人員可以順利啟動超前布署或各種支援行動。讓團隊的工作流程得以透明化,對專案開發而言是不可缺少的工作物件。所以在專案成立之初一定會被要求相關的時間排程。但是當你的第一個排程版本曝光之後,接著而來的便是無止境的調整作業,似乎大家都有意見。這是一種正常的情形,試想;你要與公司的戰略相配合又要聽聽各個協作單位的意見,所以改來改去實屬正常,但講得好聽一點是隨著大家開會所給的建議及溝通後的成果,會讓專案的時程規劃變得越來越踏實了而不只是你一個人在規劃,專案排程是團隊協作下的產物,而你只是負責專案方向的舵手。

目標驅動開發

敏捷的專案怎麼做排程呢? 敏捷不是強調估算是不準確的、僅供參考的嗎? 那還需要做排程嗎? 又;當遇到主管要求排程時該怎麼辦呢? 老實說;專案的時程規劃是絕對有必要的。即便它只是躺在你個人的行事曆裡,做為你的To-do List。但要知道,只有自己在看而沒有任何回饋的專案時程規劃是很不好的,少了協調回饋,這種專案排程就真的沒必要了。在敏捷開發之下,專案的時程規劃依然是必要的,只是請把日期移到目標的下方並盡量概略化(例如: 4月1號則改成 4月初,因為估算僅供參考)。也就是要幫開發的排程制定各種目標(每個有意義的小增量,都應該設定增量目標),而專案開發的過程則以完成目標為主而不是去吻合開發的時間日期。這便是敏捷開發周期稱為 Sprint衝刺的原因,團隊為達成目標而努力衝刺,所以衝刺一定要有目標而日期不是一種目標,有意義的功能才是。

概略化階段日期,改以有意義的增量為目標。

-目標導向排程

制定目標讓我們的工作有了向心力,團隊知道這個Sprint是為何而做的,也才有了提前達成的機會,團隊潛能也才有發揮的機會。那種成就感或因為表現優異而受到讚賞的作用是不可言喻的。這與 OKR的鼓舞作用是相仿的。若在時間上是允許的話就再加上OKR的關鍵結果評比就更見激勵的效果了 (給分依據:很難幾乎不可能達成的給1分,必須很努力才能達成的給 0.7,稍稍努力就能作到的給0.5,循正常工作就能達到的給0.3,而完全沒作到的就給0分)。這種團隊表現的考核才是有意義的績效評比。

主管一定會有意見的專案排程

小結

雖然我拿暑假作業來提醒你,但下一次討論排程的時候,我相信你還是會用時間做限制而忘了目標才是重點。但暑假作業則始終還是暑假作業。

為了敏捷化;我應該放棄傳統的專案排程嗎?當然不是,你只需要把以時間作為標的的方式改成以目標驅動就可以了,還有時間是僅供參考的請概略化。說明一下上面那張圖示;第一行是二階段的專案排程,我們在達成階段目標的過程將它分成多個小增量,並針對有意義的增量將它設為目標,在會議討論時以達成此目標為依歸,而不是完成的時間為標的。這一點正是敏捷口訣中所謂的小增量、多迭代開發設計。也就是運用增量的方式讓團隊能夠發揮在開發作業中所習得的知識,將累積而來的知識運用在後續的開發上頭,因為逐步完成目標會比一次做到位穫得的更多(註1)。第二行是以增量作為目標,用作簡報或討論的主題,然後將習慣陳列的日期時間移到第三行並概略化完成階段的時間(但小增量的目標時間可以不變,這麼做的目的是拿來做為風險衡量的參考指標),第四行則對工作內容加以說明。

專案排程千萬不要以日期為依歸,固然用日期來控管風險或資源會容易得多,但卻因此讓開發團隊失去了有意義的目標,也失去了可以提前完成的機會,失去了Sprint衝次的動能,自然也沒有了讓團隊有發揮潛能的機會,真是損失慘重啊。如果日期真的那麼重要,那就找出它的意義來,運用有意義的目標來取代它。若是你擔心專案會因此而延期或是造成答應客戶的承諾會跳票,那就積極的鼓舞你的團隊讓專案提前完成吧!

註1. 逐步完成目標比一次到位收穫更多

學習到的知識或技巧往往需要時間去消化它。分成幾次做完這個歷程也會在我們的記憶中留下更多的印象,拿寒暑假作業為例子,若能夠親子一起共同去完成作業學習的旅程,會讓寒暑假變得更具有意義也更為充實(當然是孩子學會了在自己去做,而你只是陪著他一起學習)。一次就想到位的想法,源自於現代人過於忙碌而致力於追求效率的結果。也往往希望一次就能完成所有的工作想法,損失了在過程中因為小增量讓你可以獲得回饋做得更好的機會。要知道回饋的價值,甚至能讓你有機會避開極可能因為犯錯而大量損失的時間及精力。

註2. 讓小增量形成目標

拿寒暑假作業為例;寒暑假作業通常被設定為,為下一個即將來的學期的內容鋪好基礎的前置學習,因此常常有數個明確的目標可循。我們可以善用這幾個目標,讓它形成小的增量,家長與孩子針對這些目標,排定一下學習的順序,讓寒暑假的生活在這幾個小的目標下逐漸的展開來,讓整個寒暑假作業變成在生活中多次迭代下的學習目標,一個一個在與家人一同學習下度過並逐步的完成。孩子若提前達成了目標就給予獎勵,延後了則表示這方面需要去加強,然後在增量即將完成之際才開始去做作業,這時候;孩子有了基礎的概念後在去做相關的作業時自然更為熟練,而學到的東西也會更多。

讓 To-do List 變敏捷起來

不是要全部做完

To-do List它不是工作備忘清單,不須要全部做完,而是要讓我們清楚下一步該做什麼,讓事情安排得更合宜。生活不是要把想做的事情通通都完成,而是要過得有意義。所以To-do List需要不斷更新、需要持續排序而不是通通做完。即便你把它當作備忘清單,也千萬不要把子項目全部做完。正如史蒂芬·柯維(Stephen Covey)所說的「真正有效的工作方法,是區分事情的輕重緩急,先做重要的事。」反過來說就是要篩選事情的重要性,只做那些值得去做的事。但是這句話講得容易,做起來卻很難。敏捷的思維在這裡可以幫上忙,請謹記敏捷的口訣:

小增量、多迭代與尋求回饋。

-敏捷精神

口訣小解

做任何事之前先思考它的小增量是什麼? 應該分成幾步來完成它才能讓我在學到如何把它做好之際還有機會在下一個迭代可以把缺憾修正過來,將事情做得更好。當然了;如果可以得到當事人的回饋,就更棒了。

.

該做什麼?

不是「下一步要做什麼? 」而是「下一步行動該做什麼?」。因為時間總是不夠用的。To-do List 列了一堆該做或想做的事,要挑重要的事做而不是緊急但不那麼重要的事去做。所以在每做完一件事後,首先該做的事便是判斷接下來該做哪一件事? 這一點可以參考單核工作的循環方式(註1)。

這是一日Sprint 配合單核工作法的個人敏捷圖示(參考說明)

只有專注才會有高效

尤其是知識工作者,更須要延長自己專注的時間,專注是讓我們不輕易犯錯的根本。一定要減少被中斷,不要以已經習慣被中斷做藉口,因為越多的中斷只會破壞你的專注力,讓它變得越來越短。培養專注能力的一種好的做法是製造一個不會被輕易干擾的環境。其實由其他人所給你的中斷應該算是少數,真正大量的干擾反而是來自你的手機、社交媒體,哪些不可預知的事件。所以在需要專注工作的時候,首先要隔離電子干擾,再來才是來自外部人員的干擾。

不只專注(Focus)要全神貫注(Concentrate)。如果你試過《蕃切工作法》或是其他協助你提升效能的工作法。還記得第一次使用它時的感受嗎? 感覺很累;特別累對不對。是的;如果你經常工作在十分專注之下,那是一種很容易讓人疲倦的工作形式,但換來的是工作的高效能。這說明了注意力是有價值的你必須在精神上付出的更多。因為有許多錯誤的產生都源於我們注意力的不夠集中,尤其是工程師在撰寫程式的時候。因此我比較喜歡用全神貫注。想要提升效能,第一件事就是必須在工做時能集中精神,心無旁鶩。

配合單核工作法的個人看板設計

小結

To-do List 就是看板的第一個欄位,在工作上;我們與團隊將開發流程運行在團隊的看板上,大家協同合作處處追求效能。感覺上就像在跑接力賽跑一樣,但是一棒接一棒的速度,絕對不會是個人個別成績的速度總和。而減少的時間則來自團隊的協同合作上頭。相比之下在生活上,運行的個人看板就要複雜得多了。原因是生活的 To-do List ,那些想做與必須做的事,種類太多了差異性也太大了。所以要怎麼樣才能更高效率呢? 答案就是能夠將工作項目安排得當。上圖中的第一個欄位裡,放了綠色的健康事項,灰色的公事還有藍色的事業項目及紅色的老婆交代的事情它們由上往下依重要順序排列。簡單陳述一下這個看板:

  • 待辦事項: 包含了個人健康、興趣、家庭事務及公司工作。
  • 5件事清單則可以在全景模式時進行填補、判斷。
  • 檢核欄位: 提供自我檢查,
  • 另外次欄位提供 等待 的暫存區,因為真實世界等待難以避免的。
  • 最後的完成區,提供夜晚上床睡覺前的回顧動作,並藉由email來記錄結果,以便形成持續改善。

運行的重點在中間的【Doing】欄位,它分成專注全景模式,並以25分鐘做切分。意思是當你專注地做了25分鐘的工作後,請切換成全景模式去審視一下5件事清單是不是有所異動,然後把最重要的事放在最上面,也就是接下來該做的工作,也就是最重要的事。

》在全景模式中, 放眼整個地平線上的任務:從現在開始的一小時最好用來做什麼?
》給專注時段設置一個固定的長度 (整點時鐘<25 分鐘) 有助於保持良好的節奏。

如果你覺得排序很難的話,那就把它寫下來,然後用OKR的方式(註2.)去評估它,自然就容易進行排序了。

To-do List沒問題,問題出在你怎麼去用它。

.

註1. 單核工作法的循環裡有一個集草器清單,遇到不會立即處理的終斷時就把它擺進去。然後給項目三個屬性: 目標、利益相關人與進入的時間日期。每每做完一件工作項目,就回過頭來看看集草器清單。在快速排序一下,決定是否放入優先開工的事項裡。

註2. OKR (Objectives and Key Results)全稱為“目標和關鍵成果”,是企業進行目標管理的一個簡單有效的系統,能夠將目標管理自上而下貫穿到基層。是企業進行目標管理的一個簡單有效的系統,能夠將目標管理自上而下貫穿到基層。它的簡單性其實更適合運用在日常生活上。

看板的流程管理

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

看板可視化了主要的開發流程,但無論是設計得再好的流程仍然需要管理來輔助,因為它是不會自我管理的。團隊運作的主要流程當然應該由團隊自我管理(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 編著的《用戶故事地圖》以用戶故事地圖為主題,強調以合作溝通的方式來全面理解用戶需求,涉及的主題包括怎麼以故事地圖的方式來講用戶需求,如何分解和優化需求,如果通過團隊協同工作的方式來積極吸取經驗教訓,從中洞察用戶的需求,開發真正有價值的、小而美的產品和服務。