闲聊绩效管理- 未病还是末病？

185 2024-01-13

团队绩效

短短一个月内，阿里的笔记和文档知识库-雀语宕机了两次，引起IT行业人员热议。作为纯制造业背景，大学玩过单片机的小编来说，个人也起哄发表一些看法。没想到大家非常感兴趣，刚开始以为只是从制造业视角来看看IT行业的问题。随着往下挖和讨论，才发现，现象的背后，都反映出目前大多数公司的共性问题-绩效管理。

恰好最近参加培训期间，频繁听见大佬们分享企业绩效管理的小故事，总体来看员工们“苦不堪言“：能者多劳，鞭打快牛，溜须拍马之人平步青云…从大家的反应和吐槽来看，这些现象看样子不仅仅是企业个例，这是非常值得大家审视和深思的。

结合小编近期的一些反思，本文一起和大家聊聊企业绩效管理。在此之前，我先分享扁鹊三兄弟的一个小故事，先进行热身。

圣人不治已病，治未病，不治已乱，治未乱，此之谓也。夫病已成而后药之， 乱已成而后治之，譬犹渴而穿井，斗而铸锥，不亦晚乎。

——《素问·四气调神大论》

根据典记，魏文王曾求教于名医扁鹊。“你们兄弟三人都精于医术，那么请问，在你们三兄弟中，究竟谁的医术是最好的呢？”

扁鹊回答道：“大哥的医术最好，二哥的医术差些，而我是三个人中医术最差的那一个。”

魏文王紧接着又问道：“那为什么你在兄弟三人当中是最出名的呢？”

扁鹊解释说：“大哥治病，是在病情发作之前，那时病人自己还没有意识到自己身体不适，大哥就下药铲除了病根，这使他的医术难以被人认可，因为他治未被病，所以没有名气，只是在我们家中被推崇备至。我的二哥治病，是在病初起之时，症状尚不明显，二哥就能药到病除，使人都认为二哥只是治小病很有效。我治病，都是在病情十分严重之时，病人痛苦万分，病人家属心急如焚。他们看到我在经脉上穿刺，用针放血，或在患处敷以毒药以毒攻毒，或动大手术直指病灶，使重病患者的病情得到缓解或很快治愈，所以我名闻天下。”

看完这个故事，相信读者肯定也有点感觉了。治未病只能内部崇拜，治末病才能外部知晓！

这是不是很符合企业选拔人才的重要指标。我们想想：一直在救火，忙于解决突发问题的项目经理能力就强吗？项目期间一帆风顺，项目难道就没有难度，项目经理就没有能力？

某公司同时入职了两名刚刚名校毕业的项目助理，几年期间，他们都先后得到快速成长，并成功成为了资深项目经理，两人的综合绩效都很突出，不相上下。此时，有一个高级项目经理岗位空缺，需要在A和B中选择一人。A：几个项目总是顺风顺水，没有非常棘手的问题需要解决。管理层把项目的成功归功于团队；B：项目期间问题点不断爆出，一直奔波在解决问题的路上，但是最终项目还是可以像A那样按时按质交付。管理层把项目的成功归功于B的能力突出。最后，B顺理成章获得了该岗位，A也在不久就离职，且A那边的骨干也在A离职后陆陆续续离开。

A和B在多年后，坐在一起，无意间聊到了这件事。A一直致力于发展团队的能力，在项目期间给了大家很多锻炼的机会，此外还安排了与业务相关的集体培训。在A做项目经理期间，由于团队成员能力突出，基本上可以提前规避大部分项目风险，所以项目看起来都顺风顺水。B个人能力很强，团队成员按照自己的工作方式推进项目过程中，由于能力不足，无法提前避免风险。一般都是风险爆发后，B才知道。此时，这个风险超过了团队成员的能力，B为了让项目按期交付，只能自己上去摆平，团队成员只能在其中零零散散学到一些经验，但是能力提升非常缓慢。导致B的项目，经常会出现救火的场面。其实B也非常清楚A的个人能力，同时聊天后，B更加敬佩A的管理能力。但是，后来B并没有向A学习-去发展团队成员的能力，反而在多次观察后，得到这个升职加薪锦囊妙计——“有困难，马上上；没有困难，创造困难也要上”

如果你是管理者，在知道以上A和B的故事后，再给你一个机会，重新选择晋升的人员，你还会选择B晋升吗？

此刻你应该已经有了答案，你会毫不犹豫选择晋升A。甚至你都已经想好怎么安慰和引导落选的B了。你会借助这个机会，先向B普及团队的意义，从一线经理开始引导集体学习文化的氛围。借助这件事可以额外播种下团队意识和持续学习的种子。对企业来讲，这是个长期主义行为。在案例分析中，你可以找到标准答案。

然而，在现实中，当同样的case落到自己的头上时，大多数管理者说不定还是会选晋升像B一样的下属。

到底发生了什么问题呢？

其实小编认为主要归结于管理者的心理安全。人类在进化过程中，我们一直都有着某种基因，促使我们相信“眼见为实，耳听为虚”，即可看见，可触及的东西才让我们有足足的安全感，才会得到我们的信任。

治未病，提拔A，他们做的事情都是我们看不见，摸不着的东西。

治末病，提拔B，他们做的事情都是我们看得见，摸得着的东西。

之前听到一个IT行业的敏捷教练在线下论坛中分享过一个敏捷团队绩效衡量的故事。他们公司开始尝试按照Scrum方式运行项目。前期整个Scrum Team还是可以按照框架正常运行，主要绩效考核还是每个Sprint的输出的价值。慢慢地，当Scrum团队运行越来越平顺之后，团队效率得到明显的提升后。此时管理者开始一步步增加Scrum团队个人的绩效考核指标：比如故事点的完成率，bug的数量，代码重复率，个人周报……一套又一套的KPI组合拳下来，最终敏捷教练离职了！团队成员陆陆续续也离职了！公司好像又回到了Scrum之前的工作模式，但是业绩衡量标准却开始使用Scrum运行顺利时的指标！！！

关于绩效管理的故事随便都可以抓出一大把。绩效衡量的关键点，还是要看你是站在哪个视角去衡量。作为管理者，我们还是要着眼于“治未病”的思想，虽然会引起短暂“看不见”此类安全缺失的不适，但是我们要看见长期的持续收益。这不仅仅是客户的体验，还包括整个公司的文化氛围的正确引导，增强员工的归属感。

从设备工程师和制造业RD的角度，小编想分享关于未病和末病的绩效考核思路。

1. 设备维护工程师会根据设备的数量来安排对应人数VS IT行业运维人数？
2. 设备连续无故障运行时间 VS 衡量IT软件无Bug运行时间？
3. 设备技改技革VS IT软件自动化？
4. 设备修复时间 VS 软件故障响应时间？
5. 设备故障率 VS 系统稳定性和可用性？
6. 设备预防性维保 VS 客户满意度？

……

原文链接： http://mp.weixin.qq.com/s?__biz=Mzg2NzcyOTQ3OQ==&mid=2247484269&idx=1&sn=7509765dcaeba68da7851d7c2733e005&chksm=ceb66a45f9c1e353b81422ea785db4092c726c533173d9f8de3e2e69dc31f1aee5a96ab8ba6a#rd