[projeto em curso]
O “causo”
Uso um gerenciador de tarefas que eu mesmo programei. Segue as técnicas GTD e Pomodoro.
A base é uma lista de tarefas:
Conta com automações, dentre as quais, as tarefas vencidas hoje e não concluídas, são automaticamente remarcadas para amanhã.
Numa semana ruim, improdutiva, chega o dia no qual estou com mais de 70 pomodoros acumulados… impossível resolver num dia:
Cada pomodoro dura 30 minutos, logo, impossível 78 num dia! O ideal é que os pomodoros permaneçam entre 16 e 24.
Porém, o fato é que tenho 78 pomodoros pendentes, não vão ser feitos no mesmo dia, preciso de alguma priorização.
A ideia é desenvolver esse algoritmo.
As análises
As premissas
Nenhum sistema ou algoritmo será capaz de executar uma priorização perfeita.
Nem mesmo o humano é capaz de uma priorização perfeita. Experimente em qualquer lista de tarefas criar uma campo prioridade com três níveis pré-definidos: prioridade [(baixa)(normal)(alta)]. Em pouco tempo todas as tarefas da lista estarão como alta prioridade e todas atrasadas. Em maior ou menor grau, nós, humanos, somos assim.
Um caminho legal pode ser a “gameficação”, criar um sistema de pontos ganhos/perdidos, ranking, selos etc.
No meu sistema as tarefas seguem as premissas da GTD, podendo assumir as seguintes características quanto ao prazo:
- Padrão [tarefa com vencimento], precisa ser feita até aquela data;
- Agendada: precisa ser feita exatamente naquela data e hora;
- Um dia talvez: tarefas e ideias lançadas no sistema, sem prazo.
- Aguardando terceiro: tarefas que aguardam a ação de terceiro, podem assumir qualquer dos prazos anteriores
Neste ponto do desenvolvimento, percebo um erro conceitual no programa. Explico:
O método GTD tem o “aguardando terceiro” como um tipo de tarefa e OK, como conceito prático funciona bem, mas, na programação há uma falha conceitual: Enquanto as três primeiras se referem ao prazo para conclusão, o aguardando terceiro se refere a quem deve executar a tarefa, ou seja, tratam de elementos completamente diferentes.
Misturar elementos conceituais, prazo com quem deve executar a tarefa, não vai funcionar em termos de lógica booleana.
Grosso modo seria como mandar a máquina somar 10 com a cor azul (conceitos diferentes).
Então, será necessário consertar esse processo: incluir o “aguarda terceiro” como uma marca na tarefa e não como um tipo apartado (vai exigir uma extensa reprogramação …. sempre que se mudam conceitos, a intervenção no programa é severa e, por vezes, impossível).
[xxx a implantar]
Gameficação
[em estudo]
- Pontuação:
- Modelo teia [vide –>] https://www.youtube.com/watch?v=bc8R6W0uuvY&t
- Modelo contínuo –> os pontos por cada ação são sempre somados;
- Modelo status –> o jogador tem um status 100% e fica variando nesse entorno;
- Modelo pontos de experiência –> Tal como farcry;
Premiação [estudar]
Na prática:
No meu programa, quando a tarefa não é cumprida na data, a exemplo ontem, em rotina automatizada (que roda durante a madrugada) o vencimento é alterado para hoje, afinal, não é possível concluir tarefas ontem….
Incluí um novo campo “prioridade”, numérico, inteiro, com valor padrão 0 (zero). A cada vez que a rotina de remarcação passa, soma 1 nas tarefas remarcadas. Logo, quanto mais vezes a tarefa for remarcada, maior deve ser essa prioridade.
O algoritmo
- Selecionar todas as tarefas criadas pelo usuário;
- No sistema há dois campos relacionados: 3000_tarefas.codigo_pessoa, que identifica o responsável pela tarefa e 3000_tarefas.codigo_pessoa_criador, que identifica a pessoa que criou a tarefa. Não são necessariamente a mesma pessoa, visto que a tarefa pode ser sido criada para outro executar.
tarefas do tipo “um dia talvez“, ou quando alteradas para a forma “um dia talvez” devem ter seu campo “prioridade” atualizado para 0 (zero). [xxx a implementar].
As tarefas “agendadas” por suas características, devem ter como ordem de prioridade sua proximidade com o momento de execução. Não dever ter sua data ajustada pela rotina automatizada.
As tarefas padrão,
Deixe um comentário