La clave para aplicar metodologías ágiles correctamente

Definiciones
jueves, 25 de junio de 2015

Tras casi 20 años en el mundo de la consultaría Business Intelligence, como consultor y como cliente, he cometido todos los errores que se pueden cometer... como consultor y como cliente... Eso me permite hablar con cierto conocimiento. Actualmente, no soy exactamente lo uno ni lo otro, por lo que puedo desvelar algunos secretos de tirios y troyanos con cierta libertad :-)

La semana pasada hablaba de las "metodologías ágiles" de un modo algo teórico. Hoy trataré de explicar, siempre desde mi personal punto de vista, la cuestión diferencial de este tipo de proyectos y algunas consecuencias prácticas muy importantes. Hablare de LA CUESTIÓN.

En último artículo decía que los proyectos ágiles debían entregar resultados de una manera frecuente, continua e incremental. Esa es la clave. De modo orientativo, hablaba de entregar resultados cada 3 o 4 semanas... Pero podrían ser igualmente 5 o 6... A estos periodos de tiempo se les suele denominar "sprints" o "iteraciones" (yo prefiero este último término).

El contrato

Antes de hablar propiamente de las iteraciones conviene recordar cómo se contratan los proyectos (ágiles o no), porque una cosa es decir que cliente y consultor deben colaborar codo con codo con independencia del contrato, y otra cosa es hacerlo. No es lo mismo predicar que dar trigo.

Tradicionalmente han existido y existen dos tipos de contratos claramente diferenciados:

  • Contratos por horas. Oh, los proyectos por horas. Escasos y deseados. Es la gloria de cualquier consultaría. Cualquier retraso es siempre compensado por el cliente. Si después de 5 meses el proyecto aún no está terminado, es porque falta análisis, diseño, pruebas o lo que sea. Por supuesto, no es difícil de imaginar que el cliente evita contratar proyectos por horas, y este tipo de contratos se reserva para mantenimientos, pequeños evolutivos, bolsas de horas, o simple subcontratación de recursos....

  • Proyectos a precio cerrado. En este caso, el alcance y el precio es acordado al principio del proyecto y cualquier retraso es asumido por el consultor (de los "adelantos" ya tal). Teóricamente es todo muy sencillo: Solo es necesario calcular los materiales que harán falta, las nóminas del equipo, añadir un margen, etc. Este es, evidentemente, el método preferido por el contratador.

No desvelo ningún secreto al señalar los efectos indeseables que generan estos tipos de contratos. Las consultoras están obligadas a sobrevalorar el esfuerzo de cualquier proyecto para protegerse de posibles retrasos. Y los clientes utilizan la fuerza que les proporciona la aceptación del proyecto para alargarlo y pedir extras a base de lecturas imaginativas del "alcance". O requerimientos de última hora. O por mis cataplines:

SIN ESTO QUE PIDO AHORA EL PROYECTO NO SIRVE PARA NADA (Super jefe en la reunión de cierre)

Por supuesto, ninguna consultora puede tolerar tener un equipo de 5 o 6 personas durante un par de meses cerrando flecos y sin facturar. Conozco un amigo que ha visto equipos de 10 personas trabajando "gratis" (de manera no planificada) durante meses. Por supuesto, se buscarán el modo de facturarlos y al cliente no le saldrá gratis (se facturará en el siguiente proyecto, ya sea sobreestimando los costes o reduciendo la calidad).

En serio, clientes y consultoras, los REYES NO EXISTEN.

Esos contratos tradicionales tienen sentido para contratar la construcción de una autopista o para hacer los planos de una casa. El alcance y los requerimientos en esos casos están claros, y clientes y proveedores han participado en proyectos similares. En el caso de la consultaría tecnológica (estoy hablando de proyectos de desarrollo, y específicamente de Business Intelligence), el alcance esconde sorpresas y los requerimientos se van descubriendo tras cada reunión. El grado de indefinición y los riesgos son mucho más elevados en nuestro caso. Si no cambiamos la manera de trabajar, con independencia del tipo de contrato escogido, es solo cuestión de tiempo que clientes y proveedores se estén engañando mutuamente... y sabiendo mutuamente que son mutuamente engañados. No os riáis que hablo en serio. Conozco un amigo que pedía 10 manzanas a 1 euro porque necesitaba 2 sandías de 5€. En fin...

Por lo anterior, creo que la apuesta por las metodologías ágiles ha de reflejarse de algún modo desde el contrato mismo. En caso contrario, más pronto que tarde empezarán a surgir bandos y tiranteces que afectarán negativamente al proyecto... Más controles, más seguimientos, más listados de cosas con las que defenderse o atacarse.... Y menos entregas frecuentes.

La solución

DISCLAIMER: La solución que propongo es puramente teórica, y forma parte de una guerra que de momento voy perdiendo. No penséis que hablo por experiencia. Cualquier cambio es complicado, y clientes y consultoras seguirán empleando sus viejas armas para defender lo que creen que los beneficia. Se desconocen los efectos a largo plazo. Si estás embarazada o crees que puedes estarlo, consulta tu abogado. No emplear sobre lactantes.

La solución es trabajar por iteraciones. No es un proyecto a precio cerrado (pero se le parece), ni es un proyecto por horas o por jornadas (pero se le parece).

En un proyecto por iteraciones el precio es conocido (lo que gusta al cliente... y también al consultor) y la duración también es conocida de antemano (lo que gusta al consultor... y también al cliente).

La teoría es relativamente sencilla:

  • En lugar de planificar un proyecto de 9 meses con 3 meses de análisis, 3 meses de diseño, y 3 meses de construcción, debes planificar un proyecto de 9 iteraciones de 1 mes cada uno.
  • Cada una de estas iteraciones tendrá un entregable. Insisto, cada iteración debe tener un entregable funcional. No un diseño o un powerpoint. Software que funciona. Debemos entregar valor para el cliente en cada una de las iteraciones.
  • Debemos empezar desarrollando aquellos aspectos más importantes y prioritarios (siempre y cuando estén suficientemente definidos).
  • Cada iteración tendrá su propio alcance. Al comenzar la iteración, ese alcance debe estar suficientemente acotado (sí, hemos de ser capaces de describir suficientemente el resultado de un mes de trabajo).
  • La iteración se cierra en la semana prevista, por definición. Se entrega lo que ha podido hacerse. El cliente debe revisarlo, trasmitir su feedback y replanificar el proyecto.
  • El proyecto finaliza 3 o 4 semanas después de finalizar la última iteración. Punto. Se abonan todas las facturas y clientes y consultores se dan un beso.
  • Si es necesario, se contratan más iteraciones y se dan nuevos besos.

Este modo de trabajo tiene algunas implicaciones positivas que a mi me resultan evidentes (y a ti no sé):

  • Los consultores no necesitan sobreestimar costes ni los clientes necesitan un abogado para escribir o interpretar los requerimientos.
  • Clientes y consultores pasan a ser un mismo equipo. No hay razón para mirar el contrato ya que ambos saben que finalizará en la fecha prevista.
  • El equipo conoce el ritmo de trabajo. Cada mes hay un entregable, y existe visibilidad sobre lo que se ha hecho (y sobre lo que no ha podido hacerse).
  • Por lo anterior, es fácil replanificar mensualmente el trabajo y tener una idea realista sobre lo que se alcanzará al finalizar el proyecto (y lo que no y deberá renunciarse a ello o posponerse para siguientes proyectos).
  • El esfuerzo de "seguimiento" y "perseguimiento" es menor. No andamos valorando si tal funcionalidad está al X%. Eso es siempre una farsa. Deja al equipo de desarrollo trabajar y al finalizar la iteración tendrás el resultado.

Y algunas implicaciones negativas... ¿negativas?

  • El cliente debe involucrarse más. Debe ir definiendo y validando el proyecto durante mucho más tiempo. Esto no es como comprar un coche que te entregan las llaves cuando está listo. En el caso de los proyecto IT, el coche lo has de construir tú...
  • El consultor no puede escudarse en un contrato o en un acta para no hacer algo que solicita el cliente. El consultor ha de ser flexibile, diseñar y construir sabiendo que los requerimientos pueden cambiar. Cambiarán seguro, de hecho.

Este método no te asegura el éxito del proyecto. Únicamente te asegura descubrir pronto que vas por el buen o mal camino. Si eres cliente, en la tercera o cuarta iteración ya debes tener una idea de la capacidad de trabajo del equipo. Debes decidir si te conformas con ello o decides cancelar el proyecto y probar con otro proveedor. La alternativa no es, desde luego, esperar al último día para decir que además quieres esto u aquello. Lo verdaderamente prioritario ya deberías tenerlo desde hace meses, y lo que falta por hacer, probablemente, no sea tan importante como piensas...

Sin duda, al terminar el proyecto quedarán cosas por hacer y otras podrían mejorarse. Es estéril discutir en ese momento si se debe a la mediocridad del equipo de desarrollo, a la indefinición de los usuarios. Unos dirán que el cliente no proporcionó los medios adecuados, otros que el proyecto estaba mal planificados desde el inicio, etc... Con toda seguridad, la causa es la suma de todas esas cosas al mismo tiempo. Usuarios, clientes, gestores y técnicos son culpables por igual de resultado. Cada uno tiene su parte de culpa y su parte de mérito. Por eso son un equipo.

Esos problemas, de existir, deberían haberse detectado y gestionado durante el proyecto. Si eres cliente, y crees que la culpa es de los consultores, trata de buscar soluciones cuanto antes. Los problemas no se resuelven solos. Si no te gusta su trabajo, échales al tercer mes, o al cuarto, o al quinto, o al sexto... O propón soluciones. Involucrarte y pon más recursos. En el único momento que no puedes quejarte es al final del proyecto. En ese momento la culpa es solo tuya por no haberlos echado antes.

Lo que queremos evitar son cosas así:

¿Cómo puede ser que un proyecto, tras 10 años, no esté en producción? RT si te parece inadmisible. A las pocas semanas debería estarlo.

Las claves

Tras el sensacionalista título del artículo, me veo obligado a señalar dos claves (distintas que las que señale la semana pasada, por cierto):

  • Entrega frecuente de resultados. Hemos de ser transparentes. Mostrar cada mes hasta donde hemos llegado y tener un listado actualizado realista de hasta donde llegaremos.
  • Flexibilidad. Los requerimientos se van descubriendo a lo largo del proyecto. El cambio es la norma. Hemos de ser flexibles para hacer cosas de más y que nadie había pedido, y flexibles para hacer cosas de menos que no son tan importantes o tal vez son demasiado complicadas. Eso nos obliga a ser creativos y buscar alternativas. En equipo todo es mucho más fácil de lo que parece...

Me dejo muchísimas cosas en el tintero. Gestión de expectativas, listado de funcionalidades, la importancia del feedback de los usuarios, los tests, el calendario, los mantenimientos, y cosas así. Tal vez otro día.

Me despido con el último vídeo promocional de Crono que hemos preparado. Espero que os guste. Crono es el software de Business Intelligence más fácil de usar y creado pensando en el usuario de negocio. (¡y desarrollado siguiendo metodologías ágiles, por supuesto!).


Si te ha interesado lo anterior, te encantará este otro vídeo sobre cómo construir un cuadro de mando con Crono Business Intelligence.