Cómo avanza un proyecto de software, de la oferta a la entrega

Una de las primeras preguntas de una organización que quiere encargar un software es cómo será el proceso. Cuándo verán qué, qué se esperará de ellos, cuándo se dará el trabajo por terminado.

En este artículo explico por qué pasos pasa un proyecto, desde la primera reunión hasta el mantenimiento. Los pasos no duran lo mismo en todos los proyectos. En un trabajo pequeño, varios caben en una sola reunión. Pero ninguno se salta, porque el paso que se salta vuelve al final del proyecto en forma de sorpresa.

Primera reunión

En la primera reunión no hablamos de precio. Intentamos entender qué se quiere hacer, cómo funciona hoy el trabajo y qué tiene que cambiar. Quién lo va a usar, qué datos va a tratar, con qué sistemas se va a comunicar.

Al final de esta reunión, a veces decimos que no hace falta software a medida. Si un producto estándar resuelve el trabajo, decirlo desde el principio ahorra tiempo a todos.

Descubrimiento

Si la necesidad no está clara, proponemos una breve fase de descubrimiento. Unos cuantos talleres, un repaso de los sistemas y datos actuales y la descripción paso a paso del proceso de trabajo. El resultado del descubrimiento es un documento escrito: alcance, roles de usuario, integraciones, datos, riesgos conocidos y lo que aún no se sabe.

Es la fase más barata del proyecto y la que más dinero ahorra. Corregir una necesidad mal entendida en un documento es mucho más fácil que corregirla en el código.

Oferta

La oferta se basa en el documento de descubrimiento. Para cada paquete de trabajo consta por escrito qué se hará, cuánto durará, qué se espera de la organización y con qué criterio se aceptará. Lo que queda fuera del alcance también se escribe aparte. Aquí se aclara de quién serán el código fuente y la propiedad intelectual y cómo funcionará el mantenimiento.

Diseño

Antes de escribir código, diseñamos el modelo de datos, la estructura de permisos y las pantallas principales. Enseñamos los bocetos de las pantallas a usuarios reales de la organización. Las objeciones que surgen en esta fase salen mucho más baratas que las que surgen después.

Si se van a tratar datos personales, en esta fase también se decide qué datos se recogen y por qué, quién podrá verlos y cuánto tiempo se conservarán. No son funcionalidades que se añaden después, sino parte de la arquitectura.

Desarrollo

Llevamos el desarrollo en ciclos cortos. Al final de cada ciclo, la organización ve una versión que funciona en el entorno de pruebas. Si algo se ha entendido mal, se nota en unas pocas semanas.

Con cada cambio se ejecutan pruebas automáticas. Si una prueba falla, esa versión no avanza. Explicamos cómo lo hacemos en nuestro propio sitio en otro artículo.

Pruebas y aceptación

La aceptación se hace según los criterios que figuran en la oferta. Para cada funcionalidad, criterios concretos del tipo «en este caso da este resultado». La organización los prueba con sus propios datos, los puntos que no se cumplen se registran y se corrigen.

Cuando los criterios de aceptación no están por escrito, la discusión sobre si «funciona» es inevitable. Explicamos por qué en el artículo que escribimos sobre los criterios de aceptación.

Puesta en producción

La puesta en producción no es un día, sino un pequeño plan. Si hay que migrar datos del sistema antiguo, las migraciones de prueba se hacen antes. Está por escrito cómo volver atrás si algo sale mal. Se da una breve formación a los usuarios y en las primeras semanas se responde rápido a las preguntas.

Mantenimiento

Después de la entrega siguen las actualizaciones de seguridad, las actualizaciones de infraestructura y las pequeñas mejoras. El alcance del mantenimiento y el tiempo en que se atenderá un problema se ponen por escrito en la fase de oferta.

El código fuente, la documentación y los pasos de despliegue se entregan a la organización. Así, si algún día quiere continuar con otro equipo, puede hacerlo.

El papel de la organización

En todos estos pasos hace falta un interlocutor por parte de la organización. Alguien que conozca el proceso de trabajo, que responda pronto a las preguntas y que pueda probar las versiones intermedias. Lo que retrasa los proyectos muchas veces no es un problema técnico, sino la falta de ese interlocutor.

En resumen

Primera reunión, descubrimiento, oferta, diseño, desarrollo, aceptación, puesta en producción y mantenimiento. Los pasos se acortan o se alargan según el tamaño del proyecto, pero ninguno se salta. Que al final de cada paso conste por escrito qué se entrega evita sorpresas al final del proyecto.