識人用人是指識別和發掘下屬的優勢與潛能，用人之長。對於不足的部分，也可以有效地加以補強。雖然這個
工作很重要，但相關的研究和方法五花八門。個人覺得適合就好，倒不一定非要熟讀九型人格，然後再加以套用,並且不見得合適。準確的認識乙個人總需要一些過程，中間需要多次修正，才可能比較完整。結合所從事軟體開發工作的特點，我使用了能力賬戶(靈感來自《高效能人士的七個習慣》中的情感賬戶)的概念來識人用人。
**示例:
各項的評價都以正向的方式進行，有利於將焦點定位於"所長"!
對於技術的部分，因為涉及的專案較多，可以制訂乙個技術樹來展開所涉及的技術專案，一方面組員可以了解工作會使用到哪些技術？有哪些還需要
學習？對主管而言，也可以對組員的技術發展有乙個系統的認識。
評價的層次不用太複雜,如果所有專案都按1～5分級就繁瑣了，日子一長，對於是2還是3會變得無所適從。當然也沒必要每項使用統一的層次，不過基本上兩個分值就可以了。舉個例子，如果要求a工程師做了一件對流程改善有益的事，則在這件事上,"流程及方法的優化"專案是沒有加分的，應當加分可能是"技術學習與攻關"和"
問題分析能力"。
在評價過程，不可避免地會出主觀因素和近因效應的影響，主管一定要有先分析，再加以甄別。比如，在一次release中因為某人的所負責的部分不合格被qa拒收，它就包括了以下可能的原因:
1.qa發現的是新問題。
2.specification中未能明確定義。
3.release前測試不充份。
4.對功能定義沒有理解清楚。
5.沒有同其它模組的修改同步。
6.接收到錯誤的指令。
7.對負責部分的**理解不全面。
8.編寫**時的疏忽。
除了第8點個人負主要責任外，而對於其它各項，更多地還是要檢討流程和主管的責任。(主管不好做啊!即便是第8項主管也有相當的責任，比如**走查的實效有問題。）總之關於問題分析與檢討也是要花些心思的，視問題的發生為機會，應當從分析中找到改善的措施。如果確係個人因素，才可以依狀況調整能力賬戶。
個人能力賬戶的調整，變動的頻率應當越來越小。試用期結束還一直變化評價，就需要冷靜思考一下指標的定義和評價方法是不是主觀因素太重。在績效面談時，也可以使用這張表同員工討論職涯發展規劃，以及主管可以為其提供的支援。
一開始，出現些偏差是不可避免的，只要敢於嘗試，不斷在實踐中修正，就一定可以找出一套適用的做法，這對
團隊管理會有很大的助益，也是自我提公升的實踐。
MySQL資料遷移之能力提公升
公司項由於目因業務需求變化，進行了許可權模型和部分業務表結構更新，同時要求原資料可用。這就是導致我們不僅要更新表結構和業務需要，同時需要對舊資料進行遷移，保障使用者資料不丟失。select insert語句的使用 select insert是基於 將a表的多個記錄插入b表 的場景使用，樣咧sql如下...
SIP協議簡介（五）之能力查詢（OPTIONS）
sip方法options允許乙個ua來查詢另外乙個ua或者proxy伺服器的能力。這個提供個客戶端乙個手段來查詢服務端支援的方法，內容型別，擴充套件，codecs等等。這些都不用 ringing 對方。比如，在客戶端試圖在invite請求頭中增加乙個請求字段選項的時候，它並不知道對方uas能否支援這...
敏捷團隊建設
敏捷團隊建設 本文發表於4月 軟體世界 最近很多人都問我，有沒有適合的人可以推薦給他們公司，他們正在招人，面試了很多個，但有經驗的開發人員太難找了。有乙個朋友在問我要人的同時，他手下的乙個開發人員反而問我有沒有好的機會，他想跳槽。不久前乙份報告稱，中國本地軟體企業面臨的最大問題之一，就是高階技術人才...