Pensando: Problemas y modelos mentales

WP_20150403_045

Es interesante pensar sobre los problemas de los proyectos y posibles soluciones cuando se tiene tiempo, como ahora en Semana Santa, de forma relajada. Este artículo contiene algunas opiniones e ideas al respecto que tengo en la cabeza a día de hoy.

Partir una nuez con una piedra es fácil si cuentas con una roca de cierto tamaño. Pero si divides la roca en trozos que sean de forma y tamaño similar y que sumen el peso total de la piedra (por ejemplo un puñado de arena), no podrás partir la nuez. O al menos la técnica directa (golpear) no funcionará. Se necesita una técnica diferente, por ejemplo usar la arena como material abrasivo para desgastar la cáscara, o compactar la arena en un saco antes de golpear para que actúe como un cuerpo sólido. Es interesante que un único cambio cualitativo en el recurso (fragmento grande de roca VS fragmentos de roca) aun manteniendo el resto de cualidades y su cantidad, inhabilita la solución más obvia y añade nuevas necesidades (tiempo, un saco…).

Otros problemas tales como lanzar una nave espacial necesitan tener ciertos umbrales de trabajo o recursos asegurados para un periodo: independientemente de como lances un cohete (hora, lugar, tipo, carga, ángulo…), necesitarás aplicar energía suficiente durante un periodo determinado si deseas tener éxito. Si no concentras la energía necesaria en forma y tiempo (cohete, toberas y tiempo de encendido), lo más que conseguirás será un cráter humeante.

En el Mythical Man Month de Fred Brookes, clásico entre los clásicos de la gestión de proyectos, se comentaba que añadir recursos a un proyecto no hace más que retrasarlo, y se añadía que “9 mujeres no pueden tener un bebé en 1 mes” como forma de indicar que ciertos problemas necesitan cierto tiempo y dedicación, independientemente del número de personas implicadas.

Con estas analogías quiero recordar la importancia que tiene la dedicación y la concentración de los integrantes de un proyecto en el resultado de este. Concretamente quiere recordar que:

  1. La rotación de la gente dentro de una empresa ya es mala, pero la rotación dentro de un proyecto o empresa es devastadora.
  2. Aunque no haya rotación en el sentido de gente nueva o gente que es reemplazada, el que un proyecto tenga gente entrando y saliendo debido a prioridades cambiantes (y legítimas, como vacaciones, emergencias u otros proyectos), es siempre algo negativo y un hándicap a manejar.
  3. El dedicar a una misma persona a múltiples proyectos (con los problemas de cambio de contexto asociados) provoca una dedicación y atención dividida entre N temas y puede llegar a provocar que un recurso, sobre el papel, esté asignado y trabajando en una serie de proyectos, pero en la práctica puede no estar aportando absolutamente nada a ninguno de esos proyectos.

En mi opinión hay una relación entre estos cada uno de estos problemas, un modelo mental común que los provoca: la idea de que un proyecto informático es un proyecto de construcción. Con esa idea en mente es normal pensar así: un albañil pone X ladrillos por hora, dos albañiles deberían poner el doble y acabar la obra por tanto en la mitad de tiempo. Es fácil también pensar que lo que hace un albañil o un fontanero, lo puede hacer otro en un tiempo similar. Es fácil pensar que cambiar al albañil de planta en el edificio no tiene ningún impacto, avanzará a la misma velocidad poniendo ladrillos en la primera planta que en la cuarta.

Y el desarrollo de software no funciona así.

Ese modelo mental del desarrollo de software que lo considera una actividad de “construcción” podría llegar a ser válido quizá montando un CPD, o plataformando equipos, actividades también informáticas. Sin embargo el desarrollo de software es un proceso de diseño, y los procesos de diseño requieren sobre todo de tiempo, toneladas de comunicación y mucha investigación para responder al “por qué” del proyecto con una implementación. Un proceso de diseño es conversación, experimentación, preguntas y respuestas. Por eso Agile siempre me ha parecido no solo una buena idea, sino la única que puede funcionar: porque está orientado a la comunicación, a hacer preguntas y obtener respuestas.

Agile, el desarrollo ágil de software, articula esa comunicación mediante ciclos cortos, sprints, reuniones mínimas, TDD, simplicidad… Todo está orientado a tratar de obtener feedback de todas las partes (Pair Programming, entrega continua…). Todas esas técnicas y conceptos empleados: stand up meeting, lean, kaizen, kanban… Todo es un reconocimiento de la misma idea: estamos diseñando algo y reconocemos que no sabemos realmente como debe ser, así que tenemos que experimentar, dialogar y descubrir.

Agile es un reconocimiento tácito de ese modelo de mental del desarrollo de software como proceso de diseño. Pero eso no evita que se use como herramienta de márquetin, vaciándose de contenido y manteniendo la forma, lo “barato” y “visible” para poder vender certificaciones, proyectos “con las mejores metodologías” y “mejores procesos” que no son más que cosméticos. Ante esa pérdida de sentido, ante ese deterioro del término, hay poco que hacer sin mucho trabajo, pero este es doblemente complicado cuando estamos frente a personas que piden “agilidad” mediante la adición de recursos extra a proyectos iniciados. Personas que piden “agilidad” en proyectos llave en mano de precio cerrado. Personas que piden “agilidad” dedicando lo mínimo posible de su tiempo al proyecto. Ante esas persona está claro que no se está haciendo ni pidiendo Agile, sino solo la apariencia del mismo, bien porque no se quiera (por diferentes interese) o bien porque se haya malentendido Agile como un producto a seguir ciegamente (metodologías fijas, certificaciones y márquetin), en lugar de como una serie de medidas de sentido común cuando el modelo mental es el de desarrollo de software como proceso de diseño.

Y aquí lo dejo. El tema de los modelos mentales, las metodologías y la comunicación son temas complejo y hay cientos de libros sobre esos temas, eventos y experiencias reales comentadas en multitud de sitios. Con este artículo solo me he limitado a pensar sobre varios temas relacionados y espero que animado a otros a pensar sobre ello. Quizá pensando entre todos, podamos hacer más felices a equipos y clientes. Y serlo nosotros mismos claro.

Anuncios

2 pensamientos en “Pensando: Problemas y modelos mentales

  1. Pingback: Pensando: Analogías, símiles, metáforas, copia, innovación y comunicación | jbolano

  2. Pingback: Analogías y desarrollo de software I | jbolano

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