Gestión de Alcance y Tiempo · Serie 3 · Semana 1 · Tema 1.4
Un proyecto entrega un sistema. Funciona, cumple los requisitos, pasa las pruebas, se firma el acta. El equipo se disuelve.
Tres meses después, alguien de soporte descubre que para cambiar una tarifa hay que editar un archivo de configuración en el servidor, que no hay forma de ver qué usuario hizo qué, que el proceso de respaldo no existe y que la única persona que sabe reiniciar el servicio se fue con el proveedor.
Nada de eso es un defecto. El sistema hace exactamente lo que se pidió. El problema es lo que no se pidió, y tiene nombre: requisitos de operación.
Ya hablamos de cómo se recogen los requisitos y de los que impone el entorno de la organización. Faltan los que se refieren a la vida del producto después de que el proyecto termine.
Por qué se olvidan siempre
Por una razón estructural, no por descuido: quien especifica no es quien opera.
El área usuaria describe lo que necesita hacer con el sistema. El patrocinador describe el beneficio. Ninguno de los dos va a estar a las once de la noche intentando averiguar por qué un proceso se quedó colgado. La persona que sí va a estar ahí no suele participar en la fase de requisitos, porque «no es usuaria».
El resultado es previsible: el proyecto optimiza el día de la entrega y desatiende los mil días siguientes, que es donde vive el 90% del costo total del producto.
Las siete familias
1. Instalación y despliegue
Cómo se instala, cuánto tarda, si se puede hacer sin parar el servicio, y sobre todo: cómo se deshace. Un despliegue sin marcha atrás definida es un despliegue que nadie querrá hacer un viernes.
2. Configuración sin tocar código
Qué parámetros deben poder cambiarse en producción y por quién. Tarifas, plazos, textos, límites, destinatarios de avisos.
La pregunta que hay que hacer en la fase de requisitos: «de todo esto, ¿qué va a cambiar en los próximos dos años?». Todo lo que salga en esa respuesta y esté escrito en el código es una futura solicitud de cambio con su presupuesto.
3. Monitoreo y alertas
Cómo se sabe que el sistema está sano, y quién se entera cuando no lo está.
Un requisito de operación bien escrito aquí no dice «el sistema debe monitorearse». Dice qué se mide, cuál es el umbral y a quién le llega la alerta. Lo demás produce paneles bonitos que nadie mira.
4. Registro y trazabilidad
Qué queda registrado de cada operación relevante: quién, qué, cuándo, desde dónde. Es un requisito de operación y muchas veces también legal.
El momento en que se echa de menos siempre es el mismo: cuando hay una discrepancia y alguien pregunta quién cambió ese dato. Si no se pidió antes, no hay respuesta.
5. Respaldo y recuperación
Dos números que casi nunca se acuerdan y deberían estar en el documento de requisitos:
- Cuánta información puedes permitirte perder (medida en tiempo: una hora, un día).
- Cuánto puede estar caído el servicio antes de que el daño sea inaceptable.
De esos dos números sale toda la arquitectura de respaldo, y son decisiones de negocio, no técnicas. Preguntarlos es incómodo porque obliga al patrocinador a poner precio a algo que preferiría no cuantificar. Por eso hay que preguntarlos.
Y un tercero que se olvida: ¿alguien ha probado alguna vez la restauración? Un respaldo que nunca se restauró es una hipótesis.
6. Soporte y niveles de servicio
Quién atiende una incidencia, en qué horario, con qué tiempo de respuesta según la gravedad, y cómo se escala. Si el proyecto entrega un sistema y no entrega esto, la primera incidencia se resuelve improvisando.
7. Documentación de operación
No el manual de usuario: el manual de quien mantiene. Cómo arrancar y parar, qué hacer ante los errores conocidos, dónde están las contraseñas de servicio —gestionadas como corresponde, no en un documento—, qué depende de qué.
Es el entregable que más se recorta cuando el proyecto va tarde, y el que más caro sale haber recortado.
Caso práctico: el sistema que solo una persona sabía levantar
Escenario construido con patrones habituales; las cifras son ilustrativas.
Un proyecto de nueve meses entrega una plataforma interna. Todo correcto: funcionalidad completa, pruebas superadas, formación a usuarios impartida.
La plataforma la desarrolló un proveedor externo, cuyo contrato terminaba con la entrega. En el alcance figuraba «documentación técnica», y se entregó: ciento veinte páginas describiendo la arquitectura.
Lo que no figuraba en ninguna parte era el procedimiento de reinicio tras un corte de luz, que tenía un orden concreto: primero la base de datos, esperar a que terminara de recuperar, después el servicio de colas, después la aplicación. Hacerlo en otro orden dejaba la cola en un estado inconsistente.
Lo supieron a la mala, un domingo, con el sistema caído nueve horas y el proveedor sin obligación contractual de contestar el teléfono.
La documentación técnica existía. El procedimiento operativo no, porque nadie lo pidió. Y no se pidió porque la persona que lo necesitaba no estuvo en ninguna reunión de requisitos.
Cómo sacarlos antes de que sea tarde
La técnica que funciona es una entrevista corta con quien va a operar el sistema, con estas preguntas:
- ¿Cómo sabrás que esto está funcionando bien? ¿Y que dejó de hacerlo?
- Si falla a las tres de la madrugada, ¿quién se entera y cómo?
- ¿Qué tendrás que cambiar tú, sin pedirle nada a nadie?
- ¿Cuánta información podemos perder? ¿Cuánto tiempo puede estar caído?
- ¿Qué haces hoy cuando el sistema anterior se cae?
- Si te vas de vacaciones, ¿quién puede hacer tu trabajo con lo que hay escrito?
Media hora. Y hay que hacerla durante la fase de requisitos, no en la de pruebas, porque muchas de esas respuestas cambian el diseño.
Cómo se escriben
Igual que cualquier otro requisito: verificable. Comparemos.
| Mal escrito | Verificable |
|---|---|
| El sistema debe ser fácil de mantener | Un técnico sin conocimiento previo restaura el servicio siguiendo el manual en menos de 30 minutos |
| Debe tener respaldos | Respaldo diario; pérdida máxima aceptable 24 h; restauración probada trimestralmente |
| Debe estar monitoreado | Alerta al turno de guardia si el tiempo de respuesta supera 3 s durante 5 minutos |
| Debe ser configurable | Tarifas, plazos y textos de aviso se editan desde el panel de administración sin desplegar |
La columna derecha se puede probar antes de aceptar la entrega. La izquierda solo se puede discutir después.
Checklist antes de cerrar requisitos
- ¿Entrevistaste a quien va a operar el sistema, no solo a quien va a usarlo?
- ¿Están acordados los dos números: pérdida máxima de información y tiempo máximo de caída?
- ¿Existe un procedimiento de marcha atrás para el despliegue?
- ¿Qué parámetros deben cambiarse sin tocar código? ¿Está esa lista escrita?
- ¿La documentación de operación es un entregable con criterio de aceptación, o una buena intención?
- ¿Alguien va a probar una restauración antes de la entrega?
Para cerrar
Los requisitos de operación no compiten con los funcionales: los sostienen. Un sistema que hace todo lo que se pidió y no se puede mantener es un sistema que se va a sustituir antes de tiempo, y esa sustitución la pagará alguien que no estuvo en la decisión.
Preguntarlos cuesta media hora en la fase donde cambiar cuesta poco.
Te leo en los comentarios: de los sistemas que usas a diario, ¿cuál se nota que fue diseñado sin hablar con quien lo mantiene?
Referencias
- IIBA, BABOK Guide, sobre requisitos no funcionales y de transición.
- ISO/IEC 25010, características de calidad del producto software, incluida la mantenibilidad.
- Beyer, B. et al., Site Reliability Engineering, sobre objetivos de nivel de servicio.
- Project Management Institute, Guía del PMBOK, sobre transición del producto y cierre del proyecto.
← Anterior en la serie: Los requisitos que nadie te dice: factores ambientales de la organización
Siguiente en la serie: Requisitos de calidad: cómo convertir «que sea rápido» en algo verificable →
Este artículo forma parte de Gestión de Alcance y Tiempo, una serie de 52 artículos. Ver todos los de esta serie · Índice completo por materia.