完整的两小时版本可以在Hexlet YouTube频道上查看。
目录：
产品和公司历史
产品开发如何进行
技术选择与发展
开发过程
产品和公司历史
Miro是用于视觉协作的在线协作白板平台。关键字分别是协作，协作，我们用来衡量有效性的关键指标是产品中发生的协作委员会和协作会议的数量。
我们称自己为平台是因为我们已经超越了产品范围：我们拥有开放的API，市场，开发人员办公室，因此任何公司都可以自行扩展产品。
我们的目标受众是来自相同或不同办公室的产品团队。 Miro通常用于举办研讨会，战略会议，集思广益，敏捷实践（计划，回顾）。
我在Miro领导开发。我在彼尔姆长大，继续住在这里。历史上，该公司出现在我们的创始人来自彼尔姆的地方。我们大部分的开发部门现在都在这里，并且在2019年，我们在阿姆斯特丹成立了并正在积极开发第二个工程办公室。
以前，我从事定制开发工作，首先以开发人员的身份构建分析数据仓库，然后进行设计，然后领导大型项目。他于2016年加入Miro，当时公司拥有30名员工。从那时起，我们发展了很多：现在我们有五个办事处，共有400名员工，其中140名是工程师。
该公司成立于2011年。我们最大的职能是并且仍然是产品开发，今天它占公司的一半左右。
名称变更
我们曾考虑过在2015年进行品牌重塑，但最终在2018年进行了重塑。我们的前名RealtimeBoard冗长而复杂。它经常被误认为是RTB，或者更糟糕的是完全被人们遗忘了。此外，这是没有感情的，背后没有故事。我们希望使新名称简短，宽敞，说话，令人难忘。
结果，我们受到了艺术家琼·米罗（JoanMiró）作品的启发，并选择了他的姓氏作为头衔。研究本身和名称的选择花了几个月的时间，然后我们推出了一个新品牌几个月。在该项目之后，将有一系列有关该项目工作安排方式的文章，以及另一篇关于将授权用户从旧域无缝迁移到新域的小但不重要的技术问题的文章。
我们和用户都很快习惯了这个新名称。我们正在快速发展，因此数百万新用户甚至都不知道我们的名字有所不同。令人更名奖金是奖励来自欧洲设计奖的身份，这是我们作为品牌重塑的一部分，连同欧洲机构开发Vruchtvlees。
Miro产品开发的工作方式
由170人组成的整个产品开发团队位于彼尔姆和阿姆斯特丹：工程师，产品，产品设计师，Scrum大师。
以前，我很难想象有这么多人可以使用一种产品。但是今天，我知道Uber，Slack和Atlassian有成千上万的工程师在开发同一产品。我们继续成长，并了解到我们现在显然还不够，我脑海中的下一个目标点是发展中的300人，然后我们将继续进一步成长。这不只是个数字。我们有战略计划，我们了解两年，五年后的目标，以及为此需要做什么。
在组织结构方面，有行会：前端，后端，质量检查等。为了进行项目工作，他们被合并为跨职能团队。
团队分布在关键领域：
- 横向产品是所有用户都能看到的主要产品功能：贴纸，文本，形状，框架等。
- 系统方向-负责核心平台和基础架构。
- 增长就是增加用户数量：激活，参与度，回报率，获利。
- Enterprise — , . -, Miro, . -, SaaS-, . , , .
- — 2019 . API, , marketplace, — , , .
- — , . , , , Miro, : Meetings & Workshops, Ideation & Brainstorming, Research & Design, Agile Workflows, Strategy & Planning, Mapping & Diagramming.
: , , . , . , : - .
工程师的主要软件：IntelliJ Idea，Jira，Slack，Zoom，Miro，Confluence。大多数员工在MacBooks上工作，大多数工程师在MacBook Pros上工作，对于某些我们在必要时购买功能更强大的计算机。
我们每天使用自己的产品：内部会议，讲习班，集思广益会议，计划。这使您可以快速测试产品中的所有创新，并极大地简化了新开发人员的适应工作，从一开始，新开发人员不仅在代码方面而且在用户方面都与该产品一起工作。这是我们文化的重要组成部分-我们生产的产品本身应该舒适且使用愉快。
堆叠，整体式
前面是Typescript，React和AngularJS。后端是Java。数据库-Redis，Postgres，用于集群通信-Hazelcast和ActiveMQ。我们在同一数据中心的Amazon中托管。生产中大约有400台服务器。处理用户板的应用程序服务器最多可以配置100个，所有内容都将自动编排。
我们使用Atlassian的堆栈：Jira，Bitbucket，Bamboo以及我们自己的脚本，这些脚本固定在Bamboo上，并允许将所有内容推出到服务器。到目前为止，所有发行版都是一个大发行版和一个大发行版。现在，我们正在考虑如何制作更多这些版本。
我们的主要应用是模块化的整体结构：有一个模块负责API，板，服务功能。整体以模块的形式部署到所需的服务器，而不是以大块的形式部署到连续的所有服务器，也就是说，我们还拥有角色不同的服务器。
在该应用程序中，我们立即分别进行了许多集成和附加服务，并且团队与前后的其余部分分别独立发布了这些集成和附加服务。
当您的公司规模较小时，从整体开始就容易得多，而不必围护服务的基础架构。但是，现在我们已经了解到，一个通用的整体结构无法使我们扩展各个方向（水平产品，平台，企业等）的能力，因此我们正在开发一种方法来保留单个整体结构。
发布
组装本身需要15到20分钟，包括执行单元测试。端到端测试最多可能需要40分钟。整个过程需要一个半小时至两个小时才能将母版发布。这已经很长时间了，我们仍然有一些工作要做。
每五分钟发布一次可能是理想的选择。但是为此，我们还没有这么庞大的团队，也没有那么大的每日受众。大量的用户对于频繁发布很重要，因为它允许您通过将更改推广到一小部分用户来快速确保一切正常。
技术选择与发展
我认为应该对技术的选择进行这样的处理：无论您选择什么，都必须在某一天进行更改，尤其是在公司和产品不断发展的情况下。因此，技术更改的过程是正常的。技术很重要，但是在公司发展的不同阶段需要区别对待。
刚开始寻找产品市场契合度的小型公司可以快速运行，快速建立MVP，然后迅速将其丢弃。对于他们而言，寻找市场比建立复杂的技术解决方案更为重要。但是，一旦找到市场，技术解决方案便会脱颖而出，因为它们使您能够为增长和安全性创造一定的安全裕度。
我们首先尝试了解我们想通过更改技术来解决的问题。然后，我们进行了大量研究，探索替代方案，测试性能。这可以通过我们将要实施的任何技术解决方案来完成：“不要拿您最初在市场上听说的第一件事，而要研究和研究最适合解决问题的方法。”
在大型产品和团队中，技术变更是一项重要的战略决策；它可能导致产品开发部分或完全停止，将团队转移到新任务上，等等。它很长而且很昂贵，但是如果不及时完成，出现的问题可能会带来更多的困难。
我们已经在前端和后端进行了一些重大的技术转变。这里有些例子。
Flash→画布
直到2015年，整个战线都在Flash上，然后Flash开始消失，我们改用HTML和Canvas。堆栈的更改对产品的性能和可用性有很好的影响，并导致了观众的显着增加。过渡大约花了一年时间，这是一个庞大而复杂的项目。有关此项目详细信息的文章。
我们目前正在考虑迁移到WebGL，但尚无明确证据表明值得这样做。
角→反应
在过去的几年中，我们已逐渐从Angular JS迁移到React。主要原因：
2015年，我们从Hetzner租用的服务器切换到Amazon托管。一年多来，有一个项目将主数据库从Redis迁移到PostgreSQL。我们有关于此的文章：数据迁移的项目管理，创建故障转移群集。
从存储的键值转移到SQL数据库这一事实使我们的情况变得复杂。有很多重构。重要的是做所有事情，以使应用程序不会停止。这就像改变驾驶汽车的方向盘一样，因为数据库是应用程序赖以生存的基础。对于董事会的内容，我们实际上无需维护即可完成所有工作。是的，过渡过程被延迟了，但是用户什么也没注意到，该产品仍然有效。
产品稳定性是重点。用户在Miro中存储了大量内容。因此，如果用户已经安排了会话或会议，并为其准备了内容板，并且此时产品不可用，则说明这是失败的，因此无法使用该内容。虽然可以使用环聊快速替换有条件的缩放，但不能快速替换内容。因此，我们的主要任务之一就是确保用户内容始终可用。
爪哇
Java在我们可以找到的生产力和开发人员资源方面极大地帮助了我们。我知道Booking正在从Pearl转向Java，因为他们厌倦了对工程师的再培训。
来自C ++和.Net的工程师来找我们，可以正常进行调整。如果您是一位经验丰富的开发人员，尝试过不同的技术并且知道系统的构建方式，那么深入学习一种新的语言并不是那么困难。最主要的是，工程师提出了正确的解决方案，并且我相信他一定能够把自己的语言深深扎根。
测试进化
最初，我们只有手动测试。每两到三周发布一次发布，发布的准备工作花了一周的时间：您需要在几天内进行回归测试→找到关键的错误→正确→再次进行手动测试。当有几个团队时，它可以工作，但是有二十个团队，则不可能手动测试所有内容。
因此，我们开始考虑自动化。首先，我们编写了自动测试来完全摆脱回归测试。现在，我们正在努力在整个开发周期中建立正确的质量管理流程。我们越早考虑质量，就越早发现边缘案例，了解如何对其进行测试-这最终将降低成本并加快开发过程。您发现出售的错误不仅值得花费时间和资源来回滚发行版并进行修复。该错误影响产品的整体用户体验，而修复该体验的成本非常高。
我们有一个质量检查协会，其中工程师决定我们现在需要实施哪些流程，制定质量策略，然后，每个质量检查工程师都可以帮助其团队自己实施以下流程：
- QA- -, . QA , . .
- QA , .
- QA , , .
当我们向一小部分受众推出某个功能并检查是否错过了某些功能时，Canary版本也是一种测试方法。我们会通过复选框启动大型的新功能，并推广到表示希望参与Beta测试的Beta用户（我们的产品经理将在研究访谈中了解这一点）。Beta和Alpha用户的数量必定包括我们的团队，我们首先将绝对所有新功能推出给自己。
详细介绍我们质量检查流程的各个阶段。
负载增长和重构
由于2020年向远程办公的大规模转变，我们的用户群猛增，并且我们的年度基础设施和应用程序弹性在几周内就用光了。在负载急剧增加的第一周，我们停止了所有产品开发，并重新调整了团队的工作以致力于容错和性能。
随着产品中同步作业数量的增加，不仅在后端，而且在前端和客户端都需要安全裕度。如果以前有20个人可以同时在一个板上工作，那么现在是300个人。我们的前端工程师做了很多工作，并继续致力于提高负载性能。例如，我们使带有板清单的仪表板与其他所有东西分开加载，并且比以前更快地完成。而且，如果用户直接访问开发板，而不是通过仪表板，则应加载开发板的代码和内容，而无需进行其他操作。
我们将进行大量重构，以便用户更快地从开发板上获得反馈和内容，然后所有主要功能（脚本，界面）会慢慢启动。为此，我们将代码分为“惰性”模块。因此，我们的速度提高了约三分之一，并且在下个月，我们计划在负载方面再提高两倍。
在主板性能上是相同的-用户在运行的计算机的速度和资源上存在一场战争。并非每个人都拥有好的机器来上网；有人将现成的，性能低下的老式家用笔记本电脑下架了。但是我们的产品应该可以在任何笔记本电脑上正常工作。这是我们目前正在研究的另一个大技巧。
开发过程
技术解决方案和代码审查
任何任务都始于准备产品解决方案。产品解决方案是对“我们要做什么？”这个问题的答案。基于产品策略和OKR的产品经理正在做大量研究，以找出当前我们产品中缺少哪些用户。根据研究，该产品描述了解决方案。食品行业协会讨论解决方案，必要时进行修改。
在产品解决方案的基础上，形成了一个技术解决方案，回答了“我们将如何做到这一点”这一问题。它是由将实现该功能的团队的工程师开发的。技术解决方案经历了多个审核过程：
- 具有功能交叉的团队；
- 对我们将在体系结构中涉及的组件的安全性审查；
- 我们将如何部署结果。
之后，开发本身就开始了。重要的是，代码审查不会减慢开发速度，因此最近，我们没有强制要求接受两次代码审查，而是在组件级别引入了个人责任。现在，在代码级别，我们总是知道由谁负责这一部分，这极大地促进了开发过程中的沟通。因此，一旦您对代码进行了更改，该代码的所有者即自动分配给审阅者。如果代码是您的代码，则审核由您的团队成员完成。
我们为什么要引入个人责任感？过去只有少数人“老歌”，他们知道整个产品的工作原理，并且可以检查任何代码。但是随着产品的发展，这些人的能力开始缺乏，他们不再了解开发中正在发生的一切。代码审查过程开始减慢其余过程的速度，尚不清楚谁去进行代码审查。然后，我们开始将特定产品模块的所有必要能力带给使用它们的团队。因此，团队能够自行进行代码审查。一次，这帮助我们加快了很多速度。
性能评估
该公司具有等级，因此，我们可以了解谁具有哪些能力，他们对应的等级以及最重要的是每个人继续前进需要做什么。绩效评估每年进行两次，有助于捕获每个人现在所在的位置的图片，并获得个性化的反馈。
基于这张照片，团队负责人与每个团队成员一起制定个人发展计划：员工本人说出他想发展的地方，而绩效评估则突出了他的长处和不足。
然后，通常每隔一到两周一次，团队领导与员工举行1：1的会议，除其他事项外，他们讨论并跟踪计划方向的运动。在一年半的时间里，根据这一运动的结果，职等和薪水都有所增加。
团队负责人的一切都完全一样，此外，他们还需要接受外部培训和外部指导。
不幸的是，人们的成长速度通常不及公司快-没关系。我们准备在培训方面投入大量资金，因为公司的成长直接取决于员工的成长。我们对外部课程有补偿，我们推荐了课程和导师。我们对义务培训进行100％的补偿（例如英语），我们尝试对其余的50到50进行补偿，以便对结果负有共同责任。
我们很少去参加会议。我们尝试选择那些谈论当前与我们相关且我们缺乏足够知识的技术和案例的人。
招聘工程师的工作方式
我们的招聘链是俄罗斯和欧洲的标准服务。在俄罗斯，招聘渠道已经很狭窄，因此第一次面试不能由招聘人员进行，而是由招聘经理（通常是我们雇用一个人的团队的团队负责人）在招聘人员处理了简历并清除了不符合要求的职位后立即进行。
我觉得与欧洲相比，在俄罗斯积极寻求工作的工程师要少得多，因为他们不想冒险。当许多公司由于隔离而进入风险区时，人们变得更不愿意冒险并换工作。
无论哪种方式，招聘链都始于对候选人的筛选电话面试，该面试由招聘人员或招聘经理进行。筛选的目的是快速了解候选人如何满足空缺的关键要求。
筛选之后，进行测试任务，然后进行技术面试，其中包括对测试任务的讨论。然后-与候选人将参加的团队开会。对我们来说，这是必不可少的步骤，因为它首先有助于了解候选人的文化背景，而不是其技术技能。
在所有采访之后，我们收集参与者的反馈，提出要约。
为了评估测试任务，我们使用分数系统，然后对结果进行排名，从而看到最佳结果。在高级职位上，如果候选人拥有良好的公共资源库，我们有时会取消测试分配。
初级职位
在开始远程工作之前，我们开始与初级专家合作：我们雇用了Juns，毕业生，尽管不是很积极。现在，我们已经完全冻结了这个故事，因为很难将它们放在远程位置上，到目前为止，我们对此的经验很少。因此，我们专注于具有至少3-4年经验的中级企业。
但是即使我们与Juniors一起工作，对我们来说也很重要，他们可以在一年内长成小鸟，这样他们就可以很快地学习和适应。
高招聘要求
传说，由于要求很高，我们很难找到工作。这并非完全正确。
我们经常接受具有团队负责人职位的候选人面试，根据我们的内部标准，他们处于中间位置。发生这种情况的原因是，在寻求职位时，他们来到的公司愿意通过几个步骤来提供高于其当前能力的职位，而只是雇用一个人。结果，结果是损害：该人尚未达到所需的水平，但他已经占据了较高的位置；那么他将很难离开公司，因为他不会被聘用其他公司的相同职位。
招聘中最大的障碍是英语。以前，我们可以在不懂英语的情况下进行聘用，但是现在这是不可能的，并且不可能在几个月内投入使用：从工作的头几周起，工程师将需要阅读英文文档，与同事用英文通讯，参加股东大会，其中大多数以英文举行语言。
产品不断增长，出现了新的有趣任务，因此在彼尔姆和阿姆斯特丹，我们在工程领域总是有很多空缺职位。