El Chaos Report. Hacia los lotes pequeños... y los métodos ágiles.

"Lesser fiery copper Lycaena thersamon (female)" by Charlesjsharp - Own work. Licensed under CC BY-SA 3.0 via Wikimedia Commons.

Antecedentes del reporte

Leí el reporte recomendado por Alejandro García el Viejo hace un par de semanas. Tal vez estoy demasiado influenciado por los métodos ágiles, pero creo que si mapeamos cada uno de los reportes tanto en los errores comúnmente cometidos, como en las mejores prácticas es muy probable que el uso de estos métodos este muy relacionado con la mayor parte de las razones de la mejora de la tasa de éxito en proyectos. Lo cual es una buena noticia.

• El Chaos Report tien una base de datos casi de 50,000 proyectos. 60% de estos proyectos provienen de USA, 25% de Europa y el 15% de proyectos del resto del mundo.Un poco más del 50% de estos proyectos son de las top 1000, 30 por ciento de medianas empresas y 20% de PYMES. 39% de los proyectos tuvieron éxito, 43% no cumplieron con la meta inicial y 18% fallaron. Sin embargo la tasa es mayor que en 2009, ya que este año 29% de los proyectos fueron exitosos.
• El incremento en la tasa de éxito se debe a varios factores, pero el principal es “el incremento en número de proyectos ágiles y pequeños”. Varias buenas prácticas están siendo utilizadas, como el hacer un análisis postmorten, más de 90% de organizaciones realizan esta práctica.
• El punto de apalancamiento más importante para la mejora de la tasa de éxito es el “incremento de la competencia· del patrocinador ejecutivo o product owner, haciendo referencia a Scrum. Este rol se convierte en el “Chief enabling officer”. Siendo el principal catalizador del proyecto dentro de la compañía.
• Más compañías enfocan en actividades que generan más valor, en lugar de enfocarse en la totalidad de los requerimientos.
• El análisis del presente año sugiero que existe funcionalidad que no se utiliza que va desde el 20% del proyecto hasta el 50%!!!!! Aquí aplica la ley de Paretto. El 20% de la funcionalidad aporta el 80% del valor de producto. Reducir el alcance pues, según el reporte, no solo es una estrategia valida, sino “LA MÁS PRUDENTE”. Menos es más dirían nuestros amigos finlandeses.
• Los proyectos ENORMES no son necesarios. La premisa es romper estos proyectos en mini proyectos. La propia portada del Chaos Manifest es una mafiosa, haciendo referencia al “efecto mariposa” que tiene un impacto...
• PIENSA EN GRANDE, ACTUA EN PEQUEÑO.
• La recomendación del Standish Group es “limitar el tamaño y la complejidad de un proyecto”, lo más que se pueda. La solución rápida podría ser no aceptar proyectos grandes, pero una más sensata es adoptar una serie de proyectos pequeños que contribuyan a una meta grande. Los proyectos frecuentemente son demasiados grandes para tener éxito.

Factores de éxito y su ponderación para proyectos pequeños

A continuación un análisis a detalle de cada uno de los factores que influyen en el éxito de los proyectos pequeños.

1. Soporte ejecutivo (20 puntos). En proyectos pequeños el patrocinador puede ser un administrador de nivel medio o un producto owner haciendo referencia a SSCRUM. NO SE REQUIERE UN PLAN DETALLADO por ser un proyecto pequeño. La negociación es mínima. Un VISION STATEMENT de una o dos páginas es suficiente para que un proyecto sea aprobado o rechazado rápidamente. La habilidad que más impacta y que debe ser altamente dominada es IDENTIFICAR que motiva al equipo. FACTOR CRÍTICO: El 78% de los proyectos pequeños que están alineados con la estrategia de negocio, TIENEN ÉXITO.
2. Participación del cliente (15 puntos). Los proyectos tienen el fin de construir un proceso, producto o servicio que la gente utilizará. Una pregunta importante sería, se ha identificado el valor que aportará este producto o servicio para ellos? El patrocinador debería ser un usuario primario que comprendiera perfectamente lo que el usuario final necesitará o sea un product owner. Los proyectos pequeños no rehuyeren un alto expertise por parte de los product owners debido al alcance y tamaño del proyecto. La falta de comunicación en un proyecto grande es mayor, un proyecto pequeño permite manejar esto de una manera más cómoda. FACTOR CRÍTICO: el identificar el expertise real en un usuario.
3. Optimización (15 puntos). "Less is more". La esencia de un proyecto pequeño es un alcance pequeño, el tamaño hace realmente una diferencia en la tasa del éxito del proyecto. Como dice la ley de Paretto el 20% de la funcionalidad aporta el 80% del valor, por tal razón esta debe ser construida así. FACTOR CRÍTICO: contar con una lista de entregables determinados por el propio alcance del proyecto.
4. Mano de obra calificada (13 puntos). Tener mano de obra calificada no solo permite una mayor probabilidad de éxito, sino que conduce a mejores costos. Cuando se agrega personal a un proyecto este tiende a retrasarse, descrito por la Ley de Brooks. FACTOR CRÍTICO: la mayor parte de los miembros del equipo de los proyectos analizados tienen un nivel que va de competente a talentoso o virtuoso. Solo un 10% de los participantes fueron evaluados como no competentes.
5. Experiencia en gestión de proyectos (12 puntos). Debido a que los proyectos son pequeños, un administrador de proyectos puede administrar varios proyectos a la vez. FACTOR CRÍTICO: simplificar el procesos de gestión del proyecto para que pueda ejecutarse.
6. Métodos ágiles (10 puntos). La solución universal para el fallo en proyectos de desarrollo de sw son los métodos ágiles que manejan naturalmente proyectos pequeños. Y que utilizan el desarrollo iterativo. LOS PROYECTOS QUE SON RIGIDOS TIENEN UNA ALTA PROBABILIDAD DE CANCELARSE. FACTOR CRITICO: El Product Owner es el rol responsable de la ejecución del proyecto.
7. Objetivos claros (6 puntos). La claridad y el enfoque son esenciales para proyectos exitosos. Las standup meetings actúan como una junta de status del proyecto. Un enfoque ligero se centra en artículos de alto valor que mantienen la innovación sin sobrecargar administrativamente a la organización. FACTOR CRITICO: La comprensión de la visión de los stakeholders.
8. Madurez emocional (5 puntos). La madurez emocional se relaciona con el autoconocimiento tanto personal como social, la auto administración y el manejo de relaciones. “Confía en tu equipo, pero revisa los resultados. -Ronald Reagan”. FACTOR CRITICO: En su mayoría, la gente percibe como no sinceras a las personas. Solo el 4% las considera sinceras.
9. Ejecución (3 puntos). La ejecución es el arte de completar las actividades en función de un plan. Los proyectos pequeños dan la oportunidad al equipo de salirse de su zona de confort y tomar más riesgos. Los proyectos pequeños te permiten. Aun los proyectos pequeños tienen que terminarse en tiempo y medirse de manera adecuada.
10. Herramientas e infraestructura (1 punto). Cuando se trata de infraestructura menos es más. Menos herramientas ayudan a los pequeños proyectos a terminarse más rápido. La cuestión más critica de este aspecto es la infraestructura y procesos estándar para proyectos pequeños. La filosofía de buscar siempre tener menos herramientas y utilizar servicios de nube. NOTA . El pasar de pocos proyectos de muchos millones a pocos proyectos puede incrementar el número de proyectos de manera exponencial. Hay un límite en la capacidad de gestión de proyectos de los equipos,

En resumen

En resumen, muy pocos proyectos grandes son exitosos. En cambio los proyectos pequeños tienen más del 70% de probabilidades de terminar en tiempo, con el presupuesto establecido y que cuentan con los requerimientos de más valor implementados. No es fácil pasar de macro proyectos a pequeños proyectos, de soluciones complejas a soluciones sencillas.

Porque es útil este reporte para el anteproyecto de tesis

• Existe una gran cantidad de información sobre buenas prácticas y sobre proyectos fallidos. El Chaos Report es una de las fuentes más citadas en cuanto al éxito y fracaso de proyectos de software se refiere. Es un reporte fundamental que debe ser considerado en este tipo de proyectos.
• SCRUM mapa una buena parte de los 10 factores de éxito de una manera sencilla.
• Si lo analizáramos con PSP es probable que también manejara ciertos aspectos.
• Less is more, pero solo para los demás. En ocasiones reiteradas en el reporte se menciona el principio de “Less is more”. Sin embargo, cada uno de los factores de éxito mencionados en el reporte tiene otros 10 puntos críticos para el manejo de ese aspecto en particular. Al contrario que técnicas como Kanban con tres principios solamente, al final terminan siendo 100 principios que deben “gestionares” para incrementar la tasa de éxito de proyectos pequeños.
• El Standish Group tiene una serie de herramientas y software para gestionar los factores de éxito detectados. Por lo cual dentro de varios de los puntos se menciona y se dan ejemplos de la interfaz del software sugerido para festinar el factor.

Referencias

• The Chaos Manifesto 2013. (2013). Boston, Massachusetts. Retrieved from http://www.versionone.com/assets/img/files/CHAOSManifesto2013.pdf

¿Cómo mejorar la industria del Sw de manera sencilla?

De acuerdo al CHAOS Report 2012 el 43% de los proyectos son “Challenged” (fuera de tiempo, presupuesto, o alcance) y el 18% son cancelados. Y casi ninguno de estos fracasos es analizado. El no analizar estos errores impide que aprendamos, para no volver a cometerlos.

El transporte aéreo tiene una tasa de 0.05 muertes por cada mil millones de kilómetros recorridos. Es una industria que ha mejorado continuamente en la seguridad. El día de hoy es más segura que hace 20 años. Y la razón principal es que el 100% de los accidentes o averías importantes son analizados y convertidos a estándares de seguridad obligatorios. No sucede así en la industria del software. 

En su blog, Bertrand Meyer hace reflexiones contundentes sobre la diferencia entre las dos industrias. A pesar de que existen foros y sitios web que recopilan errores existen muy pocos analizados a profundidad, ejemplo de estos son: el caso de estudio de  Nancy Leveson sobre la Therac-25 y el análisis de Gilles Kahn sobre el accidente del Arian 5. Estos análisis son la excepción. Ambos casos han contribuido a un mejor entendimiento de la industria del software.

No existe una receta única para el éxito en los proyectos de software, generalizando, no existe una receta única para el éxito, como menciona Kough (2011),  “después de una vida en los negocios no puedo dar una receta del éxito, Lo que puedo hacer es hablar acerca de cómo perder. Y garantizo que cualquiera que siga esta fórmula será un perdedor seguro“. El detectar las causas de los fallos y evitarlas asegura en consecuencia mejores resultados. 

Patrick Eha (2012)  hace referencia a la pérdida de 440 millones de dólares por un error en un sistema automático de trading en Nueva York. Pero en ningún lugar se menciona cuales fueron las causas. El análisis sistemático de estos errores podría detectar causas clave: capacidad de los desarrolladores, métodos de calidad poco estrictos, procesos de seguridad deficientes. 

Existen muchas maneras de contribuir a la mejora de la industria del software, la investigación sobre temas de avanzada es una de ellas; Meyer(2009) enfatiza que la manera práctica, de baja tecnología es “ aprobar una ley que obligue a analizar de manera profesional cualquier fallo en un proyecto de software”. 

De inicio hay varias restricciones que deben ser consideradas: la iniciativa privada es renuente a hacer públicas sus fallas, por cuidar el prestigio de su empresa. La hipótesis es que una ley general a nivel nacional o estatal que requiera que analicen los proyectos de software implica cabildeo legislativo y una gran cantidad de recursos. Pero de inicio, los proyectos finalizados que tengan como fuente de financiamiento en México son públicos por la propia Ley Federal de Transparencia o sus equivalentes en los estados de la República. Estos proyectos pueden ser un inicio. Este sería el enfoque top down.

Planeamos hacerlo de otra manera. El desarrollo de casos de negocio basado en proyectos reales de software, así como la recopilación de artículos y bibliografía existentes sobre proyectos fallidos de software y la construcción de un observatorio de estos proyectos fallidos pueden contribuir para el conocimiento real. 

Casi cuarenta años después de la publicación del Mythical Man Month de Frederick Brooks seguimos fallando de la misma manera. Existen varias fuentes de información relacionadas con proyectos fallidos de software: libros, artículos, algunos análisis profundos de fallos en la industria del software en proyectos costosos o críticos a nivel mundial. Pero está información no está disponible para la industria del software de manera directa. Ello hace necesaria un mecanismo para la promoción de los aprendizajes obtenidos del análisis de proyectos fallidos. 

Un mecanismo para ello, puede ser la Gestión del Conocimiento puede proveer la base para que está información esté consolidada en un solo lugar y la creación de un Observatorio de Proyectos de Software Fallidos. Siendo una buena idea en el contexto Mundial, el propio contexto de México y Latino América, donde existe una gran cantidad de PYMES que desarrollan software y que cometen errores en su propio contexto requiere un análisis profundo de fallos de software en este nivel. Así pues el alcance se reduce y es más real. 

Referencias:

• Meyer, Bertrand (2009, Agosto). The one sure way to advance software engineering. Blog post consultado el 30 de julio de 2014 de http://bertrandmeyer.com/2009/08/21/the-one-sure-way-to-advance-software-engineering/
• Meyer, Bertand (2010, Mayo).  Analyzing Software Failure. Blog post consultado el 30 de julio de 2014 de http://bertrandmeyer.com/2010/05/24/analyzing-a-software-failur
• Patrick Eha, Bryan (2012, Agosto). Los errores informáticos más costosos. Artículo electrónico consultado el 30 de julio de 2014 de http://www.cnnexpansion.com/economia/2012/08/10/los-errores-informaticos-mas-costosos