En los últimos meses he viajado mucho, posiblemente más que lo he viajado en muchos años. En uno de estos viajes tuve la suerte de sentarme delante de una pareja con su pequeño hijo de 3 o 4 años lleno de inquietud intelectual y energía. La energía era evidente en su constante ir y venir por el pasillo, en sus patadas a mi asiento y en los saltos sobre su padre. La inquietud intelectual se manifestaba en forma de las más variadas preguntas:
- Ma, ¿por qué no se mueve el colitivo?
- Colectivo
- Si, ¿por qué no se mueve?
- Porque está subiendo la gente.
- Ah...
- Ma, ¿adonde va ese otro colitivo?
- Colectivo
- Bueno, ¿adonde va?
- Capaz que vaya para Buenos Aires.
- Ah...
- Ma, ¿qué hay abajo del piso del colitivo?
- Colitivo no. Colectivo.
- ¿Qué hay abajo?
- Está la bodega donde dejamos los bolsos.
- Ah...
La persistencia maternal me hizo pensar en la importancia de estas correcciones para que ese pequeño más tarde o más temprano aprenda a decir colectivo. Entonces recordé pensamientos de mi niñez que han causado una fuerte impresión en mí dado el tiempo que ha pasado y la nitidez con que los recuerdo.
A la temprana edad de 6 años, tenía un amigo cuyos padres eran sordomudos. A mí me llamaba mucho la atención visitar su casa ocasionalmente y verlos comunicarse con lenguaje de señas. Era algo que me hacía pensar mucho. Lo que pensaba en ese momento era la mala suerte de estas personas por tener problemas en los oídos y en la lengua simultáneamente. No era algo agradable tener problemas para hablar o para escuchar, pero tener problemas para las dos cosas a la vez, eso si que era mala suerte. Con esa idea en la cabeza comencé a observar que era algo más común encontrar una persona sordomuda de lo que era cruzarse con alguien sordo pero no mudo o mudo pero no sordo. También me fijé que no se daban otras combinaciones que suponía igual de factibles, ciego-sordo, ciego-mudo.
“¡Qué raro!” pensaba.
“Debe existir como una enfermedad que afecta los oídos y la lengua a la vez.”
Esa conclusión me parecía lógica considerando las evidencias pero de todas maneras consulte el tema con mi mamá.
- ¿Viste que las personas siempre son sordomudas? Casi nunca son sólo sordas o sólo mudas.
- Claro, porque cuando una persona tiene problemas para escuchar desde chiquita no puede aprender a hablar.
- ...
Esa respuesta me hizo pensar más aún. Todas esas personas estaban físicamente en condiciones de hablar. Podían producir sonidos sin problemas. Simplemente no lo hacían porque no podían escuchar. No podían copiar los sonidos que hacían sus padres, y tal vez más importante, no podían escucharse ellos. No tenían retroalimentación de lo que hacían. Aunque pudieran escuchar a los demás, si no podían escuchar que sonido emitían ellos, no tenían posibilidad de corregirse. Sin retroalimentación simplemente no había aprendizaje. Una y otra vez emitirían sonidos ininteligibles y no podrían mejorarlos. Estaban condenados a errar.
A nadie le gusta cometer errores pero los cometemos todo el tiempo. Una vez tras otra. En cada ámbito de nuestra vida. Los repetimos o, algo mejor, cometemos nuevos errores cada día. Somos como una delicada máquina errática que va corrigiendo su curso constantemente. En el ámbito laboral, rara vez nuestro accionar pasa desapercibido para otros. Nuestras acciones dependen de lo que hacen otros y viceversa. Esta relación que se teje entre el comportamiento de varias personas desarrollando una actividad da lugar al surgimiento del fenómeno de retroalimentación, esencial para el aprendizaje.
Este mecanismo tiene distintas formas de presentarse en un equipo de desarrollo de software. En muchos equipos, por ejemplo, se compila todo el código al menos una vez al día. Esto se hace para saber que siempre se tiene código que al menos es correcto sintacticamente. Esto que parece tan elemental a veces es algo difícil de alcanzar. Recuerdo historias de compañeros en la facultad que rendían su última materia, donde debían presentar una aplicación que habían desarrollado durante todo el año o más ante un auditorio de decena de personas, con sus padres observando orgullosos, un panel de profesores y con un cañón mostrando una interfaz de usuario de 1 metro y medio de alto, y su aplicación no se podía compilar. Como muchos sabrán algunos entornos de desarrollo como Visual Basic permiten ejecutar una aplicación sin compilarla. Simplemente va interpretando el código a medida que necesita ejecutarlo. Por supuesto, en el momento que se encuentra con una incoherencia como la asignación de una cadena a una variable numérica, la aplicación explotará en nuestra cara (y en la de las de la audiencia, panel, padres y/o tutores) informándonos que no coinciden los tipos. Bien, ellos sacaban provecho de esta característica y ejecutaban su aplicación de esta manera en la presentación de su materia final. ¿Por qué alguien podría arriesgarse a presentar una aplicación en ese estado? Porque pasaron mucho tiempo desarrollando sin compilar la aplicación. Son tantos los errores para corregir, y son tantos los nuevos errores que aparecen cada vez que se corrige uno, que deciden evitar tener que posponer su graduación un año y toman el camino de la audacia y de la fe cristiana (“Ma si, yo me presento y que sea lo que Dios quiera”).
Concientes de este tipo de problemas o inspirados en un artículo de Michael Cusumano, muchos equipos de desarrollo compilan frecuentemente su código, posiblemente una vez al día o más frecuentemente. Esto mantiene una base de código limpia de errores elementales como la asignación de cadenas a variables enteras y otros tantos. ¿Cómo funciona esto? Se programa alguna tarea en el sistema operativo para que tome la última versión del código fuente existente en el repositorio y lo compile. En caso que existan errores, el encargado de mantener la integridad del repositorio verá en el informe que la compilación del día anterior no se pudo realizar por errores en algún archivo (o en varios) y, usando la herramienta de control de versiones identifica al culpable. Aquí es donde se activa la condena social que hace que el sistema funcione. El culpable deberá corregir el error para retornar al buen camino, pero además deberá comprar facturas para todo el equipo, encargarse de realizar la tarea de mantener la integridad del repositorio hasta que un nuevo individuo cometa su error o algo por el estilo. La idea es que este pequeño ritual define la importancia que tiene para el grupo mantener el repositorio código sin errores elementales, y además le avisa a cada miembro cuando está afectando este objetivo. Eso es retroalimentación en su estado más puro. El mensaje es claro: “Eres muy buen desarrollador pero nos gusta tener un repositorio libre de errores y vos LO ROMPISTE.”
Para una persona con el rol de desarrollador, esta retroalimentación se presenta fácilmente y de muchas maneras. Si no cumple con una fecha de entrega su jefe de proyecto lo llamará y le preguntará que sucedió, probablemente con una cara de preocupación que manifieste que hay un retraso importante. Si escribe un método que debe actualizar un registro en una tabla de una base de datos y olvida poner la cláusula WHERE, la mirada suspicaz de sus compañeros le dirá que eso es un error bastante común y que sería bueno que no se cometieran esos errores comunes. Yo lo hice y capte el mensaje en el ambiente :-)
Pienso que esta retroalimentación es positiva porque nos permite corregir nuestro comportamiento con mayor rapidez. Los efectos de los errores llegarán igual, la retroalimentación permite acelerar los tiempos de las soluciones y evitar que las consecuencias se propaguen, además de reforzar el aprendizaje. Por supuesto, esta retroalimentación debe mantenerse dentro de ciertos límites que no afecten las relaciones. Si cada vez que rompo una compilación en el repositorio, recibo una sesión de pedradas en la sala de reuniones de la empresa, bueno, podría considerar que no es positiva. La manera en que se da esta retroalimentación es parte de la cultura de un grupo y es una característica distintiva del mismo.
No hay que ser un observador particularmente agudo para percibir que no todos tienen la suerte de recibir la cantidad de retroalimentación que reciben los desarrolladores. A medida que subimos en la pirámide organizacional que existe en la mayoría de las empresas, más allá que nos guste hablar de autogestión y empowerment, las posiciones comienzan a volverse adversas a la retroalimentación. Esto es un fenómeno fácil de observar. Hay menos personas dispuestas a decir su opinión sobre el accionar de un jefe de proyecto que a criticar el trabajo de un desarrollador, pocas personas dicen algo sobre como está actuando un gerente y posiblemente nadie se anime a decirle una palabra negativa al dueño o CEO de la empresa (bueno, su esposa tal vez pero ese es otro ámbito). Por supuesto, no se trata que todos piensen que estas personas hacen bien su trabajo. Simplemente nadie dice lo mal que lo hacen, si es que piensan eso. Podemos decir que algo de esto tiene que ver con una evolución histórica de la organización occidental y su origen en la milicia y la iglesia, donde uno no opina sobre sus superiores. Pero también tiene que ver con el carácter de las personas que tienen estos roles. Hay jefes de proyectos y gerentes que les gusta hablar, conducir la conversación en cada momento. Es algo que uno puede identificar con 5 minutos de charla casual. Simplemente hablan, cuentan sus puntos de vista, tal vez hacen chistes, pero no escuchan. Les cuesta terriblemente escuchar. Pareciera ser que les resulta extraño juntarse con otras personas y sentarse a escuchar. Los requerimientos de su tarea diaria los acostumbro a conducir, a hablar, a decidir y comunicar, pero no a escuchar. Entonces esta actitud reacia natural que cualquiera puede tener a decir que algo que su jefe o superior está haciendo mal se ve potenciada por esa característica. Es muy difícil trabajar de esta manera. Significa que si ocupamos estos roles nadie nos dirá nada aunque cometamos un error tras otro, uno más grande que otro. Diríamos “colitivo” una y otra vez. ¿Será posible que esto sea así?
Imaginemos un jefe de proyecto en un proyecto X complicado. Está renegociando el alcance del proyecto con el cliente y esta tarea nunca es agradable. Si bien nadie salta de alegría, se está trabajando profesionalmente, se están planificando pequeñas entregas, se está midiendo el avance y se están estableciendo puntos de decisión en el tiempo en base al avance. Hay una luz al final del camino. Se han activado mecanismos de control. De a poco y con esfuerzo el proyecto se encamina. De pronto, aparece su superior inmediato y le dice: “Noté que el cliente del proyecto X no estaba del todo conforme. Así que me reuní con él y les dije que iban a tener todo lo pactado originalmente para la fecha estipulada y además agregamos un módulo de reportes. Ahora ya se calmaron las aguas. Espero que el equipo responda a las expectativas de la empresa”
¿Qué es lo que piensa el jefe de proyecto? “¡Pedazo de imbécil! Cualquiera puede calmar las aguas hoy haciendo grandes promesas, el problema es que vamos a hacer mañana.”
¿Qué es lo que dice el jefe de proyecto? “Mmm, bueno, si, creo que será algo complicado pero veremos como nos acomodamos. Muchas gracias y suerte en su partido de tenis.”
La verdad es que si existieran rituales proporcionales para este tipo de errores con respecto al error de incluir un archivo defectuoso en el repositorio, Argentina importaría trigo por el desabastecimiento de harina en las panaderías. Y es que el equivalente de este error en el ámbito de un desarrollador no sería incluir varios archivos con errores repetidamente. Sería mas bien como entrar en la sala de servidores, arrancar los discos de los servidores con los dientes y prenderlos fuego junto con las cintas de backup. Sin embargo no existen rituales de retroalimentación para estos roles. Todo esto tiene otras consecuencias.
Hay roles que tienen responsabilidades operativas o ejecutivas, y otros roles de responsabilidades tácticas y estratégicas. Esto además de indicar cual es el sueldo anual de un empleado, también define la cantidad de daño que uno puede hacer. Si un proyecto se demora 6 meses difícilmente la responsabilidad pueda ser de los desarrolladores. No quiero decir que su accionar no pueda influir en esta demora. Quiero decir que existen cientos de alternativas y decisiones que otras personas en roles superiores pueden tomar para que esto no suceda. Y en conclusión, si estas decisiones no se toman, pueden sentirse responsables directos de las consecuencias sin temor a equivocarse. El fundador de una pequeña empresa de software que se decide a entrar en el mercado de los procesadores de texto para desbancar a Microsoft Word del liderazgo con un producto de precio más competitivo, ha tomado decisiones estratégicas estúpidas que no hay manera de arreglar por mejor gestión de proyecto que tenga. Asignar culpas a personas con roles cuya responsabilidad es mucho más limitada que la supuesta consecuencia de sus acciones es como pensar que el responsable del derrumbe de las torres gemelas podría ser un niño que estaba jugando con su bolón explosivo en la vereda del World Trade Center. Por supuesto, como las reglas sociales implícitas de una organización permiten evidenciar los errores en algunos roles pero en otros no, ya todos saben hacia adonde apuntaran los dedos cuando algo ande mal. Es algo que se repite una y otra vez.
“Colitivo, colitivo, colitivo”
Pero existen otras situaciones que se repiten una y otra vez en los proyectos de software. Lo suficiente para que me encuentre una y otra vez leyendo sobre el tema en libros sobre gestión de proyectos de software. Un tema en particular me desvela y la última vez que leí sobre el mismo fue en Debugging the Development Process de Steve Maguire.
Cuando los proyectos comienzan a complicarse, las primeras dos acciones que los lideres toman usualmente son las obvias y fáciles: contratar más personas y forzar al equipo a trabajar más horas. Estas pueden parecer respuestas razonables, pero de hecho estas son posiblemente las peores opciones que los líderes pueden tomar para volver a encaminar un proyecto en problemas.
Imagine un galeón mercante del siglo dieciséis cruzando el Atlántico del Viejo Mundo hacia el Nuevo Mundo. Cuando el galeón está alejado mar adentro, el primero de a bordo nota que la nave se está llenando de agua y alerta al capitán. El capitán ordena a los miembros de la tripulación que quiten el agua, pero a pesar de su esfuerzo, el agua sigue subiendo. El capitán les ordena a más miembros de la tripulación a quitar el agua€¦ Pronto el capitán tiene a la tripulación entera quitando agua en turnos, pero el agua sigue subiendo.
Dándose cuenta que no tiene más marineros para quitar agua, y con el navío inundándose, el capitán ordena a todos los miembros de la tripulación a que trabajen más horas, sus días y noches se transforman en quitar agua, colapsar exhaustos, despertarse y volver a quitar agua. Funciona. Los marineros no sólo están previniendo que el agua siga subiendo, sino que están haciendo progreso, quitando agua más rápido de lo que entra. El capitán está contento. Mediante su brillante gestión de recursos humanos, él previno que el navío se hunda.
Al menos durante la primer semana.
Pronto los miembros de la tripulación caen rendidos y comienzan a quitar menos agua de lo que quitaban cuando trabajaban en turnos y estaban más descansados. El navío nuevamente comienza a inundarse de más agua de la que ellos pueden quitar. El primero de abordo intenta convencer al capitán que debe permitir que los marineros descansen si quiere que sean efectivos. Pero porque el navío se está hundiendo el capitán rechaza cualquier charla sobre darle a la tripulación un descanso. 'Nos estamos hundiendo. La tripulación debe trabajar más horas,' grita el capitan. '¡Nos estamos hundiendo!'
El agua sigue subiendo y finalmente el navío se hunde, llevándose a todos con él.
¿Podría haber existido una mejor manera de salvar ese navío que poner a todos los miembros de la tripulación a quitar agua y forzarlos a trabajar más duro y más horas? ¿Si estuvieses en esa nave que se está inundando, que hubieras hecho? Yo puedo decir que hubiera hecho: yo hubiera buscado las filtraciones de agua.
Suena obvio. Pero una y otra vez observo que ese camino obvio no es tomado. Y me llama la atención porque conozco personas inteligentes, con experiencia, capacitadas, estudiando gestión de proyectos, gestión de riesgos, con títulos del PMI, cursos de CMM, posgrados, MBA. Y siguen tomando malas decisiones en estas situaciones. No se trata de opiniones, o de coincidir o no con un enfoque. Por un momento olvidémonos de las consecuencias que pueden tener en una persona trabajar 12 horas y no tener fines de semanas. Viendo la situación desde un enfoque completamente práctico, que un jefe de proyecto haga trabajar 12 horas y fines de semana a su equipo durante meses es mal desempeño. Tan simple como eso. Porque esta actuando de una manera poco racional, no está solucionando nada. Tiene la excusa perfecta (“hicimos todo lo que pudimos”) pero las excusas sirven de bastante poco. Lo que yo me preguntaría si fuera su superior sería: “¿cuándo piensa solucionar algo? Veo que trabajan muchas horas pero, ¿cuándo vamos a ver las soluciones?” Son simplemente malas decisiones. Es mal desempeño. Es un hecho cristalino como el agua de un arroyo cordillerano. Tan mal desempeño como lo es que un desarrollador entregue su trabajo fuera de término, lleno de errores, sin documentar y sin respetar directivas de codificación. O un vendedor que no pudo vender un helado en todo el verano.
Pienso que la falta de retroalimentación de algunos roles puede ser un factor que influye en esta repetición constante de errores. Esto se ha alargado demasiado y debe existir alguna conclusión, en este caso casi arrogante de mi parte:
Si tienes poder de decisión sobre un proyecto en el que la norma es trabajar 12 horas por día y fines de semana, si tienes poder decisión sobre ese proyecto y tienes la idea de agregar más gente al proyecto, si sabes que todos se quieren ir y sólo se te ocurre cerrar puertas y ventanas, si ves que más allá del esfuerzo los problemas siguen ahí, posiblemente las señales de retroalimentación que recibes son muy sutiles, casi imperceptibles. Déjame tomarme el atrevimiento y hacerlas más nítidas: estas haciendo mal tu trabajo, estas cometiendo el mismo error una y otra vez. Pero no hay nada que te impida hacerlo mejor. Eso es muy bueno. Significa que mañana mismo puedes empezar a buscar las filtraciones.
No hay que ser un genio para aprender. Sólo hay que observar nuestros errores y corregir nuestro accionar. Esto es cierto para el niño que pateaba mi asiento y decía “colitivo”, y es igual de cierto para el jefe de proyecto que piensa que la única manera de encaminar un proyecto es haciendo lo mismo que hace siempre y que nunca solucionó nada. Ambos pueden aprender y decir un día:
“Colectivo”
“Vamos a buscar las fallas en este proyecto y vamos a solucionarlas. Para empezar tómense el día libre.”
