Factory
Una aplicación exitosa depende de un sistema, no solo de código.
Hoy, que una aplicación tenga éxito depende menos de escribir código y más del sistema que la rodea: qué se decide antes de construir, quién responde por cada etapa y cómo se mantiene después. Factory reúne los modelos y checklists que uso para ordenar ese sistema.
Primero el alcance, después el código
Escribir el Brief y definir el PRD antes de la primera línea de código es, y debería ser, lo más importante de cualquier proyecto. Ahí se fijan los alcances: qué se construye, qué no y cómo se sabrá que está terminado.
- Paso 01 Brief Una o dos páginas: qué se quiere lograr, por qué y para quién. Alinea a todos y decide si vale la pena seguir.
- Paso 02 PRD El documento de requisitos: problema, usuarios, alcance, métricas y restricciones. Fija los límites antes de construir.
- Paso 03 Código Recién aquí se escribe la primera línea, con un alcance acordado contra el cual medir cada cambio.
El paso a paso completo, con quién aprueba cada etapa, está en DFDy.
Un factory abierto no escala
Un factory sin límites, donde cualquier pedido entra y cualquiera lo construye, genera tres problemas que aparecen tarde y cuestan caro.
- Continuidad Si el alcance no está escrito, cada persona nueva lo reinterpreta. El proyecto depende de la memoria de quien empezó.
- Mantenimiento Lo que se construye sin límites crece sin criterio. Cada funcionalidad extra es código que alguien tendrá que mantener.
- Responsabilidad Si nadie aprueba ni firma una etapa, nadie responde por ella cuando algo falla o cuando hay que decidir.
Por eso esta página restringe y delimita: Factory solo reúne modelos y checklists documentados que resuelven esos problemas desde el inicio. Para entrar, cada uno declara tres cosas:
- Qué etapa cubre
- Dónde empieza y dónde termina, y qué queda fuera de su alcance.
- Cómo se construye
- Los pasos, entregables o puntos que lo componen, con sus fuentes.
- Quién responde
- Quién aprueba, firma o se hace cargo de cada parte cuando llega una solicitud.
Qué reúne Factory
5 recursos en 4 categorías. No son lo mismo: un modelo de proceso dice cómo se trabaja, un modelo de calidad dice qué se mide y una checklist dice qué se revisa. Se complementan.
Modelos de proceso
Cómo se trabaja: etapas, ciclos, roles y quién aprueba cada paso.
-
- Qué resuelve
- Gestionar cada etapa del desarrollo, del Brief a producción, sin saltarse decisiones.
- Cómo se construye
- Un flujo paso a paso: Brief, PRD, ADR, SAD, HdU, pruebas, ARB y SSP, cada uno con entradas, salidas y criterio de término.
- Quién responde
- Cada etapa declara quién la aprueba; el cliente firma el Brief, el PRD, las HdU y la UAT.
-
- Qué resuelve
- Construir en ciclos cortos con retroalimentación constante, sin perder calidad.
- Cómo se construye
- Ciclos trimestral, semanal y diario: historias, planificación, pareja con TDD, integración continua y releases pequeños.
- Quién responde
- El cliente define y acepta las historias; el equipo responde por el código y la build.
Modelos de calidad
Qué se mide de un producto para decir que tiene calidad, con requisitos verificables.
-
- Qué resuelve
- Describir la calidad esperada con requisitos medibles, no con adjetivos.
- Cómo se construye
- Nueve características de calidad, sus subcaracterísticas y ejemplos de requisitos medibles.
- Quién responde
- Quien escribe los requisitos no funcionales y quien los verifica en las pruebas.
Checklists
Puntos concretos que se revisan uno a uno mientras se construye y se opera.
-
- Qué resuelve
- Que el sitio sea rápido y se mantenga rápido en el tiempo.
- Cómo se construye
- 31 puntos en seis capas: frontend, red, API, backend, base de datos, y medición y arquitectura.
- Quién responde
- El equipo que construye cada capa y quien mide el rendimiento en producción.
Cumplimiento
El piso legal y técnico que se exige antes de salir a producción.
-
- Qué resuelve
- Salir a producción con el piso legal y técnico cubierto.
- Cómo se construye
- Checklist por áreas: HTTPS, seguridad, privacidad, legal, accesibilidad, SEO y operación.
- Quién responde
- Quien publica el sitio, que responde por cada punto ante usuarios y autoridades.
Qué etapa cubre cada recurso
Ninguno cubre todo el proyecto. Combinados, dejan cada etapa con al menos un responsable.
| Recurso | Definir | Construir | Lanzar | Operar |
|---|---|---|---|---|
| DFDy: Design-First Delivery | Cubre | Cubre | Cubre | No cubre |
| XP: Extreme Programming | No cubre | Cubre | Cubre | No cubre |
| ISO/IEC 25010 | Cubre | Cubre | No cubre | No cubre |
| Tu web optimizada | No cubre | Cubre | No cubre | Cubre |
| Cumplimiento mínimo | No cubre | No cubre | Cubre | Cubre |
- Definir Antes de escribir código: qué, por qué y hasta dónde.
- Construir Diseño, desarrollo y pruebas dentro del alcance definido.
- Lanzar Aprobaciones y requisitos para salir a producción.
- Operar Medir, mantener y responder después del lanzamiento.
Lectura aparte
Antes de empezar: ¿conviene construir?
No es un modelo ni una checklist: es una guía para decidir si vale la pena tener software propio.