Por qué corregir los errores de software debería ser el problema del CEO
Por Nicholas BowenMarca
Gestionando organizaciones
Harvard Business Review
Las plataformas de software impregnan el tejido de nuestras vidas, sin embargo, solo el 27% de los CEO en Fortune 100 tienen títulos en ingeniería y ciencias. Únase a una llamada de ganancias trimestrales y escuchará mucha discusión sobre ingresos, gastos y tendencias geográficas, pero poco (si es que hay algo) sobre la calidad del software de la compañía. Los resultados son obvios: para casi todos los desastres importantes causados por defectos de software, la autopsia generalmente determina que el defecto ha existido durante algún tiempo.
El problema no es que los líderes de la compañía necesiten tener experiencia en ingeniería y no, sino que pocos fuera de los silos de ingeniería saben cómo discutir los sistemas de software críticos. Como resultado, los errores de software generalmente permanecen por debajo del radar del CEO a menos que ocurra un evento catastrófico.
El problema de la aceleración repentina en los automóviles Toyota fue el caso de un libro de texto de lo que puede suceder sin un sistema de calidad interno proactivo. En 2004, la Administración Nacional de Seguridad del Tráfico en Carreteras abrió una investigación sobre las quejas sobre el control electrónico del acelerador en los Lexus ES300. Pero Toyota no emitió grandes retiros, ni detuvo las ventas de los modelos afectados, hasta 2010. Cuando se resolvió una demanda contra Toyota tres años después, dos testigos expertos informaron que "el sistema era defectuoso y peligroso, plagado de errores y lagunas en son a prueba de fallas lo que condujo a la causa raíz del accidente ". Un programador de Toyota describió la aplicación de control del motor como" tipo espagueti ". La naturaleza prolongada y la falta de resolución de este caso son signos claros de que hubo un sistema de revisión de calidad inadecuado en su lugar. Con un buen sistema, ese error habría sido visible para el liderazgo superior mes tras mes, temprano y con frecuencia, lo que provocaría una acción eficiente y que salvaría la vida.
Los líderes de la compañía pueden y deben estar íntimamente involucrados en la calidad del software, tal como lo están en las divisiones de ventas y finanzas. Esto significa comprender cómo trabajan los equipos técnicos e implementar un sistema de gestión de calidad.
Cómo se ve liderar el camino
Trabajé en la división de mainframe de IBM en un momento en que tanto IBM como Microsoft tenían problemas de calidad que causaban importantes problemas comerciales y problemas de satisfacción del cliente. A principios de la década de 1990, IBM estaba experimentando serios problemas de calidad de campo además de dificultades para cumplir con los plazos para nuevos productos. El CEO Louis Gerstner Jr. estaba frustrado porque, en la fecha de vencimiento de algunos productos, le dijeron que se perderían la fecha de lanzamiento por un año. En una nota legendaria, Gerstner ofreció un programa de amnistía: 30 días para restablecer las fechas, y después de perder una fecha sería motivo de despido.
La tarea de crear nuevos horarios fue encomendada a Nicholas Donofrio, el vicepresidente sénior de tecnología y fabricación. El lema de Donofrio era "Sea franco [sobre su horario y problemas de calidad] y lo comunicaré [sobre conseguirle los recursos necesarios]". No tenía administración de línea directa para el negocio de sistemas (tanto hardware como software), pero desde fue el líder anterior de la unidad de negocios, tenía un conocimiento profundo y relaciones personales profundas. Casi el 80% de las fechas de los productos se restablecieron, y cada organización de productos estableció sistemas de gestión de calidad de extremo a extremo. En 1999, IBM era el líder mundial de servidores, con una participación de mercado del 23%.
Del mismo modo, en la década de 1990, los sistemas operativos Windows de Microsoft tenían una serie de errores que provocaban la congelación frecuente de las computadoras. El público se acostumbró en gran medida a esas fallas ("pantallas azules de la muerte"), pero luego Microsoft se vio afectado por otros errores: a medida que los sistemas Windows se conectaban a Internet, sufrieron muchos ataques vergonzosos, virus y problemas de seguridad. Bill Gates respondió a la crisis con un memorando emitiendo un llamado a las armas, que fue enviado a los 50,000 empleados y publicado simultáneamente en Wired. En él definió "computación confiable", un amplio conjunto de iniciativas para mejorar la seguridad y el diseño del producto, y describió los requisitos previos para un amplio sistema de gestión de calidad (SGC), incluidos los cambios en el diseño del software y los procesos de desarrollo, nuevas capacidades de informe de errores, y nuevas funciones de actualización. Para el año 2000, los ingresos de Microsoft cruzaron los $ 20 mil millones, y la compañía informó que los clientes citaban el servidor Windows 2000 recién lanzado como la versión más confiable hasta la fecha.
Estos dos ejemplos muestran cómo los líderes pueden cambiar las divisiones de ingeniería deterioradas haciendo preguntas simples, estableciendo estándares y viéndose a sí mismos como parte del proceso.
Cuando el software es crítico, también lo son los errores
La creación de un SGC eficaz que incluya a ingenieros y líderes superiores por igual debe abordarse como un ejercicio evolutivo, comenzando de manera simple con un enfoque en el alto impacto desde el principio. Los CEO deben hacer dos preguntas simples sobre un producto que se ha enviado recientemente:
1. “¿Qué criterios se usaron para determinar cuándo el producto estaba listo para ser enviado?” Debe haber una discusión clara sobre la cantidad de tiempo en las pruebas del sistema, el tipo de pruebas completadas y los criterios precisos utilizados en la decisión de enviar el producto.
2. "¿Cuál es el estado actual del defecto después de los primeros seis meses?" Es normal ver un aumento en los defectos después del envío inicial, debido al mayor uso en entornos del mundo real, pero los líderes deben investigar 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 profundizar en la métrica clave de los días abiertos para un defecto, para garantizar que los defectos más graves se reparen de manera expedita.
La cuadrícula 2 × 2 a continuación muestra cómo calificar un sistema de gestión de calidad basado en las respuestas a esas dos preguntas. A lo largo del eje y, usted mide qué tan aislada es la información, en función de la rapidez con que se responden las preguntas. A lo largo del eje x, mide la respuesta de la organización a sus preguntas, en función de cuán proactivo es el equipo para abordar los errores. Un QMS "maduro" puede identificarse por el hecho de que el equipo comparte información de defectos de manera rápida y sincera con los principales líderes; en un sistema "con problemas", las respuestas se presentan lentamente y con mucho antagonismo.
Si encuentra que su empresa se encuentra en el cuadrante con problemas, su primer paso debería ser crear inmediatamente un enfoque proactivo en los defectos para pasar al cuadrante de aprendizaje. Esto es lo que hicieron Gerstner y Gates. Debe centrarse en crear una cultura en la que se recompense la honestidad y los empleados se sientan seguros discutiendo métodos y técnicas para abordar defectos de software. En este entorno, la información debe fluir fácilmente entre los silos requeridos, moviendo su sistema de aprendizaje al cuadrante maduro.
Gestión de calidad del 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 debe ser realizado por los equipos orientados al cliente en conjunto con los clientes. En general, los equipos priorizarán dos tipos de errores: los que provocan el bloqueo del sistema y la pérdida de servicio (estos obtuvieron la mayor severidad en IBM) y los que son menos graves pero podrían ser generalizados.
Luego, como organización, decida su tiempo de respuesta objetivo para cada nivel de gravedad. Si el QMS es nuevo, entonces el enfoque inicial debería estar en corregir los errores más graves en cuestión de horas o días. A medida que usa su sistema, puede recopilar datos sobre dos métricas clave, las tasas de errores entrantes y la productividad de los correctores de errores, y ajustar sus objetivos según sea necesario. Finalmente, debe crear un sistema de revisión que lo involucre a usted mismo y a otros líderes principales. Las revisiones de defectos abiertos y el tiempo para resolver un defecto deben hacerse con diversos grados de detalle en todos los niveles de la organización.
Una vez que se establece el QMS, es poco probable que el CEO vea muchos errores antiguos simplemente porque nadie quiere dar la misma excusa dos meses seguidos. El CEO también podría revisar todos los errores de alta gravedad y los omnipresentes. El CEO podría hacer la pregunta más simple: "¿Cómo se lanzó el software con ese tipo de error?" El equipo de desarrollo de productos podría responder con jerga de ingeniería de software sobre "escapes", y el CEO podría entonces hacer una pregunta casi retórica: "Will ¿Probamos esas condiciones la próxima vez antes de lanzar el producto?
Este tipo de SGC conducirá a mejores experiencias del cliente. Para comprender lo importante que es esto, considere un defecto de software que encuentro regularmente en el sistema de cheques en línea de mi banco: una función de código de gasto falla con frecuencia, lo que requiere que reinicie mi computadora. Me he quejado innumerables veces durante el último año, y todo lo que dice el banco es: "Se lo dijimos a TI, pero no sabemos si lo solucionarán". Esta es una señal de que el banco carece de un SGC riguroso, lo que deja su Los asesores financieros parecen indefensos y molestan a sus clientes, lo que puede hacer que cambien de banco. Desearía poder decirles que pueden hacer un cambio, como lo hicieron IBM y Microsoft.
Nicholas Bowen, Ph.D. Trabajó en IBM durante 31 años en una variedad de puestos en investigación, desarrollo de productos, estrategia corporativa y gestión general. Uno de sus roles favoritos era liderar a los 5.000 desarrolladores de IBM que trabajaban en todos los sistemas operativos de IBM, donde era el "cuello de botella" para cualquier error en los productos de servidor de IBM.
Gestionando organizaciones
Harvard Business Review
Las plataformas de software impregnan el tejido de nuestras vidas, sin embargo, solo el 27% de los CEO en Fortune 100 tienen títulos en ingeniería y ciencias. Únase a una llamada de ganancias trimestrales y escuchará mucha discusión sobre ingresos, gastos y tendencias geográficas, pero poco (si es que hay algo) sobre la calidad del software de la compañía. Los resultados son obvios: para casi todos los desastres importantes causados por defectos de software, la autopsia generalmente determina que el defecto ha existido durante algún tiempo.
El problema no es que los líderes de la compañía necesiten tener experiencia en ingeniería y no, sino que pocos fuera de los silos de ingeniería saben cómo discutir los sistemas de software críticos. Como resultado, los errores de software generalmente permanecen por debajo del radar del CEO a menos que ocurra un evento catastrófico.
El problema de la aceleración repentina en los automóviles Toyota fue el caso de un libro de texto de lo que puede suceder sin un sistema de calidad interno proactivo. En 2004, la Administración Nacional de Seguridad del Tráfico en Carreteras abrió una investigación sobre las quejas sobre el control electrónico del acelerador en los Lexus ES300. Pero Toyota no emitió grandes retiros, ni detuvo las ventas de los modelos afectados, hasta 2010. Cuando se resolvió una demanda contra Toyota tres años después, dos testigos expertos informaron que "el sistema era defectuoso y peligroso, plagado de errores y lagunas en son a prueba de fallas lo que condujo a la causa raíz del accidente ". Un programador de Toyota describió la aplicación de control del motor como" tipo espagueti ". La naturaleza prolongada y la falta de resolución de este caso son signos claros de que hubo un sistema de revisión de calidad inadecuado en su lugar. Con un buen sistema, ese error habría sido visible para el liderazgo superior mes tras mes, temprano y con frecuencia, lo que provocaría una acción eficiente y que salvaría la vida.
Los líderes de la compañía pueden y deben estar íntimamente involucrados en la calidad del software, tal como lo están en las divisiones de ventas y finanzas. Esto significa comprender cómo trabajan los equipos técnicos e implementar un sistema de gestión de calidad.
Cómo se ve liderar el camino
Trabajé en la división de mainframe de IBM en un momento en que tanto IBM como Microsoft tenían problemas de calidad que causaban importantes problemas comerciales y problemas de satisfacción del cliente. A principios de la década de 1990, IBM estaba experimentando serios problemas de calidad de campo además de dificultades para cumplir con los plazos para nuevos productos. El CEO Louis Gerstner Jr. estaba frustrado porque, en la fecha de vencimiento de algunos productos, le dijeron que se perderían la fecha de lanzamiento por un año. En una nota legendaria, Gerstner ofreció un programa de amnistía: 30 días para restablecer las fechas, y después de perder una fecha sería motivo de despido.
La tarea de crear nuevos horarios fue encomendada a Nicholas Donofrio, el vicepresidente sénior de tecnología y fabricación. El lema de Donofrio era "Sea franco [sobre su horario y problemas de calidad] y lo comunicaré [sobre conseguirle los recursos necesarios]". No tenía administración de línea directa para el negocio de sistemas (tanto hardware como software), pero desde fue el líder anterior de la unidad de negocios, tenía un conocimiento profundo y relaciones personales profundas. Casi el 80% de las fechas de los productos se restablecieron, y cada organización de productos estableció sistemas de gestión de calidad de extremo a extremo. En 1999, IBM era el líder mundial de servidores, con una participación de mercado del 23%.
Del mismo modo, en la década de 1990, los sistemas operativos Windows de Microsoft tenían una serie de errores que provocaban la congelación frecuente de las computadoras. El público se acostumbró en gran medida a esas fallas ("pantallas azules de la muerte"), pero luego Microsoft se vio afectado por otros errores: a medida que los sistemas Windows se conectaban a Internet, sufrieron muchos ataques vergonzosos, virus y problemas de seguridad. Bill Gates respondió a la crisis con un memorando emitiendo un llamado a las armas, que fue enviado a los 50,000 empleados y publicado simultáneamente en Wired. En él definió "computación confiable", un amplio conjunto de iniciativas para mejorar la seguridad y el diseño del producto, y describió los requisitos previos para un amplio sistema de gestión de calidad (SGC), incluidos los cambios en el diseño del software y los procesos de desarrollo, nuevas capacidades de informe de errores, y nuevas funciones de actualización. Para el año 2000, los ingresos de Microsoft cruzaron los $ 20 mil millones, y la compañía informó que los clientes citaban el servidor Windows 2000 recién lanzado como la versión más confiable hasta la fecha.
Estos dos ejemplos muestran cómo los líderes pueden cambiar las divisiones de ingeniería deterioradas haciendo preguntas simples, estableciendo estándares y viéndose a sí mismos como parte del proceso.
Cuando el software es crítico, también lo son los errores
La creación de un SGC eficaz que incluya a ingenieros y líderes superiores por igual debe abordarse como un ejercicio evolutivo, comenzando de manera simple con un enfoque en el alto impacto desde el principio. Los CEO deben hacer dos preguntas simples sobre un producto que se ha enviado recientemente:
1. “¿Qué criterios se usaron para determinar cuándo el producto estaba listo para ser enviado?” Debe haber una discusión clara sobre la cantidad de tiempo en las pruebas del sistema, el tipo de pruebas completadas y los criterios precisos utilizados en la decisión de enviar el producto.
2. "¿Cuál es el estado actual del defecto después de los primeros seis meses?" Es normal ver un aumento en los defectos después del envío inicial, debido al mayor uso en entornos del mundo real, pero los líderes deben investigar 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 profundizar en la métrica clave de los días abiertos para un defecto, para garantizar que los defectos más graves se reparen de manera expedita.
La cuadrícula 2 × 2 a continuación muestra cómo calificar un sistema de gestión de calidad basado en las respuestas a esas dos preguntas. A lo largo del eje y, usted mide qué tan aislada es la información, en función de la rapidez con que se responden las preguntas. A lo largo del eje x, mide la respuesta de la organización a sus preguntas, en función de cuán proactivo es el equipo para abordar los errores. Un QMS "maduro" puede identificarse por el hecho de que el equipo comparte información de defectos de manera rápida y sincera con los principales líderes; en un sistema "con problemas", las respuestas se presentan lentamente y con mucho antagonismo.
Si encuentra que su empresa se encuentra en el cuadrante con problemas, su primer paso debería ser crear inmediatamente un enfoque proactivo en los defectos para pasar al cuadrante de aprendizaje. Esto es lo que hicieron Gerstner y Gates. Debe centrarse en crear una cultura en la que se recompense la honestidad y los empleados se sientan seguros discutiendo métodos y técnicas para abordar defectos de software. En este entorno, la información debe fluir fácilmente entre los silos requeridos, moviendo su sistema de aprendizaje al cuadrante maduro.
Gestión de calidad del 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 debe ser realizado por los equipos orientados al cliente en conjunto con los clientes. En general, los equipos priorizarán dos tipos de errores: los que provocan el bloqueo del sistema y la pérdida de servicio (estos obtuvieron la mayor severidad en IBM) y los que son menos graves pero podrían ser generalizados.
Luego, como organización, decida su tiempo de respuesta objetivo para cada nivel de gravedad. Si el QMS es nuevo, entonces el enfoque inicial debería estar en corregir los errores más graves en cuestión de horas o días. A medida que usa su sistema, puede recopilar datos sobre dos métricas clave, las tasas de errores entrantes y la productividad de los correctores de errores, y ajustar sus objetivos según sea necesario. Finalmente, debe crear un sistema de revisión que lo involucre a usted mismo y a otros líderes principales. Las revisiones de defectos abiertos y el tiempo para resolver un defecto deben hacerse con diversos grados de detalle en todos los niveles de la organización.
Una vez que se establece el QMS, es poco probable que el CEO vea muchos errores antiguos simplemente porque nadie quiere dar la misma excusa dos meses seguidos. El CEO también podría revisar todos los errores de alta gravedad y los omnipresentes. El CEO podría hacer la pregunta más simple: "¿Cómo se lanzó el software con ese tipo de error?" El equipo de desarrollo de productos podría responder con jerga de ingeniería de software sobre "escapes", y el CEO podría entonces hacer una pregunta casi retórica: "Will ¿Probamos esas condiciones la próxima vez antes de lanzar el producto?
Este tipo de SGC conducirá a mejores experiencias del cliente. Para comprender lo importante que es esto, considere un defecto de software que encuentro regularmente en el sistema de cheques en línea de mi banco: una función de código de gasto falla con frecuencia, lo que requiere que reinicie mi computadora. Me he quejado innumerables veces durante el último año, y todo lo que dice el banco es: "Se lo dijimos a TI, pero no sabemos si lo solucionarán". Esta es una señal de que el banco carece de un SGC riguroso, lo que deja su Los asesores financieros parecen indefensos y molestan a sus clientes, lo que puede hacer que cambien de banco. Desearía poder decirles que pueden hacer un cambio, como lo hicieron IBM y Microsoft.
Nicholas Bowen, Ph.D. Trabajó en IBM durante 31 años en una variedad de puestos en investigación, desarrollo de productos, estrategia corporativa y gestión general. Uno de sus roles favoritos era liderar a los 5.000 desarrolladores de IBM que trabajaban en todos los sistemas operativos de IBM, donde era el "cuello de botella" para cualquier error en los productos de servidor de IBM.
No hay comentarios:
Publicar un comentario