標題是在我思緒亂飛，文不及意的時候改的，原標題是命題作文“CTO的最後一課 第一季畢業設計”的一部分，《技術團隊績效考覈機制》，思緒飛完，發現這都是自己的意淫，作爲一個基層員工，除了自我管理就是被管理，談技術團隊的管理，未免太不切實際，但是恰是因爲自己是被管理的對象，所以在聽完CTO訓練營整整一季的課後，我想說，老師，我有話要說~
在思考如何激勵時，自然想到了CTO講師于斌平《技術團隊如何做績效管理》中的論述，于斌平老師有着10年以上500人以上的團隊管理經驗的，觀點也是經過了實踐的淘洗，有幾點很適合我們當前的團隊。此處並非拿來主義，更不敢談英雄所見略同，但是作爲基層管理人員，有些point還是可以get到的~
1. 考覈預設
統一的價值觀，引導，“方向比努力更重要”——CTO講師于斌平
預設是爲了將企業對技術團隊，乃至具體到員工的價值期望傳達到位，而不是在最後評分的階段流於形式，對員工評價高，打分低或者打分評價都高，卻沒有實質的獎勵，再次驗證了方向比努力更重要的正確性。
2. 採用OKR而非API
KPI有毒，此言不假，如果設置不當，對團隊和個人不能指導就會變成誤導了。
OKR全稱是Objectives and Key Results即目標與關鍵結果，何爲關鍵結果？
做了幾個項目，搭建了幾個系統，測試除了多少bug這個是關鍵結果嗎？是，但是核心還不夠清晰，有產出是必要的，但是我們忽視了其背後的兩個重要的目的，一，對業務帶來的收益（此處綜合考量成本），二，對技術人員帶來的成長 。細化一下：是否純粹爲了bug數量這一指標，在IE6兼容問題上技術爭得火熱？是不是用合適的技術，高效優美的完成的項目？搭建的系統有沒有後續推廣指導投入到作業中？等等。
3. 激勵策略
那，重點來了，作爲技術管理層，這種格局下怎麼才能通過管理手段，來打造一支有活力，有戰鬥力，熱血又不輕浮的技術團隊呢？以下我從週期，內容，獎罰及關鍵因素四個方面，來論述OKR的落實：
具體的目標及獎懲機制根據具體人員及項目來設置調整，原則是要能充分調動起技術人員的積極主動性，成果明顯，氣氛歡快輕鬆，員工幸福指數高。
另外， 既然是團隊激勵，那團隊的組織結構將密切影響激勵方案及方案效果。以下是某司的技術部組織結構草圖：
這種小組劃分，優勢明顯：分工明確，責任到位，各司其職，術業專攻；
劣勢也很明顯：工作形式長期單一，組間各自爲站，不利於技術交流及發揮整體團隊協作的power。
公司作爲較早崛起的互聯網公司，積累了豐富的互聯網經驗，資源及用戶；傳統業務項目歷久彌長，業務形態成熟穩定，技術方面以支持爲主；隨着互聯網的迅速發展，網絡的普及，智能手機的大衆化，辦公移動化等時代的進步，如何突破創新，走出安逸，跟隨甚至引領互聯網大潮，對企業及技術團隊提出了較高的要求；業務先行，技術需提供強有力後盾。
這種業務形態下的這種組織，貌似是很合理的，但是，員工職責單一，在團隊規模不大的情況下，組員成員少，人才梯度小，不能幫扶，不利於員工成長； 時間久了，呈現出兩類員工，一類是對業務輕車熟路，對技術熟視無睹（或者感覺當前的工作都在把控之內，無意識也無能力超於自己）；另一類是有追求，也是不能自己完成突破，通常寄希望於環境來改變自己，比如離職跳槽；
第一類的員工貌似會給公司帶來穩定，實則是不求上進的態度（企業和員工都是），試想技術迅猛發展，用戶需求複雜多變，這種保守會讓企業慢慢的掉隊；第二類的員工通常都是有想法，和對自己的投資負責的員工（員工選擇企業併爲其工作也是一種投資”），能留住此類能自驅的員工，併爲其提供成長的環境，形成互利關係，纔是健康茁壯的團隊面貌。
組織結構是穩定的產物，這裏並不是要打亂當前結構，把團隊揉成一團，而是可以結合OKR的形勢，在關鍵事件中，引入“技術指導”之類的概念，擔當技術指導角色的通常是來自其他組，有能力的人貢獻想法，能力稍差的人在指導下落實實踐方案。實踐結果都納入二者的考覈範圍。（貌似和大公司的師傅帶徒弟制度類似，不過導向更明確）。
至此，好像說了很多，又好像什麼都沒說清楚，理論是美好的，現實是多變的，但是相信努力不會白費，經過摸索和實踐一定能找到適合自己團隊的風格。
本文旨在拋磚引玉，技術成就夢想，讓團隊更美好！