Hablemos de agentes (VII): algoritmos de planificación

Y llega el momento de tratar lo que, quizá, sea el elemento más diferencial de los nuevos agentes: la planificación que, como veremos, tiene mucho que ver con el razonamiento y, de alguna manera, la 'inteligencia'. 

Planificación y algoritmos de planificación

Intuitivamente todos tenemos una idea de lo que es la planificación: ante un problema o una labor, definimos las acciones a realizar y establecemos de alguna manera la secuencia lógica de esa realización.

En la vida corriente, o también en el ámbito de la dirección de proyectos, la planificación implica también otros aspectos como la asignación de recursos, estimación de presupuestos y el establecimiento de plazos temporales.

En el caso de los agentes inteligentes, prescindimos, al menos habitualmente, de lo que tiene que ver con presupuestación y con el marco temporal.

La planificación, en el mundo de la inteligencia artificial y la robótica, tiene mucho más que ver con la decisión de las tareas a realizar y su secuenciación. En cierto sentido, se trata más de definir una estrategia de actuación para resolver un problema o conseguir un objetivo que de una verdadera planificación y, por tanto, tiene tiene una estrecha relación con la resolución de problemas, el razonamiento y la 'inteligencia'.

Los algoritmos de planificación son esenciales desde hace muchos años en la inteligencia artificial, quizá la inteligencia artificial más clásica y, por ejemplo, ocupa numerosos capítulos del famosísimo libro de texto: 'Artificial Intelligence: a modern approach' de Stuart Russell y Peter Norvig.

En lo que sigue, vamos a revisar una panorámica de los algoritmos o estrategias de planificación orientados hacia los nuevos agentes de la 'Agentic AI' en cuyo núcleo se encuentra un gran modelo de lenguaje (LLM, 'Large Language Model').

Y seguimos principalmente, como en toda esta serie de posts sobre agentes, el contenido del libro 'Building Agentic AI systems' de Anjanava Biswas y Wrick Talukdar. En dicho libro, los autores nos presentan siete algoritmos / estrategias, estructurados conforme a una clasificación un poco paradójica de 'practicidad'. A falta de una mejor clasificación, también los revisaremos aquí de esa forma, por orden creciente de practicidad.

Algunos algoritmos no muy prácticos

En esta no muy lucida categoría de algoritmos poco prácticos, los autores nos presentan bastante brevemente, cuatro algoritmos, en general muy famosos.

• STRIPS ('Stanford Research Institute Problem Solver'): Un algoritmos que se remonta ya a 1971 y que está respaldado por un lenguaje formal del mismo nombre. En STRIPS se trabaja con estados y acciones definidas mediante predicados lógicos. Hay un estado inicial y varios posibles estados objetivo. Además están definidas la serie de acciones con las precondiciones para que se puedan llevar a cabo y las poscondiciones tras su aplicación. En él, una plan es una secuencia de operadores que deben conducir a un estado final. Este algoritmo resulta poco adecuado para trabajar con los LLMs de los modernos agentes, ya que las interacciones en lenguaje natural no se reducen fácilmente a las condiciones cierto/falso que precisa STRIPS.


• A^*: Un algoritmo muy habitual en robótica para definición de caminos en el caso de robots móviles. Se apoya en grafos, existiendo un nodo inicial y un nodo objetivo. Asociado a los diferentes arcos existe un peso (o coste) y el algoritmo se ocupa de encontrar el recorrido en el grafo que representa el menor coste (donde, con frecuencia, el coste es la distancia y, por tanto, lo que hace es calcular el camino más corto). Estos algoritmos necesitan esa estimación clara del coste de una acción y una heurística para estimar el resto del coste en un punto dado (el uso de heurísticas es para hacer más eficiente computacionalmente el algoritmo). Esa estimación de costes, muy numérica, resulta problemática en el caso de interacciones basadas en lenguaje natural.


• GraphPlan: Otro algoritmo basado en grafos donde se representan en capas las acciones y sus efectos en el tiempo. En el caso de uso de modelos basados en lenguaje, no es fácil encajar las interacciones en capas ni establecer relaciones causa-efecto claras.


• MCTS ('Monte Carlo Tree Search'): Un método donde el árbol de planificación se va creando y expandiendo mediante muestreo aleatorio en el espacio de búsqueda y tomando las ramas más prometedoras. No resulta práctico para su uso en agentes basados en LLMs por dos motivos: porque cada simulación requeriría invocaciones al LLM, haciéndolo muy costoso computacionalmente, y porque en el caso de interacciones en modelos de lenguaje el espacio de estados es tan enorme que no resulta eficiente su exploración aleatoria.

Para el lector avezado en inteligencia artificial, algunos o todos los nombres de algoritmos anteriores le resultarán familiares, porque se trata de algoritmos clásicos, con notable éxito en ciertos campos de aplicación o ciertos momentos de la historia de la inteligencia artificial. Sin embargo, para trabajar con los modernos agentes de la 'Agentic AI', cuyo 'núcleo' es un gran modelo de lenguaje, quedan descartados.

Algunos algoritmos moderadamente prácticos

En esta categoría intermedia de algoritmos moderadamente prácticos, los autores nos hablan de un único algoritmo: Fast Forward planning o FF planning.

Se trata de un algoritmo que hereda algunas ideas de otros como STRIPS o GraphPlan. Utiliza una búsqueda heurística en una versión simplificada del problema.

Los autores estiman que su orientación a objetivos pudiera  ser usada en el caso de agentes basados en LLM, aunque requeriría adaptaciones para un manejo efectivo del lenguaje natural.  De todas formas, también presenta dificultades ya que las heurísticas que utiliza son de tipo numérico que, como ya hemos comentado en otros algoritmos, no se adaptan bien al tratamiento mediante lenguaje natural.

Resumiendo bastante, los autores entienden que FF planning se puede utilizar en agentes basados en LLM pero sometiéndolo a una serie de modificaciones.

Los algoritmos más prácticos

Y llega el momento de ver las opciones mejores o más prácticas. En este caso se nos habla de dos opciones: una planificación basada en LLMs y HTN. Veámoslas brevemente

Planificación basada en LLMs

Esta forma de planificación prescinde de estados y acciones formales, costes, grafos y otros elementos habituales en los algoritmos de planificación tradicionales que hemos revisado más arriba. En su lugar, trabajan en lenguaje natural y los estados y acciones se describen en lenguaje natural.

Cuando planificamos con grandes modelos de lenguaje, estamos asumiendo que estos modelos son capaces de entender objetivos complejos, generar los pasos adecuados para conseguirlos y adaptar esos pasos según cambia el entorno o la situación.  

Aunque hace un tiempo esta posibilidad hubiera podido parecer poco creíble, lo cierto es que si se atiende a lo ya conseguido en modelos razonadores, parece un opción muy válida, al menos para ciertas situaciones o tipos de problemas. 

De todas formas hay que tener en cuenta que también tiene sus limitaciones de las que nos advierten los autores: los LLMs no acaban de adaptarse bien a planes en que hay elementos o restricciones numéricas o temporales y tienden a ser demasiado optimistas y poco prácticos si no se establecen las debidas restricciones.

A cambio se desenvuelven bien, o al menos mejor que los tradicionales, en situaciones con incertidumbre, información incompleta o estados nuevos.

HTN ('Hierarchical Task Network')

Es una estrategia de planificación que trabaja mediante la descomposición jerárquica de tareas en subtareas aunque, eso si, a diferencia de algoritmos clásicos como STRIPS que trabaja con unas acciones primitivas muy claramente definidas, HTN trabaja con tareas más abstractas y luego va descomponiendo en otras más concretas.

Se trata de un enfoque flexible, que tiende a reflejar el modo de planificar humano y que escala y se adapta bien a problemas complejos 

La asignación de recursos: las herramientas, de nuevo

Al inicio de este post, al comparar el concepto de planificación del ámbito de la dirección de proyectos con el significado de planificación en inteligencia artificial, decíamos que no se tenía en cuenta ni tiempos ni costes y sólo parcialmente recursos. Estrictamente hablando, no es imposible incluir de alguna forma tiempos y costes en una planificación de inteligencia artificial, pero no es lo más habitual ni definitorio.

¿Y los recursos? Bueno, no suelen usarlos tanto en el sentido, por ejemplo, de las personas, equipos o empresas necesarias para realizar una tarea. Pero sí hay otros recursos que hay que tener en cuenta: las herramientas.

En efecto, hemos visto los mecanismos de planificación que son, en cierto sentido, mecanismos de pensamiento y razonamiento. Pero para que esto resulte útil en la mayoría de los casos, y para que el agente sea realmente un agente, debe poder actuar, cosa que, como explicábamos en el post anterior, lo hacen a través de las denominadas herramientas ('tools') que, de esta forma, se constituyen en los recursos necesarios para realizar una tarea.

Así que los agentes, también deben de ser capaces de conocer y razonar sobre las herramientas que tienen a su disposición, sabiendo de alguna forma lo que pueden y no pueden hacer. Y la propia planificación debe utilizar ese conocimiento sobre las capacidades disponibles para definir las acciones a llevar a cambo.

La planificación en la práctica de desarrollo

¿Y cómo se lleva todo esto a cabo en tiempo de desarrollo? ¿Cómo se construyen este tipo de soluciones?

Bien, en la obra citada, los autores ejemplifican casi todos los aspectos usando el framework CrewAI.

Además, y para aumentar un poco el abanico de posibilidades, también dan como opciones el uso del conocido LangGraph (parte de LangChain) o AutoGen.

O sea, que no sólo disponemos de grandes modelos de lenguaje, también existen ya frameworks que permiten construir el resto de elementos de un agente, incluyendo la planificación.

Conclusiones

Hemos visto cómo una parte nuclear de un agente es la planificación, algo ya tradicional en el campo de la inteligencia artificial pero que es necesario revisar, aportar nuevos algoritmos y estrategias, para realizar una planificación expresada en lenguaje natural y que se crea con el apoyo de un gran modelo de lenguaje. 

Artículos de este blog relacionados

• Hablemos de agentes (VI): herramientas
• Hablemos de agentes (V): reflexión e introspección
• Hablemos de agentes (IV): sistemas multi-agente
• Hablemos de agentes (III): arquitecturas reactivas, deliberativas e híbridas
• Hablemos de agentes (II): auto-gobierno, agencia y autonomía
• Hablemos de agentes (I): concepto, contexto y tres características esenciales

Reflexión, preparación e innovación

¿Preparación?

¿Para la innovación?

Vivimos orientados a la acción. O al menos, la practiquemos realmente o no, encumbramos esa acción, el moverse, el hacer cosas. Es la forma de avanzar, de conseguir objetivos. Y demuestra en cierto sentido nuestra valía, nuestro empuje, nuestra capacidad para dar resultados.

Y es cierto. La acción es muy importante. Es vital. No se consiguen resultados sin acción. No vendemos sin acción. No ejecutamos proyectos sin acción. Y no innovamos sin acción.

Sin embargo, así lo creo, hay que defender un cierto espacio para la reflexión y la preparación.

Está ya abundantemente descrito que una cierta dosis de aburrimiento promueve la creatividad porque libera nuestro cerebro y le permite moverse en sendas diferentes a la de la acción inmediata, la actividad compulsiva y explorar a cambio nuevas opciones.

A pesar de lo anterior, que me resulta creíble, se me hace difícil abogar por el aburrimiento. No me cuesta sin embargo, porque estoy convencido de ello, abogar por la preparación de esa acción, por la reflexión, por la planificación y por la estrategia.

Incluso para enfrentarte a actividades donde domina la incertidumbre, como es la innovación o el emprendimiento, creo que es necesaria, quizá más que nunca, esa estrategia y esa planificación. No es esta apuesta por la reflexión y la planificación una postura que sea fácil de defender hoy en día donde todos los discursos parecen llevar a la acción inmediata y al famoso fracaso rápido y barato.

Yo creo firmemente, sin embargo, en la importancia de la preparación. Una preparación, eso sí, bien entendida: una preparación que es abierta, que no es eterna, que no es paralizante. 

Que es abierta porque es plenamente consciente de que parte, a veces incluso mucho, de lo pensado y planificado, puede sufrir revisiones, en ocasiones profundas,  ante el choque con la realidad, ante la realimentación de clientes, del mercado o del propio devenir del proyecto. Una preparación y planificación que es abierta porque no se enamora de sí misma y está dispuesta a rehacerse, si es necesario y cuando es necesario.

Y una  preparación y planificación que no son paralizantes, que no se enroscan sobre sí mismas en un pensamiento eterno que no lleva a nada sino que, por el contrario, son tan breves como sea factible. Una preparación y una planificación que identifican y promueven los siguientes e inmediatos pasos y que están dispuestas a planificar a corto plazo si no hay información suficiente para hacerlo a largo.

Eso es: abogo por la reflexión, la preparación y la planificación... incluso en innovación.

Y hay veces que esa reflexión y ese pensamiento se producen en actividades que quizá no valoramos en su justa medida.

Luis Pérez-Breva, autor del libro 'Innovar' que, además, subtitula de forma muy significativa, 'Un manifiesto de acción', nos identifica en su obra, al menos dos puntos donde hay preparación y reflexión aunque quizá no seamos plenamente conscientes de ello.

El primer caso es ante la exposición de un proyecto de innovación, sea para captar nuevas personas para el equipo o sea para atraer a inversores. El autor resalta la importancia de preparar la presentación del proyecto, no ya por el resultado que esperamos de esa presentación, sino por la preparación en sí misma, porque nos ayuda a nosotros mismos a clarificar nuestro propio proyecto. Así, en un punto de su libro nos dice:

prepararte para exponer tu proyecto es valioso en sí mismo, lo acabes presentando o no.

Nótese: "lo acabes presentando o no". Lo que quiere resaltar, precisamente, es que la reflexión sobre el propio proyecto es una actividad de valor.

Hay otro punto al final del libro en que de nuevo nos habla de reflexión y que resuena fuertemente con mi experiencia personal.

Es cuando nos habla de cómo documentar la innovación, una actividad que quizá está apartada del 'glamour' de la literatura sobre innovación y emprendimiento, pero que tiene valor, no sólo como registro de lo avanzado y como herramienta de trabajo sino, lo que es quizá más importante, por lo que de reflexión implica.

En efecto, personalmente yo siempre he dicho, literalmente, que "pienso cuando escribo". Por supuesto, es una afirmación ligeramente exagerada. Pienso en otras formas y ocasiones pero sí es cierto que el escribir en sentido amplio, ya sea un texto, un diagrama o una PPT, me ayuda muchísimo a estructurar las ideas y a avanzar en el pensamiento.

Y Luis Pérez-Breva debe experimentar algo parecido, al menos de vez en cuando, porque nos dice:

A veces el acto de documentar induce pensamientos.

Así es. documentar, especialmente cuando se hace de forma cuidadosa, concentrados en la tarea y con la voluntad de rigor y comunicación, induce pensamientos, muchos pensamientos...y refina los que ya habíamos tenido.

Así que a las preguntas ¿Reflexión?¿Preparación?¿Planificación? ¿Para la innovación?

Respondo: si, sin ninguna duda.

En Pulse: El primer paso. Agilidad y planificación en tiempos de incertidumbre

La transformación comienza por un primer paso. Las iniciativas comienzan por un primer paso. Los proyectos comienzan por un primer paso.

Un primer paso que en ocasiones no nos atrevemos a dar. Un primer paso al que, en otras ocasiones, nos lanzamos con excesiva ligereza.

Hace décadas no existían mecanismos formales de planificación.

Luego, en 1958, llegó el proyecto Polaris y se desarrollaron técnicas como el PERT, el Critical Path Method, o el Diagrama de Gantt. Y nació la dirección de proyectos, y nos acostumbramos a planificar cuidadosamente los pasos que debíamos dar. No solo eso, incluso nos acostumbramos, algo más tarde, a hacer planes estratégicos y de marketing. Nos acostumbramos a que las actividades respondían a un plan.

Y aquello era bueno.

Luego el mundo, la tecnología y la gestión, comenzaron a acelerarse y a hacerse menos predecibles, el mundo se nos volvió VUCA (Volatile, Uncertain, Complex, Ambiguous) y más elusivo, más confuso, menos aprehensible por planes que nos marcasen nuestra actuación de principio a fin.

Y como respuesta, surgieron metodologías más laxas, más iterativas, de pasos más cortos y ajustes conforme a los resultados obtenidos. Así, la ingeniería de software pasó del modelo en cascada al agile, donde el software se va definiendo, construyendo, probando y desplegando en iteraciones cortas, en sprints. Y el marketing de producto y el lanzamiento de empresas, se nos volvió Lean, Lean startup para ser más exactos. Y empezamos a pensar que mejor que conseguir y lanzar al mercado un producto magníficamente definido y pulido en todos sus detalles, era preferible lanzar el famoso producto mínimo viable… y ver qué pasaba… y reaccionar según los resultados.

Nos hemos acostumbrado a planificar menos y reaccionar más. A ser más rápidos pero menos rigurosos y predecibles.

Y esto también es bueno…

¿Si? ¿También es bueno?

Hasta cierto punto. Sólo hasta cierto punto.

Si, si ello no supone una renuncia a unos objetivos y una estrategia claros. Si, si ello no supone un abandono gratuito de la planificación cuando ésta es posible y en el modo en que es posible. Si, si ello no supone un mera rendición ante la dificultad inherente al acto de estimar y planificar. Si, si ello no supone una concesión a la improvisación, por desidia, por falta de conocimiento, o por falta de rigor.

Cuando se habla de innovación y creatividad se nos anima siempre a dar un primer paso. A identificar una acción concreta, tangible y alcanzable que nos haga avanzar hacia el objetivo. Y es un buen consejo. Pero no hay que olvidar que a un primer paso debe seguir otro, y luego otro, y otro…si es que realmente queremos conseguir un resultado valioso. Y es que, en el fondo, necesitamos tener algo parecido a un plan, aunque quizá no alcance la complejidad de un PERT, o aunque sea entendido como una mera sucesión de pasos que conducen al fin pretendido. En caso contrario, en ausencia de plan, nuestros pasos pueden no conducir a ninguna parte, o pueden desplazarnos en círculos o, simplemente, nos podemos cansar de caminar sin llegar a ningún lugar.

¿Cómo conciliar todo esto? ¿Cómo conseguir el rigor de una planificación sin caer en la rigidez y la burocracia? ¿Cómo planificar y al tiempo ser ágiles y con capacidad de reacción?

Creo que hay dos claves: por un lado tener claro el objetivo y la estrategia básica. Por otro lado, ajustarse siempre a un tipo de planificación que voy a bautizar como multinivel, aunque ya se verá que no es en sí misma un concepto original.

En primer lugar el objetivo y la estrategia. A lo que creo que nunca podemos renunciar, por mucha incertidumbre que haya en nuestro entorno, por muchas dudas que tengamos en una gran variedad de aspectos, es a tener claro cuál es nuestro objetivo, qué queremos conseguir con un proyecto, un producto, una innovación. Si no es así, si no tenemos claro nuestro objetivo, ya sabemos cuál debe ser nuestro primer paso: definir ese objetivo. Formulémoslo, escribámoslo y que sea claro, entendible, inequívoco…. y, si es posible, inspirador… y medible…

La planificación multinivel se refiere adoptar diferentes grados de detalle en la planificación. Cuando estamos empezando un proyecto o transformación complejos, probablemente no podemos ni debemos aspirar a una planificación detallada en todos sus aspectos. No tendría sentido, no sabemos lo suficiente. Y la realidad, o el mercado, o los primeros resultados, nos pueden obligar a cambiar algo el rumbo. Entonces debemos hacer una planificación de muy alto nivel, sólo las grandes fases y, eso sí, intentar planificar en más detalle la primera fase, las primeras acciones. Eso lo que en dirección de proyectos se denomina “rolling wave planning”. A medida que tenemos más claras las cosas, hacemos una planificación más detallada y, si tiene sentido, de más largo plazo.

El uso inteligente de un objetivo y una planificación multinivel te permiten la agilidad y capacidad de reacción que exigen los nuevos tiempos y el rigor y solidez que hemos aprendido a lo largo de décadas de gestionar proyectos.

La unión de ambos factores conjuga la flexibilidad y rapidez, con el rigor y el control.

¿Te convence la idea?

¿Quieres empezar a usar esta forma de enfocar tus iniciativas, tus proyectos, tus aspiraciones?

Pues, simplemente atrévete. Selecciona tu próximo objetivo haz el plan.

Da el primer paso…

*****

Artículo publicado en Pulse el 2/11/2016

Pulse es el servicio de noticias personalizadas de la red social profesional LinkedIn

Convivir con la incertidumbre

Es un equilibrio difícil...pero inevitable.

Una de las tareas de un directivo o de un mando intermedio es la de organizar el trabajo de sus equipos,una organización que incluye elementos como, la fijación de objetivos,  la planificación, la asignación de recursos, el establecimiento de hitos...

Estas herramientas, por un lado hacen el trabajo más efectivo y eficiente pero, además, lo convierten en más previsible. Y esto es bueno.., y necesario.

Sin embargo, es preciso ser consciente de que los contextos pueden cambiar y los imprevistos surgir, Aunque la planificación y la organización son necesarias y positivas, no pueden caer en la rigidez o la inmovilidad.

En el mundo digital, los cambios se producen cada vez con mayor dificultad, el futuro es cada vez menos previsible y menos controlable, las disrupciones se hacen más frecuentes...

Por todo ello, sin renunciar a la planificación y la organización, los líderes de un mundo digital deben estar preparados para convivir con un cierto nivel de ambigüedad e incertidumbre... e, incluso, sentirse cómodos con ellas.

Ese es el consejo que nos dan George Westerman, Didier Bonet y Andrew McAfee en su libro 'Leading digital' cuando nos dicen:

A key aspect of competing in the digital age is the ability of leaders to be comfortable with a certain level of ambiguity when it comes to digital initiatives.

Esa convivencia amistosa con la incertidumbre no implica, entiendo yo, una renuncia a la planificación, todo lo contrario. Implica la capacidad para tomar decisiones y establecer planes con un cierto e inevitable nivel de riesgo, la disciplina para monitorizar las hipótesis sobre las que se construyeron los planes y una actitud abierta para modificarlos si las condiciones de contexto los invalidan.

No se trata de no planificar sino que, las planificaciones se deben mover o, o al menos revisar, al ritmo acelerado del cambio en el mundo digital.

Se trata, como decía, de un equilibrio difícil...pero inevitable.

#macrotweet: la necesidad de un plan de proyecto

The first step in controlling a big project on a tight schedule is to have a schedule, made up of milestones and dates for them.

Frederick P. Brooks Jr.

'The mythical man-month'

El optimismo como defecto... en la planificación de proyectos de software

Parafraseando el famoso dicho, podríamos afirmar que

Planificar siempre es difícil... especialmente si es a futuro.

En la sentencia original el verbo es predecir, y no planificar...pero en cierto modo la planificación es una predicción, bien que basada en la experiencia y, en ocasiones, en técnicas más o menos reconocidas.

Si bien la planificación es siempre compleja, parece como si los proyectos de software fuesen especialmente sensibles a un error de planificación que nace de un excesivo optimismo.

Por eso, en su famoso libro 'The mythical man-month', Frederick P. Brooks afirma:

All programmers are optimists

Y la experiencia indica que algo hay de cierto en esto. En efecto, los proyectos de software tienden con enorme frecuencia a retrasarse, probablemente mucho más que cualquier otro tipo de proyecto.

So the first false assumption that underlies the scheduling of systems programming is that all will go well.

Pero, ¿de dónde sale ese optimismo crónico?  

Dos son los argumentos que recoge el autor. 

Por una parte, el medio con el que trabaja el desarrollo software es un medio lógico, no físico y, por tanto, extremadamente maleable. Esto es diferente, por ejemplo, de la construcción de una vivienda donde los medios son materiales y mucho menos maleables. El software es casi pensamiento puro... y eso nos crea esa sensación de maleabilidad y de poder sobre ello. y de que no surgirán dificultades...cosa que es extremadamente falsa.

De hecho, y este es el segundo argumento, el software es extremadamente complejo y formado por muchísimos elementos. La probabilidad de que los avances de todos o la mayor parte de los componentes sean tal y como estaba planificado, es decir, que no surjan dificultades en ninguno de ellos, es extremadamente baja..,con lo que, aunque sólo sea por estadística, el optimismo en el mundo del software está absolutamente injustificado.

Y esa es la paradoja: al contrario de lo que sucede en la mayoría de los campos, en el caso de los proyectos de software, el optimismo lejos de ser una virtud es un defecto, un defecto frecuente, un defecto crónico...

Arquitectura empresarial, proyectos y la necesidad de ver el fin

A veces, quizá por falta de conocimientos, quizá por falta de disciplina o, más probablemente porque la magnitud del empeño abruma, se acometen grandes iniciativas sin un fin claro, sin una plan.

Existe una ambición y un objetivo difuso que parece deseable y lejano. 

Y se inicia la marcha.

Uno de los casos en que eso puede suceder es en proyectos de gran magnitud como una reingeniería de procesos o la definición e implantación de una arquitectura empresarial. 

Quizá se confía en la intuición. Quizá se considera un rasgo de iniciativa y arrojo. Quizá se piensa que no se es capaz de fijar unos objetivos hasta que no se haya avanzado en el camino.

Creo que es un error. 

Creo que es muy importante tener una idea clara de los objetivos que queremos lograr, de cuáles son los 'entregables' del proyecto que acometemos y cómo llegar a ellos. Es necesario tener una visión y es necesario, siguiendo la metodología tradicional de dirección de proyectos, un alcance, una planificación, unas tareas...

Es cierto que en proyectos de gran alcance es difícil ver con nitidez todos los detalles y que una planificación detallada o una descomposición de tareas finas no se pueden lograr quizá al principio. 

Es cierto que, por ejemplo, en el caso de una arquitectura empresarial, los detalles del modelo de procesos o de información o de la arquitectura tecnológica no es fácil establecerlos con nitidez en las primeras fases. Es cierto que en un proyecto complejo puede resultar algo lejano el definir los pasos de su despliegue.

Es cierto, también, que en proyectos complejos es necesario tener cierta flexibilidad y capacidad de adaptación. Es cierto que, como el algún artículo he afirmado, es importante 'saber conducir'...

Pero hay que tener una visión, un objetivo, un fin...y una idea de cómo llegar.

Incluso sabiendo conducir no se llega a ningún sitio...si no se sabe dónde se quiere llegar.

En el ámbito específico de la arquitectura empresarial, me alegra encontrar una idea parecida en el libro 'Launching an enterprise business architecture practice' de Guy Sereff cuando afirma:

one of the paramount habits of highly effective Enterprise Business Architects is the ability to begin with the end in mind.

Definir e implementar una arquitectura empresarial es uno de esos proyectos complejos y abrumadores. Por ello, ese 'fin en la mente', ese sentido de dirección, de objetivo...es fundamental.

Difícil lograr el éxito en caso contrario.

¿A qué dedican su tiempo los programadores?

Cuando intentamos estimar trabajos intensivos en mano de obra es fácil errar... y generalmente por el lado del optimismo.

En entornos muy industriales, puede que aún tengan validez técnicas taylorianas de medida de tareas y tiempos pero ¿qué pasa con los trabajadores de cuello blanco?

Una disciplina que es especialmente elusiva, difícil de gestionar y planificar por las técnicas de carácter industriales es el de la ingeniería sofware y más específicamente la programación.

Diferencias en la experiencia, formación, habilidad, motivación o inteligencia entre diferentes programadores, puede dar tasas de productividad sorprendentemente diferentes.

Pero más allá de esto, hay un error mucho más básico, y más fácilmente enmendable,  a la hora de estimar la duración de un proyecto de software: sobreestimamos la dedicación efectiva de los programadores a escribir líneas de código o probar lo que han programado.

Lo cierto es que un programador, como cualquier otro trabajador, dedica una parte de su jornada laboral a tareas que no están directamente relacionadas con su puesto de trabajo o con aquello que se supone es su labor: reuniones, cafés, asuntos personales, distracciones...

En su libro 'Going Agile' Gloria J. Miller aporta referencia de dos estudios.

Menciona por un lado un estudio llevado a cabo en 2001 por Booch y Brown. Según este estudio, los programadores dedican:

• 3% de su tiempo a llamadas telefónicas
• 7% de su tiempo leyendo
• 17% de su tiempo en reuniones

Si suponemos que el resto se dedica a programar o probar, nos queda un 73% de tiempo productivo. Si realmente ese 73% se dedicara completamente a su labor, no me parece una mala cifra, especialmente teniendo en cuenta que el 7% dedicado a leer, si es en relación con su trabajo, es un potenciador y podríamos considerarlo como parte de la formación y desarrollo profesional, algo que redunda en la productividad futura.

Sin embargo, en 1995 Brook daba una estimación algo más grosera... y bastante más pesimista, estimación que atribuía sólo un 50% de dedicación a programar y depurar mientras el resto se perdía en reuniones, burocracia, bajas por enfermedad, etc.

Dos conclusiones creo que se obtienen.

Por un lado, que es conveniente vigilar la productividad y establecer medidas para mejorarla porque si Brook tuviera razón, la cosa parece preocupante.

Por otro, que no es realista planificar un proyecto de sofware suponiendo una dedicación 100%. Incluso siendo moderadamente optimistas, deberíamos suponer que, por ejemplo, un 25%  de la capacidad de trabajo en horas se va hacia tareas que no se planifican y que no tienen que ver directamente con la producción de software.

Muy relevante es hacer notar que en este artículo tratamos con el caso de la programación pero que, si pensamos en planificación en otros campos, siempre debemos partir con esa dedicación inferior al 100%. Por ejemplo podemos, de forma quizá conservadora, reservarnos un 20% para actividades no planificadas y difícilmente planificables.

Una virtud del director de proyecto es el realismo...y esta receta añade, creo, realismo a las planificaciones.

Dirección de proyectos y la falacia de la planificación de Kahneman

Es curioso cómo, a veces, dos disciplinas diferentes, con técnicas diferentes y partiendo de supuestos diferentes, pueden llegar a las mismas o similares conclusiones.

Eso he podido observar hoy cuando leyendo el libro 'Thinking fast and slow' de Daniel Kahneman, un autor del campo fundamentalmente de la psicología, llego al punto en que nos habla de la visión externa ('outside view') y de la falacia de la planificación ('the planning fallacy').

El libro de Kahneman se centra en estudiar dos modos de pensar, el Sistema 1 automático y rápido, y el Sistema 2 racional y lento, cómo se complementan e interaccionan, pero también los sesgos y falacias que produce en ocasiones esa interacción, o la intervención de uno de ellos, típicamente el Sistema 1, cuando sería preciso la intervención del Sistema 2.

El caso es que en este rincón de la obra, se centra en la planificación y previsión (fundamentalmente de fechas). Dice Kahneman que con frecuencia se producen errores en la planificación de proyectos. El motivo fundamental que encuentra es que la planificación es en cierto sentido endógena (visión interna) en que los miembros o responsables del proyecto hacen una estimación que se caracteriza por tender a centrarse en el mejor escenario (incapaces o no deseosos de identificar y estimar todos los posibles problemas y desviaciones que puedan ocurrir) y despreciando lo que denomina la visión externa, que vendría a ser la experiencia en proyectos similares realizados anteriormente (y que ya han pasado por todo tipo de vicisitudes).

Así lo explica:

planning fallacy [] describe plans and forecastas that:

• are unrealistically close to best-case scenarios
• could be improved by consulting the statistics of similar cases

Recordemos ahora un poco de teoría de dirección de proyectos, en concreto en el área de planificación o gestión del tiempo del proyecto. La forma habitual de planificar proyectos, inspirándonos en el PMBOK incluye la descomposición en actividades (a partir de la Work Breakdown Structure que forma parte de la gestión del alcance del proyecto), el establecimiento de relaciones de dependencia entre las actividades, la estimación del tiempo de las tareas actividades, y el cálculo del tiempo total del proyecto aplicando una técnica como PERT/CPM.

Como técnicas para estimar la duración de las actividades individuales podríamos mencionar varias como, por ejemplo:

• Juicio de expertos: estimaciones por parte de expertos con base en su experiencia y conocimientos.


• Estimación paramétrica: elegimos algún tipo de parámetro que represente el 'output' a generar, por ejemplo, número de líneas de código, planos, objetos fabricados o lo que sea, y eso lo unimos al tiempo unitario para producir ese output. Com ambos datos es posible obtener la duración de la actividad.


• Estimación analógica: por mera comparación con tareas o proyectos similares

Lo cierto es que todas estas técnicas se pueden aplicar para tareas individuales pero también para una estimación, grosera eso si, del proyecto en su conjunto. Así, podemos estimar la duración total del proyecto mediante una comparativa analógica con un proyecto similar o una estimación paramétrica tomando outputs del proyecto en su conjunto.

Por otro lado, ¿de dónde proceden los valores de la duración unitaria del elemento elegido como parámetro o las duraciones de proyectos anteriores? Pues de lo que en el PMBOK se denominan activos de la organización ('Organizational process assets'), que no dejan de incluir, entre otras cosas, la base de conocimiento generada en experiencias anteriores... es decir, a experiencia de otros...

¿Se observa el paralelismo?

Si consideramos como expertos a los miembros o responsables del proyecto y pensamos en una planificación hecha a partir de juicio de expertos unida a una técnica de PERT/CPM (probablemente lo más habitual) nos situaríamos en lo que Kahneman denomina la visión interna. Por el contrario, mediante métodos paramétricos o analógicos estaríamos recurriendo a la experiencia anterior de la organización, es decir, a la visión externa.

Si hacemos caso de lo que parece sugerir Kahneman aparentemente lo correcto sería recurrir a métodos paramétricos o analógicos.

Mi experiencia personal, sin embargo, me dice que éstos últimos suelen ser mucho menos rigurosos y muy de grano grueso. Además, una vez hecha la estimación, resulta difícil de seguir su cumplimiento, repartir trabajos, explicar desviaciones, detectar riesgos y definir acciones correctoras.

¿Qué es, pues, lo óptimo? Probablemente la complementariedad de técnicas: 

Primeramente, mediante un método más riguroso y formal, los expertos del proyecto con todos sus conocimientos generales y específicos del proyecto hacen su estimación y luego se contrasta con una visión analógica o paramétrica. Si hay mucha distancia, se debe intentar entender qué paso en otros proyectos y que no estamos teniendo en cuenta (las denominadas lecciones aprendidas 'lessons learned' nos deberían ayudar) o, quizá, poner un cierto colchón para imprevistos (aunque esto está desaconsejado por el PMI, Project Management Institute) para hacer frente a esas eventualidades que no somos capaces de identificar en el momento de la planificación. 

Otra opción podría ser partir de nuestra estimación 'interna', con una advertencia a los 'stakeholders' del 'gap' con estimación externa y con una muy rigurosa gestión de cambios y riesgos a lo largo del proyecto.

Sea como fuere, no parece que las conclusiones del psicólogo y de los especialistas en dirección de proyectos sean tan diferentes. Es conocido que los proyectos tienden a retrasarse y es muy probable que la imposibilidad de identificar casos adversos, el interés en no hacerlo (para no perjudicar la venta interna del proyecto), o un cierto optimismo estén en la raíz de ello. Y también es cierto que el mirar de reojo a experiencias anteriores, a las lecciones aprendidas y las duraciones de actividades o proyectos anteriores sirve de valioso contraste de realidad.

La estrategia de probar y aprender

Las disciplinas de gestión empresarial más tradicionales han puesto el foco en la planificación. Así, por ejemplo, hablamos de plan estratégico, de plan de marketing o de planes de acción.

A más bajo nivel, y en entornos que me resultan muy cercanos, las metodologías de gestión de proyectos, de nuevo, ponen mucho énfasis en la planificación. Aparte de las archiconocidas técnicas del PERT y el GANTT, pueden revisarse adicionalmente al respecto, por ejemplo, las más nuevas enseñanzas del PMI y su casi obsesiva fijación en el plan de gestión de proyecto con todos sus subplanes.

En el entorno del diseño y desarrollo software, las metodologías tradicionales, con su modelo en cascada, intentaban enmarcar en unas fases muy defninidas el desarrollo de módulos y sistemas software. No era una planificación completa, pero sí un intento de aprehender los estadios del desarrollo.

Es un intento loable, y probablemente fructífero, de hacer manejable la realidad y, sobre todo, un futuro aún en construcción. La planificación permite clarificar el trabajo a realizar, permite identificar recursos, plazos y costes y consigue, sobre todo, enfocar los esfuerzos y monitorizar los avances. Y, piscológicamente, nos da una sensación de control...

... pero la realidad se resiste a ser planificada.

Incluso en esos entornos altamente planificados, se reconoce la necesidad de la replanificación y la seguridad de las metodologías en ocasiones se resquebraja.

Los grandes planes estratégicos, por ejemplo, suelen tener una frontera a, por ejemplo, tres o cinco años...y sin embargo, se revisan anualmente. En gestión de proyectos se establecen líneas base...frente a las cuales luego comparamos las nuevas planificaciones o los avances reales. Y en desarrollo software, las nuevas metodologías agile hablan más de un desarrollo iterativo, de pequeños avances seguidos de reconsideración de objetivos y planes.

El ritmo acelerado de cambio en las tecnologías, en los mercados e, incluso, en la sociedad, dificultan, hasta el punto de a veces convertirla en no realista, la tarea de la planificación. Cuando hablamos, además, de innovación, de la cresta de la ola, muchas veces nos enfrentamos a lo desconocido, a los limites tecnológicos o a reacciones imprevisibles del mercado. En esas situaciones, aunque quizá se puedan hacer planificaciones tentativas, es preciso reconocer nuestra incapàcidad para una planificación completamente fiable. Es preciso tener una actitud mental y de gestión de flexibilidad y adaptación, de reconocimiento de situaciones y reacción consecuente, sin ceder a vanas ilusiones de control que nos pueda proporcionar una planificación que, sencillamente, no tenemos ninguna garantía de que se cumpla.

En estos entornos, y como nos propone Chuck Martin en su libro 'The third screen' al respecto del marketing móvil, la mejor estrategia puede llegar a ser 'Test and learn' (probar y aprender), lanzar un producto o una idea, ver cómo reacciona el mercado y adaptarse a los resultados.

No es, en el fondo, y a pesar de las apariencias, una estrategia frontalmente contraria a la planificación. El lanzamiento del producto puede, y debe, haber sido gestionado mediante una planificación. Otras técnicas tradicionales de gestión, como la gestión de riesgos, deben aplicarse, y no parece admisible el lanzamiento a ciegas de un producto o servicio sin estudios previos de viabilidad. 

No se trata de estrategias suicidas sino de flexibilidad.

Las técnicas tradicionales de planificación y monitorización de proyectos de todo tipo o de la actividad empresarial, creo que siguen siendo valiosas, muy valiosas, pero si van acompañadas, especialmente en los entornos más innovadores, más en el límite, de la necesaria flexibilidad y capacidad de reacción, si no se hacen planificaciones a muy largo plazo sino en lapsos temporales realistas y si somos capaces de adaptar esas planificaciones al devenir de la realidad y a la respuesta del mercado.

Al fin y al cabo, la planificación es sólo es una herramienta. Nuestro objetivo es el mercado.

Una interpretación pesimista del uso de hitos de planificación

Penúltima perla extraída de 'El manifiesto cluetrain'. En esta ocasión, David Weinberger nos habla acerca del uso de las fechas límite. Esto es lo que nos dice:

"las fechas límite son a menudo un arma que usan los directivos que asumen que los trabajadores son básicamente vagos."

Weinberger piensa que en las organizaciones hipervinculadas, repletas de trabajadores motivados, predomina el deseo de conseguir un producto o de ayudar a un cliente. Opina que en este tipo de organizaciones la planificación no es necesaria, que los trabajadores darán lo máximo de sí mismos para conseguir los objetivos lo antes posible sin necesidad de una presión externa en forma de planificación.

¿Cuánto hay de cierto y cuánto de utópico en esta visión de las organizaciones hipervinculadas?¿ Y cuánto hay de cierto y cuanto de rebeldía sin causa en la interpretación del uso de fechas límite?

Es cierto que en organizaciones o equipos motivados la necesidad de supervisión disminuye. Es cierto que en este tipo de equipos se trabaja más sin que ese esfuerzo sea explícitamente exigido por los directivos. Lo he visto. Puedo dar fe de ello.

Pero tambien es cierto que no podemos asumir siempre que los equipos están plenamente motivados...y a pesar de ello, los proyectos tienen que salir adelante. Igualmente es cierto que el marcar metas y objetivos, si son retadores pero cumplibles, tiende a mejorar el rendimiento de un equipo. Y, finalmente, es cierto que el establecer planificaciones marca una referencia que permite tomar decisiones, asignar recursos, adquirir compromisos...convirtiéndose así en una herramienta de gestión de primer orden.

No es que a Weinberger no le asista una parte de razón y no es que la visión que nos propone de la empresa hipervinculada no sea atractiva y tenga su dosis de verdad. Pero quizá se deja llevar un poco por la pasión a la hora de pensar en esa organización ideal, y por un cierto prejuicio acerca de las intenciones de los directivos cuando planifican actividades.

¿Cómo decía el famoso eslogan publicitario?

"La potencia sin control no sirve de nada"