裁掉一个 35 的业务测试 ， 还是一个线上不会出问题的那种， 不是领导不行就是公司不行，眼界太低

你也有 35 岁的时候。。

我觉得这个帖子很有意义。因为大家都会有 35+ 的一天，但不是所有人都能成为决定他人命运的领导者，所以采访一下身为管理者的真实想法，作为参考很有必要。究竟是卷还是躺，跟什么样的领导干活去什么样的公司，希望这个帖子能多多地讨论。

测试唉，基本没有线上事故，这还不称职？换个技术好的，搞几个线上事故？技术能带来多少效率提升？线上没事故这才是真本事

如果都是产品发现的，说明这些都是产品文档上列出的：这种漏洞一般不太应该。
建议理解产品文档时，将各个规则、细则通过思维导图等等一一标记出来，测试时一一核对。
当然态度决定一切，以后继续努力

你跟前端开发联合，跟领导层反馈，前端人手不够，得加人。

本职工作干的号不就行了，咋还要求这要求那的？
人家本来就是一个点工，你非要他在一年内成为一个优秀的测试开发？
那你为啥不招个测试开发或者找个好苗子去培养的？

我觉得对于年纪大的老员工，评判他的工作要看他本职工作是否努力完成了，以及平常工作态度。
当然，我最讨厌的是那种要技术没技术要业务能力没业务能力，就仗着自己是老员工就各种摸鱼偷懒的人。

给我的第一感觉：你是来寻求处理方式还是自我安慰的？
第一种，如果一个测试能保证职责范围内无问题出现、善于沟通、经于业务，有什么不足的呢？你说 kpi 你说技术提升，请问他的岗位需要做这些事吗？如果需要他去进行此类工作，那 ta 确实复合你说的能力不足，如果不需要，那这所谓的 kpi 就是依托答辩
第二种，感谢你在杀猪前还有一丝自我愧疚并来此寻求一丝自我安慰后才下刀

个人感觉是管理者对其定位问题，看描述这个老员工是能较好的完成手工测试任务，那就给他定位就是手工测试人员啊。定位为手工测试就拿手工测试工资，布置手工测试活。

为啥要裁掉这个老兵, 个人觉得凭业务很熟和基本没有线上事故在公司完全能混吧, 哪怕转岗转成产品或培训讲师都完全可以.
啥情况上面几个就要把别人优化掉

这个问题的本质，还是要回到 “竞争力” 这个话题上：
1、站在公司利益角度：考虑这个人是否 “物美价廉”？替换成本是多少，是否有优化空间？如果有，一旦公司有强制裁员的名额或者强调降本增效的汰换，那么老点工很容易出现在名单上。
2、站在团队管理角度：老点工的输出能够在团队年度汇报 PPT 上有百分多少的篇幅贡献？质量团队既有业务质量保障的目标（红线），也有技术提效的目标（亮点）。团队能因为老点工拿到高绩效，老点工就能拿到高绩效，反之同样成立。再从管理四象限模型来分析，案例明显是处于 “低能力、低意愿（始终达不成目标）” 的象限，面临的管理动作是 “汰换”
3、站在人力管理角度：晋升、调薪，都是 for 未来，而不是 for 过去；你晋升之后能做到什么，给你晋升能激发什么，你的潜力有多少？能够为团队为公司带来什么价值？

以下是个人看法~

看公司情况，业务稳定非技术导向的公司：
年度晋升/调薪酌情考虑，不优先考虑
年底绩效的考核扣除技术提升这一部分，其他该优秀就优秀
裁员不优先考虑，需要干重活又拿得不多的。先裁拿得多的，再裁不干活的。

需要奋斗偏技术的公司：
保不准马上就要被优化走

我觉得这个很简单吧，就看岗位职责呀，人家能力可以承担现有工作，就可以了呀，技术提不提升那是人家自己的事情呀。当然裁员的时候要另外看了，毕竟裁员都想以最小成本 留下最合适的人

你手下的强将，能按质按量的完成任务，为什么要考虑裁掉他，换一个业务不熟的来来接替么，如果这样出的线上事故是不是你来承担？

说明这名员工就属于有能力没潜力的类型，这样的员工是否去留主要考虑 2 个方面
1.组织的发展阶段，如果现在组织还在扩展阶段，需要应对当前业务需求压力比较大，人员不够，那就还是留，同时尽量引导，威逼利诱让他进步。
2.如果公司当前处于稳定期，业务压力不算很大，组织可以考虑优化，就结合团队成员画像，综合比较团队人员能力，如果综合来看他处于中下游，那就轮换。
作为管理者你的第一原则是要保证你的团队是不断进步，保持战斗力。所以永远去找那些能力处理当前团队中上的人员，让无法适应发展的人员有更好的去处。

管理是横向比较的，个例很难评估

正解

你提了吧？提了。
你催了吗？催了。
有证据吗？有。
好的，下一位，跟你没关系了，那个前端，来我办公室喝喝茶，咱们来探讨下你工作的排期。

说实话这种开发还是比较少的，碰到了该怼就怼，不要怂，代码是你写的，我只是帮你把 BUG 找出来，你不谢谢我就算了，还不耐烦？线上出了问题谁负责，要学会转移矛盾，让产品和他去扯，让 PMO 和开发 leader 和他去扯，有事尽量在群里说，不要私聊，让大家他看看是什么嘴脸。

看你们公司流程，如果是严重有影响系统的及时沟通挺合理的，遇到这种艮的开发就上报。不严重的 bug 提交系统等修复完验收就行了，有啥流程就跟着走，觉得有好的意见提就行了。

楼上说的对，漏侧不可避免。
记得追加测试用例，扩充测试用例库。

你不要心虚，感觉楼主还是刚入职的新人一样。是你工作范围内的，该提的 bug 就提，提完之后如果有类似的 bug 管理平台，研发改状态了就验收回归，没改你就不管，到时候根据 bug 的遗留数量和验证程度来出报告，是不合格就直接测试不通过，自然会有研发的负责人或者产品问具体是什么情况导致的测试不通过。项目延期啊，线上出 bug 这类跟你都无关，你按照流程来正常工作就行。对方态度不好，你态度就公事公办。所有不给好脸色的同事我都不惯着。

看领导，领导偏他你离职（除非不提 bug 也发工资），领导正常继续提。

我个人觉得用例设计是需要一定的思考，不然容易设计不全。慢慢来吧

产品能发现的漏测说明是主流程上问题，或者是比较容易发现的问题。由于是新手，还是多积累经验，多想多测吧~~不要气馁