A versão completa de duas horas pode ser vista no canal Hexlet no YouTube .
Índice:
História do Produto e da Empresa
Como funciona o desenvolvimento de produtos
Seleção e evolução de tecnologia
- Flash → Tela
- Angular → React
- Servidores e bancos de dados
- Java
- Evolução de teste
- Crescimento de carga e refatoração
Processos em desenvolvimento
- Solução técnica e revisão de código
- Avaliação de Desempenho
- Como funciona a contratação de engenheiros
- Posições juniores
Produto e história da empresa
Miro é uma plataforma de quadro branco colaborativo online para colaboração visual. A palavra-chave é colaboração, colaboração, respectivamente; as principais métricas pelas quais medimos nossa eficácia são o número de painéis de colaboração e sessões colaborativas que ocorrem no produto.
Nós nos chamamos de plataforma porque já fomos além de um produto: temos uma API aberta, um marketplace, um escritório de desenvolvimento, para que qualquer empresa possa expandir o produto por si mesma.
Nosso público-alvo são equipes de produtos que operam no mesmo escritório ou em escritórios diferentes. Na maioria das vezes, Miro é usado para conduzir workshops, sessões estratégicas, brainstorming, práticas ágeis (planejamento, retrospectivas).
Eu lidero o desenvolvimento na Miro. Eu cresci em Perm e continuo morando aqui. Historicamente, a empresa surgiu em Perm, de onde vêm os nossos fundadores. A maior parte do nosso departamento de desenvolvimento está aqui e, em 2019, lançamos e estamos desenvolvendo ativamente um segundo escritório de engenharia - em Amsterdã.
Anteriormente, trabalhei com desenvolvimento customizado: comecei construindo data warehouses analíticos como desenvolvedor, depois os projetei e conduzi grandes projetos. Ele ingressou na Miro em 2016, quando a empresa empregava 30 pessoas. Desde então, crescemos muito: agora temos cinco escritórios, 400 pessoas, das quais 140 são engenheiros.
A empresa foi fundada em 2011. Nossa maior função era e continua sendo o desenvolvimento de produtos, que hoje responde por cerca de metade da empresa.
Mudança de nome
Pensamos em mudar a marca em 2015, mas acabamos fazendo isso em 2018. Nosso nome anterior, RealtimeBoard, é longo e complexo. Muitas vezes era confundido, abreviado para RTB ou, o pior de tudo, esquecido completamente. Além disso, não é emocional, não há história por trás disso. Queríamos tornar o novo nome curto, amplo, falante e memorável.
Como resultado, nos inspiramos nas obras do artista plástico Joan Miró e escolhemos seu sobrenome como título. A pesquisa em si e a escolha do nome levaram vários meses, e depois mais alguns meses lançamos uma nova marca. Na sequência deste projeto, há uma série de artigos sobre como o trabalho no projeto foi organizado e um artigo separado sobre uma tarefa técnica pequena, mas não trivial, para a migração perfeita de usuários autorizados do antigo para o novo domínio.
Nós e os usuários rapidamente nos acostumamos com o novo nome. Estamos crescendo rapidamente, então vários milhões de novos usuários nem sabem que fomos chamados de maneira diferente. Um agradável bônus de rebranding foram os prêmios dos European Design Awards para a identidade, que desenvolvemos como parte do rebranding em conjunto com a agência europeia Vruchtvlees .
Como funciona o desenvolvimento de produtos no Miro
Toda a equipe de desenvolvimento de produto de 170 pessoas está localizada em Perm e Amsterdã: engenheiros, produtos, designers de produtos, scrum masters.
Anteriormente, era difícil para mim imaginar que tantas pessoas pudessem trabalhar em um produto. Mas hoje, sei que existem milhares de engenheiros trabalhando no mesmo produto no Uber, Slack e Atlassian. Continuamos a crescer e entendemos que claramente não somos o suficiente agora, e o próximo ponto-alvo na minha cabeça são 300 pessoas em desenvolvimento, e então continuaremos a crescer ainda mais. Não é apenas um número que saiu da sua cabeça. Temos um planejamento estratégico, entendemos onde queremos estar em dois anos, em cinco anos, e o que precisamos fazer para isso.
Em termos de estrutura organizacional, existem guildas: front-end, back-end, QA e assim por diante. Para trabalhar em projetos, eles são combinados em equipes multifuncionais.
As equipes são distribuídas em áreas-chave:
- Um produto horizontal é a principal funcionalidade do produto que todos os usuários veem: adesivos, texto, formas, quadros, etc.
- Direção de sistemas - responsável pela plataforma central e infraestrutura.
- Crescimento significa aumentar o número de usuários: ativação, engajamento, retorno, monetização.
- Enterprise — , . -, Miro, . -, SaaS-, . , , .
- — 2019 . API, , marketplace, — , , .
- — , . , , , Miro, : Meetings & Workshops, Ideation & Brainstorming, Research & Design, Agile Workflows, Strategy & Planning, Mapping & Diagramming.
: , , . , . , : - .
Os principais softwares dos engenheiros: IntelliJ Idea, Jira, Slack, Zoom, Miro, Confluence. A maioria dos funcionários trabalha em MacBooks, a maioria dos engenheiros trabalha em MacBook Pros e, para alguns, compramos máquinas mais potentes quando necessário.
Usamos nosso próprio produto todos os dias: reuniões internas, workshops, sessões de brainstorming, planejamento.Isso permite testar rapidamente todas as inovações do produto e simplifica muito a adaptação de novos desenvolvedores que, desde o primeiro dia, trabalham com o produto não só em termos de código, mas também como usuários. Esta é uma parte significativa da nossa cultura - fazemos um produto que deve ser confortável e agradável de usar.
Pilha, monólito
A frente é Typescript, React e AngularJS. O backend é Java. Bancos de dados - Redis, Postgres, para comunicação de cluster - Hazelcast e ActiveMQ. Hospedamos na Amazon, no mesmo data center. Existem cerca de 400 servidores em produção. Os servidores de aplicativos que processam placas de usuário podem ter até 100, tudo é orquestrado automaticamente.
Usamos uma pilha da Atlassian: Jira, Bitbucket, Bamboo e nossos próprios scripts que são aparafusados ao Bamboo e permitem que tudo seja implementado nos servidores Até agora, todos os lançamentos são um grande lançamento frontal e um grande lançamento posterior. Agora estamos pensando em como fazer mais desses lançamentos.
Nossa aplicação principal é um monólito modular: há um módulo que é responsável pela API, pela placa, pela função de serviço. O monolith é implantado em módulos para os servidores necessários, e não em uma grande parte para todos os servidores em uma fileira, ou seja, também temos servidores com funções diferentes.
Dentro do aplicativo, há muitas integrações e serviços adicionais que fizemos imediatamente separadamente e que as equipes liberaram separadamente do resto da frente e de trás.
Quando você tem uma pequena empresa, é muito mais fácil começar com um monólito e não cercar a infraestrutura de serviços. Mas agora entendemos que um monólito comum não nos dá a capacidade de dimensionar direções individuais (produto horizontal, plataforma, empresa, etc.), portanto, estamos desenvolvendo uma abordagem para deixar um único monólito.
Lançamentos
A montagem em si leva de 15 a 20 minutos, incluindo a execução de testes de unidade. Os testes de ponta a ponta podem levar até 40 minutos. Todo o processo leva de uma hora e meia a duas horas para trazer o mestre para a liberação. É muito tempo, ainda temos algo para trabalhar aqui.
Provavelmente, é ideal para lançar a cada cinco minutos. Mas para isso ainda não temos uma equipe tão grande e nem um público diário tão grande. Um grande público é importante para lançamentos frequentes, porque permite que você certifique-se rapidamente de que tudo está bem implementando as alterações para uma pequena proporção de usuários.
Seleção e evolução de tecnologia
Acredito que a escolha da tecnologia deva ser tratada assim: não importa o que você escolha, ainda terá que mudar algum dia, principalmente se a empresa e o produto crescerem. Portanto, o processo de mudança de tecnologias é normal. A tecnologia é importante, mas precisa ser tratada de maneira diferente nas diferentes fases do desenvolvimento de uma empresa.
As pequenas empresas que estão apenas começando e procurando um produto adequado ao mercado funcionam rapidamente, criam MVPs rapidamente e os descartam rapidamente. Encontrar um mercado é mais importante para eles do que criar soluções técnicas complexas. Mas quando o mercado é encontrado, as soluções técnicas vêm à tona, pois permitem criar uma margem de segurança para crescimento e segurança.
Primeiro, tentamos entender o problema que queremos resolver mudando as tecnologias. Então, fazemos muitas pesquisas, exploramos alternativas, testamos o desempenho. Isso é feito com qualquer solução técnica que vamos implementar: "não pegue a primeira coisa que você ouviu falar no mercado, mas pesquise e estude o que é mais adequado para resolver o problema."
Em um grande produto e em uma equipe, uma mudança na tecnologia é uma decisão estratégica importante; ela pode levar a uma interrupção parcial ou total no desenvolvimento do produto, uma mudança de equipes para novas tarefas e assim por diante. É longo e caro, mas se não for feito a tempo, os problemas que aparecem podem trazer muito mais dificuldades.
Tivemos algumas grandes mudanças tecnológicas, na frente e atrás. Aqui estão alguns exemplos.
Flash → Tela
Até 2015, toda a frente estava em Flash, então o Flash começou a morrer e mudamos para HTML e Canvas. A mudança na pilha teve um bom efeito no desempenho e usabilidade do produto e levou a um aumento perceptível na audiência. A transição durou cerca de um ano, foi um projeto grande e complexo. Um artigo sobre os detalhes deste projeto .
No momento, estamos considerando a migração para WebGL, mas ainda não há evidências claras de que valha a pena.
Angular → React
Nos últimos anos, temos mudado gradualmente do Angular JS para o React. Motivos principais:
- O React permite uma melhor digitação e, posteriormente, permite uma melhor refatoração do código e garante que nada caia.
- React . «» , Angular . Angular, React, .
- React , Angular JS .
Em 2015, mudamos de servidores alugados pela Hetzner para hospedagem na Amazon. Há mais de um ano, existe um projeto de migração do banco de dados principal do Redis para o PostgreSQL. Temos artigos sobre isso: gerenciamento de projetos de migração de dados , criação de cluster de failover .
Nosso caso é complicado pelo fato de que, do valor-chave do armazenamento, estamos migrando para um banco de dados SQL. Há muita refatoração. É importante fazer tudo para que o aplicativo não pare. É como trocar a roda de um carro em movimento, porque o banco de dados é a base sobre a qual o aplicativo está. Para o conteúdo das placas, na verdade fizemos tudo sem manutenção. Sim, o processo de transição atrasou, mas os usuários não perceberam nada, o produto funcionou.
A estabilidade do produto é o foco principal. Os usuários armazenam muito conteúdo no Miro. Da mesma forma, se um usuário agendou uma sessão ou reunião, preparou um quadro de conteúdo para ela e o produto não está disponível naquele momento, isso é uma falha, o conteúdo não pode ser usado. Embora o zoom condicional possa ser substituído rapidamente pelo Hangouts, o conteúdo não pode ser substituído rapidamente. Portanto, uma de nossas principais tarefas é garantir que o conteúdo para os usuários esteja sempre disponível.
Java
Java nos ajuda tremendamente em termos de produtividade e recursos de desenvolvedor que podemos encontrar. Eu sei que a Booking está mudando de Pearl para Java porque eles estão cansados de retreinar seus engenheiros.
Engenheiros de C ++ e .Net vêm até nós e se adaptam normalmente. Se você é um desenvolvedor experiente, já experimentou diferentes tecnologias e sabe como o sistema é construído, não é tão difícil mergulhar em um novo idioma. O principal é que o engenheiro apareça com as soluções certas, e com certeza ele vai conseguir se enterrar na linguagem, acredito nisso.
Evolução de teste
Inicialmente, tínhamos apenas testes manuais. Os lançamentos eram lançados a cada duas ou três semanas, a preparação para o lançamento levava uma semana: você faz o teste de regressão em alguns dias → encontra bugs críticos → correto → teste manual novamente. Quando havia várias equipes, funcionava, mas com vinte equipes é impossível testar tudo manualmente.
Então começamos a pensar em automação. Em primeiro lugar, escrevemos autotestes para nos livrarmos completamente dos testes de regressão. Agora estamos trabalhando para estabelecer os processos corretos de gestão da qualidade ao longo de todo o ciclo de desenvolvimento. Quanto mais cedo pensarmos sobre qualidade, mais cedo encontraremos casos extremos, entenderemos como testá-los - isso acabará reduzindo o custo e acelerando o processo de desenvolvimento. Um bug que você encontra à venda não vale apenas o tempo e os recursos para reverter o lançamento e corrigi-lo. O bug afeta a experiência geral do usuário do produto e é muito caro consertar essa experiência.
Temos uma guilda de QA, na qual os engenheiros tomam decisões sobre quais processos precisamos implementar agora, desenvolvemos uma estratégia de qualidade e, em seguida, cada engenheiro de QA ajuda suas equipes a implementar esses processos em seu próprio país:
- QA- -, . QA , . .
- QA , .
- QA , , .
Os lançamentos canários também são uma forma de teste, quando lançamos um recurso para um pequeno público e verificamos se perdemos algo. Lançamos novos recursos de grande porte por meio de caixas de seleção para usuários beta que expressaram o desejo de participar de testes beta (nossos gerentes de produto aprenderão sobre isso durante as entrevistas de pesquisa). O número de usuários beta e alfa necessariamente inclui nossas equipes. Implementamos absolutamente todas as novas funcionalidades para nós mesmos em primeiro lugar.
Uma descrição detalhada de todos os estágios do nosso processo de controle de qualidade .
Crescimento de carga e refatoração
Devido à grande mudança para o teletrabalho em 2020, nossa base de usuários disparou e nossa infraestrutura anual e resiliência de aplicativos esgotaram-se em algumas semanas. Na primeira semana de um aumento acentuado na carga, paramos todo o desenvolvimento de produtos e reorientamos as equipes para trabalhar com tolerância a falhas e desempenho.
A margem de segurança era necessária não apenas no back-end, mas também no front-end e no cliente, conforme o número de trabalhos síncronos aumentava no produto. Se antes 20 pessoas podiam trabalhar em um conselho ao mesmo tempo, agora são 300 pessoas. Nossos engenheiros de front-end fizeram muito e continuam a lidar com o desempenho de carga. Por exemplo, fazemos o painel com a lista de painéis carregar separadamente de todo o resto e mais rápido do que antes. E se o usuário for diretamente para o quadro, não pelo painel, o código e o conteúdo do quadro devem ser carregados, sem todo o resto.
Faremos muitas refatorações para que o usuário obtenha feedback e conteúdo do quadro mais rápido, e então todas as principais funcionalidades - scripts, a interface - aumentam lentamente. Para fazer isso, passamos a dividir o código em módulos “preguiçosos”. Graças a isso, aceleramos cerca de um terço e, no próximo mês, planejamos acelerar mais duas vezes em termos de carregamento.
É o mesmo em termos de desempenho na placa - há uma guerra por velocidade e recursos no computador em que o usuário está executando.Nem todo mundo fica online com boas máquinas; alguém tirou da prateleira um laptop doméstico antigo e de baixo desempenho. Mas nosso produto deve funcionar bem em qualquer laptop. Este é outro grande truque em que estamos trabalhando muito agora.
Processos em desenvolvimento
Solução técnica e revisão de código
Qualquer tarefa começa com a preparação de uma solução de produto. Uma solução de produto é uma resposta à pergunta “O que vamos fazer?”. Um gerente de produto com base na estratégia de produto e OKRs está fazendo muitas pesquisas para descobrir o que os usuários estão faltando em nosso produto. Com base na pesquisa, o produto descreve a solução. A guilda do alimento discute a solução e a revisa se necessário.
Com base em uma solução de produto, é formada uma solução técnica que responde à pergunta "Como vamos fazer isso?" É desenvolvido pelos engenheiros da equipe que irá implementar a funcionalidade. A solução técnica passa por vários processos de revisão:
- com equipes com as quais há interseções de funcionalidade;
- revisão de segurança dos componentes que abordaremos na arquitetura;
- como vamos implantar o resultado.
Depois disso, o próprio desenvolvimento começa. É importante que a revisão de código não retarde o desenvolvimento, então, recentemente, em vez de receber duas revisões de código, introduzimos a responsabilidade pessoal no nível do componente. Agora, no nível do código, sempre sabemos quem é o responsável por essa parte, o que facilita muito a comunicação durante o desenvolvimento. Conseqüentemente, assim que você fizer alterações no código, o revisor será automaticamente designado como o proprietário desse código. Se o código for seu, a revisão é feita por um membro de sua equipe.
Por que introduzimos a responsabilidade pessoal? Costumava haver algumas pessoas, "veteranos", que sabiam como todo o produto funcionava e podiam verificar qualquer parte do código. Mas à medida que o produto cresceu, as capacidades dessas pessoas começaram a faltar, elas não podiam mais saber sobre tudo o que estava acontecendo no desenvolvimento.O processo de revisão do código começou a retardar o resto do processo, não estava claro a quem recorrer para a revisão do código. Então, começamos a trazer toda a competência necessária para blocos de produtos específicos para a equipe que trabalha com eles. Assim, as equipes puderam conduzir revisões de código por conta própria. Ao mesmo tempo, isso nos ajudou a acelerar muito.
Avaliação de Desempenho
A empresa tem notas, graças às quais entendemos quem tem quais competências, a que notas correspondem e, o mais importante, o que cada um precisa fazer para seguir em frente. A avaliação de desempenho ocorre duas vezes por ano, ajuda a capturar uma imagem de onde cada pessoa está agora e recebe feedback personalizado.
Com base nessa imagem, o líder de equipe traça planos de desenvolvimento pessoal com cada membro da equipe: o próprio funcionário diz onde deseja se desenvolver e a Avaliação de Desempenho destaca seus pontos fortes e fracos.
Então, regularmente, uma vez a cada uma a duas semanas, o líder da equipe com o funcionário realiza reuniões 1: 1, onde, entre outras coisas, eles discutem e acompanham o movimento na direção planejada. Em um ano e meio, com base nos resultados desse movimento, há aumento de classe e salário.
Com os líderes de equipe tudo é exatamente igual, além disso, há treinamentos externos e mentoria externa para eles.
Infelizmente, as pessoas geralmente não crescem tão rápido quanto a empresa - tudo bem. Estamos dispostos a investir muito em treinamento, pois o crescimento de uma empresa depende diretamente do crescimento dos colaboradores. Temos remuneração para cursos externos, temos cursos recomendados e mentores. Compensamos 100% da formação obrigatória (por exemplo, inglês), tentamos compensar os restantes 50 a 50, para que haja responsabilidade mútua pelos resultados.
Raramente vamos a conferências. Procuramos escolher aqueles que falam sobre tecnologias e casos que atualmente são relevantes para nós e para os quais não temos conhecimento suficiente.
Como funciona a contratação de engenheiros
Nossa rede de recrutamento é padrão na Rússia e na Europa. Na Rússia, o funil de contratação já é mais restrito, então a primeira entrevista pode ser conduzida não por um recrutador, mas por um gerente de contratação (geralmente o líder da equipe na qual contratamos uma pessoa) depois que o recrutador processou o currículo e eliminou as vagas que não são adequadas aos requisitos.
Tenho a sensação de que na Rússia há muito menos engenheiros procurando ativamente por trabalho, em comparação com a Europa, porque eles não querem correr riscos. E quando muitas empresas entraram na zona de risco devido ao isolamento, as pessoas ficaram ainda menos inclinadas a assumir riscos e mudar de emprego.
De qualquer forma, a cadeia de contratação começa com uma entrevista de seleção por telefone com um candidato, que é conduzida por um recrutador ou gerente de contratação. O objetivo da triagem é entender rapidamente como um candidato se encaixa nos principais requisitos da vaga.
Após a triagem, uma tarefa de teste, em seguida, uma entrevista técnica, que inclui, entre outras coisas, uma discussão sobre a tarefa de teste. Então - uma reunião com a equipe em que o candidato vai trabalhar. Para nós, esta é uma etapa obrigatória, pois ajuda antes de tudo a entender a adequação cultural do candidato, e não suas habilidades técnicas.
Depois de todas as entrevistas, recolhemos feedback dos participantes, apresentamos uma oferta.
Para avaliar as tarefas de teste, usamos um sistema de pontos, então classificamos os resultados e, assim, vemos os melhores resultados. Em posições seniores, às vezes cancelamos uma tarefa de teste se o candidato tiver um bom repositório público.
Posições juniores
Antes de passar para o trabalho remoto, começamos a trabalhar com especialistas juniores: contratamos Juns, graduados, embora não muito ativamente. Agora, congelamos completamente essa história, porque é muito difícil integrá-los em um local remoto e temos muito pouca experiência nisso até agora. Portanto, nos concentramos em médios com pelo menos 3-4 anos de experiência.
Mas mesmo quando trabalhávamos com Juniors, era importante para nós que eles pudessem crescer até os midles em um ano, para que pudessem aprender e se adaptar muito rapidamente.
Altos requisitos de contratação
Há uma lenda de que é muito difícil para nós conseguir um emprego devido aos requisitos muito elevados. Isso não é inteiramente verdade.
Frequentemente somos entrevistados por candidatos com o cargo de Líder de Equipe, que, de acordo com nossos critérios internos, são intermediários. Isso ocorre porque, em busca de cargos, eles chegam a empresas que estão dispostas a ceder posições acima de suas competências atuais em várias etapas, apenas para contratar uma pessoa. Como resultado, resulta um desserviço: a pessoa ainda não atingiu o nível necessário, mas já ocupa uma posição elevada; então dificilmente poderá simplesmente sair da empresa, pois não será contratado para o mesmo cargo em outras empresas.
O maior entrave na contratação é o inglês. Antes podíamos contratar sem conhecimento de inglês, mas agora isso é impossível, e é impossível bombá-lo em poucos meses: um engenheiro desde as primeiras semanas de trabalho precisará ler a documentação em inglês, se corresponder em inglês com os colegas, participar de assembleias gerais, a maioria delas realizadas em inglês língua.
O produto está crescendo, novas tarefas interessantes aparecem, então sempre temos muitas vagas abertas na engenharia tanto em Perm quanto em Amsterdã.