Programar es un trabajo intelectual

En su célebre obra Peopleware: Productive Projects and Teams, los autores Tom DeMarco y Timothy Lister comparan la actividad de “programar” con otra actividad altamente industrializable, como es el negocio de la comida rápida. El siguiente cuadro resume los puntos de comparación:

Las siguientes medidas pueden resultar eficaces para aumentar la productividad de una hamburguesería (o en cualquier línea de producción industrial):

• Reducir la tasa de error: Evitar que las personas cometan errores (tratarles como si fueran máquinas).
• Dirigir a las personas con estilo autoritario: Aumentar la presión, exigirles más horas de trabajo (no remuneradas).
• Tratar a las personas como elementos sustituibles (como si fueran piezas de una máquina).
• Optimizar el ritmo de producción para mantenerlo constante (que no crezca ni decaiga).
• Estandarizar el Proceso: Hacerlo todo según el manual.

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

• Exigir una cuota de error (derecho de veto): Muchos proyectos software son proclives a errores, sobre todo cuando los requisitos no pueden determinarse apropiadamente. Aquí la forma aconsejable de avanzar es por iteraciones incrementales, produciendo prototipos algunos de los cuales serán desechados. Este coste se debe asumir porque es muy inferior al retrabajo si el producto es rechazado a la entrega. Muchas veces es necesario retroceder 2 pasos para avanzar 10. Un jefe que exija a los programadores que no se equivoquen ha de esperar alto nivel de retrabajo. Si por el contrario les pide que le informen sobre cuántos diseños han desechado, o cuántas horas de programación han resultado infructuosas, dejando claro que “cero” no es buena respuesta, podrá esperar menos retrabajo final, mayor satisfacción de los miembros del equipo y mejor desempeño global. Los programadores tienen derecho a generar productos de calidad cada vez. Cuidado con decirle a un programador “Lo práctico antes que lo perfecto, Pepe, quiero que este programa funcione mañana, esté como esté”. Al pobre Pepe le estamos disparando en la línea de flotación de su autoestima. Su estándar de calidad es “lo mejor que lo he hecho antes en algo parecido”. Un buen Director de Proyectos le da derecho de veto a sus programadores: “Mi equipo dice que si entregamos este sistema mañana, no tendrá un nivel de calidad aceptable y aparecerán muchos defectos en producción. Lo siento mucho, pero la nueva fecha de entrega será dentro de una semana. No es negociable”. 
• A los programadores les gusta su trabajo: Estar encima del trabajador, pendiente de si trabaja o no, azuzándole continuamente, puede ser beneficioso en el negocio de las hamburguesas, no lo es para dirigir a un grupo de programadores. Un toque de atención hace que la gente se active, pero no consigue que la gente piense mejor. Los programadores necesitan su cabeza al 100%, no necesitan que les alienten, a la mayoría les encanta su trabajo. Un buen jefe les persigue más bien para que no trabajen tanto, que es lo que suele ocurrir.
• Los programadores no son intercambiables: El jefe de una línea de producción  ve los  individualismos como amenazas. Para estos jefes, 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. 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, si es posible un poquito menos conflictiva, muchas gracias". Por el contrario, un proyecto de desarrollo software 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 Rafael tiene un coste. 

• En el mejor de los casos, si Rafael entra al día siguiente de la partida de Luisa, su productividad neta será negativa. Si Luisa producía 60 Puntos-Función al mes, dado su desconocimiento inicial y la penalización en el rendimiento de los demás miembros del equipo, la productividad neta de Rafael puede comenzar siendo de -20 PF/mes. Su tasa de productividad crecerá con el tiempo hasta ponerse al nivel de Luisa. El área sombreada del dibujo (parecida a un triángulo) representa gráficamente el coste de la sustitución. Si tarda tres meses, este coste es como mínimo 120 Puntos-Función (como 2 meses de Luisa). Es fácil imaginar el perjuicio mayor cuando la sustitución no ocurre  inmediatamente (rectángulo+triángulo).
• Un proyecto es algo dinámico: Los proyectos empiezan y acaban, no son operaciones repetitivas. 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 hacer tareas, ¿qué proporción del tiempo habrá que dedicar a hacer dichas tareas? No el 100%. En todo proyecto es aconsejable hacer alguna provisión para tiempo “improductivo” (brainstorming, planificar, estimar, investigar nuevos métodos, leer, formarse, incorporar a nuevos miembros, etc.). La mentalidad de producción continua típica del negocio de las hamburguesas generalmente no concede importancia alguna a “pensar” sobre la naturaleza del trabajo. 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! La pregunta clave “Esta tarea, ¿de verdad debe hacerse?” es si cabe más pertinente en los proyectos duros. Cuanto más heroico sea el esfuerzo, más importante es 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”.