El por qué de que muchos proyectos fracasen I: Waterfall

Es muy típico entre los desarrolladores de software criticar el proceso de desarrollo en cascada o Waterfall utilizando argumentos como: es antiguo, no me gusta o no funciona. Algunos más precavidos suelen decir que bueno, que es aplicable dependiendo del contexto en el que nos encontremos ya que nada es ni blanco ni negro. Estos últimos suelen continuar diciendo que depende de si el cliente tiene claro lo que quiere o no. En cierto modo, este último argumento parece tener sentido salvo por el hecho de que el cliente no suele tener claro al 100% que es lo que realmente quiere, no suele saber lo que realmente necesita (por eso acude a nosotros) y nosotros no entendemos por completo cual es su problema porque no estamos en su piel.

proyectos-desarrollo-software

En la universidad nos enseñaron que un desarrollo en cascada es el modelo de desarrollo más sencillo. Este modelo parte de una estructura lógica y una serie de pasos secuenciales o fases ordenadas en las que no podemos pasar de una fase a otra hasta no haber completado las anteriores. Primero obtenemos los requisitos y analizamos las necesidades de cliente,  continuaremos con una fase de más detalle en la que sacamos los requisitos del software,  la fase de análisis de esos requisitos es la siguiente para posteriormente crear un diseño,  una vez terminado continuamos programando la solución, realizamos pruebas y finalmente corregimos errores. Y una vez implantado el sistema, podemos entrar en una fase de mantenimiento y corrección de incidencias que vayan saliendo.

waterfall

Como veis una estructura totalmente lógica, basada en fases en las que hasta que no se produce la finalización de las mismas no podemos continuar, y ese hecho es lo que hace óptimo y da sentido a este modelo. Esto nos los cuentan en la universidad y también nos dicen que este modelo fue ideado por el Dr. Winston W. Royce. Puede que nos den más detalles, como por ejemplo que este modelo se le ocurrió un día que estaba en el servicio,  se cayó de la taza del váter y se dio un golpe  en la cabeza. Fue justo en ese instante cuando le vino a la mente este modelo de desarrollo como si de una visión se tratara.  A ese profesor deberían retirarle la licencia de conducir, por consumo de sustancias psicotrópicas.

KVmartyLic

También te pudieron contar que existían otro tipo de modelos como el modelo en V (que trataremos en otro post) y el desarrollo en espiral. El modelo en espiral le representaban con una espiral semejante a un garabato y no decían mucho más porque estaba fuera de temario. Recuerdo un profesor que terminaba la explicación diciendo “es lo que hace Microsoft, por eso sacan tantos service packs, para que los clientes detecten los errores, menudos listos” (obviamente, este hombre era linuxero).   Como consecuencia de esa falta de información, un joven universitario y friki pensaría seguramente que si el modelo en cascada fue ideado por El Dr. Royce, el modelo en espiral tenía que haber sido diseñado irremediablemente por el Dr. Who.

doctor who

La realidad es que el Dr. Royce publicó el artículo denominado “Managing the development of large systems” en 1970 tratando de explicar su experiencia personal acerca del desarrollo software en sistemas de gran tamaño. A lo largo del artículo expone un modelo al que no pone nombre y que representa en la Figura número 2 del mismo artículo. Royce habla en ese modelo de una serie de fases que recuerdan sin lugar a duda al modelo en cascada que conocemos actualmente, del que dice que se trata de una aproximación de alto riesgo y destinada al fallo. El artículo propone una solución iterativa e incremental donde la participación del cliente en el proceso de desarrollo es vital como solución a los problemas expuestos usando como base el modelo de la Figura 2. Aquí tenéis la copia  del artículo original de Royce que tras leerla me deja totalmente estupefacto: Managing the development of large systems.

perplexed

Creo profe, que me he perdido. ¿Cómo puede atribuirse a Royce el mérito de algo que estaba criticando en su artículo Original? En los años 80 del siglo pasado se inventaba en la ficción el condensador de fluzo y el Ministerio de Defensa de los estados unidos publicaba su nuevo estándar para desarrollo software, el  DoD-STS-2167 . Tras varias mejoras de este modelo de desarrollo copiando la idea alemana del modelo en V, se estableció el MIL-STD-498 que no deja de ser un modelo en V dividido en varias fases incrementales. La industria, siempre por detrás, fue copiando estos estándares de defensa USA hasta sacar el IEEE 12207. En un informe publicado en 1994 por el Standish Group se decía que en la aplicación de Waterfall en proyectos software de los últimos años, el 31,1% de los proyectos fracasaron y fueron cancelados, el 52,7% tuvieron un sobrecoste en tiempo y/o dinero y el 16,2% de los proyectos tuvieron éxito. A día de hoy, los datos no han mejorado y lo que hemos tenido es un “Waterfall” de derroche de dinero.

money_waterfall

Pero, ¿Qué problema tiene realmente Waterfall?, es un proceso ordenado, secuencial, lógico  y fácil de entender. El proceso en cascada sería eficaz si se dieran los siguientes supuestos:

  • Vemos el futuro y leemos la mente. Es decir, sabemos lo que quiere exactamente el cliente e incluso somos capaces de adelantarnos a lo que él no sabe que quiere. Sabemos lo que va a pasar durante el desarrollo, es decir, podemos predecir el futuro y misteriosamente no nos avergonzamos de decirlo en voz alta.

bola-de-cristal-leitao-bolsa

  • Seguimos el proceso. Es decir, no empezamos a codificar antes de tener todos los requisitos.  Una de las premisas de Waterfall es que no se puede empezar una fase sin cerrar la anterior. En la mayoría de los desarrollos, se solapan las fases empezando a desarrollar antes de que algunas de las fases anteriores se termine, porque evidentemente al no conocer el problema, no se cierran. A pesar de eso y viendo que se nos echa el tiempo encima, empezamos a programar como locos teniendo que volver a cambiar todo con grandes impacto en:
    • Funcionalidad
    • Arquitectura
    • Pruebas
    • Tu salud mental
    • Tu vida familiar
    • Tu mascota

gato cabreado Peque

  • Las pruebas se realizan al final del proceso. Me dirás, “no, si lo he probado y en mi ordenador funciona”. Si hacemos la fase de pruebas al final, esto lo que producirá inevitablemente es que:
    • Se detectarán errores y tendrás que corregirlos.
    • Se detectarán errores en la especificación, tendrás que corregirlos e importante: tendrás que rehacer todas esas partes del sistema que se verán afectadas.
    • Cada error detectado en fases tardías del desarrollo, tendrá un coste mucho más elevado que si lo hubieras detectado sobre el desarrollo. Imagina la cantidad de horas (dinero) de personas que estarán involucradas en cada error detectado.
    • La fase de pruebas, debido a todas estas correcciones, se dilata y obviamente entregaremos fuera de plazo.

      sin dinero en el bolsillo

En definitiva, me pregunto qué hubiera pasado si realmente hubieran hecho caso las advertencias de Royce.  Algunos scrum masters, al hablar de Waterfall me han dicho en alguna ocasión: “¿estás hablando de Waterfall?, ¿por qué estoy perdiendo mi tiempo hablando de eso?”. Sin embargo yo creo, que el saber no ocupa lugar, y saber de lo que estás hablando te pone en un mejor lugar a la hora de hacer críticas constructivas de cualquier cosa, incluso de tus propias creencias, las cuales posiblemente estén equivocadas también.

PDFicono EXTENDIDO

REFERENCIAS:

[1] DOD-STD-2167
[2] The Art of Lean Software Development: A Practical and Incremental Approach
[3] MIL-STD-498
[4] Managing the development of large systems

Enhorabuena, vas a llevar un equipo III: El anti líder autocrático

En los dos artículos anteriores hemos visto la evolución del líder en la empresa tradicional y en qué factores debería focalizarse un líder para lograr evolucionar hacia un líder transformacional. En este artículo vamos a ver cómo no debe ejercer un líder dentro de un contexto creativo como es el desarrollo software. Para ello quisiera centrarme en un tipo de liderazgo que a su vez es un anti-patrón de la colaboración: command and control o liderazgo autocrático.

tirano

Mientras preparaba el guión del curso que dimos de liderazgo en el que explicábamos este apartado, tuve una discusión con mi mentor acerca de si enfocar el curso en este sentido y mostrar el command and control como anti patrón: yo creía que no era posible en el mundo real porque  “nadie en su sano juicio se comportaría de una manera tan extrema”. Él me contestó, que realmente, los líderes autocráticos no se suelen poner un gorro de militar, poner cara de malas pulgas y gritarte al oído, sin embargo, en menor o mayor grado siempre hemos podido ver líderes que deciden que tareas debes hacer y cuáles no en cada momento. Son líderes que posiblemente no dispongan de información suficiente para tomar ciertas decisiones y hagan caso omiso a las argumentaciones del equipo para acometer las tareas de una manera u otra.

sargento

 A lo largo de los años, he podido ver casi todo tipo de líderes y ahora puedo decir que sí puede producirse este liderazgo extremo, hasta tal punto que he podido llegar a ver a un equipo altamente efectivo en casi fase de performing destruirse por completo en cuestión de semanas por la incorporación de un nuevo líder que no entendía los conceptos más básicos del trabajo en equipo.

guerra

El liderazgo autocrático, es sin duda uno de los anti-patrones de la colaboración: “yo digo tú haces”. Es un anti patrón porque se basa en el concepto de premio y castigo para lograr los objetivos. Este condicionamiento al que se ven sometidos sus colaboradores tiene efectos totalmente contraproducentes, entre ellos la desmotivación. Si lo pensamos fríamente, el ciclo vicioso que se produce en  este tipo de liderazgo es el siguiente:

  1. Yo como líder, no confío en el equipo o confío poco.
  2. Yo como líder les digo a mis colaboradores lo que tienen que hacer. Normalmente, ellos no conocen todo el contexto o parcialmente y yo no espero feedback o sólo espero feedback de algunas personas seleccionadas por mí.
  3. Cada colaborador realiza una interpretación y realiza las tareas orientado a su visión de lo que el líder le ha pedido.
  4. Los resultados no son exactamente los esperados y yo como líder debo volver a repetir lo que tienen que hacer, con lo cual mi desconfianza aumenta. Vuelvo al paso 1.

En un entorno de desarrollo software este ciclo carece de sentido,  todos los miembros del equipo deben jugar con la misma información, o al menos toda la que necesiten para poder lograr sus objetivos. Si todos los miembros del equipo disponen de la información, podrán alinearse de una forma más efectiva que si una única persona es la que toma las decisiones.

Dilbert_-_La_desconfianza_entre_jefe_e_ingeniero (1)

Una de las cosas que más me ha costado entender es por qué en las empresas, se produce y favorece el liderazgo autocrático. Le di muchas vueltas y pasaron por mi mente toda clase de posibles razones. Al cabo del tiempo volví a recordar lo que dije en antaño a mi mentor: “nadie en su sano juicio se comportaría de una manera tan extrema”. Y esta vez, me respondí a mi mismo con un rotundo “sí, si se dan todas o alguna de las siguientes circunstancias”:

  • La falta de formación debida a cualquiera de las áreas que se te puedan ocurrir. Por ejemplo, si el líder tiene poca experiencia o formación en liderazgo, o los maestros que ha tenido no han sido buenos. Sus actos de buena voluntad pueden generar conflictos sin resolver, los cuales alimentarán la desconfianza del equipo hacía él y entre los propios miembros del mismo.
  • La cultura de la organización. “Aquí siempre han sido así las cosas”.Para este caso y por no extenderme os dejo un vídeo de 1,5 minutos que explica cómo nace este tipo de paradigmas culturales: Como nace un paradigma.
  • La desconfianza, provocada por cualquiera de los motivos que se te puedan ocurrir. El líder no confía, quizá debido a su falta de formación o por cualquier otro motivo y se produce el ciclo de desconfianza mencionado en párrafos anteriores.

131007_desconfiado_700

La desconfianza, unida a la falta de información dentro de una cultura organizacional de rechazo y miedo al cambio, produce que el líder se pregunte “¿en qué situación me pondrá el equipo y como puedo salvarme de ella?” en lugar de preguntarse “¿Qué puedo hacer para que mi equipo logre los objetivos y evolucione?”. Esta situación es más típica de la que creemos y es lo que hace que se dispare el miedo a no ser válido o a no encajar.

microgestion

El liderazgo autocrático se puede producir también a veces debido a que no existe una distinción clara entre lo que es un gerente y un líder.  El gerente es necesario y es un elemento clave en una organización. El líder es algo distinto, su objetivo no es la eficiencia  de la organización si no que su objetivo es desarrollar al equipo. Si os fijáis, lo más importante de líder es el equipo.

lc3adder-o-jefe

Si como líder tu trabajo es lograr una serie de objetivos con tu equipo y lo que haces es limitarte a gestionar tareas, es lo mismo que si tu trabajo consistiera en llevar el mejor espectáculo del mundo a cada ciudad y lo que haces es simplemente cobrar por la entrada sin preocuparte de nada más. Obviamente, la contabilidad es necesaria para la supervivencia de tu espectáculo, pero tu objetivo es lograr que la gente quiera venir para que el gestor pueda hacer su trabajo.

el-mejor-espectaculo-del-planeta

Un gestor debe tener capacidades de eficiencia y eficacia. Eficiencia es hacer las cosas de forma óptima y eficacia conseguir el objetivo planteado. Para ser eficiente debe reducir recursos (o ampliarlos) y debe ser capaz de determinar los objetivos adecuados. El liderazgo sin embargo es una cosa diferente. Está siempre centrado en el equipo, de forma que consigue que el equipo sea eficiente y eficaz, ayudando al equipo a que alcance sus objetivos y respaldando y potenciandole.

el-super-gerente_thumb2

¿Puede una persona ejercer de gestor y de líder al mismo tiempo? Evidentemente sí, pero encontrará en muchas ocasiones objetivos opuestos  y debe hallar la forma de saber discernir entre ambos roles. El líder debe estar al servicio del equipo, esa es la idea fundamental que trataremos en el siguiente artículo. Trataremos un tipo de liderazgo denominado “líder de servicio”. Os invito a leerlo y reflexionar.

PDFicono EXTENDIDO

REFERENCIAS:

[1] Trabajo en Equipo. Dinámica y participación en los grupos (Guillermo Ballenato Prieto)