- Ao conduzir grandes projetos técnicos, manter a motivação e chegar até o fim depende da existência de resultados visíveis no dia a dia
- Em vez de dividir o projeto em blocos grandes e vagos, a ideia é quebrá-lo em pequenas partes visíveis e escolher formas de confirmar progresso real em cada etapa
- Nas fases iniciais, criar demos rapidamente com loops de feedback curtos ajuda muito na imersão e na automotivação
- É eficaz começar desenvolvendo primeiro os recursos necessários para si mesmo e continuar aprimorando por meio do uso real
- Mais importante do que a perfeição é o avanço; acumular repetidamente a experiência de pequenos sucessos leva à conclusão de projetos longos
No ponto de partida
- Ao iniciar um projeto de grande porte, o maior obstáculo é decidir por onde começar
- Se tentar considerar todos os componentes de uma vez, tudo fica abstrato demais e é fácil perder o interesse
- O importante é começar por pequenas unidades que permitam ver resultados rápidos
- Cada subprojeto deve ser independente e oferecer sinais claros de conclusão
- Quanto mais experiência se tem, melhor se consegue enxergar a forma geral e os subcomponentes do projeto
Gerando resultados iniciais
- No trabalho inicial, pode haver poucos elementos visíveis externamente, então o progresso pode parecer invisível
- Nesses momentos, é importante usar bem testes automatizados (por exemplo, testes unitários) para obter resultados visíveis
- Por exemplo, ao criar um parser de terminal, é possível verificar imediatamente em testes o resultado do parsing de strings de entrada
- A experiência repetida de ver os testes passando já traz sensação de realização
- Com esses pequenos sucessos, é possível continuar acumulando evidências objetivas do progresso do projeto como um todo
Criando demos rapidamente
- O objetivo inicial não é um subcomponente perfeito, e sim uma implementação suficiente para uma demo
- Complexidades necessárias no longo prazo, como banco de dados ou estruturas de dados avançadas, ficam para depois; a prioridade é avançar rápido com uma implementação simples
- É importante sempre lembrar que 'o perfeito pode se tornar inimigo do progresso'
- A meta é produzir uma demo simples uma ou duas vezes por semana
- Mesmo uma demo incompleta pode ser verificada diretamente e gerar feedback intuitivo, o que contribui muito para a motivação
Desenvolvendo para mim mesmo
- Especialmente em projetos pessoais, é importante implementar primeiro as funcionalidades de que você precisa e passar pelo processo de adotar e usar você mesmo
- Ao usar diretamente, você sente na prática o que está faltando e melhora o projeto focando nas funcionalidades realmente necessárias, fazendo-o evoluir do ponto de vista de um usuário real
- No início do uso, incômodos ou bugs aparecem, mas isso deixa muito claro o que fazer em seguida
- O orgulho de usar um software que você mesmo escreveu ajuda a sustentar o projeto
- No começo, recursos desnecessários como scroll, seleção com mouse e abas são todos omitidos
Como empacotar o projeto como um todo
- Quebre o problema inteiro em pequenos problemas visíveis. Cada problema deve permitir confirmar um resultado concreto
- Cada pequeno problema deve ser resolvido apenas até um nível suficiente para produzir uma demo, e então você passa para o próximo
- Crie uma demo funcional o mais rápido possível e depois adicione funcionalidades de forma iterativa
- Priorize implementar funcionalidades que tenham significado para o seu próprio uso
- Quando necessário, melhore cada componente iterativamente e repita esse ciclo
Conclusão
- Com esse método, é possível manter a própria motivação e concluir projetos diversos, sejam pessoais, em grupo, de trabalho ou acadêmicos
- O foco está menos em deploy ou tooling e mais em que tipo de abordagem realmente torna possível sustentar a motivação ao longo do tempo
- O mesmo método não serve para todo mundo, mas resultados visíveis de progresso são a maior força para concluir projetos de longo prazo
- É importante entender seus próprios interesses e seu modo de se motivar, e construir um processo de trabalho alinhado a isso
1 comentários
Comentários no Hacker News
Concordo com tudo o que foi dito no texto e queria acrescentar mais uma coisa: a importância de loops de feedback rápidos
Quando você faz uma mudança e vê o resultado imediatamente, isso é muito motivador
Quando você mexe no código de forma mais livre e observa o efeito, muitos problemas desaparecem ou se transformam em algo fácil de resolver
Em projetos enormes, havia uma correlação clara entre quão fácil era configurar e executar o projeto e a quantidade de problemas no projeto (bugs, atraso em prazos etc.)
Essa palestra fala sobre loops de feedback
link do YouTube
Estou pensando em aplicar testes e2e para bugs que encontrei, para confirmar com certeza que foram corrigidos
Quando você quer tentar ou consertar algo, se o setup por si só leva horas, a motivação vai embora e no fim você adia
Por isso gosto de linguagens como lisp, que têm um REPL realmente útil
Tem aquela satisfação imediata de ver o resultado na hora
No momento em que você perde a motivação, o projeto evapora
Por isso, fazer com que o próprio desenvolvimento seja uma experiência prazerosa é quase o fator mais importante
Acho que experiência às vezes até atrapalha
Vejo com frequência engenheiros seniores se aprofundando demais para construir algo perfeito, mas quando chega a hora de mostrar uma demo, o resultado final não é grande coisa
A implementação pode até estar boa, mas a funcionalidade ou o produto em si é completamente sem graça
Às vezes eu queria simplesmente desligar o cérebro e sair escrevendo código tosco
Antigamente eu fazia muitos projetos de brincadeira e até jogava todo o código-fonte em um único arquivo
Eu nem me preocupava com modularização, mas era divertido e funcionava
Agora ficou realmente difícil terminar até um projetinho de brincadeira
Acho que vem da tendência de querer colocar um monte de recursos desnecessários porque você já fez isso uma vez antes
Por exemplo, participar de desafios de programação como Advent of Code, em que os problemas do começo são simples e só mais tarde exigem otimização ou algoritmos complexos
Ou trabalhar com restrições como no pico-8, onde não dá para codar por muito tempo
Ou ainda fazer algo em ambientes com tempo limitado, como hackathons ou game jams
Porque pessoas com menos experiência podem esquecer todas as "best practices" cansativas das linguagens antigas e tentar coisas livremente
Eu mesmo desenho as tabelas do banco de dados e deixo a parte de implementação um pouco mais solta para a LLM
Achei marcante a ideia de que o objetivo dos subprojetos iniciais não é criar um "subcomponente finalizado", mas sim um subcomponente "bom o suficiente" para permitir avançar para a próxima etapa
Percebi que, para colocar esse jeito em prática, é preciso "deixar algo de fora"
Outras pessoas disseram que, nesse modo, ignoram a modularização do código, mas para mim manter o código organizado me dá satisfação e motivação
Então eu pretendo "deixar de fora" coisas como algoritmos, estruturas de dados e desempenho
No fim, o ponto é que com certeza algo precisa ser pulado, mas se esse algo for justamente o que me dá motivação, então não deve ser deixado de lado
A demo faz o papel de etapa intermediária entre desenvolver software (programar) e explicá-lo por escrito (documentar)
Por meio de demos, posso validar continuamente minhas hipóteses sobre o que meu projeto deve fazer, e isso vira uma espécie de mecanismo de feedback
As demos permanecem ao longo do tempo, então quando alguma funcionalidade quebra, dá para perceber na hora e continuar o ciclo de corrigir e iterar
Pessoalmente, trabalho assim no motor de jogo que estou desenvolvendo
exemplo de demo no github
Tomara que esse jeito vire senso comum
Parece mais focado em projetos pessoais
Eu queria saber qual seria um bom jeito, em grandes projetos técnicos de equipe, de fazer todo mundo trabalhar em direção a um objetivo e realmente concluir as coisas direito
Em quase 15 anos de trabalho, nunca vi um projeto técnico sem estouro de orçamento, atraso de cronograma, entrega incompleta de funcionalidades ou burnout
Por outro lado, se houver exemplos de grandes projetos conduzidos com sucesso, eu gostaria de ver links ou recomendações de leitura adicional
Estouro de orçamento é algo comum, desde que o dinheiro de verdade não acabe de fato
Na maior parte das vezes, é só alguém reclamando que a estimativa estava errada
A mesma coisa vale para atraso de cronograma: se não existe um prazo realmente inadiável, isso não é um problema tão grave
Na verdade, eventos atrelados ao calendário, como grandes campanhas de divulgação, idealmente não deveriam ser planejados até que o projeto esteja quase pronto
Entrega incompleta de funcionalidades também é, no fim, uma questão de expectativa
O verdadeiro problema é quando as pessoas ficam completamente drenadas e entram em burnout
Isso, pelo menos, precisa ser evitado a todo custo
Pessoalmente, venho gostando cada vez mais do Scaled Agile Framework
Eu o uso como um framework, ou seja, como uma espécie de "espantalho" que pode ser adaptado conforme a situação
Isso me levou a explorar mais a fundo os materiais originais e tirar minhas próprias conclusões
Aprendi que o verdadeiro sucesso começa com entender claramente "por que estamos construindo isso"
Se o objetivo não está claro, você não consegue nem definir prioridades nem saber por onde começar
Essa clareza ajuda muito mais a decidir "o que construir e quando", e às vezes até torna possível decidir "não construir nada"
A próxima coisa importante é a "empatia"
Você precisa realmente entender os problemas do cliente a partir da perspectiva dele e propor uma solução
Não se trata simplesmente de entregar tudo o que o cliente pede, mas de entender com precisão a dor central e entregar algo realmente valioso
A verdadeira razão pela qual a maioria dos projetos fracassa é que a equipe gasta tempo demais construindo a "coisa errada"
Se o foco continuar nas funcionalidades necessárias, que as pessoas realmente querem ou pelas quais pagariam, muito mais projetos poderão ser concluídos com sucesso
Tem gente demais olhando para projetos grandes e entrando em paralisia por análise
O realmente difícil é terminar
Quando você cria um software para uso próprio, pode resolver seus próprios problemas
E, usando o software você mesmo, também consegue encontrar bugs
Na prática, encontrei vários bugs enquanto criava e usava meu próprio servidor web
Uma cultura de desenvolvimento focada, iterativa e orientada a resultados que estejam sempre funcionando