La mentalidad “hamburguesa cocinada, hamburguesa vendida”

 
El desarrollo de software es una actividad muy diferente a la producción. Sin embargo, los Directores de Proyectos de software a menudo aplican una filosofía de gestión derivada completamente de los entornos de producción de la era industrial.

Imagine por un momento que usted es el gerente de una franquicia local de comida rápida. Para usted, tendría mucho sentido tomar cualquiera de las siguientes medidas para aumentar la eficacia en la producción:

• Reducción de la tasa de error: Hacer que la máquina (humana) funcione tan suave como sea posible.
• Dirección autoritaria (presionar, castigar, más horas).
• Tratar a los trabajadores como piezas intercambiables de una máquina.
• Ritmo de producción constante: No pensar en lo que supone la transición operativa para ganar velocidad o el tiempo que supondrá cerrar la operación.
• Estandarizar el proceso: Hacerlo todo según el manual.
• Eliminar la experimentación (para eso pagan a los de servicios centrales).

Estas medidas serían razonables si usted se dedicara al negocio de la comida rápida (o a cualquier otro entorno de producción), pero no es así. Usted es Director de Proyectos. La mentalidad de “hamburguesa cocinada, hamburguesa vendida” puede resultar fatal si se dedica al desarrollo de software, o cualquier otro proyecto relacionado con el “trabajo del conocimiento”. Solo le servirá para quitarle la ilusión a la gente y para alejar su atención de los problemas reales.

Este estilo de gestión es completamente opuesto a la efectividad en el tipo de trabajos que debe desarrollar el “knowledge worker”.


Puesto que programar es un trabajo intelectual, estas medidas resultarían contraproducentes en un proyecto de desarrollo software. Un buen Director de Proyectos software debería adoptar justo las contrarias:

Exigir una cuota de error

Para la mayor parte de los trabajadores del conocimiento, cometer ocasionalmente un error es natural y saludable en su trabajo. Pero puede haber una asociación casi bíblica entre error en el trabajo y pecado. Esta es una actitud que hemos de cambiar.

En una ocasión, en una conferencia que impartíamos para un grupo de directores de desarrollo, introdujimos una estrategia denominada “diseño por iteraciones”. La idea era que algunos diseños son intrínsecamente propensos a errores, deben ser rechazados, no reparados. Estas vías muertas deberían esperarse en la actividad de diseño de software. El esfuerzo perdido aquí es un pequeño precio que hay que pagar para lograr un comienzo limpio y fresco. Para nuestra sorpresa, muchos directores dijeron que esto supondría un problema político imposible para con sus jefes: “¿Cómo podemos tirar un producto que a nuestra empresa le han pagado por producir?” Parecían creer que harían mejor guardando la versión defectuosa aunque costase más a largo plazo.

Cuando se promueve una atmósfera de trabajo en la que no se permite el error, esto hace que la gente se ponga a la defensiva. No intentan cosas que podrían resultar mal. Se fomenta esta actitud defensiva cuando se trata de sistematizar el proceso, cuando se imponen metodologías rígidas para que los miembros del equipo no tomen ninguna decisión estratégica, no sea que se equivoquen. Gracias a los pasos que se toman para evitar los errores, el nivel “tecnológico” del equipo puede mejorar un poco. El nivel “sociológico”, sin embargo, puede sufrir gravemente.

El enfoque contrario sería el de animar a que las personas cometan algunos errores. Se puede conseguir esto preguntándoles ocasionalmente cuántas vías muertas han descartado, y asegurándose de que entiendan que “ninguna” no es buena respuesta. Cuando se equivoquen, deben sentirse bien (también les pagan por eso).

A los programadores les gusta su trabajo

Dirigir es algo lo suficientemente complejo como para no poder definirlo de forma simple, pero esto no era un problema para un director senior que encontramos en una conferencia en Londres. Él resumió su punto de vista en la materia con esta frase: “Dirigir es pegar patadas en el trasero”.

Esto es lo mismo que decir que los directores piensan todo y los subordinados se limitan a cumplir las órdenes. Otra vez, esto puede dar resultado para una hamburguesería, no para cualquier esfuerzo en que las personas trabajen con sus cabezas, más que con sus manos.

Cualquiera en un entorno semejante debe tener el cerebro a punto. Se puede dar patadas para hacer que la gente se active, pero no para que sean creativas, inventivas y reflexivas. Incluso aunque dar patadas en el trasero hiciera que la gente aumentara su productividad en el corto plazo, no sería útil en el largo plazo: No hay nada más desalentador para un trabajador que el sentimiento de que su motivación es inadecuada y que necesita un “suplemento motivacional” por parte del jefe.

Lo más triste de este enfoque de gestión es que la mayoría de las veces es superfluo. Rara vez resulta necesario tomar medidas draconianas para hacer que la gente siga trabajando; a la mayoría les gusta su trabajo. Por el contrario, a veces es necesario tomar medidas para hacer que trabajen menos, y así hagan más trabajo de calidad.

Los programadores no son intercambiables

En los entornos de producción, es conveniente pensar en la gente como partes de una máquina. Cuando una parte se avería, se puede sustituir. La pieza nueva es intercambiable con la original. Se piden piezas nuevas indicando cuántas hacen falta, más o menos. Muchos responsables de desarrollo adoptan la misma actitud. Se convencen de que nadie es insustituible.

Contra el riesgo del trabajador que se despide, elaboran la ilusión mental del “pool de recursos”, que consiste en descolgar el teléfono y decir “Por favor, envíenme para mañana una nueva Luisa Pérez, y si es posible, que sea un poco menos conflictiva, muchas gracias.”

Estos jefes ven los individualismos como amenazas. Para ellos, la buena gestión implica que la producción no dependa de las personas. No hay personas clave y se pueden sustituir como las piezas de una máquina.
Sin embargo, un proyecto necesita personas clave. Si no están al principio, al poco tiempo acaban siéndolo. Un buen Director de Proyectos fomenta y aplaude este desarrollo personal, y por supuesto, sabe que reemplazar a Luisa por un tal Rafael tiene un alto coste.

Un proyecto es algo dinámico

Un Director de Proyectos puede hacer estimaciones y gestionar su proyecto pensando que el ritmo de producción se mantiene constante, que ni sube ni baja. El ritmo de producción puede medirse de muchas formas: entregas por semana, funcionalidad construida o documentación generada por persona y día, etc.

Sin embargo, un proyecto es siempre dinámico. Los proyectos no son operaciones repetitivas. Tendemos a olvidar que principal objetivo de un proyecto es finalizar. El único estado estable de un proyecto es el rigor mortis. Salvo que el proyecto esté a punto de terminar, hay que esperar que el ritmo de producción sea variable, muy dependiente del grado de cohesión del equipo y de cómo crecen las personas en esa asignación particular.
 

Replantearse el trabajo (no sólo hacerlo)

Si nos pagan por terminar tareas, ¿qué proporción del tiempo habrá que dedicar a hacer dichas tareas? No el 100%. Debe hacerse una provisión para tiempo “improductivo” (por ejemplo: reuniones de brainstorming, planificar, estimar, investigar nuevos métodos, leer, formarse, incorporar a nuevos miembros, perder el tiempo, etc).

La pregunta clave “esta tarea, ¿de verdad debe hacerse?” es si cabe más pertinente en los proyectos críticos. Cuanto más heroico sea el esfuerzo, más importante es replantearse el trabajo, no solo hacerlo, que los miembros del equipo funcionen “como una piña”, más frecuentes deben ser las sesiones de brainstorming, más necesarias las actividades de “socialización”.

La aspiración es lograr un 100% en modo “hacer”, y un 0% en modo “pensar”. La justificación es que se trabaja a contrarreloj. ¡Como si hubiera algún trabajo que no ha de hacerse a contrarreloj!

Este texto se ha traducido del libro:

Peopleware: Productive Projects and Teams

Tom DeMarco & Timothy Lister. Dorset House Publishing, 1998