Gestión de proyectos, sprints y tickets para software house.
Cada cliente es un proyecto con backlog y sprint, el bug en producción entra como ticket con plazo, y las horas registradas se convierten en el cierre del mes. La especificación queda junto al código, mantenida por el agente de IA que tu equipo ya usa.
El día a día que reconoces
Una software house rara vez pierde por falta de código. Pierde en la frontera entre lo acordado, lo hecho y lo cobrado.
Cinco clientes, cinco herramientas
Un cliente exige su Jira, otro manda tareas por correo, otro por un grupo de WhatsApp. Para saber la carga real del equipo, alguien abre todo y suma a mano.
El bug en producción atropella el sprint
El ticket llega a mitad del ciclo, va directo al desarrollador y nadie lo registra. El sprint se desborda y el cliente nunca ve el coste de eso.
Hora trabajada que no se convierte en factura
El registro se deja para el viernes, se reconstruye de memoria y se pierden horas. En el cierre del mes la cuenta del cliente y la del equipo no cuadran.
La especificación envejece antes que el código
El documento escrito al comienzo del proyecto no sigue los cambios. Quien entra a mitad lee un texto que ya no describe el sistema.
Cada cliente se convierte en un proyecto, con sprint y backlog listos
La plantilla Desarrollo de software, del registro, ya nace con los frentes Producto y Calidad, sprint vinculado y los estados Backlog, En desarrollo, Revisión, Prueba, En aprobación y Completado. Ajustas los nombres y empiezas por un cliente.
- 1 Un proyecto por cliente o producto«App de pedidos · Distribuidora Aurora». Backlog, sprints, tickets y documentos del contrato quedan juntos, y el historial acompaña al cliente de un ciclo al siguiente.
- 2 Sprint con el backlog a la vistaPlanifica el ciclo, sigue el burndown y ve la velocidad real del equipo. Lo que no cupo vuelve al backlog, sin hojas de cálculo de por medio.
- 3 Ticket en producción, fuera del backlog de funcionalidadesLa solicitud del cliente entra por un formulario público o por la atención, en una cola propia con plazo. Puedes decidir si el bug entra en el sprint o espera al siguiente.
- 4 Revisión y pruebas como etapas de verdadLa tarea pasa por Revisión y Prueba antes de Completado, y el estado «En aprobación» retiene la entrega hasta que el responsable decide.
Lo que nadie más reúne en una sola herramienta
Tres cosas que suelen vivir en herramientas distintas: la hora que se cobra, la especificación que se sigue y la respuesta al cliente.
Horas facturables con valor por proyecto
Cada proyecto y tipo de trabajo tiene su valor por hora. El cierre sale para el cliente en PDF o CSV, con la factura registrada (Tasskee no emite facturas), y el margen aparece al final. Quien cobra por hora obtiene su propio extracto.
Specs mantenidas por el agente de IA, vía MCP
El agente de tu equipo, con la clave que tú mismo traes de tu proveedor, lee y actualiza la spec del proyecto por el servidor MCP. El responsable sigue el estado y el progreso, y las tareas nacen de los criterios de aceptación.
Portal para que el cliente haga seguimiento y apruebe
El cliente entra como invitado, ve lo que tú liberes, comenta y aprueba la entrega. No ocupa plaza de usuario, así que la cuenta no crece con cada patrocinador nuevo.
Las funciones que sostienen esto en el día a día
Tarea, cronograma, ticket, formulario y conversación son la misma base de datos. Lo que cambia en un lugar aparece en el otro, sin exportar nada.
Preguntas de quienes entregan software
¿Sustituye a Jira?
¿Cómo funcionan las specs con el agente de IA?
¿Se puede cobrar al cliente por hora y por proyecto?
¿Y el ticket del cliente con el sistema ya en producción?
¿Funciona con integración continua, repositorio y despliegue?
Empieza por el cliente que más informes pide
Crea la cuenta, abre un proyecto con su backlog y programa el próximo sprint. En una tarde ves si el cierre del mes pasa a salir solo.