No es lo mismo calidad del PRODUCTO software, que calidad del PROCESO software, que calidad del EQUIPO

En el mundo del software, y supongo que en otras disciplinas también, cuando nos referirnos al amplio concepto de “calidad software” hemos de ser muy conscientes de que en realidad ese “etéreo” concepto de calidad se subdivide, principalmente, en tres tipos de calidad: la del proceso, la del producto y la de las personas/equipos.
No se vosotros, pero yo demasiadas veces me encuentro con que este tema, aun siendo tan antiguo, en el mundo empresarial no está tan claro y maduro. Y, a la hora de la verdad, cuando se entrega el software, aquello que en la oferta / contrato parecía tan claro resulta que produce enormes desengaños. “¿Pero cómo puede ser qué la empres x con CMMI nivel y nos entregue este producto tan malo?” “¿Pero no usaban la metodología z?”
Sin pretender, ni poder, resolver el mundo, dejáme que en este post haga un breve resumen de estas tres tan diferentes y determinantes áreas de la calidad software.

La calidad del proceso

La calidad vista desde el mundo de los PROCESOS nos dice que la calidad del PRODUCTO software está determinada por la calidad del PROCESO. No me voy a perder en definiciones de libro, pero por proceso se entiende las actividades, tareas, entrada, salida, procedimientos, etc., para desarrollar y mantener software.
Modelos, normas y metodologías típicas aquí son los CMMI, ISO 15504 / ISO 12207, el ciclo de vida usado, e incluso las metodologías ágiles entran aquí (aunque en el mundo ágil la palabra proceso no guste nada, no entiendo muy bien porque, aunque creo que es porque hay quien aún piensa que proceso = a ciclo de vida en cascada, lo cual no es nada cierto, véase este post para más detalle)
Un buen proceso sin duda segura un buen producto, pero, claro, también podemos seguir un modelo de procesos famoso, y que no sea el más adecuado para nuestra organización y que por ello el producto no acabe siendo el mejor. Por ello, una mala, algunas veces perversa, interpretación es asumir que cumpliendo cierto modelo, nivel de madurez, norma, metodología, ciclo de vida, o cualquier otra cosa relacionada con el proceso… se ASEGURA por ello directamente productos de calidad. ¿Realmente es garantía suficiente? ¿Una certificación sobre la calidad del proceso garantiza un producto de calidad?…

La calidad del producto

Comentaban en IEEE software que hay poca evidencia en que cumplir un modelo de procesos (CMMI, ISO 12207, una metodología ágil o no, etc.) asegure la calidad del producto. Y en Computer, que las evaluaciones de calidad deberían estar basadas en evidencias del producto (auditando el software), y no en evidencias circunstanciales o suposiciones.
Y es por ello que existen los modelos de calidad de producto, destacando entre ellos la ISO 9126, o la nueva serie ISO 25000, que especifica diferentes dimensiones de la calidad de producto. Aunque aquí la dura tarea de evaluación recae en el uso de métricas software, amplio mundo que no voy a tratar porque excedería el objetivo de este post.
Sí una empresa que desarrolla software debe preocuparse de la calidad del PROCESO y del PRODUCTO que desarrolla y entrega, una empresa que solo compra software (el típico cliente) debería, principalmente, preocuparse de la calidad del PRODUCTO que compra. Aunque vemos que en la realidad, las empresas que compran software lo hacen al revés, se preocupan por el proceso que usa su proveedor (CMMI, ISO, etc.) y apenas del producto que les llega. Cosas de la industria.

La calidad del equipo y/o personas

Ya lo decíamos en aquel post… ¿Qué es lo más determinante para el éxito, o fracaso, de un proyecto (o para el producto software)? Las personas. Lo más determinante, complejo, y sobre lo que menos “guías”, “maneras de puntuar” o “métodos” hay. Tema complejo donde los haya.
Aquí podemos encontrar decenas de aproximaciones para mejorar, que van desde el tan de moda coaching, a la filosofía ágil de lograr la auto-organización de los equipos, estrategias de motivación, combinaciones de los anteriores, etc. E incluso hasta hay modelos, como son los TSP y PSP.
Alguna conclusión…
Si quieres calidad, vas a necesitar los tres anteriores. Aunque depende del rol que juegues te puede importar más uno u otro, y esto es muy importante saberlo. Si eres un cliente que solo compra software no puedes perder la prioridad, procesos, productos y personas son importantes, pero la calidad del producto es para ti determinante. Si eres fabricante de software, vas a necesitar los tres y no puedes olvidar ninguno.