Veintitrés signos de que un proyecto cloud puede tener problemas

Todos los lectores tienen su porcentaje de proyectos software exitosos y fallidos. Todos tienen batallas que contar. Pero para los responsables de proyectos software, tanto de empresa como de consultoría, existe sorprendentemente muy poca información actualizada sobre las causas que provocan excesos en el presupuesto y retrasos en la fecha de entrega.

Por supuesto, las consultoras de gestión que valoran su nombre aclamarán que su metodología solucionará el problema, y muy probablemente tendrán un gráfico bidimensional que mostrará cómo, gracias a su experiencia, serán capaces de volver a enderezar la situación.

Pero las cosas no son tan sencillas. Los informes de caos del Standish Group, una especie de CSI para los crímenes de TI, ofrecen una sólida evidencia de que el éxito de los proyectos de software depende de docenas de factores.

Después de realizar este tipo de análisis durante 16 años, Standish Group ha sido capaz de mostrar una deprimente consistencia en las áreas problemáticas y tasas de fallos en los proyectos. Estos datos trabajan bien con la implementación de software bajo premisas, tanto en extensiones de paquetes de software como en el desarrollo de aplicaciones a medida.

Desafortunadamente, es demasiado pronto para tener datos sólidos sobre los proyectos cloud. Así que estoy aventurándome y describiendo cosas a partir de 150 sistemas Salesforce implementados.

4 problemas en proyectos cloud dañinos, pero no fatales

Comencemos con la lista de cosas que contribuyen al éxito o fallo pero no parecen dominar la relación coste/plazos/satisfacción del cliente en proyectos cloud.

Requerimientos que no merecen la pena el coste o el esfuerzo. Esto es basura, pura y sencillamente, pero raramente descabala un proyecto cloud.

Formación inadecuada sobre un sistema o herramienta en particular. Las curvas de aprendizaje son dolorosas, por supuesto, pero si dispone de la gente adecuada es un coste que hay que pagar solo una vez.

Errores de configuración o codificación a nivel de módulo o "feature-unit". Son un problema, pero son bastante sencillos de encontrar y reparar, porque no están repartidos por todo el sistema. Se necesitan muchos de estos para hacer descarrilar un proyecto.

Falta de voluntad para recortar pérdidas. Fail-fast es una optimización importante, pero aguantar mucho tiempo normalmente no acabará con el presupuesto.

7 problemas de proyectos cloud que pueden solucionarse sobre la marcha

Lo siguiente es una serie de problemas que tienen un mayor impacto pero que afortunadamente pueden detectarse y corregirse antes de que los proyectos avancen demasiado.

Miembros del equipo que tienen problemas con la literatura matemática o los modelos de datos. Solucione esto en las entrevistas y procesos de selección.

Miembros del equipo con problemas de comunicación verbal y escrita, especialmente cuando se trata de resolver problemas. Erradíquelo a base de pruebas.

Miembros del equipo agobiados que no pueden cumplir con sus compromisos de desarrollo, revisión y pruebas.

Errores de codificación, configuración o integración que se expanden a múltiples objetos o servicios cloud. Puesto que estos errores y omisiones requieren cooperación y un entendimiento común entre diversos miembros del equipo, se pueden minimizar mediante un sistema de documentación compartida y técnicas de desarrollo iterativo e incremental.

Tener muchos jugadores “B” y no suficientes “A”. Esto es neurocirugía, no hacemos salchichas. No hay sustituto para el talento, la actitud y el conocimiento. Los jugadores “B” aumentarán los costes, sin importar lo pequeñas que sean sus nóminas.

Ampliar el equipo en distintas zonas horarias. Recuerde, la distancia es mortífera.

Asunciones erróneas o pensamientos mágicos sobre la forma en que trabajan los objetos y RDBMSs (pensar que las actualizaciones entre objetos sencillamente suceden, por ejemplo, o que el deduping sucede de forma espontánea). Esto nos llevará a la muerte, “Pero por supuesto el sistema se encargará de mí…”.

12 problemas de proyectos cloud que debe solucionar nada más verlos

Esta categoría final incluye los problemas serios y perniciosos que deben ser identificados y corregidos antes de comenzar el proyecto. Muchos pertenecen a la categoría “problemas etéreos”, especialmente aquellos relacionados con la comunicación, políticas y procesos empresariales.

Falta de comprensión acerca de la calidad y significado de las fuentes de datos existentes. Puesto que el coste de la limpieza, transformación e integración de datos puede moverse fácilmente de un orden de magnitud a otro, es desastroso realizar estimaciones de coste o tiempo sin tener acceso a algunos datos reales y gente que pueda interpretarlos.

Asunciones incorrectas sobre el acceso a los datos o sistemas externos. Esto es algo que puede hacer crecer los problemas (y costes) rápidamente.

Incapacidad o desgana de los comités de evaluación de seguridad y otros sistemas para aprobar lo que necesita. Aquí hay que añadir las dudas, retrasos y a veces los requerimientos sin sentido.

La desgana de la administración para involucrar a los usuarios adecuados en las fases de diseño, creación de prototipos, implementación o puesta en funcionamiento. Este gran problema de primer orden sucede con una frecuencia sorprendente, a menudo acompañado de “o se hace a mi manera o te vas a la calle”.

Débil o falsa defensa de la gestión. Algunos ejecutivos tienden a comportarse como si garantizar el presupuesto fuese su máxima responsabilidad, cuando de hecho es solo el comienzo de un proceso que abarcará muchos trimestres. Un responsable del presupuesto poco atento es tan peligroso como un conductor distraído.

Una incapacidad o falta de voluntad para afrontar los hechos o comunicar malas noticias a tiempo suficiente para poder solucionarlas. Diga “Sí” o “No hay problema” demasiadas veces y pronto tendrá un gran problema.

Esperar que gestionar un proyecto software sea como implementar un hardware. Esto es algo que sencillamente le explotará en las manos.

Mantener proyectos a largo plazo con equipos grandes e interdependientes y productos finales Big Bang. Mantenga las cosas pequeñas, sencillas y separables.

Escribir requerimientos enfermizos o definir necesidades sin precisión.

Escribir requerimientos que sencillamente no importan, a menudo porque se añadieron a una documentación que no era práctica.

Procesos empresariales que evolucionan rápidamente, en particular si se da un gran cambio organizacional. La importancia se duplica en el caso de las desinversiones o fusiones y adquisiciones; durante esos momentos tan tumultuosos, solo se acometen proyectos para la reconstitución, supervivencia del sistema y continuidad empresarial.

Procesos empresariales desconocidos o incorrectamente dirigidos. Hemos visto casos en los que los responsables estipulaban procesos empresariales que no habían sido reales durante años, o que incluso nunca habían existido antes.

Recuerde La cláusula Van Halen (o el color de los M&M) para resolver problemas

Probablemente piense que voy a hablar incansablemente de “agile development”. (¿Yo? ¡Nunca!) En su lugar, tomaré una táctica de, entre todas las cosas, relaciones públicas.

Como líder de un proyecto, necesita estudiar todos y cada uno de los 23 puntos aquí listados. Pero no se puede permitir lograrlos todos. Va a tener que priorizar. Wargaming es una herramienta de PR que ofrece la forma más procesable de "análisis sensitivo", la clasificación definitiva.

La primera parte del ejercicio identifica las cinco primeras cosas que sabe que podrían acabar con su proyecto y desarrolla una contingencia o medida correctiva para corregirlas. La segunda parte encuentra las tres cosas más importantes que podrían aparecer por sorpresa para dañarle. Con esta segunda lista podrá situar algunos “canarios en la mina de carbón” para que actúen como primer indicador de problemas en el sistema (por dar un ejemplo que no sea de TI, piense en Van Halen y sus M&Ms marrones).

Un típico ejercicio de juegos de guerra no debería llevarle más de una hora. Debería ser un juego cooperativo que involucre tanto a la administración como al equipo (tanto plantilla como consultores) y que se desarrolla en cuatro situaciones clave: mientras finaliza la definición del trabajo, plazos y presupuesto; nada más comenzar el proyecto; justo en la mitad del proyecto (en días o euros, lo que suceda primero), y antes de cualquier reunión tipo "el proyecto va bien" o “go/no go”.