Métodos predictivos y adaptativos

Los métodos tradicionales de gestión de proyectos surgieron y maduraron en el mundo de la ingeniería civil y militar, cosas para hacer aviones, puentes y edificios. Allí donde el objetivo y los requisitos son claros (el “qué”), lo son los materiales, técnicas y herramientas (el “cómo”) y también se conoce el tiempo y el presupuesto (el “cuánto”). Lo que ocurre en la informática es que desde hace algún tiempo no se sabe bien qué hay que hacer exactamente, quién lo ha pedido, cómo hay que hacerlo y cuánto tiene que costar. Lo más que se sabe es que lo quiere para anteayer.

Regata de Schuylkill, de Thomas Eakins. Imagen de dominio público (en aquellos países en que los derechos de autor tienen una vida de 90 años o menos)

Aunque los precedentes se remontan a los últimos 1950, es desde hace unos diez años, a partir de la publicación del manifiesto Agile (2001) y de los libros de Cockburn y Highsmith, cuando en el mundo del desarrollo de software se introducen y documentan prácticas que permiten hacer las cosas de otra manera, a ser posible más eficiente y divertida. Algo que cubría en principio el ciclo de construcción de programas a medida, se va ampliando como un método (o al menos unos principios) de propósito general para gestionar proyectos, sobre todo en el mundo de la informática. Mario Gómez Molina hacía aquí hace poco alguna reflexión muy interesante acerca de ésto, a partir del llamado software libre.

Hay un excelente manual de gestión de proyectos que revisa lo mejor de ambos mundos (los métodos “tradicionales” y los “nuevos”) de forma equilibrada y pragmática, bien alejada de iconos ideológicos.  Es el de Robert Wysocki, Effective Project Managementque ya va por la sexta edición y más de 800 páginas. Es muy denso y detallado a veces, pero Wysocki no es un predicador ni un académico, sino un tipo madurado en la profesión (o sea, que ha hecho muchos proyectos) y con una reflexión práctica e irónica, sin perder el rigor; en fin, lo que a todos nos gustaría. Explica los métodos tradicionales (siguiendo como línea central el PMBOK, en inglés se pronuncia pímboc y queda menos litúrgico) y  la larga taxonomía de propuestas llamadas “adaptativas”, hasta la gestión “extrema” de proyectos. Lo hace con objetividad y evidencias, también con dudas y paradojas.

Wysocki viene a decir que las cosas no son lo que parecen (el libro empieza con una cita del fabulista Fedro, ya es ésto) y que todo depende, que es lo que dicen los gallegos y los ingenieros. La gestión de proyectos cambia y evoluciona a medida en que mayor es la incertidumbre y la complejidad, que a su vez correlacionan, y requiere de una u otra aproximación o de una mezcla de las dos, según el contexto y la historia. Ocurre que la línea entre los modelos tradicionales y los adaptativos no es discontinua.

O sea, mientras más claro es el objetivo, más poderoso y activo es el espónsor, más conocidos los productos y las herramientas, más pasivos son los usuarios y más estables son el mercado y la cultura de la empresa… entonces más sentido tienen los métodos “directivos”, “predictivos” o “estructurados”. En esta clase de enfoque, la preparación, la planificación, la documentación y el control son claves, para reducir los cambios y evitar (o manejar con mano de hierro) las desviaciones de alcance, tiempo y coste.

Mientras más ocurra lo contrario o más dudosas y abiertas sean las definiciones de todo lo anterior (empezando por “qué quiere decir éxito”), más aconsejables son aproximaciones adaptativas, en sus diferentes variantes. La gestión de proyectos adaptativa acepta y convive con la incertidumbre, el cambio y el error, planifica y entrega en fases y partes más pequeñas, mantiene una comunicación  continua con usuarios muy activos, los procesos de decisión son más participativos y los criterios de éxito más globales: importa lo que la empresa y el usuario podrá hacer o hará mejor con el producto, más que el cumplimiento en tiempo y coste de una determinada funcionalidad y su documentación exhaustiva. O sea, como diría Alicia en el País de las Maravillas: “Primero, la aventura. Luego, las explicaciones”.

Las culturas profesionales y empresariales cuentan. Los métodos adaptativos piden gente (analistas y jefes de proyecto) generalista y con visión del negocio y una mentalidad poco jerárquica. En la última entrada de su blog, Wysocki se pregunta: “¿sería posible que la misma persona fuese analista de negocio (business analyst)  y jefe de proyecto (project manager)?”

Nota: El pintor americano Thomas Eakins (1844-1916) fue remero él mismo y son frecuentes sus retratos y autorretratos individuales o en grupo, en especial de la célebre regata de Skuilkill en las afueras de Philadelphia. O sea, toca remar y hay varias maneras, pero todas son la misma.

Licencia Creative Commons
Este contenido, a excepción del contenido de terceros y de que se indique lo contrario, se encuentra bajo una Licencia Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported Licencia.

Acerca de josé ramón

José Ramón Rodríguez es profesor de dirección de las TIC y responsable de los programas de Business Intelligence de los Estudios de Informática, Multimedia y Telecomunicación de la UOC. Trabaja también como consultor independiente.
Esta entrada fue publicada en Profesión y etiquetada . Guarda el enlace permanente.

6 respuestas a Métodos predictivos y adaptativos

  1. Pingback: Bitacoras.com

  2. Emili dijo:

    Uno de los aspectos mas sorprendentes de la gestión del proyectos en la actualidad es la selección de la metodología a emplear. A pesar de la madurez del marco teórico, la enorme base de la literatura existente y la experiencia de miles de profesionales, para escoger metodología se ha evolucionado muy poco, y básicamente, la elección depende de dos o tres condiciones:
    Primero, la metodología de la empresa de servicios responsable de la gestión del proyecto. Cuanto mas grande y generalista es la empresa, mas estructurada es la metodologia.
    Segundo, el producto o solución a implantar. Cuanto mas “importante” es la empresa fabricante, mas metodología propia, que suele ser una “customización” de una metodología estructurada.
    Hay un tercera posibilidad que suele coincidir con empresa pequeña + desarrollo a medida o “proyecto web”. Entonces, las metodologías ágiles se imponen.

    Sin embargo, poco o nada tienen que ver con la elección, el grado de incertidumbre sobre los beneficios del proyecto que comentas en el post y menos el tipo de empresa o más específicamente el tipo de sponsor que tiene el proyecto.

    ¿Qué opinas ?

    • josé ramón dijo:

      Jajaja, me encanta, gracias Emili
      Varios comentarios rápidos:
      1) Como dice Pedro Navaja, “si naciste pa martillo,/ del cielo te caen los clavos”. O sea, cuando tiene algo llamado “metodología”, puedes echarte a temblar, muchas veces. Buscará el tipo de problemas o situaciones que se adapten a su amenaza, con independencia de las necesidades del proyecto, el cliente y el contexto.
      2) Mientras mayor es el proveedor, mayor es la amenaza. Creo que ésto es más cultural y europeo. He conocido en Estados Unidos fantásticos jefes de proyecto con cicatrices de guerra y no sólo en las compañías de servicio, también en las de producto, que dan allí servicios que aquí no se encuentran.
      3) One size doesn’t fits all. Se supone que los modelos de referencia de gestión de proyectos (empezando por el “pímbok”), se basan en que un jefe de proyecto experimentado, considerando los necesidades del proyecto y del entorno, establecerá el enfoque, los métodos y las herramientas, con una visión, con perdón, “estratégica”. Ese es su trabajo. Si no recuerdo mal (no lo tengo a mano) hasta en el PMBOK hay un proceso de gestión en el que se prevé hacer ésto, incluso, me parece que durante la planificación. Pero no debe caer en los exámenes del curso.
      Gracias. Seguimos.

  3. Pingback: Gestión de la infraestructura y las operaciones: una cuestión de músculo | iNFoRMáTiCa++

  4. Pingback: Informática polirrítmica (II) | iNFoRMáTiCa++

  5. Pingback: Informática polirrítmica (I) | iNFoRMáTiCa++

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

Puedes usar las siguientes etiquetas y atributos HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Leer entrada anterior
¿Se puede ser un programador toda la vida?

Esta semana en Twitter, hemos hablado sobre si es posible desarrollar toda una carrera profesional como programador o si hay...

Cerrar