遇到这样的员工你会怎样处理？？

learn

她来面试的时候，说得非常好，尽最大努力来认真做好测试工作，且对部门能够提出一些创新观念，给部门注入新鲜血液，等等。。。（以前工作也是做测试）

        来上班不久，我就发现她做的和说的不一致，平时看着很努力，其实脑子里不知道在想些什么，例如：书写某个功能的case，她会花去好久，看着也在思考，但就是写出的case根本没有多少内容，就是按照case根本无法执行，写的操作不详细，且预期结果也不明确。我找她谈过，她的理由是写case需要去方方面面思考，这点我也无话可说，是应该从不同角度去考虑，但我更需要考虑的结果，总是花去很多时间去思考，到头来没有写出什么好东东。且这样的事情多次出现，也多次找她谈，每次都是一堆理由，被说服完，结果都是下次一定好好写。但经常仍然出现这样情况。

        后来由于项目事情着急需要加班，她拒绝加班，如果加班就要涨工资，由于法律上不能强迫加班，后来考虑已经培养好久了，就给涨了工资，但加班还是不乐意，但实际上后来也没有进行加几次班。

       当时考虑过把她辞掉，但又想想培养一个员工也不容易，一个员工挣钱也不容易，最后还是想给她改正的机会。

        近来她越来越不象话了，一个任务单测试通过4-5次还是出现问题，且每一次都是到用户使用发现的问题，就是说用户已经反馈问题4-5次了，由于我近期都不在公司，其他领导找她谈，说又是测试总会有遗漏的，不可能一下想的很全面。关键是其他领导告诉我出现的问题都是功能之内的，根本谈不上是关联或者深挖掘的问题。要求她进行快速解决此问题，答复是等明天再搞。我无言了。关键是现在她怀孕了，也没法给她辞退。

        对于这样一个没有责任心的员工，我想现在只有通过经济惩罚她了，但惩罚的标准该如何制定？

        同行的朋友，请发表你们的见解帮助我吧！期待你们有更好的解决方法！多谢啦！！！

archonwang

一件归一件。

1. 工作责任心的问题，首先赏罚明确么？如果发现存在问题，就应该仔细规划测试工程师的工作范围和权利；其次，工作时不能考虑任何借口，任何人只需要回答的语句只有这几句话中的一句：是！不是！可以！不可以！不知道！如果同事给你的托辞你可以接受，就应该考虑为什么可以接受。而不是他提供了多少可以逃避工作的理由；

2. 关于出现问题，需要培养员工具备对应的及时反馈的习惯，如果没有，只能说是管理上的失败。如果是做了，但是都没有遵循，再考虑是不是制定的是否合理，具备检查性。

3. 最无奈的办法才是辞退。如果员工认为工作不适合自己了，那直接给她建议离开现在的岗位，换岗。

4. IT项目加班可能是常事，这点需要人事部门提供一定的补偿，否则的话劳动法上说不过去。这点还是很佩服外企的做法，直接给加班工资。^_^"

5. 关于测试的漏洞问题，这个问题分析起来就比较复杂了。测试案例存在漏洞会导致这个问题，但是可能是缺乏案例审核的过程，所以会发现这些问题也就不足为奇了。测试工作的复杂性可能远比开发来得更大些，所以需要良好的管控方法和机制来进行控制和改进。另外一种情况是，是否在需求或设计中明确提及了对应的内容。如果有，还是发现案例写得不完整，存在漏洞，则可能的理由如下：1. 相关的基础文档没有很好的跟进更新，导致测试案例一直都不更新；这点是绝对错误的，我和同事们常说的一句话就是文档就是拿来修改的可以参考使用；2. 需求中对测试的内容的划分模糊，这是很容易导致测试漏项的重要原因。由于测试人员的水平和对业务理解的深度，最好可以在每次测试新功能前进行培训，让其深入理解需求和设计及业务情况。在我实践的内容里面，这样的效果是最好的。

6. 关于测试案例编写的问题，这个就比较容易了。写案例是需要花费时间的，那么关键的问题是你给她提供的是什么标准，写完之后是否仔细审查。我在项目中每份案例文档都必须经过审查才可以投入使用，否则宁可不提交处理；另外一个问题是，如果你给了明确的修订说明她没有做，这就是工作态度的问题。案例设计时发现了设计漏洞，需要主管提供对应的支持，要求进行纠正的不一定是测试文档，可能还包含了需求和设计。

我不清楚楼主让你的弟子写了多少次案例，楼主自己检查了多少次，如果发现每次检查的结果都是案例编写存在漏洞或不标准，就应该给他们提供具体的标准，必要的话需要提供正规培训，以适应工作需要。

7. 关于加薪的问题。加薪时为什么要考虑加班的问题？加班是加班，那时额外工作的补助，加薪则是对工作的肯定才作出的；两者根本不能一概而论。

题外话，关于怀孕了的问题——如果你的同事处于这个position并且正好有这个情况，从主管角度考虑，应该主动减轻她的工作，把她的一部分工作转交给其他同事或自己处理。

learn

首先非常感谢版主!我将针对你的7点一一给出答案
1、我部门目前只有赏没有罚，因为我总觉得她们都很辛苦，很认真，觉得挣钱不容易，真的偶然出现问题，都没有惩罚过，但该领的奖金一分不少给她们，其实部门的其他人员真的都做的挺好，唯独她不行，所以现在我体会到没有罚是不行的，我体谅她们，但她不能体谅我。所以现在我要做些惩罚措施。至于她的借口，我在公司每次我都对她谈的很清楚，测试就是“质量”，其他任何理由都不能成为降低质量的理由。后来她有所收敛，但最近听说又很放肆了。
2、员工的信息反馈有要求也可执行，近期都是反馈给我委托的一个人，但执行的不好。（注：我近几个月都不在公司工作，在休假中）
3、你说得太对了，当初我休假前，真的很无奈，领导也和她沟通过，但结果也不太好，也建议我给她辞掉，最后我还是决定再给她机会。
4、忘记说了，我们部门是直接给加班工资的。
5、你说得很对，就是case没有经过审核就直接用了。我们大部分的工作不是在做项目，而是做公司产品卖出后进行的修改，所以修改的内容一般都是非常明确的，都是用户提出的，单子一般很小，半天到一天都能测试完毕。所以不存在你说的case更新，文档的跟进，因为前期的需求，设计都是经过开发、测试和支持人员讨论的，并经过签字认可的。对于业务理解应该可以排除，她来了有一年多了，对公司产品的业务还可以。
6、有书写用例的标准，且标准也是经过测试人员等确认的，针对她的用例，我找她谈不止5次，她每次都认识到自己的错误，但就是不能长期真正改正，当时还好，过了一段时间又老毛病重犯。由于我们来了一个小任务单都需要写用例，所以弟子写的用例不计其数，因为都比较小的功能。由于任务单很多，我没有每一个都检查，只能是抽查，每次抽查结果其他人都很好，唯独她的经常出问题，当然后来就重点检查她写的，她居然有一次说我好像盯着她工作，我觉得可笑又好气，我就告诉她为什么检查她的比较多的原因。对于用例培训，入职时培训了，且我们会定期的讨论怎样书写更好的用例。
7、关于加薪的问题，现在我都觉得加的不是时候，因为本来我已经和老总说了给部门员工适当加薪，正好她又提出这个问题，加薪好像就变成她威胁加的， 其实不是，我觉得员工一年了，应该给予肯定，适当的加薪。

关于题外话，由于我在休假，我已经给委托的人说了给减少工作，且也确实减少了，测试一个单子别人用半天时间，给她延长时间，留出时间给她休息。但事情还是做的很糟糕。

真的再次感谢你！过段时间就要上班了，现在正在制定惩罚标准，希望版主能给点惩罚标准的意见。以前没制定过。只有项目奖金， 心太软有时真的害己

板砖

按Bug数量和百分比进行扣钱.

扣几次后她自己就努力了.

gwell

我也是，以前一直老是觉得做领导的就会板起脸孔对人，现在自己做管理了，想以德服人，真是像LZ说的，自己体谅别人，别人不鸟你啊。像我有时安排工作，咨询他们的意见，他们居然明目张胆把工作量最大的分给我，还附带说辛苦了。而且人就是这样，自己不硬，别人就硬起来了。…………

learn

我觉得即使他把工作量大的分给你，你也不能接，不是不想去做，是我们没有太多的时间去做，我现在真正感觉到，既然管理，就好好进行管理，少做测试工作，多去检查审核，制定一些标准，措施，完善部门流程等等，把你不接的原因告诉他们，他们肯定也能理解，下次就不会这样了，不自觉的人会一步一步试水

null2

当初就该。。 开除她

xyxykitty

不负责任的人不适合做测试的哟

52enjoy

同意楼上说的观点，管理体谅下属但是下属却不能很好的执行应该分配给的任务，反而说你针对她，实在让人头大。
另外 learn能不能把你的奖惩制度分享下？QQ:3354631

learn

你好！现在正在准备写惩罚制度，还不知该怎么写呢。奖赏制度是公司规定的，我一直执行的很好哈哈。。。，就是项目组内，奖金20％给测试人员，40％给开发人员，20％给技术支持人员，剩下20％由项目经理进行支配给功劳最大的员工，呵呵，这是公司定出来的。但现在我认为部门内最好也要搞点奖赏，这样可以调动员工的积极性。对于惩罚制度，有好的意见写出来，给我参考参考

jy00274486

我这也有这类人 感觉这类人女性比较大 而且都是为母的多  让她做点事都不做 还指望我去教

yangtesting

我们公司处理这种人就是给一次机会，不行的话就往最累最低的部门转，工资下调。原因就是能力不足，说白了就是下放改造去，一般的人是自己辞职，下调多没面子啊。

polestark

我看完了，基本上如果在沟通上行不通，可以采取一些特殊的方法：
具体到你分配的任务去，跟她沟通一个很详细的标准，如果一个周期完不成或者达不到要求，警告一次，2次不行，再给一个机会，实在不行辞退。
我觉得这其实是工作态度的问题，不行开掉。在一个项目中，20%super star, 50%normal, 30%中的一部分就是需要开掉的，这样会影响团队的氛围的。前提是你必须有一个很明确的衡量标准，保证大家是一致和相对的公平

archonwang

看了你的回复，大概明白了问题所在。她的情况对企业来说，对这个产品而言不是不可替代的，建议还是找个合适的机会劝退吧——如果今后的工作没有任何改善的话。工作首先是态度的问题，而不是优先考虑他的能力有多强。

我个人认为PolesTark的建议值得参考，一次不行，沟通，二次不行警告，三次不行，沟通再给次机会，再不行，辞退。

有时候做管理工作，需要多为整个Team里的成员想想，而不是仅为了其中的一个员工。我可以理解身为一个待产母亲的心态——之前我的Team里也有类似的情况，但不赞同这种工作态度。希望你的那位Team Member可以有所改善。

learn

非常感谢大家!我会参考你们的建议进行妥善处理的,再次感谢大家!

lin85210

公司最怕用错人 。。看到公司里吃闲饭而又 不少拿工资的人 我就觉得恶心。。。。

现在公司都有这种人存在，他们起的作用不是白领了公司的钱，而是更大程度上影响了其他辛苦工作的同事的心情。。。 鄙视这些人

polestark

楼上的，心态放的平和一点。哪个公司估计都有这样的人，也许在你看来这样的人还不如炒掉，但也许在领导的眼中还是有作用的，比如可能是润滑剂或者就是让你们这样的人鄙视的。。

lin85210

就象地球的蛆，无法消除掉，因它们代表一个种类。。。

vanceinfo

做测试有些日子了，对于楼主遇到的问题，有些想法。
1.对于楼主说的，那个女孩负责测试的功能范围，经常会被客户发现功能上的问题
---测试用例设计，通常是按照软件的需求说明书来设计对应的测试用例，这样来达到对测试需求的完全覆盖；
---测试用例执行，在拿到软件测试版本后，对于测试功能点发生变化的地方要进行修改（需求变更了），继续保持对需求的完全覆盖。测试用例执行结果我们用TD来记录执行结果和测试缺陷
---回归测试，这个看测试时间是否允许。缺陷的回归和测试用例的回归
2.女孩说测试需要考虑这样的那样的方方面面
---这个说法完全同意，但是需要由可以用的测试时间来决定。测试基本要求是，就是要对软件的系统的功能点覆盖，Yes Or No 的问题，测试用例的期望结果明确写出来。比如说，一个提交按钮的测试用例。简单用例就是 点击按钮，出现什么样的结果
---在这个基础上再来考虑方方面面的测试。仍然是一个提交按钮的用例，连续点击这个按钮N次，看出现什么样的结果。
3.楼主说，面试时女孩给你感觉很好。
---对于项目组的新成员，我的做法是，不管你的以往经历多么辉煌，对于这个新成员的测试用例，都会定期抽查，看设计的测试用例质量。（这个时间是值得花费的，也可以让小组的Leader来完成这个事情）；前提是测试团队要有一个统一的测试规范，如测试用例设计，测试缺陷描写等。
4.楼主说几次沟通未果
---最难的就是团队之间的沟通了，PMP说沟通会占用PM的85%以上的时间。本人很是同意这个说法。
5.赏罚分明
---赏/罚，对于测试来说，个人认为不容易判断。发现的缺陷数量，也许是测试人员负责的那个模块确实就是很少，但是实际上我们的测试人员是非常负责的在测试呢；测试用例设计效率，这个倒是可以作为一个参考值，但是对于测试来说，只有最后的缺陷数量才能体现测试团队存在的必要性。

puchonghui

我一直认为
面试一个程序员首先就应该让他写几段程序来看
同样面试一个测试员首先就应该让他写几个测试用例和缺陷报告来看

问一堆概念有啥用
你能了解多少他的实际工作能力