我在成為內訓師的初期，因為培訓之前經常要寫培訓目標，也就是學員在本次培訓中的主要學習目標。一開始經常會看到如下的編寫形式：
- 了解面向對象設計SOLID原則
- 掌握大部分代碼壞味道
- 掌握TDD的姿勢
這類目標的編寫方式看起來好像沒毛病，每個人也都能讀懂，并且好像能夠明白其中的含義。仔細琢磨一下，這其實不是最好的方式，原因如下：
- 受眾不明確。參加的學員是什么樣的學員？是資深開發人員，還是初級開發人員，是QA還是還是DEV，因為一場培訓中有可能存在不同背景的學員。
- 驗收不明確。不知道如何驗收學員有沒有了解或掌握。學員有哪些行為表現表明目標達到了。
- 條件不明確。學員是剛培訓完就能掌握TDD的用法，還是學完后經過兩周的實踐。或者學員在用Java編程語言，還是其他任何編程語言。
- 范圍/程度不明確。是所有學員都要做到，還是只要保證80%的學員達到目標即可。另外TDD的姿勢能做到80%的標準，還是嚴格100%
基于這四個點，業界同仁總結出了學習目標的ABCD寫法：
- A（Audience）聽眾，目標聽眾是誰，一場培訓通常有不同背景的學員，不同背景的學員參加完同一場培訓之后所能夠達到的目標也是有所差異的，這點是培訓面臨的一個挑戰之一。
- B（Behavior）行為，培訓后表現出什么樣的行為。能夠講出來，能否做出來，都是可以觀察到的。
- C（Condition）條件，在什么條件下，比如，特定的技術棧、多長的期限內。
- D（Degree）程度，完成的效果如何，能達到多大、多高的比例，比如是所有人還是部分人，是嚴格按照標準還是標準的部分。
采用，ABCD模式改變一下上述的模式：
- 所有學員，在培訓結束后，能夠用自己的話闡述SOLID原則。
- 90%開發人員，能夠在培訓后完成結業作業，識別出《重構》書中所列的10種代碼壞味道。
- 所有學員，能夠在培訓結束后，在開始Story是做Tasking，并可視化記錄下來。
- 所有開發人員，能夠在1個月后，Java技術棧下，采用標準的TDD四步法來完成Story。
寫法比之前具體明確了很多，有了不同的目標區分，就會驅使你對培訓的設計做出一些調整，一開始確保了目標的準備，設計培訓的時候不至于走的太偏。這有點像做TDD的時候，很少會多出一些無用的接口。一開始思考清楚了培訓目標，也會讓你的培訓更有針對性，更適合學員。花時間去思考是一項值得做的事情。
采用ABCD的模式能夠幫助你更深入的思考目標，因地制宜。另外，衡量一個學習目標好壞的標準 -- 目標達成是否容易評估，要做好這一點，背后有一個參考原則，見下一篇分享。
