1. 软件人员的绩效管理。
      我不知道现在还有多少公司还用代码行数来算生产力的，我以为采用如此办法考评的只能说明一点：公司没有办法组织起有效的绩效管理。绩效考核应该以：所实现的技术复杂度＋所花费的时间（OT时间一定要算）＋加权调整，3个来评定。
      业务的复杂性往往导致技术实现上复杂，A和B两个工程师在相同时间内完成不同的项目，A的复杂性高于B的复杂性，那么A的绩效应该高于B。不过，实际的情况往往不是这样，复杂性越高的项目需要的时间也会越多（当然如果有人能很快完成，说明之前他积累的相当的经验能快速分析或者是对这个业务本身很熟悉），无论如何完成工作所需的时间是需要做合理的评估的：10天，1个月或者更多，一个需要1个月可以完成的项目用了1.5个月，那么考核绩效就需要降低。
      有看客说了：你这是坐着说话不腰疼。技术复杂度和时间的评估是那么容易做的，这里面的人为因素就可以让整个绩效管理全部跨掉。
      这位看官还真让你说对了：
      技术复杂度确实不好估计，一名优秀的架构师可能觉的是B的复杂度的项目，在一名普通工程师眼里可能是A。
      时间评估也不好做，老员工凭着对业务和系统的熟悉，以及对公司内部资源的了解，可以很快的理解需求（自学或者找有做过类似的同事学习）认为只需要2周的任务，对于一名新员工来说可能需要1个月。
      这样的情况将使实际的绩效管理一团糟。
      我们需要尽可能的减少两者评估在不同团队成员间的差异性，而这个手段是用统计方法＋案例法：把所有的做过的任务翻出来重新评估统计。参与统计的成员尽可能覆盖广，这样就可以得到一个相对合理的评估值，对与新的任务，就类似英国的案例法，参照旧的以做过的项目给出的评估值。（当然这个值合理与否在于统计的任务数）此外还有个统计覆盖时间取舍，软件技术更新很快，通常采用新的技术框架往往会改进工作（举例：在使用webwork+spring+hibernate和前webwork+spring+hibernate年代做同样的时间，花的时间是不一样的）。对于复杂度来说，用新的技术框架＋公司不断改进私有的平台是可以在一定程度上降低复杂度的。这是我不用“业务复杂度”而用“技术复杂度”的原因。
      在这个基础上加上一个加权调整，理论上可以比较好的做绩效管理了（实际情况很难讲，具体大家都知道怎么回事）。
      实际工作，由于这样的成本比较高，对于小企业和项目导向型的企业来说不太实际，或者没有，或者草草完成。

2. 软件公司的内部消耗
      因为是团队合作，每个开发人员的工作需要其它同事协助。这里的内部消耗就是这个，包括了知识传递，工作传递和工作委派。对于公司来讲，希望努力控制内部消耗就来提高竞争力。不过这种事往往吃力不讨好！
      知识传递。最传统的是靠文档，同样最靠不住的也是文档。写文档的人费力，看的人也费力。写文档人往往假定读的人对文档的需求背景有一定了解，有意无意的省略一些东西（例如：写的文档人由于对需求背景很熟，觉的有些东西司空见惯，就不写），但对于读的人来说却未必。
      工作传递。最常见的新来的觉的老代码都有问题，来一批人就重新写一次代码。还有比较常见的是一些任务大处了讲没什么，细节却很多很琐碎（意味着陷阱很多），传递的人不知道从何处讲，接手的人不知道有陷阱，往往做到后来还是给不停的问。
      工作委派。这个就更容易耗时间了。一件不大的事，请人帮忙，那人手里不忙还好，如果忙事情的优先级又不高就不知道什么时候能做好了，尤其是跨部门的时候。
      XP的开发方法试图解决这样的问题，似乎蛮有效！可惜还没有机会尝试，如路过的看官有心得体会还请赐教。