Gestión de proyectos

Cómo redactar el pliego de condiciones de un proyecto de software o web

Por Codevista InnovationsPublicado el 12 de octubre de 20269 min de lectura

Un buen pliego de condiciones de software describe la necesidad, no la solución: quiénes son los usuarios, qué tienen que poder hacer, en qué condiciones se da por terminada una funcionalidad y con qué restricciones (seguridad, alojamiento, idiomas, presupuesto, plazos). Cabe en ocho apartados, desde los objetivos de negocio hasta la propiedad del código y el mantenimiento. Bien redactado, sirve de referencia común al cliente y al proveedor y, durante el proyecto, se prolonga en un backlog ágil.

¿Para qué sirve el pliego de condiciones de un proyecto web?

El pliego de condiciones traduce una necesidad de negocio en expectativas que un equipo de desarrollo puede entender. Para una dirección general o un departamento de sistemas (TI), es la herramienta que permite comparar ofertas, estimar un presupuesto realista y dirigir el proyecto sin malentendidos.

Protege al cliente: sin un documento de referencia, es difícil demostrar que falta una funcionalidad o que una entrega no es conforme. Y protege también al proveedor: un alcance por escrito pone límite a las peticiones que se añaden sin haberse presupuestado.

Cuando tenga el documento listo, nuestra guía para elegir una agencia de desarrollo en Casablanca detalla las preguntas que conviene plantear a los candidatos.

¿Qué estructura seguir al redactar un pliego de condiciones de software?

Este es un índice tipo, que conviene adaptar al tamaño del proyecto. Se parte del porqué antes del qué, y del qué antes del cómo.

1. Contexto y objetivos: la situación actual, el problema que hay que resolver y los indicadores de negocio que la propia empresa seguirá para valorar el resultado (tiempo de tramitación de un expediente, errores de introducción de datos, tareas que aún se hacen a mano).
2. Usuarios y perfiles (personas): quién utilizará la herramienta (clientes, comerciales, back-office, mandos), en qué dispositivo y en qué idioma.
3. Alcance funcional: las necesidades expresadas en historias de usuario, cada una con sus criterios de aceptación y su prioridad.
4. Requisitos no funcionales: rendimiento, seguridad, accesibilidad, alojamiento, idiomas.
5. Integraciones: ERP, CRM, correo, pasarela de pago en línea, inicio de sesión único (SSO), API de socios.
6. Datos y migración: los datos existentes que hay que recuperar, su calidad, los plazos de conservación y los datos personales afectados.
7. Restricciones, presupuesto y calendario: una horquilla presupuestaria, una fecha límite obligatoria o deseada, las restricciones normativas o internas.
8. Entregables, propiedad y mantenimiento: qué se entrega, a quién pertenecen el código y la propiedad intelectual, cómo se mantendrá el software.

Unas pocas páginas bien estructuradas valen más que un documento voluminoso que nadie relee. Adjunte como anexo maquetas y capturas de lo que ya existe.

Cómo describir las funcionalidades: historias de usuario y criterios de aceptación

El formato más eficaz es la historia de usuario: «Como [usuario], quiero [acción] para [beneficio]». Obliga a precisar quién tiene la necesidad y por qué.

Cada historia va acompañada de criterios de aceptación: condiciones verificables que permiten decir, sin discusión, si la funcionalidad está terminada. Por ejemplo, para una solicitud de vacaciones:

• el empleado ve su saldo de días antes de enviar la solicitud;
• el responsable recibe una notificación y puede aceptarla o rechazarla con un comentario;
• una solicitud que se solapa con un periodo ya aprobado se bloquea con un mensaje explícito.

Asigne una prioridad a cada historia, por ejemplo con el método MoSCoW (Must, Should, Could, Won't: imprescindible, importante, deseable, excluido de esta versión). Es lo que permitirá decidir qué se sacrifica si el presupuesto se ajusta y delimitar una primera versión realmente utilizable.

Requisitos no funcionales: seguridad, rendimiento, idiomas y alojamiento

A menudo se olvidan, y corregirlos después sale caro. Describa el nivel esperado, no una tecnología.

• Rendimiento: usuarios simultáneos previstos, tiempo de respuesta aceptable en las pantallas críticas, uso con red móvil.
• Seguridad: roles y permisos, autenticación, registro de las acciones sensibles, copias de seguridad y restauración. Pregunte también al proveedor cómo protege sus datos por su parte; una certificación ISO/IEC 27001 es un indicio de ello, como explica nuestro artículo sobre la seguridad de los datos en un proveedor.
• Datos personales: en Marruecos, su tratamiento está regulado por la ley 09-08 (loi 09-08). Los trámites ante la CNDP, la autoridad marroquí de protección de datos personales, corresponden al responsable del tratamiento, en principio la empresa cliente; precise qué debe aportar el proveedor para prepararlos (finalidades, categorías de datos, medidas de seguridad).
• Accesibilidad: contrastes, navegación con teclado, compatibilidad con lectores de pantalla; las pautas WCAG del W3C ofrecen un vocabulario común para fijar el nivel esperado.
• Alojamiento: nube o servidores propios, ubicación de los datos si viene impuesta (la transferencia de datos personales fuera de Marruecos también está regulada por la ley 09-08), entornos de pruebas de aceptación y de producción.
• Idiomas: francés, árabe, inglés e incluso amazigh. El árabe exige una interfaz de derecha a izquierda (RTL): maquetación en espejo, tipografía adaptada, campos que mezclan árabe y cifras. Si se prevé desde el principio, es una decisión de diseño; si se añade al final del proyecto, es todo un proyecto aparte.

Integraciones, datos y migración: la parte que se subestima

Un software de gestión rara vez funciona aislado. Para cada sistema que haya que conectar, indique qué debe intercambiar, en qué sentido y con qué frecuencia, quién es el interlocutor técnico y si existe documentación de la API y un entorno de pruebas. Una integración cuyo proveedor no responde puede bloquear un proyecto entero: más vale saberlo antes de firmar.

La recuperación de datos merece la misma atención. Enumere las fuentes (hojas de Excel, aplicación antigua, base de datos existente), estime con honestidad su calidad (duplicados, campos vacíos, formatos incoherentes) y diga quién se encarga de la limpieza. Prevea al menos una migración de ensayo en el entorno de pruebas antes del paso definitivo, y una solución de vuelta atrás si falla.

Presupuesto, plazos, entregables y propiedad del código

Muchas empresas dudan en indicar un presupuesto. Sin embargo, una horquilla presupuestaria permite a los proveedores proponer una solución adecuada en lugar de ofertas imposibles de comparar. Distinga también entre fecha límite obligatoria y fecha deseada.

El apartado de entregables debe despejar cualquier ambigüedad:

• entrega del código fuente en un repositorio cuyos accesos tenga la empresa;
• propiedad intelectual del código desarrollado para usted y condiciones de uso de los componentes reutilizados o de código abierto; no dé por hecho que pagar el desarrollo basta para ser su propietario: deje por escrito la cesión de derechos;
• documentación técnica, accesos a las cuentas de alojamiento y nombres de dominio a nombre de la empresa;
• condiciones de mantenimiento: correcciones, evoluciones, plazos de intervención, reversibilidad si cambia de proveedor.

Estas cláusulas son materia contractual: pida a un jurista que las revise en lugar de fiarse de una plantilla genérica.

Pliego cerrado o backlog ágil: ¿cómo combinar ambos?

El pliego «a precio cerrado», que congela todo el alcance, tranquiliza al departamento de compras, pero supone que todas las necesidades se conocen de antemano, algo que rara vez ocurre. Al contrario, un backlog sin marco escrito deja al cliente sin salvaguarda presupuestaria. La combinación que funciona:

1. fijar en el documento lo que no debe moverse: objetivos, usuarios, requisitos no funcionales, presupuesto, plazos, entregables y propiedad;
2. expresar el alcance funcional en historias de usuario priorizadas, que se convierten en el backlog inicial;
3. prever una fase de descubrimiento para afinar las historias prioritarias;
4. validar cada iteración en un entorno de pruebas de aceptación y resolver cada nueva petición sustituyendo una historia de menor prioridad.

Así trabaja Codevista Innovations en sus proyectos de desarrollo: una fase de descubrimiento y diseño (UX/UI) y, después, sprints de dos semanas con entregas periódicas en un entorno de staging para su validación. Si duda sobre cómo mantener vivo ese backlog, nuestra comparativa Scrum o Kanban le ayudará a elegir.

Por parte del cliente, la persona que dirige el proyecto tiene que controlar el alcance, los riesgos y las partes interesadas: son precisamente ámbitos que cubre la formación PMP®, que prepara para la certificación del PMI.

Los errores más frecuentes en el pliego de condiciones de una aplicación

• Describir una solución en lugar de una necesidad: «un botón de Excel arriba a la derecha» en vez de «Recursos Humanos tiene que poder explotar el historial con sus herramientas». El proveedor ya no puede proponer nada mejor.
• No priorizar: cuando todo es imprescindible, nada lo es, y el primer ajuste presupuestario se convierte en un conflicto.
• Olvidar los criterios de aceptación: la recepción se convierte en un debate de interpretación.
• Redactarlo en solitario: un documento escrito por el departamento de sistemas sin las áreas de negocio, o al revés, deja fuera parte de las restricciones.
• Quedarse en la puesta en producción: si el alojamiento, el mantenimiento y la reversibilidad no se prevén negro sobre blanco, el software entregado se convierte pronto en una dependencia que se sufre.

¿Quiere una mirada externa sobre su pliego de condiciones o enmarcar un futuro proyecto SaaS a medida? El equipo de Codevista Innovations en Casablanca puede comentarlo con usted: póngase en contacto con nosotros.

Preguntas frecuentes

¿Qué diferencia hay entre el pliego de condiciones funcional y el técnico?

El pliego de condiciones funcional describe lo que el software debe permitir hacer, para qué usuarios y con qué criterios de validación. El pliego técnico describe cómo realizarlo: arquitectura, tecnologías, modelo de datos, alojamiento. El cliente redacta el primero; el proveedor suele elaborar el segundo, que se valida con el departamento de sistemas.

¿Cuántas páginas debe tener el pliego de condiciones de una aplicación web?

No existe una extensión ideal: una herramienta interna sencilla cabe en unas pocas páginas; una plataforma con numerosas integraciones exige más. El buen criterio es la verificabilidad: cada funcionalidad esperada debe poder identificarse, estar priorizada e ir acompañada de criterios de aceptación. Más vale corto y revisado por las áreas de negocio que largo e ignorado.

¿Hay que indicar el presupuesto en el pliego de condiciones?

Sí, al menos en forma de horquilla. Sin esa indicación, los proveedores dimensionan sus ofertas de maneras muy distintas y las propuestas se vuelven imposibles de comparar. Una horquilla permite a cada uno proponer lo que es realista y sugerir un reparto en versiones sucesivas. Precise también si el presupuesto cubre el mantenimiento y el alojamiento después de la puesta en producción.

¿Es compatible un pliego de condiciones con el método Scrum?

Sí, siempre que no se congele todo. El documento fija los objetivos, los usuarios, los requisitos no funcionales, el presupuesto, los entregables y la propiedad del código. El alcance funcional, expresado en historias de usuario priorizadas, se convierte en el Product Backlog inicial, que el Product Owner ordena y el equipo afina sprint tras sprint. Cada nueva petición se pondera frente a las historias existentes, lo que mantiene el presupuesto bajo control.