A vida inicial

Não sei quase nada sobre a vida. Foi ainda mais verdadeiro quando entrei na minha primeira empresa depois da universidade. Era uma pequena startup na indústria adtech, cerca de 25 pessoas, todas jovens e legais. A empresa havia acabado de levantar sua primeira rodada e era hora de acelerar. Fui contratado como Cientista de Dados para extrair insights da enorme quantidade de dados que a empresa acumulou. Achei que meu trabalho era treinar modelos de aprendizado de máquina, escrever código em Python e jogar pebolim. Eu estava tão errado.

A vida era divertida

Eu era o segundo integrante da equipe Data, logo depois do próprio Head, então tudo era para ser construído do zero. Foi emocionante e desafiador. Passei meu tempo lendo artigos de pesquisa sobre aprendizado de máquina, percebendo o pouco que sabia e escrevendo códigos como um louco. Rapidamente percebi que a escola não conseguia me ensinar muitas das habilidades fundamentais necessárias para o meu trabalho diário. Então eu aprendi. Diariamente. Aprendi a escrever código de nível de produção em Python e Scala, criar trabalhos Spark e orquestrá-los com Airflow DAGs. Aprendi a fazer rebase e lidar com conflitos no git. Aprendi a construir pipelines de CI/CD. Aprendi a usar AWS. Eu estava sendo despedaçado em revisões de código por membros seniores. Essas centenas de comentários por pull request foram meu curso intensivo sobre engenharia de dados.

Eu amei. Eu tinha minha pequena bolha onde podia aprender e criar ao mesmo tempo, no meu próprio ritmo, porque estava sob o guarda-chuva de Pesquisa e Desenvolvimento, porque “as coisas levam tempo na ciência de dados” e porque eu era júnior. Então, alguns meses se passaram até que comecei a notar algo diferente.

eu vi a pressão

Na gestão, responsável por dezenas de pessoas.
Em engenheiros de back-end, responsáveis ​​por entregar milhões de anúncios 24 horas por dia, 7 dias por semana, em menos de 50 milissegundos.
No pessoal de infra, responsável por manter uma infraestrutura multimilionária o tempo todo.
Executivos de contas, responsáveis ​​por vender a solução aos clientes e trazer dinheiro.
Nos fundadores, responsáveis ​​pela visão e sobrevivência da empresa.

Eu os vi acordando no meio da noite, lidando com falhas e escalações. Canecas de café quebradas em pedaços, pessoas gritando umas com as outras e pessoas sendo assadas por não acertarem os alvos. As mudanças de humor eram épicas.

Foi quando eu entendi.

é sobre sobrevivência

Quando você está trabalhando para uma startup, tudo se resume à sobrevivência. E para sobreviver, você precisa de duas coisas: valor e execução. Todo o resto é ruído.

Valor

O valor é a coisa mais importante a entender, especialmente para o pessoal da tecnologia, pois tendemos a nos concentrar muito no lado técnico.

As empresas existem por um único motivo: resolver problemas que importam. É isso.

Qual linguagem de programação usar? Qual estrutura usar? Qual editor de texto usar? Que arquitetura? Devemos usar aprendizado de máquina? Isso é irrelevante. Na melhor das hipóteses, é um detalhe de implementação.

O valor vem de problemas, pontos problemáticos e usuários. Então, primeiro, precisamos entendê-los. Então, precisamos criar produtos que facilitem a vida deles. Finalmente, precisamos fazer isso rápido. Mas há um porém.

Execução

É tudo uma questão de ritmo. Devemos encontrar o equilíbrio entre enviar algo perfeito tarde demais e enviar algo inutilizável muito cedo.

Podemos estar desenvolvendo o maior modelo de aprendizado de máquina de todos os tempos, mas, desde que não atinja a produção, é inútil. Historicamente, é assim que os projetos de TI são executados. Projetos que duram meses ou anos com uma extensa equipe de desenvolvedores antes de entrar em produção. Exceto em casos raros, é 1. desnecessário e 2. ineficiente. Se enviarmos algo tarde demais, corremos o risco de ficar sem dinheiro sem nada para mostrar.

E a concorrência? Queremos que os usuários vão para outro concorrente?

Se enviarmos algo inutilizável muito cedo, a experiência do usuário será péssima e as pessoas se afastarão do produto, mesmo que ele melhore com o tempo. A reputação está em jogo aqui. Portanto, devemos ter cuidado com o que enviamos e como nos comunicamos.

Então, o que fazemos? Nós iteramos. Nós nos concentramos nas peças essenciais e as enviamos o mais rápido possível. Coletamos feedback, melhoramos e adicionamos recursos. Enxágue e repita até que o ROI não seja mais atraente. É por isso que os produtos SaaS têm visualizações públicas e privadas. É por isso que teremos que enviar produtos incompletos com códigos desagradáveis ​​de vez em quando. Nosso pipeline de ingestão pode não ser o mais rápido ou o mais econômico, nosso modelo de ML pode não ser o mais preciso e nosso back-end pode não ser o mais escalável, mas é assim que nos movemos rápido e somos ágeis. Isso é verdade Ágil.

Parece fácil, mas não é. Uma boa iteração requer uma mentalidade diferente. Devemos fazer compensações e aceitar enviar código abaixo do ideal. Devemos abraçar o caos temporário para o sucesso a longo prazo. E é difícil.

Conclusão

Em vez de focar na tecnologia em si, devemos olhar para o quadro geral e entender quais são os problemas para nossos usuários. O que estamos tentando alcançar no nível de negócios? Qual o valor fornecido?

Ideias sem execução adequada são perda de tempo. É por isso que precisamos iterar rapidamente, obter feedback do usuário, melhorar e depois dinamizar, se necessário.

Finalmente, e esta é provavelmente a parte mais desafiadora, devemos chegar a um acordo com as compensações e o envio de códigos abaixo do ideal.

Curiosamente, tudo o que foi dito até agora se aplica a todas as empresas, não apenas às startups. Eles simplesmente têm mais dinheiro.

Até que eles não o façam.