新进来的组员，资历非常深，工作十几年的老工程师。本来是其他组的，后来领导说归到我的组。然后让我当他的导师，试用期的绩效由我给他制定目标和评分。
这几天遇到一个问题，问题出现得比较突然，该组员确实没有机会提前识别到该问题。然后领导让我跟他一起看，复现问题后第一时间我们都有了各自的判断，他认为是系统的问题，而我认为是我们的应用导致系统出现了问题。当即按照我的思路进行了浮现，确认就是我们应用导致系统出的问题。
本来也没什么，恰好月底绩效流程走到我这里，我就顺手写了一个“能够按照要求完成相关开发任务，但对问题的钻研程度有待提升”的评价，这个评价不影响他转正（转正靠的是打分，而我都是给他打了不错的分数），后来该组员就找到我，认为我的这个评价有问题,当场表示他很生气。
一时间我有点懵逼，当即表示这个并不是说你不好，只是我的一个主观判断，而且不会影响转正。况且我的行事风格就是这样，说点好的一般也回带点不好的。一番沟通下来，该组员似乎“接受”了这个评价。
下来我自己想了想，一直反思自己做得到底对不对，各位 V 友怎么看
第 1 条附言 · 1 小时 32 分钟前
反思∶
1.确实需要学会掌握说话的技巧，任何表达都应委婉一点。
2.理解并尊重每个人对问题的不同看法，切忌一切以结果为导向。
想了想，我平常也没怎么跟组员进行沟通，他的专业领域我也没什么发言权。如果平常多沟通交流，关系搞好一点就压根不会发生这个问题了，这是我作为组长没有做好的地方，这点非常不好，确实要跟组员打成一片才能更好地开展工作。
打算节后开个小组会议，公开跟该组员道个歉;平常多跟组员们交流，争取打成一片。
1.确实需要学会掌握说话的技巧，任何表达都应委婉一点。
2.理解并尊重每个人对问题的不同看法，切忌一切以结果为导向。
想了想，我平常也没怎么跟组员进行沟通，他的专业领域我也没什么发言权。如果平常多沟通交流，关系搞好一点就压根不会发生这个问题了，这是我作为组长没有做好的地方，这点非常不好，确实要跟组员打成一片才能更好地开展工作。
打算节后开个小组会议，公开跟该组员道个歉;平常多跟组员们交流，争取打成一片。
 |
1
defunct9 13 小时 52 分钟前
问就是他不对
|
 |
2
brave6 13 小时 50 分钟前  7
不建议反思，委婉一点表达即可 "能够按照要求完成相关开发任务，在问题研究方面，如果能投入更多精力进行更深层次的探索，相信能够取达到更高的高度。"
|
 |
3
FranzKafka95 OP @brave6 感谢答复，这里我确实是该用委婉一点的语气。可能技术做久了，表达能力上有所欠缺。
|
 |
4
wintersun 13 小时 43 分钟前
反思就是：当众表扬，私下建设性批评（如 @brave6 所写），大家都开心。
如果一个人屡教不改，建设性批评无效，则私下里再来一次深刻长谈，彻底发现不合适，则和平分手，他去他适合的公司和团队。 |
 |
5
xmdbb 13 小时 42 分钟前 1
这个问题之前也困扰过我，其实归根到底核心原因和能力不一定挂钩，但是和对现在公司系统/业务熟悉度有关。
他的判断是基于他目前对公司系统和应用熟悉不如你，所以给出了一个这样的判断。 其实这行干久了就发现，很多东西无法盖棺定论，总有意想不到的意外，所以判断有了偏离不大即可，自己去复现一步步找出问题根源所在，有些时候甚至预判几次都是错的，我反而觉得没啥。 至于绩效这里，想问一句如果你知道他是你领导的亲戚，你也一样会这样写吗？如果是的话那没啥，如果不是的话那就不是比较直的问题了。 说了好的，也说了不好的，分数给高，说白了意思就是有可能会有问题也有可能没问题，目前跟着我处理没问题。 纯属自己瞎猜，OP 不喜勿喷 |
 |
6
wei2629 13 小时 35 分钟前 2
我觉得单次不能说明什么。很多问题都是根据系统特定存在的，了解环境就是最大的优势。根据一次表现就下论断是不是太武断了。
|
 |
7
bestie 13 小时 32 分钟前 9
在我当组长的第一年，领导让我给组员写评价，我那时确实就是楼主的想法，优点和待提升点都写（待提升点不是什么很差的评价，类似于需要加强细节把控之类的），然后有个组员也在之后单独找我，问我给他的评价是什么意思，搞得我也很尴尬。
后来领导再让我写评价我就懂了，反正这个评价也没有什么实质性的影响，我直接让组员自己写好发给我，我略微调整下就发给领导了，组员领导都满意。 |
 |
8
512357301 13 小时 32 分钟前 via Android
“能够按照要求完成相关开发任务，但对问题的钻研程度有待提升”
你这评语本身就很无理，因为理论上，你的组员是一直无法超过你的，真的有一天超过了，你也该走了。然后他和他的手下重复着这个循环。 这个评语本身比较中性，但仔细回想一下，手下确实会受限于掌握的资源不如自己、对公司的方针政策了解不如自己而想的没那么全面。 |
|
9
FranzKafka95 OP @wintersun 这里提到是流程上面的评价，不分什么当众和私下，这个流程说白了就只有少数几个人参与。问题核心在这里∶我认为“对问题的钻研程度有待提升”算不上一个批评，应该算是勉励或者说激励，但是该组员可能会觉得有问题。而且公司的这个流程上写明了要写优点与不足，当然也可以不写不足，不过我恰好那天跟他解决一个问题，当时觉得他处理问题确实有问题的，所以就带上了这么一句。
反思下来，我跟该组员确实交流比较少，仅仅通过一个问题去写这样的评价确实有失偏颇，算是给自己长个记性了。 |
 |
11
Pookylol 13 小时 27 分钟前
“有待提升”略微有点重，比较敏感的就会具体问一下。不过，既然他知道了你的评价，他来询问“有待提升”的具体含义也是正常的，也不需要反思什么，告诉他预期应该怎样
|
|
12
FranzKafka95 OP @bestie 唉，你说的很有道理。主要是我平常汇报工作，包括给自己做总结都是写好的也会写不好的，所以给他人做评价也会习惯性这样做。现在想来，让组员自己给自己写也不失为一个好办法。
|
|
13
FranzKafka95 OP @Pookylol 他不是来询问，他认为这个是批评，是对他十几年专业经验的不认可。但我的本意真不是这样，就遇到的问题而言，我是希望他不要过早的下结论，作为功能 owner 一定要进行调查以后再下判断。出现问题时，他的反应是“这个问题是系统导致的，我们搞不定”，我觉得这个是不合理的。
|
|
14
FranzKafka95 OP @wei2629 嗯嗯，道理是这样的，但是当时这个评价中不好的部分是出于我的思维惯式∶写点好的也带点不好的;再加上公司流程上要让我们“写”，凑巧那天也跟他一起排查问题，对待问题的态度差异这几个因素综合在一起才导致我写了这么一个评价。我并不是不认可他的工作能力，前面也提了打分都是给了不错的分数。
|
|
15
FranzKafka95 OP @512357301 “你的组员是一直无法超过你的”这个说法我并不认可，一个人的能力分很多种，技术力只是其中一种，况且每个技术人员都是术业有专攻，如果不是某个细分领域内的同一从业人员，你也是不好评价技术能力的。虽然我作为组长，但是我自认为在很多专业领域上我是不如这位组员的，这里的核心还是在于我跟该组员对于这句评价的理解存在差异。
|
 |
16
520discuz 12 小时 39 分钟前
有待提升=直接否定其能力，稍微有点玻璃心的人看了都会生气。。。
|
 |
17
xiaomoxian 12 小时 30 分钟前
首先你的评价有点宽泛 容易误解
以后可以分两部分，先就项目、问题做出评价，其他的你怎么写都行了 谁也跳不出来毛病 |
 |
18
kkkbbb 12 小时 23 分钟前
这东西本来就是挺主观的，而且谁也不可能针对每件事情方方面面都考虑那么周全，但是你还能自我反思，这挺不容易的还。
|
 |
19
chairuosen 12 小时 18 分钟前 1
他有什么可提升的呢？由于对系统不熟悉所以没有一次判断对问题原因？你以为招了个上帝来么，全知全能。
|
|
20
chairuosen 12 小时 15 分钟前
这就像面试出一道 hard 算法题，面试者没答上来，你会，你就给了个评价：算法能力有待提升。
|
 |
21
billlee 12 小时 15 分钟前
这也太玻璃心了
|
 |
22
frankilla 11 小时 59 分钟前
 有待提升钻牛角尖的话确实有点重了，有点否定的感觉。折中呗。 |
 |
23
thorby 11 小时 51 分钟前 via iPhone
除了销售，一般岗位心理比较少面对挫败。他要是内心强大，越挫越前进，那就是你老板了。
|
 |
24
zixianlaiye 11 小时 33 分钟前 2
看到了吧，干了十几年没当成小组长或者更大领导的人，被别人评价的时候，老脸挂不住
工作十几年，要么单干，要么靠被动收入，在职场做一线，不一定能受得了这种恶心 |
 |
25
coderluan 11 小时 17 分钟前
对方不是玻璃心，而是情商低。
程序员在意楼主这种批评很正常，感觉不认可，完全可以找对方要个解释，对方又没给你打低分，所以解释很容易，什么事也不会有。但是他“认为我的这个评价有问题,当场表示他很生气”，如果楼主和他一样心态，说不定就上头直接吵起来了吗，造成完全没必要发生的争执。 |
 |
26
beneo 10 小时 33 分钟前 1
我觉得 1-25 楼都没有 get 到点
1. 这种资历高的人，进入你这个初级管理者的队伍，你首先要做的事情是请领导吃饭（中午工作餐就可以了），充分领会领导的真实意图（是不是要搞这个人走啊），同时借此机会了解这位员工的工作风格和性格特点（是不是有点能力，但是没啥情商），要确认这个人是不是大动脉等 2. 你带的队伍的目的是出成绩，团队建设和文化建设是手段。如果这个人不是大动脉，能力不顶级又不听话还一身反骨，资历深，没有眼力劲（说白了你给他发工资啊），刚愎自用，居功自傲的人，是典型的内耗型员工，除非你爱好沟通，喜欢玩弄人心，否则赶走这种内耗型的员工没什么不好的，与其花精力去哄着、磨合，不如带着和你一条心的兄弟加班向前冲 3. 永远记得你的目标是什么，多向上管理，帮你加班的兄弟多争取点 money ，当然，如果自省是达到目的的手段那就去做 |
 |
27
yogamaga 10 小时 0 分钟前
确实有应用导致系统出问题的问题吗，那系统是不是也需要做下容错
|
 |
28
iOCZS 9 小时 58 分钟前
他认为是系统的问题，那根据是什么？只要有理有据，即使结论不正确，我觉得问题不大。
能否因为一次判断失误，就下结论认为他是这样一个人呢？一而再，再而三这样的话，那的确是这样的人。 思维方式还是很重要的，写代码是比较看重 debug 的能力。 |
 |
29
smlcgx 9 小时 54 分钟前 via iPhone
炒菜的怕被说东西难吃，干技术的怕被说技术不行，还是 10 多年的老技术
|
 |
30
ChefIsAwesome 9 小时 49 分钟前
我觉得你作为管理者，对基本的人际关系处理有待提升。
|
 |
31
wen20 9 小时 31 分钟前
小家子气了。 因为不算大故障的事过去就过去了。 还写到纸上留下笔记。
你扪心自问， 有没有通过这种方式表现自己很牛？ 我的观点是： 错不在他。 |
 |
32
NealB 8 小时 29 分钟前
他认为是系统的问题，而我认为是我们的应用导致系统出现了问题。当即按照我的思路进行了浮现，确认就是我们应用导致系统出的问题。
1. 按照你的思路解决问题，就说明他的思考方式错了吗？ 2. 按照他的思路复现了吗？是不是你们系统的兼容性问题？ 想了解下你们公司的制度，十多年的程序员，进你的组，你当他的导师是需要你指导他什么吗？一般的公司导师都是给实习生配备的。 |
 |
33
airqj 8 小时 15 分钟前
新组员对项目不熟悉判断出错了不是很正常吗
LZ 这个结论太武断了  |
 |
34
vevlins 8 小时 8 分钟前
委婉一些好，尤其是绩效评价、转正这种，员工肯定不希望自己的评价上有任何明显负面的东西，万一认下了以后哪一天被翻出来作为裁员依据呢。
|
 |
35
NotLongNil 7 小时 39 分钟前 2
你这评价不够客观，从你描述看，完全看不出对方哪里“对问题的钻研程度有待提升”。你给对方的评价完全是不公正的。他没有任何问题，反而是你这个导师的工作做得很不尽责，居然是凭自己的喜好，来捏造事实。你应该跟对方道歉。而不是在这里扯什么思维惯式，给自己找借口。你的行事风格目前看来是：做事全凭自己喜好，掌握了一点权利就想打压别人，做错了事也没勇气承认。你是想来这里寻求安慰，好让自己心安理得吗？
|
 |
36
theguagua 6 小时 3 分钟前
@beneo 不认同第二点，仅凭一件事去判断一个员工就是所谓的“内耗型员工”，你比楼主更加武断。
新进组的组员没有项目经验不是很正常的事儿吗？“对问题的钻研程度有待提升”，实际上就是少了些经验罢了，何必写一句带有负面意味的评价，楼主不是更加刚愎自用？ 在职场里最好做一条泥鳅，这需要一点语言艺术，即使是下属，再小的笑面虎关键时候也能把你推进坑里。 |
 |
37
lijiangang886 3 小时 16 分钟前
|
 |
38
Vegetable 2 小时 22 分钟前
对于业务系统这种东西的理解认识，尤其是新人，很难体现出什么能力。虽然我不知道你们说的是什么问题，但所谓对问题的钻研程度这种评价过于宽泛，没什么意义，还有可能被人过度解读。
我这两年就在一线摆烂，反而把之前想不明白的事情想明白了一些。点评同事本来就是很主观的，建立在希望继续合作的前提下，这种向第三方评价对方的场景，应该侧重于描述事实、陈述自己认可的地方，也就是加分制。你对于同事带有负面评价的点评，必须能准确表述，进一步解释，而不是泛泛的写在考评表上。应该在尽可能小的范围内讨论，比如双方私下讨论、和上级汇报时非正式点评等，这种面谈能够把话说清楚，张三哪方面不错，哪方面有所欠缺，适合做什么，不适合做什么，这个谈才算是有意义。 |
|
39
FranzKafka95 OP @lijiangang886 不是求认同，我只是解释我心里的想法。事后我的反思确实是这样的，我确实做得不对，打算节后小组内公开这件事，公开道个歉。
|
|
40
FranzKafka95 OP @ChefIsAwesome 我自己不认为自己是个管理者，或者说我自己认为自己不适合做管理者，还是做技术纯粹一点。
|
|
41
FranzKafka95 OP @vevlins 确实，学会说话是门艺术，偏偏我们这些臭搞技术的都是比较直的人。
|
|
42
FranzKafka95 OP @yogamaga 这个要看如何界定，站在系统的角度，系统在进入各个状态前都会有相应状态广播给上层业务，是需要上层业务根据这些状态及时处理做相应的资源释放。这里的场景就是我们开发的业务没有考虑到系统的状态切换带来的影响，该问题非该组员的锅，前期需求和场景没有定义这一部分，只是开发跟测试过程中发现的。
其实到底是系统还是业务的锅也不重要，重要的是对待这个问题的态度，单单根据现象就下结论“是系统的问题”我认为太轻率，以至于我后面写了这么一个评价。 唉，当时我不知道这么一句评价可能会伤到组员的自尊。 |
|
43
FranzKafka95 OP @NotLongNil 接受批评。但是不存在什么打压不打压，因为转正看的是评分，评分我都给了不错的分数。这里的评价是只有这个流程参与者中的少数几个人能看到，非公开的，而且这个评价压根就没几个人正经会看。所以你可以把这个评价看成更多是“形式主义的”，当然如何理解“有待提升”的性质也是关键，有待提升也不是否定，是希望加强一点。
总之，站在我的角度我可以说我问心无愧，站在他的角度我也可以理解。 |
|
44
FranzKafka95 OP @NealB 导师就是快速帮新来的同事熟悉业务和开发流程，公司的日常这些，并非专业领域上的导师。在专业领域上我也压根不配做他导师，该组员十几年的老工程师，之前在前司是资深的专家。
这里不至于是系统的问题，因为我就是做系统的，他可以说是该业务领域的专家。系统上开发该业务的还有其他应用，同一场景下其他应用不会导致系统出问题，因为其他应用有正常处理，而我们自己开发的就没有。 其实这里都扯远了，这个不是核心。 |
Select Language