我们如何克服交付俱乐部的不确定性

朋友，大家好！我叫Kolya Arkhipov，我负责Delivery Club的研发工作。



我们的团队在FoodTech平台内解决科学密集型任务：我们基于算法和数据开发组件，而DC平台中有很多组件。在解决过程中，我们在业务和开发方面都面临许多不确定性。



事实证明该材料非常丰富，希望对您有用。因此，我建议放入茶壶并冲泡美味的咖啡，在撰写本文时我自己做了。



今天，我将向您介绍我们的团队在过去一年中已经通过的比赛。这种比喻本身就产生了-我们在一家充满活力的公司（俄罗斯市场领导者FoodTech）工作。我们正在迅速发展不同的业务领域，这确实在推动！我们不仅成功地到达了终点线，而且在比赛中也获得了很多见识。这就是我想与您分享的。

该文章发表在RIT ++ 2020会议的报告之后。对于那些喜欢视频的人，请在文章末尾查找。

水壶已经沸腾了吗？超！因此，今天将要讨论的是：

1. 研发和不确定性。我们面对的是什么。
2. 实验。我们如何以及为什么在战斗中指挥他们。
3. 可测量性。让我们讨论指标的选择和风险。
4. 自治。DC Tech的我们如何适应GIST框架和内部来源方法。

绿灯，离合器，首先-走吧。

研发与不确定性

在某些公司中，研发团队从事新技术的基础研究。此类研究的目的既可以是当前流程的开发，也可以是全新的业务领域。例如，几年前区块链就是这样的技术。



马上，我们在谈论其他事情。 Delivery Club的研发工作是解决应用问题。我们的业务发展迅速，订单数量不断增长，并且我们的大部分内部流程都基于数据和算法。随着输入数据量的增加，某些算法不再有效，而昨天完全适合我们的那些组件，今天我们经常发现它们无法使用。



正如您可能已经猜到的那样，此类问题通常缺乏确定性，因此，各方面都存在许多不确定性。让我们突出显示关键的一些：





让我们仔细看看我们面临的挑战以及这些挑战是否真的存在。



如何实现目标



我们始终清楚地了解业务目标-我们计划朝哪个方向移动，我们必须走到哪里。但是，在研究任务时，如何实现这个目标还远远不能立即明确。采取哪种策略：立即通过实验还是大规模推出该功能？通过模拟或实验来构建环境？选择很大-眼睛睁大了。



到底值得做什么



好的，我们了解了业务目标，并同意了我们将遵循的策略。现在是时候决定我们将要使用的一组特定功能了。如何选择它们，要在积压中包括什么，按什么顺序：您不仅需要确定“完全值得做什么”，还需要确定谁将是我们领域中最专业的人。



当我们可以达成目标



时机对于业务而言绝对重要。研究既有趣又有趣，您可以在数据中寻找新功能，研究算法，并从其他国家的同事那里读有趣的笔记。但是，对于企业而言，重要的是要了解何时可以实现目标，因为通常不需要在错误的时间启动功能-FoodTech市场现在非常活跃。



为什么有人根本需要我的代码



最后的不确定性远非重大，而是激励开发人员的问题。研发很大程度上是实验性的开发，因此，我们的代码并非总是扎根于生产中。刚开始，我们非常沮丧，因为我们不知道为什么做出该功能，并且全心全意，并且业务部门决定该功能不起作用，需要将其锯掉。问题-我为什么要这样做？为什么有人需要我的代码？ -经常和我们一起出现。在此过程中，我们意识到了如何以及应该如何使用它，现在我们确信这是最需要首先克服的最关键的不确定性之一。



因此，在填补了如此大的坎s之后，我们将所有问题集中在一个地方，并意识到，为了幸福，我们在这些不确定性的交汇处缺少三个过程。

1. , , .
2. . , , . , - , , .
3. , , - . . IT- ( ), , , , 2-3 . — , .

在下图中示意性地显示。



实验将回答有关如何实现目标以及该做什么的问题。通过度量标准，您可以非常清楚，透明地回答此代码是否应真正保留在生产环境中的问题。完全自治将有助于评估并按时完成。



我们不会停止。离合器，二挡，迅速发展起来。

实验

考虑一个自定义的快递自动分配平台。她的任务很简单-召集三个市场参与者：我们的合作伙伴，物流人员（即他们的快递员）和客户，以便使所有参与者满意。也就是说，当订单到达时，我们必须选择一名快递员，该快递员将在餐厅准备好饭菜时准确地到餐厅，然后迅速将其取走，并按我们承诺的时间将其热辣美味地交付给客户。



看起来很简单，在这里您可能会说-足够的理论！现在该进行真正的发布了。



我同意您的意见，但让我们继续进行一些实验。让我们看整个图片。

1. - — . — , , .
2. — . . — , .
3. — Just In Time. , : , , . , , , . , FoodTech- : , . , .

让我们仔细看一下产品增量背后的过程。







3.1假设。它可以用文字表达或示意性显示。最主要的是要明确说明为什么它应该工作。也就是说，实验必须经过理论训练。



3.14发展。我不会在这里居住，本文将介绍有关我们开发的更多详细信息。我们使用Scrum，进行两周的迭代，完成所有必需的活动。



3.2准备。接下来，您需要准备一个实验。也就是说，我们需要确定在此实验期间要与之通信的地理段或受众。并选择与结果进行比较的细分。



3.3实验。接下来，我们开始实验本身。重要的一点：即使在开始之前，我们也同意我们将要监控的业务指标。今天让我们离开对技术指标的讨论，它告诉我们实验已经启动并且技术上是稳定的，我们将更多地讨论业务指标。我们一定会修复红色标志-这些是我们在实验期间不应该超过的一些阈值。



3.4分析。我们已经积累了很多只有我们才能拥有的很酷的独特数据。不从中提取有用的信息，即就所检验的假设的有效性得出合理的结论，并强调有关我们服务对象的新事物，这很奇怪。



3.5结论。可能是此过程中最重要的一点。在我们的例子中，输出总是按三个按钮：

• 将实验进一步推广到下一个地理区域或下一个受众群体；
• 如果出现问题，回滚；
• 继续。在某些情况下，我们会看到没有考虑到第三方因素的影响，因此，我们无法得出明确的结论。在这种情况下，我们决定继续。

真实实验

终于到了在实际示例中了解其工作方式的时候了。你累了吗？有趣的开始。



返回到自动分配平台。在此之前，我们建议“准时生产”方法对于我们减少交货时间非常酷。我们将其与当前的分配策略（称为贪婪算法）进行比较。



首先，我们将证明该假设是正确的。

贪心算法

它的主要功能是立即开处方。订单到达平台后，我们会为该订单寻找合作伙伴的最合适快递员，立即任命并通知该订单快递员。因此，我们将优化寻找快递员的时间。但是这种方法并不总是有效的，因为情况可能在一分钟内发生变化：新订单到来或另一位快递员被释放。该算法不再对此作出反应。下面是一个插图。





在此示例中，我们总共需要45分钟来挑选两个订单。看来我们可以做得更好。

准时

该算法的任务是准确选择要在准备好订单时到达餐厅的快递员。它会给我们什么？由于以下事实，它将最终减少交货时间：

• 快递员将减少在餐厅的时间​​；
• 我们将更优化地选择快递。

从技术上讲，这非常容易实现。收到订单后，我们会立即选择快递员，但我们不会将订单告诉他，因此进行了“虚拟约会”，并给了自己时间来更改选择。而且，只有到餐厅的路径等于准备订单的剩余时间时，我们才能最终决定（是否将订单转移到快递员）。示意图-在下图中。







因此，我们仅需30分钟即可选择订单，比上一个案例少三分之一。



我认为，该假设是合理的，我们正在将其发展。按照约定，我们将不详细考虑开发过程。

让我们继续准备实验

在我们的情况下需要准备什么？并不是很多：A / B测试的时间，实验的地理位置以及我们将与之进行比较的时间。我们在某个城市停下来，选择了条件，以最大程度地减少一种约会策略对第二种约会策略的影响。



我们一定会与企业协商有关危险信号及其反应的信息。危险标记是我们在实验期间不希望超过的业务指标阈值。如果交叉，那么在绝大多数实验中，这就是回滚。但是也有例外，当我们确定不是因为我们而发生交集时，而是其他因素的结果。在这种情况下，我们有时可以决定继续进行实验。



还有什么需要准备的？与控制室的同事达成共识，他们实时观察到，按订单操作一切都很好。对于他们来说，我们的变化是可见的，因为在我们立即为快递员下订单之前，但是现在我们不这样做，我们给自己一些时间来改变主意。这就是为什么应该警告同事有关计划中的实验的原因。



好吧，继续前进。准备了一个实验，进行了实验并得到了结果。接下来是有趣的部分-分析。

实验分析

我们同意缩短总交货时间，突然之间有四个时间表。这里值得解释。启动实验时，不要只看一个关键指标，而要看对业务至关重要的几个业务指标，这一点很重要-在这种情况下，我们可以大大降低假设失败影响平台实际流程的风险。坦白地说，我们在实验开始时就犯了这样的错误，有时它们会导致非常不愉快的后果。但是错误是好的，我们可以从中学习。



让我们看一下结果。我们将显示没有特定值的图，因为本文的目的不是详细分析Just In Time算法的效率。在进行实验时，我们希望更多地专注于我们的方法。出于同样的原因，我们将不再赘述进行A / B测试和确定结果的统计意义的理论，这对于下一个出版物甚至整个周期来说都是一个巨大的话题。

• « ». , , . , . , — , . , . , , . , . , , (/), — , , . -, .
• « ». . , , , . , . , .
• « » « ». : . .

结果，我们减少了关键指标（1），减少了非常重要的指标（2），其他两个关键指标的稳定值（3，4），红色标志没有点亮。这使我们可以得出有关实验成功和所检验假设有效性的结论。



类！您是否继续下一个假设？它极富娱乐性，旨在改善每个人的生活！但是，不仅仅如此。也许还有最重要的步骤之一，我们不应该忘记。这是按三个按钮之一：

1. 推出
2. 回滚
3. 继续

在实验过程中，团队必须有一位同事，其角色将完全负责该功能，然后按这三个按钮之一。开始时，我们遇到了一些忘记了此步骤的情况，结果，我们收到了几十个同时启动的实验，但每个实验的状态都不为人知。他们给出了积极的结果，但没有完全铺开，这对业务没有效果。此外，我们不得不花费大量资源，只是为了记住细节并按部就班。但是，我们再次从错误中学习。

真实实验

让我们简要介绍一下为什么我们要立即在战斗中进行试验。这种方法通常与分析模拟环境相对，分析模拟环境基于历史数据可以以一定的准确度回答如果实现此功能将是什么。



为什么我们为自己选择第一种方法？有两个原因。

• -, .
  
  , , . , - , , . — .
  
  
  
  . .
  
  
  
  ? , , , — . , , , , , . , .
  
  
  
  值得诚实的是，这是一种相当冒险的方法。使观众，客户，业务失望的风险。本文主要讨论如何减少此类风险：仔细准确地选择指标（几个）并实时监控它们。万一出问题了，我们立即关闭实验。

• 第二个当然是速度。在战斗条件下进行的实验将显示更准确，更快的结果。

在进一步运行之前，让我们修复一些小胜利。





一个透明的实验过程为我们提供了如何实现目标的答案。通过立即在真实条件下进行测试，我们开始更好地了解我们的听众。因此，开发团队拥有足够的专业知识，可以提出解决业务问题的特定功能。



不错，但这还不是全部。现在是时候更多地谈论可测量性了。同时，我们打开第三层，向地面吹气，吹起风。

可测性

为什么我们根本需要指标？主要是为了确认假设或减少失败假设的影响。假设即使从理论上讲也是有根据的，但并不总是会发生。当他们射击时，有时在膝盖上。

• -, FoodTech, : , , , .
• -, , , . , , , . ! , , , . , , -.

我们的经验表明，有多个指标才是一个好的秘方。一个目标指标-改进它；还有其他一些关键问题-我们一定不能放弃。



引入一个统一的监视空间，在该空间中可以同时查看业务和开发。它不必是一种工具，我们可以使用两种：Metabase和Grafana，但是将来我们计划选择其中一种。最重要的是，应该有一个单一的空间，业务和开发部门的同事都可以看到。并确保标识红色标志。

红旗

是的，这些是我们在实验期间不应该超过的一些指标阈值。值得与企业就反应达成共识，如果反应已经通过，并在其上发布警报。



还有一个小小的胜利：我们回答了一个问题：“为什么所有人都需要我的代码”。让我们不要忘记她！





让我提醒您，开发方面的不确定性是我们并不总是理解为什么我们的代码没有保留在生产中，并且坦率地说，我们对此感到难过。通过采用从开发到业务指标的对等沉浸式方法，我们不仅增进了对客户解决方案的了解，而且通过关注最终结果为解决业务问题提供了一定的推动力。



好的，我们找到了实验和透明的流程，指标和可测量性。终点线在前面，我们以最快的速度打开第四条直到胜利。

自治

只有当我们在业务和开发方面都变得自治时，上述所有工作才可能可行。

要旨

在这里，所谓自治，是指做出决定时的最小依赖性。我们在业务方面做了哪些工作以快速做出决策，而不会淹没在审批流程中？我们已经实施了GIST框架。





这种方法是目标，想法，分步项目，任务。公司有明确的业务目标，管理层可以透明地与所有员工进行沟通。为了实现这些目标，员工会提出想法。可能有十二个或一个想法。重要的是，一个想法还不是一个项目。这些是我要实现的一些方法。分步项目-这些已经是项目：实现这些想法的相当大的功能。在我们的“及时”示例中，目标只是分步项目。最后一个是我们习惯的任务-这已经是一个分解的分步项目，以人工成本估算。



那么，该方法如何帮助您实现自治？当我们建议使用此功能（及时）时，企业会透明地看到：

1. 实现此功能的大小和成本。
2. 他实施了什么主意。
3. 公司的具体目标是什么（影响）。

接下来，我们需要根据相同的标准将其与相邻的分步项目进行比较：成本，影响。我们召开会议（他们经常与我们开会），讨论，确定优先次序并做出决定。



它看起来非常简单明了。在我们的情况下，它是有效的：企业快速制定决策，我们很高兴。但这只是迈向自治的第一步，因为从开发的角度来看，我们也不应该受到阻碍。

内部来源

就像开源一样，仅在公司内部。Delivery Club架构是微服务，现在有一百多个。通常，为了做出功能，不仅需要修改我们团队负责的组件，还需要修改邻近的服务。在这里，我们有两种方法：

1. 在其他团队的待办事项中进行改进，并同意他们会做到。
2. 自己做。

在我们的改编中，该过程如下工作。有一个很大的“及时”功能，它会影响三组服务：

• 负责研发的自动分配平台，
• 物流平台
• 与合作伙伴（餐厅和商店）互动的组成部分。

我们这样做：

1. 将所有任务收集到研发团队的积压中；
2. 我们在团队中确定优先级并进行分配，其中哪些人将优化哪些组成部分；
3. 我们同意物流和合作伙伴团队的技术负责人在实施方面的细微差别；
4. 我们发展自己，同事进行审查；
5. 然后我们测试自己；
6. 我们已经为服务所有者提供了批量生产的服务。

投入生产后，这些改进仍属于拥有这些服务的团队的责任范围。



老实说，这种方法并不完美，并且存在风险。主要的是时间。通常，我们修改组件的时间是服务所有者的2-2.5倍。



但是好处也是显而易见的，它远远超过了实施中的小延迟-它是可预测的。在此必须注意，其他团队有自己的待办事项列表，自己的优先级，并且通常不能“紧急”执行我们的任务。因此，我们的业务截止日期是现实的；它不会受到其他团队优先级可能变化的影响。



因此，恭喜您-完成，胜利！





我们已经实施了GIST框架，以进行快速，透明的决策，并采用了内部源代码来实现开发中的自主权，现在，所有难题的各个部分都已组装完毕。是时候结束了，这是一场有趣的比赛，谢谢您的参与！让我们总结一下。

结论

• 实验是实现目标的透明有效的工具。
• 在真实的环境中进行操作，我们研究了受众，这使我们每次都能进行越来越有用的更改，并了解为什么并非所有功能都应保留在生产中。
• 但是为了避免混乱，您需要一个清晰的过程，角色分配和任命负责人。
• 在实验的活跃阶段和分析过程中，值得一次监视几个关键指标，并且不要忘记得出结论（在我们的示例中，请按三个按钮之一）。
• 在开发中做出快速决策和自主权有助于取得成果并保持团队的动力。

RIT ++ 2020会议报告的录像带。





就这样，谢谢您与我一起参加这场比赛。我确信我们才刚刚起步，仍然面临着巨大的挑战。我很乐意与他们分享，很快再见！