评价事而不是人

我们常说对事不对人,但是在日常工作沟通中,或者一对一沟通中,我们有时会有意或无意的说,我觉得你这有这方面的问题、怎样不好,我觉得你过于内向等等针对一个人的评价。我们的出发点是为了解决问题,为了让每个人把事情做得更好,对于大部分人来说,这样的沟通可能没有太大问题。

但是,由于生长环境的不同,个人的经历、阅历的不同,每个人的性格特点也不同,在遇到问题、面对挫折时的反应和应对方式往往差异很大。

对于性格比较感性,遇事比较敏感,猜忌心里比较强,比较自负,内心不太成熟,或者心态有问题等等类型的人,如果你直接指出他有什么问题,特别是评价说你觉得他是一个什么样的人时,通常得到的效果都不会太好。在沟通现场不一定能发现什么问题,因为员工可能不想表达或不敢表达,但是这位员工内心对你的印象可能因此而发生了改变,内心已经种下了不满的种子。

通常来说,评价一个人是什么样的人,是偏主观的判断,可能比较片面。
另一方面,对于负面的评价,每个人多多少少都会有一点难受,特别是在当这个评价和自己对自己的评价、或者过往别人对自己的评价差异较大时。

所以,在与员工沟通时,应尽可能的避开对人的直接评价。

更好的方式,我认为是评价事情,而不是评价人。是沟通讨论一件事情哪里做得好、哪里可以改进,而不是指出一个人有什么优点或缺点。对于是否应该评价一个人的优点或缺点,这一点可能大家不一定认可,因为这样的沟通有时带来的效果还不错。

接下来,列举一些例子大家一起来感受一下,自己做一些对比和判断。

例子1:我觉得你的脾气太倔了,每次谈需求时,都会跟产品同事在某个点上纠缠很久。(员工想:你不是要让我们多提建议吗?以后不提了)

建议表达方式:前天在个人中心优化需求会议上,针对用户名是否允许使用字母问题,当时你对个人立场的坚持,对这个需求的评审带来了比较大的影响,导致最后需求改期了。(员工想:当时的确有点激动了)

例子2:我发现你做事有点激进,经常引入新技术、使用一些新方案,导致系统很不稳定。(员工想:带来的好处怎么不提,全盘否定我?)

建议表达方式:上周的排行榜需求,上线后发现有内存泄漏问题,经过排查发现根因是引入了一个不太成熟的缓存组件。我们项目原来已经使用了一个缓存组件,也比较稳定,正常情况使用它就好了。如果已有的缓存组件满足不了要求,或者想尝试其他组件对比效果,也没有问题。但是正式引入之前,一方面需要调研确认新的组件足够成熟、社区维护比较到位、有很多公司在使用了,另一方面需要在团队内部做一次技术评审,并且经过充分测试之后再上线,这样上线后更加稳定可靠。(员工想:这次新组件的引入,的确调研不太充足,而且新方案过于复杂,自己有点激进了)

例子3:我觉得你是一个比较有想法的人,经常提出一些有建设性的建议,对产品也会有一些好的想法。(员工想:原来我是一个这么有想法的人,我自己都没有发现,但是我好像也就提过2、3次的建议)

建议表达方式:月初你建议团队可以组织一些技术分享,以提高团队的技术氛围,这个建议挺好的,最近落地效果也不错。还有,昨天你对产品在UI上的优化建议也挺好的,我们整个团队规模还比较小,大家能给产品提建议、共创,是我们当前阶段所需要的氛围。(员工想:Leader对技术氛围比较重视、也关注产品,同时能够吸取建议,这是我比较认可的领导,以后我会多提一些建议)

以上例子,有一些共同点。

原来的表达方式比较笼统,员工不知道你具体是因为哪几件事情而作出了判断,互相之间的信息差会比较大,你认为的和他认为的往往不是同一个回事。同时,直接评价一个人,相当于给员工加上了一个人设或者一个标签,他就是这样一个人了、一直都是,这个设定带有比较强的主观性,比较片面,也没有看到人是会变化的。

而建议的表达方式,从客观事件出发,针对已经发生的事情做讨论,针对这件事情的结果来评价一个人。注意,这个评价只是针对该事件,或者发生该事件的那个阶段。一方面表达的内容更加明确,有针对性,双方容易沟通清楚并达成一致。另一方面,不给员工加人设,也避免因几件事情而对一个人造成了片面的评价。毕竟,人是会变化的,社会是会发展的,今天这件事情做好了,不代表改天另一件事情一定做得同样好。

这一点,其实也是在做绩效评估的时候应该采用的、相对比较客观的评价方式。对于团队的成员来说,我们应该对比的,是在同一个阶段内,谁在哪些事情上表现得如何。而不是拿一个阶段、几件事情的表现,来评价员工一直都是这种表现,以后一直都是这样一个人,这样对于员工来说是不公平的。


---转载本站文章请注明作者和出处 二进制之路(binarylife.icu),请勿用于任何商业用途---

留下评论