Proyecto y apps
Sprints de dos semanas
Hay alcance cerrado y fecha comprometida: el trabajo se planifica en bloques y se demuestra en ciclos.
Planificación y demo cada 2 semanas
Todo cliente pide dos cosas que sobre el papel no caben juntas: precio cerrado y poder cambiar de opinión. Aquí está, paso a paso, cómo las hacemos convivir.
«Bienvenidos los cambios de requisitos, incluso tarde.»
Nadie conoce del todo un sistema hasta que lo usa.
«Esto se construye, en este plazo y por este precio.»
Nadie aprueba una orden de compra que diga "lo que vaya saliendo".
Caben las dos si se separan: el contrato fija QUÉ se construye; el sprint decide EN QUÉ ORDEN y CÓMO. Dentro del alcance repriorizas cuantas veces quieras, sin costo. Lo que sale del alcance tiene una puerta, y está en la tabla de más abajo.
Cinco fases. Ninguna empieza sin que la anterior te haya entregado algo en la mano.
Reuniones con quien conoce la operación. Qué tiene que hacer el sistema, con qué se integra y qué queda fuera. Se puede contratar sola.
Recibes Alcance, cronograma y precio cerrado.
Se firma el alcance y se monta lo necesario: repositorios a tu nombre, entornos, accesos y el tablero donde verás el avance.
Recibes Accesos, tablero y primer sprint planificado.
Sprints de dos semanas. Cada uno abre con una planificación donde tú priorizas y cierra con software funcionando, no con diapositivas.
Recibes Cada dos semanas: incremento probado y desplegado.
Un sprint entero sin funcionalidad nueva: pruebas con datos reales, carga si hace falta y corrección. Va planificado desde el principio.
Recibes Sistema probado y lista de defectos cerrada.
Puesta en producción acompañada, capacitación y traspaso técnico a quien lo vaya a mantener, seamos nosotros o no.
Recibes Producción, documentación, accesos y 30 días de garantía.
Siempre igual, para que sepas qué esperar y cuándo. Tres momentos contigo en diez días laborables; el resto es construcción con el tablero abierto.
Construcción. El tablero está abierto y al día: puedes mirar cuando quieras sin pedirle un informe a nadie.
Tú priorizas, el equipo estima. Sale la lista cerrada de estas dos semanas.
Tu responsable + el equipo
Solo para bloqueos que dependen de tu lado. Si no hay ninguno, se cancela.
Tu responsable + líder técnico
Funcionando, en un entorno donde puedes entrar después. Y el acta el mismo día: qué se terminó, qué no y qué entra en el siguiente.
A quien quieras invitar
La regla que lo sostiene: una vez empezado, el alcance del sprint no cambia. Lo urgente entra al siguiente — o se para el sprint de forma explícita, que es decisión tuya y queda registrada.
Siempre cambia algo. Lo que separa un proyecto que acaba bien de uno que acaba en reclamo no es cuántos cambios hubo, sino si estaba acordado de antemano qué hacer con ellos. Busca tu caso en la tabla.
| Tipo de cambio | Ejemplo | Cómo se trata | Quién decide | Impacto |
|---|---|---|---|---|
| Reordenar prioridades | «Los reportes urgen más que la configuración.» | Se reordena en la siguiente planificación. Sin trámite: es el uso normal del proceso. | Tú, en la planificación | No mueve nada |
| Detalle de ejecución | «Ese listado va mejor con los filtros arriba.» | Se ajusta dentro del sprint. El alcance dice qué hace la pantalla, no cómo se dibuja. | Tú y el equipo, en la demo | No mueve nada |
| Defecto en lo entregado | «El cálculo no cuadra en un caso concreto.» | Entra al sprint en curso con prioridad. No es un cambio: no cumple lo acordado. | Nosotros, sin consultar | Sin costo, en garantía |
| Alcance nuevo | «Además queremos facturación electrónica.» | Solicitud formal. Se estima en 48 h hábiles con su impacto en precio y fecha. No se toca hasta que la apruebes. | Tú, por escrito | Cotización aparte |
| Alcance que se retira | «El módulo de inventario ya no hace falta.» | Sale del plan y su importe queda a favor: se descuenta o se cambia por alcance nuevo. Tú eliges. | Tú, por escrito | Baja o compensa |
| Cambio en tu lado | «Cambiaron el sistema con el que había que integrarse.» | Se evalúa y se replanifica juntos. No se penaliza, pero la fecha nueva queda por escrito el mismo día. | Ambas partes | Puede mover la fecha |
Ningún cambio se ejecuta sin aprobación escrita. Tampoco se absorbe en silencio "para no molestar": así es como una fecha se descubre incumplida el día de la entrega.
Aquí no seguimos el manual, y es a propósito: forzar sprints donde no encajan produce reuniones vacías que todos se saltan a la tercera semana.
Sprints de dos semanas
Hay alcance cerrado y fecha comprometida: el trabajo se planifica en bloques y se demuestra en ciclos.
Planificación y demo cada 2 semanas
Flujo continuo con prioridades
El trabajo llega cuando llega: una urgencia de producción no espera al lunes. Cola priorizada con límite de trabajo en curso.
Revisión de cola semanal o quincenal
Si no se acuerda antes, "terminado" acaba significando cosas distintas para cada lado — y eso se descubre siempre el día de la entrega. Estas cinco se cumplen o la tarea no se marca como hecha.
Cuatro cosas, y ninguna cuesta dinero. Pero si faltan, el ritmo se cae: esto funciona con las dos partes dentro.
Con autoridad para priorizar y aprobar, no solo para transmitir. Si cada decisión sube dos niveles y vuelve, el sprint se queda esperando.
Solo a lo que tiene el trabajo detenido. Lo planteamos por escrito y con la decisión ya formulada, para que responder sea rápido.
Entornos, credenciales y documentación de lo que hay que integrar. Es la causa número uno de retraso en el arranque.
45 minutos cada dos semanas. Es el único momento en que corregir el rumbo cuesta barato.
Se dice en la demo, con el motivo, y lo que quedó abierto entra primero en la planificación siguiente. No se maquilla ni se da por terminado a medias: un sprint que "cierra" con trabajo sin acabar destruye la única señal de avance fiable que tiene el proyecto. Si eso se repite dos sprints seguidos, la estimación estaba mal y lo hablamos, incluido qué significa para la fecha comprometida.
Sí, y es una de las razones de trabajar por etapas. Se cierra el sprint en curso, se entrega lo construido hasta ahí funcionando y documentado, y se liquida lo ejecutado. No hay penalidad por detener: lo que se paga es lo que se hizo. Como el código y la documentación son tuyos desde el inicio, puedes retomarlo con quien quieras.
No, y es a propósito. La reunión diaria es una herramienta de coordinación interna del equipo que construye; convertirla en una reunión con el cliente lo termina poniendo de jefe de proyecto, que no es lo que contrató. Tú tienes el tablero abierto todo el día, un punto de control opcional a mitad de sprint y una demo cada dos semanas. Si hace falta más contacto en un momento concreto, se acuerda para ese momento.
Se puede, y en dos casos lo recomendamos nosotros: cuando el alcance es genuinamente incierto —una exploración, una prueba de concepto— y en mantenimiento, donde el trabajo no se deja acotar de antemano. En un proyecto con alcance conocido preferimos el precio cerrado porque traslada a nosotros el riesgo de estimación, que es donde debe estar.
Se puede adaptar el ritmo, los formatos de reporte y las herramientas a lo que tu empresa ya use, mientras se mantengan las dos piezas que hacen que el compromiso de fecha signifique algo: alcance del sprint fijo una vez empezado, y cambios fuera de alcance por escrito. Todo lo demás es negociable.
Porque no se reporta con porcentajes. Un "60% avanzado" no es comprobable y por eso es el indicador favorito de los proyectos que van mal. Lo que se enseña cada dos semanas es software funcionando en un entorno donde entras tú, y el tablero está abierto en todo momento. Si algo no se puede demostrar, se cuenta como no empezado.
Escríbenos al WhatsApp y recibe una cotización gratis en menos de 24 horas. Sin compromiso, con alcance y precio por escrito.