Dominar muitas tecnologias e saber como construir serviços complexos e altamente carregados acaba não sendo suficiente quando você é um desenvolvedor em uma startup ou projeto em crescimento. Na minha carreira, estive envolvido em muitos projetos de crescimento e criei duas startups do zero. Neste artigo, compartilharei minhas experiências sobre o que focar durante o desenvolvimento e por que o perfeccionismo estraga até as melhores ideias. As ferramentas são um meio, não um fim Para todo desenvolvedor, lançar um projeto por si só é um desafio sólido. É muito natural sentir que você precisa fazer tudo com perfeição. Demorei um pouco para perceber que o desejo de perfeccionismo é na maioria das vezes o reflexo do medo de que os colegas me julguem por uma ‘estampa’ extra ou por não usar um padrão ou ferramenta; e aí vai: o servidor de produção vai entrar em colapso, os clientes vão reclamar, eu vou ser demitido e o mundo vai acabar. Qualquer ferramenta, padrão ou linguagem de programação é , não um objetivo. Pergunte com mais frequência: Por que preciso disso agora? O que isso fornecerá? Quais métricas serão melhoradas? Por exemplo: por que configurar um linter agora? Por que personalizar CI/CD agora? Se você estiver fazendo uma implantação 10 vezes por dia, provavelmente precisará dela. Se você implantar uma versão uma vez por semana ou mês, provavelmente não o fará. Se a customização do CI/CD levará muito tempo, mas não acelerará o desenvolvimento nem agregará valor ao projeto e aos clientes, ela deveria ser implementada agora? apenas uma ferramenta Em um projeto favorito, faz sentido tentar algo novo: melhorar infinitamente a estrutura do repositório e do código, experimentar padrões, etc. . O principal objetivo de um projeto de produção é entregar valor aos clientes. Os clientes nunca saberão que usamos aspas duplas em vez de aspas simples e singletons, e não há código rígido. Neste caso, as ferramentas que implementamos são o objetivo A refatoração é necessária apenas quando aumentará a velocidade e o desempenho do desenvolvimento, reduzirá bugs ou desbloqueará o backlog. O compromisso com a qualidade deve perseguir os objetivos do produto e não o seu desejo de perfeccionismo. Então, é importante lembrar: um desenvolvedor em um projeto em crescimento nunca é um perfeccionista. O valor comercial vem em primeiro lugar Para um desenvolvedor em um projeto em crescimento, é essencial compreender o valor do negócio. Quando você está acostumado a ser um desenvolvedor regular que codifica apenas de acordo com especificações prontas, isso pode ser um desafio no início. Quando o produto está apenas nascendo, o valor para os usuários ainda não está comprovado, mas o valor a ser comprovado existe na mente dos stakeholders. Neste estágio, você pode cometer o erro de sobrecarregar a base de código com lógica desnecessária. Por exemplo, você precisa escrever um manipulador de pedidos. Você cria uma tabela com pedidos no banco de dados e uma segunda tabela com tipos de pedidos, embora ainda exista apenas um tipo. Digamos que você faça isso porque a parte interessada insiste que algum dia essa lógica poderá ser necessária. Na realidade, pode nunca ser necessário. Não gere entidades desnecessárias se não houver valor nelas agora e, mais importante, não desperdice tempo e dinheiro de negócios com isso. Uma pergunta razoável poderia ser feita: “Vou discutir com uma parte interessada?” Bem, às vezes você vai. As partes interessadas esperam uma análise detalhada. As especificidades dos projetos em crescimento geralmente são a falta de recursos, portanto, os desenvolvedores devem ter habilidades analíticas. Você precisa validar constantemente o valor dos recursos do produto, pois sua viabilidade depende literalmente disso. Se você se espalhar, o negócio ficará sem recursos e você arquivará o repositório. Faça muitas perguntas: "Por que implementar esse recurso agora? Devemos resolver esse problema agora? Esse problema existe?" É exatamente o mesmo descrito acima com as tecnologias. Ser capaz de fazer as perguntas certas revela o seu profissionalismo. Você só precisa gastar seu tempo e recursos de negócios em coisas que realmente agreguem valor aos seus clientes. Hackathons são um ótimo exemplo de como a compreensão do valor do negócio influencia o resultado. Dentro de um tempo limitado, deve ser apresentada uma solução não ideal, mas viável, para um problema claramente definido. Quando os desenvolvedores se inspiram no projeto e entendem claramente por que o fazem, o resultado sai bem mesmo em 2 dias. O plano depende dos riscos Imagine um jogo de estratégia: você tem um lenhador e um recruta. O objetivo é criar um guerreiro. Primeiro, o lenhador deve coletar madeira e construir quartéis, onde o recruta poderá aprender treinamento militar. Para colher a madeira, o lenhador precisa chegar à floresta por uma parte inexplorada do mapa. A julgar pelo mapa, a floresta pode ser alcançada em um dia de jogo, o corte da lenha levará cerca de meio dia e a construção do quartel levará uma semana. Então o quartel aparecerá em cerca de dez dias. O lenhador demora quase um dia para chegar à floresta, mas de repente o rio bloqueia o caminho. O objetivo muda: temos que construir uma represa, uma ponte ou um barco para chegar ao outro lado, ou talvez seja melhor procurar florestas em outro lugar. A avaliação prematura leva a um colapso na estratégia. Se o batedor tivesse explorado primeiro uma parte não descoberta do mapa, esse risco poderia ter sido evitado. Um desenvolvedor experiente reconhece riscos que não são óbvios para as partes interessadas: integrações com serviços de terceiros, a complexidade de estender a base de código e assim por diante. É sua responsabilidade avaliar os riscos e alertar sobre eles. Na maioria das vezes, as partes interessadas desconhecem estes riscos, mas estes afectam a avaliação, o que é importante para eles. integrar seu serviço a um serviço de pagamento. Em primeiro lugar, configure o serviço de pagamento, obtenha acesso e investigue onde as coisas podem dar errado. Antes de integrar, entenda como integrar. É melhor passar um dia pesquisando do que descobrir, após duas ou três semanas de desenvolvimento, que o recurso não pode ser concluído a tempo ou que a integração falhou porque o serviço de pagamento alterou os termos ou desativou o suporte para o recurso necessário. . Um exemplo de tarefa: Depois de calcular os riscos, você precisa planejar o trabalho e fornecer uma estimativa de tempo para a tarefa. Esta é a estrutura que uso: Escreva cenários ou visualize-os no quadro: por exemplo, o usuário clica em um botão e o documento é baixado. Escolha abordagens que você entenda. Analise como o script poderia funcionar de um ponto de vista mais técnico. Quanto mais opções, melhor. Eu avalio as opções e escolho uma solução potencialmente escalável com riscos minimizados que resolveria o problema mais rapidamente. Divida os cenários em partes lógicas que precisam ser codificadas. Estime cada parte em dias e multiplique pelo coeficiente 1,11. Este é meu coeficiente mágico pessoal, que é meu aniversário em 11 de outubro. Isso é, claro, uma piada (ou não). Meu conselho é adicionar alguns dias ou até semanas extras à estimativa, dependendo do escopo do projeto. Embora tentemos prever tantos riscos quanto possível, alguns não podem ser previstos. É melhor fazer as coisas mais cedo do que não ter sucesso. Não tenha medo de dar uma estimativa maior: quando uma parte interessada perguntar: “Você não pode fazer isso mais rápido?” não responda apenas “Não”, mas justifique o porquê. Fale sobre os riscos, demonstre cenários e dê exemplos. A parte interessada precisa entender que você analisou o problema e não apenas o avaliou aleatoriamente. Aspecto importante: o seu estado de espírito também é um risco. Planeje suas férias e fique de olho na sua saúde mental para se manter motivado e não se esgotar: a responsabilidade é sua. MVP não é uma nave espacial A pergunta me incomodou durante toda a minha carreira. Parece simples – Produto mínimo viável. "Como criar um MVP?" Definição da Wikipédia: Um produto mínimo viável (MVP) é uma versão de um produto com recursos suficientes para ser utilizado pelos primeiros clientes, que podem então fornecer feedback para o desenvolvimento futuro do produto. Tenho observado frequentemente que quando você precisa construir um MVP, às vezes acaba mais como construir uma espaçonave que leva um tempo ridiculamente grande. O principal objetivo no estágio de MVP é obter feedback rápido do cliente e, com base nesse feedback, concordar com a parte interessada se devemos 'seguir em frente' ou 'virar à direita'. A melhor maneira de obter feedback são as métricas. É ótimo se eles tiverem sucesso sem eles, mas se isso não acontecer, pelo menos você saberá por quê. Vou contar sobre meu primeiro MVP. Encontrei muitas ferramentas e estruturas: . Decidi usar tudo isso porque essas estruturas são usadas dentro de grandes empresas e ouvi falar delas em conferências, palestras e no YouTube. UML, padrões de design, roteiro, pontos de história, especificação de requisitos do sistema, ADR, testes de UI e assim por diante O objetivo do serviço era armazenar dados sobre execuções de testes. Elaborei um roteiro para um ano, desenhei uma arquitetura detalhada em , passei muito tempo escolhendo um framework para o backend, configurei um sistema para testes e logs no Sentry e calculei a carga em muitos usuários em vez dos 10 esperados -15. Eu queria fazer o projeto perfeito. UML A primeira versão levou 6 meses para ser concluída. Dava para ver todos os lançamentos e gráficos e baixar relatórios, mas havia um problema na coleta de dados. Duas ou três vezes por semana aparecia um relatório quebrado, o que impossibilitava o uso do serviço, mas segui obstinadamente o plano. Nos anos seguintes, tive muitos projetos diferentes e tentei lançar minha startup. Aprendi sobre marketing, vendas e dores do cliente. A experiência mudou minha mentalidade e me permitiu desenvolver as abordagens que compartilho neste artigo. Descreverei uma tarefa recente para demonstrar como elas funcionaram na prática. Eu precisava acelerar o método API, o que incomodava os usuários com sua lentidão. O plano era movê-lo para um serviço separado do monólito, onde havia dificuldades devido a muitas integrações com serviços internos e estruturas de dados. Este projeto foi experimental – ninguém sabia se a aceleração era possível. Claro, eu poderia ir em frente e sugerir reescrever tudo e torná-lo perfeito. Comecei pesquisando o monólito e os serviços internos e investiguei os riscos das integrações. Aí criei uma estratégia usando um diagrama simples no Miro, dividi tudo em iterações e só então comecei a trabalhar. De vez em quando, ocorriam problemas com integrações sobre os quais as partes interessadas eram as primeiras a saber. Em primeiro lugar, nós os resolvemos. Sim, ainda havia dívida técnica no projeto: linters, testes incompletos, esquemas antigos no banco de dados - mas o problema dos clientes foi resolvido. Em cada iteração, coletei métricas sobre o desempenho do método API: Lento e com erros, sem liberação. 2x mais rápido e com erros, sem liberação. 5x, 1% de erros em todas as solicitações. 6x mais rápido, sem erros. Todas as iterações atingiram a meta e, na 4ª tentativa, atingimos 100%. Seriam necessárias 10 iterações para reescrever tudo do zero, mas ainda em menos tempo conseguimos um serviço escalonável que resolveu o problema. A única questão é a abordagem. Codex de um desenvolvedor em um projeto em crescimento Deixe de lado o perfeccionismo. Embora o mundo esteja repleto de tecnologias que resolvem problemas, não é preciso saber tudo para tornar os projetos úteis para as pessoas. Use soluções prontas sempre que possível. O valor do negócio vem em primeiro lugar. Os usuários não vêm em busca de um produto, mas sim de uma solução para seus problemas. Avalie os riscos desde o início e comunique-os às partes interessadas de forma clara. Faça planos de curto prazo. Se a tarefa estiver pendente há dois anos, provavelmente os usuários não precisarão dela. Colete feedback e métricas de todas as maneiras possíveis. As métricas são uma forma confiável de encontrar pontos de crescimento. Soluções escaláveis podem ser alcançadas mesmo quando os padrões de engenharia “certos” não são usados no início.
