🕎 🤼 🏗️ De desenvolvedor a gerentes e vice-versa 🧔🏿 🐢 😆

No inverno de 2012, um colega sugeriu que eu, um programador de C ++ com cinco anos de experiência, escrevesse o primeiro aplicativo para Android. Um ano depois, comecei a liderar uma pequena equipe de desenvolvedores de dispositivos móveis e, desde então, o tamanho das minhas equipes aumentou constantemente. Mas, no ano passado, depois de dois anos gerenciando o departamento de desenvolvimento móvel, joguei poeira novamente no meu IDE favorito.

Vamos dizer como foi do outro lado, por que eu voltei para os desenvolvedores com mais de 30 anos (spoiler) e não me arrependo.

Caminho para desenvolvedores Android

O Android, que na época era um truque na minha cidade provinciana, parecia-me outro "brinquedo" divertido, ao jogar o qual você podia largá-lo com segurança e voltar ao Qt habitual. E assim tudo começou: um amigo lançou a idéia de um aplicativo simples para contabilizar receitas e despesas, começamos a vê-lo em nosso tempo livre e, seis meses depois, o MVP estava pronto para publicação.

Nosso Money Keeper tinha um design bastante primitivo, mas um UX bem pensado: a receita ou a despesa foi registrada em um clique - toque no ícone da categoria para abrir imediatamente uma janela para inserir o valor.

Lembro-me muito bem de como vi as estatísticas de download: a primeira pessoa a baixar meu aplicativo foi alguém do Egito. E este não excluiu o aplicativo na mesma semana, mas continuou a usá-lo!

Pouco a pouco, várias dezenas de downloads por dia, o público cresceu, a classificação aumentou, as primeiras críticas positivas apareceram. Dizer que inspirou foi subestimar. Respondi às avaliações do mercado, planejei um desenvolvimento adicional com base nos desejos dos usuários, simplesmente porque meu aplicativo é necessário para os usuários, eles agradecem e colocam cinco. E toda a nossa publicidade estava em uma única postagem no w3bsit3-dns.com.

Também foi impressionante o quanto o desenvolvimento móvel difere do desenvolvimento de sistemas embarcados e aplicativos de desktop nos quais trabalhei antes. O caminho do aplicativo para o usuário e seus comentários são muito curtos. O público é enorme, e tudo o que você faz deve fazer pelo menos bem, caso contrário, o aplicativo não será necessário por ninguém e todo o trabalho poderá ser jogado fora.

Como me tornei líder de equipe, "porque_para_alguém_alguma_devem_"

O aplicativo cresceu e se tornou mais complicado, uma versão paga com funcionalidade adicional apareceu. Meu par de mãos para o desenvolvimento de dois aplicativos deixou de ser suficiente, especialmente levando em conta o fato de que eu os escrevi no meu tempo livre a partir do trabalho principal. Não havia orçamento especial para a contratação de funcionários, porque a monetização não gerava tantas receitas.

Recusamos a ideia de "congelar" um aplicativo gratuito para um pago, porque não queríamos decepcionar a comunidade de usuários agradecida, da qual estávamos atraindo energia e idéias para o desenvolvimento todo esse tempo. Por isso, decidimos ganhar um pequeno salário com dois caras que estavam longe do desenvolvimento e queimávamos para entrar nele. Foi decidido levá-los ao longo do meu caminho, mas com uma diferença significativa: tive que ensiná-los a se mover e navegar pelo mundo do robô verde e mostrar a eles todos os buracos e buracos que conhecia nessa estrada.

imagem

Não tinha medo de assumir tarefas difíceis)

queriaoutras pessoas compartilharam meu entusiasmo pelo desenvolvimento, e mesmo dois pares de mãos claramente não foram supérfluos para nós. Fui à casa deles, expliquei, ensinei, aconselhei, ajudei. Eu defini tarefas e verifiquei sua implementação. Então, silenciosamente, me tornei um pequeno, mas gerente.

O aplicativo, no entanto, teve que ser fechado ... Fui a uma startup, depois a outra, depois desenvolvi o produto em um grande negócio. Em todos os lugares onde não havia pessoas suficientes para o papel principal, havia um cenário aproximadamente semelhante: “Você descobriu a área de assunto, fez amizade com a equipe, não é contra o trabalho de liderança e você tem essa experiência? Vamos tentar definir tarefas para outras pessoas. Pelo menos neste sprint ... ”

Mas havia outro aspecto importante: eu estava pensando no futuro - e parecia nebuloso.Há muito tempo, deparei com um artigo sobre a idade média dos desenvolvedores. Ele disse que o "pico da carreira" do desenvolvedor cai em 27 anos. Comecei a notar artigos semelhantes - e involuntariamente me perguntei: o que farei como desenvolvedor, por exemplo, aos 32 anos, quando “uma merda jovem vier nos apagar da face da Terra”? Não é melhor seguir lentamente o caminho dos gerentes e resolver o "problema dos 30 anos" por si mesmo?

Meus princípios como Timlida

Quando abandonei o C ++ e parti para o Android, eu já havia trabalhado com diferentes gerentes e sabia exatamente que tipo de líder eu queria ser. E mais tarde, em equipes completamente diferentes: equipes de produtos (composta por analistas, designers, desenvolvedores, testadores) e equipes de desenvolvimento - tentei não me afastar dos meus princípios.

Precisa trabalhar com aqueles que estão

Um estudante com olhos ardentes, que está sendo enviado no caminho certo, depois de algum tempo, pode começar a trazer mais benefícios ao projeto do que uma “estrela do rock”.

Em um dos projetos, decidi que era hora de deixar o familiar pacote MVP + Dagger + RxJava e experimentar na produção as ferramentas que o Google recomenda usar para criar aplicativos móveis modernos. Planejamos implementar a arquitetura recomendada usando apenas Jetpack e Kotlin com Coroutines.

Todos os desenvolvedores e chefes experientes torceram os dedos no templo e disseram que, com uma equipe de dois jones que nunca usaram nada da pilha que selecionei, concluiríamos o projeto e a responsabilidade ficaria comigo. Mas esses dois membros ficaram satisfeitos por trabalhar com o que os desenvolvedores do Android escreveram no blog ontem.

imagem

Sim, é claro, pegamos um monte de doenças infantis nas versões alfa das bibliotecas no início ...

Mas os caras trabalharam duro, entraram na fonte e estudaram problemas no Github, analisaram perfis à noite e, no final, obtivemos:

código limpo, estável e fácil de manter,
produto de sucesso na produção,
e um monte de experiência inestimável.

Em outro projeto, um desenvolvedor muito legal chegou à equipe, que não fez amizade imediata com toda a equipe, mas cortou as tarefas perfeitamente. Os caras entraram em contato com ele através de dores, lágrimas e chefes, e alguém até disse que seria melhor tomar um junho em vez dele, mas no final reduzi a comunicação ao vivo entre eles ao mínimo necessário, e tudo ficou calmo.

Você também precisa trabalhar com "estrelas do rock", por mais difícil que seja, às vezes.

Naturalmente, existem pessoas que conscientemente não fazem seu trabalho: alguém pensa que chegou ao "chefe que fará tudo por mim", alguém simplesmente não pode ou não quer trabalhar. Se as conversas e o tempo não ajudarem, você não deve ter medo de se separar delas.

Não trabalho com subordinados, mas com pessoas

Cada um tem suas próprias circunstâncias, necessidades, temperamento e humor. Certa vez, antes de passar por um sprint difícil, uma garota testadora, da qual todos esperavam o resultado do teste final do produto, começou a trabalhar com raiva por causa de um escândalo com o marido, que não encontrou meias limpas. Prazo, este não é o primeiro dia de testes intensos, mas aqui está. Ela não tinha vontade de trabalhar. Nesta situação, foi possível esmagar, exigir e ameaçar. Mas tentei entendê-lo e redistribuir o recurso de outros testadores de forma a cobrir a lacuna. Depois de meio dia, esfriou e investimos com sucesso em tempo.

imagem

Quem antes das férias não ficava em outros sites durante o horário de trabalho, deixa o primeiro jogar um monitor em mim)

Ou outra história: um colega parou de fazer algo alguns dias antes das férias, simplesmente porque estava ocupado com os últimos encontros para uma viagem de bicicleta à Europa, que ele preparava há quase um ano. Durante todo esse ano ele meticulosamente realizou tarefas de trabalho, e aqui - como um substituto. E eu dei a ele esses dois dias. Depois de duas semanas de férias, ele voltou descansado e começou a trabalhar no mesmo ritmo, mas eu consegui não estragar o relacionamento na equipe.

Em uma situação difícil, ninguém avançará a menos que eu lidere

Em uma equipe do DevOps que era nova para mim, por alguns meses "dinamizei" com a implantação do CI, e os desenvolvedores sabotaram abertamente sua implementação, não concordando com os argumentos sobre sua utilidade. Não é que eles tenham sido preguiçosos e retrógrados, apenas me pareceu que eles não funcionavam no ambiente em que a CI foi preparada corretamente.

Abraçando o Google, sentei-me à noite e escolhi as configurações. Gradualmente, o DevOps e os desenvolvedores se envolveram no processo. Como resultado, conseguimos configurar o IC e as ligações necessárias para criar e distribuir aplicativos, que rapidamente e silenciosamente se tornaram o padrão para diferentes equipes da empresa.

Fecho os buracos na organização de processos com intervenção pessoal e microgestão? Talvez. Mas, para mim, em uma situação tão impassível, existem dois extremos: `` aperte os parafusos '', afastando-se cada vez mais da equipe e tornando-se o `` chefe '', ou tente ajudar uma pessoa quando for difícil para ela, mesmo tendo concluído seu trabalho, tornando-se 'dele'. Mas eles não deixam seus próprios problemas.

Você precisa se desenvolver e desenvolver todos na equipe

Local de trabalho típico de um líder

: quanto mais eu me sentava em um projeto, mais sentia que o desenvolvimento moderno passava por mim. Uma pilha de tecnologias, idiomas e estruturas foi selecionada há vários anos e não mudou significativamente desde então. Isso ocorreu devido às datas de gravação eternas, ao fraco interesse dos negócios, mas acima de tudo - ao medo dos desenvolvedores de algo novo, quando há uma idade tão familiar.

Chegou ao ponto de os desenvolvedores recém-aceitos serem proibidos de escrever no Kotlin, porque os principais programadores não o conheciam e não encontraram tempo (não queriam encontrar?) Para ensiná-lo. Esses problemas foram resolvidos de maneira bem simples: realizei palestras, reuniões e cursos sobre assuntos interessantes para toda a equipe. É mais fácil e mais interessante para os desenvolvedores classificar uma tecnologia em um projeto de estimação por uma semana e contar o resto sobre isso do que arrastá-la cegamente para a produção.

E é mais fácil para uma empresa justificar um aumento salarial para uma pessoa que está estudando e introduzindo algo novo e útil para toda a empresa.

Não se pode ir longe dos problemas de desenvolvimento

Assim que você não entende mais os problemas dos desenvolvedores com dívida técnica, recursos da plataforma e a interação entre diferentes partes do sistema, a porcentagem de sprints diminui.

Houve casos em que os gerentes ficaram sinceramente surpresos com a impossibilidade de publicar um aplicativo iOS na véspera de Ano Novo, porque os revisores da Apple tinham saído em feriados. Às vezes, os designers não entendem os problemas dos desenvolvedores do Android com a digitação em telas diferentes. Os backenders que não trabalharam com clientes móveis antes devem explicar que não precisam fornecer um erro de página HTML em vez do JSON.

E se você "examinar" esses momentos ao desenvolver o sistema ou sua parte, as consequências para os prazos podem ser muito deploráveis.

imagem

Oh, quanto de bom pode ser alcançado simplesmente adotando soluções técnicas. E mesmo se eles derem as tarefas para distribuir - você pode rolar montanhas!

Eu consegui liderar?

Não presumo dizer que esses são os princípios corretos. Nem sei se eles correspondem ao que escrevem nos livros sobre gestão de pessoas, porque ainda não li nenhum deles. Eu julgo por vários fatos:

As relações na equipe melhoraram. Se antes de mim houve escândalos com o esclarecimento das relações com as autoridades, então comigo - um máximo de pequenas escaramuças.
Em geral, nos encaixamos em sprints. Até o impossível. E se eles não se encaixavam, nem tanto que o cliente estava com raiva. Naturalmente, esse é o mérito da equipe. Mas provavelmente um pouco meu. Eu sempre tentei levar em consideração todos os riscos e realizar o planejamento das tarefas, levando-os em consideração.
Nós constantemente refatoramos e melhoramos os processos de produto e desenvolvimento, a dívida técnica diminuiu.
Os desenvolvedores cresceram em posição e salário.
Minha orientação direta também foi bonita.

Ok, e as desvantagens da liderança?

Para mim eles são:

Quanto mais você é gerente, menos desenvolvedor. Não importa como você tente acompanhar os meandros da parte técnica do projeto, eles escapam a cada dia mais e mais. E quanto maior a equipe e mais ativo o desenvolvimento, mais rápido. Gradualmente, o volume de novas informações recebidas sobre Android e iOS foi reduzido para a leitura de notas de versão de novas versões de sistemas operacionais e alguns artigos sobre Habré por mês.
. — , . , “” . .
. . , . - - , .
. , . , 2-3 . - — 70-80% !

!

Não importa como você goste em algum lugar, você terá que sair um dia. E, em algum momento, comecei a procurar um novo emprego. Previsivelmente, eu queria entrar em um negócio ainda maior para continuar o desenvolvimento.

A próxima entrevista do Skype estava em andamento: 10 entrevistadores, 2 horas , requisitos - conhecimento da parte técnica do nível Desenvolvedor Sênior e capacidade de gerenciar pessoas. Depois de duas horas, percebi que, ao gerenciar pessoas, não sei quase nada. Pelo menos eu não conheço a teoria e sou baseada apenas em meus princípios e experiência.

Parecia algo assim:

— ?

— .

— ?

— , . , .

— ?

— …

— , scrum kanban?

— .

— ?

— …

Bem e assim por diante. Eu falhei com a teoria. De alguma forma, consegui implementar, mas para explicar os princípios básicos de por que uma maneira ou outra tinha que ser feita - não. Após a entrevista, percebi que havia atingido meu limite na liga de gerenciamento de amadores e que sentar em duas cadeiras não funcionaria. Para desenvolver, foi necessário decidir para onde eu quero ir.

imagem

Esta é minha atual equipe ausente para trabalhadores remotos. Pelo menos mais uma pessoa foi da mesma maneira: foi para os líderes de equipe e conscientemente retornou aos desenvolvedores.

A primeira maneira é para os gerentes. Ainda assim, leia os livros muito corretos. Comece a assistir a vídeos e participe de conferências de gerenciamento, planejamento e motivação. A liga gerencial profissional tem suas próprias regras e especificidades.

Segunda via- mergulhe no desenvolvimento, se possível, alcançando os anos de gestão.

Bem, a terceira opção de compromisso é "puxar" a teoria e tentar continuar "no meio", pendurando "em amadores" por mais alguns anos.

E então me lembrei de como tudo começou. Com a sensação de que você está mudando o mundo, fazendo algo útil para os outros. Mesmo que você tenha pintado o botão de verde, ele se tornou um pouco melhor para milhares de usuários. Mesmo se eu corrigisse um erro de digitação. E se você já reduziu um recurso há muito esperado pelos usuários e agradeceu nos comentários - isso é apenas uma explosão de emoções e um bom humor por alguns dias!

Senti um sentimento tão forte ao trabalhar como gerente? Eu acho que não. Mesmo quando clientes, equipe e líderes o elogiam. E quando os usuários elogiam o recurso esperado, é claro que isso se deve principalmente àquele que o preparou, serrou, testou e exibiu. E um pouco - o meu como gerente.

Por isso, achei um lugar agradável para trabalhar, escrevo código e até agora não me arrependo.
Existe vida nos desenvolvedores aos 32 anos? Há sim!

PS

O que me deu como desenvolvedor a experiência de liderança?

Agora eu entendo melhor negócios e PMA, mesmo sem palavras. Muitas vezes eu sei que pergunta eles querem me fazer.
Planejo o tempo e as tarefas com mais competência, levando em consideração os riscos.
Contraste. Depois de ver como estava do outro lado, percebi o que eu gosto sobre este.

De desenvolvedor a gerentes e vice-versa