終於到了最後也最重要的主題—可執行目標。為什麼這是最重要的主題呢？因為在所有的主題中，只有可執行目標具有『改變現狀』的能力。所謂『千里之行，始於足下』，講了一堆美夢卻沒有著手進行，再美都是假的。但如果憑著傻勁照著 Nike 講的— Just Do It 會是怎樣的情況？

    BD: ㄟ客戶說他們希望有 XXX 功能
    你: 好我馬上處理. Just do it!
    PM: 老闆說他覺得 YYY 功能有賺頭，我們來開發吧
    你: 喔喔喔發大財. Just do it!
    工程師同事 A: 我覺得那邊的做法可以改成 ZZZ 這樣對效能比較好
    你: 喔喔喔你說得對. Just do it!
    你: （越想越不對勁）我手上好像還有很多事情沒有做ㄟ

是的，這種情況下不是很快被各種要求淹沒、就是待辦事項堆積如山但卻不知從何下手。於是會開始想要更有效率的解決這些要求。這也是為什麼可執行目標被放在最後的原因，可執行目標需要建構在前述所有面向的基礎下，才能產生有效的改變。

可執行事項

英文叫做 actionable items，中文有的叫做可執行行動或可執行事項，也可以叫做『可執行目標』。舉例來說，肚子餓了於是產生一個可執行目標就是填飽肚子，而實質行動是走去廚房泡泡麵吃。那為什麼強調『可執行性』呢？因為『可以執行』的目標才有比較高的機率被執行。反過來看假設我們設定了一個減重十公斤的目標，你覺得這個方案被執行的機率有多高？減重十公斤雖然很明確，但是我想不到採取什麼行動（抽脂也不行抽那麼多吧？）可以一次就達成這個標的，當目標較為複雜時需要額外花心力拆解目標而非把心力放在執行本身，自然不容易開始。事實上，SMART 原則就是在講這件事：

具體（Specific）：所謂的具體可以是量化的比如打電話給二十個人，也可以是一個具體的功能（當然，你需要先有個具體的功能行為定義），這裡的具體指的是實際的執行細節。


     模糊：提升客戶好感度（範圍太大，不知道從哪開始）
     具體：排班確保每天都有人處理客服信件以縮短客服反應時間

     模糊的：客戶可以透過系統寄送信件
     具體的：客戶登入後在選單選擇寄送信件後填入收件者、標題及內文後按下寄送，在收件者信箱即會收到含有標題及內文的信件

     模糊的：建構一個推薦系統（當團隊內沒人知道怎麼做的時候）
     具體的：研究推薦系統的架構

可以衡量（Measurable）：為了解執行成果，必須要找出可以衡量的數值，用以驗證目標達成的程度。如果一個目標的成果是無法衡量的，那麼至少要能產出『下一個目標』才行。
```
 透過排班客服反應時間縮短了 20%

 功能上線後第一個月有 5% 的使用者使用了此功能

 研究後獲得一些主流架構的基礎知識，下一個目標則是『技術評估該使用哪一種架構』
```
可達成（Attainable）：可以在一次執行內合理到達的，比如說今天想寫完這篇文章。反之不合理的目標則是：今天想寫出萬言文（我知道有人可以，但對非專業寫手來說這難如登天）。
有益（Rewarding）：除了可衡量之外，還必須確認成果是否往更高階的目標前進。因為如果只看眼前的可執行目標可能會喪失方向感，有時候需要再往上一層確認大目標是什麼，才有辦法確定此次的成果是否有效。舉例來說有一個可執行目標是透過調整文案衝高廣告點擊率，成果也的確提高點擊率，但更高階的目標則是獲得更多的客戶／收益，此時就要檢視提高的點擊率是否如實造成收益的增加。
時效性（Time-based）：沒有截止期限的目標如同不具體的目標，因為我們不知道什麼時候會達成。

最小可行產品 MVP

最小可行產品 MVP 的概念可以幫助我們更快速的完成任務並驗證成果。所謂的 MVP 雖然稱為最小可行產品，但其概念可以套用在可執行任務上：基於系統現況及預定的目標，建立核心需要的元件，並且驗證成果。不用太鑽研細節，隨時回到具體的目標並檢視哪些是核心項目並專注其上，這樣才能確保在最短時間內有效產出。MVP 不但可以幫助團隊更快驗證成果並改善，熟悉後因產出的效率提升，也有助於累積團隊的成就感與士氣。[註1]

專注

將目標拆分到前述的可執行狀態，就能保有一定的專注度。若執行事項的定義明確，造成分心的事物就會減少，有助於我們專注在眼前的任務。剩下的變因？就是控制自己的雜念，比如說想看手機訊息之類的雜事，關於這方面可以透過理解習慣的原理，戒斷查看訊息習慣透過理解習慣的原理，戒斷查看訊息習慣，或是建立良好的工作習慣。突發事件則是專注的另一個大敵，團隊內透過指定負責人，建立一個事件緩衝區，可以減少他人打斷的機率。若不幸沒有其他人可以幫忙、或是你身為負責人，那麼確實的遵守 SMART 原則也會有幫助，任務的轉換會比較輕鬆。

驗證與改善

事情不一定會照我們希望的進行，因此在執行前就應該先決定驗證的數據指標，執行後就能回頭驗證執行成果。如果成果不如預期，就進一步找出可以改善的地方，產生下一個目標。這也代表，團隊必須準備工具紀錄驗證的數據指標。以及相對應的驗證過程。

給產品團隊的啟示

開發團隊常遇到一個問題：開發功能時到底要做到什麼程度才算完成。這點可以透過實踐『具體』這個原則進行：開發功能前，應該先定義具體的功能行為，並且以完成該功能為基準來進行。說穿了就是先定義功能規格，如果你是工程師的話可以用 BDD / ATDD 的方法確保開發的功能符合規格上的行為。此方法也讓我們先專注在功能規格上，待完成後再來考慮其他的細節。

在執行的過程中一定會遇到很多狀況，定期的反饋是必要的，才能有效蒐集問題進而解決。跑 SCRUM 的團隊會在 Daily Standup 以及 Retrospective 提出，非 SCRUM 團隊也應該在類似檢討會的時間提出。問題蒐集之後與一般流程相同，找到解法，設定可執行目標下去執行。只要這條反饋的道路是通暢的，加上良好的團隊文化，團隊自然會隨著一個個可執行目標改善並成長。

執行 → 反饋 → 找出改善方法 → 執行

摘要

- 可執行目標應該遵從 SMART 原則，包含了： 具體、可衡量、可達成、有益、時效性五個特性
- 可執行目標也有助於執行時的專注度
- 執行前應該先決定驗證的數據，執行後回頭驗證執行的成果並找出改善方法
- 建立執行 → 反饋 → 找出改善方法 → 執行這樣的迴圈，團隊自然持續的成長

理解現況、目標設定與可執行目標三者的關係

這三篇講的理解現況、目標設定、到可執行目標三者的關係是會隨著系統複雜度演進的。當我們什麼都不懂的時候，我們只需要理解現況，此時先做再說就是我們理解現況最快的方式。當對於現況初步理解時會產生一些改善方式，進而產生可執行任務。久而久之對於領域現況理解的越加深入，目標越加遠大的時候，就無法直接產生可執行任務，此時就需要透過規劃目標來輔助。
初階
理解現況：搞清楚水有多深

中階
理解現況 → 可執行目標： 搞清楚水有多深，然後往前跨

高階
理解現況 → 目標設定 → 一個個可執行目標: 水真的很深，規劃渡河的路徑，然後沿著路徑走

理解自身狀況可以幫助選擇合適的處理流程，避免落入以下情境：當踏入一個全新領域時，只想做目標設定到頭來光是花在理解狀況上的間就足夠做出一個 MVP，又或者明明系統已經很穩定，增加新功能時卻不顧系統本身的目標，盲目亂加，造成目標上的混亂。

對團隊來說，最好的狀態為這三者相輔相成，並且知道什麼時候該做什麼。再加上以人為本、溝通與誠信、開放與學習所打下的文化基礎，這樣的團隊能進入一個正向循環，且持續自我改善狀態，這也是目前我們正在極力打造的團隊。如果您認同此系列文的理念，想跟我們一同打造出更好的產品，那就來看看有沒有適合你的位置吧！

https://www.yourator.co/companies/yourator