Kaizen Forge

Cómo trabajamos

Alcance cerrado,sin sorpresas a mitad de camino

Cómo convertimos un problema mal definido en un precio y un plazo cerrados, y qué necesitamos de ti para que esa fecha se sostenga.

Cómo planificamos una entrega

Seis etapas, de la primera conversación a la métrica en producción. Siempre sabes en cuál está el proyecto y qué recibes al final de cada una.

  1. S
    01

    Study: Entender

    Escuchamos y mapeamos el contexto antes de hablar de tecnología. Recibes el problema descrito en una página.

  2. P
    02

    Plan: Planificar

    Alcance, fases, criterios de aceptación y precio. Decides si seguir o parar.

  3. A
    03

    Assemble: Construir

    Ciclos cortos con progreso visible. Repositorio abierto desde el primer día.

  4. D
    04

    Demonstrate: Mostrar

    Ejercitas el flujo real, en tu entorno, antes del go-live.

  5. E
    05

    Endorse: Validar

    Revisión de calidad y seguridad, criterio por criterio.

  6. S
    06

    Ship & Sense: Entregar y medir

    Despliegue, documentación de operación y lectura de las métricas de éxito.

Cronograma previsto

Referencia de un proyecto de tamaño medio. El cronograma real, con fechas, sale en el plan de entrega al final de la inmersión.

  1. 01 Relevamiento y alineación técnica

    Alcance detallado, prototipos y decisiones de arquitectura.

    15 días
  2. 02 Desarrollo e integración

    Frontend, backend y APIs, con entregas que validas en cada ciclo.

    6 semanas
  3. 03 Pruebas y validación técnica

    Pruebas automatizadas, de integración y de punta a punta.

    2 semanas
  4. 04 Documentación y observabilidad

    Documentación de la solución, registros, métricas y alertas.

    1 semana
  5. 05 Entrega final y go-live

    Código, accesos y entorno en producción, con métricas en lectura.

    Hito final

Las fases se solapan: las pruebas empiezan junto con el desarrollo. Los plazos se fijan en contrato y solo cambian por una modificación de alcance que tú pidas.

Lo que recibes antes de decidir

La inmersión de alcance es corta, tiene precio fijo y termina con cuatro documentos. Si decides no seguir, son tuyos y puedes llevarlos a otro proveedor.

0101

Alcance cerrado

Lista numerada de lo que se construirá y lista explícita de lo que no. Es la segunda lista la que evita la discusión al final.

0202

Criterios de aceptación

Para cada elemento, la frase que define terminado de forma verificable. Sin adjetivos, sin interpretación.

0303

Plan de entrega

Fases, hitos y fechas, con lo que recibes en cada uno. Ningún intervalo entre pagos supera las seis semanas sin una entrega verificable.

0404

Precio cerrado

Importe total, condiciones de pago y la regla de cambio de alcance. El precio no cambia por dificultad técnica: ese riesgo es nuestro.

Lo que necesitamos de ti

La causa más común de retraso no es la dificultad técnica, es la espera. Levantamos estos puntos antes de cerrar el plazo y tratamos cada uno como una dependencia con responsable y fecha.

0101

Decisión y personas

Alguien con autoridad para aprobar alcance y aceptación, un punto focal técnico y disponibilidad acordada. Sin decisor, cada duda se convierte en reunión de comité.

0202

Accesos y credenciales

Cuenta de nube, repositorio y DNS a tu nombre. La infraestructura nace en tu cuenta y el código es tuyo desde el primer commit.

0303

Sistemas e integraciones

Para cada sistema: documentación, entorno de pruebas y un contacto técnico. Sin sandbox, la prueba ocurre en producción, y eso no lo hacemos.

0404

Datos

Muestra representativa para pruebas y regla de anonimización. Un sistema validado con tres registros inventados se rompe el primer día real.

0505

Entornos y cumplimiento

Quién paga la infraestructura, dónde validas antes del go-live y el encuadre de protección de datos del proyecto, que cambia arquitectura y registros.

0606

Después de la entrega

Quién opera el sistema, adónde van las alertas y cuándo ocurre el traspaso. Una alerta que no llega a nadie es adorno.

Cómo los pendientes moldean el plan

  • Sin ritual de clasificación: secuenciamos la entrega en torno a lo que existe. Lo que depende de un pendiente se mueve para después; lo que está listo, sube.

  • El cronograma siempre refleja la realidad, no el deseo original.

  • Cuando falta algo que solo tú puedes proveer y no se puede rodear, la fase afectada espera y la fecha se mueve con ella, previsto en contrato, sin penalización.

Las preguntas que hace todo fundador

¿Y si cambio de idea a mitad del proyecto?

Alcance cerrado no es alcance congelado. Pides el cambio por escrito, devolvemos el impacto en plazo y precio en un máximo de dos días hábiles, y eliges: aceptar, cambiarlo por un elemento equivalente que aún no hayamos empezado, o descartarlo. Cambiar no cuesta nada y es el camino más usado. Nada se construye antes de tu respuesta.

¿Y si os equivocáis en la estimación?

Va a pasar, y el precio no cambia: el riesgo de estimación es nuestro y está en el precio. Si el plazo se ve afectado, te enteras el día que nos enteramos, no la víspera del hito. Y proponemos recortar un elemento de bajo valor antes de proponer un retraso, la elección es tuya.

¿El código es realmente mío?

Sí, desde el primer commit, en tu repositorio y en tu cuenta de nube. Ningún componente propietario nuestro queda dentro de tu sistema. No nos necesitas para continuar, y es intencional: un proveedor que amarra al cliente por dependencia técnica no tiene que entregar calidad.

¿Y si un prerrequisito llega tarde?

Avisamos el día en que se vuelve riesgo, no el día en que se vuelve retraso. Proponemos un rodeo cuando existe, datos sintéticos en lugar de la muestra real, por ejemplo, y registramos el retrabajo que ese rodeo va a generar. Si es bloqueante y no hay rodeo, la fase se congela y la fecha se desplaza en la misma proporción.

¿Cerramos el alcance?

Treinta minutos, sin coste. Sales sabiendo si el problema merece resolverse, si merece resolverse con software y si somos las personas adecuadas.

Agendar una llamada