Timlid em uma startup - de uma só vez, e Elon Musk e Frankenstein. De manhã, ele constrói naves espaciais e, à noite, grita para o projeto: “Viva! Você não deve morrer! - e ri doentio. E tudo isso na companhia de três juniores.
Alexander Polomodov lidera o desenvolvimento do gerenciamento de atrações em Tinkoff.ru; Ele foi CTO / Gerente de Desenvolvimento de pequenas empresas. Pedimos a Alexander que se lembrasse do passado e dissesse que armadilhas podem ser esperadas de um líder de equipe chegar a uma startup.
Sob o corte - respostas a perguntas importantes:
- como sobreviver em condições em que os processos de interação não são estabelecidos (ou não existem);
- como montar uma equipe legal quando a folha de pagamento é limitada;
- como entender que você precisa escapar do projeto.
1. Cheio de idéias, ninguém para fazer
Você vem em equipe em uma startup. Expectativa: comece imediatamente a trabalhar em novos recursos. Realidade: Caça desenvolvedores, porque uma equipe forte é necessária ontem e ninguém se preocupou em montá-la.
Duas opções são possíveis aqui - mais pesadas e mais leves. Uma opção dolorosa: há pouco dinheiro na PHOT. Uma das melhores soluções nessa situação é levar estagiários com uma cabeça limpa e brilhante e colocar todo o conhecimento e habilidades necessárias nessa cabeça: desenhe para cada indivíduo um plano de desenvolvimento individual, descreva passo a passo que conhecimento ele precisará adquirir, quais habilidades em que ordem desenvolver. Uma ótima maneira, mas, infelizmente, não é sua: este é um jogo longo e as startups que precisam mostrar rapidamente o resultado quase nunca fazem isso.
Uma frase característica: “Precisamos dos principais especialistas em Angular. Pagamos abaixo do mercado ".
A opção mais fácil: há dinheiro e você está pronto para oferecer boas condições de mercado.
Um caso típico. Uma prática comum nas empresas de TI nesse caso é expor o requisito básico para um candidato conhecer uma pilha de tecnologia específica. Alguns anos atrás, nas descrições de cargos, “estamos procurando um ninja jQuery” estava aparecendo constantemente. O problema é que muitos desses ninjas parecem ter saído da cama Procrustean - eles só podem escrever em jQuery (não está no novo projeto? Bem, me desculpe). E se uma pessoa não apenas conhece a pilha específica perfeitamente, mas também tem uma boa base, provavelmente uma corporação matará sua oferta salarial.
Solução. Quando há dinheiro para salários adequados, você precisa procurar pessoas, concentrando-se na presença de conhecimentos fundamentais e habilidades conquistadas com muito esforço, como o pensamento sistêmico. Mesmo que uma pessoa não esteja familiarizada com um idioma ou pilha de tecnologia específica, ela dominará todas as principais coisas do trimestre, se desejar.
Quando você não pode competir pelos melhores especialistas em termos de salário, vale a pena contratar pessoas de cabeça aberta que escolheram o campo sem sucesso. Um homem projetou microcircuitos e agora decidiu mudar a área para uma mais monetária? Nós aceitamos.
2. CEO da Narnia
A segunda dificuldade que um líder de equipe pode encontrar em uma startup são os óculos rosa de CEO. Os planos que já foram enviados a clientes ou investidores não correspondem à realidade. A equipe é pressionada de acordo com os prazos, eles precisam mostrar rapidamente o MVP, adicionar recursos e, ao mesmo tempo, definir prazos rígidos e irreais. Novas e novas camadas do código da muleta estão crescendo, a dívida técnica está se acumulando e o criador da startup tem certeza de que tudo está em ordem - os desenvolvedores são previsões pessimistas preguiçosas ou expressas.
Geralmente, essa situação ocorre com o gerente de vendas. Ele já havia vendido o castelo no ar - e como construir esse castelo agora, ele realmente não se importa.
A frase característica: "Eu vendi esses recursos, eles devem aparecer até o final da semana, mês, ano" (sublinhe conforme necessário).
Um caso típico. O CEO quer uma liberação em três dias, o desenvolvedor avalia a tarefa e diz ao líder da equipe o que ele pode fazer em cinco. Explica: “A API com a qual você precisa trabalhar já faz muito tempo para integrar. Se a API funcionar como prometido pelo parceiro, em três dias eu a receberei. Mas, na minha experiência, a API desse parceiro geralmente não cumpre suas promessas, portanto - cinco dias ". O CEO responde: “O parceiro promete que tudo ficará bem. Você tem três dias ", diz o CTO após a reunião:" Eu não entendo nada em desenvolvimento, mas quase reduzi pela metade a avaliação da tarefa ".
O desenvolvedor deste caso tentou e concluiu a tarefa em quatro dias. De qualquer forma, o fakap aconteceu, mas mesmo que cumprisse os prazos, não poderia continuar por muito tempo, este é o estágio terminal do mal-entendido como uma equipe normal e saudável deve funcionar.
Solução. Discutir o momento é normal, mas deve ser uma discussão fundamentada. O estilo de Tony Robbins responde: "Uma semana é muito longa!" e "Você precisa se esforçar mais!" - indicador de óculos cor de rosa. Removê-los é um teste sério das habilidades de comunicação do líder da equipe.
Não se trata de derrubar o preço negociando, como em um bazar em que há um custo e uma margem mais baixos que são distribuídos em um jogo de soma zero entre o vendedor e o comprador. Ele discute uma solução de engenharia que você deseja avaliar, levando em consideração fatores adicionais. O desenvolvedor não negocia cinco dias de trabalho, mas faz uma avaliação com base em seu conhecimento. Se a pressão for boa, reduzirá o tempo, mas provavelmente reduzirá todos os riscos. E quando algo der errado, os planos definitivamente darão certo. É isso que é importante transmitir ao CEO, e se você não quiser entender, fuja, seus tolos.
3. Dívida técnica com juros de microcrédito
A história da criação do OS / 360, descrita no livro “Mythical Man-Month” de Frederick Brooks, é muito reveladora. Era para ser o sistema operacional mais legal da época. A IBM atraiu milhares de pessoas ao projeto e ainda faltava em todos os aspectos: tempo, funcionalidade e recursos de suporte.
Do livro de Brooks, fica claro que os desenvolvedores pisaram em todos os possíveis ancinhos, e isso apesar do fato de que eles usaram o Waterfall e entenderam claramente os estágios de desenvolvimento. E hoje, com a ampla disseminação do Agile, a equipe e o plano de arquitetura a longo prazo geralmente não o possuem - apenas um backlog que consiste em tarefas de negócios e um sprint por uma a duas semanas.
Frase característica: “Repintar este botão em azul? Vai demorar uma semana
Condicionalmente, se a construção de três apartamentos estiver planejada no primeiro sprint, no segundo sprint uma cabana ou uma cabana será construída nas proximidades. Em seguida, vem uma nova tarefa - cobri-los com um telhado comum e, se for de algum modo instalado, acontece que haverá outro andar em cima e assim por diante.
Onde uma casa real teria entrado em colapso sob o peso dos erros do designer, uma dívida técnica é formada no desenvolvimento. E se, a princípio, o trabalho no projeto for conforme o planejado, e ninguém vê as muletas espalhadas, então, em algum momento, verifica-se que um recurso simples, que inicialmente custa o dia do desenvolvedor, agora leva o dobro. E como você tem que percorrer as muletas repetidamente e adicionar novas a elas, em um quarto o recurso custará cinco vezes mais.
Solução. Um líder normal toma decisões com base em fatos e números. Venha com os cálculos: mostre quanto a dívida técnica aberta custará em um mês, em um quarto, em um ano. Assim, você terá a oportunidade de ajustar os planos, incluindo nos sprints não apenas novos recursos, mas também um "pagamento de dívidas" em fases.
Obviamente, essa não é uma lista exaustiva de problemas que os teamlids enfrentam nas startups, mas esses três são os mais agudos e difíceis de resolver.
Alexander Polomodov - curador do
Teamlead Weekend intensivo no distrito binário; o próximo curso será realizado de 15 a 16 de dezembro.