又到年终，各个单位都会开始自己的绩效考核和评优工作，这些工作中不免会有一项就是'评价你的同事'。刚入司的时候，没机会评价他人，工作年头多了，自然就有了'权力'去评价他人，这个评价对于被评价人当然是十分重要了，可能直接关系到他的奖金、薪水涨幅以及更好的机会，所以每当要给别人评价的时候，心里都'发虚'，生怕自己的评价不能完全反映这个人真实情况，带来些不好的后果。

也许"如何评价一个人"这个题目有些大，一个人的组成因素就很复杂，既有显式的因素，比如沟通能力、演讲能力、专业技术能力等，也有隐式的因素，比如道德、精神等。这里还是将话题缩小些吧，缩小为"评价一个人的工作情况"，这也是我们平时最常见的一种情况了。

这个话题源于今天我填写的一份公司级优秀新员工推荐表，公司发展很快，规模扩张迅速，每年有大量新员工加入公司，基数大了，评优的竞争就更加激烈了，所以人力在发来邮件的时候用上了'认真'二字，因为这份推荐表报上去后，会与其他新员工一起竞争，这样一来我的评价就起到至关重要的作用了。

思前想后无从下笔，到底什么样的语言才能更好地体现出这位新员工的优良表现呢？我的语言向来'比较枯燥'，缺乏感染力，如果生搬硬套一些现成的华丽辞藻反倒效果不好，那我只能摆事实了，用六顶思考帽的理论来说就是带上'白帽子'去思考，事实本来就是最能令人信服的依据了。然而从什么角度去摆这个事实呢？对于一个入司刚足半年的新员工来说，哪些事实可以让其与众不同呢？也许你要说技术？对于软件行业来说，技术大牛都是令人刮目相看的，软件行业里百分之九十以上都是技术出身，说技术肯定没问题。关键是半年时间也许还不够这批新员工完全展示自己的技术的，而且技术这个东西都是有体系局限性的，在一个Java人员小A面前大说特说某C语言开发人员小B技术有多棒，小A肯定会质疑：小B连J2EE是什么都不懂，怎么说他技术很棒呢？一头雾水。

那么除了技术外，在管理者角度，新员工还有哪些东西可以被看重呢？考虑再三，我决定从职业素质这方面说起。职业素质这个东西分显性素质和隐性素质。显性的素质比如知识和技能，隐性素质则是冰山下的那部分(很多管理类课程都会有'冰山'理论这一说)，比如职业道德、职业精神，两种素质相比，真正反映一个人后劲的还是冰山下的那部分就是隐性素质。对于新员工来说，让从学校出来进入社会，往往具备了一定的显性素质，而且差异不大，隐性素质有所欠缺，且往往差异很大。如果从隐性素质入手，很容易就能比较出来谁高谁低。

举两个工作中常见的例子：

前提：小A和小B，同样是刚入司的新员工，技术能力平分秋色，小A在技术深度上的理解甚至好于小B。

[情景一]
小A与小B同时接收到上级的两个任务，分别负责修改和维护一块遗留代码。两人的做法如下：
小A按照时间期限和任务目标完成了对代码的修改，思路方法都是模仿以前遗留代码的风格，即便他看出了这块代码实现和维护都很繁琐。
小B也同样在这段时间内完成了对代码的修改，思路方法也都是模仿以前遗留代码的风格。但是在述职的同时，小B拿出了另外两个成果物：一个是自己对遗留代码的总结分析文档，便于后人维护这段代码时有文档参考，另外他还向上级提交了另一套改造遗留模块的技术方案，并已经实现了原型，给上级做了演示，说明新方案的优点，小A为了这两份超额的成果物，每天牺牲一定的私人时间来工作。

[情景二]
小A与小B同时接收到上级的两个任务，分别负责设计一个子模块，输出设计文档(负责人给小A与小B两人提供了以前的一些需求和设计资料)
小A收到任务和资料后，马上建立一个设计文档，根据负责人提供的资料、已有的代码以及前期的一些研究开始埋头设计。
小B收到任务和资料后，同样开始学习资料和代码，并将资料和代码中的一些疑问列出，并定期向负责人咨询，负责人反馈后，小A不断修正自己的方案。

任务结束后，小A和小B按时提交了成果物，小B的设计符合需求，而小A的设计与负责人的预期目标却大相径庭，甚至某些需求都不能实现。

也许我不用再多说了，通过这两个工作中常见的例子，小A和小B高低立见。

最近一段时间正处于项目策划阶段，这个阶段势必要和部门QA打交道，咨询问题并获取支持。按照我们公司的软件开发流程，策划阶段要输出一系列文档的。这些文档都是有公司模板或者是经部门裁剪后模板作为基础的，所以现在项目前期策划基本上就是按照自己的思路填写文档，估计很多公司也都是这么做的。

好不容易花了一个星期的时间把这些文档'填全'了。提交给QA，让之帮忙审审。QA的一封邮件回来，问题多多。

当我看到这些QA提出的问题时，我的第一个念头就是"QA人员一定要有实际项目经验"或者说这些体系文档QA自己按照流程一个一个的实践一下，自己填一遍。这样就能体谅这些问题是为什么发生的了。比如说：QA建议每个项目阶段前都要有一个任务叫"策划xx阶段"，用过MS Project的人都会了解，如果分配给一个人的任务散布在整个Project甘特图的各个部分，十分不利于人员的任务分配，你要考虑到任务间的依赖关系，还要考虑到'资源工作表'中每个资源不能'变红(过载了)'。这些阶段性策划在实际项目过程中都是在一个集中的时间段完成的，大可集中放到一处。还有，对于多人参与的任务也是很难分配的，也是要考虑依赖关系和资源过载的。

部门的QA没有实际项目经验，隶属学院派的，工作很认真，并且有坚定的过程改善的信念，唯一缺乏的就是实际的项目经验。如果能到一线锻炼一下，相信她会发现更多待改善的问题，也就不用我们不断的提意见、沟通、反驳、再沟通、再达成一致了。谈到QA，我的理解是：QA一定要有坚定的信念，很好的执行力，丰富的项目经验，相信通过良好的不断改进的过程一定能让项目管理更加精确、准时。否则如果没有这份坚定，做起工作来那简直就毫无乐趣而言了。很多大公司的QA都是由一线开发人员、测试人员或者是项目管理人员转型后来做的，他们在项目里待过，知道改善的地方在哪里，同理心更强，知道开发人员为了达到某个项目管理的目标需要付出的代价。有项目经验的QA能大大减少纸上谈兵的概率，提高自己的说服力。

还有很多问题原因不在QA，而是模板的问题。填写模板时我们也希望要填写自己能控制、能想到的东西，如果在自己控制力之外的一些东西非要填，那就很头疼了。其实这也和部门角色定位有关系。部门的项目负责人与传统意义上的项目经理不甚相同，部门的项目负责人在一定意义上是偏技术类的。如果让偏技术类的负责人去填写什么"信息资产管理"、"共利益者管理"、"客户资产管理"、"项目采购计划"这类的表格显然是"门不当户不对"。

做项目也是做事，应该本着一个原则'简单'。把一些与项目目标不相关的事情也牵扯进来似乎费力费神，毫无意义。记得在上一个项目总结会上提到过一个成本目标的问题，项目初期策划时需要填写一个成本估计，然后结项时收集实际成本数据做比对，看目标是否达成。可是项目总结时根本无处获取这样一个成本数据，财务那面根本就不会给我们技术负责人出这种报表的，类似这样的'估计'估之作甚呢。

意见和建议已经提交给QA了，估计明天又会有一次激烈讨论。^_^