Software house: sprints, pedidos e horas faturáveis no mesmo sítio

Segunda-feira, nove da manhã. O sprint do cliente A está a meio. O cliente B, cujo sistema entregou em março, telefona porque a emissão de relatórios parou em produção. E no fim do mês a contabilidade pede as horas de toda a gente para faturar. Três rotinas diferentes, com ritmos diferentes, e a tentação é montar três ferramentas: uma para o desenvolvimento, outra para o suporte, uma folha de cálculo para as horas.

O resultado costuma ser o mesmo: informação duplicada, um pedido urgente que ninguém vê no quadro do sprint e horas que são lançadas de memória à sexta-feira à noite. Aqui fica uma forma de organizar as três rotinas sem três ferramentas e sem misturar o que tem de ficar separado.

As três rotinas e porque não se misturam

Rotina	Natureza	Ritmo	Pergunta a que responde
Sprint	Trabalho planeado	Ciclos de uma a duas semanas	O que vamos entregar neste ciclo?
Pedido em produção	Procura que chega sem aviso	Fila contínua, com prazo	Quem atende, e em quanto tempo?
Hora faturável	Registo de esforço	Fecho mensal	Quanto cobramos e a quem?

O sprint é previsível; o pedido, não. Se meter tudo na mesma fila, o urgente atropela o planeado e a equipa nunca fecha um ciclo. Se separar em ferramentas diferentes, perde a visão do todo: ninguém sabe quanto do sprint foi consumido pelo suporte. O caminho é manter as três rotinas distintas e no mesmo lugar.

Rotina 1: o sprint

Para o desenvolvimento planeado, o ciclo continua a ser o melhor instrumento: um backlog ordenado, um recorte para duas semanas, um burndown para ver cedo se vai apertar. O sprint na Tasskee reúne tarefas de um ou de vários projetos, o que interessa a quem atende vários clientes ao mesmo tempo, e usa a velocidade dos ciclos anteriores para o planeamento do seguinte.

Reserve capacidade para o imprevisto

O erro mais comum é planear o sprint com 100% da capacidade e depois descobrir que o suporte consome 20%. Observe quanto tempo os pedidos ocuparam nas últimas semanas e deixe essa fatia fora do planeamento. Uma equipa que reserva capacidade para o suporte não precisa de rebentar o sprint de cada vez que um cliente telefona.

Âmbito fechado, âmbito aberto

Num projeto de âmbito fechado, o sprint serve para a equipa se organizar e para o cliente acompanhar. Num contrato de bolsa de horas ou de manutenção, o sprint passa a ser a forma de distribuir as horas contratadas por melhorias. Nos dois casos, vale a mesma regra: o que entra a meio do ciclo exige tirar algo que já lá estava.

Rotina 2: o pedido em produção

O pedido tem lógica própria: alguém reporta, alguém classifica, alguém atende, e existe um prazo. O que não deve ser é uma tarefa solta no quadro do sprint, a competir por atenção com o planeado.

Um desenho que funciona:

• Fila própria para pedidos, com estados próprios (novo, em análise, a aguardar cliente, em correção, resolvido) e prazo por prioridade.
• Formulário público de abertura, para o cliente descrever o problema com os dados de que precisa: sistema, passos para reproduzir, urgência. Menos "não está a funcionar" e mais informação sobre a qual se pode agir.
• Regra de triagem. Todos os dias, uma pessoa (pode ser por rotação) olha para a fila antes das nove e classifica: é um defeito, uma dúvida ou uma melhoria?
• Um defeito grave entra no ciclo; uma melhoria passa a backlog. Um defeito crítico interrompe o sprint, com troca explícita. Uma melhoria pedida por um pedido vai para o backlog e entra no planeamento seguinte.

A fila de pedidos da Tasskee tem prazo e SLA por prioridade e o formulário de abertura público. Como pedido e tarefa vivem no mesmo sistema, o defeito que exige código transforma-se em tarefa de desenvolvimento sem copiar texto entre ferramentas.

Rotina 3: a hora faturável

Aqui a regra é simples e dura: a hora que não é registada no momento em que acontece quase nunca é registada corretamente. Lançar à sexta à noite o que foi feito na terça é adivinhar, e adivinhar dá discussão com o cliente.

O registo no momento

O apontamento de horas tem de estar na própria tarefa, a um clique de onde a pessoa está a trabalhar. Sem mudar de ferramenta, sem abrir uma folha de cálculo. Cada lançamento fica ligado ao projeto e ao tipo de trabalho, e é isso que permite faturar de forma diferente: desenvolvimento a um valor, suporte a outro, reunião a um terceiro.

Valor por hora por projeto e tipo

Uma software house raramente tem um valor único. O contrato com o cliente A pode prever R$ 180 por hora de desenvolvimento e R$ 120 de suporte; o cliente B, uma bolsa de 40 horas por mês. Com o controlo de horas da Tasskee, o valor é definido por projeto e tipo, o fecho para o cliente sai em PDF ou CSV, e a nota fiscal é registada ali, embora a emissão continue a ser feita no seu sistema fiscal, pois a Tasskee não emite notas.

Quem recebe à hora

Se parte da equipa são freelancers pagos à hora, o extrato de quem recebe e o ecrã "As minhas horas" evitam a conversa do "quantas horas fiz afinal?". E como o valor e o custo têm permissões separadas, quem regista horas não precisa de ver quanto o cliente paga.

Como as três se ligam

As rotinas são distintas, mas partilham dados, e é aí que ter tudo no mesmo lugar compensa.

1. O pedido passa a tarefa. O defeito triado entra no sprint ou na fila do dia, com referência ao pedido.
2. A tarefa recebe horas. Quem trabalha no defeito lança o tempo ali mesmo.
3. As horas passam a fatura. No fecho, o relatório separa o que foi sprint, o que foi suporte e o que foi coberto por contrato.
4. O sprint sabe do suporte. Na retrospetiva, a pergunta "quanto do ciclo foi para pedidos?" tem resposta em horas, não em impressões.

Um exemplo de semana

Uma software house de Florianópolis, com oito pessoas e quatro clientes. Segunda: planeamento de um sprint de duas semanas para dois projetos, com 30% da capacidade reservada para suporte. Terça: um cliente abre um pedido crítico pelo formulário; a pessoa de prevenção classifica-o como defeito, converte-o em tarefa e puxa-o para o ciclo, tirando uma melhoria de baixa prioridade. De quarta a sexta: cada pessoa lança as suas horas nas tarefas, e o líder acompanha o burndown. Último dia útil do mês: a contabilidade exporta o fecho de cada cliente, com horas por tipo e valor, em vez de recolher mensagens da equipa.

O que muda quando um agente de IA ajuda

Uma parte do trabalho de gestão numa software house é manter a documentação de requisitos atualizada. Na Tasskee, as specs são documentos ligados ao projeto e às tarefas, e podem ser mantidas por um agente de IA através do servidor MCP: o agente que escreve o código atualiza a spec, regista decisões e acompanha o progresso. Assim, a especificação deixa de ser um ficheiro que envelhece numa pasta e passa a refletir o que foi feito, com as tarefas associadas.

Erros que se repetem

• Suporte dentro do backlog do sprint, sem reserva. O ciclo rebenta de quinze em quinze dias.
• Pedido sem dono. Uma fila sem triagem diária passa a ser um cemitério de pedidos.
• Horas lançadas em lote. A conta chega ao cliente sem credibilidade.
• Um valor único para tudo. Desenvolvimento, suporte e reunião não custam o mesmo e não deviam ser cobrados do mesmo modo.
• Misturar a equipa de prevenção com a equipa do sprint sem rotação. Uma pessoa passa a ser o "suporte" para sempre, e é a que se despede.

Indicadores que cabem numa reunião mensal

Com as três rotinas no mesmo sistema, a reunião mensal de gestão pode ser curta e baseada em quatro números: quanto do tempo da equipa foi para sprint e quanto para suporte; quantos pedidos foram abertos e quanto tempo demoraram a ser resolvidos; quantas horas foram faturadas por cliente; e quanto do que foi planeado nos sprints foi de facto entregue. Os quatro respondem a perguntas diferentes, mas juntos mostram se a casa é sustentável: se o suporte consome mais tempo do que o planeado, é altura de rever o contrato ou de investir na correção da causa dos pedidos repetidos.

Por onde começar

Escolha uma rotina de cada vez. Se as horas são a maior fuga, comece por elas: registo na tarefa e fecho mensal. Se o suporte atrapalha o desenvolvimento, comece pela fila e pela reserva de capacidade. Quando as três estiverem no mesmo lugar, a conversa de segunda-feira de manhã muda: em vez de apagar fogos, a equipa sabe o que é planeado, o que é imprevisto e quanto custa cada coisa.