Meu nome é Vladimir. Sou responsável pelo desenvolvimento de dispositivos móveis na Vivid Money.
Vivid Money é uma startup de fintech para o mercado europeu com uma ampla gama de funcionalidades - pagamentos e transferências, multimoedas, análises financeiras, compartilhamento de contas, investimentos e muito mais. Os concorrentes mais próximos são Revolut e N26.
Conseguimos fazer e lançar com sucesso um aplicativo fintech móvel em um ano. Durante este ano, coletei ideias que estavam se formando na minha cabeça por cerca de 4 anos, enquanto era líder em outros projetos. Neste artigo, essas ideias são coletadas na forma de dicas para gerentes / líderes de engenharia de software que iniciam projetos de longo prazo e em grande escala do zero.
Introdução
Há pouco mais de um ano, cheguei ao projeto como líder de uma equipe Android. Eu me deparei com uma tarefa ambiciosa e interessante - escolher tecnologias, montar uma equipe, configurar processos e, o mais importante, fazer tudo bem. Bom é um conceito solto, mas para mim é um produto de qualidade do ponto de vista técnico e do produto.
Começar um projeto do zero é uma tarefa tão interessante e excitante quanto incompreensível e difícil. No começo você não sabe em que se agarrar, então há tantas coisas para fazer que todo o processo de trabalho é como apagar incêndios.
Para evitar que isso aconteça, é necessário antes de tudo definir claramente as prioridades das atividades.
Na minha opinião, as principais atividades de um lead podem ser organizadas na seguinte ordem:
- Construindo o processo de contratação;
- Selecionando uma pilha de tecnologia;
- Configurando a interação da equipe;
- Construindo um processo de desenvolvimento e teste.
Nesta parte do artigo, vou me concentrar apenas no primeiro ponto.
Disclaimer:
Este artigo contém minhas idéias e conclusões baseadas na minha experiência de trabalho em projetos grandes e de longo prazo. Algumas das dicas podem parecer banais, mas, como a prática tem mostrado, nem todas são aplicadas mesmo em grandes empresas e projetos.
Contratação de prédio
Para mim, esse ponto está em primeiro lugar, já que o trabalho futuro da equipe depende da “qualidade” das pessoas.
Tínhamos um prazo muito ambicioso para lançar o banco - 1 ano. Durante este tempo, foi necessário fazer qualitativamente uma grande quantidade de funcionalidades. Simplesmente não havia tempo para funcionários dependentes e mal treinados. Portanto, segue o seguinte conselho:
Conselho número 1. Lembre-se da importância da contratação
Além do fato de um desenvolvedor fraco afetar diretamente a qualidade do código e a quantidade de bugs do produto, é impossível delegar a ele, pois não haverá total confiança e será necessário um monitoramento constante. Portanto, surgirão dificuldades em um projeto em rápido crescimento.
Conselho número 2. Verifique não apenas as habilidades difíceis em uma entrevista, mas também as habilidades sociais
Freqüentemente, uma entrevista de desenvolvedor na Rússia se resume a questões de linguagem / estrutura. Na verdade, as habilidades sociais desempenham um papel igualmente importante e são mais difíceis de desenvolver. Além disso, uma pessoa com uma mentalidade semelhante tem mais chances de se encaixar na equipe.
Nós identificamos as seguintes habilidades pessoais:
- Pensamento sistemático;
- Asseio e perfeccionismo saudável;
- Baseando-se na experiência, não em conselhos; questionando fatos não verificados.
E, claro, o não-conflito básico e a habilidade de se comunicar com as pessoas.
Por exemplo, fazemos uma pergunta a um candidato: "Por que você está deixando seu antigo emprego e quais são seus critérios para escolher um novo emprego?" A resposta em si não é tão importante quanto a abordagem sistemática é importante - esperamos que o candidato esteja ciente de que ele não está satisfeito, que ele foi capaz de chegar a isso de uma forma lógica e resolver tudo em sua cabeça.
Exemplos dessas perguntas que nos ajudam a entender a mentalidade e os princípios de um candidato podem ser: "Como é sua equipe ideal?" ou "Como é o processo de desenvolvimento ideal?"
Conselho número 3. Otimize sua entrevista
A entrevista deve ser vista como um mecanismo que pode ser melhorado e otimizado. Ou como um programa que pode ser refatorado.
Vou dar exemplos das otimizações que fizemos.
Exemplo 1
Demora aproximadamente 1,5 horas para dois desenvolvedores entrevistar cada candidato. Para otimizar esse tempo e não desperdiçá-lo com candidatos obviamente fracos, introduzimos a triagem. A triagem consiste em algumas perguntas simples e fechadas que prepararam respostas. Os próprios recrutadores fazem essas perguntas ao candidato, o que leva cerca de 10 a 15 minutos.
Poucos números:
De 100 candidatos após a triagem, cerca de um terço, ou seja, cerca de 30. Um recrutador gasta cerca de 15 minutos em cada triagem, ou seja, cerca de 8 horas de tempo líquido para 30 candidatos eliminados. Em uma entrevista clássica para os mesmos 30 candidatos, teríamos gasto cerca de 60 horas-homem no cenário mais otimista.
Exemplo 2
O objetivo da entrevista é selecionar o candidato mais relevante. Analisamos e identificamos as hard-skills e habilidades críticas para o projeto, levando em consideração a pilha de tecnologias selecionadas, o que nos permitiu remover algumas das questões irrelevantes e reduzir o tempo de entrevista.
Por exemplo, removemos perguntas relacionadas a partes do Android SDK que não são usadas em nosso projeto - ContentProvider, JobScheduler, etc. As respostas a essas perguntas não nos darão uma compreensão de se serão incluídas no desenvolvimento de recursos regulares do projeto em que essas partes SDKs raramente são usados.
Exemplo 3
Inicialmente, a entrevista técnica decorreu em duas fases distintas - questões teóricas e tarefas práticas. Isso aumentou muito o tempo que leva para um candidato completar todas as etapas da entrevista, e muitos candidatos se perderam, já que o mercado de TI é muito competitivo - bons desenvolvedores recebem ofertas rapidamente.
Para otimizar o funil, reduzimos a entrevista no estágio 1 - removendo perguntas não informativas e resolvendo problemas algorítmicos. Escrevi sobre questões não informativas no parágrafo anterior. Mas substituímos as tarefas algorítmicas por tarefas práticas para o framework. Eles também testam suas habilidades de codificação e conhecimento do SDK.
Como resultado, houve apenas uma entrevista técnica de 1,5 hora, mas o conteúdo ficou o mais polido possível.
Conselho número 4. "A compreensão é mais importante do que o conhecimento"
O critério mais importante para a escolha de um desenvolvedor foi “compreensão”. Para que uma pessoa não saiba apenas dar definições e conhecimentos acadêmicos, mas demonstre uma compreensão da estrutura de um determinado framework. Um desenvolvedor sem essa compreensão, diante de problemas, não será capaz de encontrar uma solução por si mesmo ou não resolverá o problema da maneira ideal. Portanto, fizemos todas as perguntas da entrevista abertas para que o candidato não dê os termos aprendidos, mas raciocine sobre um assunto ou outro. E nós acompanhamos seu conhecimento do assunto e o curso de sua lógica.
Por exemplo, fazemos uma pergunta aberta: “Como fazer um detector ANR (Application Not Responding) no Android?”. Esta questão testa o conhecimento de como os threads funcionam no Android, mas evita a questão direta sobre o Looper e o Handler. Também permite alternar concisamente para um tópico com multithreading.
Conselho número 5. Distribuir a função de entrevistas
Com o rápido crescimento da equipe, as entrevistas se tornam tantas que demoram o dia todo, e não sobra tempo para outras atividades. Portanto, é útil delegar parcialmente a função de entrevista à equipe.
Isso não só tira o fardo do chumbo, mas também inclui o desenvolvedor na escolha de seu colega em potencial, o que o motiva adicionalmente.
Além disso, o candidato conhece a equipe e cria uma experiência mais holística para si mesmo.
Conselho número 6. Equilibre o time
Ao contratar, você deve sempre se lembrar do equilíbrio das pessoas por competências na equipe. Muitos desenvolvedores seniores podem levá-los a encontrar novas soluções, mas os desenvolvedores não criarão recursos. Mas no início do projeto, quando a base técnica está lançada para os próximos anos, é necessário. Além disso, para escrever o código usual de recursos, o signatário será excessivamente caro. Muitos juniores, por sua vez, degradarão a base de código e, como resultado, afundarão o projeto no longo prazo. No entanto, os juniores inteligentes crescem rapidamente e se tornam muito mais leais à empresa e à equipe do que os médios do mercado. Na minha opinião, esse equilíbrio é diferente para cada projeto e situação específica, então não vou dar percentuais específicos.
Muitas vezes, as equipes são diluídas com empreiteiros para acelerar o desenvolvimento. O equilíbrio também é muito importante aqui, uma vez que um grande número de empreiteiros também pode degradar o código do projeto. Os contratados raramente têm a mesma motivação e interesse em um projeto que os funcionários internos.
Conselho número 7. Não tenha medo de atirar
Finalmente, não há necessidade de ter medo de demitir pessoas da equipe. Uma pessoa que não se encaixa na equipe em termos de princípios e espírito ou habilidades técnicas causará muito mais danos a longo prazo do que o benefício da codificação de curto prazo.
Parece fácil demitir, mas como fazê-lo da forma mais indolor possível para o funcionário e a equipe? O princípio funciona aqui: “Não importa o que você faça, mas o quão importante é.” Se você fizer tudo com antecedência - discutir as expectativas da função, dar feedback sobre o trabalho dentro do prazo, sem esperar o fim do período probatório, e argumentar seus comentários - isso não será uma surpresa para o funcionário.
Também é importante deixar publicamente a equipe entender por queo funcionário foi demitido. Caso contrário, você pode inspirar medo na equipe e arruinar a atmosfera da equipe.
Conselho número 8. Colete feedback de funcionários recém-chegados
O processo de recrutamento consiste em 2 fases - entrevista e integração de novato.
A integração deve ser útil não apenas para o iniciante, mas também para o projeto.
Após a imersão no projeto, novas pessoas podem ver as áreas problemáticas com uma aparência aberta e dar novas ideias. Portanto, desenvolvemos uma regra - ouvir e analisar conscientemente suas opiniões e recomendações para melhorar as abordagens e a base de código. Algumas dessas recomendações foram implementadas com sucesso no projeto.
Por exemplo, após a chegada de um dos membros da equipe do Android, revisamos completamente a abordagem de armazenamento de dados no cache in-memory.
Resultado
Concluindo, gostaria de dizer que nossa equipe móvel cresceu para 26 pessoas em quase um ano e meio. Todos os desenvolvedores fazem um bom trabalho e ninguém saiu da equipe por conta própria. Lançamos o produto com sucesso e passamos no teste de trabalho remoto sem perda de qualidade e velocidade de desenvolvimento.
Espero que as dicas coletadas neste artigo sejam úteis para você também.
Nas próximas partes, falarei sobre nossas abordagens para escolher uma pilha de tecnologia e configurar a interação da equipe.