哈Ha！正如我在上一篇文章中所承诺的那样，我将继续向您介绍Delivery Club Tech。今天我们将讨论产品转型。
巧合的是，我于2018年10月到达DC时，团队中所有流程都进行了全面重组。那时，IT部门乃至整个公司都面临着新的挑战。显然，旧流程不满足新要求。他们主要关注上市时间的下降。
我想告诉您的是这些变化，新的挑战，新的团队结构，没有项目经理和技术分析师的情况下我们的工作方式以及产品开发方法。
2018年10月，我担任消费者总监。这是我前往交付俱乐部的起点。有必要在指导中组建产品团队，描述流程，对其进行形式化并将其扩展到所有其他领域。此外，任务是为团队导出绩效指标并从头开始开发招聘框架。
团队特色
最重要的挑战是要在开发过程中实现可预测性和透明性。当时没有性能指标的事实使情况变得复杂。但是可以肯定的是：发布不是定期发生的，并且其构成只有在发布本身时才清楚。
另一个问题是没有围绕产品组建团队。与企业的这种复杂的交流，因为同一位开发人员可以参与完全不同的项目，因此没有明确地专注于特定任务。因此，起初决定重建IT部门的结构，并从平台团队转移到产品团队。
使用平台方法，后端人员分开坐着，前端人员分开坐着，每个团队都有一个负责分配任务的团队负责人。这种结构的明显缺点是：开发人员没有沉浸在过程和产品中，他们对共同的目标不感兴趣，团队没有重点关注，并且也没有产品专用的资源。结果，开发人员无法集中精力，目标仍然无法实现。即使可以奇迹般地实现目标，但由于产品经理和利益相关者之间缺乏沟通，所以往往没有实现最初的计划。
决定要做的第一件事：一个团队-一个产品。资源被分配，也就是说，团队仅针对该产品执行任务，而没有其他任务。研究类似产品的团队构成了发展方向。第一次转换的结果是，获得了4个方向：
- 消费者
- 后勤
- 供应商
- 内部
决定要做的第二件事：为每个团队分配一名产品经理。他也是团队之一。产品经理制定产品变更策略，形成团队关注的产品指标，并为冲刺设定目标。
结果，我们得到以下单元格：“产品经理-团队负责人-开发-质量检查”。我们包括后端和前端开发人员作为开发人员，但是也有没有前端的团队。前端是Web Angular和JS，或iOS / Android。
现在每个团队平均有5±2人。这是为什么？我们没有立即得出这个公式。我们的统计数据表明，这是团队的组成部分，可让您实现最可预测的结果。也就是说，该团队能够采用足够的功能来对产品进行重大更改，但是与此同时，计划的复杂性仍然比拥有更多人时要低。即，计划误差变得最小。
在一段时间内，我们尝试了团队中的角色，我们有移动开发团队负责人（iOS / Android）和后端团队负责人。但是我们最终得到一个矩阵结构：
- 一个团队负责人（通常是后端人员），在他的直接报告下拥有质量检查，后端和前端提供者。
- product- « — — QA».
- — . . , QA- , CI/CD, QA- .
- - , .
- .
我们的另一个特点：我们没有项目经理和技术分析师。最初在Delivery Club中就是这种情况，我们决定不更改它。还记得我们专注于产品的团队有问题吗？那么，为什么要在团队和产品经理之间建立中间人呢？对于我们而言，重要的是，团队首先要关注其功能如何影响最终用户，而不仅仅是在Jira中关闭门票。为此，人们需要将自己沉浸在上下文，领域，业务甚至产品指标和财务指标中。
结果，开发团队与产品经理之间的对话正在进行。开发人员不仅要从产品经理那里获取任务清单，然后去开发所有这些东西，而且他们可以在几个小时内来找他，例如说：“嘿，我们可以使这里的按钮更简单一些，但要快一周”，显示出来在号码上，产品经理会说“确定”。
因此，技术团队独立执行技术分析，评估和分解的任务，然后与产品经理计划冲刺。为使此工作正常进行，我们在开始前一周开始了Sprint。这是下一部分。
冲刺开发和计划
预先计划
冲刺开始前一周，产品经理为您提供了案例和设计，回答了问题“需要做什么？”。技术团队决定如何进行以及何时准备就绪。
为此，团队需要一个星期的时间，在此期间，团队负责人，开发人员和QA会面，讨论技术细节，进行分解，并通过计划扑克进行评估来重置。在此期间，质量检查人员列出了一系列测试用例，然后将对其进行测试。
规划
团队完成分解和评估后，便开始计划。所有任务分为8小时。要计算sprint中的任务数，我们将员工数乘以两周迭代的80小时，然后将结果乘以0.8的关注因子。
进一步的任务被击败，其中只有三个：
- 产品60％
- 科技债务20％
- 支持20％。
让我举一个例子。我们有3个支持者团队。这是80 * 3 * 0.8 = 192个可用小时。我们将在产品开发上花费116小时（60％），在技术债务上花费38小时（20％），在支持上花费38小时（20％）。
修饰
我们在星期一安排任务，在冲刺的中间，即一周后，进行梳理。我们称其为分析第一周的结果，并确定是否有时间达到冲刺目标或应该减少某些时间。如果达到了目标，则产品经理将在同一次会议上提出下一个冲刺的计划，然后重复整个周期。
演示版
冲刺的逻辑端是演示，我们邀请所有开发团队，利益相关者，业务部门的同事，甚至是交付俱乐部的负责人。
负责发布的同事准备演示，讨论sprint的成就以及克服的困难。我们分享产品故事以及有关新功能如何使用户受益的见解。
这对整个团队来说都是重要的一天！
复古风
对我们来说，复古是提高效率的一种方式。首先，我们查看团队绩效的指标，完成冲刺的成功程度。我们检查完成状态下的任务与迭代开始时完成的任务的比率，并按存储桶修复此数据。
例如，在产品中，我们解决了20个问题，并完成了17个问题。因此，此存储桶的成功率为85％。对我们而言，产品开发的良好进展表明90％或更高。如果较低，我们在Retro会分析如何改进此指标。
冲刺工作
经常有人问我们代码审查以及测试如何进行。这里的一切都很标准。
一天从站起来开始。在15分钟内，团队讨论了他们昨天所做的事情以及今天将要做的事情。
我们使用Jira Flow和Git Flow来完成任务，我们有Atlassian堆栈。还有一个Scrum板，其中包含要执行的列-进行中-准备进行代码审查-准备进行质量检查-做好生命准备-完成。
当开发人员准备好代码后，他在Jira中创建一个具有当前发行号的分支-这是一个功能分支。他还将其发送到Bitbucket中的请求请求。开发人员至少需要两个批准。我们还与Jenkins集成，如果构建为绿色，则可以合并。技术负责人和团队负责人有权合并。有时您需要为拉取请求准备单元测试。有时，如果我们知道这些是业务的非关键领域，非关键领域或试验性功能，则有意不编写它们，然后将其删除。
当一切都变臭时，我们将其发送进行测试。测试工程师编写自动测试或手动运行测试用例。再次取决于域的关键程度。然后部署。
我们可以说这个过程就像一个时钟。但实际上，目前，团队内部一直保持着沟通。主要重点是冲刺目标和及时发布。为了实现该目标，我们可以讨论产品变更或修订技术实施。所有这些都是在执行任务时发生的-它始终是开发人员，团队负责人，产品经理和质量检查人员之间的对话。
IT部门的发展方向和结构
在转型过程中，我们走向了新的发展方向结构。您还记得，一开始我们就写了四个。此外，很明显，为了高质量，及时地实现目标，还需要确定两个领域。因此，现在有6个：
- 消费者只关心定制产品：网站和移动应用程序。
- 物流-关于物流师，快递和送货。
- 供应商-关于与我们的合作伙伴（餐厅/商店）的整合。
- 内部-呼叫中心和支持。
- 研发-解决科学密集型任务。
- 平台-改善整体架构和平台。
每个方向都有自己的任务范围和难度。
消费者
该方向的优先事项是用户的幸福感。主要产品指标如下：保留率，订单转换率，消费者NPS。从技术角度来看，对我们来说重要的是所有数据都必须快速发送。在这个方向上，也许是最大的高负载，因为我们直接与最终用户合作。而且还有大量的微服务，其中大多数是微服务。
主要产品是一个网站（包括移动版本）以及适用于iOS和Android的应用程序。两个主要流是杂货店交付和餐厅交付。与其他地方一样，技术堆栈也有加或减：PHP，Go，Postgres，Redis和Memcache用于缓存，Kafka用于异步通信。
后勤
这个方向的任务是确保将订单快速交付给饥饿的用户。此外，我们正在为调度员开发一个界面，如果需要，调度员可以帮助快递员进行手动控制。
物流的主要挑战之一是订单数量的增加以及系统的负荷增加。为了应付负载，您需要对体系结构进行质量更改。此外，食品的运送与办公用品，衣服，书籍等的运送有很大的不同。那里的一切都稍微简单了一些：我们制作了路线图，计划了路线并出发。
对于送餐，这样的数字将不起作用。我们都按需提供，情况每5-15分钟更改一次。开始下雨或下雪时，需求总是上升。当外面阳光明媚，而您又不想呆在家里时，需求就会减少。在节假日和周末，需求状况与工作日不同。交通情况和交通拥堵也可以自行调整，尤其是在汽车/摩托车快递员盛行的地区。上午，下午和晚上的时间有不同的需求状况。
此需求迁移由我们的监视器跟踪。如果需求减少，我们将更改搜索结果，并在“促销”部分中提供更多相关报价。为了提高相关性，我们连接了ML模型，这些模型使用户和观察变化的物流区域的个性化排序成为可能。
物流中最主要的应用程序之一是Rider App。这是一个Android应用程序，快递员可以在其中查看在哪里领取订单以及应该将订单交付到哪里。
供应商
该区域与我们的内部合作伙伴（餐厅和商店）合作。或者更确切地说，与他们的经理一起，他们通过个人帐户管理菜单并对搜索结果中的统计信息做出反应。
由于收集到的订单数据和统计信息，我们对目标受众和餐厅的特征有了很好的了解。我们与他们合作，为他们提供了一种工具，可以帮助他们更好地了解他们的客户是谁，并启用营销机制。我们还帮助餐厅开发价格优化模型，了解哪些菜在什么时候，什么顺序展示是最好的。
在供应商方向上正在开发的另一种产品是仪表板，用于厨房的订单落入其中。厨房接受订单，查看其组成，确定如何准备它，实际上是准备它。准备好订单后，厨房会在应用中确认这一点，然后将订单转移给快递员。然后，快递员可以使用Rider App。
内部
该区域负责我们的呼叫中心的工具，该工具提供用户支持。实际上，这是与订单相关的所有内容的“管理区域”。操作员可以帮助客户，提供有关订单当前状态的其他信息，在将订单发送到餐厅之前对其进行调整。
这个方向的挑战在于制造这样的系统，首先，该系统将很方便并满足操作员的所有需求；其次，这将是快速的，因为需要尽快为客户提供帮助。除了关键任务之外，Internal的工作人员还致力于减少操作员处理一个问题的时间并减少呼叫数量。
研发部
当您需要更改业务流程并同时了解这些更改将如何影响整个平台时，就需要进行研究与开发。他们进行实验，建立模型，计数和称重。他们还与BI部门进行了最紧密的互动，在BI部门中，他们与大数据，ML模型，设计神经网络和预测需求进行合作。在这方面，BI通过研究和工具帮助研发。
研究主要是关于数据的。例如，如果您更改某些因素，系统将如何运行。现在，大多数研发任务都来自物流，因为该领域的不确定性最高。
平台
这是技术方向。首先，这些家伙的目标是改善系统核心，重构订单处理并分解我们的整体。这不是传统意义上的产品开发，而是所有改进都以一种或另一种方式旨在使用户更轻松，更轻松地与Delivery Club应用程序进行交互：减少响应时间，以便更快地打开页面，增加平台容量，以便更多用户可以秩序，同时使用经验对他们来说也尽可能令人愉快。
转型成果和新挑战
我们的任务是建立一个满足成长中公司所有要求的开发流程：各个团队参与业务，彼此进行大量沟通，对他们自己设定的期限负责并了解他们的工作如何影响最终用户。该过程必须透明，可衡量并且最重要的是可扩展。
在进行了产品转换并优化了开发过程之后，我们得出的结论是我们的每个版本都可以预测。起初，我们以80％的准确度知道发布的时间和发布方式。现在，部门内所有团队的平均绩效指标已提高到90％。团队的参与，也就是家伙的动力大大增加了，他们了解自己在做什么，为什么做，对谁重要。
该过程包括在不损害产品开发的情况下响应尽快任务的能力，有足够的沟通点可以灵活地估算人工成本并及时响应产品经理的要求变更。在实践中，我们确保该过程是可伸缩的：在不影响性能的前提下，我们通过相同的开发过程成功地从40人增加到170人。
同时，我们不会停止，并相信产品转型仍在进行中。在2019年底，我们开始考虑团队如何进一步影响业务。团队拥有很多产品专业知识，似乎您可以使用它，提出了技术与业务的共生关系。另外，我们需要提出一种验证产品假设的机制。也就是说，控制落在我们开发中的任务的价值。为此，我们描述了GIST流程-一种验证产品假设的框架，我们将在以下文章之一中进行讨论。
谢谢阅读！