El pliego de condiciones: qué debe contener para ser útil

Un pliego de condiciones enuncia lo que se espera de un proyecto o de un proveedor: la necesidad, el alcance, las restricciones y los criterios con los que se aceptará el resultado. Su función no es describir una solución —eso corresponde a la respuesta— sino definir el problema con la precisión suficiente para que dos proveedores distintos lo entiendan igual y para que la aceptación pueda pronunciarse sin discusión.

Partir de la necesidad, no de la solución

El fallo más común es un pliego que ya contiene la solución: pantallas, tecnologías, una arquitectura elegida. Cierra la puerta a mejores respuestas, le devuelve el riesgo de diseño y hace indefendible la aceptación: no se puede rechazar una entrega que implementa exactamente lo que uno dibujó. Enuncie la necesidad de negocio, el proceso a servir y el efecto esperado; deje el «cómo» a la respuesta.

Qué debe contener

El contexto y el objetivo perseguido. El alcance funcional y, con igual claridad, lo que queda excluido. Los requisitos no funcionales: volumetría, rendimiento, disponibilidad, seguridad, accesibilidad, restricciones de alojamiento y de localización de los datos. Las interfaces con lo existente. Las restricciones de calendario y las fechas inamovibles. Los criterios de aceptación. Y la gobernanza: quién decide, quién acepta, con qué ritmo.

Todo requisito debe ser verificable

«La aplicación debe ser rápida» no puede aceptarse ni rechazarse. «Una búsqueda responde en menos de dos segundos para el 95 % de las consultas con 200 usuarios simultáneos» sí. La prueba es simple: para cada línea, pregunte qué mediría para decir que se cumple. Todo requisito que sobreviva sin respuesta pertenece o bien a la sección de contexto o bien a la papelera; conservarlo garantiza un litigio en la aceptación.

Lo excluido vale más que lo incluido

Lo que un pliego excluye protege al proyecto mucho más que lo que incluye. Nombrar lo que se deja fuera deliberadamente —el segundo país, la migración de los datos antiguos, la aplicación móvil— mata la ambigüedad que de otro modo reaparecería como expectativa no presupuestada al quinto mes. Es también la única manera de que una petición de cambio se reconozca como tal en lugar de absorberse en silencio.

Del pliego al proyecto en FoxPlan

En FoxPlan los requisitos viven como objetos del proyecto, cada uno enlazado con las tareas que lo implementan y con el entregable que se aceptará: la cobertura pasa a ser una lectura y no un cotejo manual. Lo excluido queda escrito junto a lo acordado, y el proyecto conserva una traza duradera de aquello a lo que se comprometió: el documento que hace corta una reunión de aceptación.