Neste artigo, falarei sobre minha experiência como líder de equipe em uma empresa de desenvolvimento de sites. Para que fosse mais útil e fácil para todos lerem, o artigo está dividido em capítulos, cada um dos quais fala sobre um problema separado e sua solução. Embora, se possível, a cronologia dos eventos seja preservada.
Espero que a experiência descrita abaixo se torne um rake de outra pessoa, e nos comentários eu mesmo retiro algo de colegas mais experientes.
Mas não há nomes, empresas, clientes, nomes de colegas. Acordo de não divulgação, tudo.
Background. Como e onde me tornei líder de equipe
Esta é a primeira empresa em que vim imediatamente com um líder de equipe. Para mim, foi um salto quântico em termos de crescimento na carreira. Eu vim para o último emprego (1,5 anos) como intermediário e cresci lá até o último ano. Mas as gradações dos desenvolvedores são subjetivas demais e geralmente dependem apenas da empresa em que trabalham. Por um tempo, estudei bastante a questão de avaliar programadores e, basicamente, tudo se resumia ao fato de que "se eles tomavam o nível médio / sênior / sênior, eu me tornava médio / sênior / sênior". Quando comecei a procurar trabalho, eu já teria ocupado um cargo sênior (e estava procurando por ele), mas a oferta de timlidismo me superou e fiquei um pouco lisonjeada.
Na verdade, quando eu estava procurando vagas, no segundo dia fui atraído para uma empresa metropolitana que desenvolve sites no Bitrix (então tudo acontece no contexto de desenvolvimento de sites no Bitrix). Eu, pelo contrário, há muito sonhava em deixar a Bitrix, mas a oportunidade de realizar meu potencial em uma nova qualidade e um bom salário não me deixou chance de recusar.
Fato engraçado: a única condição para me contratar era que eu mesmo pudesse escolher a pilha tecnológica, mas em nenhum caso devo recusar o Bitrix se o cliente insistir.
Em um novo lugar
No novo local, havia um chefe técnico muito bom, um gerente ruim, June, Middle e vários projetos realmente grandes no Bitrix. É uma situação bastante estranha e ainda não entendo como ela se desenvolveu e não entrou em colapso imediatamente. Mas talvez eu tenha sido convidado apenas para fazer as coisas acontecerem.
Nos primeiros dias, muitos problemas "infantis" foram marcantes:
- as informações do projeto foram armazenadas na cabeça de uma ou duas pessoas e em nenhum outro lugar. Também não havia instruções e documentação e, para descobrir como isso funcionava, era necessário torturar quem o criou, se é que o criamos.
- não havia sistemas e processos estabelecidos, tudo foi feito "de alguma forma", "por hábito". Daí vaidade, confusão, falha no cumprimento de prazos, estresse
- tarefas foram consideradas em palavras. Os rastreadores tinham apenas o nome das tarefas, apenas para reservar um tempo em algum lugar (era necessário digitar 40 horas por semana)
- o desenvolvimento em si também não foi tão quente:
- em algum lugar, algo estava sendo desenvolvido mesmo fora do gita
- em algum lugar, os programadores se revezavam na edição de arquivos em um servidor
- em algum lugar havia sites de teste, mas em algum lugar eles não estavam (mas, de qualquer forma, não ajudaram muito)
- Além disso, em todos os lugares havia um muito, muito govnokod. Antecipando os comentários, o próprio Bitrix, infelizmente, não tem nada a ver com isso.
- Toda a comunicação ocorreu no Skype. Mas eu só tenho uma aversão pessoal por ele
Em geral, tudo está obviamente ruim, as melhorias podem começar imediatamente, sem a realização de estudos preliminares. Até isso me deixou feliz em certa medida, já que você pode influenciar os indicadores desde os primeiros meses. Eles realmente ainda não foram considerados, mas por causa de Pareto, isso ainda não é importante.
Para minha decepção, os processos se moveram bastante lentamente durante os primeiros meses. Primeiro, eu mesmo tive que trabalhar nas tarefas do cliente por 8 horas por dia, como programador, porque simplesmente não tinha mãos suficientes. Em segundo lugar, nas condições de tal pressão de tempo, era bastante perigoso fazer grandes mudanças que poderiam levar a confusão e perda de código ou tempo.
Agora vamos diretamente ao artigo e à resolução de problemas. A primeira coisa na nova empresa foi de alguma forma orientar.
Obtendo informações dos objetivos dos funcionários
Quando cheguei, não sabia absolutamente nada sobre projetos ou clientes, e essas informações não foram armazenadas.
em nenhum lugar na forma de texto. Portanto, a primeira coisa que comecei a extrair informações dos objetivos dos colegas nos textos.
Essencialmente, uma empresa de desenvolvimento possui 2 grandes subconjuntos de textos importantes e / ou úteis:
- instruções, regulamentos, artigos, descrições funcionais, histórias de usuários, ...
- Tarefas com nome, descrição, comentários, registros de horas, assinaturas para confirmação, comentários no código, autoteste, ...
No começo, eu apenas pedi aos meus novos colegas que escrevessem coisas específicas para mim desde o primeiro parágrafo, mas é claro que todos eram preguiçosos, principalmente porque as instruções para escrever não são um recurso a ser cortado. Mas como no começo eu ainda tinha uma aparência completamente não-fumante e tive que estudar os projetos, vendo-os pela primeira vez, comecei a traduzir minha pesquisa em texto, criando instruções e descrições da funcionalidade.
Também foi uma sorte que, ao mesmo tempo, a empresa começou a mudar ativamente para o scrum (apenas uma coincidência), o software em funcionamento estava mudando (também uma coincidência), respectivamente, os processos de negócios foram criados a partir do zero. E, por alguma razão, inicialmente eu tinha grande autoridade aos olhos de meus colegas. Portanto, eu apenas comecei a escrever as regras (dentro da competência) e reconstruir os caras nelas, ou seja, apenas ditar as regras e ser um exemplo de sua implementação.
A solução do problema com a formulação e gerenciamento de tarefas foi adiada por mais de um mês. Isso acabou sendo um gargalo e, nos capítulos subsequentes, abordarei esse tópico mais de uma vez.
No início do meu trabalho, o gerente definiu tarefas terrivelmente. Exemplo: o nome da tarefa é "Corrigir o bug no site" e é isso: nenhuma descrição, nenhuma captura de tela, apenas o nome e a referência ao projeto. Obviamente, houve tentativas de transmitir os princípios do SMART e a importância de descrever as tarefas ao gerente, mas todas as empresas foram divididas em "Não tenho tempo para pintar tarefas".
Ao mesmo tempo, tentei assumir parte da responsabilidade pela definição de tarefas, mas é irônico que também não tive tempo suficiente para isso, já que escrevia código quase o tempo todo.
Mas o problema relacionado de obter o status atual das tarefas a qualquer momento, decidimos ignorar, por meio de telefonemas e planos de coordenação para o dia.
Reabastecimento de equipe, integração de equipe
Quase inicialmente ficou claro que havia muita falta de pessoas (eu mesmo escrevi o código de tempo integral, mas ainda não tínhamos tempo).
Os primeiros decidiram tomar a frente, porque as duas progers na empresa estavam na retaguarda (e eu também me identifiquei mais com o back-end), e havia tarefas suficientes, especialmente no layout, e as tarefas de reação e valor começaram a aparecer no horizonte.
Foi muita sorte que eu tinha (e tenho) um amigo na frente, que ao mesmo tempo começou a pensar em sair como freelancer, para que pudéssemos preencher rapidamente a vaga e recebi um bônus por trazer um funcionário (outra vantagem para as autoridades antes disso) vistos hr-awards).
Quase imediatamente após a frente, foram encontrados 2 sinais. E em algum lugar ao mesmo tempo, o joon foi embora (cujo código me cutucou alguns meses após sua partida).
No total, a seguinte situação se desenvolveu:
- um "velho"
- eu
- três iniciantes absolutos
- trabalho ainda não foi estabelecido
- algum conhecimento já está perdido
É natural que dezenas de perguntas dos recém-chegados imediatamente caíssem sobre mim, como líder de equipe. Basicamente, essas eram perguntas sobre o ciclo de vida do código (onde escrever o código, como mostrar para onde enviá-lo mais tarde, como coletar o release), sobre o gerenciamento de tarefas (como colocar tarefas no trabalho, como mostrar status, como determinar prioridades) e como trabalhar com o git . Além disso, os caras ainda estavam tentando fazer as perguntas "Como funciona A?", "Temos um B no nosso site?", Mas quase tudo naquele momento foi reduzido apenas à necessidade de estudar o código.
Antes de tudo, era importante dar aos programadores a oportunidade, em princípio, de trabalhar e escrever código por conta própria. Conduzi conversas introdutórias com eles, respondendo às perguntas deles, depois, é claro, decidi reduzir todas as perguntas e esquemas em um artigo, que depois se transformou em uma palestra e, em seguida, em um esquema de trabalho completamente novo na empresa, que discutirei no próximo capítulo.
Aqui, vale a pena dizer algumas palavras sobre o processo de contratação em nossa empresa, que ainda está funcionando.
Processo de contratação
Em primeiro lugar, temos um bônus por atrair um funcionário, o que é uma boa prática.
Em segundo lugar, decidimos não marcar um exame na entrevista, mas dar uma tarefa muito volumosa, próxima às do dia a dia. Isso é conveniente, pois o tempo gasto na contratação é reduzido apenas até a busca de currículos adequados e uma entrevista fácil com os candidatos para verificar a adequação e uma história sobre a tarefa de teste e, é claro, verificar diretamente a tarefa.
Junho pode realmente resolver o problema em algumas noites, o volumoso proporciona muita liberdade na implementação, melhorias e chips óbvios. É essa flexibilidade de implementação que nos ajuda a avaliar o nível do candidato. Dizemos imediatamente que o mais importante para nós é cumprir os prazos para resolver o problema (o executor se autodenomina) e, no final, mostrar o código de trabalho no repositório. Não estipulamos o uso de nenhuma abordagem e tecnologia, elas são escolhidas pelo artista, mas, para atender e dar dicas, listamos possíveis melhorias na lista, como tarefas com um asterisco, por exemplo, trabalhando com o Ajax, ext. validação de retorno, proteção contra spam, design de módulos, uso de D7, ...
Total:
- De acordo com o resumo e a entrevista, podemos julgar a natureza da pessoa
- até o prazo para concluir a tarefa, o fato da capacidade de trabalho do código e o uso do gita, tomamos a própria decisão de contratar
- pela qualidade do desempenho, determinamos o nível e, consequentemente, o salário que podemos oferecer
- mais já na tarefa de teste, mostramos quais tarefas terão que ser resolvidas em um novo local
Estabelecendo um Sistema de Desenvolvimento e Entrega de Código
Naquela época, tínhamos vários projetos que foram desenvolvidos aleatoriamente:
- em algum lugar na batalha havia um mestre, em outro lugar um galho
- em algum lugar havia sites de teste, em algum lugar não
- e se houver, os endereços de todos são diferentes
- O git, em princípio, foi usado fracamente e com um rangido
- alterações manuais no banco de dados
- ...
No começo, tentei corrigir a situação em pequenas porções, para que os programadores precisassem menos de reaprender e, consequentemente, ficassem confusos. Por exemplo, tirei a pasta bitrix de baixo do gita e renomeei o ramo principal de volta ao mestre.
Mas quando um grande reabastecimento chegou até nós, a situação se tornou crítica. Eu tive que explicar muito, lembrar e escrever instruções ilógicas, pois a atual estrutura de desenvolvimento não era de todo muito intuitiva.
Como não sou fã de instruções, acredito que a presença delas é um indicador do problema em si, por isso foi decidido criar um sistema comum para todos os projetos que precisam ser entendidos uma vez e que, por sua própria estrutura, remove muitos problemas e perguntas.
O sistema é o seguinte:
- cada desenvolvedor tem uma plataforma de trabalho pessoal remota onde ele trabalha
- existe uma plataforma em que a funcionalidade é acumulada para a próxima versão
- se necessário, existe uma plataforma de demonstração para demonstrar todos os primórdios da funcionalidade
- todo o código de uma tarefa é mantido em uma ramificação separada, em que o nome da ramificação é igual ao nome da tarefa no rastreador
- para preencher o código em uma plataforma comum, basta manter o ramo em algum lugar e pressionar
- mudanças nos bancos de dados são armazenadas como arquivos de migração na ramificação da tarefa
Eu dei uma grande palestra sobre o assunto desse sistema e iniciamos uma transição piloto para ele em um projeto, onde acabamos de lançar o recém-adquirido sênior.
O processo de transferência de todos os projetos para esse sistema, é claro, foi adiado (por exemplo, em um projeto não conseguimos mover misticamente para o mestre na primeira vez) e ainda continua, mas, como resultado, obtivemos pelo menos:
- a capacidade de liberar apenas as tarefas necessárias e não a funcionalidade inacabada, juntamente com o código útil
- execute um release de tarefa sem envolver um autor de código
- trabalho paralelo em um projeto entre artistas
- não perca código
- testar a funcionalidade isolada de outra e não interromper o trabalho do programa
Tudo isso simplesmente não existia antes. Além disso, você não precisa explicar os detalhes extras do trabalho com sites git ou test para novos programadores agora, pois tudo é universal e intuitivo.
Scrum, comunicações, regulamentos
Obviamente, no artigo pretendi falar sobre como ajudei no desenvolvimento da empresa como líder de equipe, mas você não pode falar sobre o desenvolvimento de nossa empresa sem mencionar nosso chefe e sua iniciativa, caso contrário não será totalmente honesto.
Primeiro, ele introduziu o scrum e, no momento da minha chegada, os processos na empresa começaram a ser ativamente refeitos. Também naquele momento a transferiu de Bitrix24 para Jira.
O Scrum certamente trouxe mais ritmo à empresa e reduziu o caos. A reciclagem de gerentes, a execução de chamadas de coordenação, a abertura / fechamento / planejamento de sprints foram monitorados pelo próprio chefe, como o mais velho neste link.
Ele também trabalhou muito com os próprios gerentes, especialmente em como eles se comunicam com clientes e programadores, já que a maior parte de seu trabalho (mas, é claro, não se limitando a) consiste em se comunicar: isolar programadores de clientes, transmitir desejos dos clientes. tarefas no backlog e nos sprints, encontre e reconte histórias de usuários. Tudo isso resultou em muitos regulamentos: na comunicação com os clientes, na definição de tarefas, no trabalho com um backlog, na aceitação de erros no trabalho. Foi dada forte ênfase à comunicação e o vínculo gerencial realmente mostrou progresso.
A transição para o scrum em si, é claro, é muito difícil e, no momento em que escrevemos este artigo, ainda não nos tornamos seus profissionais, embora tudo isso aconteça. E estou muito feliz por ter recebido muitos conhecimentos novos sobre metodologias e produtos flexíveis da Atlassian.
Novo gerente. Textos, configuração de tarefas, lista de pendências
Em algum momento, outra pessoa veio nos ajudar a dar um salto quântico - um novo gerente (antes disso tínhamos).
Eu não esperava esse momento, já que não tínhamos tantos projetos e programadores e, em teoria, apenas um gerente deveria ser suficiente. Esse link foi um ponto fraco na empresa, mas tentamos resolver esse problema desenvolvendo a equipe existente. Aconteceu que um gerente excelente, que eu conheço bem, decidiu mudar de emprego, meu chefe descobriu sobre isso, pois de repente ela entrevistou nossos contratados e eu mencionei esse incidente engraçado, e nós a chamamos para nós mesmos. Outro prêmio)
No início, a nova gerente repetiu parte do meu caminho, enfrentando os mesmos problemas (ela não sabe nada e nenhum lugar para ler) e começou tudo de novo, mas com a diferença de que ela não tocou no código, na infraestrutura de desenvolvimento e nas habilidades do programa, mas trabalhou com estabelecendo metas, comunicando-se com os clientes, limpando a lista de pendências e também puxando diligentemente informações do chefe do gerente antigo. Em particular, a primeira coisa que retirei foi a lista de contatos de clientes e contratados.
A equipe já a conhecia, pois uma vez a convidamos como palestrante para nos contar sobre gerenciamento de tempo. Além disso, as tarefas do aço começaram a ser colocadas com mais detalhes, ela não acrescentou negatividade e não a transmitiu do cliente, os status das tarefas tornaram-se mais relevantes a qualquer momento. Portanto, imediatamente depositamos grandes esperanças nela.
Nas primeiras semanas, ele e seu chefe limparam a carteira de pedidos em um projeto, em particular, encontraram um período vencido de 2 meses e uma epopéia que ainda não havia começado. Além disso, em princípio, surgiram muitas tarefas que precisavam ser realizadas há um mês. É bom, é claro, que a lista de pendências tenha sido limpa, mas foi feita muito tarde.
Ela mesma realmente “desligou” da bagunça e tentou sair várias vezes, mas melhoramos o vínculo gerencial de uma maneira ou de outra. É menos provável que as tarefas sejam perdidas no backlog, é menos provável que os programadores perguntem novamente.
A moral da história estará no final.
A crise
Quase meio ano após o início do trabalho, tive que sair de férias. A propósito, eu concordei em férias, mesmo quando me candidatava a um emprego, como era planejado como lua de mel, então o período da minha ausência era conhecido com bastante antecedência. Mas enfim, claro, fiquei nervoso até o fim, porque só recentemente paramos de trabalhar “por desgaste”.
Na semana anterior às férias, terminei de delegar tarefas, ensinei pessoas selecionadas a executar tarefas específicas fora do código, atribui a responsabilidade de cada programador de um projeto específico, concluí ou transfiro todas as minhas tarefas atuais (eu ainda estava programando a maior parte do dia). Nada aconteceu em meados de julho.
E também nos primeiros dias de férias, nada indicava problemas.
E então houve uma crise.
Em um projeto, o cliente ficou sem paciência devido ao fato de suas expectativas de tarefas (prazos, lista, prioridades) não corresponderem ao caso. Nós mesmos percebemos isso não faz muito tempo, com o processamento completo do backlog e a comunicação ativa com o cliente (capítulo sobre o novo gerente), mas já era tarde demais.
E no segundo projeto, eles finalmente aceitaram uma tarefa muito grande e aguardada, concluíram os testes e a liberaram. Mas a nova funcionalidade de repente derrubou o local de combate sob carga pesada, e o meio e o meio da frente não puderam fazer nada por uma semana. .
, . , . , , .
vue, ( , ).
— , , , - , “ / / / ”.
, , , , .
, , , , , .
, . , - . , - .
. ( ), - :
- , - , - , . .
, . , , , .
. , , , . , , .
, vue, .
, - 5. -, . , .
, : , , , .
, - , - . , , , , , .
.
. , , , - , , .
, , , 1 , - , , , , , . , .
,
. .
, , 3-4 “ 3 ”, 40.
, , .
/ — ( ). , . , . , , -, 8 .
. :
- :
( ), :
— . :
:
, . , .
, . .
—
, , , , , “ ” , .
, , “” - .
, , , , , 2 . , , .
, , / , . , , .
, . , , / - , , - .
(, )
- . , , , , , , , .
, , . , , .
: , , , , . , .
, - , . , .
:
, , , .
, , , ( ), , , .
, ( , 2 , ).
, , . “ ”, :
, .
Parte 2
Este artigo abordou cerca de seis meses do meu trabalho em uma nova posição. Na segunda parte, gostaria de falar sobre como avançamos em direção aos objetivos com a ajuda de:
- autotestes que estamos começando a implementar. Estranho, mas por algum motivo não há exemplos dignos no Bitrix.
- livrar-se da herança no código
- acelerar e simplificar ainda mais o desenvolvimento
- o que vou aprender com os comentários
- muitas outras coisas secretas (de repente meus caras me leem)
Obrigado a todos pela leitura. Eu ficaria muito feliz em comentar, especialmente se você souber maneiras mais ótimas de resolver os problemas que encontramos.
Boa sorte e alegria para todos no trabalho e na vida!