1.前言

本文的主旨是列內部培訓的提綱，特別對培訓他人和寫作技巧寫得細一些，讓大家明白很多東西可以培訓和怎麼傳播知識。
雖然題為培訓，但我還是想說一句：程式設計師其實不需要培訓，只需要指點。原因有三：

1. 程式設計師的工作都必須去實踐，幾乎沒有純理論的領域。
2. 由於網際網路的開放性，程式設計師能找到大量的資源自學。
3. 隨著實踐深入，會自然地遇到一些問題。解決這些問題除了靠智力外，大部分只需要知道答案的大致方位就能用時間來消滅掉。

大牛之所以能成為大牛，就是知道了很多答案存在的地方以及發現這些地方的方法。優秀的程式設計師培訓師懂得教方法而不僅是教答案。可惜很多培訓師不是這樣的，公司內部的培訓流於形式，大家聽完後就知道這是個很牛b的技術，卻不知道怎麼令自己也牛b起來。
HR就算懂上面的道理，他們因為知識領域的差異也從根本上沒能力推動發展程式設計師的內部培訓。HR能做的事是幫助管理者在程式設計師心中培養技術為尊的意識，讓他們有動力去自學並實踐，並以公司內某位榜樣為目標趕超他

。
HR難以發起大活動，也令大多數公司很少重視培訓（培訓 != 交流，請留意第3節）。因為即使不培訓也不會影響賺錢，工作效率的低下可以用加班來彌補。而且專案做到一定程度就會更新換代、推倒重來，原本寫得多爛的程式碼都成過眼雲煙。還有就是老員工們都有自己的習慣，較難通過培訓來改變，基本都需要有人經常提醒。
在實際中有時候還是需要培訓的，這其中多數是因為負責人懶得寫文件，或者文件很容易過時而懶得更新，不如口頭說一遍算了，╮(╯▽╰)╭。

2.業務技術培訓

按內容區分，培訓可分為業務技術培訓和軟技能培訓，還有HR組織的集訓。

大家對技術培訓的第一反應都是PPT式會議，因為這種形式多，而且也是最最初級的培訓。
PPT最大的意義在於做報告，內容凝練而簡略，所以受眾是沒法得到很多的資訊的。但是這並不等於沒用。PPT式會議和網上的視訊教程一樣，能幫助零基礎的人快速入門。這裡需要解釋一下何謂零基礎，是指對這門知識幾乎沒接觸過，但已有相近的知識。例如已知C學C++或已知C++學Java，也就是說，至少不用在培訓中解釋何謂關鍵字或者面向物件。連相近知識也沒有的人，應該叫負基礎，他們會連PPT式會議都聽不懂，還是得迴歸書本。
書本不僅適合負基礎的人，也適合高階讀者。因為看書有時間細想琢磨，有助於吸收。專家級則是閱讀各種SDK和API文件。大神級的就是看各類原始碼看出神的了。

搜遍各種書籍和網際網路都找不到的東西，才是真正有意義做培訓的，多數跟本公司密切關聯：

• 產品的整體架構、設計思路、業務邏輯，迭代歷史等
• 各類工具/系統（IDE、需求、專案管理、測試與bug、文件等）的使用技巧
• 解bug、做優化等的經驗
• 工作流程和制度
• 本部門的知識體系梳理。直接用例子說明是什麼吧，請點選《iOS開發知識與能力體系 思維導圖》。文章很久沒更新，但能說明問題了，相信不做iOS的也能get√到。

掌握技術知識需要花很多時間思考並經過實踐，通過培訓來達到目的的價效比很低，只有其中牽涉到工作業務的部分能帶來實效。換句話說，“如何把技術應用到業務中”是公司內部培訓要解決的核心問題，而實現業務所需要的“技術”本身，應該讓大家邊自學邊實踐。

能讓受眾最大程度吸收的培訓形式應該是手把手地教，這個貫穿在設計和編碼過程中。本人實踐過，發現被培訓的人確實能完整地吸收，而且時間長了他會有反饋並跟你討論，你可能在討論中反過來也學到東西。當然，這個很少發生在網際網路公司裡，大家都很忙碌。

3.軟技能培訓

相對於程式設計能力、設計能力這些程式設計師的硬性要求，其它能輔助工作的技能都算軟技能。
大家能思考出這部分內容的意義嗎？答案我寫在最後吧。下面這些都是可培訓的。

3.1高效會議

這一節放到前面很重要，因為不少人搞不清幾種會議的差別。會議的主持人或主講人對會議的高效性負有最大責任，如果都用同一種思路來召開，會議就變得沒什麼效果。IT界“尊崇”的會議是喬布斯的蘋果釋出會和各種技術大會上的交流演講，可惜這些並不是公司內部會議的榜樣，很多人找錯了模仿物件。

會議型別	用途	特點和要求
釋出會	展示新產品、新戰略	算是一種表演，要聲色俱全，多媒體裝置只是一種道具。 目的是引起轟動，傳播的內容要能煽動觀眾的情緒，不斷製造高潮。
交流	傳播自己或本公司的經驗 （技術大會屬於這個性質）	展示個人、團隊或公司的優秀技術或成果，間接地賣廣告。 講授的內容具有高度概括性，不會講細節。 不會很在意觀眾是否都聽懂，甚至怕洩密而有所保留
培訓	傳播知識，提高工作效率	引導觀眾記憶和會後探索，目標是讓觀眾最大程度地記住傳授內容
宣講會	傳達資訊或做動員	觀眾可能是被要求來聽的，這在本質上是一種命令，所以不用在意講得怎麼樣
評審	對方案的評審	主持人講述自己的方案，觀眾提出意見和建議 對方案的描述要儘可能地細緻，目的是讓觀眾都理解後能發現問題，減少實施過程中的返工
總結	成果展示、述職	為了提高績效評級，在符合事實的前提下，能怎麼吹就怎麼吹，你懂的
研討	討論、頭腦風暴	沒有主講人，而要有主持人。非主持人都可以隨意發言，有專人做會議記錄。 主持人的最大職責是引導討論有序進行且不偏離主題，並減少爭論以至形成共識。
例會 （日/周）	日常的資訊交換	每個人都可發言，要儘量簡短。發言內容只需在場有另外一個人聽懂。 產生的問題會後再由各關聯者自行討論，不佔用所有人時間

*請留意交流和培訓的差異。

在日常工作中，一個會議的性質可能會包含以上多種，主持人需要在不同的階段完成不同的職責。特別是主持人也是作為主講人的時候，應該留意場景的切換，如培訓完畢後的問答階段。一般來說主持人都需要做到這幾點：

• 宣講會議議程或子主題，讓參會人做好準備配合
• 儘量使會議達成目標。如果沒達成，商定後續的安排，可再開一次
• 按時開始，不超時結束
• 幫助觀眾理解發言人（包括自己）的講話內容
• 提醒其他發言人注意時間、語氣等。不要因為一個人而耽誤了全部人的時間
• 確保重要的人員都到齊
• 引導會議中的討論達成一致意見
• 記錄重要的發言和待跟進事項

3.2培訓他人

好的程式設計師不一定是好的培訓師，但好的架構師一定是合格的培訓師，因為架構師必須向他人傳達自己的思想，那恰是培訓的意義所在。
做培訓的首要目標是讓觀眾完全吸收你所講的內容，當然這很難做到，但做得到讓人吸收大部分的也太少了。這是令多數公司不重視培訓的重要原因，但也不能完全怪講師，因為好的培訓是需要花費大量時間和精力的。如果不是專門設立培訓師崗位或者把培訓職責寫入KPI，沒有幾個人會對把培訓做到極致。交流演講和培訓的側重點不同，不能說哪個的要求更高，但如果把交流的意義上升到代表團隊和公司，那應該更重視。看看需要做多少功夫才能做好吧：

會前準備：

• 觀察和調查你的聽眾的特點，例如數量、知識與技能基礎、職位、工作內容、最感興趣領域等。培訓內容和手法應根據這些特點做調整，假如向Java工程師培訓C++，就可以多用Java的術語來介紹C++。
• 冥想和模擬訓練。在腦子裡演練完整個培訓過程，或者找個地方（培訓現場最佳）對著空氣講。這能減小忘詞的概率和減輕現場講演的緊張感，還能發現培訓邏輯的疏漏。如果還不夠，可以先讓少部分人來聽，然後再面向全體。
• 如果怕會上遺漏一些事項沒說，應準備一張小紙寫上給自己做提醒的話語。非莊重場合寫在手機裡也行。
• PPT的製作技巧，很多書可參考，不贅述了。特別提醒，如果確認這是一個培訓而不是一個交流演講，PPT上的字不應該追求簡略，特別是重要到需要觀眾記憶或記筆記的內容（也可能把PPT交給他們）。甚至可以考慮用Word或網頁而不是PPT。
• 如果要講到程式碼，不應該只用PPT。可以直接開啟編輯器對著程式碼講。在PPT裡貼大段程式碼的都是耍流氓，因為程式碼佔用的篇幅大，而且資訊量較多，很難短時間理解透。（這時候技術培訓不如文件，但現實往往是相反的，本質原因是文件的糟糕。讀者看不下去而希望能面授，集體的訴求自然轉變成現場培訓。）
• 如果需要演示操作或有多個培訓材料，應提前開啟所需的軟體，並令其狀態準備至一切換視窗過來就能講（例如滾動條位置都拖好），不要在會議上花費這樣的時間，因為一群人在等你。
• 發郵件提醒培訓的適用人群。如有需要，提醒參會者提前閱讀一些基礎知識。
• 保證自己在培訓過程精力充沛。為此，喝茶、喝咖啡、做幾個俯臥撐什麼的都行，用你喜歡的方式。
• 選擇觀眾注意力容易集中的時間段。不餓，不困，不忙等。
• 選擇好的場地，幫助觀眾集中注意力。不吵、無異味、氣溫適中（空調設好）、座位密度適中等。座位密度：太疏容易分心走神或聽不見就玩手機去了；太密會被旁人影響；一個判斷標準可以是側頭不側身地看，剛好看不清人家微信裡的字。
• 培訓內容的準備。思考如果你是觀眾，你最希望聽到什麼內容。培訓的思路可參考下節“寫作”。
• 其實，你的髮型和服裝都會影響培訓效果，不信你cosplay來試試。

進行時：

• 幫助觀眾保持注意力集中：
  
  • 如果講授的內容很繁重，可嘗試分節，每節40分鐘左右，中間休息10分鐘。是的，培訓的本質是上課。
  • 多微笑，聲音洪亮。在旁人眼中，此刻的你應該比平常狀態更興奮和活躍。自己表現得越投入，觀眾就會越認真聽，否則會變成一場催眠大會。
  • 提到他的名字，讓他的注意力集中回來，或讓他有更多的參與感。比如“某某肯定也是這樣想的”，“某某曾經說（問）過”，“這樣就能解決某某的問題了”。
  • 注意自己的姿勢、手勢，可用來引導觀眾的目光位置，但不要動作誇張到吸引走了注意力。如果一直拿著滑鼠，記得不要亂動，觀眾的眼睛會跟著游標走。
  • 開始講述的內容可以不怎麼重要，例如做自我介紹或描述一些東西輔助今天培訓的主題，幫助觀眾慢慢進入狀態。
• 演講的技巧：
  
  • 克服和利用緊張與恐懼。要理解這是人的天性，被很多人圍觀而自然產生的防禦心理，實際上這能幫助你更集中注意力做好培訓。
    克服它們的方法有自我暗示（用特定的話語激勵自己，想象過往成功的演講，想象這只是普通的例會等）、深呼吸、轉移注意力（喝口水，擺弄一下其他物品，跟別人說說話等）等。
    事實上無論你犯多大的錯，觀眾過幾天就淡忘了。
  • 不能用提問來考驗人，更確切來說不能令被提問者尷尬而導致冷場，別學學校老師那套。提問可用於：現場調查，證明結論；開放式的，沒有正確答案；讓觀眾猜測，活躍氣氛。
  • 重複以強調。講完例子或論據後重復一遍觀點，加深觀眾的印象。或者更直接地，“這個很重要，我再重複一遍”。
  • 不跑題。我就見過“我如何當好技術leader”這個主題花了三成時間講“我如何當上技術leader”的人。
  • 讓觀眾跟上你的節奏。“承上啟下，伏筆，呼應”這些寫作技巧，在演講中表現為“前面我們講的都是理論，下面我們看看如何應用”、“這點我們後面會有詳細描述”、“我們前面講到的XXX在這裡就是最典型的應用”。
  • 適當的停頓。如果需要觀眾思考、消化理解，不妨直接說“給大家15秒時間思考一下”，就這樣沉默著。
  • 幽默。注意幽默是為了加深記憶服務的，不要最終變成展示個人魅力。“如何製造幽默效果”這個話題很大，不展開了，建議找書看。幽默感需要刻意地積累，而且要恰到好處地用在演講上是需要鍛鍊的。
  • 說服。最佳方式是列舉好處，以利誘導，而不是把規矩硬塞入別人的思想。更厲害的方法是洗腦，這個也是可以找書看哦。
  • 要會講故事，在故事中蘊含你觀點。故事的形式比理論好。
  • 生動，運用打比方和對比、反比。觀眾一時難以理解你所描述的內容時，可以換一種角度來說。比如向不懂程式設計的家人解釋架構設計是做什麼，“就好比設計一輛汽車，要做到零件可拆卸組裝（模組化），多個廠家都能幫助生產零件（可擴充套件性強），開起來省油又馬力足（效能高）……”
• 控制會場的一切：
  
  • 利用好你的權力。無論發生什麼影響會議程序的事情，如何處理都以你的決策為主。即使你的上司在場也請記住，這個時候你最大。
  • 準備面對意外。比如投影儀或麥克風壞了你也能繼續做培訓；有人問你答不出的問題，你可以找後援團來回答或說會後私聊。
  • 現場環境的使用。麥克風音量、膝上型電腦、燈光、投影儀、座位擺放、提詞板、遙控器、鐳射筆、白板等。

會後：

• 收集反饋。提醒大家可以隨意批評這次培訓中做得不好的地方。
• 注意受眾的當場反應。
• 觀察受眾的會後行為，是否有受你的培訓影響而有所改變等

3.3寫作

這裡特指撰寫技術文件和報告，其它文件都比這個的要求低。
寫作是很多程式設計師的弱項，除了表達能力基本功缺乏鍛鍊外，最主要是忽略了文件的作用是給別人看的，不是給自己看的，無論內容多麼有意義也得保證使用者平均停留時間和留存率。這恰恰是產品經理熟悉的領域，好的文件也是追求使用者體驗的，所以想鍛鍊寫作的話不妨用一下這個偏方——找產品設計方面的書看看。舉個更形象的例子，電商網站（如淘寶）上的寶貝頁面也算一個文件，你是怎麼被吸引或引導去付費呢？當然，最好的模仿物件應該是Windows/iOS/Android的系統SDK文件。
培訓和寫作有部分技巧是相通的，這裡不再重複。

保證讀者有耐心從頭到尾看完：

• 讀起來通順，有一定的節奏感（長短句排布適中，合理使用標點符號斷句；不是指押韻，但讀起來會有一點點韻律感）。
• 有條理，有過渡，同級的子主題之間不跳躍
• 由淺入深，不會突然遇到理解障礙。想想C++/C#/Java書籍的目錄？
• 選擇不花眼、不太小的字型，排版好看，不凌亂
• 如果是web文件，要注意讓讀者不需要點選太多連結，必要時自己總結連結文件的內容。
• 一張圖片內不要資訊量太大。尺寸不要過大致無法一頁看完，或作適當分割；Web文件的大圖要做成豎型，不要產生橫向滾動條。

保證“傻瓜”也能看懂：

• 樸實。不要用口語，不要帶非群眾性的幽默甚至沒有，這不是在寫演講稿，也不要寫成內心獨白。
• 別賣弄知識和文采，也不要用偏門詞彙和方言，會影響部分人的理解。比如有多少人知道銀彈（silver builet）或者“拋書包”的意思？考考你粵語：撞板、撞彩。
• 抽象或模糊的概念和觀點有示例做進一步說明。（很可惜，本文因時間關係沒做到，那能寫成一本書了）
• 考慮讀者可能不具備一些基礎知識而看不懂，要麼在文章開頭寫明閱讀基礎，要麼在文中加註釋闡述。
• 沒有歧義。比如一個新聞標題叫“中國過早拆房1年浪費數千億”，這裡可以有三種歧義：“過早1年拆房，浪費數千億”、“過早拆房，這一年浪費數千億“、”過早拆房，每一年浪費數千億“。改成這樣就沒歧義了：“中國過早拆房每年浪費數千億”。
• 一個概念從頭到尾都用同一個詞，不要同時使用同義詞或近義詞，並且應選擇讀者慣用的那個。例如：
  1. “閃退”和“崩潰”都代表程式非正常退出，前者是使用者用語，後者是程式設計師用語（即Crash），但不是所有程式設計師都聽過“閃退”。當寫文件給程式設計師看時，應始終用“崩潰”這個詞，如果用了“閃退”，也許會有人問你“閃退”是什麼意思。
  2. Singleton有翻譯成單例或單件，應該統一隻用其中一個翻譯，或者全篇直接就用英文單詞。
  3. 更常見的情況是，某個業務名稱在這個部門叫AAA，在另一個部門叫BBB，寫給哪個部門看的，就應該只用那個部門的慣用語。

專業性，保證處女座不會看瘋：

• 簡潔凝練，不要廢話連篇。用最短的話說清楚問題。在技術領域，還可多用專業詞彙來減少長篇描述，比如用“外觀模式”代替“新增一個類統一封裝這個模組的所有介面，對外遮蔽這個模組的複雜邏輯”。
  更高要求的簡潔是在語文層面的，這方面的能力很多人在大學畢業就固定下來了，故不想多言，有興趣請百度。
• 精簡掉冗餘資訊，不是必要的資訊不寫或簡寫或寫在末尾，減少讀者耗費的時間成本。
• 關鍵的資訊處不能有錯別字。英文單詞拼寫也是哦，特別是時態、名詞還是形容詞。
• 嚴謹，嚴密，有邏輯。不斷論證，有理有據，不留疑問，無懈可擊

技術文件會被多次檢視，保證後續的閱讀能迅速找到最可能感興趣的點：

• 請注意很多製作PPT的技巧不適用於寫文件，兩者的用途分別是單次展示概貌和多次檢視細節，相差甚遠。例如不能盲目地執行“能畫圖的畫圖，能用表格的用表格”，有時候圖表不是描述細節的最佳方法。
• 能從幾個維度方便查詢。可參考論文、書籍的寫法，有目錄、摘要、關鍵字、前言、章節、參考文獻等。
• 重點的地方可改變字型（顏色、粗細、大小、字形等）
• 按檢視頻率排章節。某些文件會把思考和論證過程寫上去，最後寫結論。這也意味著別人檢視的時候，滑鼠得滾好遠，這時可考慮把結論放前面。
• 合理地分章節。這裡要很多例子才能幫助理解，時間關係只能講一個。假如文件的主要內容是“在Windows、Mac OS、Linux下如何使用執行緒和程序”，那麼：
  如果為了方便查詢各作業系統下怎麼使用，各節的標題應該是“Windows下的使用”、“Mac OS下的使用”、“Linux下的使用”，每節都是描述此作業系統下執行緒和程序的API；
  如果為了方便查詢執行緒和程序的使用分別在不同系統有什麼差異，那麼各節的標題應該是“執行緒”、“程序”，每節都是同時列舉三個作業系統下的API。
• 內容多到一定程度，應分多篇文件。和上一點一樣，同樣有技巧。比如寫Windows SDK的使用，可分為“初級篇、中級篇，高階篇”，每篇都可能講到繪圖框架，但難度不同；也可分為“……，I/O，繪圖，網路……”，把所有的繪圖框架知識寫到同一章。具體的應根據目標讀者的需求來劃分。
• 如果更新頻率較高或是多人合作，能不用畫圖的儘量不畫，或用文字型圖（點我看示例）。這樣方便維護，無需額外的軟體就能編輯；文字型圖還有個好處是可以Find和複製其中的部分內容。
• 利用好Web文件的便捷性——超連結
  連結的目標網頁如果不是最上面，應直接連結到錨點，不需要別人再拖動滾動條。
  連結過去的文件如果內容很多，一下子找不到你引用的資訊，應該自己總結一下或複製核心的內容過來

如何具備寫好文件的能力？多練，以及總結你看到的優秀文章的特點。
不過除非是寫使用者手冊（說明書）的文件工程師，很少有公司對程式設計師有這方面的要求，或者說國內還沒到這個境界。

3.4溝通交流

在團隊合作中總會遇到衝突，優良的溝通技巧能和諧掉很多不愉快的事情。

• 對事不對人，不要對人進行評論。即使對方知道你的原則，也可以是事先再說一遍“我是對事不對人的”。討論對方做得不好的地方時，應設法降低這種討論的不良影響，儘量去除對方警戒心以避免升級為衝突。
• 人多的場合，讚揚可點名，指出錯誤需匿名。
• 幽默。它可以化解很多的問題。
• 措辭。這個最好是向國家機關的發言人學習，但也不要太官腔。舉個例子，“不夠好”比“比較差”更少一點攻擊性。
• 隨時敢於承認自己的錯誤，可以解釋，但不要用來推翻你犯錯的事實。這個年代，“我錯了”、“你贏了”都成了幽默詞彙，還怕什麼多說幾句。
• 微笑。不建議偽裝地笑，應發自內心。如果做不到，不嚴肅即可。
• 理清概念，避免歧義。如果對話中有無法理解的詞語，要問清楚什麼意思，不要不懂裝懂。
• 請教別人問題時，先說明你的目的再講述細節，讓別人帶著問題去聽細節，他會自然地篩選其中的重要資訊。常用句式：“我想幹嘛幹嘛，現在的情況是這樣這樣，我該怎麼做或你有什麼意見”。
• 不輕易打斷別人，尊重發言欲。如果不趕時間，即使對方講的話沒意義也等他講完吧，至少在別人停頓稍長的時候再插入而不要顯得突兀。
• 抓住重點。簡單的事情不要用一大段話來說。當別人說了一大段無關緊要的話時，你可以用自己的話概況一遍請對方確認是不是這個意思。
• 精確傳遞資訊，不要誤傳誤報。
• 用打比方或過往事例來幫助別人理解你的話。比如向外行人解釋“終於把bug解掉了的感覺”，就像“肚子疼時終於坐到了馬桶上”。（哈，相信你會有更好的描述）
• 轉折話題時做好過渡，別人未必能反應過來，以為你還要爭論。很經常用到的一句是：“這部分是對的，還有一個問題是……”
• 控制好自己和他人的情緒，也就是情商的鍛鍊。實際的鍛鍊過程是需要經常反思的，沒有一個理論能幫助你應對所有狀況。

3.5敏捷教練

無論敏捷開發究竟有沒有用，至少很多公司在學習和推廣。Scrum Master是有認證體系的，可以派人去參加外訓拿個證書，然後回公司推廣。各種理論就不在此展開了，請百度。
補充一個點，教練的人選也很重要。最好是原本就在團隊內，但不是團隊leader，並且leader有當眾宣告教練的權責。這恐怕算是中國特色了。原因：

• 如果leader是教練，那麼大家都當是命令，會產生抵觸心理，也不敢亂提反對意見，達成不了自組織狀態
• 如果教練是外來的，礙於情面，很多改革難以指正執行
• 如果教練沒有足夠的權力（至少能合理地否決leader的意見），那會是個吃力不討好的工作。想純靠精神宣導，那是痴人說夢。

3.6行為規範/職業素養

HR領域的正直、不幹違法事情這類東西就擺一邊去吧。技術領域的也不提了，比如遵守程式碼規範，多寫註釋方便Review和維護之類的。這裡說的是：

• 做有利於團隊合作的選擇，但如果自己有犧牲也要表現出來。最簡單的例子：如果你的工作是團隊另一個緊急任務的前提，免費加班也先搞好。
• 忠於自己的專業眼光，不輕易妥協，也不做消極對抗。例如，如果認定這樣某段程式碼會有風險，在未驗證前不同意釋出產品。
• 承諾的時間點都按時按質完成。
• 傳遞前輩對你的幫助，激勵後輩的成長。
• 堅持學習。本文應該也有引導作用，除了學技術，還有很多可學呢。
• 多觀察別人是怎麼做的，多自己解決問題，不問低階問題
• 敢於承擔責任，不推諉

擁有的知識和技能越多，表現出來的素養應該越高，不再投機取巧。

3.7時間管理

“番茄工作法”和“四象限法則（重要&&緊急）”這兩個理論應該比較多人聽過。但如何正確運用在日常工作中恐怕很多人沒頭緒。這也就是培訓的重點，應結合實際工作舉例。這個領域的學問也挺多，鼓勵多看書。

3.8事務推進與思考

即使你不是leader，當由你牽頭某個事務時就需要應用一些管理方法。舉幾個例子，不解釋了，請點選連結：

• 破窗效應
• 木桶效應
• PDCA
• 六頂思考帽

還有很多，微博裡到處都有轉發，或者找些公眾號關注下吧。
知道這些理論還不夠，要自己思考如何運用到實際工作中。只舉一個例子，破窗效應：如果一個人不遵守程式碼規範而你又不要求他改正，其他人看到就會鬆懈、模仿、複製貼上，最後很多人都不遵守規範了。

3.9職業規劃

這種培訓少數公司才有，因為懂得越多，越會跟HR作對。呵，心大了就想升職或跳槽了。
問題大概有這些：

• 選什麼崗位，要不要轉崗。開發、測試、產品經理、管理類等。
• 選什麼行業。傳統軟體型、硬體廠商、網際網路、非IT業的IT部門等。
• 選什麼技術。前端、後臺、移動開發、硬體……
• 選什麼型別的公司。外企、創業企業、國企等。
• 選哪類城市。北上廣深還是二三線？
• 跳槽的時機。

公司組織的培訓一般都是某些英雄人物講自己在本公司的成長經歷，因為有很多限制，效果一般不佳，例如要避免炫耀的嫌疑，不能說得很細。而且可以說這可能是特殊情況，套在自己身上不合適。所以基本上都需要多聽幾個人的演講，由觀眾自己找出相似的點，這些點比較可能不是個案。
個人自學的話也差不多，多看些職業規劃的理論、名人傳記、網上寫個人經歷的文章（如《非計算機類專業畢業生五年程式設計師職業生涯的回顧和思考》）等。先廣泛收集，再從中挑選拼湊出合適的。也可以做做網上免費的職業評測。

3.10外面的世界

程式設計師可以終身都在學習，即使不跳槽，也要了解外面的變化，最起碼要知道同行的情況。培訓這些東西的最大作用自然是激勵員工。可是要得到這些資訊並不容易，因為有可能涉及商業機密。渠道還是有的：網路或技術大會的分享、第三方諮詢機構、社交、挖角過來等。
也可分享下外國本土公司的特點，雖然能照搬過來的東西不多，但能借鑑的也是有的。例如：開發活動的形式本身也在進化，不僅僅是人在追求最大效益；英雄主義的競爭文化，崇尚以一敵百的能力。

題外話：培訓自己

軟技能都不會給公司帶來直接明顯的收益，所以大多數公司不會重視培訓這些。實際上，軟技能可以加倍工作效率，公司和個人是雙贏的。就算公司不重視，自己一定要重視，沒人培訓你，那就自己培訓自己。如果技術水平相當、資歷相近的兩個人選哪個當官，那自然是選和領導最親近的。哈，你覺得和領導親近不是靠軟技能在發揮作用？
軟體工程的概念是借鑑工業工程的，程式設計師要發展也可以從很多其它行業獲取知識。就像程式設計能力之於程式設計師，以上每一種軟技能都是某一種職業的核心技能。也許你無法和很多不同職業的人交朋友，但你能買到所有職業的專業書，這年頭真的連如何當乞丐的教程都有。不要等著老師教你，推薦看看HR、管理學、心理學、銷售、演藝、人物傳記、科普、旅遊、藝術設計等領域的書籍。
還有就是，鍛鍊好身體，革命的本錢嘛。

補充