2019年5月31日 星期五

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年5月28日 星期二

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



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

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




為什麼要寫這篇文章?
前陣子,為了替非程式部門的企業夥伴上Scrum的課,又重新整理了Scrum的概念,並轉化成普通人也可以想像的情境,發現這樣效果非常好,花短短2個小時的時間,就能讓每個人使用它來工作,並用Scrum的語言來溝通。
為了讓剛接軌Scrum的團隊與完全不認識它的朋友,都能迅速理解Scrum的整體架構,這次用了一般人(非程式人員)也可以懂的故事情境,來替大家解釋Scrum的基本流程。
讀完這篇,你會得到什麼?
1.了解Scrum的基本架構
2.了解Scrum一般術語
3.判斷自己有沒有機會用到Scrum模式

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

因為Scrum源於工程師的工作模式,即便企業主知道它有多種好處,卻因對普通人而言難以理解,總是不願導入一般部門之中。
為了讓大家更容易上手,這次決定用生活上的情境,來解釋到底什麼是Scrum,以加速每個人理解。
這次,就讓我們從一個旅遊故事開始,揭穿Scrum的面紗吧!

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

故事的起頭是這樣的,保羅(PO)和他的朋友們,打算用1周的時間準備,並去澳洲旅遊2周的時間(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)在會議開始的時候,先和大家說明了一些事項:
這次包含行程準備、遊玩的時間,我們有3周的事情要做,而今天,我們就要討論好所有該做的事情,這樣之後大家就可以依照這樣的安排走了!
接著保羅(PO)從口袋中,拿出一張這次的景點、準備事項清單,把它們都寫在大大的白板上,並跟大家拍胸普保證,去這些地方玩準沒錯!



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



就這樣,他們花了大概3~4個小時,將所有該做的事情都列了出來,打算從明天就開始執行。
清楚地列出待辦事項有很大的好處,因為每個人可以貢獻的時間,在出發前,每天就是3~4小時,而旅遊期間,扣除突發狀況、體力等因素,能玩的時間大概就是8個小時左右。
為了確保在這3周內,可以完成充足的準備、走完該走的行程,在規劃的時候就把時間、項目、誰要負責都列出來,就能在一開始知道時間夠不夠、有沒有什麼事情忘記做了!
※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工作術。


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,從說一個好目標開始!

為什麼要寫這篇文章?
規劃會議,可說是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吧!

為什麼要寫這篇文章?
規劃會議,可說是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的撰寫與說明,就如同管理一樣是一門藝術,有千百萬種方式與見解,也很歡迎大家留言與我交流!