引言
在帮助客户完成敏捷转型的过程中，作为顾问团队，我们需要协助客户建立贯穿产品交付生命周期的一整套敏捷研发流程。在这个过程中，由于需要改变客户现有的工作模式，转型面临诸多阻力与挑战。如果能为客户降低工作中的阻塞，一方面可以提高敏捷运作的流畅度，另一方面也可以赢得客户的信任，提高配合度。近期我们为客户组织了一次测试环境问题梳理活动，本文分享了活动的完整历程，对过程中遇到的问题及使用的方法、工具做了介绍，旨在为大家提供实践参考。
关键词：Workshop | 根因分析 | 鱼骨图 | 5 why
背景介绍
近期在团队教辅过程中，多个团队频繁出现测试环境阻塞问题。这些团队隶属于同一部门，负责不同的业务，具备以下几个共同特征：
- 共同工作在“大泥球”架构上
按组织架构划分系统层次。每一层的所有模块归属于一个部门，每个模块对应一个代码仓库，模块内部包含多个子模块，每个团队分别负责其中一部分子模块。纵向虚拟团队之间配合，实现业务需求。横向团队间业务关联弱，但代码与架构不得不耦合在一起。 - 业务流程链路长
业务实现被映射到每一层，散落在不同的子模块内，导致大部分需求均需要跨多个部门协作来完成开发。相应的，系统的可用性取决于各个模块的稳定性。 - 工程实践能力弱
主要体现在编码质量不高，如绝大部分代码面向基本数据类型编程。单元测试有效性差，如：只看覆盖率却没有使用断言。由专门的基础设施团队来负责统一的平台建设，团队对基础设施缺少管理经验。
过多的内外部依赖与脆弱的代码质量，导致整个业务链路故障频率很高，测试流程非常容易发生阻塞。由此顾问团队组织协调多个团队，开展测试环境问题治理活动，并举办了环境问题梳理workshop。在workshop上，客户多个团队以共创的形式梳理当前的主要问题和根本原因，产出下一步改进计划，并确立了后续跟进机制，以持续优化测试环境稳定性。
阶段一：问题收集
作为梳理活动的起点，问题收集的方式考虑了以下几方面因素：
问题随机发生，表现形式多样，理想状态下需要通过一段时间的积累和统计才能拿到全貌。但这种方式时间成本较高，且需要建立更长线的团队配合机制。
顾问对于团队的实际情况认知并不全面，因此需要依赖团队来提供输入。而团队往往疲于应付交付工作带宽有限，因此需要尽量高效的收集信息。
不同团队、个体的视角均不一致，信息来源需要尽量丰富，以降低样本间的偏差。
基于这些因素，我们收集问题的策略优先考虑效率与广度。因此设计了两个阶段的数据收集：问卷调研与共创补充。
问卷调研
问卷规划：首先需要对问卷内容进行规划。除了基本的信息量，问卷还需要包含一些维度信息，以便从多个角度分析数据。本次问卷包含的选项有问题描述、问题原因、模块名称、影响时长、发生频率以及角色。
问卷发放：问卷发放环节与各个团队的客户TL做好沟通工作，明确当前的目标，并请TL协助通知团队成员。TL作为团队中的技术管理者，一方面能帮助我们牵引团队，另一方面也是我们获取信息的重要途径。比如这次问卷的设计环节，便是我们和其中一位TL共同完成的。
数据分析：对收集到的数据进行初步的整理，在这一环节我们根据影响时长与发生频率两个维度归类问题，掌握问题的影响分布。
最终，总共收集到13份问卷，包含24条目。有效填写人数比例约60%。依据问卷中两个时间维度，最终整理出了初步的问题范围，如下图：
但是收集上来的数据也存在细节不足，比如存在概括性的描述“服务不可用”、“XXX系统无法访问”等。另外不同的人对相同问题的感知频率与时长，可能出现不一样的感受。
共创补充
问题收集第二个阶段发生在workshop上，形式与Retro基本一致，只是增加了问卷收集结果作为输入。
阶段二：解决方案共创Workshop
Workshop其实是本次环境问题梳理活动的重点环节，需要满足多方面要求：
人员：受邀者范围应该尽量广泛，在输入上提供更广阔的视野，在输出上影响更多的团队。
角色：需要有多种类型的关键角色，包括但不限于以下：
直接相关人-团队为主：需要有人来提供问题的准确输入，以及承担大部分后续的改进工作。
长期负责人-部门架构师：需要有人能持续牵头跟进，确保治理活动的延续性。
核心干系人-部门领导层：需要有人来决策拍板、提供资源支持。
流程：流程需要顺畅，以确保在有限的时间内，尽可能的让大家充分投入、足够聚焦，来提高产出的质量。
产出物：如同Retro成功的标准一样，需要确保活动有可执行的产出，指定到人的action，明确的时间节点。
确定参与者
在workshop之前，我们通过与部门负责人的沟通，圈定了核心干系人，包括部门架构师与测试经理。架构师承担了重要的决策作用，也会作为长期负责人推进后续的改进工作。与我司常见的全功能团队不同，客户的研发与测试属于两个部门，测试人员被派驻到团队，汇报给测试经理。因此测试相关的实践优化需要与测试经理达成一致，才便于在团队中推行。除此之外，测试经理还承担了管理测试环境、与基础设施团队对接的职能。
团队方面我们邀请了4个研发团队的TL、骨干Dev和团队内QA作为直接相关人，共计15+成员参与workshop讨论。这里有一个隐性的重要因素：在邀请团队时，需要确保其中有“积极分子”。客户大部分同事还不习惯做一些“额外”的事，习惯于按部就班的完成给定的任务。但workshop的效果非常依赖与会者的主动参与度，如果大家都不敢或者不愿意表达见解，那么会面临冷场、产出不足的风险。其中的一位TL就是我们认定的“积极分子”，在预约时优先考虑他的档期。事实也证明这位TL除了提供多项建议外，还带动了大家讨论的气氛，起到了非常关键的作用。
凑齐这些核心参与者也需要不少沟通协调工作，各种因素影响下，workshop的日程改期了两次才得以举行。
活动准备
准备工作一方面需要围绕会议做基本事项准备，另一方面需要提前规划活动流程。
基本事项包括了会议时间协调、会议室预定、会场布置、会议使用的片子准备等内容。
流程规划类似于计划会，我们以2小时为目标，对各项活动进行了时间分配。在workshop开始前，团队内部进行了彩排。基于大家的经验与彩排的效果，最终workshop的环节安排如下：
会议目标（5min）
问题梳理（20min）
根因分析（50min）
方案讨论（30min）
下一步行动（10min）
问题梳理
问题梳理环节的目标是让大家对现状达成共识，包括对齐调研问卷结论以及遗漏问题的共创补充。
我们将电子表单收集到的数据提前挪到物理看板，并现场与大家依次澄清细节，确保团队对内容、影响程度没有明显争议。在梳理完问卷涉及问题后，邀请大家基于经验，补充遗漏的问题。比较有意思的是，有一个重要的问题便是在workshop现场补充的，并没有出现在任何人的问卷中。
在基本圈定整体范围后，与Retro类似，我们对话题进行了合并分组，投票确认优先级。选定高优先级的三个话题作为根因分析环节的输入。问题梳理结果如下图所示：
问题梳理环节需要带领所有人进行协作，因此需要主持人具备一定的引导技术。一方面需要引导大家产出高质量的内容，另一方面要关注现场的氛围。
根因分析
根因分析是不确定性最大的环节。一方面，待分析问题的深度与广度无法事先估计，需要现场根据时间来控制范围。另一方面，该环节的结论决定了后续的改进的目标，如果方向偏离则后续的改进都会失去意义。因此，根因分析环节的流程设计如下：
首先将参会人分为三个小组，每个小组不超过6人。
每个小组选同样的问题，完成根因分析与方案内部讨论。
所有小组讨论完选定的问题后，依次showcase组内产出。其他小组负责提问与补充，确保跨小组达成一致。
Showcase均结束后，所有小组切换下一个问题。
在内部讨论环节我们使用了两个工具，一个是鱼骨图，一个是5 why。鱼骨图主要是为了让大家先梳理出分类，激发大家从更多的维度来思考根因。5 why是为了保证每个话题讨论的深度，避免无法深入到底层原因。这两个工具在使用前，需要向团队介绍使用方法。这里借鉴了我司内部培训使用的一个样例。
鱼骨图做根因分析时，首先将待讨论的问题写在鱼头处，聚焦事实本身，尽量精确描述问题，基本的句式结构为“What’s wrong with what”（描述不符合预期的行为，可通过加否定式检查是否是预期的行为，来判断问题描述是否正确）。
然后需要确定骨架，也就是问题原因的主要分类。标准的推荐分类包含人员、机器、材料、方法和环境。结合测试环境问题上下文，我们给团队推荐的分类包括基础设施、方法与实践、代码与架构、数据、流程规范以及人员角色。推荐的做法是最后讨论人员角色维度，以求先从客观原因出发，避免一开始便陷入互相指责。
骨架确定后，在每个分类中采用5 why寻找根因。首先从问题出发寻找直接原因，然后层层递进，每一次原因找到后转化为下一个问题，继续寻找下一层的原因，直到找到根因。根因有一个比较主观的判断标准，就是对当前团队有意义，做出改变就能影响到。找到根因后，可以从问题出发，用“因为”串联每一层根因来判断逻辑是否通顺（反向用“所以”来串联）。
最终在根因确定后，基本就可以产出相应的解决方案。
团队在梳理完三个问题的根因后，产出的分析结果如下图所示：
从根因分析的结果来看，大家对工具的熟悉程度不够，导致使用并不是很规范。
部分团队在定义问题时，描述不够具体，如：“基础设施问题”。应该表达出不符合预期的特征，如“基础设施对交付活动产生了阻碍”。
部分根因分析链路，并没有严格遵循5 why的逻辑递进结构。
另外，根因分析环节耗时确实超出了不少预期，单个问题的分析耗时基本在30分钟，因此后两个问题便改为不同的小组分别讨论，集中showcase。
不过从现场观察来看，鱼骨图对拓展大家思路还是有一定的帮助，能够提醒大家从多个方面思考问题的原因。尽管分析过程还有改进的空间，但在showcase环节大家还是互相提出了一些问题，并通过共同决策消除了争议，达成了共识。
下一步计划制定
随着根因与方案的明确，下一步计划基本快速的确定了下来。这里与我们常见的团队retro不同，“领导层”的支持与决策分量更重一些。一方面是因为团队还是习惯于被动接受任务这种工作方式，一方面是因为部分改进举措是需要团队外资源协助，还有一部分原因是测试环境治理是长期工作，需要建立起来管理机制来持续跟进，“领导层”的支持是保证这套机制运转的重要条件。
具体的改进计划表参考：
至此，整个环境问题workshop环节全部结束。在历时3个小时的workshop后，产出了9项改进举措。其中4项为团队级改进，3项需要组织级支持，2项需要跨部门协作。
阶段三：计划跟进
在完成了改进举措产出后，还需要确保举措按计划落地，也需要观察改进效果，确保举措的有效性。如果发现效果不理想，还需要进一步探查原因。
跟进机制主要是利用定期例会来建立。一方面，客户技术负责人会在定期的技术例会上，收集各个团队的进度与反馈。另一方面，顾问也会在与部门负责人的周期例会上，汇报所列事项的进展情况，提升“曝光度”。
成效主要通过数据对比来度量。一方面计划利用同样的问卷，来收集阶段性的反馈，观察大家主观感受的变化。另一方面，客户有定期的问题复盘会。通过对比改进前后的统计数据差异，来更加客观的观察问题发生的趋势。
截至目前，产出Action已经陆续开展，后续将会以收集环境问题统计数据的形式，关注改进效果。
总结与反思
最终经过2个星期左右的历程，环境梳理活动第一阶段告一段落。对整个过程复盘，可以得到以下的一些体验。
Well：
虽然鱼骨图工具使用方面并不稔熟，但其结构化的能力还是能够帮助大家拓宽视角，帮助团队完成共创活动的核心目标：产出具体到人的可执行Action。这里其实也应证了我们一贯的团队引导价值观，“相信大众智慧会找到最佳解决方案，相信均等参与会得到最佳的执行力”。
得到了来自领导层的支持，引入了重要的干系人，扩大了影响力范围，并确保产出快速落地执行。
引入了团队中的“积极份子”，带动了其他人的投入度，让整个流程更加平顺。
通过梳理活动，顾问团队扩大了与客户的接触面，与团队外的重要干系人建立了联系，对后续教辅活动有一定的帮助。
顾问内部的协作配合也是非常关键的因素，在整个活动的每一个环节，都包含了多位同事的共同合作，确保了整个流程的顺利进行。
Suggestion：
针对可能出现的卡点，可以提前做预案，在现场出现滞涩时可以适度引导。
引入工具时需要考虑与会者的学习成本与主动性，通过更贴合当前上下文的例子来解释用法。
转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 350394277@qq.com
