從敏捷看目標管理的SMART原則
今天我們要來談談目標管理(Management by Objective，MBO)，目標管理是管理學之父彼得杜拉克所提出的管理理論，其中有一個SMART原則值得我們拿來好好聊聊。但是大家先不要翻白眼，請放心，傑瑞今天保證不嘴砲，SMART原則其實也可以套用敏捷的思維來應用。
內外夾弓大立腕
因為武漢肺炎的關係，2020年第一季最朗朗上口的應該就是洗手口訣了，其洗腦程度已經取代傑瑞小時候印象最深刻的兩大口訣：「沖脫泡蓋送」以及「吹含吸舔摳」(不得不佩服星爺)。好吧，扯遠了，簡單來說，做專案不外乎三件事，為何做(WHY)、如何做(HOW)以及做什麼(WHAT)，而這也剛好跟SMART原則不謀而合。
如果把這三件事想像成一個同心圓，
為何做(WHY)屬於最內層，它是專案的根本，在這裡要思考兩件事情(對應到SMART原則的S、M):
- 你的專案目標是否夠具體(Specific)→你是在解決用戶什麼問題?你希望用戶行為怎麼改善?
- 你的專案績效是否能衡量(Measurable)→你如何判斷專案有成功?你怎麼知道用戶行為有改善?
如何做(HOW)屬於中間層，它是專案的結構，在這裡要另外思考兩件事情(對應到SMART原則的A、R):
- 你的專案計畫是否能執行(Actionable)→你要如何將目標轉成行動方案?你如何確保完成所有交付物就能達成目標?
- 你的專案成果是否有連動(Relevant)→你的專案有跟單位策略呼應嗎?你如何讓自己的工作讓老闆看見?
做什麼(WHAT)屬於最外層，它是專案的排程，在這裡要思考最後一件事情(對應到SMART原則的T):
- 你的專案排序是否有以終為始(Time-based)→你規劃的內容是否有輕重緩急?你排序後的內容是否有跟主管達成共識?
由內而外再循環
所以下次當你要應用SMART原則在敏捷專案時，千萬要記得上面這個口訣。由內而外表示:規劃專案應該先由同心圓的最內層開始思考再逐步延伸到最外層(從S_專案目標到T_專案排程)，再循環表示:完成專案排程規劃後，如果初步檢視有發現執行上的困難，就應該回到源頭去檢視一開始的設定是否合理(從T_專案排程回到S_專案目標)。如果拿道路交通來比喻，SMART原則不應該是條單向道，它應該是個圓環，可以幫助我們不斷來回檢視專案的關聯性與合理性。
簡單來說，SMART原則的循環機制在於三個關鍵:S_專案目標、A_專案計畫、T_專案排程。先有S_專案目標才能產生A_專案計畫，有了A_專案計畫才能執行T_專案排程，但是T_專案排程如果不合理就要調整S_專案目標，然後再次調整A_專案計畫，再次執行T_專案排程，直到覺得T_專案排程合理為止。
至於這樣的循環機制在實務上要怎麼操作呢?
首先是S_專案目標:
每次在專案開始之前，與其寫下這次是要解決用戶的什麼問題?不如進一步思考，你希望能幫助用戶達成什麼事情?或發生什麼行為上的改變?將你希望看到的行為逐條寫下來，用戶可能是終端客戶、業務同仁或部門組織，端看你的專案而定。
接著是A_專案計畫:
你的目標應該要能夠透過行動方案來達成，一個成熟的PM應該能將一個大目標拆成幾個不同小目標，而每個小目標都有具體的交付物來支撐，這個拆解目標的過程也就是俗稱的工作分解結構表(WBS，work breakdown structure)，所以我們就是利用工作拆解將目標轉化成一個一個行動方案，然後透過交付來達成我們的目標。所以現在回過頭來將你的目標換成用戶行為，大目標對應到用戶的主要行為，小目標則對應到用戶在該行為下的不同任務，例如:假設我們想要改善傳統進線客服的用戶體驗，我們希望用戶未來能在3C裝置上快速得到答案並解決問題(這是大目標)，而底下的任務可以再拆成信用卡相關業務、帳務交易相關業務等等(這是中目標)，而信用卡相關業務可以再細拆完成線上繳費、完成線上辦卡、完成線上掛失等子任務(這是小目標)，最後團隊再來思考每個子任務對應的具體產出為何。
最後是T_專案排程:
排程當然會有時間限制，但有時間限制不是要逼PM跟團隊加班做完全部的工作，應該反過來，在有限時間壓力下(以終為始)，PM是否能排序A_專案計畫的輕重緩急，PM是否能將工作分解結構表(WBS)的內容至少排序出三種順序，MUST HAVE(一定要有的，如果沒有交付就不算達標)、SHOULD HAVE(應該要有的，如果有交付則可加分)、COULD HAVE(可以有的，交不交付都不影響達標)，如果連排序後的MUST HAVE你都判斷很難在時間限制內完成(EX:投入100%時間也做不完MUST HAVE)，那PM應該回到一開始的S_專案目標，檢視目標一開始是否設定太大，是否想要幫客戶解決(改變)的問題(行為)太多。這也是傑瑞所說為何SMART原則在敏捷思維下應該是個循環，那你可能會問何時才會停止循環呢?這邊建議八二法則，至少在投入80%的時間下有信心完成MUST HAVE，因為實際在做的時候，你永遠不會知道可能發生什麼事delay專案，如果事情都很順利，你可能會有20%以上的時間來做加分項，但如果真的不幸遇到大魔王卡關，你至少還有20%的時間緩衝來交付MUST HAVE。
所以大家以後在規劃專案時記得別忘了先唸一遍口訣喔(由內而外再循環)，這樣你才能事半功倍，而且專案成功率才會提高喔。
敏捷數位小教室二部曲就說到這，對於首部曲有興趣的夥伴可以參考以下連結(有效的Daily scrum，你也可以這樣做)~我們下個月見!!
如果喜歡傑瑞的文章，歡迎追蹤(follow)傑瑞並分享(share)給你的朋友。
👉喜歡這種類型或主題的文章，也別忘了拍手給傑瑞鼓勵唷
