Fast company recientemente publicó una entrevista con Fred Brooks, quien en la década de los 60s dirigió uno de los proyectos de software más grandes de la historia –la creación del sistema operativo para los sistemas IBM 360 (posteriormente conocidos como “mainframe”).
Brooks es autor del libro The Mythical Man-Month, un clásico de la ingeniería de software, que contiene frases reveladoras como: “agregar más personas a un proyecto de software retrasado, solamente lo retrasa más”, o “todos los programadores son optimistas”. Su libro más reciente, es The Design of Design: Essays from a Computer Scientist publicado en 2010. Recientemente platicó con Co.Labs (Fast Company) sobre dirección de proyectos, diseño y por qué los gerentes todavía cometen los mismos errores:
La entrevista original en inglés está disponible aquí. A continuación comparto una traducción que hice al español con los comentarios que considero de mayor relevancia.
Has comentado que “todos mencionan a ‘The Mythical Man-Month’, pero solo algunos lo leen y todavía menos le hacen caso”. ¿Por qué dices esto?
Simplemente basta con echar un vistazo al desastre del nuevo sistema para gestión de seguros médicos en Estados Unidos; cometieron prácticamente todos los errores mencionados en el libro.
El libro ha vendido más de 500,000 copias y es parte del currículum de las licenciaturas de ingeniería de software. Así que muchos han aprendido de los errores y aprendizajes que documenta, pero si escoges a alguien que no es un ingeniero de software, para dirigir un proyecto de software, es muy probable que no esté consciente de estas lecciones y cometa los mismos errores.
El error más grande del software para el sistema de salud es que no había nadie a cargo del proyecto; no tenía ni un project manager, ni un arquitecto. Eso es un error fundamental.
¿Por qué es importante que un proyecto de software tenga un project manager y un arquitecto de software?
Creo que es importante, incluso en equipos pequeños, distinguir las funciones del project manager y el arquitecto. El arquitecto es responsable de las decisiones técnicas, el project manager es responsable del calendario y recursos. En la industria cinematográfica existe una división de funciones similar entre el productor y el director. El productor es responsable de que la película se realice, y el director trabaja para el productor, pero el director es responsable de todo el contenido artístico y decisiones de contenido.
El project manager primero debe ser duro, y luego debe ser flexible. Un lema que me gusta es: “nunca inseguro; siempre abierto” (never uncertain; always open), la cual vi escrita en el techo de una universidad en Heidelberg, Alemania. Es importante siempre tener una dirección y moverse hacia ella, no puedes girar un barco que está parado. Pero también es importante estar abierto a cambios en circunstancias y dirección, y no ser completamente terco. Un project manager también debe ser alguien que entienda a las personas, ya que la mayoría de los problemas al dirigir proyectos, son problemas de personas.
¿Por qué todavía es tan difícil estimar cuánto tiempo tomará hacer un software?
Al construir una casa trabajamos con tecnologías conocidas y especificaciones conocidas. Pero cuando construyes algo nuevo, no sabes con qué problemas te puedes encontrar. El problema de la estimación de software es que continuamente trabajamos con tecnología nueva para crear soluciones nuevas también.
En tu libro más reciente, The Design of Design mencionas “Creo que una ‘ciencia del diseño’ es una meta imposible. ¿Por qué?
La diferencia entre la ciencia y la ingeniería no está tanto en lo que se hace, sino por qué se hace. El científico invierte esfuerzo en construir un aparato para un experimento, pero lo hace para aprender. En cambio, el ingeniero puede dedicar mucho tiempo a estudiar materiales, usos o diseños previos, pero aprende para poder construir. Esa distinción es crucial.
Así que pienso que la intención de la Fundación Nacional de Ciencias de crear un programa para “la ciencia del diseño” es errónea, porque construir es distinto a aprender las leyes de la naturaleza. Puedes sistematizar leyes de la física, pero no necesariamente sistematizas el proceso bajo el que los físicos trabajan.
Mencionas que aplicar procesos estándar de diseño corporativo puede ayudar a mejorar el desempeño promedio de los diseñadores, pero también inhibe lograr diseños innovadores y grandiosos. ¿Como sabe un diseñador cuando y hasta donde aplicar el proceso?
Creo que ese juicio es el que distingue a los buenos diseñadores de los malos. No hay forma de decirle a una persona como hacerlo. Sin embargo, es posible entrenar a las personas –por medio de participación en proyectos y mentoría– para que desarrollen ese gusto y juicio a lo largo del tiempo. Hay un dicho que dice: “el buen juicio viene de la experiencia, y la experiencia viene de las malas decisiones”. Creo que eso se aplica al entrenamiento de diseñadores.
¿Cómo se debe entrenar a los diseñadores?
Hacerlos participar en el diseño de una variedad de proyectos, de manera supervisada y con mentoría. Que tengan rotación entre distintos aspectos del proceso de diseño y construcción. El diseñador está entre el usuario y el constructor, así que necesita entender al usuario y dedicar tiempo con usuarios haciendo lo mismo que ellos, pero también necesita entender la construcción y dedicar tiempo a construir para entenderlo.
- Log in to post comments