Límites en la gestión de proyectos de software

WP_20150709_032

Gestionar implica poner límites: límites a las horas trabajadas, limites a los recursos utilizados, límites al alcance del proyecto, límites a la responsabilidad de cada miembro del equipo, límites a lo que el cliente recibirá, cuando lo hará, etc.

Aunque las diferentes modas, escuelas o prácticas de desarrollo de software difieren en muchos aspectos, me parece interesante pensar en cómo se pueden categorizar, grosso modo, por aquello que limitan. De este modo tendríamos cuatro categorías:

  1. Límites a las tareas en curso, a la atención (KANBAN mediante el WIP).
  2. Límites al tiempo y recursos* empleados (SCRUM mediante los SPRINTS).
  3. Límites al alcance, tiempo y coste (gestión de proyectos clásica: on time, on spec, on budget).
  4. Límites a los recursos* (LEAN mediante la búsqueda de desperdicio).

*Nota: Con “recursos” pienso en personas, dinero y cualquier otro elemento que vayamos a emplear, para diferenciar del énfasis que pone la gestión clásica en los costes económicos, muy por encima de las personas.

Desde este punto de vista, es interesante observar como la gestión clásica trata de ser muy restrictiva y se enfoca en aspectos monetarios y alcances cerrados. Estas características, que funcionan bien y son necesarias en proyectos de construcción (edificios, barcos…), se convierten en una debilidad en el mundo del software, donde los mayores costes son los de personal y el alcance varía con facilidad. Porque el desarrollo de software es un proceso de diseño, no de construcción.

También es interesante observar como Scrum resulta más restrictivo que Kanban y Lean, por lo que podemos pensar a priori que es menos flexible y quizá menos adecuado para un proceso de diseño (software novedoso, entornos cambiantes) que Lean o Kanban. Esta flexibilidad reducida puede ser una ventaja en desarrollos poco novedosos y en cualquier caso es una mejora sobre la gestión clásica al centrarse más en personas y procesos.

Entender estas herramientas es vital para poder emplearlas con éxito. De otro modo caeremos en el cargo cult programming y sólo aparentaremos hacer desarrollo ágil de software, que es lo que temo que se produce en la mayoría de las organizaciones medianas y grandes: empresas con una inercia brutal en su cultura organizativa e incentivos, que tratan de sumarse al hype sin realizar un muy necesario cambio cultural. No puedo dejar de recomendar la lectura de Philip Zimbardo para entender los problemas sistémicos y Nassim Taleb para la gestión de riesgos y sistemas complejos.

Creo importante comentar que hay muchísimo hype desde hace unos años con todo el tema de ser ágiles, Scrum, etc. Por lo que recomendaría la lectura de un excelente artículo de la MSDN sobre todos ellos: The Lean of Scrum

En el artículo se comenta, entre otras muchas cosas, algo en lo que nunca se insiste lo suficiente: Scrum es un marco de trabajo, un conjunto de prácticas para poder desarrollar software de forma metódica. Lean es una filosofía de desarrollo, una forma de pensar y enfocar lo que hacemos. Kanban es una práctica o técnica para ayudar a optimizar un proceso.

Lo interesante del artículo de Microsoft es que permite contemplar cómo todas estas herramientas pueden tomarse por separado, mezclarse sin problemas o emplearse en diversos contextos, o con nuevas técnicas, filosofías y marcos  de trabajo para poder desarrollar software con éxito. O al menos con mejor probabilidad de éxito, al centrarnos en los elementos más críticos de los procesos de diseño, que lo que permite la gestión de proyectos clásica.

Centrarse en entender qué estamos haciendo, y sobre todo qué necesitamos en cada contexto, permite olvidarse del marketing, las formulas mágica (balas de plata, soluciones milagro) y realizar mejor nuestro trabajo.

Considero importante que los gestores de proyectos de software tengan experiencia real y fresca en el campo, porque gestionar un proyecto de software requiere entender qué estamos haciendo, qué limites debemos o podemos establecer y la naturaleza de lo que estamos haciendo. Sin ese conocimiento, basado en la experiencia, es improbable que hagamos algo diferente del cargo cult, y nuestras posibilidades de terminar un proyecto con éxito se reducen. Sin esos límites la “gestión de proyectos” se convierte en un mero drenaje de recursos, un viaje sin destino, en el que el único límite es cuantos recursos del proveedor pueden absorberse cada día, a ser posible 24/7.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s