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.
- S01
Study: Entender
Escuchamos y mapeamos el contexto antes de hablar de tecnología. Recibes el problema descrito en una página.
- P02
Plan: Planificar
Alcance, fases, criterios de aceptación y precio. Decides si seguir o parar.
- A03
Assemble: Construir
Ciclos cortos con progreso visible. Repositorio abierto desde el primer día.
- D04
Demonstrate: Mostrar
Ejercitas el flujo real, en tu entorno, antes del go-live.
- E05
Endorse: Validar
Revisión de calidad y seguridad, criterio por criterio.
- S06
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.
- 15 días
01 Relevamiento y alineación técnica
Alcance detallado, prototipos y decisiones de arquitectura.
- 6 semanas
02 Desarrollo e integración
Frontend, backend y APIs, con entregas que validas en cada ciclo.
- 2 semanas
03 Pruebas y validación técnica
Pruebas automatizadas, de integración y de punta a punta.
- 1 semana
04 Documentación y observabilidad
Documentación de la solución, registros, métricas y alertas.
- Hito final
05 Entrega final y go-live
Código, accesos y entorno en producción, con métricas en lectura.
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.
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.
Criterios de aceptación
Para cada elemento, la frase que define terminado de forma verificable. Sin adjetivos, sin interpretación.
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.
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.
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é.
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.
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.
Datos
Muestra representativa para pruebas y regla de anonimización. Un sistema validado con tres registros inventados se rompe el primer día real.
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.
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.
