Los programadores no son empleados

Año 1987, dos señores llamados Tom DeMarco y Timothy Lister publican un libro titulado “Peopleware – Productive Projects and Teams”. Es de lo mejor que se ha publicado sobre trabajo colaborativo en equipos de desarrollo de software en estos últimos 30 años. Está en inglés, pero tanto si eres desarrollador como si eres un mando intermedio o directivo que trata con equipos de desarrollo es un libro que hay que leer.

Un programador no funciona con los mismos parámetros de estímulo que otros empleados de tu empresa. No es un empleado -salvo por el pequeño detalle de que cobra a final de mes-. Se le ha definido de muchas formas, enumero algunas que pueden parecer graciosas, pero hay algo de verdad en todas ellas:

• Alguien que arregla problemas que no sabías que tenías de una forma que no entiendes.
• Una persona que tiene una relación más profunda y significativa con un ordenador que con otras personas.
• Alguien que convierte cafeína y pizza en software.

Desde el manifiesto ágil de 2001 el agilismo ha provocado cambios importantes y beneficiosos en cómo son vistos los programadores y cómo se forma un buen equipo de trabajo de desarrollo de software. Se pasó de un estilo centrado en la planificación y procesos a otro basado en las personas y en la colaboración. Se allanaron las jerarquías en los equipos y se dio poder al programador, situándole más cerca del usuario y convirtiéndole en el elemento clave para conseguir la ansiada satisfacción del usuario. Escrito así parece fácil, pero llevarlo a la práctica es más un arte que una ciencia, como suele ocurrir en casi todas las disciplinas en las que está involucrada la psicología humana.

“El software se está comiendo el mundo”. Marc Andreesen

La demanda de programadores aumenta cada año. El paro en este sector y en ese rol es casi inexistente. La razón es que las empresas se están convirtiendo cada vez más en software. A medida que pasa el tiempo se automatizan más procesos o se crean otros nuevos, de tal modo que la dependencia que tienen las empresas del software y la conectividad es total.

La forma de sobrevivir en este ecosistema tan agresivo es contar con un buen equipo técnico. Tu ventaja competitiva se tornará decisiva si cuentas con un grupo de programadores con objetivos alineados y con una causa común. Buen nivel técnico y excelente compenetración entre ellos. Así se consigue progresar. Si pretendes ganar esa batalla y la guerra con programadores externos con tres niveles de subcontratación, quizás para que las impresoras funcionen te puede valer, pero poco más.

“La paradoja es que cuando los managers se centran en la productividad, rara vez se mejora a largo plazo. Por otra parte, cuando los managers se centran en la calidad, la productividad mejora de forma continua”. John Seldon

Cuando se sacrifica la calidad, el programador sufre porque aquello que produce, que ha creado pensando y escribiendo código, siente de alguna forma que es parte de sí mismo. Y si considera que esa parte de él es “basura”, ese sentimiento erosiona su autoestima y lesiona su compromiso con lo que hace. Es una brecha muy peligrosa que abre el camino a otros sentimientos y que a la larga puede derivar en que la persona abandone el equipo. Y una persona que abandona el equipo por ese factor puedo asegurarte que es una persona que no convendría perder.

El cuidado de la calidad, fomentar un sentimiento de “élite”, huir de equipos homogéneos, mantener equipos de trabajo que funcionan bien y proporcionar dirección estratégica (largo plazo) y no táctica (corto plazo), son factores indispensables para conseguir buenos equipos de desarrollo.

“Todos piensan en cambiar el mundo, pero nadie piensa en cambiarse a sí mismo”. Leo Tolstoy

Las estructuras planas en el agilismo son buenas en general, pero las cosas no son tan sencillas en la realidad. Las personas del equipo tienen conocimientos distintos, experiencias diferentes y capacidades que varían de unos a otros. Es importante que en esa estructura plana se reconozca a los líderes, pero que también se ayude a los miembros del grupo que están más abajo en ese reconocimiento entre ellos para que progresen. Habrá momentos complicados, tensiones y será necesario resolver esas situaciones para que no degeneren y afecten a la cohesión del grupo. En mi experiencia, si mantienes como aliados la integridad, la honestidad y la lealtad, en general las personas lo reconocerán y apreciarán y normalmente los problemas se podrán resolver.

“La supervisión visual no sirve para los desarrolladores. La supervisión visual es para los presos”. Tom DeMarco

El hábito de aumentar la productividad calentando la silla como sistema es un mal del sector. Hace 15 años se aceptaba como algo normal. Hoy ya cuesta venderlo, aunque sigue vigente. Y desde luego, como sistema de trabajo, es nefasto, aparte de un fraude. Si la situación se torna complicada y es necesario redoblar esfuerzos para lograr hitos intermedios, es muy importante involucrar al equipo, explicar qué sucede y a la vez qué se va a hacer para no incurrir en los mismos errores en el futuro. Si todo consiste en que la planificación era irreal y se asume como algo normal que seguirá ocurriendo, porque no se toman medidas para cambiar las cosas, ese camino de forma invariable conducirá a lugares oscuros de los que es mejor mantenerse alejado.

“El propósito de un equipo no es el logro de metas, sino la alineación de objetivos”. Tom DeMarco

Un equipo no lo es hasta que todos tienen un objetivo común, reconocible, y cada uno ve que su trabajo colabora para conseguirlo. Siempre he pensado que la pregunta más importante en un proyecto no es el qué, el cómo ni el cuándo. La pregunta más importante es ¿por qué hacemos esto? El efecto que tiene hacer trabajo sin sentido en un programador es terriblemente desastroso. De hecho mi propuesta aquí es que se debería ir más lejos de lo que ha ido el agilismo en cuanto a involucrar al desarrollador y ponerle en primera fila. Creo que en muchos desarrollos sería muy bueno que el programador comprendiese por qué hace las cosas, lo que significa entender al menos parte de los procesos de negocio, y de ahí a que vengan propuestas por su parte es casi el paso natural.

La separación tradicional entre usuarios y programadores en la que el usuario pide y el programador desarrolla lo solicitado es hoy un escenario para mí superado. El programador en muchas ocasiones entendiendo por qué hace lo que hace y qué se trata de solucionar, puede proponer mejoras interesantes y nuevas características, sabiendo lo que se puede hacer técnicamente y que a veces ni los usuarios imaginan o que ni llegan a proponer porque piensan que es muy costoso.

“Dentro justo de un año, desearás haber empezado el cambio hoy”. Karen Lamb

Comencé el artículo mencionando un libro clásico sobre el tema y termino proponiendo otro: “Lean Enterprise -How High Performance Organizations Innovate at Scale”, orientado más a managers y directores técnicos, que complementa a mi juicio muy bien la obra de Tom y Timothy.

Los equipos de programadores no son equipos comunes; sus necesidades y preocupaciones difieren bastante de otros grupos de trabajo. La tecnología cambia muy rápidamente y se necesitan personas que aprendan de los cambios y que incluso sean motivadores. Esas son las personas más valiosas como desarrolladores, no son fáciles de encontrar, pero merece la pena dedicar esfuerzo y tiempo a lograrlo, porque puede suponer la diferencia entre surfear con habilidad en la ola tecnológica o que te trague y acabes en la orilla envuelto en arena, sin saber muy bien cómo has llegado hasta allí.

Foto: Crisi Calatrava