Decomposição de tarefas
(jacobian.org)- Estimar ou delegar um projeto começa transformando pedidos grandes como “fazer isto” em uma lista clara de tarefas, e cada item deve deixar explícitos a mudança desejada e o estado de conclusão
- O processo de decomposição funciona anotando, a partir de ideias, esboços e listas iniciais, os passos necessários e refinando recursivamente cada item até que esteja suficientemente definido
- O exemplo de um streak tracker para atividades ao ar livre vai sendo dividido em modelo de dados, visualização de calendário, registro de atividades, cálculo de streak e streak freeze, revelando também os pontos de incerteza
- Uma “tarefa suficientemente definida” é aquela em que se pode responder sim para a mudança desejada, a aparência do concluído, todas as etapas até a conclusão e as informações necessárias para começar imediatamente
- Como decompor tarefas é uma habilidade que exige reconhecimento de padrões baseado em experiência, equipes iniciantes precisam de oportunidades seguras para praticar planejamento e receber feedback
Transformando um grande projeto em uma lista de tarefas
- Discussões anteriores sobre estimativa de projetos já presumiam a existência de uma lista clara de tarefas, mas na prática pode ser necessário primeiro passar pela etapa anterior de decomposição do trabalho
- Decompor tarefas é o processo de dividir um projeto grande em partes constituintes, e para estimar ou delegar é preciso uma granularidade mais fina do que uma tarefa única como “fazer este desenho”
- Em um projeto pessoal tocado sozinho, um esboço pode bastar, mas para passar a outra pessoa ou estimar prazo é preciso elevar o nível de detalhamento
Exemplo: um streak tracker pessoal
- É usado como exemplo um streak tracker pessoal para acompanhar os dias em que houve atividade ao ar livre
- Deseja-se algo parecido com o app Streaks
- Quer incluir opções de atividades ao ar livre como corrida, ciclismo e esqui
- Também pretende incluir o recurso de streak freeze do Duolingo
-
1ª etapa: começar por um esboço
- Um mockup visual é um bom ponto de partida para mostrar de forma fácil o que será construído
- Em um projeto feito sozinho, talvez já fosse possível começar a programar apenas com esse nível de esboço
- Se o objetivo for estimar ou delegar, é preciso uma lista de tarefas mais fragmentada do que apenas “fazer este desenho”
-
2ª etapa: dividir em grandes blocos funcionais
- Na primeira decomposição, o projeto é dividido em componentes aproximados
- Modelagem de dados
- Visualização de calendário mostrando as datas da semana atual
- Calendário interativo em que se clica em um ícone para registrar uma atividade e marcar a data correspondente como concluída no rastreamento de streak
- Cálculo e exibição do tamanho do streak atual
- Implementação de streak freeze
- Para simplificar o exemplo, ficam de fora tarefas operacionais como deploy e configuração de banco de dados
- Em um projeto real, especialmente com várias pessoas envolvidas, costuma ser mais apropriado separar deploy, frontend e backend em itens distintos
- Mesmo nessa etapa já dá para fazer alguma estimativa, mas ainda restam incertezas como a forma de acumular e rastrear freezes, histórico passado e inclusão ou remoção de tipos de atividade
-
3ª etapa: dividir mais até que os critérios de conclusão fiquem visíveis
- O modelo de dados é dividido em tipos de atividade, atividades registradas, freeze e streak
- Para tipos de atividade, uma lista hardcoded como run/bike/ski/climb já basta
- Atividades registradas têm data e tipo
- Freeze tem data de obtenção e data de uso
- Streak tem data de início, data de fim e informações agregadas por tipo de atividade
- A visualização de calendário estático é dividida em visão semanal, tela inicial, visão mensal, navegação e entrada para mover-se entre datas
- Para mover-se entre datas, pode-se usar o widget HTML5 de data sem precisar de entrada fuzzy de datas mais complexa
- O calendário semanal dinâmico evita colocar entrada dinâmica na visão mensal e registra a conclusão ao clicar no tipo de atividade de uma data específica
- O cálculo e a exibição do streak percorrem os registros de atividade para calcular o streak, mostram o streak atual na UI e recalculam o streak quando uma atividade é registrada pela UI
- O streak freeze inclui acúmulo, prevenção de acúmulo duplicado e exibição na UI do uso e da quantidade restante
- O valor X de dias para ganhar um freeze pode, por enquanto, ficar hardcoded
- Um freeze pode ser carregado para o próximo streak
- Ao recalcular o streak após editar atividades passadas, é preciso impedir o acúmulo duplicado de freezes obtidos novamente
Procedimento de decomposição aplicado repetidamente
- Decompor tarefas não é um desenho concluído de uma vez, mas um processo iterativo
- Começa-se por uma lista de tarefas ou por um grande projeto
- Pensam-se e anotam-se os passos necessários para concluir aquele trabalho
- Verifica-se se cada passo está suficientemente definido
- Se não estiver, aquele item é decomposto novamente
- Cada iteração não precisa ser completa nem exata; basta que esteja um pouco mais desenvolvida do que a lista anterior
- O mesmo processo é repetido até que todas as tarefas estejam suficientemente definidas
O que conta como “tarefa” e como “suficientemente definida”
- Em desenvolvimento de software e estimativa de projetos, uma tarefa é uma unidade de trabalho suficientemente definida, completa e capaz de produzir mudança
- “work on stuff” não é tarefa porque não delineia os requisitos
- “cortar a árvore” não é uma tarefa completa se a pessoa só trouxe a motosserra
- No contexto de trabalho, uma tarefa só faz sentido se algo estiver diferente após sua execução
- Se uma tarefa está suficientemente definida pode ser julgado por saber se quem vai executá-la consegue responder “sim” a todas as perguntas a seguir
- Entende qual é a mudança desejada
- Entende como será o “concluído”
- Consegue definir todas as etapas necessárias até a conclusão
- Na ausência de bloqueios ou dependências, possui todas as informações necessárias para começar agora mesmo
- Dependendo do contexto organizacional, observadores como gerente de projeto, principais stakeholders ou auditores também podem precisar responder “sim” a essas perguntas
- Há tarefas, como correção de bugs, que têm incógnitas difíceis de decompor ainda mais
- Nesses casos, podem ser usadas técnicas como timeboxing
A intuição de decomposição que se forma com a experiência
- Decompor tarefas é uma habilidade que exige prática, e é normal que não pareça fácil no começo
- No exemplo, a modelagem de dados vem primeiro não por haver um algoritmo claro, mas por intuição baseada em experiência
- Ao criar ferramentas parecidas, houve a experiência de que começar pelo modelo de dados fez o trabalho fluir melhor
- O Django oferece affordances mais adequadas para um fluxo orientado primeiro aos dados do modelo
- Sem experiência suficiente em observar ou executar projetos diversos, pode ser difícil decidir por onde começar
- Para que uma equipe desenvolva essa capacidade, ela precisa criar planos de projeto em um ambiente seguro, tentar decompor o trabalho e receber feedback
- Mesmo que os planos iniciais estejam bastante errados, se isso não for punido, esses erros se tornam dados de experiência para o próximo reconhecimento de padrões
Resultado da estimativa do projeto de exemplo
- Na estimativa bônus, após decompor as tarefas, são atribuídos complexidade, incerteza, dias estimados e dias no pior caso
- O total estimado é de 15,5 dias, e o pior caso calculado é de 23,5 dias
- Entre os itens principais, cálculo de streak e acúmulo de freeze têm complexidade média e incerteza moderada, com estimativa de 3 dias e pior caso de 4,5 dias cada
- A prevenção de acúmulo duplicado de freeze tem complexidade pequena, mas incerteza extrema, com estimativa de 1 dia e pior caso de 5 dias
- Na prática, o projeto foi concluído em cerca de doze noites e um voo longo, mas com grande simplificação do design, e o algoritmo de freeze possivelmente ainda terá bugs que aparecerão depois
1 comentários
Comentários do Hacker News
Primeiro, quase nunca segui até o fim as etapas reais conforme planejadas. Depois de apenas algumas etapas, percebo algo novo, descubro algo que deixei passar ou vejo um caminho mais fácil, então acabo não seguindo o plano
Segundo, sinto que todo o esforço criativo de pensar em como construir fica concentrado no começo, e por isso não gosto de trabalhar assim. O restante ainda é a maior parte do trabalho, mas sobra só a parte mais tediosa; misturar criatividade e tédio de forma mais equilibrada é mais divertido, portanto mais rápido, e o resultado também é melhor
As duas coisas provavelmente estão relacionadas, e não é impossível que eu tenha TDAH
Se você está explorando ou construindo um projeto próprio e não há muita estrutura de responsabilização, não precisa planejar tanto assim, a menos que goste de planejar por si só
Mas no momento em que seu chefe pergunta “quanto tempo vai levar? quem faz o quê? por onde começamos?”, algum tipo de estrutura passa a ser necessário
Eu também detesto me adaptar a sistemas arbitrários ou rígidos demais, mas sistemas devem ser simples e flexíveis, e sistemas de produtividade existem para ajudar as pessoas
Acho que o autor não pretendia apresentar isso como uma receita detalhada; parecia mais querer mostrar sua abordagem para que outras pessoas tirassem suas próprias ideias
Às vezes é até pior do que dizer “o plano nunca é seguido à risca”. Quando você continua adicionando tarefas durante a execução, no fim fica apenas uma lista bagunçada de tarefas incompletas que não são mais necessárias, misturadas às tarefas criadas durante o planejamento
Isso acontece porque essas tarefas foram criadas sem o contexto completo que só surge durante a execução
A graça da programação está em ser uma atividade criativa, flexível e fluida. Você vai construindo à medida que avança e vivencia o processo de forma orgânica
Em um ambiente de trabalho, como são necessários monitoramento e atribuição de responsabilidade, essa organicidade geralmente é removida
Da próxima vez que você planejar algo igual ou parecido, o plano futuro será melhor
Gerentes de projeto também têm o lema “falhar em planejar é planejar para falhar”
Porque percebo com frequência que deixo muita coisa passar em meio a tantas coisas que preciso lembrar
Um plano é apenas uma forma de lembrar ao meu eu futuro o resultado ideal que meu eu do passado imaginou. Em vez de ficar mudando o plano sem parar e correndo atrás de vaga-lumes
“Decomposição de tarefas” é um tema grande o bastante para virar um gênero de livro ou de podcast. Em livros de autoajuda ou organização, muitas vezes a atividade de decompor tarefas é tratada como uma capacidade humana primitiva que os leitores já possuem
Mas, pela minha experiência e por relatos que ouvi em sessões de grupo, decompor tarefas é muito difícil e pode provocar vontade de evitar a tarefa ou sensação de desespero
O conselho mais amplamente aplicável que já vi é continuar quebrando a tarefa em partes menores até eu ter 90% de confiança de que consigo concluí-la com sucesso. Esse nível de confiança varia conforme a autoconfiança e a propensão ao risco; algumas pessoas talvez quebrem até chegar a algo como 70% de chance de sucesso
O tempo disponível em um dia é de cerca de 6 horas; quando alguém diz com confiança que leva “meio dia”, e você aponta que isso significa cerca de 3 horas, a pessoa de repente fica bem menos confiante ou se irrita. E, 3 dias depois, ainda está trabalhando naquilo
Esse método foi surpreendentemente preciso para estimativas de tempo, mas quando visto no total; as estimativas individuais erravam bastante
No fim, é uma estimativa probabilística. Depois de muitos eventos, converge para a média
O problema que a maioria não percebe é que o desenvolvimento de software é, acima de tudo, uma atividade criativa. Claro que há aspectos técnicos sérios, mas como o problema em si é virtual e não está preso a restrições do mundo real como na engenharia civil, não existe uma única solução ótima definida
Tentar definir a solução antes de examinar adequadamente o problema só limita o resultado final. A maior parte da exploração só acontece depois que a codificação de fato começa
Em software, o fato de o resultado final e o tempo não serem claramente definidos não é tão importante, porque não há custo por unidade. Gestores sem formação em engenharia de software não entendem bem isso
Um produto genérico pode ser vendido a vários clientes sem custo adicional de desenvolvimento
Mas, como a maioria das empresas é administrada como uma fábrica, todos os processos acabam produzindo produtos muito limitados voltados a clientes específicos. Foi exatamente isso que as grandes empresas de tecnologia evitaram
Parece que o setor inteiro aceitou esse padrão
Mas, sinceramente, acho que o que impede a maioria de nós é justamente a falta da capacidade de não fazer isso. Se há algo que você quer construir, não planeje todas as peças; simplesmente construa a menor coisa que possa ter valor
No exemplo, basta começar com a tela “Hoje” e 4 botões. Você provavelmente consegue criar hoje algo que mostre 4 botões de exercícios para apertar todos os dias. Não precisa de sequência de dias, congelamento nem visualização de calendário
Essas ideias são todas boas e você fará depois, mas primeiro precisa de impulso. Daqui a alguns dias, talvez você decida que aquela visualização de calendário não lhe agrada
Mais projetos precisam desse empurrão de “faça, mesmo que seja algo pequeno”. Termine hoje e, a partir desse ponto, veja qual é a próxima tarefa. Há uma grande chance de ser diferente do que você imaginava na fase de planejamento
Claro que isso também não é fácil. É preciso reflexão e disciplina para encontrar a menor coisa possível e decidir lançá-la sem se dispersar. Ainda assim, vale a pena praticar
É o princípio de que, diante da incerteza, devemos nos concentrar na “próxima coisa certa a fazer” [0]
Não digo isso para trivializar a ideia. Descobrir qual é a próxima coisa certa a fazer é difícil e, na minha visão, é a parte mais valiosa do planejamento
0: https://en.wikipedia.org/wiki/The_Next_Right_Thing#Synopsis
Por exemplo, uma pessoa cria um método de comparação para testes, outra tenta uma abordagem, outra tenta outra abordagem, uma terceira tenta ainda outra e, depois de um período definido, todos avaliam os resultados
Claro que isso só faz sentido quando ainda não há uma abordagem preferida ou claramente superior
No desenvolvimento real, a modularização pode ser uma forma de paralelização. Cada pessoa ou equipe fica responsável por um componente
No meu trabalho, especialmente quando ainda estou entendendo a direção, gosto de alternar entre a parte voltada às pessoas e os interiores técnicos. Se você desenvolve apenas a tecnologia sem conhecer o uso, acaba forçando as formas de uso em uma certa direção; e também há armadilhas em projetar só a interface sem conhecer a tecnologia
Mas, em trabalhos que exigem experimentação criativa e prova de conceito para validar algo que não pode ser conhecido de antemão, como pesquisa, a própria decomposição do trabalho desmorona
Por isso criei o hábito de fazer a maior parte do trabalho de prova de conceito em privado, sem contar a ninguém
Se der certo, posso divulgar; se não der, posso descartar e seguir em frente sem passar vergonha nem ouvir que devo dar um jeito de fazer funcionar mesmo depois de confirmar que não devo continuar
Basta dizer: “vamos gastar 3 horas investigando X, 3 horas em Y e 3 horas em Z, e depois fazer uma reunião de planejamento para decidir o que vem em seguida”
Há quatro resultados: o primeiro resolve, o segundo resolve, o terceiro resolve, ou nenhum resolve
Se for um problema que pode ser resolvido com um pouco de esforço, a probabilidade de resolvê-lo na segunda tentativa, isto é, em até 6 horas, é de 50%
E, em algum momento, é simplesmente preciso fazer
Decompor e estimar trabalho são quase a mesma coisa. Depois que a decomposição termina, alguém com alguns anos de experiência já tem estimativas-padrão para tarefas pequenas, então leva apenas alguns minutos para atribuir estimativas a cada pedaço
No meu caso, divido o trabalho em blocos que consigo estimar e peço a opinião de outras pessoas sobre as partes que não consigo estimar
Mas não acho que o verdadeiro caminho para a maestria seja a decomposição do trabalho. Qualquer pessoa consegue criar uma decomposição ruim
A verdadeira maestria está em perceber quando as evidências mostram que aquela decomposição do trabalho está errada a ponto de causar problemas, e em comunicar isso ou reestimar [0]
Também é importante aceitar com tranquilidade que isso vai acontecer, para não se estressar ao apresentar desde o início um cronograma com grande chance de mudar
Gestores normalmente querem um roadmap preciso desde o começo, mas isso é pedir o impossível. A boa gestão está na flexibilidade e em entender que, com o tempo, à medida que os desenvolvedores aprendem, a natureza do trabalho esperado muda
O pequeno exemplo no fim do texto também vale a reflexão. Mesmo que alguém tivesse dado uma estimativa precisa, ou seja, “isso termina em alguns jantares durante viagens de avião”, ele teria recusado por considerar arriscado demais
Isso mostra que estimativa não é apenas uma questão de precisão. Há muitos elementos que não aparecem totalmente em palavras como gestão de riscos, gestão de expectativas e familiaridade com o trabalho
[0] https://jacobian.org/2021/jun/8/incorrect-estimates/ - Também há um texto sobre esse tema
Eles são bons profissionais de software iniciantes, mas às vezes a área é nova e eles realmente não sabem como construir funcionalidades básicas. Pela minha experiência, eles querem tarefas com as quais possam aprender e se sair bem, e isso leva ao crescimento
O que é indispensável lembrar é que o custo do processo é um contínuo que deve ser ajustado à equipe. Jogadores da NBA não aprendem a arremessar durante o huddle no meio do jogo, mas crianças do 3º ano do fundamental aprendem
O planejamento e o coaching dos dois métodos são adequados quando combinam com cada equipe
Talvez essa seja a verdade central da engenharia de software. Talvez já exista uma versão open source do app Streak que o autor quer criar, e ele esteja reinventando a roda
O cérebro parece não gostar de listas de tarefas. Criar listas pode ser divertido, mas a maior parte de empreender ou programar é exploração
E listas de tarefas impedem a exploração
Se não, o que há de diferente no desenvolvimento de software para que, na nossa profissão, “não sei” seja uma resposta razoável?
Às vezes isso é correto, às vezes não. “O mapa não é o território”
Para dividir o trabalho em tarefas menores, é preciso fazer trabalho duplicado, e o truque é minimizar isso
Se você tentar não fazer nenhum trabalho desnecessário, acaba tendo que fazer tudo de uma vez
Por exemplo, digamos que você vá refatorar um programa com os módulos A e B, em que B depende de A. O método com menos desperdício é refatorar os dois módulos juntos. Mas esse também é o mais arriscado e o mais difícil de estimar
A forma como foi dividido foi: refatorar A e ajustar B para funcionar com o A refatorado. Depois, se A for refatorado de novo, há o risco de aquele trabalho de adaptação feito antes ser rapidamente descartado
Se você quiser reduzir a zero o trabalho que será jogado fora, muitas vezes não dá para dividir a tarefa. Mesmo com 20 anos de experiência, ainda hesito com frequência em fazer trabalho temporário que será descartado só para conseguir dividir o trabalho
Em vez disso, acabo trabalhando em algo de algumas semanas e raspando todos os pelos do iaque que deixei para trás, sem deixar nenhum
Faz sentido pensar no problema que se quer resolver antes de começar, e marcos aproximados também são importantes. Mas, na maioria das vezes, há incógnitas desconhecidas demais, então decompor tudo completamente é totalmente inútil ou impossível
Sinto que teria terminado muito mais rápido se tivesse usado o tempo gasto para decompor o projeto apenas para encontrar ou construir a solução. Pelo menos é essa a sensação
Eu normalmente abordo de outro jeito. A ideia é estimar o esforço necessário para decidir se vale a pena construir aquilo ou não. Em outras palavras, o primeiro motivo é ajudar em uma avaliação de custo-benefício
Também pode ser muito útil para a equipe. Especialmente ao trabalhar com pessoas menos experientes, dá para dividir bastante o trabalho e paralelizar
Imagino que Jacob também não tenha feito tanta decomposição assim ao implementar o próprio app Streak, e por isso tenha usado exemplos recursivos para explicar
Nesses momentos, dividir em tarefas menores e concluir uma de cada vez foi útil. Assim, mesmo quando você está travado ou sem vontade de trabalhar, surge algum progresso, e esse progresso cria impulso para continuar
Também há claramente valor em os gerentes conseguirem estimar a velocidade. O problema é que, depois que pegam gosto por isso, passam a realmente não entender quando alguém diz “não tenho certeza”
Eu também sou consultor, então, mesmo que trabalhemos de forma “ágil”, é muito importante dizer “entregaremos isto dentro deste prazo”