Empresa de software: sprints, tickets y horas facturables en el mismo lugar

Lunes, nueve de la mañana. El sprint del cliente A va por la mitad. El cliente B, cuyo sistema entregaste en marzo, llama porque la emisión de informes se ha detenido en producción. Y a final de mes el departamento financiero pide las horas de todo el mundo para facturar. Tres rutinas distintas, con ritmos distintos, y la tentación es montar tres herramientas: una para el desarrollo, otra para el soporte y una hoja de cálculo para las horas.

El resultado suele ser el mismo: información duplicada, un ticket urgente que nadie ve en el tablero del sprint y horas que se registran de memoria el viernes por la noche. Aquí tienes una forma de organizar las tres rutinas sin tres herramientas y sin mezclar lo que debe quedar separado.

Las tres rutinas y por qué no se mezclan

Rutina	Naturaleza	Ritmo	Pregunta que responde
Sprint	Trabajo planificado	Ciclos de una a dos semanas	¿Qué vamos a entregar en este ciclo?
Ticket en producción	Demanda que llega sin aviso	Cola continua, con plazo	¿Quién atiende y en cuánto tiempo?
Hora facturable	Registro de esfuerzo	Cierre mensual	¿Cuánto cobramos y a quién?

El sprint es previsible; el ticket, no. Si lo echas todo en la misma cola, lo urgente atropella lo planificado y el equipo nunca cierra un ciclo. Si lo separas en herramientas distintas, pierdes la visión de conjunto: nadie sabe cuánto del sprint se lo ha comido el soporte. El camino es mantener las tres rutinas diferenciadas y en el mismo lugar.

Rutina 1: el sprint

Para el desarrollo planificado, el ciclo sigue siendo el mejor instrumento: un backlog ordenado, un recorte para dos semanas, un burndown para ver pronto si va a apretar. El sprint en la Tasskee reúne tareas de uno o de varios proyectos, lo que importa a quien atiende a varios clientes a la vez, y usa la velocidad de los ciclos anteriores para planificar el siguiente.

Reserva capacidad para lo imprevisto

El error más común es planificar el sprint con el 100% de la capacidad y descubrir después que el soporte consume un 20%. Observa cuánto tiempo han tomado los tickets en las últimas semanas y deja esa porción fuera de la planificación. Un equipo que reserva capacidad para el soporte no tiene que reventar el sprint cada vez que un cliente llama.

Alcance cerrado, alcance abierto

En un proyecto de alcance cerrado, el sprint sirve para que el equipo se organice y para que el cliente haga seguimiento. En un contrato de bolsa de horas o de mantenimiento, el sprint se convierte en la forma de repartir las horas contratadas entre mejoras. En los dos casos vale la misma regla: lo que entra a mitad del ciclo exige sacar algo que ya estaba dentro.

Rutina 2: el ticket en producción

El ticket tiene una lógica propia: alguien lo reporta, alguien lo clasifica, alguien lo atiende, y existe un plazo. Lo que no debe ser es una tarea suelta en el tablero del sprint, compitiendo por atención con lo planificado.

Un diseño que funciona:

• Cola propia para tickets, con estados propios (nuevo, en análisis, esperando al cliente, en corrección, resuelto) y plazo por prioridad.
• Formulario público de apertura, para que el cliente describa el problema con los datos que necesitas: sistema, pasos para reproducirlo, urgencia. Menos "no funciona" y más información con la que se puede actuar.
• Regla de triaje. Cada día, una persona (puede ser por turnos) revisa la cola antes de las nueve y clasifica: ¿es un defecto, una duda o una mejora?
• El defecto grave entra en el ciclo; la mejora pasa al backlog. Un defecto crítico interrumpe el sprint, con un intercambio explícito. Una mejora pedida por ticket va al backlog y entra en la siguiente planificación.

La cola de tickets de la Tasskee tiene plazo y SLA por prioridad y el formulario de apertura público. Como ticket y tarea viven en el mismo sistema, el defecto que exige código se convierte en tarea de desarrollo sin copiar texto entre herramientas.

Rutina 3: la hora facturable

Aquí la regla es simple y dura: la hora que no se registra en el momento en que ocurre casi nunca se registra bien. Registrar el viernes por la noche lo que se hizo el martes es adivinar, y adivinar acaba en una discusión con el cliente.

El registro en el acto

El registro de horas tiene que estar en la propia tarea, a un clic de donde la persona está trabajando. Sin cambiar de herramienta, sin abrir una hoja de cálculo. Cada registro queda vinculado al proyecto y al tipo de trabajo, y eso es lo que permite facturar de forma diferente: desarrollo a un valor, soporte a otro, reunión a un tercero.

Valor por hora por proyecto y tipo

Una software house rara vez tiene un valor único. El contrato con el cliente A puede prever R$ 180 por hora de desarrollo y R$ 120 de soporte; el cliente B, una bolsa de 40 horas al mes. Con el control de horas de la Tasskee, el valor se define por proyecto y tipo, el cierre para el cliente sale en PDF o CSV, y la factura (nota fiscal) se registra ahí, aunque la emisión se siga haciendo en tu sistema fiscal, pues la Tasskee no emite facturas.

Quien cobra por hora

Si parte del equipo son freelancers que cobran por hora, el extracto de quien cobra y la pantalla "Mis horas" evitan la conversación de "¿cuántas horas hice exactamente?". Y como valor y coste tienen permisos separados, quien registra horas no necesita ver cuánto paga el cliente.

Cómo se conectan las tres

Las rutinas son distintas, pero comparten datos, y ahí es donde tenerlo todo en el mismo lugar se amortiza.

1. El ticket se convierte en tarea. El defecto clasificado entra en el sprint o en la cola del día, con referencia al ticket.
2. La tarea recibe horas. Quien trabaja en el defecto registra el tiempo allí mismo.
3. Las horas se convierten en factura. En el cierre, el informe separa lo que fue sprint, lo que fue soporte y lo que cubrió el contrato.
4. El sprint conoce el soporte. En la retrospectiva, la pregunta "¿cuánto del ciclo se fue en tickets?" tiene respuesta en horas, no en impresiones.

Un ejemplo de semana

Una software house de Florianópolis, con ocho personas y cuatro clientes. Lunes: planificación de un sprint de dos semanas para dos proyectos, con el 30% de la capacidad reservada para soporte. Martes: un cliente abre un ticket crítico por el formulario; la persona de guardia lo clasifica como defecto, lo convierte en tarea y lo trae al ciclo, sacando una mejora de baja prioridad. De miércoles a viernes: cada persona registra sus horas en las tareas, y el líder sigue el burndown. Último día laborable del mes: el departamento financiero exporta el cierre de cada cliente, con horas por tipo y valor, en lugar de recoger mensajes del equipo.

Qué cambia cuando ayuda un agente de IA

Una parte del trabajo de gestión en una software house es mantener actualizada la documentación de requisitos. En la Tasskee, las specs son documentos vinculados al proyecto y a las tareas, y pueden ser mantenidas por un agente de IA mediante el servidor MCP: el agente que escribe el código actualiza la spec, registra decisiones y sigue el progreso. Así, la especificación deja de ser un archivo que envejece en una carpeta y pasa a reflejar lo que se ha hecho, con las tareas vinculadas.

Errores que se repiten

• Soporte dentro del backlog del sprint, sin reserva. El ciclo se desborda cada quincena.
• Ticket sin responsable. Una cola sin triaje diario se convierte en un cementerio de solicitudes.
• Horas registradas en bloque. La cuenta llega al cliente sin credibilidad.
• Un valor único para todo. Desarrollo, soporte y reunión no cuestan lo mismo y no deberían cobrarse igual.
• Mezclar al equipo de guardia con el del sprint sin turnos. Una persona se convierte en el "soporte" para siempre, y es la que presenta la dimisión.

Indicadores que caben en una reunión mensual

Con las tres rutinas en el mismo sistema, la reunión mensual de gestión puede ser corta y basarse en cuatro números: cuánto del tiempo del equipo fue a sprint y cuánto a soporte; cuántos tickets se abrieron y cuánto tardaron en resolverse; cuántas horas se facturaron por cliente; y cuánto de lo planificado en los sprints se entregó de verdad. Los cuatro responden a preguntas distintas, pero juntos muestran si la casa es sostenible: si el soporte come más tiempo del planificado, es hora de revisar el contrato o de invertir en corregir la causa de los tickets repetidos.

Por dónde empezar

Elige una rutina cada vez. Si las horas son la mayor fuga, empieza por ellas: registro en la tarea y cierre mensual. Si el soporte estorba al desarrollo, empieza por la cola y la reserva de capacidad. Cuando las tres estén en un mismo lugar, la conversación del lunes por la mañana cambia: en lugar de apagar fuegos, el equipo sabe qué es lo planificado, qué es lo imprevisto y cuánto cuesta cada cosa.