Las plataformas de software permean el tejido de nuestras vidas, pero apenas el 27% de los CEOs en la lista de Fortune 100 tienen grados académicos en ingeniería y ciencia. Únase a una revisión trimestral de ganancias y escuchará muchas discusiones acerca de ingresos, gastos y tendencias, pero muy poca respecto a la calidad del software de la compañía. Las consecuencias son obvias: Casi todos los análisis póstumos de los principales desastres ocasionados por defectos en el software determinan que esos problemas habían existido desde hace tiempo.

El problema no es que los líderes de las compañías carezcan de antecedentes en ingeniería, sino el que pocas personas fuera de los departamentos de ingeniería saben cómo discutir respecto a estos fundamentales sistemas de software. Como resultado, los errores de software generalmente se ocultan bajo el radar del CEO hasta que sucede un evento catastrófico.

Los líderes de las empresas pueden, y deberían, involucrarse íntimamente en el monitoreo de la calidad del software, del mismo modo en que están involucrados en las ventas y las finanzas. Esto significa entender cómo funcionan los equipos técnicos e implementar un sistema de gestión de calidad, o QMS (por sus siglas en inglés).

Cómo dirigir el rumbo

Cuando estaba trabajando en la división principal de IBM a principios de los 90, la compañía experimentaba problemas de calidad que ocasionaban significativos desafíos empresariales y problemas con la satisfacción de los consumidores. En particular, IBM tenía dificultades con problemas de calidad en campo y con el cumplimiento de las fechas de entrega para nuevos productos, para frustración del CEO, Louis Gerstner Jr. En un memorándum que se ha vuelto legendario, Gerstner ofreció un programa de amnistía: Los trabajadores tenían 30 días para ajustar las fechas de lanzamiento de productos, y si no cumplían con la nueva fecha límite, ello sería razón para despedirlos.

La tarea de crear nuevos calendarios se le asignó a Nicholas Donofrio, el vicepresidente senior de tecnología y manufactura. El lema de Donofrio era “Sé sincero [acerca de tus problemas con el calendario y la calidad] y yo seré cooperativo [acerca de conseguirte los recursos necesarios].” Él no tenía experiencia en la gerencia directa de los trabajos de hardware y sistemas de software, pero ya que era el anterior líder de la unidad de negocios, tenía conocimiento a profundidad y profundas relaciones personales. Casi el 80% de las fechas de lanzamiento de producto se replantearon, y cada organización de producto estableció sus propios QMSs. Para 1999, IBM era el líder mundial en servidores de cómputo, con una participación de mercado del 23%.

El ejemplo de IBM muestra que, al hacer preguntas simples, definir estándares y verse a sí mismos como parte del proceso, los líderes pueden cambiar el rumbo de cualquier división de ingeniería que esté en problemas. Crear un QMS que incluya tanto a ingenieros como altos directivos debería trabajarse como un ejercicio evolutivo, con un enfoque en crear alto impacto desde el inicio.

Si el software es crítico, también lo son sus errores

Los CEOs que quieren iniciar el proceso de establecer un QMS efectivo para un producto que ha sido lanzado recientemente deberían hacer dos simples preguntas:

1. “¿Qué criterio se utilizó para determinar que el producto estaba listo para enviarse?” Debería haber una clara discusión sobre la cantidad de tiempo invertido en las pruebas de los sistemas, el tipo de análisis realizados y los estándares precisos utilizados en la decisión de lanzar el producto.

2. “¿Cuál es el estatus de defectos después de los primeros seis meses?” Es normal ver un aumento en los defectos después del envío inicial, debido al incremento en el uso del producto en condiciones del mundo real, pero los líderes deberían verificar cómo los equipos de ingeniería están priorizando los errores y categorizando los defectos más severos. Con esta información, los líderes pueden asegurarse de que los errores más graves estén siendo corregidos en forma ágil.

Calidad al siguiente nivel

Si está creando un QMS desde cero, su primer paso es decidir cómo la organización clasificará y priorizará los errores. Esto deberían hacerlo los equipos que tratan con clientes en conjunto con los consumidores. Generalmente, los equipos priorizarán dos tipos de errores: aquellos que ocasionan que el sistema se caiga y deje de funcionar (estos se consideraban los más severos en IBM), y aquellos que son menos graves, pero aun así pueden ser generalizados.

A continuación, decida su tiempo objetivo para responder ante cada nivel de severidad. Si el QMS es nuevo, entonces el enfoque inicial debería estar en resolver los errores más pequeños en un lapso de horas o días. Conforme usa su sistema, puede reunir datos sobre dos mediciones clave, las tasas de arribo de errores y la productividad de quienes los corrigen, y ajustar sus objetivos conforme se requiera. Finalmente, debería crear un sistema de revisión que lo involucre a usted y a otros líderes de alto nivel. Las revisiones de errores sin resolver y del tiempo que tomaría resolver un defecto deberían realizarse con diversos niveles de detalle en todos los niveles de la organización.

Una vez que el QMS esté establecido, es improbable que el CEO vea muchos errores viejos simplemente por el hecho de que nadie quiere dar la misma excusa durante meses. El CEO también debería revisar todos los errores de alta severidad y los generalizados. El CEO podría preguntar, “¿Cómo es que el software se lanzó con este tipo de error?” El equipo de desarrollo de producto podría responder con tecnicismos de la ingeniería de software acerca de “escapes,” y entonces el CEO podría hacerles una pregunta casi retórica: “¿Haremos pruebas bajo estas condiciones antes de lanzar un producto la próxima vez?”

Este tipo de QMS llevará a experiencias mejoradas para los clientes. Para entender lo importante que es esto, considere un defecto de software que encuentro regularmente en el sistema de chequera en línea de mi banco: Una función falla con frecuencia, obligándome a reiniciar mi computadora. Me he quejado incontables veces durante el último año y en cada una el banco ha respondido, “le dijimos a TI, pero no sabemos si lo repararán.” Esta es una señal de que el banco carece de un QMS riguroso, lo que deja impotentes a sus consejeros financieros y molesta a sus consumidores. Quisiera poder decirles que pueden cambiar, como IBM lo hizo.