S.M.A.R.T.

想來大家多半對第一天上班的印象都很深刻，我也不例外。除了記得當天重感冒到一把鼻涕一把眼淚之外，就是快下班的時候，我的上司把我找到一個小會議室，跟我解釋什麼是 S.M.A.R.T.。這個記憶就這樣跟了我二十幾年。

如果你問任何一位 M 社的 PM/Dev/Test，在公司的任務是什麼，“做產品” 多半是你會聽到的答案。這時也許您心裡會想，“做產品” 也太模糊了吧， 不應該是更明確的事情嗎？ 這代表你的問題要稍微調整一下，應該問 “你手邊的交付 Deliverables 是什麼？“。”做產品“ 是團隊的整體目標，可是針對特定的時間以及特定的產品，就要透過每一個人彼此的協作，以及 ”交付“的結果，才能完成。

M 社是一家工程公司，很自然的會要求事事都要具體化，對於關鍵成敗的 “交付” 更是如此。雖然許多的 deliverables 可以用 KPI 或是定量化的方式來定義，可是有更多的部分：例如團隊的溝通協調、計畫的訂定、活動的進行等等，只能以定性的方式描述。這裡就必須用大家都同意的角度和層面加以規範，不然就會流於各說各話的結果，找不到人負責。S.M.A.R.T. 就是大家普遍同意的交付規範方式：

S - specific 要具體 - “提高員工滿意度” 顯然要比 “我要對員工好一點” 要具體一些。

M - Measurable 可測度 - 這裡通常引用的是數字，例如 “百分之三十的 fix rate"。不過有時也有定性式的描述，如“OCF 所定義的里程碑 exit criteria"。

A - Achievable 可達成 - 這個層面就會牽涉到每個人不同的能力等級，所以是設定 deliverables 的雙方（通常是上下級）必須共同同意的。舉例而言，要求一位初級的 developer 完成整體的架構設計就不合理。

R - Result-oriented 以結果論 - 如果只注重完成特定的活動，而沒有實質的效果，也不能稱為有效的交付。常見的問題像：在一季之內完成三場使用者訪談並不能算有結果，必須涵蓋後續的功能改進計畫並且實際執行，才符合結果論的要求。

T - Time bound 有時間限制 - 沒有期限等於沒有交付。但是話說回來，也不是每個 deliverable 都要畫押一個死死的日期。比較實際的做法是先訂一個 checkpoint 日期，之後又必要時可以調整時間。

說到底，S.M.A.R.T. 的精神就是 “講清楚，說明白”，這樣才能盡量減少溝通不良所產生的摩擦。另外，領導者的實踐而以身作則，對團隊中觀念的養成，有著關鍵性的影響。M 社中實事求事的文化，就是這樣一點一滴累積起來的。