Hablemos de calidad

En el mundo acelerado del desarrollo de software, la calidad a menudo se relega en favor de la velocidad o el volumen de código y en el ámbito de la implantación de sistemas ERP  la calidad del código puede ser la diferencia entre el éxito y el fracaso.

Implantación sin complicaciones, ¿es posible?

Generalmente, el punto de partida más seguro en cualquier software es la instalación estándar que proporciona el propio fabricante. En el caso de Odoo, se invierten muchos recursos en asegurar de que el código base sea de alta calidad, estable, y eficiente. La implantación "perfecta" (a nivel de código) ocurre cuando no tenemos ningún añadido sobre el código nativo, contratamos directamente con el fabricante, lo alojamos en su servidor, y dentro de su programa de actualizaciones ("Saas", sí, entre comillas).

Seguramente existan muchos casos así - que los implantadores no vemos -, por el enfoque de sus campañas de promoción, este tipo de cliente es el ideal para Odoo, su target principal. Y aunque muchos hemos considerado en algún momento que centrar la estrategia ventas de un ERP "SAP-Killer" como Odoo hacia empresas pequeñas o poco complejas es desperdiciar su potencial, lo cierto es una excelente manera de monetizar el producto (economía de escala) por realizar apenas esfuerzo individual para cada uno de sus clientes.

Las cuentas de gran envergadura son - por ahora - algo que el fabricante suele ceder a su red de partners, aunque por su expansión geográfica, estrategia comercial y crecimiento de consultores cualificados, es fácil ver que la tendencia podría cambiar en un futuro no muy lejano.

Pero, volviendo al código ¿es suficiente con los módulos exclusivos de Odoo? Aunque la versión estándar es una base excelente, raramente satisface todas las necesidades de empresas con cierta complejidad o envergadura, y aquí es donde entran en juego los desarrollos adicionales o personalizados y es precisamente donde la calidad de todo el sistema puede verse comprometida si no se tiene cuidado con el código introducido.

Añadir un único módulo ya nos llevaría a tener una implantación con desarrollos de terceros, funcionando todo en una misma base de datos. Entonces, ¿como puedo valorar la integridad de ese Odoo personalizado?

Código de calidad, no cantidad de código

«Medir los avances de un programa utilizando como base el número de líneas de código es como medir el avance en la construcción de un avión por el peso» Bill Gates

En todos mis años de implantador, nunca un cliente me ha pedido código de calidad; se habla de requerimientos, coste, recursos dedicados, planificación de las fases, gestión de expectativas, formación del personal y todo lo relacionado con el proyecto, evitando lo más obvio: buen código. Es como hacer una casa centrando el proyecto de construcción en los tiempos, costes y metodología, pero sin una memoria de calidades. Pero claro, el código es invisible y el cliente no tiene contacto "directo".

Cuando es necesario añadir desarrollos, la calidad debe primar sobre la cantidad y la velocidad de entregas. Un pequeño desarrollo de código bien escrito, mantenible y eficiente es mucho más valioso que grandes cantidades de código mal estructurado. Cuando la calidad es alta es más fácil de depurar, actualizar y escalar, y por tanto resulta más económico y eficiente a medio y largo plazo, especialmente en los proyectos de implantación de ERPs, donde los requisitos pueden cambiar rápidamente y la capacidad de adaptarse es vital.

La naturaleza de código abierto de Odoo, junto con la gran comunidad que lo respalda, lo convierte en un ecosistema perfecto para fomentar la calidad del código. Además, el software que ha sido ampliamente utilizado tiende a ser más robusto y confiable. 

¿Pero donde encuentro el código?

Simplificando, estas son las fuentes para obtener código adicional:

• Marketplace de Odoo:  en general prima la cantidad sobre la calidad. Aunque hay mucha variedad, es habitual encontrar módulos que fallan nada más instalarlos, o problemas e inconsistencias en el sistema que sólo pueden ser solucionados por  su desarrollador o contratando a un implantador que audite y refactorice el código "conflictivo". La sensación general entre implantadores es que suelen ser desarrollos a evitar.
• Repositorios de GitHub de terceros, esto es como una caja de bombones, nunca se sabe qué puede salir, si no queremos sorpresas, mejor auditar antes de utilizar en producción.
  
• OCA (Odoo Community Association), el repositorio más extenso y con mayores requisitos de calidad, además ofrece la ventaja de que está siendo utilizado y mantenido por una gran comunidad, por lo que ofrece bastantes garantías.
• Desarrollo a medida: todo cae en la parte del implantador. Hacer código a medida suele ser necesario en muchos casos, si bien es conveniente probar primero funcionalidades similares ya desarrolladas (del propio implantador o de OCA) y realizar las menores personalizaciones posibles.
  

¿Pero como se puede saber sin auditar? ¿Hay métricas? Aunque puede parecer complicado, simplificándolo, hay dos maneras de saber que contamos con buen código:

- Utilizar desarrollos de la Comunidad de Odoo Internacional. Cuenta con estándares muy estrictos y bien definidos, por lo que si nuestros requerimientos están (o son publicados) en este repositorio, podemos tener la certeza de que hay calidad.

- Analizar la metodología de desarrollo del implantador. Preguntar a sus clientes, los más antiguos, como ha sido la evolución y mantenimiento de su ERP, y pactar actualizaciones periódicas.

Una migración con cambio de versión suele hacer aflorar todo lo que en su momento no se hizo correctamente o con prisas. Clientes "atascados" en versiones muy lejanas de Odoo no suele ser un buen indicativo de calidad. 

El enfoque de implantación con código comunitario también simplifica las migraciones futuras, ya que es más probable que muchos de los problemas se hayan identificado y resuelto previamente.

¿Como podemos asegurar buen código? ¿Qué métricas hay?

Elegir el proveedor adecuado y llevar a buen puerto una implantación es una tarea tan complicada como el tamaño o complejidad de la empresa lo sea. Las transformaciones digitales son procesos que implican cambios en la mentalidad de la empresa, adaptación de sus trabajadores, una buena sintonía cliente-proveedor y un buen producto de base, en nuestro caso Odoo, y definir muy bien hasta donde queremos evolucionarlo.

Proyectos grandes y complejos implican mucho tiempo y desgaste, y es fácil dejarse seducir - como implantador - por las "implantaciones express", que por otra parte son como ya hablamos anteriormente, el objetivo principal del marketing de Odoo. Todo bien, siempre que no implique meter código sin auditar o desarrollado con prisas. O si se hace, por motivos de causa mayor, tener previsto recursos para corregirlo a medio plazo.

Odoo es uno de los softwares más preparados (sino el que más) para gestionar grandes cuentas. Por su modernidad tecnológica, su estructura modular, su facilidad de desarrollo y su apoyo en grandes tecnologías libres. Tiene funcionalidades que otros no podrían ni soñar y ya ha demostrado sobradamente en grandes clientes, como Danone, Toyoya o Securitas DIrect.

Conclusión

La calidad del código no es un lujo, es una necesidad, especialmente en proyectos de implantación de ERP como Odoo. Aunque la instalación óptima del fabricante es un punto de partida sólido, las necesidades específicas de la empresa suelen requerir desarrollos adicionales.

En este contexto, mantener un alto estándar de calidad del código es imperativo para el éxito a largo plazo de cualquier proyecto de ERP. Así que, cuando pensemos en desarrollar o implantar soluciones ERP, recordemos siempre: hablemos de calidad.