Durante los últimos meses, he trabajado con un psicólogo clínico experimentado y un equipo de investigación con un doctorado que incluye un psicólogo y un científico académico del comportamiento para comprender qué separa a los equipos con mejor desempeño de aquellos que tienen dificultades. Las investigaciones muestran que el 81% de los responsables de la toma de decisiones empresariales en el Reino Unido y el 89% en los EE.UU. están preocupados por la entrega puntual de proyectos de software en sus organizaciones.
Este trabajo se ha realizado en un contexto en el que la industria normalmente se ha centrado en mejorar el proceso de prueba de software, una de las últimas etapas del ciclo de vida del desarrollo de software, para abordar estos problemas. Además, muchas empresas han recurrido cada vez más al estudio de las métricas de cómo se escribe el software en sí para intentar mejorar el proceso de ingeniería de software.
Sin embargo, los desafíos parecen incluso más arraigados que cuando el código se escribe o se prueba.
Cuando escribí mi último libro, Cómo protegerse de las computadoras asesinas, investigué en profundidad una serie de fallos catastróficos de software, incluidos aviones que entraban en ‘inmersiones mortales’, accidentes automovilísticos mortales y sobredosis de radiación letal en hospitales. El libro describe cómo factores psicologicos ayúdenos a comprender por qué los errores de software se convierten en fallas informáticas catastróficas; sin embargo, un tema recurrente y alarmante en muchos de los estudios de caso es cómo la causa técnica original de muchos problemas fueron problemas de diseño de software, o incluso la falta de un diseño robusto.
Este enfoque de requisitos livianos se formalizó en el Manifiesto Ágil, que ya tiene más de 23 años, que defendía un enfoque de diseño de software centrado en “responder al cambio en lugar de seguir un plan”.
Con la firma encuestadora JL Partners, pregunté a 600 ingenieros de software en el Reino Unido y Estados Unidos sobre los proyectos de desarrollo de software exitosos y fallidos en los que habían trabajado. Nuestra investigación encontró que en proyectos de software donde el desarrollo comenzó antes de requisitos claros, donde no había un documento de especificación completo y donde se produjeron cambios significativos en una etapa tardía del desarrollo, los proyectos fallaron el 65% de las veces.
Sin embargo, identificamos solo cinco prácticas de ingeniería que redujeron la tasa de falla al 10%. Tener requisitos claros antes de que comenzara el desarrollo por sí solo hizo que los proyectos tuvieran un 97 % más de probabilidades de tener éxito y que los ingenieros tuvieran la libertad de discutir y abordar los problemas aumentaron las tasas de éxito en un 87 %. Otras prácticas incluyeron: garantizar que los requisitos fueran precisos para el problema del mundo real (54%); tener una especificación completa antes de iniciar el desarrollo (50%) y evitar cambios tardíos en los requisitos (7%). Cuando se combinan, nos referimos a estas prácticas como Ingeniería de Impacto.
Curiosamente, no encontramos una diferencia estadísticamente significativa entre quienes trabajan en varios proyectos al mismo tiempo y quienes solo trabajan en uno a la vez, a pesar de que limitar el trabajo en progreso es un elemento clave de marcos como el desarrollo de software Lean. Esto pone de relieve cómo se deben abordar los riesgos tempranos en los proyectos de software.
Fue preocupante ver que la mayor diferencia en las prácticas de ingeniería entre el Reino Unido y los EE. UU. era que los ingenieros de software en el Reino Unido tenían un 13% menos de probabilidades de sentir que podían discutir y abordar problemas que los de los EE. UU. esto es a pesar numerosos estudios realizado por mí y por otros, incluida esta investigación, destacando cuán fundamentalmente importante es la seguridad psicológica para el éxito de los sistemas informáticos.
Durante nuestra investigación, también analizamos por qué fracasan las iniciativas de transformación. A pesar de la promesa de las metodologías de transformación, todavía vemos que el 70% de las transformaciones digitales y el 96% de las transformaciones ágiles fracasan. Incluso entre todas las empresas, independientemente de su industria, cuando una empresa entra en administración en Inglaterra y Gales (es decir, un administrador concursal asume el control), sólo el 10% de las empresas sobrevivirá a pesar del cambio de dirección.
Nuestra investigación ha descubierto que los factores psicológicos fundamentales desempeñan un papel determinante en el éxito o el fracaso de tales transformaciones. Así lo ha demostrado una investigación de EY (Ernst & Young) y la escuela de negocios de la Universidad de Oxford, que encontró que los líderes que priorizan las emociones de la fuerza laboral tienen un 260% más de probabilidades de tener éxito en las transformaciones digitales.
Al igual que cuando se consola a un bebé que llora, es esencial prestar atención emocional antes de abordar el problema real. También es importante garantizar que los factores emocionales no se descuiden en las transformaciones organizacionales.
Hallazgos similares fueron realizados por el psicólogo David DeSteno, quien descubrió que simplemente cuando los participantes del estudio sintieron la emoción de gratitud, duplicaron con creces su capacidad de retrasar la gratificación ahora para obtener una recompensa mayor en el futuro.
A través de investigaciones como esta, desarrollamos un marco psicológico que permite a las personas lograr transformaciones personales y organizacionales significativas. Estas técnicas se presentan en mi nuevo libro, Ingeniería de impacto: transformando más allá de la gestión ágil de proyectosque describe su aplicación a estudios de casos del mundo real junto con la descripción de la base científica de estos hallazgos.
Sin embargo, quiero subrayar que es vital que no se abuse de esta investigación para obligar a otros a cambiar cuando no quieren. En muchos casos anteriores, quienes abogan por la transformación no han respetado debidamente la absoluta necesidad de consentimiento, tanto para los individuos como para las organizaciones.
Dejando a un lado las cuestiones morales, privar a alguien de la capacidad de aprender de sus propios errores lo priva de una importante fuente de aprendizaje de la que puede beneficiarse (en la medida en que tenga el consentimiento informado para cometer esos errores y no represente un riesgo absoluto para los demás). ).
Además, como ha demostrado nuestra investigación sobre ágil, aquellos que tienen la mayor convicción en sus ideas pueden estar equivocados, debemos abordar las situaciones con una mente abierta independientemente de cuán convencidos estemos de que tenemos razón.
Sin embargo, al asegurarnos de que los problemas estén bien definidos antes de buscar soluciones y al asegurarnos de diseñar soluciones antes de comenzar a implementarlas, podemos mejorar el éxito de nuestros proyectos de software. De manera similar, al asegurarnos de abordar las necesidades emocionales junto con la resolución de problemas, podemos garantizar que las iniciativas de transformación sean exitosas.
El Dr. Junade Ali CEng FIET es un tecnólogo experimentado interesado en la gestión de ingeniería de software, la investigación de seguridad informática y los sistemas distribuidos.