El producto entero, o la parte que lo bloquea.
Un producto llevado desde un planteamiento del problema hasta un software en funcionamiento que alguien opera: alcance y arquitectura antes del código, y luego la interfaz, los servicios detrás de ella, las integraciones, el camino de despliegue y la entrega. La persona que define el alcance sigue siendo responsable del desarrollo.
Los desarrollos que encajan.
Ser concreto sobre el encaje vale más que estar disponible para todo. Una empresa que dice sí a todo es una empresa a la que no puedes calibrar.
- Un producto que todavía no existe, donde lo difícil no es la interfaz y quieres un solo equipo responsable de todo.
- Un producto existente con un componente que bloquea al resto, donde la parte bloqueante llega por debajo de la capa de aplicación.
- Una reconstrucción donde el sistema actual se entiende lo bastante bien como para decir qué debe sobrevivirle.
- Software interno u operativo sobre el que de verdad funciona un negocio, y no una prueba de concepto.
- Un equipo que tiene la superficie resuelta y necesita que el backend, el modelo de datos y el camino de despliegue se construyan bien por debajo.
Dónde suelen fallar los desarrollos completos.
Casi nunca es la interfaz. Un desarrollo se tuerce en las costuras: el frontend asume una forma que el backend nunca prometió, una integración se comporta en producción de otro modo que en el entorno de pruebas, un modelo de datos que era correcto para la primera funcionalidad se vuelve en silencio incorrecto para la cuarta, y nadie lo nota hasta que el cambio que lo necesita ya va tarde.
El segundo fallo es la responsabilidad. Reparte un producto entre un proveedor de diseño, un estudio de apps y quien administra la infraestructura, y cada problema difícil cae en el hueco entre dos contratos. La parte que no es trabajo de nadie es, invariablemente, la que decide si la cosa funciona.
El tercero es la entrega. Un sistema que solo sus autores saben operar no está terminado: está alquilado. Lo que separa un desarrollo que es tuyo de uno con el que te quedas atascado es si el razonamiento vino con él: las decisiones, las alternativas descartadas y el procedimiento para lo que hay que operar.
La pila, y dónde encaja esta categoría.
Un desarrollo completo llega a toda la escalera. Cuando un peldaño corresponde a la profundidad de otra categoría, el diagrama lo dice en lugar de absorberlo en silencio.
Una arquitectura de referencia, es decir, la forma sobre la que se diseña el trabajo y no un registro de sistemas entregados. Nombra capas y responsabilidades, nunca productos: lo que se ejecuta en una capa determinada es una decisión que se toma contigo durante el alcance, no aquí por adelantado.
- L5
Superficie de producto
Cobertura: A cargoLa interfaz y la aplicación frontend, construidas sobre estados reales y no sobre el camino feliz. Una maqueta sin sistema debajo es la oferta de otro.
- L4
Servicios y APIs
Cobertura: A cargoServicios backend y APIs, con las integraciones detrás, y las costuras hechas explícitas en lugar de asumidas por ambos lados a la vez.
- L3
Datos y estado
Cobertura: A cargoEl modelo de datos, pensado para la cuarta funcionalidad y no solo para la primera, porque es ahí donde se tuerce en silencio.
- L2
Modelos y agentes
Cobertura: ParcialConstruido donde el producto de verdad lo necesita. El trabajo de límites, recuperación de información y evaluación se define como IA y automatización.
- L1
Ejecución e infraestructura
Cobertura: ParcialUn camino de despliegue del commit al servicio en marcha, con una reversión que se ha ejercitado. La plataforma en sí es otra categoría.
- L0
La capa de debajo
Cobertura: ParcialSe llega a ella cuando la parte que bloquea el producto vive por debajo de la capa de aplicación, en lugar de detenerse en el límite de un proveedor.
Qué significan las marcas
- A cargo
- Esta categoría es responsable de la capa. Se diseña, se construye y se entrega dentro del encargo.
- Parcial
- El trabajo llega a la capa hasta donde lo necesita el desarrollo, y la profundidad aquí corresponde a una de las otras categorías.
- Fuera de alcance
- Deliberadamente fuera de esta categoría. La nota del peldaño dice adónde va el trabajo en su lugar.
Lo que produce el encargo.
Sistemas y documentos, no actividad. Cada elemento es algo que te quedas.
- Un alcance por escrito: el problema tal como se entiende, lo que se construirá y lo que no, las etapas y los criterios de aceptación de cada una.
- Una memoria de arquitectura con las decisiones, las alternativas consideradas y las condiciones que justificarían revisar una de ellas.
- La interfaz y la aplicación frontend, construidas sobre estados reales y no sobre el camino feliz.
- Servicios backend y APIs, con el modelo de datos y las integraciones detrás.
- Un camino de despliegue del commit al servicio en marcha, con una reversión ejercitada.
- Un runbook y un paquete de entrega: cómo operarlo, cómo falla y qué es manual a propósito.
A qué ya no estás expuesto.
Expresado como riesgo eliminado y no como beneficio obtenido, porque eso es lo que un comprador adquiere de verdad.
- Acordar una cifra antes de que nadie haya acordado qué es el trabajo, que es donde suelen fracasar los proyectos a precio fijo.
- Una costura entre proveedores donde el frontend culpa al backend y el problema difícil no es de ninguno.
- Heredar un sistema que nadie sabe explicar, donde cada cambio futuro empieza con arqueología.
- Un producto terminado que solo funciona mientras las personas que lo construyeron están disponibles.
- Descubrir durante un incidente que la vía de reversión era teórica.
Trabajo que rechazamos.
Es más barato para ambas partes leerlo ahora que descubrirlo tres semanas después de empezar a definir el alcance.
- Proyectos solo de diseño. La interfaz se construye aquí, pero una maqueta sin sistema debajo es la oferta de otro.
- Un precio fijo sobre un alcance que nadie ha escrito todavía. Definir el alcance va primero, y es trabajo de verdad.
- Ampliación de plantilla por horas sin un resultado definido, donde el encargo es un puesto y no un resultado.
- Una fecha límite que el alcance no puede sostener. Una fecha cumplida saltándose las partes que hacen que el sistema aguante no merece acordarse.
- Reconstrucciones donde el sistema existente no se entiende lo bastante bien como para decir qué debe sobrevivirle. Eso es descubrimiento, y se define como descubrimiento.
Con qué te quedas.
La prueba es si un ingeniero que no estuvo en el desarrollo puede retomar el sistema sin negociar.
El código fuente en tus repositorios
El código vive en tu organización desde el primer commit, no en la nuestra y copiado al final. Eres dueño del código y de la propiedad intelectual producida durante el encargo, y eso se dice en el documento del encargo en lugar de darse por supuesto.
La infraestructura en tus cuentas
Todo se ejecuta en cuentas que controlas, aprovisionadas como código para que un entorno pueda reconstruirse desde el código fuente y no recordarse de memoria. Revocar nuestro acceso es algo que puedes hacer sin pedirlo.
El razonamiento, escrito mientras ocurría
La memoria de arquitectura, las decisiones y las alternativas descartadas, registradas cuando estaban frescas y no reconstruidas al final. Es la parte que suele perderse, y la que abarata el siguiente cambio.
Un runbook para lo que hay que operar
Tareas rutinarias, modos de fallo y sus respuestas, dónde están los registros, qué es manual a propósito y las limitaciones conocidas. Escrito para alguien que no estuvo allí.
La evidencia detrás de esta página.
El desarrollo, los documentos y el proceso que describe esta página, cada uno en su propia página.
- ProyectoUna plataforma de contenido multiinquilinoUna superficie de producto leída como una clase de problema: un modelo de edición, y mantener la salida publicada de acuerdo con él.
- DocumentosEjemplos de entregablesEl alcance, la memoria de arquitectura, el runbook y el paquete de entrega, mostrados como los formatos que recibirías.
- ProcesoCómo se desarrolla un encargoDescubrimiento, alcance por escrito, hitos, aceptación y entrega, publicados antes de la primera llamada.
Empieza por la restricción.
Un brief corto basta para empezar: qué estás construyendo, quién lo opera, qué está bloqueado y qué contaría como terminado.