Software house: sprints, chamados e horas faturáveis no mesmo lugar

Segunda-feira, nove da manhã. O sprint do cliente A está na metade. O cliente B, cujo sistema você entregou em março, liga porque a emissão de relatórios parou em produção. E no fim do mês o financeiro pede as horas de todo mundo 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 planilha para as horas.

O resultado costuma ser o mesmo: informação duplicada, chamado urgente que ninguém vê no quadro do sprint e hora que é lançada de memória na sexta à noite. Aqui vai um jeito de organizar as três rotinas sem três ferramentas e sem misturar o que precisa ficar separado.

As três rotinas e por que não se misturam

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

Sprint é previsível; chamado, não. Se você joga tudo na mesma fila, o urgente atropela o planejado e o time nunca fecha um ciclo. Se separa em ferramentas diferentes, perde a visão do todo: ninguém sabe quanto do sprint foi comido por suporte. O caminho é manter as três rotinas distintas e no mesmo lugar.

Rotina 1: o sprint

Para o desenvolvimento planejado, o ciclo continua sendo 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 importa para quem atende vários clientes ao mesmo tempo, e usa a velocidade dos ciclos anteriores para o planejamento do seguinte.

Reserve capacidade para o imprevisto

O erro mais comum é planejar o sprint com 100% da capacidade e depois descobrir que o suporte consome 20%. Observe quanto tempo os chamados tomam nas últimas semanas e deixe essa fatia fora do planejamento. Um time que reserva capacidade para o suporte não precisa estourar o sprint toda vez que um cliente liga.

Escopo fechado, escopo aberto

Em projeto de escopo fechado, o sprint serve para o time se organizar e para o cliente acompanhar. Em contrato de banco de horas ou de sustentação, o sprint vira a forma de distribuir as horas contratadas entre melhorias. Nos dois casos, vale a mesma regra: o que entra no meio do ciclo exige tirar algo que já estava dentro.

Rotina 2: o chamado em produção

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

Um desenho que funciona:

• Fila própria para chamados, com status próprios (novo, em análise, aguardando cliente, em correção, resolvido) e prazo por prioridade.
• Formulário público de abertura, para o cliente descrever o problema com os dados que você precisa: sistema, passos para reproduzir, urgência. Menos "não está funcionando" e mais informação que dá para agir.
• Regra de triagem. Todo dia, uma pessoa (pode ser rodízio) olha a fila antes das nove e classifica: é defeito, é dúvida ou é melhoria?
• Defeito grave entra no ciclo; melhoria vira backlog. Um defeito crítico interrompe o sprint, com troca explícita. Uma melhoria pedida por chamado vai para o backlog e entra no planejamento seguinte.

A fila de chamados da Tasskee tem prazo e SLA por prioridade e o formulário de abertura público. Como chamado e tarefa vivem no mesmo sistema, o defeito que exige código se transforma 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 é registrada na hora em que acontece quase nunca é registrada direito. Lançar na sexta à noite o que foi feito na terça é chute, e chute vira discussão com o cliente.

O registro no ato

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

Valor por hora por projeto e tipo

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, um banco de 40 horas por mês. Com o controle de horas da Tasskee, o valor é definido por projeto e tipo, o fechamento para o cliente sai em PDF ou CSV, e a nota fiscal é registrada ali, embora a emissão continue sendo feita no seu sistema fiscal, pois a Tasskee não emite nota.

Quem recebe por hora

Se parte do time é de freelancers pagos por hora, o extrato de quem recebe e a tela "Minhas horas" evitam a conversa de "quantas horas eu fiz mesmo?". E como valor e custo têm permissões separadas, quem registra horas não precisa ver o quanto o cliente paga.

Como as três se conectam

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

1. Chamado vira tarefa. O defeito triado entra no sprint ou na fila do dia, com referência ao chamado.
2. Tarefa recebe horas. Quem trabalha no defeito lança o tempo ali mesmo.
3. Horas viram fatura. No fechamento, 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 retrospectiva, a pergunta "quanto do ciclo foi para chamado?" tem resposta em horas, não em impressão.

Um exemplo de semana

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

O que muda quando um agente de IA ajuda

Uma parte do trabalho de gestão em software house é manter 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 por meio do servidor MCP: o agente que escreve o código atualiza a spec, registra decisões e acompanha o progresso. Assim, a especificação deixa de ser um arquivo que envelhece numa pasta e passa a refletir o que foi feito, com as tarefas vinculadas.

Erros que se repetem

• Suporte dentro do backlog do sprint, sem reserva. O ciclo estoura toda quinzena.
• Chamado sem dono. Fila sem triagem diária vira 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 igual e não deveriam ser cobrados igual.
• Misturar o time de plantão com o time do sprint sem rodízio. Uma pessoa vira o "suporte" para sempre, e ela é a que pede demissão.

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 do time foi para sprint e quanto para suporte; quantos chamados foram abertos e quanto tempo levaram para ser resolvidos; quantas horas foram faturadas por cliente; e quanto do que foi planejado nos sprints foi de fato entregue. Os quatro respondem a perguntas diferentes, mas juntos mostram se a casa está sustentável: se o suporte come mais tempo que o planejado, é hora de rever o contrato ou investir em corrigir a causa dos chamados repetidos.

Por onde começar

Escolha uma rotina de cada vez. Se as horas são o maior vazamento, comece por elas: registro na tarefa e fechamento mensal. Se o suporte atrapalha o desenvolvimento, comece pela fila e pela reserva de capacidade. Quando as três estiverem num mesmo lugar, a conversa de segunda de manhã muda: em vez de apagar incêndio, o time sabe o que é planejado, o que é imprevisto e quanto cada coisa custa.