我在一家手機公司做新產品功能部門的研發負責人的時候，管理著5名程式設計師，大多數是畢業3年左右的android開發工程師，他們熟悉android的技術開發，四大元件與android架構都非常熟悉。我簡單介紹這5個人的特點：

      程式設計師A:89年出生，喜歡讀書，買了30本左右的android圖書，從入門篇到核心架構，再到unity3d，幾乎全涉獵了，這個程式設計師當時進入該公司因為女朋友是公司財務，是公司的關係戶，當時的技術總監安排的活幾乎都被頂回去了，最後總經理與他聊，他說總經理的口才比較好，最後將他安排在我們部門，我當時心裡上也認為該人也就一個關係戶而已，但是接觸後，他寫的2D動畫效果非常好，程式碼也比較規範，於是我開始另眼看他，幾乎很多預研的技術疑問點都交給他，讓他通過其DEMO特點，給出一個結果，效果很好。

      程式設計師B:90年出生，是一個很少說話的工程師，是公司最勤勞的工程師，當年到公司不倒4個月，就被公司評為最優秀員工，要知道我們公司幾乎都是從早上9:30，一直幹到晚上10:30左右，這是正常的程式設計師的下班時間，忙一點的主管或者專案核心，測試人員，凌晨3:00甚至通宵都是完全可能的事情，星期六也是全天上班，在這樣的公司裡邊的優秀員工，可以想象一下，是什麼樣的工作態度。當然，天道酬勤，這小夥子的技術也是不錯的。那麼，我當時把什麼樣的工作給他的呢？那就是開發量大，幾乎難度不是特別大，專案週期緊的開發任務分配給該人。比如vivo的異次元launcher，客戶指定要這樣的效果，幾乎3個星期，這個launcher就在這個“老實巴交”程式設計師的努力下，高仿完成了，不愧是優秀員工。

      程式設計師C:89年出生，其實上面兩個是優秀的程式設計師，但是不是傑出的，而C呢，我認為是傑出的程式設計師，怎麼說呢？因為他知道“偷懶”，每次我去陽臺上溜達溜達，都看見他在抽菸，可是，真正的核心專案，還得交給他來做，因為他知道如何溝通，公司需要的東西，讓我去完成，當我講明我的意圖，如“減少測試人員的機械操作，或者測試人員未能完成的整機效能測試的智慧測試工具”，他會在專案開始的時候，反反覆覆的詢問我，系統的需求，系統的邊界值，然後，自己再專案未做還在做的途中，“犧牲”了很多時間來思考，看如何能夠更加容易的實現這樣的功能，另外，更主要的，他“犧牲”很多時間來與我溝通，從而在整個專案的進展當中，讓我瞭解是否與我要的東西發生偏移，而其他程式設計師，幾乎都要我主動去關心進展，甚至，對某些需求，他會說，不好做，能不能就像現在這樣呢？所以說，對C程式設計師這樣型別，我更加願意把重大專案交給他完成。

     程式設計師D:88年出生，當時是另外一個主管招的他，因為android後面我全部負責，所以就安排在我的團隊裡邊，當時招聘聘用他的原因是，問他加班怎麼樣，他說樂意加班，再晚也奉陪，看樣子是很久沒有工作還是真的喜歡加班呢？這個人的特點是，不太喜歡溝通，但是，因為缺乏專案經驗，每次完成的工作，都需要我指出這裡那裡的缺陷，然後再修改，幾乎我每天都要“關注”他。

     程式設計師E:86年出生，確切的說，不是程式設計師，是專案工程師，因為總部在異地，分工原因，我們只能開發APK產品,而公司出的是手機主機板，所以我們部門算是“醬油”部門，而客戶確在深圳，於是，E就負責總部的專案協調工作，E的特點是熱情，哪裡有問題，哪裡就有他去解決，後面我看他也夠閒的，於是我把專案的“雜事”都分配給了他，他也樂此不彼。

     按理說，這樣的一個小團隊，人員分工也按照其特點進行分工了，還需要激勵嗎？當然需要，那麼我的激勵措施是什麼呢？很簡單，就是能力培養，你可以是一個非常優秀的程式設計師或者專案管理人員，那麼不一定就是很有能力的人。

      於是我們第一個措施激勵措施就是受訓，我們的培訓也有針對性，首先我根據他們的共性，制定了系統設計上的培訓，他們都是程式設計師，比如設計網站，他們可能僅僅考慮了客戶端的APK，然後開始做APK了，也不管後臺怎麼樣，資料怎麼錄入，資料怎麼運算，PC上要做什麼事情，手機上要做什麼事情，所以針對全體進行的技術培訓，雖然短期內，”影響“到工作，可是如果他們有設計和計劃做事的好的觀念，至少我可以放心的分配給他們原來需要我做的事情，比如需求設計，概要設計，詳細設計等佔用我大量時間的事情。另外，也請公司總部就他們所熟悉的5W2H等他們培養管理人員的培訓方式培訓他們做事能抓住重點，提升能力。

      第二個激勵措施是他們的反向培訓，公司的出貨以功能機為主，功能機的主管和專案人員對智慧機的開發非常想了解，大家一個辦公室的同事，很多時候他們去詢問我們部門的android開發人員，既影響工作，也感覺到對公司的整體不利，所以我給android開發同事們說，讓他們培訓會議，也得到技術總監等的大力支援，於是他們也開始學習怎麼樣做好培訓，因為給老開發人員做培訓，MTK功能機的整體，受訓人員瞭解非常透徹，他們常用MTK的思維來理解android，所以培訓人員也不得不互相請教或者閱讀framework的內容。

      第三個激勵，就是工作成果或者階段性的激勵，我們的新功能組的會議，從來都不是我一個人講什麼事情，而主要是開發人員講述他們做的東西，從同事的讚許，質疑，建議總他們感覺到自己的工作成功，還有工作的不足。

      第四個激勵，開發人員情緒安撫和制定可行的計劃。我不會讓他們到我的位置來與我聊天，我會到他們的工作位置上去，瞭解他們的最新進展，單獨處理某一個同事的問題，對做得不錯的，予以肯定和讚揚，對不足的地方，提出合理的建議或者參考標準。非常重要的一點，就是對開發人員的情感和情緒的安慰，當有新專案的時候，因為新，因為難度較大，他們可能比較焦慮，這個時候，我就只需要告訴他，不要著急，你只需要本週完成哪些東西就可以，我發現很多管理人員在制定計劃的時候，根本完不成的任務，也寫進了計劃表，這樣的特點會造成開發人員的”不誠信“，因為反正是完不成，怎麼做都無所謂。而我給他們的是他們努力能完成的任務，這樣，幫助開發人員分解任務，專案變得非常可靠，開發人員在不斷看到自己的成果，與管理人員的信任也逐步建立，沒有焦慮情緒，更容易溝通和建立良好的上下級關係。