识人用人是指识别和发掘下属的优势与潜能，用人之长。对于不足的部分，也可以有效地加以补强。虽然这个工作很重要，但相关的研究和方法五花八门。个人觉得适合就好，倒不一定非要熟读九型人格，然后再加以套用,并且不见得合适。准确的认识一个人总需要一些过程，中间需要多次修正，才可能比较完整。结合所从事软件开发工作的特点，我使用了能力账户(灵感来自<<高效能人士的七个习惯>>中的情感账户)的概念来识人用人。
表格示例:
各项的评价都以正向的方式进行，有利于将焦点定位于"所长"!
对于技术的部分，因为涉及的项目较多，可以制订一个技术树来展开所涉及的技术项目，一方面组员可以了解工作会使用到哪些技术？有哪些还需要学习？对主管而言，也可以对组员的技术发展有一个系统的认识。
评价的层次不用太复杂,如果所有项目都按1～5分级就繁琐了，日子一长，对于是2还是3会变得无所适从。当然也没必要每项使用统一的层次，不过基本上两个分值就可以了。举个例子，如果要求A工程师做了一件对流程改善有益的事，则在这件事上,"流程及方法的优化"项目是没有加分的，应当加分可能是"技术学习与攻关"和"问题分析能力"。
在评价过程，不可避免地会出主观因素和近因效应的影响，主管一定要有先分析，再加以甄别。比如，在一次Release中因为某人的所负责的部分不合格被QA拒收，它就包括了以下可能的原因:
1.QA发现的是新问题。
2.Specification中未能明确定义。
3.Release前测试不充份。
4.对功能定义没有理解清楚。
5.没有同其它模块的修改同步。
6.接收到错误的指令。
7.对负责部分的代码理解不全面。
8.编写代码时的疏忽。
除了第8点个人负主要责任外，而对于其它各项，更多地还是要检讨流程和主管的责任。(主管不好做啊!即便是第8项主管也有相当的责任，比如代码走查的实效有问题。）总之关于问题分析与检讨也是要花些心思的，视问题的发生为机会，应当从分析中找到改善的措施。如果确系个人因素，才可以依状况调整能力账户。
个人能力账户的调整，变动的频率应当越来越小。试用期结束还一直变化评价，就需要冷静思考一下指标的定义和评价方法是不是主观因素太重。在绩效面谈时，也可以使用这张表同员工讨论职涯发展规划，以及主管可以为其提供的支持。
一开始，出现些偏差是不可避免的，只要敢于尝试，不断在实践中修正，就一定可以找出一套适用的做法，这对团队管理会有很大的助益，也是自我提升的实践。
*在Harold Kerzner的<<Project Management - A Systems Approach to Planning, Scheduling and Controlling>>第五章提到了Personal Skills Matrix，其中也提到其它几个相似的工具以及它们的功能和缺点。
转载请注明出处:http://blog.csdn.net/horkychen
同类博客参考: