Como vocês se organizam de forma sistemática sendo desenvolvedor solo?

• Quando eu trabalhava em equipe, metas de curto prazo como scrum e um backlog de trabalho bem estruturado realmente ajudavam a manter o foco e acompanhar o que precisava ser feito
• Mas, ao desenvolver sozinho, não consegui encontrar uma abordagem adequada e muitas vezes acabava me desviando e perdendo o objetivo
• Que ferramentas e técnicas vocês usam para se manter fiéis às metas?

CharlieDigital

• Usa um caderno de papel
• Quando não há necessidade de compartilhar informações, não existe nada melhor que um caderno para espalhar todas as ideias e revisá-las repetidamente. Não precisa fazer login, dá para levar para qualquer lugar, sentar num banco e pensar em ideias, ou ir para a academia e anotar ideias.
• Basta escrever as metas do dia em uma checklist e ir marcando uma por uma. Como não é preciso compartilhar o status com outras pessoas, não há necessidade de algo como GitHub Projects

olooney

• Usa um arquivo TODO.md
• Escreve a lista em GFM (GitHub Flavored Markdown) assim:

    1. [X] Dockerfile  
    2. [ ] Bulk Inference  
    3. [ ] CLI  
    4. [ ] Logging  
  

• Coloca no topo uma seção chamada "backlog" para ideias futuras, uma seção "bugs" para erros a corrigir e uma seção sem nome com os itens atuais
• Quando chega a um marco, como um release, apaga todos os itens concluídos

jasonb05

• Escreve muito para o seu eu do futuro
  1. Trello com colunas para semana, mês, trimestre e ano
  2. Um caderno aberto ao lado do mouse
     2a. Página da esquerda: checklist diária de tarefas com caneta e papel. (2 a 3 linhas por dia)
     2b. Página da direita: rascunhos, esboços de diagramas, sticky notes etc.
  3. Um diário de desenvolvimento para registrar pesquisas, URLs, artigos, pensamentos, ideias, progresso, extensões etc.
  • Todo projeto no GitHub tem uma pasta dev/ para essas notas, com nomes de arquivo no formato yyyymmmdd-n.txt
  • Cria um novo arquivo por projeto a cada dia, conforme necessário
  4. Sticky notes amarelos para ideias temporárias (na parte de baixo da tela, no notebook ou no quadro branco)
  • Normalmente com aforismos que indicam a direção correta do projeto (por exemplo: "ninguém nunca vai ler o rtfm")
  5. Quadro branco, colunas por projeto, impressões + ímãs (gráfico mensal do progresso do projeto), sticky notes, ideias para projetos futuros e vários objetos
• Ele tenta se comunicar de forma excessiva com o seu eu do futuro
  • Isso ajuda a organizar o que está pensando no momento, como expectativas, progresso e obstáculos
  • O obstáculo sou eu, não o trabalho
  • O trabalho normalmente ganha forma em itens depois de "pensar bastante"
• Trabalha sozinho assim há 8 anos
  • Desde o doutorado, no começo dos anos 2000, usa diretórios /dev e arquivos .txt para manter um diário de desenvolvimento em tempo real. Isso já economizou incontáveis horas (grep).
• Ah, e ele faz as mesmas coisas todos os dias. Quase todos os dias
  • Por exemplo, suporte ao cliente, divulgação, escrita, programação e.... sem precisar pensar, só faz aquela tarefa e depois passa para a próxima

liampulles

• Ao tocar side projects, "desenvolvimento guiado pelo README" ajuda a manter a motivação e limitar o escopo

Tehnix

• Define metas diárias, semanais e mensais, e as organiza com apps como Linear, Todoist e Notion
• As metas mensais são bem gerais e poucas (por exemplo: "criar um PoC", "redesenhar e relançar o blog")
• As metas semanais são mais específicas e limitadas (por exemplo: "decidir uma abordagem para chamar Rust a partir de código Swift" ou "finalizar o design e o styling do post")
• As metas diárias são muito específicas (por exemplo: "configurar o pipeline do UniFFI para gerar bindings em Swift" ou "implementar o novo tema em todas as páginas do blog")
• Às vezes, no meio da implementação, surgem novas tarefas e a meta diária acaba sendo adiada para o dia seguinte
• Até agora, esse método tem sido eficaz para aumentar o foco, e as metas diárias são escolhidas com base no foco da semana dentro de uma longa lista de trabalhos/issues em andamento em vários projetos
• Se cada trabalho em andamento for configurado como um projeto e, ao adicionar uma tarefa, ela já receber prioridade, fica fácil ter uma visão geral dos projetos grandes e pequenos em andamento ou que você quer fazer no futuro
• Gosta de papel, mas só para coisas temporárias. Prefere uma abordagem digital, em que pode adicionar ideias facilmente pelo celular quando está em movimento. Além disso, escrever no teclado é muito mais rápido, e usa várias tarefas como repositório de informação enquanto trabalha ou pesquisa algo

OogieM

• Organiza tudo em pastas dentro de um Obsidian Vault
• As pastas contêm elementos em comum parecidos
  • Uma nota Kanban com o plugin Kanban para a estrutura de telas (quais recursos ou atividades existem em cada tela)
  • Uma nota de roadmap com detalhes de cada funcionalidade
  • Notas gerais com várias tarefas relacionadas àquele app ou componente
• Usa o plugin Tasks para acompanhar exatamente no que está trabalhando
  • Essa pasta também contém documentação adicional como capturas de tela, materiais de referência e outras notas relacionadas a um app específico
• Seus projetos são um conjunto de programas para gerenciar gado e registros de raças raras
  • Por isso, mantém Farm Mobile (Android), Farm Desktop (Python), Registry Web (Flask), Registry Desktop (Python) e o schema do banco de dados (SQLite), todos em repositórios separados no GitLab
• Agora entraram mais 3 colaboradores, então compartilha o Obsidian Vault via Obsidian Sync. O sistema solo conseguiu ser ampliado para dar conta do trabalho em equipe

robomartin

• Há anos usa um arquivo de texto simples inspirado em Kanban
• Gerencia tudo assim, de projetos pequenos a projetos de milhões de dólares
• Cada projeto tem um arquivo de log principal, e há arquivos específicos por área (eletrônica, mecânica, óptica, manufatura, testes etc.)
• Conteúdo do arquivo

  <nome do projeto> arquivo de log  
  -------------------------------- WORKING ON NOW   
  <tarefa em andamento>  
  
  -------------------------------- TO DO   
  - <inicie cada tarefa com um traço>  
    - <indente subtarefas ou notas relacionadas>  
  
  -------------------------------- IDEAS  
  <notas em formato livre>  
  
  -------------------------------- RESOURCES  
  <recursos em formato livre>  
  
  -------------------------------- DONE  
  <mova o que foi concluído para esta seção>  
  <deixe timestamps se quiser>  
  

kkfx

• Organiza tudo com Emacs/org-mode/org-roam
• Usa o org-agenda da nota do ano atual; as notas ficam em um diretório por ano dentro de um diretório comum do org-roam, com um arquivo por dia e separados por hora
• Isso reduz a quantidade de arquivos que o org-agenda precisa percorrer e também diminui, na nota-resumo anual, o material de longa duração que passa de um ano para o outro

makz

• Antes de encerrar o expediente, deixa comentários no código: "estou fazendo isto agora, e para funcionar preciso fazer A, B, C..."
• Assim, na próxima vez que abrir o editor, sabe exatamente o que precisa fazer

qntmfred

• Tem um template de rotina diária no Obsidian Daily Note. Isso o ajuda a focar no dia e ficar animado com ele
• O primeiro [X] que marca para si todos os dias é completar a checklist da rotina diária
  • Uma vitória grátis para começar um dia produtivo
• Na prática, escreve a maior parte das notas usando digitação por voz do Windows, então é quase como fazer uma daily standup
• Também costuma fazer live stream o dia inteiro, mesmo que o único espectador seja ele mesmo (claro, é uma live privada, então faz isso todos os dias, mas serve para o caso de precisar lembrar o que estava fazendo/pensando uns 20 minutos antes, antes de se perder em alguma tangente. Na verdade, o Recall do Windows também é bom para isso)
• Seu dia transcorre de forma parecida com quando trabalha com outras pessoas em uma organização de 2 ou mais pessoas (também conhecido como reuniões)

mentos

• Um quadro no Trello com três listas: Done/Doing/ToDo
  • Faz uma lista de tudo o que precisa ser feito
  • Define prioridades
  • Move o item do topo para a lista de doing e começa a trabalhar
  • Quando termina, move para done. Pega o próximo item da lista to do e repete
• Usa outras listas do Trello para gerenciar cartões de pesquisa ou remover da lista ToDo funcionalidades que não são necessárias para a v1

macNchz

• Gosta de trabalhar de forma parecida com quando está em uma equipe pequena
  • Gerencia issues no GitHub organizadas de forma solta por milestones, com checklists cheias de itens
    • Como fica perto do código, é fácil deixar notas para lembrar onde parou usando links para linhas, blocos de código copiados e colados ou rascunhos de PR vinculados
    • É muito fácil acessar de qualquer dispositivo, então quando surge uma ideia ou recebe um e-mail sobre um bug, consegue criar rapidamente uma issue na hora, pelo celular ou por outro aparelho que não seja o de desenvolvimento
    • Também é simples chamar outras pessoas na hora certa para trabalharem imediatamente
    • Tem uma boa API e várias integrações (por exemplo, criar ou vincular issues diretamente de sistemas de rastreamento de erros)

rerdavies

• Usa GitHub Projects
  • Não recomendaria com tanto entusiasmo
  • Mas gerenciar lista de tarefas e bugs não é exatamente ciência de foguetes
  • Já usou soluções de gerenciamento de projetos que custavam centenas de milhares de dólares e eram muito piores do que isso
• Mesmo que o GitHub Projects se comporte de forma estranha e não seja muito amado, o mínimo de funcionalidade já basta
  • Há muitas coisas que você imagina que poderiam ser automatizadas
    • Coisas como passar para um novo sprint com alguns cliques, sem precisar ajustar manualmente todas as queries do quadro scrum
  • Mas dá para fazer o que você quer
    • É muito melhor do que ficar preso, sem flexibilidade, a um processo definido por outra pessoa
    • Em certo sentido, o minimalismo pode até ser uma vantagem
• Psicologicamente, isso é um problema de gerenciamento de listas. Não é tão complicado. E o GitHub Projects gerencia listas muito bem
• Um motivo para recomendar GitHub Projects em vez de listas em papel ou cartões é
  • Que os usuários podem ver publicamente como bugs reports e feature requests estão sendo tratados
  • Também é muito fácil transformar algo postado em um fórum de discussão em bug report ou em tarefa de desenvolvimento (adiada ou ativa)
• As regras normais de scrum se aplicam. Todo bug é corrigido antes de começar trabalho novo, e o trabalho só vai para concluído quando estiver realmente terminado
• Você precisa de uma lista. Eu gosto disso porque a estrutura de sprint por cima das tarefas fornece milestones úteis para atualizações intermediárias e releases contínuos

leros

• Separa os papéis de gerente de produto, gerente de projeto, desenvolvedor de software, marketing, operações de negócio e liderança geral do negócio, e exerce apenas um de cada vez
• Por exemplo,
  • Pode sentar como líder geral do negócio e decidir a direção estratégica desejada
  • Depois coloca o chapéu de gerente de produto e decide o que construir
  • Depois gerencia o projeto e define prioridades para essa ideia
  • Em seguida atua como gerente de produto/designer para detalhar a funcionalidade priorizada
  • Depois separa um tempo totalmente à parte (geralmente um dia inteiro) para desenvolver a funcionalidade
  • Quando a funcionalidade é lançada, coloca o chapéu de marketing e faz o marketing relacionado ao produto
  • Esse é o tipo de ciclo de vida para desenvolver uma funcionalidade
• O perigoso é ficar alternando entre todos os papéis ao mesmo tempo. Isso pode reduzir a produtividade
• Há momentos de ser estratégico, momentos de ser criativo e momentos de simplesmente executar, e cada um desses trabalhos exige um estado mental diferente
• Faz todo o planejamento no Notion, usando alguns quadros Kanban diferentes conforme o propósito

urda

• Usa um sistema em cascata de "conhecimento":
  • Registra pensamentos aleatórios, notas, recortes, diagramas etc. em um caderno de bolso Moleskine
  • Isso eventualmente vira um "ticket" no issue tracker ou uma "wiki" / "atualização da wiki" no seu servidor de wiki
  • Isso acaba levando a snippets, notas de configuração, documentos de registro, arquivos, runbooks etc.
• No fim, manter a documentação atualizada ou, quando um problema é encontrado, colocá-lo no backlog correto virou algo "natural"

[xguru]

Acho que, para qualquer coisa, o melhor método é o que fica mais fácil de transformar em rotina para você mesmo. Se há muita preparação envolvida e abrir um documento de controle para começar leva tempo e fica incômodo, você vai se afastando disso aos poucos. Até o simples ato de tirar da gaveta e abrir um notebook que você guardou em algum lugar depois de arrumar a mesa já parece trabalho.

Nesse sentido, como o VS Code está quase sempre aberto no computador de casa e no da empresa, faz parte da minha rotina diária escrever e apagar coisas no 할일.txt que deixo aberto nele. Acho bom porque vira rotina sem precisar pensar no que abrir. Sincronizo o conteúdo com um GitHub Private Repo.

[mytory]

Eu anoto no Google Sheets todas as tarefas do projeto, dividindo tudo em blocos de 30 minutos a 1 hora, e registro quanto tempo levou até concluir. Fica mais fácil prever e também dá uma sensação boa ir concluindo uma por uma.

[devsepnine]

Acho que uso principalmente o Trello, listando tudo e organizando a descrição...
Como dá para acessar de qualquer lugar...

[tested]

Eu criei um servidor pessoal no Discord, classifico por categorias/canais e uso para fins pessoais, como TODOs.

[porteleaf]

Tentei várias abordagens, mas ainda não consegui me fixar em um único método. No momento, faço anotações no Obsidian e, no trabalho prático, escrevo no legal pad sempre que preciso.
Acho que, por serem anotações para substituir a memória de curto prazo, muitas vezes acabo esquecendo o que anotei depois de algum tempo..
Acho que vou precisar reorganizar meu sistema com base neste post..

[hwan0317]

Mesmo que não se trate necessariamente de desenvolvimento solo, parece ser um conteúdo útil para gerenciar motivação e planejamento de forma geral!