2019 06 01 左永安顧問 台大 台師大 EMBA 監控專案工作是與專案的起始、規劃、執行及結束相並行。 常見的變更申請有： 1. 矯正措施：是任何改善行動可以將已發生偏差的專案績效拉回原本基準。 2.缺點改正：是當專案交付標的沒有滿足客戶需求時對交付標的重新修正或製作。 3 預防行動：是針對負向風險可能造成績效與基準發生偏差所做的預防行動。

監控專案工作是與專案的起始、規劃、執行及結束相並行。

常見的變更申請有：

1. 矯正措施：是任何改善行動可以將已發生偏差的專案績效拉回原本基準。

2.缺點改正：是當專案交付標的沒有滿足客戶需求時對交付標的重新修正或製作。

3 預防行動：是針對負向風險可能造成績效與基準發生偏差所做的預防行動。

整合變更管制的實施是從專案開始到結束。

構型管理系統為協同整合變更控制提供一個標準化、兼具效能與效率的方法，
   
                         用於提交變更申請、追蹤核准後的變更，確定變更的批准層級及核准變更。

專案團隊面對變更管理原則：

PM的職責是主動管理影響變更的因素。

在變更送核定前要先評估變更的衝擊，以口頭或書面告知客戶或發起人擬採取之變更。

若專案變更是關鍵或重大決定，由發起人決定。

無論變更批准與否，都要將變更的結果更新到變更紀要(Chang log)。

若變更核准，則更新專案管理計劃書或專案基準。

若是變更申請被否決，代表原有的問題還存在，

所以專案經理要更專注在未被解決的問題上。

2019 05 31 左永安顧問 2019 世界葡萄酒暨烈酒貿易推廣會 World Wine & Liquor Promotion 2019(SEP 20-21) 920 酒愛你 你愛酒 我愛你 你愛我 微醺搖擺之夜

2019 05 29 左永安顧問 EMBA 到底什麼是Scrum，這次要用最簡單的方法，告訴大家什麼是Scrum，讓你用最短的時間進入Scrum的工作模式！

什麼是Scrum？不是工程師也能懂的Scrum入門介紹！

到底什麼是Scrum，這次要用最簡單的方法，告訴大家什麼是Scrum，讓你用最短的時間進入Scrum的工作模式！

Kevin Wu

Feb 18, 2018

為什麼要寫這篇文章？

前陣子，為了替非程式部門的企業夥伴上Scrum的課，又重新整理了Scrum的概念，並轉化成普通人也可以想像的情境，發現這樣效果非常好，花短短2個小時的時間，就能讓每個人使用它來工作，並用Scrum的語言來溝通。

為了讓剛接軌Scrum的團隊與完全不認識它的朋友，都能迅速理解Scrum的整體架構，這次用了一般人(非程式人員)也可以懂的故事情境，來替大家解釋Scrum的基本流程。

讀完這篇，你會得到什麼?

1.了解Scrum的基本架構
2.了解Scrum一般術語
3.判斷自己有沒有機會用到Scrum模式

什麼是Scrum？要理解其實很簡單

因為Scrum源於工程師的工作模式，即便企業主知道它有多種好處，卻因對普通人而言難以理解，總是不願導入一般部門之中。

為了讓大家更容易上手，這次決定用生活上的情境，來解釋到底什麼是Scrum，以加速每個人理解。

這次，就讓我們從一個旅遊故事開始，揭穿Scrum的面紗吧！

Scrum的第一步：職務分派｜澳洲旅遊的責任分配

故事的起頭是這樣的，保羅(PO)和他的朋友們，打算用１周的時間準備，並去澳洲旅遊２周的時間(Sprint)，於是就和西門(SM)、大衛(DV)等人，從行程景點、要準備的東西開始，進行了非常完整的規劃。

在開始前，他們用初步區分了各自的責任：

由於保羅(PO)對澳洲和旅遊都非常熟悉，就全權交給他來決定這次「去哪些景點」、「準備什麼資料物品」；因此，如果旅遊行程不好玩、出了問題，他就要好好對大家交代了！

而西門(SM)則因為擔任過旅行社的員工，對於旅遊從頭到尾的流程都瞭若指掌，就由他來負責監督，確保大家都有好好準備與溝通；在出遊期間，也會確定是否有按照行程走，以免因此讓旅途不順。

大衛(DV)等人，則是這次的旅遊團員，也都是旅遊愛好者，時常查詢資料、到處遊玩，所以實際資料的準備、玩的方法，就由他們來決定了！

※Scrum 名詞介紹：

1.旅遊期間(Sprint)：一段工作期就像2~4周的旅遊一樣，在Scrum中被稱之為「Sprint－衝刺期」

而工作團隊的分工，就像這次澳洲旅遊的分工一樣，也有著各種角色:

2.保羅(PO)：
扮演的就是團隊的總召，也是「產品負責人 — Product Owner，簡稱PO」

3.西門(SM)：扮演的是流程控管、監督的腳色，在Scrum裡面有個特殊名稱「Scrum大師 — Scrum Master，簡稱SM」

4.大衛(DV)等人：則是實際執行任務的團隊成員，在Scrum中被稱為「Development Team — 開發團隊，簡稱DV or Dev Team」

Scrum規劃會議｜準備到執行的規劃

在分配好角色之後，就要來一次正式的行程討論會了。

為了讓討論順利進行，這次還特地租了間辦公室來使用。

西門(SM)在會議開始的時候，先和大家說明了一些事項：

「這次包含行程準備、遊玩的時間，我們有３周的事情要做，而今天，我們就要討論好所有該做的事情，這樣之後大家就可以依照這樣的安排走了！」

接著保羅(PO)從口袋中，拿出一張這次的景點、準備事項清單，把它們都寫在大大的白板上，並跟大家拍胸普保證，去這些地方玩準沒錯！

有了這些項目後，大衛(DV)等人，就開始在白板上清楚地寫下「為了達到清單上的目標，應該要做的細節」：

就這樣，他們花了大概3~4個小時，將所有該做的事情都列了出來，打算從明天就開始執行。

．

清楚地列出待辦事項有很大的好處，因為每個人可以貢獻的時間，在出發前，每天就是3~4小時，而旅遊期間，扣除突發狀況、體力等因素，能玩的時間大概就是8個小時左右。

為了確保在這３周內，可以完成充足的準備、走完該走的行程，在規劃的時候就把時間、項目、誰要負責都列出來，就能在一開始知道時間夠不夠、有沒有什麼事情忘記做了！

※Scrum 名詞介紹：

1.行程規劃：是一次密集的工作規劃，在Scrum中被稱為「Planning Meeting－規劃會議」

2.準備與景點:每段旅行中(Sprint－衝刺期)，都有要跑的景點與準備的事情，就像每段工作期間有目標、執行任務一樣，這些在Scrum中被稱為「Story－故事」或「Item－物件」；而保羅(PO)從口袋拿出來的這張Story清單，則被稱為「Product Backlog－產品待辦清單」

3.執行細節:
每個故事，都有細部的事情要做，這一個個小事大概都會在一天內被搞定，它們與一般的待辦事項很類似，在Scrum中被稱為「Task－工作」。

在規劃會議中，通常會把「Sprint－衝刺期」裡面所有的「Story－故事」、「Task－工作」都安排好，不但會有基本的任務分配，還會標記出完成每個Task所需要的時間。

Scrum每日立會｜進度說明

好不容易把事情規劃好後，隔天大家就紛紛開始執行所列的項目，而為了讓西門(SM)掌握到所有人準備的狀況，他們安排了每天早上10點的時候，大家要聚在一起，花15分鐘說明三件事：

• 談談昨天做的狀況
• 今天要準備哪些項目
• 如果有任何困難，就在此時向大家說明

例如，大衛(DV)就在某一天的會議上說了：

• 昨天我查好了到雪梨歌劇院的交通方式
• 今天打算看看歌劇院裡面有哪些一定要參觀的項目
• 我發現歌劇院將有兩天閉館，我們必須刻意避開這兩天，如果避不開，要再麻煩保羅(PO)決定該怎麼辦

於是，西門(SM)確定了大衛(DV)有按照進度做事，大家也知道目前歌劇院行程的狀況；保羅(PO)則會開始思考，如果歌劇院閉館，應該如何改變行程才最適當。

之後，每天都維持著類似的短暫會議，讓所有人都知道目前狀況，一直到了旅遊結束。

．

Scrum回顧會議｜旅遊回顧與分享會

澳洲旅遊結束的隔兩天，大家再次相聚，分享了準備期間和旅遊期間有趣的事情，也分享了各個景點的照片，大家感謝彼此的幫忙後，也想了一下，哪些部分沒做好，或是忘記安排到，作為下次旅遊的改善方向。

※Scrum 名詞介紹：

Scrum裡面有三種重要的會議，除了前面提到的行程規劃的「Planning Meeting－規劃會議」，還有以下兩個：

1.進度回報：
在執行期間，每天會在固定時間花15分鐘召開「Daily Standing Meeting－每日立會」，為的是讓大家都知道目前準備、執行的狀況，每當碰到困難、任務不順，都可以在這個時候提出，請夥伴們幫忙解決。

2.回顧分享：
衝刺期結束後，會進行的是「Sprint Retrospective－回顧與檢討會議」，如同慶功宴、旅遊回顧一般，用來回顧這次完成的成果，相互鼓勵，並找出可以改善的地方，讓下次的衝刺更為順利。

---

上面這一連串，如同旅遊的行前規劃、準備與執行、完成後的分享大會，就是Scrum的大致流程。

你可以把Scrum說成一個合作的模式、專案管理的流程，或是另一種說法：

「在一段期間，完成一堆任務的工作方式。」

總而言之，Scrum並沒有想像中那麼難上手，甚至在生活的情境中都能看到類似的做法，只要有一定的概念，想要立刻啟動Scrum模式都沒問題！

---

所以該如何開始Run Scrum？

因為Scrum可以套用到生活、工作的許多情境上，如果企業或團隊有想要嘗試這種做法，建議是直接開始，用基礎的版本讓團隊習慣，對於日後的加速會非常有幫助。

至於到底為什麼要使用Scrum，在之後的文章都會提到，但我認為有3個非常吸引人的點：

1. 從上面的旅遊情境來看，我們在一開始就知道了有哪些事情要準備，連時間、負責人都列上了，也就是在起初規劃時，幾乎就知道最後的結果，這是對掌控團隊進度十分有幫助的方式。
2. 每一段衝刺期，團隊都有機會比上一次衝刺成長2倍的效率，我想這也是最吸引企業主管的一點。而原理與方法，也會在之後的文章中介紹。
3. 它有著讓規劃更完整、事情接棒更順暢、代辦事項更簡潔精準、解決問題速度更快速…等各種幫助團隊運作的好處。

Scrum的開始確實很容易，但要充分享受到它帶來的好處，還需要注意許多細節。

如果你想更深入瞭解它，建議先從Scrum的基本精神、開會方法開始，相信在不久的將來，你或你的團隊將會有巨大的成長！

【Scrum工作術】3個重要的核心精神！

用Scrum最重要的3個核心精神，來檢測你的團隊是否適合使用Scrum工作術。

Kevin Wu

Nov 19, 2017

SCRUM：用一半的時間做兩倍的事

這篇文章想說什麼?

這篇文章，主要想傳達Scrum的重要精神，讓身為主管、團隊領導者的你，可以在導入Scrum前先思考目前的團隊習慣，是否能正確地利用Scrum。文中不會討論太多Scrum的細節，而是專注討論「Scrum精神」這件事。

讀完這篇，你會得到什麼?

1.了解scrum替團隊帶來的價值
2.判斷現有團隊適不適合Run scrum
3.開始調整自己或團隊的工作心態

如果用一句話來說它能替團隊帶來的最大價值，我會說：

「它讓團隊能用相同時間，做到更多的事。」

Scrum是什麼？可以做什麼？

Scrum起初被用在程式開發，適合大約6~9人的團隊，若善用Scrum的合作模式，假設團隊第一個月可以開發2個功能，第二個月就能開發3個，第三個月4個...如此不斷循環，團隊合作、開發能力，將可以逐漸被極大化。

這樣的快速的成長，非常適合新創團隊、新部門、新品開發部門的使用。值得一提的是，它不只能用在程式開發，甚至能讓一般的業務團隊、行政團隊、行銷團隊來做使用，這也是它最大的價值。

事實上，我們公司在起初引入Scrum時，就將它用做一般行政庶務、行銷規劃，許多項目可以說是與完全與程式無關。我自己也把這個流程運用到了人生規劃、平日活動安排。

因此，如果你希望自己或團隊能

1. 在同樣時間，完成更多的事情
2. 有更多良性的溝通、團結一致
3. 每天清楚掌握，並精準地預測1個月內的專案執行狀況

就非常有機會運用到Scrum的流程與精神。

Scrum解決了什麼樣的問題？

在專案、團隊管理，或是任何計畫中，多少都會面臨到以下的問題：

「沒有按照時間進行」、「案子之間彼此卡住」、「管理者無法全面掌握狀況」、「過多的討論會議」、「執行冗長的感覺」、「應變能力不足」。

以上的問題，如果以Scrum的模式來執行，這些問題都能被更好地解決。

邏輯不同，所以可以解決許多團隊問題

一定有人會好奇，憑什麼Scrum的工作模式可以解決那麼多問題？

我認為主要關鍵在於：

「做事的邏輯不同。」

．

舉個專案管理的例子來說吧！

傳統上，我們只運用甘特圖來預測與掌控專案的進度。工具本身並沒有問題，但仍常發現預計5天的工作，因為做了8天導致整個專案延宕，而當預期被打亂，甘特圖最後只能用紀錄工具，而無法發揮預測、掌控專案的功用。

但Scrum模式中，會將每天的工作量化到以小時為單位，會議時間、客戶拜訪時間、一張表格製作的時間，全都在掌控之中。另外，整體的狀況也是使用「Story point」來掌控進度，而非具體的天數與小時。

光是這兩個概念，就能讓原本「預計5天」能完成的小型專案，變成「預計30小時」能完成的專案；讓原本「知道我們現在delay 3天」，變成「知道團隊最後將完成原本預期的70%」。

而因為在評估、規劃、討論、執行的邏輯都不同，才讓能讓諸如「無意義的會議」、「PM不斷督促詢問」、「團隊合作效率不彰」、「成員不懂得獨立思考」...等問題，都將在Scrum邏輯下，得到不一樣的結果。

---

Scrum的重要精神，你的團隊適合Scurm嗎？

因為做事邏輯不同，讓Scrum可以解決許多問題，但要培養不同的邏輯，團隊的想法就得不一樣，要能掌握一些具體的做事精神，在Scrum中，最重要的精神大概有三點：

1. 永遠彈性調整，並優先做最重要的事情
2. 團隊的所有人都要能「隨時掌握情況，幫助彼此解決問題」
3. 要專注在「如何於固定時間內，完成更多的事情」

※備註:

在實際運作SCRUM一陣子，並更深刻了解SCRUM後，才知道完成更多事情並不是SCRUM要求的，但後者的一些解釋分享，仍能提供不錯的想法，因此仍保留此部分。

這三個重點，不但是Scurm的精神指標，還能用來評估一個團隊是否適合Scurm的工作模式，以下就讓我們一一介紹吧！

---

永遠彈性調整，並優先做最重要的事情

這對於管理階層，聽起來是理所當然，因為本來就應該做最重要的事情，但對於工作執行者而言，在實務上往往是十分抗拒的。

例如，當一個案子被要求大幅度修改時，執行者的心中常會想：

「這樣，之前做的不就都白費了嗎？」
「為什麼當初不先講，現在才在那邊改？」

光是有這種想法，在Scurm中都是個大忌，因為理論上，我們過去所做的，都是當時最好的決定，只是因為現在情況變了，才做了不一樣的調整。

如果執行人員無法接受這樣的事實，任憑管理者怎麼推廣Scrum流程，都不太可能讓促成團隊緊密合作，更妄論進步這回事了。

．

另外，團隊的總時間是有限的，不可能在舊Case還沒結束時又開始新Case，管理者如果只想著新Case，卻沒有留時間讓執行人員完成舊的，大家就勢必得加班。

相對於執行者要甘願任務被改變，管理者也有責任判斷哪些是重要的事，並且良好地分配時間，而非認為所有事情都重要，要求執行者馬上改善效率、掏出更多私人的時間加班。

．

也就是說，要想良好地與Scrum接軌

開發團隊要問：
「我可以接受主管隨時調整我的任務內容嗎？」

專案管理人則要問：
「我可以讓我的團隊成員完全不加班嗎？」

答案越是肯定，就越能讓整個團隊符合Scrum的首要精神：

「彈性調整，並持續著做最重要的事情。」

．

隨時掌握情況，幫助彼此解決問題

一個團隊績效是否良好，可以從兩個方面來看。一個是前面說的「能不能持續解決最重要的問題」，另一個則是「能不能更快地解決問題」。

以團隊而言，如果我們能互相合作，即便個人能力不變，依然有辦法讓團隊績效提升。

Scrum精神的第二點，就是希望「以團隊為核心來解決問題」。

既然是以團隊為核心，Scrum中的每個執行人員，都該對所有任務負責，不會有個項目應該由誰來做，或東西做錯應該是誰的問題。

．

舉例來說，如果有個任務是與客戶開會，而A被分配到了這項任務，但當天早上卻頂著不適的身體與會，最後使得簡報狀況糟糕、丟了案子，這不該是他一人的責任，而是所有人都得扛起這個結果。

「為什麼A沒有說身體不適？」
「為什麼即便身體不適，主管卻仍派他來簡報？」
「為什麼沒有人能跳出來幫他完成這項任務？」

這都是Scrum在問責時，以團隊為核心來檢討的方式。

．

問責的反面則是互助。

只要有人在一個重要任務上碰到困難，每個人都該積極想辦法解決，即便放下手邊的工作也在所不惜。因為只要任務對於整個團隊而言是重要的，就該傾力互助完成。

值得一提的是，這樣互助的前提是「問題必須被反映給所有人」，也就是每個人都得誠實地說出自己碰到的困難，不要怕麻煩夥伴、不要怕被認為實力不足、不要怕被責難。

這對於一般的公司這是非常難達到的，因為受到了許多文化的影響，使得我們不願在會議上公開地說：「我做不到、完成不了、我不會、我做錯了」這些話。

．

所以，要想良好的與Scrum接軌，還得先調整團隊的文化：

開發團隊要問：
「我願意誠實地告訴所有人，我現在碰到的困難嗎？」
「有人碰到問題時，我有沒有思考解法，並展開行動幫助他？」

專案管理人則要問：
「我可以不責怪、輕視任何一位成員，而只想著該如何解決問題嗎？」

答案越是肯定，就越能讓整個團隊符合Scrum的第二個精神：

「隨時掌握情況，幫助彼此解決問題」

．

如何於固定時間內，完成更多的事情

一個運作良好的Scrum團隊，個人能力不需要有任何顯著的提升，就能讓團隊的效率成長非常快速。最主要就是源自於前面兩點。

但當這些到達了極限之後，不論是管理層還是執行者，都得更常問一些問題來幫助團隊加速：

1. 有沒有不同的做法，但能更快地完成任務？
2. 能不能少做一些事，但仍能達到相同的目的？
3. 能不能換個流程，讓事情進展更順利？
4. 能不能先完成某些事，讓日後的許多事一勞永逸？

這些問題都是簡單的技巧，但更重要的是，每個人都要有一個想法，就是真心地去想「怎麼讓事情更快被解決」，要真的去思考「原本預計花3天才能完成的報告，應該如何在3小時內完成。」

唯有達到以上的三點，才能讓Scrum團隊一直保持高效高速的狀態

「讓團隊在固定時間內，完成更多的事情

【Scrum規劃會議】(一)先說好目標與Stroy

重新定義Scrum裡的Story，從說一個好目標開始！

Kevin Wu

Apr 15, 2018

為什麼要寫這篇文章?

規劃會議，可說是Scrum中除了精煉會議以外最難的會議，好的規劃會議能讓大家有一致的目標，而且每天都知道自己在做什麼；不好的規劃會議，開完的隔天會沒有人知道事情該怎麼做，於是就開了更多的會議。

規劃會議的好壞，差距就是如此大，所以想透過這一系列關於規劃會議的文章，來說明規劃會議從說明、評分、撰寫Task需要關注的幾個重點。
 
讀完這篇文章後，你可以獲得什麼?

1.知道規劃會議在評分以前，應該要說明什麼
2.知道目標、Story描述，會如何影響團隊的做事方法

規劃會議，是在精煉會議後、每日立會前的Scrum會議。主要是讓所有人知道接下來的衝刺期，將會進行哪些任務。

Scrum規劃會議的開頭，第一步就是說明會議流程，然後就可以開始會議。

以我的經驗，一開始會花10–20分鐘，說明中、長期目標。然後用1–2小時左右的時間，說明以Story為單位的目標、出發視角、做法。

這篇文章，主要介紹的就是「說明目標」、「說明Story」兩大部分。關於評分、撰寫Task等規劃細節，將會在其他文章中介紹。

1.說明衝刺的長、中、短期目標

首先，我們要知道一件事，目標是有分大小、長短的，在每個規劃會議的開頭，都要說明目標是什麼，為了讓所有成員清楚，我們做的這無數個Story，究竟是為了達到什麼樣的目標。

要能先清楚的說明長、中期目標，該做什麼Story才會顯得有意義。

長期目標

例如，每個月商品銷售數量從1萬個變成1.3萬，提高30%，這應該就是一個長期目標，可能需要3次的衝刺期才能達到。

這個目標可以是模糊的，也可以是具體的，例如：成為市場的領導者，或是市佔率超過15%。

為了不是大家要達到這個數字，而是讓大家有一個長遠的眼光與方向感。然後PO可以在一段時間後，回過頭來檢視衝刺的成效。

中期目標

例如，這次衝刺完畢，希望能更精確地掌握3~4個關鍵的商品銷售通路，就是一個稍微中期一點的目標。

以1個Sprint為單位，其實已經算是一個中期目標了，因為Scrum團隊本身就是一個彈性大、反應快的單位，如果中期目標是以一季為單位，就失去了這個合作方式的本質了。

而中期目標，是為了讓大家在每次衝刺期後，能獲得更明確的一些成果。

短期目標

短期目標，也就是每一個Story完成後，可以明顯的預期的事情。

例如，做完這些事情後，希望可以得到10%的曝光增長，這就是比較能預期的事情。

但這個Story的目標，也不能太小，因為Story目標的本質，是為了讓大家在實際做事、規劃時，不要搞錯方向、短視近利。

我認為，Story的目標最好是一個

「幾乎伸手可及，但又稍微達不太到的未來。」

為了是在每天做完事情後，能有一件小到讓人立即有成就感的事情，但又能與長期的目標有所關連，讓大家完成每一個Story後，會有種「我又往這個目標邁了一大步」的感覺。

如果目標是「10%的曝光增長」，做完一個Story可能只有5–8%的增長，但沒關係，至少往目標邁進了一大步。而即便與長期目標的「提高30%銷售量」距離有點遠，但確實曝光越多、造訪網站的數量也會提高。團隊依然會在正確的軌道上。

清楚為什麼，比很多事情都重要

說明這三種目標，為了讓所有的工作者「清楚為什麼要做。」

如果我們只說短期目標，是增加10%曝光，有可能會被認為只是想讓更多人認識產品，而忽略了曝光的品質，以為隨便給一個人看商品都可以。

但如果有一併說明長期目標，是為了在3個月之後，讓這些人來買東西，那我們就會盡量找相關性比較高的客戶。

因為在實際Run Scrum時，在有太多細節管理者無法顧慮到，也不可能監督每個人的執行細節。所以目標最重要的，還是為了給執行者提供方向感，當大家都清楚為什麼要做時，在做事的時候就會有更正確的判斷。

---

2.說明Story的3個組成

一個Story通常會是這樣寫的：

「身為一個」行銷人員，
「我希望」建立一個關鍵字廣告，
「以便」帶來更多商品曝光。

Story由「身為一個」、「我希望」、「以便」這三個關鍵元素組成。而在規劃會議時，應該有1–2小時的時間，都是在說明Story。以下就分別說明這三個關鍵元素的特色。

「身為一個」：出發點、角度

身為一個…代表的就是問題的起源，是一種看待事情的角度，可以幫助我們設身處地的想。

如果是身為客戶，通常都是希望有一個快速方便的好東西，不然就是解決某種難題。

身為一個「客戶」，我希望廣告能給我「足夠的商品資訊」，以便我「快速選擇商品」。

但如果是身為內部員工，雖然方向可能都是要讓消費者看廣告，但會有全然不同的敘述：

身為一個「行銷人員」，我希望建立一個「關鍵字廣告」，以便帶來更多「商品曝光」。

「我希望」：做法、方式、策略

會和出發、抵達目標的相關性十足，身為不同角色、為了獲得不同的結果，你當然會選擇不同的做事方法。（等等會詳細說明）

．

「以便」：抵達目標

就如同前面說的長、中期目標，Story所說的短期目標，是為了幫助每個執行者更好地聯想到中、長期目標，在執行的時候，就不容易迷失方向。

但究竟為什麼，我們規劃會議要花1~2小時的時間，詳細說明這三點呢？

很大的原因就是，這三個描述，只要有稍微一點的變化，就會完全改變團隊的做法。

---

「身為一個」的出發點，如何改變我們的做法

因為你會發現，當視角不同，即便目標、做法類似，但整個Story都還是會改寫。例如：

1.身為一個「行銷人員」，我希望建立一個關鍵字廣告，以便帶來更多商品曝光。

2.身為一個「資深的行銷人員」，我希望替3個新來的行銷人員上課，以便們所設定的廣告品質更好，帶來更多商品曝光。

單純身分的不同，即便同樣希望替商品帶來曝光，因為效率、比較利益的關係，做法也可能會有所不同。

更進一步地，如果用全然不同的視角，甚至會改寫整個Story的做法與目標。

1.身為一個「行銷人員」，我希望建立一個關鍵字廣告，以便帶來更多商品銷售。

2.身為一個「產品用戶」，我希望廣告能給我足夠的商品資訊，以便讓我更快選擇商品。

客人期待的是好的廣告資訊，這樣他就能更快選到喜歡的商品。

但身為行銷人員，你一點都不期待快速選到喜歡的商品，只會希望有更高的曝光，而做法就會只是單純的廣告而已。

而且因為從「行銷人員」到「產品用戶」的視角轉換，就能讓廣告變成提供「更多資訊」而非一班的廣告。目標就不只是單純曝光，而是顧客要能「快速選購」的有意義曝光。

．

「以便」的目標，如何改變我們的做法

同樣的，即便我們的身分、做法一樣，當我們改變目標時，做事情的細節也很可能不同。

如果身為一個行銷人員，以曝光為目的，那麼在相同成本下，我會廣發我的廣告，甚至努力找到那些連聽都沒聽過我們的客人。

同樣身為一個行銷人員，但是以銷售為目的，我就更能利用更多的再行銷廣告、更精準地提供廣告給我的客戶。

．

身分+目標→做法

但無論如何，千千萬萬要記住一件事情，我們應該都是由觀察視角或目標，來決定我們的做法才對。

很多團隊都會先以做法為出發點（因為比較直覺好想），再來才說明為什麼想要這樣做。但就像上面關鍵字廣告的做法，就可以有曝光、銷售兩種目的了，幾乎每一個做法，都可以演身成數十種目標。

但我們更該說明與重視的，不是廣告可以怎麼幫我們達到目標，而是說明：

「為什麼要達到這個目標，廣告是最理想的做法。」

由於Scrum是由國外翻譯來的，很多地方其實念起來不太順，我建議大家Story可以換個寫法，會更適合大家凝聚目標、確定行動。

出發視角：「身為一個」行銷人員，
抵達目標：「我希望」商品有更多曝光，
具體行動：「所以我要」建立一個關鍵字廣告。

身分與目標，其實是行動的一個觸發點，重點是要「經過一段思考之後」，才會能有正確反應，才會有「所以我要做…」的具體行動。

建議大家，在所有的具體行動確定前，都要再回頭想一個問題：

「有沒有更好做法，但可以達到一樣的目標？」

---

講述Story做法，如果只有單純的「建立一個關鍵字廣告」其實遠遠不夠，這樣隨便建立一個廣告也都可以交差。

但團隊成員能不能聽完Story後，就知道怎麼評分、Task要怎麼寫，幾乎都是依賴良好Criteria。說白一點，就算完全不給目標、不給視角，只寫一個很完整的Criteria，團隊其實也可以執行工作。

【Scrum規劃會議】(二)說好Stroy的KPI與Criteria

Scrum規劃會議前，先釐清每個Story的KPI與Criteria吧！





Kevin Wu

May 9, 2018








為什麼要寫這篇文章?
規劃會議，可說是Scrum裡面除了精煉會議以外最難的會議，其中Criteria和KPI的制定，又時常搞得大家一頭霧水，這次想要分享的是我對於Criteria的細節的一些看法。
讀完之後你可以多瞭解什麼?
1.Criteria怎麼定會更好
2.KPI與Criteria的差別
3.管理者與執行者之間的模糊地帶

關於Story的基本

前一回談到，規劃會議要說明長、中、短期目標，也說了Stroy是由角度、目標、做法三個重要元素組成。而且短短一句Story描述，還隱藏了不少的意涵：

身為一個…：正以某角度來思考事情
我希望…：為了某個目標
所以我要…：打算做一個目前覺得最好的做法

但其實真正要執行時，單單的一句Story其實還不夠用，所以規劃會議還要注意的是Story一些幾本與Criteria細節。


Story的基本標準

在Scrum的基本介紹中，有六項檢核標準，可以幫我們測試看看是不是一個好Story，也只有好的Story，進入到後面的投票、執行才有意義。

1.獨立：不能和其他故事同時完成、不能因為其他故事而影響執行的時間。

換句話說，每一個Story如果不管重要性、時間限制性，應該都要可以立刻進行。它不能受到當期衝刺的其它的Story影響。

例如，如果我要進行的是一個裝潢房子的任務，但如果有另外一個Story是要看房並與房東簽約，這兩個任務就不該同時出現。

因為裝潢房子前，一定要先看房簽約，但如果看房時發現房子有問題，就完全無法進行裝潢，這樣第二個Story可說是在第一個沒有如預期完成以前，完全沒有在這次Sprint中存在的意義，因為很可能會進行許多變動。

2.可修改：在實際結束前，能保持彈性，可以修改標準、調整task、story目標與分數。

Sprint的本質，不單單是為了專注、可預期、提高效率而已，還有一個要點是保持彈性，所以我們可以在執行期間，加入、移出、修改任何經過PO同意的Story。

3.有價值：要能夠為目標對象傳遞價值

意思就是要站在某個人的角度想，並且能傳遞出一種願景。

4.可估算：可估算時間、成本、人力等資源。

5.規模小：為了讓故事可以列出task，他應該要讓人看到，就知道該如何列出task。

6.可測試：故事在結束時，必須通過檢驗。

．1~3的標準，相信大家還可以輕易理解，但可估算、規模小、可測試，其實比想像中更複雜，也就是這篇最主要想解釋的事情。







KPI v.s 可測試的Criteria

Story的撰寫，其實是一個管理上的問題，所以我想先聊聊我對於管理者、PO的一些看法。

管理者、PO的責任到底是什麼？

我認為，管理者與執行者最大的差別，就在「換句話說」的能力差距而已。

更高職位的人，有能力把更大的目標換句話說成小的目標，低階職位的人只能把一些較小的目標說好。

舉個例子吧！假設我們公司的目標是「成為產業龍頭」，我相信隨便問一個小職員，一定不知道現在要做什麼。但能成為管理者、CEO的人，就是能跟大家說：

1.我們要先把營業額做到100萬
2.然後把顧客滿意度提高到30%
3.接著布置15種的通路管道

這樣，我們就能成為產業龍頭。

但CEO說的，還是讓小員工一頭霧水，怎麼樣才能把營業額從現在的50萬變100萬呢？這時，可能就需要一個位階居中的業務主管來幫忙換句話說：

1.每個月比現在多跑100個客戶
2.調整定價公式，並調價所有產品

我們就能把營業額做到100萬。

這時候小職員就聽懂了，他現在每個月跑200個業務，要再多跑100個業務的話，他的行程和跑業務的方式就要調整。

所以職位的高低、是管理者還是執行者，最大的差別就是「換句話說」的能力高低，越厲害的人、位階越高的人，越有能力把大事變小事，把小事再變成下一秒可以開始做的事。

而對於Scrum的PO，或是任何管理人員而言，最重要的責任，就是把一個看起來比較難實現的目標，「換句話說」成讓人可以理解、執行的任務。

Story裡的換句話說

一般而言，Story會包含下面三個要素：

身為一個…：正以某角度來思考事情
我希望…：為了某個目標
所以我要…：打算做一個目前覺得最好的做法

以換句話說的角度來說，其實一個Story，就把長期目標換一句話，說成Story目標(我希望…)；並把Story目標換句話，說成更小的做法(所以我要…)。

PO的責任，其實就是要能換句話說現在的目標，直到讓小職員能夠聽得懂、能執行的地步。

另外，PO可能還會額外思考一件事情，我換句話說完之後，我的Scrum團隊真的知道Story中的「所以我要…」，要怎麼做才符合標準嗎？

這其實全部都暗藏這次的主題裡：Story的Criteria








Criteria的用途

每一個Story，應該都要有一個完成的標準-Criteria，它的用意是說明：

這個Story要「做哪些事」，才可以算完成。
而且這些事情，應該要是「幾乎可以完全預期的。

先說說什麼叫作「完成」

如果我們的Story是這樣寫的
Story:
身為一個行銷人員，我希望帶來更多商品曝光，所以我要建立一個關鍵字廣告。
Criteria:
1.如果我的Criteria設定到
2.建立一個廣告活動，只要跟商品相關即可
3.預算3萬
4.無須投放

當團隊最把這個Story評為5分，那什麼時候才可以拿到這個分數呢？

就是當Criteria全都被滿足的時候，也就是Story中的「可測試」原則。

因為有了Criteria，一方面可以更清楚應該要做哪些事，寫task的時候可以更容易。另一方面也是告訴我們，當通過檢驗後，就可以不用再浪費時間做相關的事情，而省下時間，也就等於加速了整個Scrum的運行

．

另外，前面有提到說，PO會擔心執行人員不知道怎麼做才符合標準。

以剛剛的廣告例子來說，大可以直接拿以前做過的，然後改好預算就好了

但如果Criteria改成
1.建立一個廣告
2.包含新的3組關鍵字
3.每組可預期帶來1000的曝光
4.預算3萬、投放7天。

如果是這樣，就還需要再額外做許多事情，也就是說，Criteria，其實就包含了PO對於這個Story完成後的所有想像。

這些更細緻的說明，其實也是對於「做法的換句話說」，它不但需要管理者的能力，也會被用來評估執行是否完成的標準。

Criteria與KPI的差別

前面有提到，「把目標的換句話說」，就是一個主管的責任，而KPI其實就是對於「目標的換句話說」，往往需要十分具體的數字，為的就是幫助我們衡量距離目標還有多遠。

Criteria則一種對於「做法的換句話說」，這些說詞不必是具體數字，但要能精準的預期完成。

你可以把Criteria想成，只要我做了1.2.3.4…件事情，我可以達到這個Story的KPI。

大家容易搞混Criteria和KPI的差別，其實就是對於「做法的換句話說」和「目標的換句話說」不理解，而兩者之間存在主要差異就是：

是否可以預期。

舉例來說，如果前面廣告的Criteria設定為：獲得1000次曝光

其實就這就代表著，沒有達到1000人看以前，這個Story永遠不會完成。

令員工困惑、加班的原因，往往都是主管只說「我希望有1000人來看我們的產品」，但這幾乎不是員工可以控制的。

員工們可以下廣告、可以上街推銷，但如果人家就是不看，那我怎麼樣也做不完。就變成說這個Criteria不是我能預估的。既然前面有提到，Story要「可預期」，那當有了這個Criteria，Story就有問題了

反過來說，當一個Criteria如果不可預期，它就是一個對於目標的換句話說，它應該存在的不是Story的Criteria中，而是接在Story本身的「我希望...」後面。

．

但有一點十分有趣，如果同樣的「獲得1000次曝光」是由一個廣告投放高手來做，他有能力每次預期廣告會有多少人看，只要給他足夠的時間與金錢，他就可以很精準地說，在3天後，將會有1000點擊廣告。

此時，這件事情又變成可以預估的了！

．

目前為止，你可能會發現一件事情，Criteria的制定者，其實應該是實際執行人才對，因為只有執行的人，有權利說，這件事情我有辦法預估。

PO雖然有責任把長遠的目標，換句話說成短期的Story目標，甚至精細到做法的初步說明，但對於做法的細節要達到怎樣的程度才算完成Story，一定得跟執行的人討論才行。

否則當Story無法預估，基本上都是白搭。








規劃會議與精煉的界線

規劃會議，除了目標，說明Criteria也是一大工程，大部分的時間應該也是在講Criteria，就如同前面看到的，就算Criteria只增加一個項目，需要做的事情也可能會暴增。

我們團隊在執行時，也很常發現規劃會議時難以確定Story，往往是因為邏輯策略、換句話說的方式、可預期、可檢測上出了問題。

但這些，本都應該在規劃會議之前的精鍊會議完成，規劃會議當天應該著重在重複說明與確認，並且進行接下來的評分、撰寫Task。

．

另外，PO最苦惱也最常思考的，就是怎樣的Story才能讓執行者朝著正確的方向走、才不會做錯。也因此花了大量的時間撰寫Story。

但其實，Criteria到底要定義到多細節，取決於管理者平日的溝通，以及對於執行人員的信任感。溝通力與信任感越強，就越能省去需多執行與目標細節的定義。

我自己認為，不要過於拘泥這些執行的小瑕疵，只要做的方向是正確，這些問題很容易在1~2次Sprint就被修正完成。

與其執著於完美的Story，不如讓Story可以被執行。畢竟，在Scrum之中最重要的不是完美，而是持續的進步。








花了這麼大的篇幅講規劃會議，就是因為Story實在太重要了，他就像是所有人的指南針一樣，為了讓在執行人員能時常確認自己的方向，也讓管理者釐清策略。

反過來說，如果能持續與團隊一同精進Story的撰寫，相信成長的速度將會出乎預料。

之後將介紹的是關於評分、撰寫Task的一些細節。

另外，我自己覺得Story的撰寫與說明，就如同管理一樣是一門藝術，有千百萬種方式與見解，也很歡迎大家留言與我交流！