Central de Produtividade Aumentada: Como Montar uma Fila Diária com Python e SQLite

Central de produtividade aumentada parece nome de dashboard caro vendido por gente que usa a palavra “sinergia” sem sentir vergonha. Mas aqui a ideia é mais pé no chão: um script local, auditável e sem firula que abre o dia dizendo o que merece sua atenção agora, antes que Slack, e-mail, issue tracker e abas aleatórias transformem sua manhã num rodízio de incêndios.

O problema real não é falta de aplicativo. É excesso de entrada. Você começa conferindo uma notificação, lembra de um pull request, vê uma tarefa antiga, abre o calendário, encontra um bug e, quando percebe, passou quarenta minutos “se organizando”. A central de produtividade aumentada deste artigo resolve esse buraco com Python, SQLite e uma regra brutalmente simples: capturar sinais, pontuar urgência e gerar uma fila diária que você consegue defender tecnicamente.

Não é uma lista genérica de hábitos. É uma implementação. Pequena o suficiente para entender, útil o bastante para virar rotina e irritante o suficiente para expor quando você está usando organização como procrastinação com crachá.

O sintoma: você não escolhe prioridade, você reage

Todo ambiente técnico tem entradas demais: alertas, tarefas, conversas, deploys, bugs, lembretes e aquele “rapidinho” que nunca é rapidinho. O cérebro tenta resolver isso com sensação. A tarefa que grita mais parece mais importante. O e-mail mais recente parece mais urgente. A pessoa mais insistente parece mais estratégica. Parabéns, você acabou de terceirizar sua agenda para o ruído.

Em Automação de Fluxo de Trabalho, eu mostrei um script para decidir prioridades. Aqui vamos um passo além: criar uma central persistente, com histórico e pontuação, para começar cada dia com uma fila operacional. A diferença é simples: em vez de “o que eu acho que devo fazer?”, a pergunta vira “o que os sinais acumulados indicam?”.

Arquitetura da central: menos SaaS, mais critério

A primeira decisão é não transformar produtividade em outro produto para administrar. A central roda localmente, guarda tudo em SQLite e recebe entradas em JSON. Isso permite plugar fontes depois sem reescrever a lógica: issues, calendário exportado, logs de erro, tarefas manuais, cron jobs, ou qualquer coisa que consiga cuspir texto estruturado.

A arquitetura mínima tem quatro peças:

• Coletor: recebe eventos brutos de fontes diferentes.
• Normalizador: converte tudo para o mesmo formato.
• Motor de prioridade: calcula pontuação com regras explícitas.
• Relatório diário: imprime uma fila curta, com motivo e próxima ação.

A parte importante é “motivo”. Uma central que só diz “faça isso” vira gerente ruim. Uma central boa explica: “esta tarefa subiu porque está bloqueando outra pessoa, vence hoje e tem impacto alto”. Essa explicação é o que impede você de brigar com o próprio sistema às 9h12 da manhã.

Modelo de dados: SQLite sem glamour, graças a Deus

SQLite é perfeito para esse tipo de automação porque não exige servidor, credencial, container, ritual de deploy nem vela aromática. Um arquivo resolve. E se quebrar, você copia, abre, inspeciona e segue a vida.

CREATE TABLE IF NOT EXISTS tasks (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  source TEXT NOT NULL,
  external_id TEXT,
  title TEXT NOT NULL,
  context TEXT,
  impact INTEGER DEFAULT 1,
  urgency INTEGER DEFAULT 1,
  effort INTEGER DEFAULT 3,
  blocked_by TEXT,
  due_at TEXT,
  status TEXT DEFAULT 'open',
  created_at TEXT DEFAULT CURRENT_TIMESTAMP,
  updated_at TEXT DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE IF NOT EXISTS daily_queue (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  task_id INTEGER NOT NULL,
  score REAL NOT NULL,
  reason TEXT NOT NULL,
  queue_date TEXT NOT NULL,
  FOREIGN KEY(task_id) REFERENCES tasks(id)
);

Impacto, urgência e esforço são inteiros porque produtividade não precisa começar com machine learning. Na verdade, começar com ML aqui é frequentemente um sinal de que você quer evitar escrever regras honestas. Use números simples primeiro. Se a regra manual já não funciona, o modelo estatístico só vai errar com mais convicção.

Entrada padrão: todo ruído vira evento

O segredo para não virar bagunça é padronizar a entrada. Cada fonte manda um evento com título, contexto, prazo e alguns atributos. Você pode preencher manualmente no começo. Depois automatiza.

{
  "source": "manual",
  "external_id": "deploy-cache-001",
  "title": "Corrigir invalidação de cache no deploy",
  "context": "Deploy de produção deixa usuários vendo versão antiga por até 20 minutos",
  "impact": 5,
  "urgency": 4,
  "effort": 2,
  "due_at": "2026-05-19T18:00:00-03:00"
}

Essa estrutura parece simples porque deve ser. Uma boa automação pessoal não nasce completa. Ela nasce pequena e confiável. Depois ganha integração com GitHub, e-mail, calendário, logs, monitoramento e o que mais estiver mordendo seu tornozelo.

Script de ingestão: colocando tarefas no banco

Vamos ao Python. O script abaixo lê um JSON da entrada padrão e faz upsert básico pelo par source + external_id. Em produção, eu criaria um índice único. Para o artigo, vou deixar explícito para ficar didático.

#!/usr/bin/env python3
import json
import sqlite3
import sys
from datetime import datetime, timezone

DB = "productivity.db"

schema = """
CREATE TABLE IF NOT EXISTS tasks (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  source TEXT NOT NULL,
  external_id TEXT,
  title TEXT NOT NULL,
  context TEXT,
  impact INTEGER DEFAULT 1,
  urgency INTEGER DEFAULT 1,
  effort INTEGER DEFAULT 3,
  blocked_by TEXT,
  due_at TEXT,
  status TEXT DEFAULT 'open',
  created_at TEXT DEFAULT CURRENT_TIMESTAMP,
  updated_at TEXT DEFAULT CURRENT_TIMESTAMP
);
"""

def main():
    payload = json.load(sys.stdin)
    now = datetime.now(timezone.utc).isoformat()

    with sqlite3.connect(DB) as conn:
        conn.execute(schema)
        existing = conn.execute(
            "SELECT id FROM tasks WHERE source = ? AND external_id = ?",
            (payload.get("source"), payload.get("external_id"))
        ).fetchone()

        fields = (
            payload.get("source", "manual"),
            payload.get("external_id"),
            payload["title"],
            payload.get("context"),
            int(payload.get("impact", 1)),
            int(payload.get("urgency", 1)),
            int(payload.get("effort", 3)),
            payload.get("blocked_by"),
            payload.get("due_at"),
            now,
        )

        if existing:
            conn.execute("""
                UPDATE tasks
                   SET source=?, external_id=?, title=?, context=?, impact=?, urgency=?,
                       effort=?, blocked_by=?, due_at=?, updated_at=?
                 WHERE id=?
            """, fields + (existing[0],))
        else:
            conn.execute("""
                INSERT INTO tasks
                (source, external_id, title, context, impact, urgency, effort, blocked_by, due_at, updated_at)
                VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
            """, fields)

if __name__ == "__main__":
    main()

Repare que não tem mágica. É proposital. Quando a automação influencia seu dia, você precisa conseguir auditar por que algo entrou, quando entrou e com qual peso. Se a ferramenta vira uma caixa-preta, você só trocou ansiedade humana por ansiedade algorítmica. Upgrade duvidoso.

Motor de prioridade: a regra que você consegue discutir

Agora vem a parte que separa uma central útil de um mural bonitinho. A pontuação precisa considerar impacto, urgência, esforço, prazo e bloqueios. Eu gosto de começar com esta fórmula:

score = (impact * 3) + (urgency * 2) + due_bonus - effort - blocked_penalty

Impacto vale mais que urgência porque nem tudo que é urgente merece dominar o dia. Esforço reduz a pontuação porque tarefas enormes precisam ser quebradas antes de entrar na fila. Prazo próximo sobe. Bloqueio reduz, a menos que a próxima ação seja destravar.

from datetime import datetime, timezone


def due_bonus(due_at):
    if not due_at:
        return 0
    due = datetime.fromisoformat(due_at.replace("Z", "+00:00"))
    now = datetime.now(timezone.utc)
    hours = (due - now).total_seconds() / 3600
    if hours < 0:
        return 8
    if hours <= 24:
        return 6
    if hours <= 72:
        return 3
    return 0


def score_task(task):
    blocked_penalty = 4 if task["blocked_by"] else 0
    return (
        task["impact"] * 3
        + task["urgency"] * 2
        + due_bonus(task["due_at"])
        - task["effort"]
        - blocked_penalty
    )

Essa fórmula não é universal. Ela é honesta. E isso basta para começar. Depois de uma semana, você ajusta pesos olhando o histórico: a central jogou coisa importante para baixo? Tarefas pequenas demais dominaram? Urgência falsa sequestrou a fila? A resposta está nos dados, não na culpa.

Box perrengue técnico: meu primeiro protótipo pontuava prazo vencido alto demais. Resultado: tarefas antigas e irrelevantes ficavam no topo todos os dias, como zumbis burocráticos. A correção foi adicionar uma regra de apodrecimento: se uma tarefa está vencida há mais de sete dias e ninguém morreu, ela precisa ser reavaliada, não promovida eternamente.

Gerando a fila diária sem virar refém dela

A fila diária deve ser curta. Cinco itens é um bom limite. Dez já começa a parecer ata de reunião. A central não deve listar tudo que existe; deve escolher o que merece uma decisão hoje.

#!/usr/bin/env python3
import sqlite3
from datetime import date
from priority import score_task

DB = "productivity.db"
TODAY = date.today().isoformat()

with sqlite3.connect(DB) as conn:
    conn.row_factory = sqlite3.Row
    conn.execute("""
    CREATE TABLE IF NOT EXISTS daily_queue (
      id INTEGER PRIMARY KEY AUTOINCREMENT,
      task_id INTEGER NOT NULL,
      score REAL NOT NULL,
      reason TEXT NOT NULL,
      queue_date TEXT NOT NULL
    )
    """)

    tasks = conn.execute("""
        SELECT * FROM tasks
         WHERE status = 'open'
         ORDER BY updated_at DESC
    """).fetchall()

    ranked = []
    for task in tasks:
        item = dict(task)
        score = score_task(item)
        reason = f"impacto={item['impact']}, urgência={item['urgency']}, esforço={item['effort']}"
        ranked.append((score, item, reason))

    ranked.sort(reverse=True, key=lambda row: row[0])
    conn.execute("DELETE FROM daily_queue WHERE queue_date = ?", (TODAY,))

    for score, task, reason in ranked[:5]:
        conn.execute(
            "INSERT INTO daily_queue (task_id, score, reason, queue_date) VALUES (?, ?, ?, ?)",
            (task["id"], score, reason, TODAY)
        )
        print(f"{score:05.1f} | {task['title']} | {reason}")

A saída precisa ser lida em segundos. Se você precisa interpretar a ferramenta, ela falhou. O ideal é colocar isso num cron local, rodar no começo do dia e salvar o relatório em Markdown, Telegram, e-mail ou onde você realmente olha. Não onde você gostaria de olhar na versão fitness da sua personalidade.

Regra de ouro: próxima ação ou arquivamento

Toda tarefa que aparece na fila precisa terminar o dia em uma de três situações: concluída, quebrada em próxima ação ou arquivada. “Continuar depois” é o depósito clandestino da produtividade. Se algo voltou para a fila três dias seguidos, não é uma tarefa; é um problema mal definido usando bigode falso.

Adicione um comando simples para registrar decisão:

python decide.py --task 42 --status split --note "Criar teste reproduzindo cache antigo antes de mexer no deploy"

Esse tipo de log parece exagero até você perceber que ele reduz autoengano. Você não precisa lembrar por que adiou algo. Está registrado. E, se a justificativa for ruim, ela fica feia no arquivo. Excelente. Vergonha auditável é uma tecnologia subestimada.

Integrações úteis: Git, calendário e logs

Com a base funcionando, aí sim vale plugar fontes reais. Eu começaria por três:

• Git: branches paradas, pull requests sem revisão e commits locais antigos.
• Calendário: eventos nas próximas 48 horas que exigem preparo.
• Logs: erros recorrentes que ainda não viraram tarefa.

Se você já leu Idempotência em Automações, sabe a armadilha: integração que duplica tarefa vira spam com diploma. Use external_id estável. Um pull request deve atualizar a mesma tarefa, não criar uma nova todo dia. O mesmo vale para alertas de produção e eventos de calendário.

Anti-padrões: como destruir a central em uma tarde

Alguns erros aparecem rápido. O primeiro é tentar integrar tudo antes de usar manualmente por alguns dias. Isso cria uma fábrica de eventos sem semântica. Você terá muitos dados e pouca decisão. O segundo é permitir que qualquer tarefa entre com impacto máximo. Se tudo é prioridade cinco, nada é prioridade cinco. É matemática, não filosofia.

O terceiro erro é tratar a pontuação como ordem divina. A central recomenda; você decide. Se uma tarefa com score baixo precisa subir por contexto humano, suba e registre o motivo. Esse registro é ouro. Ele mostra onde a fórmula não enxerga bem.

O quarto erro é transformar o relatório diário em backlog. Backlog é inventário. Fila diária é compromisso operacional. Misturar os dois é como guardar ferramentas, contas vencidas e cebola na mesma gaveta. Tecnicamente possível, moralmente questionável.

Publicando o relatório onde você realmente age

Uma central de produtividade aumentada só funciona se aparece no fluxo certo. Para muita gente, terminal basta. Para outras, uma mensagem no Telegram às 8h30 resolve. O formato abaixo é simples e eficiente:

Bom dia. Fila técnica de hoje:

1. Corrigir invalidação de cache no deploy
   Score: 21 | Motivo: prazo < 24h, impacto alto, esforço baixo
   Próxima ação: criar teste reproduzindo cache antigo

2. Revisar PR de autenticação
   Score: 17 | Motivo: bloqueia outra pessoa
   Próxima ação: revisar migrations antes do almoço

Repare no detalhe: cada item tem próxima ação. Sem isso, você criou um mural motivacional para técnicos cansados. Bonito na parede, inútil no incidente.

Manutenção semanal: ajuste pesos, não sua autoestima

Depois de uma semana, rode uma revisão. Quantas tarefas da fila foram concluídas? Quantas voltaram? Quantas eram urgências falsas? Quais fontes geraram ruído? A central deve ficar mais chata e precisa com o tempo.

Eu recomendo uma rotina semanal com três perguntas:

• Que tipo de tarefa apareceu no topo e não deveria?
• Que tarefa importante ficou escondida?
• Qual regra evitaria essa distorção sem criar exceção demais?

Esse é o ponto em que a automação deixa de ser brinquedo e vira sistema. Não porque ela ficou complexa, mas porque passou a aprender com o seu uso. Sem palestra motivacional. Sem gráfico colorido fingindo que você é uma startup de si mesmo.

Conclusão: produtividade aumentada é reduzir negociação interna

A promessa da central de produtividade aumentada não é fazer você trabalhar mais. Isso seria deprimente e, convenhamos, bem fácil de vender. A promessa é reduzir a negociação interna: menos tempo decidindo onde começar, menos culpa por ignorar ruído e mais clareza sobre o que realmente move o dia.

O melhor sistema de produtividade não é o mais bonito. É o que você consegue auditar quando dá errado. Python, SQLite e regras explícitas entregam isso com uma elegância grosseira que eu respeito muito. Comece manual, pontue com honestidade, limite a fila e registre decisões. O resto é integração.

Se quiser continuar nessa linha, veja também a categoria Produtividade Aumentada e o artigo sobre fila de automação com SQLite, que combina perfeitamente com essa central.

CTA: qual automação você quer ver na próxima? Uma integração com GitHub, calendário, Telegram, logs de produção ou um modo “me salva de mim mesmo” para quando a fila começa a mentir bonito?