Muitas outras grandes empresas de TI começaram com uma startup e o Badoo não é exceção. Nos últimos anos, a empresa passou de várias dezenas de engenheiros para várias centenas. Nikolai Krapivny esteve na vanguarda na maior parte desse caminho e tomou decisões: o que é melhor e o que não fazer, como lidar com os problemas. Seu relatório sobre o TeamLead Conf foi dedicado a essa experiência e à imagem do mundo que resultou nela.

Obviamente, cada empresa tem seu próprio caminho , mas os problemas das comunicações humanas são aproximadamente os mesmos para todos. A experiência de outra pessoa o ajudará a pensar com antecedência sobre os problemas que terão de enfrentar o crescimento da empresa. Mesmo que esses valores não se apliquem diretamente, ele dirá a você como pensar.



A história consiste em três partes. O primeiro é sobre comunicações , sobre como elas mudam com o crescimento da empresa. A segunda parte é sobre como, com o aumento do número de engenheiros da equipe, tentar manter a velocidade do desenvolvimento . E a terceira parte é por que o Badoo vive em dois escritórios e como lidar com o problema da comunicação.

Vamos começar!



Sobre o palestrante: Nikolay Krapivny (@ cyberklin ) trabalha no Badoo há oito anos, cinco deles estão envolvidos no gerenciamento de equipes e nos processos de desenvolvimento da construção.


Antes de mergulhar na primeira parte, quero dizer que esta é uma história sobre o nosso caminho e não afirma ser verdade absoluta. Cada empresa tem seu próprio caminho, mas tenho certeza de que nossa experiência, os valores que formamos para nós mesmos, algum conhecimento o ajudarão no seu crescimento, ajudarão a construir o processo certo. Apesar de você ter uma especificidade diferente, tudo é um pouco diferente, espero que seja útil para você.

Comunicações

Para começar, vamos falar um pouco teoricamente sobre o que acontece com as comunicações quando uma empresa cresce.

Comunicação é sobre como os departamentos interagem entre si, como as pessoas interagem umas com as outras, como a comunicação ocorre para que algo seja feito na empresa.

Considere um exemplo bastante comum, mas ainda assim vital: uma equipe abstrata de inicialização. Várias pessoas se reuniram, alguém mais próximo do negócio e alguém mais técnico. Mas, no geral, essa é uma equipe pequena que faz algo que talvez um dia se torne o segundo Facebook. E nesta equipe, todo o trabalho é construído em comunicações. A equipe é pequena e não faz sentido introduzir nenhum processo. Tudo funciona assim : alguém conversou com alguém, eles concordaram em fazer algo rapidamente, estão fazendo.

Apesar do processo, que foi construído apenas com base nas comunicações, nas conversas: "Vamos fazer", "Vamos fazer mais rápido", "Vamos fazer assim", existem certos problemas, sem dúvida, essa equipe tem suas vantagens.

1. O trabalho é rápido . O tempo entre uma ideia e como ela se torna disponível para o usuário é muito pequeno. A ideia surgiu, conversamos com alguém sobre como fazê-lo mais rápido, já está pronto, está pronto.
2. É flexível . Nesta pequena equipe, não existe alguém que esteja envolvido apenas em algo específico e não possa, quando necessário, conectar-se a uma tarefa que é importante. Em princípio, todo mundo faz tudo, e se algo é importante para nós, todo mundo faz um esforço para fazer isso.
3. Em geral, devido ao fato de que esses processos ainda não foram construídos, esse trabalho é bastante eficaz . Não gastamos muito tempo com custos indiretos, em alguns processos e em alguns esquemas formais construídos.

Esses são apenas os valores que toda empresa deseja ver: a equação mais flexível dos recursos, o tempo mínimo de colocação no mercado e os baixos custos operacionais.

A empresa está crescendo - as comunicações estão "rasgadas".

Quando uma empresa cresce, as vantagens de uma equipe pequena, quando tudo funciona rapidamente, na interação, nas conversas, tornam-se um problema. A carga nas comunicações a partir da quantidade de informações transmitidas começa a crescer, e chegamos ao fato de que as comunicações são "fragmentadas" . Estamos começando a perder mais em comunicações do que estamos ganhando. Precisamos conversar com muitas pessoas, em algum lugar há um mal-entendido ao transmitir informações de pessoa para pessoa, em algum lugar que perdemos alguma coisa, em algum lugar que esquecemos. E tudo o que foi construído, o que deu velocidade, estamos lentamente começando a perder.



Se você extrapolar e observar o modelo de desenvolvimento da empresa por um longo intervalo de tempo, ele parecerá um ciclo. O número de pessoas aumenta, a carga no processo aumenta, as comunicações começam a quebrar. O que anteriormente funcionava deixa de funcionar. Portanto, somos forçados a reparar algo nesses lugares. Muitas vezes isso acontece nas fronteiras dos departamentos. Para consertar, você precisa formalizar o processo de comunicação. E esse ciclo se repete muitas vezes : o número de pessoas aumenta, algo começa a funcionar ineficientemente, introduzimos novos processos, de alguma forma os formalizamos, obtemos um novo suprimento de crescimento até que ele se rompa em outro lugar e assim por diante. É como escalar um sistema, como um desempenho: se você aumentar a carga no sistema - o elemento mais fraco, a parte mais lenta não suportará. Reparamos, de alguma forma melhoramos, uma janela aparece na qual você pode aumentar a carga no sistema. Assim, com o dimensionamento da empresa.

Era uma pequena parte teórica introdutória.

Agora, vamos dar uma olhada em quais ciclos passamos, quais problemas encontramos e como resolvemos.

Termos de Referência

Como primeiro exemplo, considere a tarefa de formalizar o relacionamento entre uma empresa e uma equipe de engenharia. Os termos de referência, ou, como denominamos PRD, são uma solicitação do que precisa ser alterado em termos de funcionalidade de design. Essa é uma formalização bastante óbvia pela qual todas as empresas passam. Eu acho que a maioria de vocês trabalha em empresas onde existe algum tipo de processo formal de transferência de uma tarefa de desenvolvimento. De uma equipe de produtos, de uma empresa ou de um cliente externo - isso não importa.



Passamos por várias partes da complicação desse processo. No começo, acabamos de escrever. Quando a equipe se tornou maior do que aquela que permite que você faça negócios simplesmente conversando entre nós, começamos a escrever tudo isso em tarefas. Os objetivos foram formulados como "o que precisa ser feito". Além disso, a complexidade do produto aumentou, o número de pessoas na empresa aumentou e chegamos à conclusão de que é útil manter a versão atual do sistema de trabalho atual em um único local. Mudamos tudo isso para os Wikis, e uma discussão sobre as mudanças nos comentários do wiki, para que tudo esteja em um só lugar. O próximo passo foi formalizar o que deveria estar no processo de revisão do PRD + PRD. Agora, temos um modelo que corrige quais informações devem estar no PRD, o que deve ser descrito e quais dados devem ser coletados antes do início do trabalho. Por exemplo, agora o modelo PRD contém os seguintes blocos:

• O objetivo, por que estamos fazendo essa funcionalidade.
• Quais plataformas, produtos e países planejamos lançar.
• Descrição do formato funcional em casos de uso: casos principais + uma lista predefinida de "casos complicados" dos quais todos esquecem.
• Tokens (processados ​​separadamente pelo redator).
• Comunicações: se haverá notificações por email / push para essa funcionalidade e, em caso afirmativo, quais.
• Plano de lançamento, dependendo do marketing / outros projetos na empresa.
  
• Analytics: como avaliaremos os resultados, quais métricas de negócios precisamos adicionar para avaliar o sucesso da mudança.

Assim, na forma atual, a interação entre o produto e a equipe técnica é formalizada com muita força e nos ajuda a não perder alguns pontos importantes no processo de transferência de uma tarefa para o trabalho.

Cliente servidor

Crescemos ainda mais, o desenvolvimento móvel apareceu e se tornou uma das principais áreas. Surgiu o seguinte ponto em que a comunicação "interrompeu". Este é o ponto na junção entre o cliente e o servidor . É sobre como o cliente deve interagir com o servidor no nível do protocolo, no nível do relacionamento. Isso foi decidido pelas conversas entre os clientes e os servidores. Mas o número de equipes cresceu, o número de pessoas nessas equipes cresceu. E o fato de que as informações sobre a interação do cliente e do servidor eram armazenadas apenas na cabeça dos desenvolvedores começaram a levar a problemas.

A documentação

Os problemas que encontramos foram bastante simples e óbvios. O relacionamento cliente-servidor não é apenas um protocolo, mas também um esquema de comunicação de acordo com este protocolo. Quais comandos enviar e quando, como o cliente deve solicitar algo, como o aplicativo é iniciado - tudo deve seguir o protocolo.

Por exemplo, os desenvolvedores da parte do cliente resolvem o problema e acreditam que a API possui um comando adequado que pode ser chamado e que tudo ficará bem. Este cliente é liberado e cria um problema no servidor, porque a equipe era muito pesada para ele e requer muitos recursos. Além disso, iOS e Android entendem a API de maneira um pouco diferente e a implementam de maneiras diferentes, por isso não podemos fazer alterações rapidamente na API. Assim, chegamos à conclusão de que o protocolo precisa ser documentado.

Liberar não voltar

A peculiaridade das plataformas móveis também é que o lançamento não pode ser retornado. Se o aplicativo estiver disposto na loja e o usuário o tiver instalado, é provável que demore muito tempo para conviver com esta versão do cliente. Erro no estágio de criação do protocolo, no estágio de determinação da interação entre o cliente e o servidor, querida. No Badoo, por mais um ano ou dois, teremos que suportar qualquer aplicativo lançado até que o número de usuários caia para um determinado limite.



Para resolver esse problema, decidimos alocar uma equipe MAPI separada, que documentará o protocolo e será o ponto de troca de conhecimento entre o cliente e o servidor . Essa equipe inclui funcionários do desenvolvimento de clientes e servidores. Essa equipe combinada está transformando os requisitos do produto para modificar o protocolo e sua documentação. Como o erro no estágio de implementação do protocolo é bastante caro para nós, os processos nessa equipe são um pouco mais complicados e difíceis do que em todos os outros. Eles usam uma revisão dupla de código, tentando eliminar o máximo possível a possibilidade de erro.

Essa equipe rapidamente se tornou um centro de compartilhamento de conhecimento. Muitas vezes, há situações em que os desenvolvedores de clientes e servidores não conseguem concordar sobre como devem interagir. Por exemplo, o iOS pode ser o único caminho, mas para o Android não é adequado. A nova equipe resolve esses problemas controversos e, se necessário, reúne as pessoas certas para tomar a decisão certa.



Se você observar o diagrama do nosso processo, a equipe da API móvel é um link intermediário entre quando os requisitos estão prontos e quando o desenvolvimento começa. Isto é:

• da equipe do produto recebe a tarefa de desenvolver TK (PRD);
• a equipe de projeto de protocolo elabora a documentação;
• começa o desenvolvimento das partes do cliente e do servidor de acordo com a documentação.

Com esse processo, o desenvolvimento do servidor e do cliente pode ser independente, e geralmente o usamos.

Problema de estatísticas

A empresa continuou a crescer e se desenvolver, havia mais pessoas e projetos. Lentamente, chegamos ao ponto em que surgiu uma equipe separada que lida com dados, estatísticas e ajuda a equipe de produtos a analisar como os usuários respondem às mudanças. Como eu disse, os problemas aparecem na junção de equipes . Temos uma nova equipe e, depois de um tempo, essa articulação também começou a funcionar de maneira ineficiente.

O fato é que os analistas precisam de bons dados para identificar padrões e responder a perguntas complicadas do produto. Bons dados significam que todas as estatísticas devem estar subordinadas a um único idioma. Quando falamos de estatísticas e de nosso produto, precisamos falar um idioma.

Antes disso, em cada tarefa técnica, o gerente de produto descrevia os princípios de coleta de estatísticas com palavras: para este botão, é necessário medir a taxa de cliques, para esta tela - a conversão. Mas o próprio desenvolvedor decidiu quais eventos rastrear, como medir (do cliente ou servidor), quais gráficos desenhar e, por exemplo, quais seções adicionar a esses eventos. O desenvolvedor pode fazer gráficos cortados por tipo de dispositivo, adicionar sexo, coletar estatísticas por país. Esses dados díspares chegam ao departamento analítico, mas, com base nisso, é impossível avaliar com precisão a qualidade da solução no produto. Como resultado, surge o eixo inverso das tarefas: fazemos alterações, essas alterações são implementadas, o gerente de produtos solicita análise, a equipe de estatísticas solicita dados adicionais, a tarefa é revisada, as estatísticas estão sendo finalizadas, aguardamos novamente ... Isso prolonga o ciclo do produto e esse foi o problema para nós.

O processo de coleta e análise de estatísticas precisa ser formalizado.



Decidimos que os requisitos para estatísticas serão registrados no ToR e os proprietários do conhecimento sobre os requisitos serão analistas. O analista, na fase de transferência do trabalho no TK para o desenvolvimento, diz quais estatísticas são necessárias, quais eventos rastrear, por quais fatias os dados são quebrados. Se o analista solicitar a expansão de estatísticas existentes ou a adição de novas, adicionamos novas funcionalidades ou modificamos as existentes. Para fazer isso, formalizamos o trabalho com dados em código. Criamos uma única API, que simplesmente não permite o envio de dados insuficientes ou inválidos.

Paralelamente, do ponto de vista das ferramentas, temos uma ferramenta rápida da Microstrategy para visualização de dados e nossa própria ferramenta para testes A / B. Os proprietários de todo o conhecimento sobre como usar essas ferramentas corretamente são analistas.



Outra etapa é adicionada ao diagrama do processo. O PRD passa pelo estágio de coordenação no departamento de análise e somente depois é transferido para o MAPI e desenvolvimento. Então funciona agora.

Compartilhamento de carga

O próximo problema está associado ao aumento de carga e interação dentro de um departamento. Lidero a equipe de desenvolvimento de back-end de nossos produtos e, por exemplo, ilustrarei quais problemas surgem com o aumento do número de funcionários em uma equipe.



Em uma equipe de até 15 pessoas, tudo é bem simples. Acreditávamos que todos fazem tudo e distribuem tarefas principalmente com base em quem está livre agora - é isso que ele faz. Por que até 15?

Acredita-se que um líder de equipe ou técnico ou líder técnico deva liderar uma equipe de 7 a 9 pessoas. Este é um número empiricamente estabelecido de um número adequado de subordinados.

Tínhamos um líder de equipe e seu vice, então juntos controlamos 14 a 15 pessoas. Com mais crescimento, alguma divisão adicional se tornou necessária. O fluxo de tarefas de desenvolvimento precisa ser equilibrado. Identificamos o principal requisito para esse processo: estamos formando especialização . Cada pedaço de código terá especialistas, 1-2 e, de preferência 3, que conhecem melhor esse código e que dão suporte a esse código. Mas, ao mesmo tempo, há um requisito ortogonal: manter a flexibilidade . Por exemplo, se cinco pessoas apóiam o mensageiro e muitas tarefas urgentes chegaram, elas não devem ficar ociosas. Se a equipe tiver recursos livres, eles deverão ser incluídos no desempenho das tarefas de outras pessoas. Esses requisitos se contradizem, mas ainda queremos tentar conseguir isso.



Dividimos uma grande equipe em grupos de desenvolvimento de 4-9 pessoas. À frente de cada grupo está o líder técnico e ele é o líder direto da equipe. Introduzimos esse conceito como um componente. Um componente é um pedaço de código preenchido em termos de funcionalidade do produto. Cada componente é atribuído a um grupo específico. Cada componente do grupo tem de 1-2 a 3 pessoas, especialistas nesta peça e envolvidos em seu desenvolvimento e suporte.

• Em termos de compartilhamento de carga, cada tarefa tem um componente.
• As tarefas de dívida e suporte técnico são distribuídas no grupo "nativo" - aquele ao qual esse componente está atribuído.
• Estamos tentando distribuir novas funcionalidades no grupo "nativo". Mas somente se tivermos essa oportunidade.
• Para manter a flexibilidade, não excluímos uma situação em que um grupo ajuda outro e faz algo que não está conectado aos seus componentes.
• Nesse caso, é realizada uma revisão de tarefa técnica ou uma revisão de código - isso é feito pelo grupo "nativo".

Nesta opção, estamos trabalhando agora. A equipe tem 30 pessoas, 5 grupos e 22 componentes que compartilhamos entre eles. Embora não vejamos o limite para mais crescimento nesse formato, vamos aderir a ele em uma determinada escala.



Um efeito colateral interessante: o que acontece em uma equipe quando o número de projetos, o número de pessoas e o número de mudanças cresce bastante. Estamos diante do fato de haver tantos no total que é difícil entender os motivos específicos de uma mudança.

Vou dar um exemplo do crescimento no registro de novos usuários no Brasil. O motivo pode ser: um bot de spam que registra novas contas e estraga nossas vidas; problemas com sessões; apenas uma campanha promocional; lançamento de uma nova onda de marketing no Brasil. A mudança é visível no gráfico e queremos entender com o mínimo esforço o que aconteceu.



Fizemos para nós uma ferramenta chamada WTF. Essa é uma ferramenta que coleta de todos os tipos de subsistemas e partes da produção algo que pode afetar as métricas. , . , (, ), ( ).



: — , - . .

:

• . .
• , .
• , , — .
• .

:

• .
• BI, ;
• MAPI .
• , — .

200 . , , . , :)

. , , .



Time-to-marker . .



. , , , - . , , .



: . , , . - . . : — . . , , . , .

-, , . - .

• . - . .
• . 10 , . : . . .
  
• - . bus- , . , , , .
  

, ( — ), . , OX . . OY .

, .



. - — . - , time-to-market , . - , , - , - , . , , . .



. - . , , . . , workflow. (, ) . - . , , .



, . , , , . , — . . — 2 , . , . , , . - - , - , .

. , , .



70–80 . , , . , . , - , .



.

— , - — .

, . , , - , , — - . , , — . .

—

, , . , . , .



. , . , , , . , - , , , server-side , . , , - , . , server-side, , . 14 , . - , server-side. , server-side 50/50. , , , . , , , - , , . , , .



.

— , . , , - , , .

. , , , , . « ».

. , — , , , . 50/50 10- .



, — . , . , 3 . - , 12 . 3 — , . , , , , , , , - , . — . . 11:00, — 9:00. , .

, — , 2 , , . , — , , - , -, , . , - , .



, , « ». - , , - . :

• : — , ..
• — , , , : « ». , .

O papel estratégico pode ser desempenhado remotamente por algumas visitas e conversas regulares, uma vez que é estratégico e não há necessidade de intervenção constante no trabalho. O papel do mentor, gerenciamento operacional, é bastante difícil de executar remotamente. Portanto, para nós mesmos, desenvolvemos uma regra de que, para todos os jovens e novos funcionários, a orientação técnica ocorre localmente. Há uma pessoa na equipe que assume as responsabilidades de um líder que orienta a pessoa em questões emergentes localmente. Nesse caso, o líder ainda pode executar um trabalho relacionado ao crescimento estratégico de uma pessoa.



Ninguém cancela o fato de que você só precisa se encontrar com mais frequência . Tudo é padrão aqui:

• Nós fazemos viagens de negócios um para o outro. Conheça o trabalho de design.
• Uma vez por trimestre, há uma análise de desempenho. Todos os gerentes que têm subordinados em outro escritório devem falar um a um. Ainda assim, falar por videoconferência não é como conversar pessoalmente com uma pessoa.
• Novos funcionários devem visitar escritórios diferentes - para se conhecer, ver como outra equipe funciona, conhecer um gerente de produto para um engenheiro ou vice-versa.
• Fazemos reuniões de grupo. O departamento é dividido em grupos e cada grupo se reúne uma vez por trimestre. Além disso, em diferentes cidades, por sua vez. Primeiro, um grupo se reúne em Moscou, os funcionários fazem algo juntos, de alguma forma interagem, passam por uma espécie de formação de equipe.
• Uma vez por ano, tentamos realizar uma reunião geral do departamento em um ambiente informal. Normalmente, este é um fim de semana para o qual você pode fazer algo útil, discutir problemas, mas ao mesmo tempo apenas falar “pela vida toda”. Ajuda a sentir que estamos fazendo uma coisa comum.

Também temos um evento para toda a empresa, chamado “All Hands”. Uma vez por trimestre, todos os funcionários da empresa se reúnem e alguém fala sobre o que alcançamos recentemente. Para reduzir a distância entre escritórios, esta reunião é realizada em Moscou ou em Londres. Em um quarto, todo mundo que deveria falar vem a Moscou, e uma videoconferência acontece em Londres. No próximo trimestre, pelo contrário, há uma performance em Londres e, em Moscou, apenas uma videoconferência.

É assim que vivemos no Badoo.

Convidamos você a espionar uma nova parte das experiências organizacionais de outra pessoa no Saint TeamLead Conf . O programa inclui palestras de empresas muito famosas: Sberbank-Technologies, Avito, JetBrains, Spotify ... sim, são legais!

Este relatório é uma das dezenas de relatórios. Se você não quiser esperar até que possamos decifrá-los e publicá-los em Habré, assista à lista de reprodução da conferência em nosso canal do YouTube .

Para não perder nada, assine a lista de discussão especial. Tentamos economizar seu tempo e publicamos notícias úteis: análises de transcrições, vídeos recentes, relatórios selecionados de futuras conferências.