Cuando nos enfocamos al desarrollo software, solemos ver los requisitos que nos pone el cliente como las normas que deben guiar el proyecto que debe llevarlo a cabo.

Para ello es interesante ponernos en la piel de nuestros clientes sobre lo que esperan de un contratista o un licitador.

En este artículo intentaré resumir aquellos requisitos que personalmente pondría si tuviera que contratar un desarrollo a una empresa. Estos criterios podrán trasladarse de una manera efectiva y objetiva a los pliegos

• Colocar pruebas en la licitación o definición del proyecto. De esta manera sabremos que no están utilizando una copia de otro proyecto para presentar la oferta y sabremos también cómo de bueno es el equipo de desarrollo y sistemas. Poniendo estas pruebas de un nivel de dificultad alto permitirá puntuar de una manera mucho más objetiva.
• Control de la subcontratación y tamaño del proyecto. Garantizar la calidad del personal que va a llevar a cabo un proyecto es un punto crucial. Que no existan cadenas de subcontratación es importante a la hora de garantizar la calidad del proyecto en general. Si distintas organizaciones se encargan de partes distintas de la aplicaicón, se dificulta la coordinación y hace más complicada la integración de la solución. Además suele diluirse el dinero aplicado al personal, lo cual redunda en unas condiciones que colllevan una mala gestión del personal.
• Utilización de un framework reconocido. Muchas veces podemos comprar o contratar un producto que os resuelve un problema, pero no solemos fijarnos en cómo está construido. De cara a licitar un desarrollo, es necesario que esté desarrollado utilizando un framework que tenga soporte y que siga en desarrollo activo, sino tendremos un software que será dificilmente mantenible y por lo tanto más caro actualizar, debido a la dificultad de encontrar gente capacitada en dicho producto. Spring, Hibernate, Laravel, Symfony, Ror, Django: son algunos ejemplos de frameworks que considero reputados. Struts, JEE, JSP, PHP estructurado, son ejemplos de frameworks a evitar.
• Disponer de un sistema de migración del modelo de base de datos. Dentro de los procesos de actualización del modelo de la base de datos es un problema crucial a la hora de realizar la entrega de un proyecto en producción. Realizar un seguimiento de los cambios del modelo y la disponibilidad de los scripts de actualización del modelo es un punto crucial para evitar problemas a la hora de actualizar una aplicación en producción o para que alguien pueda incorporarse al proyecto en desarrollo.
• Que la aplicación funcione en más de una base de datos. La abstracción del nivel de la base de datos es fundamental para definir la calidad de un producto. Muchas veces se desarrolla en base a una única base de datos, en base a procedimientos embebidos, funciones internas a la base de datos. Que el producto sea capaz de funciona en distintas bases de datos da una versatilidad de implantación que no cualquier producto es capaz de disponer. Lo mismo podría aplicarse a las nubes, no debería ser aceptable que una solución sólo funcione en AWS o en Google Cloud, o que sólo funcione en un sistema operativo.
• Pruebas a gogo! No me cabe en la cabeza encargar un proyecto y que no venga con un conjunto de pruebas que cubra un porcentaje importante de pruebas de funcionalidad. El uso de BDD para definir los requisitos debería ser una necesidad a la hora de plantear el proyecto al contratista. Sobre todo para poder garantizar que la funcionalidad exigida por parte del pliego se cumple a rajatabla. Gherkin es un gran lenguaje que cualquiera puede entender, tanto desde la perspectiva de cliente como del desarrollador, pasando por el analista o el equipo de QA. Las pruebas de rendimiento son cruciales para el escalado de la aplicación, no es aceptable que una aplicación sea funcional pero no sea capaz de soportar más de 10 usuarios simultáneos en un servidor compartido, por ejemplo.
• Un entorno desacoplado. Las aplicaciones monolíticas han muerto, y cuanto antes nos demos cuenta mejor. No es aceptable a día de hoy, que con lo sencillo que es desarrollar un API Rest y las ventajas que conlleva para un producto, se estén encargando aplicaciones web que ni si quiera tengan un entorno de backend y frontend separados. La conectividad móvil o incluso entre administraciones podría resolverse de una manera muy sencilla si las aplicaciones no fueran islas aisladas que gestionan información.
• La documentación debe existir. “Yo.. he visto cosas que vosotros no creeríais…” A lo largo de mi carrera profesional, he visto de todo, desde aplicaciones que da gusto verlas a nivel interno, donde se nota claramente que las personas que estaban detrás del proyecto, hasta desastres tecnológicos de un nivel nunca visto, que con ningún tipo de documentación, se convierten en proyectos marrón que nadie quiere mantener. No es aceptable que en una contratación tanto pública como privada, no se entregue ningún tipo de  documentación que explique, ya no sólo al usuario cómo funcionar con ella, o al administrador de sistemas como instalarla y mantenerla en producción. Sino a cómo es la estructura interna de la aplicación, la explicación del modelo de la base de datos,  o la arquitectura de sistemas necesaria para desarrollar sobre ella.
• Metodología ágil. De cara a hacer un seguimiento correcto del proyecto no existe una metodología mejor. Scrum Kanban, son algunos ejemplos de ellas. Pero cualquiera de ellas de manera aplicada nos va a permitir tener una versión estable cada menos tiempo. La aplicación de una cultura devops es fundamental para reducir las fricciones y la segmentación del personal en el desarrollo del proyecto.
• Integración continua. De cara a controlar el desarrollo sería necesario que se ejecuten las tareas que tienen que ver con el proyecto en la infraestructura controlada por la organización que contrata el proyecto. Análisis estático de código, cobertura de pruebas, deuda técnica. Que además lance las pruebas de unidad e integración. Este requisito nos ayudará a controlar mejor a nuestros proveedores, poder clasificarlos e incluso valorarlos utilizando métricas objetivas de cara a posteriores licitaciones.
• Entrega continua. Para muchos clientes un entorno de despliegue continuo puede llegar a hacerse muy cuesta arriba, sobre todo si es una organización muy grande. Pero tener la capacida de empaquetar y desplegar la aplicación de manera automatizada debería ser obligatorio en la entrega de cualquuier proyecto. Como mínimo debería poder empaquetarse en algún sistema de contenedores, por ejemplo Docker.
• Sistemas de monitorización y medición del rendimiento de los sistemas en producción. La detección temprana de un posible fallo y disponer de un plan de contingencia ante un posible problema para que la aplicación siga en funcionamiento el máximo tiempo posible para cumplir un SLA, es crucial para que la gente de sistemas sea capaz de volver a poner en marcha las aplicaciones con la mínima intervención posible de un técnico para minimizar los fallos en producción.
• Los mantenimientos deben actualizar bibliotecas. Ya no sólo por un tema de seguridad sino también por un tema de gastar apropiadamente del dinero de los mantenimientos. Me he encontrado muchas veces clientes que ven el mantenimiento como una manera de hacer que la aplicación “no se caiga” pero no se hace una inversión correcta en su mantenimiento y ese software se convierte en un lastre de la organización, dificilmente mantenible y desactualizado.
• Y sobre todo: si no cumples con alguna de las reglas, justifícalo de manera argumentada. Como todo conjunto de reglas, deben tener algún mecanismo que permita el uso de nuevas tecnologías o innovación. Deben de actualizarse de una manera periódica para que puedan ser ajustadas a los cambios tecnológicos o de mercado.