Gestão de projetos, sprints e pedidos para software house.
Cada cliente é um projeto com backlog e sprint, o bug em produção entra como pedido com prazo, e as horas registadas transformam-se no fecho do mês. A especificação fica ao lado do código, mantida pelo agente de IA que a sua equipa já usa.
O dia a dia que reconhece
Uma software house raramente perde por falta de código. Perde na fronteira entre o que foi combinado, o que foi feito e o que foi cobrado.
Cinco clientes, cinco ferramentas
Um cliente exige o Jira dele, outro envia tarefas por e-mail, outro por grupo de WhatsApp. Para saber a carga real da equipa, alguém abre tudo e soma à mão.
O bug em produção atropela a sprint
O pedido chega a meio do ciclo, vai direto para o programador e ninguém o regista. A sprint rebenta e o cliente nunca vê o custo disso.
Hora trabalhada que não se transforma em fatura
O registo fica para sexta-feira, é reconstruído de memória e perde horas. No fecho do mês a conta do cliente e a da equipa não batem certo.
A especificação envelhece antes do código
O documento escrito no início do projeto não acompanha as alterações. Quem entra a meio lê um texto que já não descreve o sistema.
Cada cliente passa a ser um projeto, com sprint e backlog prontos
O modelo Desenvolvimento de software, do registo, já nasce com as frentes Produto e Qualidade, sprint ligada e os estados Backlog, Em desenvolvimento, Revisão, Teste, Em aprovação e Concluído. Ajusta os nomes e começa por um cliente.
- 1 Um projeto por cliente ou produto"App de pedidos · Distribuidora Aurora". Backlog, sprints, pedidos de suporte e documentos do contrato ficam juntos, e o histórico acompanha o cliente de um ciclo para o outro.
- 2 Sprint com o backlog à vistaPlaneie o ciclo, acompanhe o burndown e veja a velocidade real da equipa. O que não coube volta para o backlog, sem folhas de cálculo pelo meio.
- 3 Pedido em produção, fora do backlog de funcionalidadesO pedido do cliente entra por um formulário público ou pelo atendimento, numa fila própria com prazo. É possível decidir se o bug entra na sprint ou se espera pela seguinte.
- 4 Revisão e teste como fases a sérioA tarefa passa por Revisão e Teste antes de Concluído, e o estado "Em aprovação" segura a entrega até o responsável decidir.
O que mais ninguém junta numa só ferramenta
Três coisas que costumam viver em ferramentas diferentes: a hora que se cobra, a especificação que se segue e a resposta ao cliente.
Horas faturáveis com valor por projeto
Cada projeto e tipo de trabalho tem o seu valor por hora. O fecho sai para o cliente em PDF ou CSV, com a fatura registada (a Tasskee não emite faturas), e a margem aparece no fim. Quem recebe à hora ganha o seu próprio extrato.
Specs mantidas pelo agente de IA, via MCP
O agente da sua equipa, com a chave que o próprio traz do fornecedor, lê e atualiza a spec do projeto pelo servidor MCP. O gestor acompanha o estado e o progresso, e as tarefas nascem dos critérios de aceitação.
Portal para o cliente acompanhar e aprovar
O cliente entra como convidado, vê o que libertar, comenta e aprova a entrega. Não ocupa lugar de utilizador, por isso a conta não cresce a cada novo patrocinador.
As funcionalidades que sustentam isto no dia a dia
Tarefa, cronograma, pedido, formulário e conversa são a mesma base de dados. O que muda num sítio aparece no outro, sem exportar nada.
Perguntas de quem entrega software
Substitui o Jira?
Como funcionam as specs com o agente de IA?
É possível cobrar ao cliente por hora e por projeto?
E o pedido do cliente com o sistema já em produção?
Funciona com integração contínua, repositório e deploy?
Comece pelo cliente que mais pede relatórios
Crie a conta, abra um projeto com o respetivo backlog e registe a próxima sprint. Numa tarde fica a saber se o fecho do mês passa a sair sozinho.