临床组总结Word文档格式.docx

临床组总结Word文档格式.docx

《临床组总结Word文档格式.docx》由会员分享，可在线阅读，更多相关《临床组总结Word文档格式.docx（4页珍藏版）》请在冰豆网上搜索。

自小组成立以来，从组员培养开始，到现在的组员能够独立的进行部门日常工作，能够有目标有计划的完成各自的年度目标，不是夸张的说，自己真的做了很多努力，在此我就不以流水账的方式一一列举。

在这里我将自己的工作分为4种类型，各举一到两个有代表性的例子，做一个简单的概述。

1.日常工作1.1日常工作指导

其实部门的日常工作有很多，除了测试以外还会有问题验证和技术支持，在组员开始做日常工作后，对于她们要验证的问题，我都会分析一遍，将她们在验证过程中需要注意点写在需求验证中；

对她们验证的问题所书写的需求验证内容的准确性、规范性、问题的关联性进行检查。

测试验证部分，我会将她们在测试时需要注意的点写在测试说明中，使开始的日常工作有方向性，也在事前对工作的质量进行干预。

也希望通过这种方式，能够培养组员良好的工作习惯。

1.2组员工作成果的审核

在组员完成了组内的培训后，组员开始了部门的日常测试工作。

在测试工作初期，我坚持对组员测试问题所书写的测试点进行一一的审核，将她们测试点的问题反馈给她们，让她们改完后我再对修改的测试点进行审核，一直到我认为满意为止，另一方面，我也对她们测试的每个问题都重新测试了一遍。

到财年第三季度的时候，即便是10.33的测试任务很重，而且小组的概念对外公布后，自己技术支持数量也有明显增多的时候，我也坚持做到了对组员所写的测试点进行逐一审核，对组员测试的重点问题进行测试，以保证临床问题的测试质量。

2.项目工作2.1人员培训

的接收到成立小组，由我对新进的两名组员进行培训，到组员正式进组的时间不到3个工作日。

这个时候，组内培训文档是没有的，于是我就在时间很紧的情况下，先完成了药品与临床，诊疗项目与临床分的培训文档，然后在边培训组员边做培训文档的情况下，完成了组内的培训工作，虽然时间非常的仓促，但是我一直都以高标准要求着自己工作的方式和工作的质量，虽然没有人对自己的培训质量进行检测，但是以组员后面工作中所表现出来的产品、业务积累，也能够正面的反应出当时的培训成果，对于部门负责人、组员还有自己都是满意的，而且培训期间写的培训文档，在后期做了小部分的改动后也成功通过了部门审核。

2.2临床路径自动测试用例编写

自8月份开始，小组开始了临床路径应用的自动测试用例编写，为了能让组员更快的融入到测试工作中，在写测试点的时候，我就将较为简单的权限、参数、普通路径功能的测试点，有目的性的分配给了两位组员，重点发展临床路径的组员写权限、参数以及路径评估部分，另外一个组员写基本操作部分，自己写特殊路径部分。

开始我让她们先写一个功能的测试点让我审核，然后有实际例子的给她们讲解，她们写的测试点存在的问题，以及正确的书写测试点所需要注意的点和怎么样理清自己的逻辑思维。

然后再让她们大规模的开始测试点的书写工作，她们所书写的测试点我都逐一审核，并指出存在的问题，经过反复的调整后，后面也以极少部分的测试点遗漏，通过了研发测试点审核。

后面的测试用例编写工作中，我虽然没有参与编写工作，但是他们每个星期测试用例的编写工作进度我都会跟进，发现了她们工作进度异常的时候，就会跟她们交流具体什么原因耽搁了，问题是否解决了，当她们不知道怎么办的时候，我也会出面与自动开发组协调，将问题处理了，以保证临床路径自动测试的开发工作能够顺利进行。

3.年度目标

年度目标，自我们进部门不久后就有了这个概念，而且每一年的年度目标自己都保质保量的完成了，所以对于自己本年的年度目标的在意程度，远不及对组员年度目标所在意的程度多。

从一开始的年度目标设定，到人员能力提升评估表的制定，到后来年度目标的执行、跟踪。

每个步骤自己都做的很仔细，先让组员先制订出自己本月需要执行的年度目标，然后自己结合自己的经验及小组的工作目标对组员所制订的目标进行评估、调整，每周提醒组员年度目标部分的工作执行，以及安排时间审核结果文档，对文档中存在的问题指出修改意见，以保证组员年度目标的执行进度和执行质量。

4.其他

在小组成立伊始，还完成了小组工作范围、工作职责、工作划分的工作，并形成了相应文档，以规范小组的工作。

在12月的时候，我还根据小组运行期间的具体测试工作情况，制定了小组的测试工作规范，以规范小组测试工作，最终实现保证小组测试工作的质量。

为了组员能够养成良好的总结、反思习惯，我还要求组员每月写总结，在总结中对自己每月工作内容和具体情况进行总结，总结自己每月的进步，找到工作的自信心，反思工作过程中存在的问题及思考改进方式，对自己改进问题进行回顾等。

与组员正式的沟通虽然不多，但是非正式的沟通还是比较多的。

也时常关注组员的情绪，有什么问题也有及时沟通交流。

三：

自己的变化1.思维方式的改变

在前面两年的工作中，自己一心想的就是怎么样把上级安排的工作做好，然后在此之余还要完成一些自己在工作过程中自己发现的，自己缺失的产品知识、业务知识，更有甚自己还有着手学习VB知识，用于充实自己的能力。

但是在当上了组长以后，发现其实技术能力只是工作所需要能力的一部分，与人沟通交流，工作安排协调，其他诸如思考、分析、反思、表达等等多种综合能力其实都非常的重要。

一直以来我说话都是直来直往的，很多时候太在意说的事情，没太在意听的人的感受，伤害了一些人。

在当了组长后，我也征求了经常交流的研发同事的意见。

总之就是换个角度看到了自己更急需要改进的问题，更需要培养的能力。

2.耐心了很多

在小组成立之初，在我审核组员工作的时候，我一直拿着自己的高标准要求着她们，比如在写能力提升评估表的时候，我让组员改了两次都没有达到我想要的结果，最后我干脆直接改了就提交了，但是后来我想了想，我这样做，看起来我直接把东西交了就完事了，省了中间的我审了让她们改，她们改了我再审中间的麻烦，但是长远来看，对于我和组员来说是有百害而无一利，怎么解释呢？

其实让她们反复的改，在整个过程中，能够刺激她们的思考，思考怎样把事情做好，同时总结出一些工作方法和技巧。

我就这样直接的把事情做了，我没有三头六臂，事情多的时候我也做不完，到时候她们没成长起来，怎么办呢？

慢慢的，我就耐心了很多，以前看到满是字的文档就头痛的我，现在可以把她们写的几千上万字的测试点、升级文档、数据流、工作总结等等逐一审核，并指出其中存在的问题，修改后再审核，再修改再审核也没有了开始的毛躁。

3.责任心增强

在小组成立前，测试临床的问题的人比较多，以前临床出了问题，我马上就会分析，是不是自己测试遗漏而出现的问题，现在只要是临床出了问题，考虑的就完全与责任无关，自己从心底就会觉得肯定多少都会有责任，而首先想的是问题是否紧急，如果紧急就先把问题处理了，然后再来分析，问题产生的原因是什么，反思自己的工作中哪里出了什么问题，怎来改进自己的工作，避免再重蹈覆辙。

比如前面分析了一个护士确认停止后没有填写确认停止的人的问题，分析后发送，问题虽然是配合移动改的，问题也不是自己测试的，但是这个问题确实是出在了临床了，所以我就要求自己，在以后的工作中，每次版本发布问题测试中，在测试完临床组的问题后，还要对分析不在临床测试而是临床研发修改的问题，是否需要测试，以改善测试遗漏的问题。

4.集体意识、集体荣誉感增强

在得到上级要求临床组的组员讲解数据流这个事情的时候，我也特别紧张，虽然前面在她们做的时候我对她们的要求的就很严格，一再强调不是为了做这个事情而做这个事情，是要在做的过程中认识到数据流的重要性，认识到怎样去做这个事情，什么样才叫真正弄清楚了数据流。

修改了两三次的结果我也算满意了，但是在组内讲解的时候，情况不是很好，我就害怕正式讲的时候要出岔子，所以我就一再的跟组员啰嗦，不要以sql的顺序来讲解这个数据流，要用大家能够理解的逻辑思维，以及大家明白的语言来讲这个事情。

最后组员讲完后，都得到了上级的一句不错的评价，当时听到这里，比自己得到赞许还高兴。

四：

小组成员培养的好处1.目标明确，成长周期缩短

在我给组员做年度目标的时候，我就发现，其实我们在第一年的工作中，是没有很正式的年度目标这个东西的，也就到了工作的第二年的时候，我们才有了关于产品知识、业务知识积累，数据流书写等目标。

在我们以前执行的第二年的目标，其实就是我现在急切希望她们积累的知识。

到现在组员已经顺利完成了个别功能的数据流的书写，而数据流的熟悉程度也能够从侧面反映出她们的产品熟悉程度。

再者，她们在工作了两个月就参与了sp版本发布的测试工作，不到半年的时间就参与了10.33这个大版本的发布，而我们当时是在进部门近1年的时间时，才参与了10.30的测试工作，我们迟迟参与测的原因有很多，如我们刚进部门的时候，没有定方向，所积累的业务知识、产品知识并不足以参与测试，如果我们测试了，也没有办法保证我们测试质量。

其实从这两个点就能很直观的反应出她们的成长周期缩短了。

2.有明确的人支持帮助新人成长

在我们进入技术中心后，也有各自的导师，导师也会帮助我们解决工作中遇到的困难，也会有人给自己制定年度目标，但是年度目标制定后，目标的执行都是自己在看着执行，到年底清点目标的时候，完成情况就参差不齐了。

以小组形式培养后，组员的年度目标都跟的很紧，我会月月提，每个月的目标定了后还会周周提，而且年度目标的产出物，我会及时给她们审核，其中存在的问题会及时解决。

比如数据流这个目标，在参加工作第三年的同事目标中同样有，她相同的功能讲了两次还是没有让人很满意，但是我们小组的新人能够在一次的讲解中就得到了上级不错的评价，这对新人来说有很大的鼓舞和增强信心的作用。

五：

组长需要的权力

1.希望组长对组员加薪有建议的权力。

2.希望不管是谁登记的需求类问题，都强制性的由业务组长确认。

虽然现在有确认这个流程，但是问题登记后，可以直接流转到研发接受，这种情况，就只有研发修改完后才会流转到组长处，组长对自己业务划分的需求不能及时知晓不说，遇到大的需求要修改到sp上面的工作安排也不能及时。

3.研发做的相应业务模块的设计文档，业务组长要知晓或者参与审核，这对后面测试工作中所需要了解的，产品这样设计的目的、原因、相应业务又一定的帮助作用。

组长参与到讨论中也有利于组长相关能力的提升。

4.希望逐步培养业务组长邮件或其他方式调查业务的能力。

六：

疑问和困惑1.工作内容模糊

在整个过程中，其实我对于自己到底要做什么事情，要做到一个什么程度都是不清晰的，也没有一个衡量自己做的好与否的标准，所以一直以来我都是自己判断，觉得自己可以做好就做，可能做不好就努力做好，虽然这段时间自己所做的事情还算满意，但是多少还是有迷茫的时候。

2.组员能力忧虑

确定方向的培养组员能够让组员快速成长，它的反面就是组员对其他模块了解甚少，这对她们以后涉及到其他部分影响临床的测试思考会大打折扣。

比如病人结账后对临床这边的影响的测试设计。

因为临床这边与其他系统多少都会有联系，尤其是费用和药品，所以这点让我非常的忧虑。

3.组员的发展和后期工作激情的调动

虽然我跟组员有过类似的沟通，比如她们有没有当官的想法呀之类的，她们口头上虽然说暂时没有，但是工作时间久了，总是会面临发展机会的问题，也会有工作的瓶颈期，暂时还不知道怎样处理。

4.工作指导

其实不管是当了组长还是没当组长的时候，其实自己在工作中存在的问题，有的能够看到，然后自己也努力在改，但是有的问题自己可能认识不到，所以还希望有人能够及时指出，帮助自己及时改进工作。

七：

综述

通过这个总结性的梳理，自己对于小组的工作又有了进一步的认识，希望疑虑和困惑能够得到一定程度的解决，也希望自己在摸着石头过河总结出来的经验对后面业务组长的工作产生一定的借鉴意义。