Olá pessoal! Meu nome é Alexander Afenov. Sou o líder da equipe do Lamoda Order Processing. No ano passado, falei no TeamLead Conf 2018. A gravação da performance está disponível aqui .

No meu relatório, contarei a história de como me tornei líder de equipe, quais problemas encontrei e compartilharei várias estratégias que podem lhe parecer familiares individualmente. No entanto, concentro-me em que tipo de lucro eles dão no complexo.



O relatório será dividido em 3 partes:

1. Na primeira parte, falaremos um pouco sobre a empresa e os recursos de nossa TI. Isso é necessário para entender o contexto em que tudo acontece.
2. No segundo, falarei sobre o meu caminho na empresa.
3. Na terceira - sobre os métodos utilizados, seus prós e contras.

Lamoda como uma empresa de TI

Lamoda é conhecida principalmente como uma grande varejista de roupas da moda, sapatos e acessórios na Rússia e na CEI. No entanto, poucas pessoas sabem que, por um percentual ou valor fixo, prestamos serviços a diferentes empresas / entidades legais.

Deixe-me dar um bom exemplo. Digamos que você tenha um porão para bolsas de costura. Você criou um site para seus produtos e o promoveu com sucesso. Agora, muitas pessoas sabem sobre você, mas, apesar disso, você tem problemas com entrega, armazenamento e comunicação com os clientes.

Lamoda pode resolver esses problemas das seguintes maneiras:

1. Forneça os serviços do seu serviço de entrega.
   
   O LM Express é nosso próprio serviço de entrega, que desenvolvemos e automatizamos por um longo tempo.
2. Forneça comunicação com o cliente. Para fazer isso, temos nosso próprio call center.
3. Mantenha a mercadoria em casa ou até venda para você (comissão).
4. Marketplace. Os produtos dos parceiros podem ser exibidos em nosso aplicativo móvel, no site ou em sua versão móvel, e os parceiros fazem o resto.

Surge a pergunta: "Como você resolve seus problemas e satisfaz as necessidades dos parceiros?" Temos negócios em constante mudança e desenvolvimento, com nossas próprias necessidades. De alguma forma, melhoramos, desenvolvemos e avançamos. Ao mesmo tempo, você ainda precisa corresponder à lista de desejos que vem de fora. Parece que isso requer sua própria TI, e não uma pequena.

Estamos falando de desenvolvimento interno em todas as conferências desde 2016. Nós automatizamos todos os processos. São cerca de cem serviços diferentes: do processamento de pedidos e pagamentos ao trabalho com objetos de endereço e vales-presente. O suporte para tudo isso é uma equipe de aproximadamente 300 pessoas.

Por que estou falando sobre nossa TI e seu escopo? Porque 300 pessoas são muitas equipes. Quando algumas equipes trabalham em uma única pilha tecnológica, tentamos reutilizar todos esses desenvolvimentos. Podem ser pacotes configuráveis, bibliotecas, práticas no campo técnico. Mas também tentamos atrapalhar as práticas de processo bem-sucedidas entre os líderes de equipe, e falarei sobre isso mais tarde.

Questões-chave

Entrei para a empresa em 2015. Três dias após o meu emprego, foi agendada uma festa corporativa de Ano Novo, que eu decidi não participar. Minha prioridade era ficar e pensar em minhas tarefas por um período experimental.

O evento corporativo em Lamoda é um feriado temático para o qual todos gostam de se preparar. Portanto, no dia X, o arquiteto do meu departamento veio trabalhar no desfile, em um tailcoat. Naquela época, nossa equipe estava envolvida em serviços de processamento de pedidos. Era um monólito na antiga estrutura do Zend1 . O que eu observei? Os caras prepararam uma liberação forçada e queriam consertar alguma coisa. Depois de garantir que tudo estava bem, fizemos as malas e fomos para o feriado.

E aqui estou eu sentado. O lançamento entrou em produção com um hotfix, e na minha frente há uma bela TV de 50 polegadas com algum tipo de painel. No painel, havia um gráfico que dizia “Problemas no Rabbit MQ”. Parece que, se houver algum dado, algo quebrou. Mas não sei onde procurar para testar esta hipótese.

Você provavelmente pode olhar para algum tipo de log. No entanto, estou apenas no terceiro dia de trabalho e não sei onde eles estão. Eu acho que posso encontrar um link para o quadro grafana. Talvez valha a pena procurar nela a fonte de métricas e cavar lá? Sim, mas é muito acidentado. Eu gostaria que isso fosse documentado de alguma forma. E, novamente, há a pergunta: quem são todas essas pessoas que estão sentadas? Dois ou três andares nos quais a TI é distribuída. Todo mundo está fazendo alguma coisa, e eu não sei com quem me comunicar se algo der errado. Não há uma tabela dinâmica clara com quem eu poderia entrar em contato se percebesse que o lançamento está quebrado. Ou talvez haja uma pessoa de plantão, mas eu simplesmente não sei?
* (é claro que ele era) *

Havia outras perguntas. O primeiro e mais ridículo, ao qual retornaremos repetidamente: “Onde está a documentação?”. A resposta é simples: simultaneamente em qualquer lugar, lugar e na mente de funcionários experientes. Como todos saíram para a festa corporativa, mas eu não sei onde estão as docas, a resposta me pareceu "em nenhum lugar". Eu tinha um leia-me no qual lancei o projeto no meu laptop. Mas isso não foi suficiente. Eu queria obter respostas para muitas outras perguntas. Por exemplo, quais são as regras básicas de "comportamento" para um desenvolvedor?

Deixe-me explicar: eu decidi solicitar acesso ao sistema de combate para entrar na interface do usuário. Seria muito útil para mim, pois minha tarefa para o período de teste era refazer o sistema de autorização e eu queria apertar botões, fazer login no estande de produção. Fiz um pedido ao serviço de segurança, ao qual recebi rapidamente uma resposta sucinta: "Não, não daremos acesso". Aconteceu que apenas usuários reais têm acesso ao sistema de combate: funcionários de armazém, um call center e assim por diante. Desde que trabalhei anteriormente em telecomunicações, me acostumei ao fato de ter lido e gravado acesso às bases de produção de várias operadoras de telefonia móvel. E aqui, ao que parece, é impossível. Existe um protocolo.

Além disso, me deparei com muitas outras condições e restrições que o líder da equipe me falou. Nos primeiros dias, ele me dedicou a muitos momentos fascinantes. Havia tanta informação que nem tudo era capaz de ser lembrado e anotado.

As seguintes perguntas que me interessam dizem respeito a uma perspectiva de longo prazo. Por exemplo, como e onde crescer?

Por que isso é importante? Porque desde o começo eu preciso me comportar de alguma forma. Eu vim para a posição de desenvolvedor php médio. O que devo fazer a seguir para exceder as expectativas e, no futuro, obter uma nota mais alta, por exemplo, Sênior? E mais uma pergunta: "O que é esperado de mim na minha série atual?" Ou seja, quanto devo me envolver em processos como revisão de código, liberações, serviço?

Todas as perguntas que listei agora foram respondidas pelo nosso líder de equipe. Os dois últimos, mais estratégicos, foram respondidos pelo sistema de avaliação de desempenho. Vou lhe contar mais sobre isso.

Revisão de desempenho

A cada 6 meses, uma pessoa realiza uma chamada auto-revisão. Ele fala sobre as coisas legais que ele conseguiu fazer no tempo previsto. No entanto, existe uma armadilha. Isso está relacionado ao fato de as pessoas geralmente indicarem essas conquistas na auto-revisão, as quais elas estão subjetivamente inclinadas a considerar como tal. Pensar em termos de negócios é incomum, e mesmo que o projeto de rotina permita à empresa ganhar muito dinheiro, então, para o desenvolvedor, ele pode não ser um desafio ou interesse. Existe o perigo de que em uma revisão desse projeto não seja indicado.

O próximo passo é uma revisão por pares. Isso é seguido por uma série de comissões nas quais há comunicação entre líderes de equipe, gerentes de departamento, estações de serviço e, se necessário, o diretor de RH. Em seguida, uma mensagem sobre os resultados.

Quais são os possíveis resultados?

A primeira opção: uma pessoa conseguiu piorar em seis meses do que antes do início do trabalho. Parece hora de dizer adeus. Isso acontece muito raramente, mas seremos realistas - acontece.

Outra opção é um empate. Algo parece estar faltando. Pode haver velocidade, previsibilidade, perseverança. Algo precisa ser melhorado.

Três - o que eles esperavam, eles conseguiram. Uma pessoa trabalha em um ritmo adequado e, em todos os aspectos, corresponde à sua nota.

Quatro - fez mais do que o acordado. Candidato a promoção / salário.

Lobo de cinco lã. Parece que é hora de aumentar, dar bônus e assim por diante.

Eu mesmo passei por várias iterações dessa revisão. Anteriormente, acontecia trimestralmente, o que não era muito conveniente, pois durante 3 meses nem sempre a oportunidade de provar a si mesmo. Agora a revisão ocorre a cada seis meses.

Então, no começo eu cresci de desenvolvedor sênior no senior. Então meu líder de equipe decidiu que agora ele quer trabalhar mais com tecnologia e passou para o cargo de equipe técnica (arquiteto), e eu me tornei um líder de equipe.

Então, o que vem a seguir? Eu preciso fazer alguma coisa, de alguma forma, dominar.

A primeira coisa que você encontra são as mesmas perguntas sobre as quais falamos antes, apenas agora em um nível um pouco diferente. Ou seja, ainda não está claro: onde está essa documentação? Agora, de alguma forma, preciso me comunicar com outros departamentos, com outros líderes, arquitetos e outras pessoas, pensar em um nível superior. Mas neste nível de documentação, provavelmente também não.

Outro ponto são as mesmas "regras básicas". O que posso fazer

Acho que posso acompanhar as tarefas, fazer uma revisão de código. Talvez agora eu tenha o poder de mudar processos, de alguma maneira de me comunicar com as pessoas.

Como e onde crescer? Essa pergunta não desaparece, porque você pode se tornar o chefe do departamento (líder do grupo).

Bem, a pergunta - o que é esperado de mim também me parece bastante compreensível.

E agora você precisa ser capaz de responder a todas essas perguntas não apenas para si mesmo, mas para toda a equipe. No meu caso, a equipe foi recrutada quase do zero. Acontece que para cinco ou sete pessoas eu tenho que dizer tudo, explicar, estabelecer metas. Leva tempo e esforço. Tais coisas precisam ser planejadas e pensadas. Então, qual é a responsabilidade do líder da equipe?

O que uma equipe deve liderar?

Antes de tudo, é trabalhar com tarefas : sua formulação, ajuste, descrição da pessoa que recebe a tarefa durante a série. Por exemplo, para um júnior, prefiro fazer uma descrição muito detalhada e esperar que ele escreva o código e os testes corretos. No último ano, comunicarei uma meta técnica ou comercial e ele estará livre para decidir por si próprio como alcançá-la. De qualquer forma, tudo isso leva tempo.

Obviamente, você precisa fazer uma revisão de código quando surgirem conflitos durante ela. Monitore o que está acontecendo, mova tarefas por status. Também desempenho regularmente as funções de um engenheiro de lançamento. Você precisa pensar frequentemente em como nossa implantação afeta todos os outros.O serviço que presto é o processamento de pedidos. Está associado a quase todos os sistemas Lamoda e, consequentemente, é capaz de afetar muitos processos de negócios durante seu lançamento.

Outro ponto é o monitoramento, alertas e mudanças associados a isso. Se um recurso de negócios aparecer, é necessário monitorá-lo, introduzir novas métricas, desligar notificações, informar o serviço de suporte e assim por diante. Todos esses são problemas de arquitetura. No momento, não tenho um arquiteto dedicado em meu departamento. Desempenho suas funções nesses casos em que você precisa de uma solução específica no âmbito de uma tarefa / projeto específico.

Ainda precisa prestar atenção às comunicações . Isso inclui reuniões pessoais que ocorrem aproximadamente a cada duas semanas com cada desenvolvedor; retrospectivas, planejamento, comunicação com gerentes e outros departamentos. Mas ainda assim seria bom não sujar.

Muitos dizem que seria ótimo, após 10 anos de desenvolvimento, obter uma proporção de “gerenciamento para desenvolvimento” em torno de 80 a 20. Mesmo isso nem sempre é possível. Como resultado, você inevitavelmente perderá experiência e ficará fora das tendências atuais. É necessário continuar a crescer ainda mais.

Existem estratégias possíveis de como você pode crescer em termos de sua posição. Na próxima seção, falaremos sobre como a rotação de funções em uma equipe ajuda a aumentar o fator de barramento.

Rotação de funções

Vou atualizar aqueles que não sabem e dizer qual é o fator do ônibus.

Fator de barramento é um número que indica que, se um certo número de desenvolvedores "bater em um barramento", o trabalho no projeto será interrompido. Pode se manifestar em vários níveis. Por exemplo, pode ser um fator de barramento para algum elemento específico do sistema complexo.

Suponha que tenhamos um caso em que precisamos resolver um determinado sistema de relatórios. O desenvolvedor passou 5 dias para fazer isso. O bug foi complicado, mas foi corrigido e estava tudo bem. Em seguida, surge outro problema no mesmo módulo e o mesmo desenvolvedor encontra-se em licença médica. Isso significa que a próxima pessoa deve gastar a mesma quantidade de tempo resolvendo o problema. Você precisará descobrir do zero, porque não há documentação (haha).

O que será discutido mais adiante são precisamente as estratégias para aumentar o fator de barramento. E eles se reunirão em uma imagem bastante agradável com todos os deveres anteriores do líder de equipe, sobre os quais falei.

Além da documentação, é necessária experiência real. Ou seja, você precisa de uma equipe que já conseguiu tocar em diferentes partes do sistema e agora está pronta para lidar com qualquer tarefa. Mas se a equipe se unir, tudo isso não virá do nada. Meu principal objetivo é dizer como é possível combinar várias abordagens diferentes que permitirão resolver problemas com documentação e experiência.

Engenheiro de Suporte

Todo mundo já ouviu falar sobre desenvolvedores virtuais. Mas não falaremos sobre kits de RV e não sobre pessoas em um site remoto, mas sobre o papel de um engenheiro de suporte.

Quem é um engenheiro de suporte?

Temos um cara que analisa uma lista de pendências de suporte. Ele veio para o trabalho, ele não tem uma única tarefa. Ele abriu uma lista de pendências para suporte no rastreador de tarefas (Jira), e as tarefas foram classificadas por criticidade. Ele pegou o mais importante e começa a reparar. Depois que todos os problemas foram resolvidos, ele escreve por que ele quebrou e como evitá-lo no futuro. Se ele não tiver outro suporte (isso é engraçado, porque o suporte nunca termina), ele examinará o backlog técnico, que já é bastante grande.

Um pouco de distração: estamos falando de um sistema de cem mil e quinhentas linhas na antiga estrutura do Zend 1 . O arquiteto da equipe anterior disse uma vez que, de acordo com o nosso sistema, temos uma dívida desse tamanho - não é uma dívida técnica, mas uma hipoteca técnica. Daí o título do relatório.

Se não houver nada a fazer, o engenheiro de suporte poderá executar algumas tarefas não prioritárias a partir daí, o que não é uma pena encerrar e retornar ao suporte recém-exibido. Isso geralmente acontece. E ele não faz isso por mais de uma semana, porque seria um caminho direto para a frustração. Se durante toda a iteração de duas semanas você estiver envolvido apenas em obter apoio, isso irá desmotivá-lo bastante. Você repara, repara, repara e não há fim para isso. Por esse motivo, toda semana transferimos o papel de engenheiro de suporte para a próxima pessoa.

Engenheiro de Liberação

Há outra posição virtual que é muito conveniente para descarregar o líder da equipe - este é um engenheiro de lançamento. Ele prepara lançamentos para versões de correção pré-planejadas, coleta ramificações, prepara compilações, executa todos os testes. Se os testes forem executados automaticamente, simplesmente controlará o resultado. Em sua área de responsabilidade, escolha como é bonito rolar sem tempo de inatividade e efeitos especiais para sistemas que dependem de nós.

Acontece que precisamos de comunicação com outras equipes antes da implantação para avisá-las de alterações. Como resultado, o engenheiro de lançamento lança tudo e olha para ver se algo se desintegrou. Nós usamos para isso, Sentry , Prometheus , Icinga , olhar para Elastic, usando Kibana . O engenheiro de lançamento decide o que fazer se algo der errado. Ou seja, é sua responsabilidade decidir se é necessário algum tipo de hotfix ou se todos quebramos, perdemos dinheiro e precisamos fazer uma reversão. A decisão de reverter é tomada apenas como último recurso, mas isso também acontece.

Ele (engenheiro de lançamento) registra os problemas que surgem. Se algo rasgasse, seria ótimo aprender com seus erros. Para isso, ele indica a data de lançamento e os erros que levaram ao problema. Isso permite que o próximo engenheiro de lançamento observe problemas comuns e evite-os. Bem, sim, ele não faz isso por mais de uma semana consecutiva, porque a coleta de um lançamento é cara.

Se a versão for grande, meio dia voará facilmente e é muito difícil chegar a tempo de mudar para suas tarefas. Por exemplo, você iniciou uma montagem que leva 20 minutos. Enquanto a montagem estiver em andamento, você pode fumar ou pensar na vida. Mas se você retornou à tarefa e a montagem foi bem-sucedida, é necessário mudar novamente. Em geral, esse é um processo bastante sombrio, saindo do desenvolvimento normal e não permitindo a entrada no fluxo. Por esse motivo, na próxima semana, o engenheiro de lançamento é uma pessoa diferente.

Tekhlid

Outra posição virtual mais interessante é o líder técnico.

Um arquiteto (às vezes chamado dessa maneira) entra em conflito quando há uma grande tarefa importante ou um novo projeto é lançado. Isso significa que ele assume a responsabilidade pelo design, desenvolvimento e lançamento. Ele tem o direito de se comunicar com o líder e o gerente da equipe, tomar decisões técnicas e a obrigação de documentá-las é transferida. Se ocorrer algum lixo no início, ele registra todos os problemas que ocorreram e suas causas da mesma maneira que um engenheiro de liberação ou engenheiro de suporte.

Conclusões

O que obtemos como resultado?

A alternância de papéis em uma equipe por um longo período de tempo (pelo menos seis meses) possibilita que um jovem inexperiente obtenha a habilidade de trabalhar com várias partes do sistema e tipos de tarefas.

No começo, falei sobre o fato de que a documentação e a experiência real podem ajudar na solução de problemas típicos. Depois de aplicar as práticas descritas, não é um fato que você resolverá o problema da documentação, mas uma experiência variada e de alta qualidade será adquirida por todos os participantes da equipe de desenvolvimento. Durante uma longa rotação de funções virtuais, uma pessoa consegue tocar em várias partes do sistema como engenheiro de suporte. Como engenheiro de liberação, ele aprende a implantar, comunicar, observar, tomar decisões rapidamente. Se ele assumiu o papel de especialista técnico, está se preparando para conduzir projetos maiores e mais importantes de forma independente.

A partir desse momento, o líder da equipe pode e deve delegar suas tarefas aos subordinados, porque, se você se lembrar, o líder da equipe tem a tarefa de não se expor e crescer em algum lugar.

Graças a essas práticas, torna-se possível finalmente dar a alguém uma parte do seu trabalho. Por exemplo, lançamentos. São de 4 a 8 horas por semana, que são repentinamente liberadas de tempos em tempos. Agora você pode gastá-los em desenvolvimento, lendo artigos, resolvendo outros problemas. Um grande erro seria não mexer no calendário e gastá-lo em reuniões não tão úteis. Embora, via de regra, isso aconteça :) Agora, o líder da equipe pode se alegrar, pois tem a oportunidade de ficar menos nervoso e confiar parte de seu trabalho nos funcionários. Se algo acontecer com ele, os projetos não serão retomados.

Como resultado, aumentamos o fator de ônibus do líder da equipe. A equipe, por sua vez, pode ter certeza de que, se algo der errado com o líder da equipe, qualquer um deles estará pronto para assumir um trabalho e lidar com ele.

Claro, existem limitações. Essa abordagem não é possível se você fizer tudo sozinho (departamento pessoal).Se um casal é subordinado a uma pessoa, já existe a oportunidade de girar o relógio e liberar. Três parceiros e mais é ainda melhor.

No meu caso, existem 5 desenvolvedores, três dos quais compartilham papéis virtuais entre si. Os outros dois estão simplesmente envolvidos no desenvolvimento, novos recursos. Eles não estão envolvidos em lançamentos, suporte e assim por diante.

Outro fator importante é o tempo. Você terá que perseverar até o momento em que a rotação dos papéis surtir o efeito adequado e preparar uma equipe para executar tarefas que geralmente estão na competência do líder da equipe. O problema é que usamos o tempo como um recurso muito acessível e reabastecido. Mas isso não é de todo verdade. Você pode supor que, em seis meses ou um ano, o desenvolvedor, de alguma forma, se “balançará”, obterá a experiência necessária e estará pronto para o serviço e qualquer outra coisa. Mas isso pode não acontecer e, como regra, não acontece se a situação for deixada ao acaso. O fluxo de tarefas pode ser tal que não tenha motivação externa para se desenvolver da maneira correta. E são as alternâncias de papéis virtuais que dão a chance de que você possa ajudar os membros da sua equipe a desenvolver de maneira abrangente e avançar para as próximas séries.

, : « , , , ” . , , , . . , . - .