从头开始构建流程：从混乱到有序

在本文中，我将讨论在小型Web开发部门中构建工作流的问题。 该部门是从零开始成立的，并立即开始自治工作，因此我们必须自己建立生产流程，踩各种耙子，并从中得出必要的结论。 希望这可以帮助某人节省时间，金钱和神经，我将描述我们面临的问题以及解决这些问题的选择。

重要的是要注意，这不是可以在任何开发团队中实施的通用方法，并且一切都将立即变得美好。 这只是众所周知的技术和实践经验的结合，我们能够有效地适应我们的发展特点。 没有单一，简单的解决方案可以解决此问题。 您始终需要基于团队本身的规模和经验，业务特征，项目细节等来建立。

我们部门的初始数据是：一个小型的（5-10人），部分分布（一些员工在远程工作，有些在办公室）和公司内部客户的产品团队。 Web项目。 部门内没有系统管理专家，但公司中涉及部门。

团队沟通

让我们从在部门内部建立有效的沟通开始。 在任何团队中，建立有效的沟通渠道和沟通方式都很重要，但是当团队分散时，这种需求就会加剧。 由于团队仅部分分布，因此达到了最大清晰度。 我们必须学习合并办公室和远程员工的世界。

我们遇到的最重要的问题是口头讨论。 办公室工作人员总是很想迅速打包一杯咖啡并讨论该项目的状态。 但是，在这种情况下，远程工作者将无法参与此讨论，因此，他们将无法发表自己的想法，并且实际上他们将不知道正在发生什么事情。 通常，这会导致团队的动作失去同步，由于团队分散的部分出现了新的想法和建议，因此反复进行了讨论，并且回味不佳。

很明显，一些重要的共同点应该通过普通聊天或小组通话的形式进行讨论。

这引起了另一个非常普遍的问题，出现在需要大量写作的团队中-写作文化的问题。 您不能只是去找同事，拉起袖子，在餐巾纸上画些东西，然后在故事中添加手势。 一方面，这使工作变得复杂，另一方面，人们发展了以一种可理解的，结构化的方式来表达自己的想法的技能。 这种方法的结果是，文档开始变得更加形式化，任务变得更加清晰，每个人都开始思考如何以一种使他人从一读就可以理解的方式表达自己的想法。

以上所有内容并不意味着我们完全放弃了个人通信，语音和视频通话。 但是，我们规定，讨论的结果应以书面形式记录，作为一种知识工件，始终为所有人使用。
简要介绍一下我们用来解决团队内部沟通任务的工具清单。

首先，我们在Telegram上开始聊天。 但是后来，随着团队的成长，我们意识到在一次聊天中我们已经很亲密，并切换到Slack。 在那里，我们将总体流程划分为主题渠道，并设定了明确的规则-出于什么原因而写哪个渠道。 这有助于避免将有用的信息和洪水混在一起。

另外，切换到Slack给我们带来了一些很好的自动化和与其他服​​务（例如存储库管理系统或Bug跟踪器）集成的机会。

• 音频和视频通话-Skype for Business。
• 我们在吉拉执行任务。
• 知识库存储在Confluence中。

任务计划，执行和控制

当我们建立沟通时，在团队内部设置，控制和完成任务的问题就变得很重要（稍后我将与客户讨论这方面的问题）。
我们没有一个任务，任务的优先级，准备状态等的完整列表。除了明确，透明和可追溯的计划外，还存在自发的短期计划和执行。

为了解决这种情况，我们开始使用Bugtracker（实际上，我们尝试了其中的五个）。 开始出现项目总体方向的轮廓，了解某些任务和整体状况的状态。 但是，在使用Bugtracker时，我们面临着缺乏纪律的问题，这开始使我们的许多工作贬值。 并非所有任务都在Bugtracker中启动，现有任务并非总是更新，等等。 简而言之，该项目的状态图已不再相关且可靠。

为了解决这个问题，我们开发并实施了自己的任务管理文化：

• 在启动相应任务之前，请勿执行工作。 这有助于保持项目历史和团队工作的最新状态。
• 处理任务时，有必要及时更改其状态。 在我们的例子中，四个状态就足够了：“待办事项”-任务的开始状态，“进行中”-正在进行的任务，“待命”-他们开始执行的任务，但工作已暂停（我们正在等待一些其他信息） ），“完成”-任务已准备就绪。 任务的准备情况必须以某种方式由团队中的客户或经理确认。
• 随着时间的流逝，任务和项目的数量显着增加，因此我们将工作的总清单划分为单独的子项目，并且应该根据该子项目的清单来启动任务。
• 必须为任务分配优先级。 这有助于了解为了使项目获得最大收益，需要按照什么顺序执行哪些任务。
• 定期检查任务及其优先级。 由于项目的存在和发展，以及业务计划有时会更改，因此随着时间的流逝，某些任务变得越来越不相关，甚至需要删除。
• 有关在口头上或在聊天中以书面形式执行的任务的一些关键讨论需要在任务本身中确定最终解决方案，因此，当我们完成任务时，我们总是会看到有关其及其历史的最相关信息。 经过一系列讨论后，问题的最初陈述常常转变为完全不同的情况，我们经常需要对此进行监视。
• 如果任务从一组专家转移到团队中的另一组，则转移小组必须在其中修复必须转移到下一组的所有必要知识。 例如，设计团队在将任务转移给开发团队之前，必须附上模型和开发所需的所有文档。 这避免了不必要的问题，分心和上下文切换。
• 将提交附加到任务。 使用一些命名提交的规则，我们自动将链接附加到GitLab任务的提交。 这极大地有助于开发人员了解谁，什么，如何以及何时执行此任务。 相反，通过正确命名的提交，您始终可以找到包含更改原因的任务。

客户沟通

我们需要解决的下一类困难是与客户合作。 我们必须根除的第一件事就是在单词中设置单词。 如果我们在部门内部引入写作文化，那么是时候将其扩展到外部联系人了。

另一个经理喜欢与开发人员接触已经不是什么秘密了，用言语告诉他需要做什么，在屏幕上戳手指以说服力并离开，希望一切都能按时完成。 在这种情况下，经理和开发人员可以由负责所有这些任务的产品所有者和开发团队的特定经理代替。 结果不会改变。

这种方法存在几个问题：

• 言语和手势中所说的话（至少部分）会在明天（最好是在后天）被遗忘。 与其说一些小事情，不如说是彻底忘记任务的危险。 同时，无法以任何方式确认您是否将其交给某人或某人答应您至少要做某事。
• 通常，这样的问题陈述是相当混乱的，并且其中没有深入的细节。 结果，很难弄清丢失的信息。
• 正如前面所讨论的，用语言陈述问题可以使腐败的人不愿学习以书面形式表达自己的思想，以便他人理解。

当您有许多客户并且每个客户都有自己的特征时，很难与每个人建立一个单一的工作订单。 理想情况下，我们希望将所有客户带到一个错误跟踪器，他们可以在其中设置任务，设置优先级，讨论细节，接受工作。 但这仍然是不可能完成的任务。 但是，我们找到了一种折衷方案，其中任务以严格的书面流程一起流入我们的公司邮件部门，而就我们而言，经理启动并根据我国已经建立的规则将其引导到错误跟踪器中。 任务不再丢失，遗忘，存储在特定人的脑海中，或者由于所需专家的不完整组成而受到讨论等。

接下来，我们面临一个更重要的问题：客户很难制定任务。 客户在制定技术团队的技术规范时并不总是足够胜任（或者几乎总是不胜任）。 这是正常的。 人为因素不容忽视：当客户本人无法完全提出要求时，向客户提出要求会使团队感到尴尬和不自在。 成熟的专业团队的标准之一是能够帮助客户确定其问题，要求和解决方案。

通常，客户会提出实施自己发明的解决方案的请求，而不是提出问题。 为了不让自己或客户对“在餐巾纸上”草拟的ToR工作结果感到惊讶，我们为客户创建了基本的问题清单。 在这些答案的基础上，客户不仅更容易理解他的真正需求，而且开发团队也更容易理解。 然后该轮到提出一些有启发性的问题来澄清或确定需求了。

因此，在第一次与客户会面之前，我们要求您（尽可能多）预先填写并发送给我们此清单，以便以后您不必在相同的问题上浪费时间，而是立即开始富有成果的对话。 值得注意的是，在与客户互动时，不仅要弄清客户提供的答案，而且要根据客户提出的问题来帮助他确定他们可能没有想到的要求，这一点很重要。

给客户的问题清单：

• 该项目的目的是什么？ 这能解决什么问题？ 它具有什么商业价值？
• 这是解决此问题的唯一可行方法吗？ 如果没有，还有哪些其他选择？
• 整个项目是否有任何一般要求？ 例如，如果它是一家在线商店，那么它必须完全遵守管理在线交易的法律。
• 有功能要求吗？ 部分应该做什么（页面，项目）？ 例如，该部分应提供有关公司产品的信息，并通过页面上的表格，收集那些希望对产品提出疑问或购买的人。
• 是否有非功能性要求？ 他应该怎么做？ 例如，页面打开时间应不超过5秒。
• 附加要求。 自由格式，您可以在其中释放灵魂。

我们必须面对的另一个问题：任务同时来自各个方面。 当有许多不同项目的客户时，每个人都希望将自己的任务放在最高优先级。 在一般理想情况下，可能无法100％解决此问题。 我们如何生活呢？ 随着任务制定和管理中的纪律以及敏捷方法学的某些要素的引入，我们的任务池变得更加简化，对外部观察者透明，最重要的是可预测的。 我们已经在团队内部建立了订单和计划，我们只需要加强与客户的反馈即可。 在讨论优先事项，截止日期和计划时，我们学会了如何进行辩论，而不是盲目地投入工作并不断扑灭熊熊大火（实际上并不总是很重要，也不一定总是着火）。

另外，作为本段的一部分，当客户或经理飞入，“放下”任务时，我们试图消除经典的反模式“鸥管理”，并且完全放心地相信，一旦他完成任务，他肯定会获得出色的结果。 如实践所示，这种方法的结果并不是最令人印象深刻。 怎么处理呢？ 这里也没有通用的建议，没有改变人们行为的魔术短语。 为此，您需要交谈，教育，解释，展示，可以说教育。 只有教育性工作，以及非常直观或非常可衡量（最好同时包括两者）的正面和负面例子，才能充分克服“海鸥管理”问题。

开发与运营

我们的最后一个重要问题是开发和运营部门之间的沟通问题。
我们面临的经典情况是，开发人员对服务器的工作原理不太了解，而第三方管理团队却对应用程序的工作原理并不了解。 这两个领域交界处的每一个困难都给我们带来了痛苦和大量的时间。 甚至很难诊断出问题的哪一方面：

• 您在那里编程了！
• 不，那里的服务器有东西！

在这种情况下，帮助我们的是，一个精通管理的开发人员出现在团队中。 他能够与每个小组用其语言进行交谈，并从双方诊断每个问题。 差异开始减少，但我们仍然与这个人联系在一起。 为了解决所有这些问题，他开始帮助管理员了解应用程序和程序员的工作方式-服务器上正在发生的事情。 我们增加了语音编写文档的说明，不仅获得了整个团队的知识，还获得了开发和运营部门更协调的工作。 是的，在血腥的企业中，有很大一部分由特殊的团队和合格的人员来设置一切，以便开发人员甚至不知道服务器上的工作方式和位置。 但是，在小型团队中，最好是在人员中发展这种水平的能力，并且至少要有一位在这方面已经很好发展的员工。

发展历程

与此同时，我们着手发展发展文化。
我不会专注于技术部分，现在它已经是事实上的标准，几乎每个人都对版本控制系统，CI / CD以及其他开发，组装和部署工具的必要性缺乏了解。 我只会停留在发展的柔和时刻。

• 代码风格 开发并明确批准代码设计规则非常重要。 首先，从美学的角度来看，在项目中看到一个和谐的外观是令人满意的，而不是看到风格和标准不同的动物园。 其次，它提高了代码的可读性，并且众所周知，程序员在大多数时候不编写代码，而是读取别人的代码。
• 命名提交 。 我们引入了一些命名提交的规则，因此通过提交的名称可以清楚地知道进行了哪些更改，由谁进行以及在什么任务内进行了哪些更改。
• 代码审查 。 我们的项目和团队的细节使得我们没有进行强制性的代码审查，否则就无法将我们的代码投入生产。 但是，我们制定了一个规则，即至少一个人查看同事推送的代码。 这既可以帮助您发现所有缺点，也可以引入其他想法，还可以与系统的所有部分保持同步。 随着项目数量的增加和复杂性的增加，代码审查变得尤为重要，这就是为什么每个开发人员都不再有足够的时间来处理所有项目以了解其所有细节的原因。
• 尽早在团队中调整架构 。 经常发生这样的情况：为了更快地创建功能，前端开始做自己的事情，后端迅速开始自己的事情，然后发现它集成起来很困难，或者根本没有集成。 在大型功能的开发中，我们预先讨论了体系结构，数据交换格式等。因此，集成不再是漫长而痛苦的。
• 简历驱动的开发 。 这是一个问题，开发人员将新的（新的，时尚的，高薪的）技术拖到项目中不是为了项目，而是为了在简历中打勾。 我们欢迎新技术并尝试以技术方式开发我们的项目，但是，重要的是要保持平衡，以便在合理的时间范围内取得技术进步并成功完成项目。 在这个棘手的话题中，有两点很重要：客户不要推迟截止日期，以免开发人员休息，并且开发团队（或至少主管团队的主管或技术团队）不仅关心开发他们的LinkedIn个人资料，而且也关心项目的福祉。一般而言。

重构，技术债务和持续改进的原则

我们的部门开始围绕外包商现有的项目团队进行组建。 自然地，那里没有文档，没有人遵循代码的相关性和质量。 既然我们知道我们仍然需要长时间工作，维护和开发它，所以决定花一部分时间在项目中进行整理—重构，删除不相关的代码等。

由于项目很大，因此其中的熵水平也很高。 我们意识到，一坐就坐，不可能在身体上克服一切，在道德上放弃这种艰巨的工作。 我们决定应用日本持续改进的原则“改善”。 我们将技术债务逐渐分成许多小部分，但定期关闭这些小部分，从而不断修改和改进项目以及团队本身的工作。从道德上讲，这不会造成任何不便，但同时对新功能的开发和业务需求的覆盖范围没有重大影响。一年半后，我们发现旧的技术债务已全部偿还，这为我们提供了从根本上将复杂性和重要性提高到新水平的功能。

当然，这并不意味着我们现在没有技术债务。随着项目的发展，发展，壮大和发展，它肯定会建立起来。但是，我们会仔细监控它，将其放到一个特殊的任务池中，并定期花一些时间来付清它。这种持续不断的技术负担使我们能够在新功能的开发和对旧功能的高质量支持之间找到平衡。

在我们的案例中，我们（开发人员）能够解释并向企业展示偿还技术债务的重要性。我们是如何做到的？在实践中，我们已经演示了以下情况：如果您不重构或对当前项目进行其他结构性更改，则原则上将不可能开发新功能或更改旧功能（或可能，但速度要慢几倍）。

实施敏捷方法

敏捷方法论的一些思想的实施使我们能够提高团队内部和业务的透明度，使开发更可预测，更灵活，结果更稳定。

我们要做的第一件事是组织团队中的日常站立训练。由于团队是分散的，因此Slack为此分配了一个单独的渠道，每个员工每天早上要写下三点：他昨天做的工作，他今天打算做的工作，是否有任何阻碍他工作的问题。禁止在此频道中泛滥，讨论某人的任务或问题。此通道严格用于汇总有关事务状态的信息。其余讨论应在适当的主题渠道中进行。这使团队中的每个人都可以了解他的同事在做什么，总体上该项目正在发生什么，可以并且应该得到帮助。如果没有人站起来，问题就消失了，经过很长一段时间，突然发现任务还没有准备好，现在很明显谁需要帮助，需要做些什么来使团队工作更有效率。

接下来，我们决定开发sprint。每天结束时的每个星期五，我们都会进行冲刺回顾，查看计划的任务，准备的任务，未准备的任务以及未完成的任务，为什么会发生。我们考虑我们遇到了什么问题以及如何避免将来遇到类似的困难。然后，根据团队中不同领域的工作量和业务优先级，计划下一周的冲刺。结果，在一周开始时，所有开发人员都知道该做什么和以什么顺序进行，并且该企业知道在不久的将来将满足其需求，并且已经可以为下一个冲刺形成自己的“愿望清单”。值得一提的是，我们没有幸免于可能破坏我们的冲刺计划的突发任务。在这种情况下，您需要根据工作的特定性质采取行动：此类任务多久出现一次？多少钱可以预测吗？在开发的特定案例中，我们通过实验计算出平均有多少时间落在了计划外的任务上，并尝试在冲刺​​中留出一定的余地。另外，值得注意的是，在开始冲刺工作之后，我们能够明确找出在计划外的入口上交付给我们的工作量，分析并减少该数量，与客户仔细讨论优先事项，并清楚地表明当前对立即获得最必要功能的渴望有何影响整个团队的整体生产力。计划外任务的平均时间是多少，并尝试在冲刺​​中留出余地。另外，值得注意的是，在开始冲刺工作之后，我们能够明确找出在计划外的入口上交付给我们的工作量，分析并减少该数量，与客户仔细讨论优先事项，并清楚地表明当前对立即获得最必要功能的渴望有何影响整个团队的整体生产力。计划外任务的平均时间是多少，并尝试在冲刺​​中留出余地。另外，值得注意的是，在开始冲刺工作之后，我们能够明确找出在计划外的入口上交付给我们的工作量，分析并减少该数量，与客户仔细讨论优先事项，并清楚地表明当前对立即获得最必要功能的渴望有何影响整个团队的整体生产力。现在迫切希望获得不必要的功能会如何影响整个团队的整体生产力。现在迫切希望获得不必要的功能会如何影响整个团队的整体生产力。

我们也从长发行版转变为短发行版。以前，我们收到传统知识，数周或数月完成了整套功能，然后才向客户展示。结果，通常结果是客户要么改变了主意，要么就没想到这一点，因此我们开始重做全部或部分已完成的工作。更改现成的大量功能是一种可喜的乐趣。现在，我们将尽早演示每个功能，以便客户做出决定-这是他真正想要的，还是需要更改的功能。他批准或发送它进行修订的速度越快，我们将投入的劳动力就越少，因此，该功能投入生产的速度就越快。结果，功能开始更快地投入生产，假设被更快地测试，并且项目进行得更快。

总线系数

由于我们的团队很小，我们立即开始考虑人员轮换期间可能遇到的问题。特定的人已成为某些知识的唯一保管人，项目已充分扩展，因此我们开始发展知识存储和管理的文化。

知识文物的积累从特定的人的头脑转移到了实际的书面世界，从而帮助消除了这个问题。即：

• 仅当Bugtracker中有任务时，才执行所有工作。这使您可以完整地记录项目中的更改。
• 如果我们在聊天中或集会中的某个地方讨论了任务的变化，我们必须在任务本身中反映此讨论的结果。
• . , Gitlab. , .
• Confluence , - , .
• - postmortem « — — — ».

仍然存在良好的实践，当然，您需要知道该度量而不是将其提高到绝对值：如果系统仅询问您您所知道的某个部分，那么建议编写有关该文档的文档并通过其链接进行响应。因此，您无需再回答这个问题，也不必问其他人。

这种维护知识工件的方法反复地帮助我们找到了有关项目中那些可能会丢失的部分的信息。他还大大减少了人员轮换期间项目和团队的风险。最后一个示例：我们快速而轻松地检索了有关业务逻辑，操作原理和工具部署方法的信息，这些信息是由两年前辞职的员工完成的。

如果我们将站立式和冲刺式的技术应用于这项技术，那么总线系数将进一步降低。不久前，我们进行了一个实验：一个开发人员正在休假，另一个开发人员在工作。那时，当第一个去度假时，第二个去度假。实验的实质是不要写任何解释性的信件，消息，不移交案子，看看一个人在长假后了解在他不在的情况下发生了什么，改变了什么，确切地如何规划以及未来的计划会有多困难。如实践所示，查看bugtracker，提交，文档，站立和冲刺，使员工可以轻松进入业务流程并自主地继续工作。

结论

最后，我想指出，以上问题都没有立即得到完美解决。组织变革始终是一项长期而有条不紊的工作。您不能只说“现在我们这样做”，并希望现在一切都会有所不同。您做出的任何决定，组织的任何事件都需要人员的控制，培训和启发，需要时间使团队适应新方法，并使方法本身适应特定情况。我还注意到，将方法论强加于人是一个非常费力且效率低下的过程。人们会休息，忘记，甚至破坏。

为了使所需的更改在团队中开始，团队本身必须要进行这些更改。有必要监视她的工作方式，确定问题领域，意识到这些问题，找到解决方案，然后再执行它们。当然，并不是每个团队成员都应该并且愿意这样做，但是如果有人看到了这些问题并提出了解决方案，那么他首先将启发团队。

分享您的知识，观察力，经验，争论，展示和证明问题出在哪里以及可以采取哪些步骤解决问题。只有这样，才能尽可能有效地进行重大的组织变革。即使您是领导者，也想推动自己的立场和决定-尝试尽可能有说服力和说服力地做到这一点，从而节省实施时间，并使团队免受不必要的负面影响。积极技术开发小组负责人Evgeny Antonov

发布