Get best of the week

看板方法：将您的过程理解为集体学习过程

前言


在说俄语的过程管理人员专业社区中，很少有关于俄语中看板方法的文献。我们决定纠正这种不公正现象，我们将从俄语的角度发表最重要的文章，这影响了该方法的发展。

将您的过程理解为集体学习过程


以及该系列的第一篇文章，关于如何更有效地建立工作流程的可视化和感知董事会。原始文章的作者是Alexei Zheglov，可以在这里找到，

这是使作品更加集体化的普遍趋势和愿望。但是，当我要求办公室中的人员制定工作流程时，他们通常会提供以下内容（我简化）：


按照这种观点，工人构成了一条传送带，但他们的工作看起来并不像装配线。例如，软件开发人员可以检测到需求规范中的逻辑不一致，然后将工作发送回商业智能。测试创建的软件时，质量工程师（QA）可以执行相同的操作。分析人员将更新规格并将任务发送回质量检查。质量检查人员可以在其中找到错误，然后将其发送回开发人员。实施专家可能会在代码中找到阻止交付的内容。然后，开发人员进行必要的更改。现在，代码需要重新测试，因此返回到QA，然后返回到实现。

这种交互不仅发生在单个团队成员之间，而且（重要地）发生在公司部门，服务和跨职能团队之间。因此，人们绘制了许多以不同配置连接的箭头，以显示所有这些程序。

一些人试图在他们称为“看板”的板上可视化此过程：


然后他们问自己：例如，如果测试人员将工作项退还给分析人员或开发人员怎么办？卡应该留在原处还是移动？如果我们有在制品数量限制（这些数字在列标题中）怎么办？如果此列已满，怎么办？

有没有更好的办法？


这个问题很普遍，并且源于对专业服务工作性质的误解。与专门工作之间的一系列传递不同，它主要是关于创建信息和积累知识。当试图使过程看起来像流程图时，这成为一个障碍。以及在执行工作之后尝试对其进行可视化的限制。

在交付软件产品的新功能的示例中，可以创建以下知识（不一定按此顺序）：

  • 工作环境的精确配置（操作系统，Web服务器，数据库服务器，第三方软件）
  • 已开发功能的行为，用例，验收标准，可执行规范等的关键示例。
  • ( , . .)
  • -
  • : , , ..
  •   , .

任何专业服务中的每个人都可以拿出自己在交付过程中创建的知识列表。当工作完成时，所有这些知识已经存在，但是当我们刚开始根据客户的需求或对某物的要求进行工作时，这一切都是缺失的。

如果我们尝试形象化积累这些知识的过程，结果可能看起来像这样：


在此示例中，规范工作在交付过程的早期阶段占主导地位。业务分析师可以进行功能分析，分解和完善需求。但同时，其他专业人员也可以做出贡献。测试人员可以帮助将验收标准转变为可执行的测试。部署专家和开发人员可以评估对代码库和基础结构的影响。

这项活动从一开始就积累了很多知识，但最终却逐渐消失。我们不能无休止地分析交付的所有方式。因此，在某个时候开发代码成为积累知识的主要方式。

当然，大多数代码开发都由开发人员承担，但其他人也可以提供帮助。需求可能仍然需要澄清和澄清（您好，分析师）。测试人员可以获取部分现成的软件，对其进行测试并向开发人员提供反馈。开发人员可以与实施专家合作，以查看新出现的变化将如何影响部署。

但是此活动将消失。我们无法通过完善代码来取得进一步的进展。因此，我们继续进行测试。并专注于解决所有剩余的错误。知识研究中的另一项活动开始占主导地位。测试人员对此负责，但是他们需要开发人员，错误修复以及其他专家的帮助。

请注意，新流程图中的三个转折点不是职能专家或部门之间的转移。这些是主导活动的变化以及相互作用方式的相应变化。

结论


我们不需要将流程视为专家和授权转移的网络。当我们尝试以可视化方式可视化我们的流程时，我们不需要以描绘专家的块的形式来表示它们，而是用许多箭头将它们连接到各个方向。

相反，我们可以将交付过程视为获取信息和创造知识。问自己一个问题，我们为了收集知识以执行什么操作以积累知识，以交付所交付的内容，我们可以将我们的过程可视化为一系列联合行动。

下一步是什么？


在接下来的几篇文章中，我将举例说明软件开发领域以外的知识积累过程。

作为建议，我需要准备许多文章：流程专家如何与专业服务团队一起反映流程。对于使用看板系统的用户，此方法在这些系统的设计和操作中具有多个优点。

非常感谢Aleksey Pimenov和斯蒂夫。

More articles:


All Articles