• 不要过早进行绩效考核

很多企业喜欢刚刚建立绩效管理制度，马上就使用它进行考核，这种情况是不好的。因为，人们在刚刚接受一种新的度量体系的时候，往往对其中某些事物的定义还不够规范，不同的人认识还不一定是一致的。
在这种情况下贸然进行考核，使得人们会倾向于向对自己有利的方向理解和解释这些定义，而不是向客观事实的方向。这就在一段时间里引发大量的争议，而且永远找不到正确答案。
建议的操作模式是这样的：先建立度量体系，并告诉大家，半年之后将使用新的度量体系进行绩效考核。那么在半年之内，大家就会认真的去理解，这些度量体系的定义，并且充分地透明地度量出自己和其他团队的结果来。在这段时间里，组织应该帮助那些绩效不好的团队进行相应的改进，以便在正式度量的时候，获得好的绩效。
真正生效的时候，后进的团队已经获得了一些改进，也充分认识到，只要持续改进绩效还会不断上升，因此反对的力量就会小很多。

• 防范反向绩效

很多绩效考核的方法看似非常合理，非常直接，但是却有可能产生反向绩效。
比如说，有的时候我们希望提高生产率，因此会度量每一个迭代按时完成率。看似大家一定会为了按时完成，而不自觉地提高生产率，但其实不然。要保证按时完成每个迭代的最简单最直接的方法，并不是提高生产率，而是预留缓冲时间。但是这种做法，非但没有提高生产率，反而降低了生产率。
其很久以前敏捷绩效管理曾经有一个分支叫做DSDM，动态软件开发方法。在这种方法里有一种概念，叫做MoSCoW，分别是英文，Must，Should，Could，Would not的缩写。
它提供一种新型的度量方法：第一，每个迭代必须保证60%的任务按时完成（Must），这样就保证了迭代的可交付性；第二，所有迭代的平均值，应该是80%（Should），而不是60%，这个平均值可以认为是平均的生产率。为了要达到80%的平均值，由于在某些迭代只能完成60%，团队必须在另外一些迭代中，超过甚至远远超过80%（Could）。
这样，我们在保证每个迭代能够按时交付的前提下，同时也保证了总生产率没有受到负面的影响。