没有什么比用绩效考评弄垮一个团队更方便更快捷的了，让我来告诉你怎么做。
给硬件团队考核发布频率，要求跟隔壁的软件团队一样快，给面向客户的团队考核用户投诉要求跟后台团队的投诉一样少。给前端团队考核 bug 数量，要求他们的跟架构团队后数据团队的 bug 数量一样少。
还可以这样的给交付产品，最多团队考核他们的 bug 的个数，给做大型系统开发团队考核他们需求响应的速度。给成天忙着救火项目团队考核他们的文档和流程的完整度，给负责创新业务的团队考核他们需求变更的次数和近期的营收指标。给负责维护老旧系统团队考核创收、发明创新以及新技术的应用。
如果一个团队每个人都合作紧密，活也干得无可挑剔，那就更容易了。设定团队里 20% 的人必须低技巧，这样团队内部就会因为谁是低绩效而坦诚隔阂，还忽梁防备着马上就能出现问题。
如果一个团队业绩增长的飞快那也很容易出现一个用户投诉，马上评判团队的服务体验不好，差评婆兔的。如果是一个需要技术能力团队，比如说 AI 团队、算法团队、数据团队。把他们的核心成员调走，或者不给招聘的headcount，不给人、不给资源，过段时间再以没出成果给团队差评。
如果一个团队已经完完全全按照你的指标规则都打了高分。那也没有问题。等到评估的时候，临时加几个意想不到的指标，或者说我没有感受到你的诚意，我感觉你们不行，给他们打低分。如果是一个老员工，拿的工资也不高，兢兢业业的维系一片老旧系统的正常运行一直都没有出现问题，那你就问它到底起了什么作用，有什么价值？这些系统一直都好好的，你都干那些啥呢？
跟测试团队说你们测出来的 bug 越多越好，跟开发团队说你们被测出来的 bug 越少越好，这样测试就会跟开发之间互相掐架，谁也看谁，又不睁眼，只要掐第二，这样总会有人计较差。还有这种事儿跟运维说只要发布出现问题就扣你们的这招，跟开发说你们发布的频率越高越好，这样开发和运维之间就会打架，运维不愿意发布，而开发新闻播发布还是那样的，只要有人参加就会有人饥饿差。还有这种事。
儿跟中升管理人员说团队人员流失太多的话稳定性差，不会带团队，那就给你差评。到了评估时候，那是十部长兵绩效必须按统一规则严格要求，必须用 20% 的人绩要差，这样中层管理人员也会得差绩效。还有这种事儿在跟中城管理说，要激发创新，要大胆改革，同时告诉所有团队要听话，照着一切以规章制度、红头文件为准，这样的中层管理人员又获得他绩效。
告诉你这么多学废了吗？快在团队中用起来
最新评论
