了解看板(Kanban)方法的核心方法，活化你的管理思維

上一篇：透過Kanban(看板)管理方法，視覺化並改善你的工作流程

 

在上一篇看版管理方法的介紹中，我們已經為各位介紹了Pull & push system 的差異，以及WIP的計算理念。也知道了看板的概念是將現有的工作流程視覺化，並依據整個工作流的觀察加以改善的管理方法。而在這一篇文章中，會針對看板的核心六種方法，去作更細節化的解釋，作為我們在現實的工作流程與團隊績效改善的依據。

 

 

看板的六種核心方法如下：

1.Visualize (視覺化看板)

2.Limit WIP (限制WIP)

3.Manage flow (管理工作流)

4.Make policies explicit (定義工作流)

5.Implement feedback loops (落實回饋)

6.Improve collaboratively, evolve experimentally (合作改善)

 

 

接著將會以小編身為一個開發單位PM的經驗，來為各位介紹方法。

首先透過方法1，將小編目前的工作流程看板視覺化如下，並透過方法2定義WIP，定義方式為以團隊成員數來作依據。

看板如下：

 

 

 

 

大家可以看到看板上會有著許多黃色小卡，這些卡片都明確的記錄著每一個被提出來的需求。僅管每一間公司的需求定義上都不盡相同，但功能背後所具備的3W(Who、What、Why)，相信定義上都是一樣的。

 

而我的卡片格式其實相當簡單，可以參考如下，當然3W是絕對必要的囉，所以一定要寫的清楚。一來方便溝通，二來才可以避免開發方向偏離需求本體。每一張卡片上也可以依據不同的開發類型，如優化、調整UI、BUG等等來做定義，例如透過顏色區分就是一個很好的例子。

 

 

 

 

三、Manage flow (管理工作流)

 

除了卡片本身需要定義之外，我們需要針對看板去做一些明確的定義，作為我們後續改善的依據。就像業務都會用利潤、毛利來做溝通，我們也必須針對看板上的一些名詞定義做介紹。這樣每一張卡片的管理與改善才會有一些共同的指標可以來做檢討。

 

1.看板邊界: 

各位可以看到看板左右側有兩道綠色的線，也就是我們看板的起終點。

以小編的角度來解釋，當一個需求進入了業務端的Top5時，也就是進入了PM團隊該著手進行規劃及討論的作業準備。這時關於該需求的Kick off meeting也開始著手執行，也就表示進入了開發的程序起點。當一個功能經過了需求的確認、開發以及測試都完成之後，就可以排定至Release的欄位裡，通常就表示這個功能已經開發完成並可以準備Release了。

 

而Release因為會跟公司的政策及行政、行銷活動等會有相關，所以日期通常會和當初已經開發完成的日期有所落差(應該不會有公司功能一開發完成就直接上線吧)，而也因為這個日期已非團隊權責可以決定，所以團隊的看板終點就僅於測試完成。

 

這其中的看板邊界決定的核心關鍵，在於僅可以在屬於團隊的工作義務上作劃分，當今天這個工作階段已非屬於團隊的負責範圍時，就不該那入看板囉，而當然這樣的階段也不需要WIP的限制。

 

看板邊界是指通通常看板的邊界會是影響Lead time最主要的原因

 

2.Lead time

Lead time 通常指一張卡片從進入看板起點，流動至看板終點後所需要的時間，也可以明確的表示為一個功能(或是任務、修復一個BUG..等，取決在你的卡片類型)。而使用看板的目的，除了使流動明確之外，最大的目標就是縮短每一張卡片的lead time，相反的，當lead time 越長，通常這張卡片作出來的效益也就會越低，例如你想要吃Pizza時，從製作到配送到你的手上可以吃，須要耗費一天，我想除了是世界名店之外，通常沒有人願意等吧?

 

3.Cycle Time

Cycle Time的概念比較偏向於每一個階段需要完成的時間，通常有兩種作法。

 

A. 依據階段來作區分，例如每一張卡片在進行中移動到完成的時間，所以需求、分析、開發、測試會共有四個CycleTime。

 

B. 依據階段屬性來作區分，例如最一開始的需求可能是屬於團隊裡PM的工作，需求就會有一個CycleTime。分析與開發都是開發組工程師的工作(事實上可能也是同一組人馬在執行)，那就可以共用CycleTime。

這部分倒是沒有硬性規定，可以依據實際上大家運作看板的狀況來作調整。

 

四. Make policies explicit (定義工作流)

 

當看板的名詞解釋都定義清楚之後，接下來就要針對每一個階段的起迄去作完整的定義，依照順序來解釋。當業務端的需求被排入了Top5之後，對我們來說才是應該要被具體化，將需求實現成為系統中的功能。

 

這時候的需求通常很不明確，也許只是簡單的一些異業合作，或是優化等等，而納入需求階段後，就要針對這些功能去做調研，去廣納各單位的意見，讓每一個業務單位都可以接受。最簡單的做法就是將相關的業務單位招集進行會議，並依據會議結論成為後續研究與開發的依據。

 

所以對需求這個階段來說，"開始調查"就是納入進行中的規則，而會議結束並產出會議記錄就是完成的規則，也只有當起迄的規則明確，才有辦法有效的追蹤這些功能的流動。業務端隨口說說的需求，因為沒有進入Top5需求，當然就不會在看板上有後續的流動囉。

 

 

怎麼樣算進入工程師的分析階段、怎樣算分析完成，怎樣算進入開發階段，甚至是如何算是測試完成，這些都需要整個團隊的夥伴討論，取得共識後，當作規範來做執行。每一階段得時間也都需要被明確記錄著，這樣才能有效率的檢討lead time 與 Cycle time，也只有規則明確之後，這些功能開發的lead Time 與Cycle Time 才有辦法精準，後續的改善討論才會有意義。

 

 

1.定義阻礙Block

這邊要特別介紹一下Block，相信各位常在職場上遇到一些莫名的開發狀況，例如這個功能需要等到業主確認，這個開發必須要取得外部團隊的SPEC..等等。

當一張卡片他需要明確的外在協助，才能繼續往下運作時，我們就可以透過Block的標籤來加以註記，不僅可以快速了解目前團隊遇到的問題外，這些被拖延的時間，也是需要被明確記錄著的。

 

 

2.例外處理：緊急通到

例如一些急迫性影響業績的BUG或是例行性維護等等的，若是依照正常的Flow來Run，不僅耗時，更無法在短時間內做緊急應變，若是這樣的功能卡片時常落入你的看板，這時候記得在你的看板上放入一條緊急通道，並讓她的WIP為1。

這條通道是所有的階段都只算1個WIP，表示這樣的急件為特例，而怎麼定義急件，也是要明確定義出來囉。另外WIP為1的意涵也是為了避免濫用，造成真正影響嚴重的BUG因通道占用而無法修復。

 

 

五 & 六. Implement feedback loops (落實回饋)、Improve collaboratively, evolve experimentally (合作改善)

 

一般的公司中，往往不免俗會有一些定期回報的進度會議。例如每天早上例行的站立會議(討論昨天做了什麼、預計今天做什麼，有甚麼問題或阻礙)、週會(報告當週進度)以及每個Spirint(Release週期)的檢討會議，下一次Spirint的Kick off meeting(啟動會議)..等等，而導入看板的團隊。當然也會有許多這樣的例行性會議，會議招開的時機當然也可以由團隊來做決定。

 

但看板的好處是，除了上述的會議外，我們可以當一張卡片的流動結束時，甚至是受到Block時，就招開會議去檢討。因為它並不是用一種時間限制的觀念所產生的管理概念，而是與Scrum(敏捷式開發)雷同，把每一個＂改變＂當成＂不變＂的真理，我相信很難會有一個系統從開發到完成Release中間是沒有進行修正的，而每一個修正和討論，都會是卡片被Block、Lead Time和Cycle Time漫長的主因之一。

 

所以落實回饋與合作改進最主要的理念，就是要倡導團隊看板最重要的想法－如何與時俱進的改善團隊效率、提高產能。

 

 

以上就是針對看板管理方法的簡單介紹，

當然因為這些規則多半都是小編透過自身管理團隊的經歷來做撰寫，並不一定適合每一個開發團隊來做發揮。

但記得，管理的方式永遠是死的，如何有效活用並且改善團隊的效率和產能，才是重點。

 

看板最重要的精神也是亦然－視覺化現有的工作流程，並且改善他，這才是看板管理、甚至是自我管理的重要指標想法。

 

現在許多線上軟體也有類似的功能來視覺化管理你的工作階段與流程，在下一篇文章小編就會為各位介紹這些好用的辦公室工具。

 

下一篇：光了解看板還不夠，不如用Trello提升你的工作效率吧

最後，如果你喜歡我們的文章，別忘了到我們的FB粉絲團按讚喔!!