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 industrialImagine 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:
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).
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.
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.
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 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
