美文网首页软件测试go
如何建立团队执行文化思考

如何建立团队执行文化思考

作者: 卫彬TM | 来源:发表于2019-01-27 15:29 被阅读0次

    1.案例描述

    已经有的规范,已经强调过的事情,如何保证能被落地执行?在团队组建实践中,为适应多项目组、多任务、多风格团队的配合中,有各种约定、制度、规范制定,也进行了多次强调,但在执行的过程中还是存在部分问题。为解决落地、执行问题进行了很多尝试。将团队建设中的尝试进行下总结分享。

    通过整体明确责任范围、责任人、流程、时间点等对整体了解,了解自己可以做哪些事情、要做哪些事情、如何做。在明确职责的基础上去进行各类宣导、跟踪进行落地和深入,建立小组执行落地的文化。

    2.案例分析

    工作总经常出现如下场景:

    “@all/@所有人,把Bug导出分析下发出来评审”,没有下文;

    交待下去,没人配合,没人理:我跟他们说了要做什么的,但是他们不听我的;

    事情交待下去以后,也安排人员跟进了,人员也跟进了,最后检查结果只完了10%

    ................

    综上:职责、流程为明确,不知道要做什么,不清楚要做什么,不知道出现后果;

    处理措施:明确职责,明确流程,多途径强调/跟踪,提高人员能力等,提高规范落地及执行;

    3.明确责任


    明确职责范围

    明确团队的职责范围,在职责范围内的快速执行,是团队建立执行文化的基础,也是提高落地、执行力的基础。

    明确 部门职责范围A:清楚自己所在部门的性质及职责范围,和交互部门的业务交互范围以及我们可以提供的服务范围;

    明确小组职责范围C:明确小组在部门、交互部门中的范围以及职责,小组内可以提供哪些服务,明确哪些是C的工作范围。

    明确负责人职责范围D:以项目维度组件项目小组,小组赋予小组负责人的的职责范围及项目小组的测试范围。

    明确执行人员职责范围E:项目小组中执行人员的职责和范围。

    清晰明确部门、小组的定位和职责范围,清楚自己的工作范围,作为每个层级的执行者,在自己的职责范围中进行工作,若工作内容超出自己了解的既定的范围需要层级向上汇报确认,确认答复后再去执行。例如:E汇报给D,若没有超出D的范围,D进行处理,若超出D的范围,需要继续向上,汇报给C等进行处理,层级递进汇报。只处理自己职责范围内的工作,除非赋予新的职责。

    明确奖惩

    明确奖惩红线:明确职责范围,同时明确职责范围的上下限,以及触线的奖惩措施。例如:解决方案对外支持,范围:只负责后台解决方案的技术支持,若支持较好,项目进度理想,未遗留严重问题,未被投诉,xxx;被投诉xxxx等。

    执行奖惩:制定奖惩制度,需要进行执行,好的一定表扬,出现问题的一定要有处罚,有效保障执行可以顺利进行,不然“赏罚不明”,大家就无所谓了。

    明确流程

    示例A:

    领导:xxx文档本周五前完成,有没有问题?

    员工:没有问题。

    领导:周五马上下班了,xxx文档呢?什么时候评审?

    员工:我下班前发出来。

    第二周

    领导:xxx文档呢?什么时间评审?

    员工:我上周五已经发给你了啊…….

    示例B:

    Tapd上任务:

    创建人:xxx任务怎么关闭了,按照约定不是说,进行评审后,申请关闭么?

    责任人:啊,不是完成了就可以关闭么?

    创建人:任务要进行闭环……

    示例A,我觉得就是没有明确、统一大家对任务处理流程理解,任务流程如下:

    示例B:也是没有明确统一大家对任务处理流程的理解和任务需要闭环的概念。

    流程就是自己任务的地图,可以清晰的知道自己的任务所处的位置,清晰的知道哪些是我们的环节,哪些不是我们的环节。对于所有的项目/事项等都需要有流程,明确做某件事情的先后顺序,可自己介入的节点,以流程明确自己的职责范围,在流程的职责范围内进行执行。

    例如:Bug流程(tapd):清楚的知道流程的流转,以及节点的责任人,就可以清晰的、快速的处理自己任务。例如:周一打开Bug系统,发现20个已解决的Bug,根据流程、约定等确定是否时我们需要处理了,若是我们的节点就需要跟踪版本,然后触发版本提测流程,Bug回归验证,按照之前沟通约定、或流程等进行执行。若对约定、流程不清楚,就出现效率低下或没有进度的事情。

    版本提测流程:产品提前通知任务à产品提供需求à测试学习需求à沟通测试重点à编写测试计划与策略及评审修改à测试用例评审修改à邮件提测à升级à冒烟测试àBug回归à功能迭代测试。

    回归流程:获取版本-->升级-->打回/冒烟测试-->打回/Bug验证-->打回详细测试 

    遗留Bug沟通流程:周二~周三导出未关闭的所有Bug-->按照模板刷新及分类整理-->预约时间-->会议邀请-->周三~周四组织评审-->整理会议纪要-->根据会议纪要跟踪处理-->周五发出处理进度及结果;

    会议评审流程:整理评审内容-->邮件发出邀请-->组织评审-->整理会议纪要-->按照会议沟通进行跟踪-->再次组织-->……. -->结束

    以流程的维度明确当前在做什么,后续需要做什么,根据历史完成此任务的常规时间,清楚自己需要做什么,需要多少时间。不出现异常的情况下,每个人根据既定的流程进行执行。

    事例A:一个对各类流程都不太清楚的人员,分配一个任务,将版本进行下回归测试,获取版本升级后,冒烟测试不通过,不知道可以打回此版本在进行后续工作,继续执行下一步测试,在结束后发现此版本根本不具备继续测试的价值,甚至此版本Bug提交也存在异议。需要重新沟通版本回归,同时还需要对已经提交的,在异常版本上出现的Bug进行筛选复现,甚至对这些Bug进行解释说明。

    事例B:同样的任务,一个对流程、约定很熟悉的人,冒烟测试不通过,安装约定、流程立即打回重新提供版本。

    流程追责

    规定的流程、约定的事情没有落地,导致做很多无用功,是整体执行力低下;对这些异常的异常情况进行复盘,分析为什么会出现问题,是职责范围、约定、流程没有约定到时超纲的事情,还是没有认真落地导致,根据问题明确、深化、优化流程,若造成一定损失的需要对责任人进行调整等。

    明确责任人

    示例A:微信群里广播获取信息,无人回复,定点获取,很快得到回复

    A:我们运维平台的地址和账密是什么?

    ……. 无人回复

    示例B:单点请求

    B:@C,我们运维平台的地址和账密是什么?

    C:IP:xxxxxx,账密:admin/xxxx

    有句老话说得好:“人人有责等于没人负责”。如果不把任务明确给每个责任人,你的决策很有可能会无人执行。在分配任务时,你应当牢记没有“我们”这个说法。显然,这个说法的潜台词是“除了我之外的人”。即使人们不逃避任务“我们”这个表达也会让他们认为承担责任的应当是其他人。

    因此,在分配任务时你必须明确每个责任人的姓名,这种情况在团队合作中尤其必要。如果安排两三个人负责同一项任务,你必须指定其中某个人担任管理者的角色,让他对整个工作负责。如若不然,结果只会导致大家互相推脱责任。

    说明背景/目标

    示例A:

    A:本周进行下xxx版本测试,若出现提供超过三个版本,需要找领导确认…….;

    …..

    A:这是第几个版本了?

    B:第4个?

    …….

    在分配任务时可能会提及或涉及部分约定的内容。这些约定不是随口说的,是因为各种原因、背景等进行的约定,有些原因、背景会告诉大家,有些只可意会不可言传的,就需要自己领会,若还是出现在,可以明确的就直接明确;若不能明确的方便的就在后续的沟通中,会让负责人一起参与;

    示例B:

    A:本周进行xxx 版本发布(正式版本)。

    B:好的,发布版本(临时版本)

    任务是版本发布,但是具体是临时的还是正式的版本呢?若接接受任务方和布置任务方目标不一致,中间的过程、产生的结果也就不一致,对上、对外的表现就是效率低、执行力底下、制度没有落实等现场。

    清晰明确实现什么目标,不想实现什么目标。对行动目标的描述越清晰准确,偏差越小,任务完成的效率就越高。

    明确时间点

    在“明确流程”中示例A可以看出来,时间点也需要和流程节点一起明确出来。在分配任务时经常会遗漏这个关键因素。很多人往往并不明确完成任务的时间,而是语焉不详地说“回头把这个事处理一下”。在这种情况下,对方会优先解决更加重要的问题,把这项任务抛到脑后,直至最后忘得精光。可以说,缺少时间期限的任务目标根本不会激励人们的行动欲望,相反只会带来一堆问题。

    分配任务时需要和流程等一起明确时间点。例如:xxx任务,总时间控制在8小时,每天花2~3小时进行本工作,发现问题不能确定的,进度有异常的及时沟通,周五完成评审及修改完成,找我确认后任务结束。这样分配相对比较明确,大家对范围、时间点、异常处理都达成一致处理起来会比较高效。各项事情都明确了,执行力就体现出来了。

    记录宣贯提高执行力

    “有据可查”

    Bug提交、集成测试流程等比较正式牵扯各个方面的,就需要已部门、公司等进行流程整理、规范,大家安装规范进行落地执行。

    多部门配合测试中,流程非常多,若加上平时口头上、微信中、领导层、执行层随口的约定,这些约定、流程会不断变动和越来越多。流程、约定、规范来源多,已有的规范强调时和若和听众没有利益冲突的,也不会刻意记住;暂时用不到的流程,仅出现一次的约定,1~2两个月没有出现没有用到,就遗忘或出现偏差了。人都会记住对自己有利的制度和约定。这些在confluence上进行流水账记录,方便回溯和在需要时查阅。

    示例A:

    产品:你们一轮测试完成了,测试用例执行结束了,研发修改Bug期间不能再提交Bug,不然Bug接不完,有这个约定为啥还在提交Bug?

    测试:不可能啊,测试人员在没有提供新版本期间,测试发现新的Bug肯定要提交的,这个应该不存在异议,这个约定不能同意的,若必须这么走,需要大领导确认…….,在xx月份是有这么个事情,但是没有达成一致,测试同意,需要升级领导讨论的,后续没有结论。

    产品:后续再讨论。

           上次沟通过了2个月,突然出现了问题,若我们形成文字流水记录,就可以说查询下记录,告知:某年某月,xxxx,怎么沟通,没有结论…….就不会出现,没有按照流程、约定进行出现偏差,出现返工的情况。

           将随口约定的流程、规范、约定等及时以文字记录流水进行记录,使每个人可以看到、了解我们的约定、规范和流程。有新的约定就督促相关人员记录,使之养成习惯。

    “会议明确”

    晨会

    每天9点针对每个项目召开5~15分钟的站立会议,快速回顾昨天任务的进度及遗留情况,明确当天任务及同步新的规范、约定。

    回顾昨天:回顾昨天任务完成情况,经验总结,和异常情况,例如:xxx任务计划完成100%,因xxx原因实际完成60%的,主要是xxx原因,责任在xxx,后续注意…..

    明确当天任务:明确项目组小组当天整体任务,明确小组内每个人员的详细任务。例如:小组整体任务:1.版本升级冒烟测试,2.20个Bug验证;3.xxxx模块验证;4.遗留Bug整理;5.提供xxx版本;6.xxx模块测试用例刷新

    A:xxx版本升级冒烟测试,2H;若出现问题,按照流程及时打回群里同步,若没有问题群里同步下冒烟没有问题,同时通知B进行xxxx模块测试,进行下一步Bug验证,3H;进行xxx详细测试,3H;

    B:遗留Bug整理,2H;进行xxx详细测试,4H,验证OK,提供现场并指导升级;若版本异常通知同步现场,进行测试用例刷新,整体5点前完成并同步。

    明确目标,时间节点,谁,方法,交付件等;

    规范、约定、流程同步:昨天进行了xxxx约定,大家在工作时注意下,有问题及时沟通。

    周会

    每周一梳理明确本周阶段任务,及上周明确的约定、流程;

    周五例会上强调规范、约定流程及注意事项;

    PS:多次强调,形成潜移默化的是大家理解。

     借用外力”

    没有按照规范、约定执行的,责任在自己的,被怼几次、被投诉几次,自己就会深刻理解和基础了,此项约定、规范肯定执行的很到位

    有些约定是为了减少大家工作、减少扯皮的时间,但是大家没有经历过,对背景灯不了解,这些制度就没有落地。给创造下出现问题的环境,如独自负责项目、增加任务等,是问题再次出现,责任人认为不合理了,自己提出,然后告诉,xxx约定你没有执行,这个约定就是为了解决这个问题。

    以点带面”

    新的规范约定,一段时间内单独跟踪组内某一个人员,使之养成习惯后再带另个一个,以点带面来推动整体规范约定的落地,是指形成执行团队执行文化。

    总结

    上面说了很多,但是还存在某些已经宣贯的制度没有落地,对于整个团队的建设还有很长的路要走。整体思路就是明确职责范围、责任人、目标、时间点让大家知道:我能做什么、我需要做什么、我应该做什么;同时以文字、宣贯等各种方式,啰嗦的向大家传达责任、流程、目标、和时间点,让大家有据可依,流程清晰明确。

    相关文章

      网友评论

        本文标题:如何建立团队执行文化思考

        本文链接:https://www.haomeiwen.com/subject/opogjqtx.html