The Gervais Principle

Para aquellos a los que les gusta (o no pueden para de mirar) The Office y se ríen (o lloran) con Dilbert y están dispuestos a leer largo duro y parejo, y a pelearse con un inglés un poquito más difícil que la media:

The Gervais Principle, Or The Office According to “The Office”

Para tentarlos y de paso tenerlos a mano para cuando se necesite, dos botones de muestra:

Ojo que es más serio que lo que parece. Lo encontré leyendo el blog de Erik Dietrich, también recomendable para agregar al feed.

PD para cuando lean un poco de eso: yo me considero claramente un looser, y -creo- es fácil distinguir a los sociopaths (antes de que alcancen el nivel al que sólo ellos pueden llegar, si no pierde la gracia)... lo divertido es ponerse a discutir quiénes son los clueless. Tengan en cuenta que no todos son tan "puros" como Michael.

Frases: Liderazgo.

“Leadership is the art of trading imaginary things in the future for real things today”.

Dilbert es genial.

Lo que sabemos que sabemos, lo que sabemos que no sabemos, lo que no sabemos que sabemos y lo que no sabemos que no sabemos.

Hay aquí alguien a quien nunca pensé que podría citar –seriamente- en este blog: Donald Rumsfeld. Parece que el tipo se da aires de poeta, y que encima no es tan malo:

The Unknown
As we know,
There are known knowns.
There are things we know we know.
We also know
There are known unknowns.
That is to say
We know there are some things
We do not know.
But there are also unknown unknowns,
The ones we don't know
We don't know.

—Feb. 12, 2002, Department of Defense news briefing

El poema fue mencionado en el recientemente muerto y resucitado Coding Horror (por cierto, qué vergüenza. Es brutalmente cierto aquello de “En casa de herrero cuchillo de palo” y “Haz lo que digo mas no lo que hago”).

Confusión en el tren.

Un joven programador y su Project Manager abordan un tren que atraviesa una zona montañosa, pero lamentablemente la locomotora había hecho una parada anterior y casi no encuentran lugar donde sentarse a excepción de dos puestos justamente al frente de una mujer joven que viajaba con su abuelita. Después de estar un rato sentados, tanto la mujer como el joven programador empiezan a intercambiar miradas, pero este juego se acaba cuando el tren pasa por un túnel que deja el interior del ferrocarril absolutamente oscuro.

En ese momento se oye un sonido de un beso seguido por otro de una cachetada.

Apenas el tren abandona el túnel los cuatro se quedan como si nada y nadie dice ninguna palabra, sólo se quedan pensando:

La abuela piensa: “Ese joven fue muy descarado al besar a mi nieta, pero me contenta que ella se haya desquitado con esa cachetada”.

El Project Manager piensa: “No sabía que mi programador fuera lo suficientemente valiente como para besar a esta chica, pero que malo que falló su golpe y terminó pegándome a mí”.

La joven mujer piensa: “En realidad sí me gustó mucho el beso de este tipo, ojalá mi abuela no le hubiera pegado”.

El joven programador quien está sentado con una enorme y envidiable sonrisa de satisfacción piensa: “La vida es buena. ¿Qué tan seguido una persona como yo tiene la oportunidad de besar a una hermosa mujer y a la vez darle una cachetada a su Project Manager al mismo tiempo?”.

Leído en LíderDeProyecto.com.

Una mala costumbre.

Identificado 100% con la última tira de Sinergia sin control. No hay nada que hacer: los programadores cometemos errores, probamos mal, nos vamos por las ramas, ignoramos las reglas más básicas del negocio… y los PM hacen este tipo de cosas (del tipo que ilustra la imagen de aquí al lado)… todo el tiempo y en todos lados. Aunque mal de muchos consuelo de tontos… por lo menos entiendo que no es algo personal.

Tal vez peque de corporativismo… no puedo dejar de pensar que hay una diferencia sustancial. Los programadores no podemos dejar de cometer errores, sin importar cuánto lo intentemos… cualquiera que se de un paseo por allí verá que (en general) de todas maneras hacemos un gran esfuerzo por evitarlos. ¿Es igualmente imposible no comprometer el tiempo de los demás sin consultarles? ¿No es de sentido común?

Se ve que no.

Cómo microsupervisar como un verdadero ...

Saltando desde lboisset's Ruminations hacia Amalgama de letras llegamos hasta esta vieja entrada en el blog de Santi Garcia que presenta este corto sobre micromanagement.

Se titula “How to micromanage like a real asshole ass****”. Está en inglés pero es bastante sencillo de entender y Santi se ha tomado el trabajo de transcribir y traducir los puntos básicos en su entrada. Copio aquí sólo los encabezados como un servicio a aquellos para los que seguir un link representa un desafío supremo:

Paso 1: Controle, critique, asfixie.

Paso 2: Documente el tiempo que se pierde.

Paso 3: Explique todos los detalles.

Paso 4: Controle.

Paso 5: Machaque a los disidentes.

Paso 6: Interrumpa.

Paso 7: Encuentre errores insignificantes.

Paso 8: Corrija los errores.

Y por fin, el video:

Frases: Iniciativa.

Rara vez publico un insulto aquí, en esta “sección” de frases, pero ésta que remata la tira de hoy de Dilbert me pareció muy buena:

“Your head is where ideas go to die”,

sobre todo por el contexto (vean la tira). Hace mucho, en la cursada de “Sociología de las organizaciones” tuvimos la visita de un gerente de una mutual del estado. Un tipo joven, lleno de iniciativa, con verdaderas ganas de mejorar no sólo el servicio sino también la calidad del trabajo.

Hablaba sobre todo de management y algo que hoy sería como empowerment (eran otras las palabras pero era eso, al fin y al cabo). No todas sus ideas me parecieron buenas, y le comenté mis reparos sobre alguna de ellas, relacionada, justamente, con la iniciativa. Me contestó algo que recién ahora empiezo a valorar (esto no es textual, por supuesto):

“Mirá, son ideas. La mayoría ni siquiera son mías, sino de la gente con la que trabajo. Cuando vienen a quejarse por algo o con problemas en general ya tienen una solución en la cabeza, y en principio yo lo único que hago es decir sí y ayudarlos a que ellos la pongan en marcha. Si luego no funciona ellos mismos vendrán con otra, y con otra y así… bueno, en algún momento va a salir ¿no?

Lo importante no es tanto el éxito de una iniciativa como el hecho de demostrar a la gente que presentar esa iniciativa vale la pena, que si piensan proactivamente eso se transforma en cosas reales. Si yo cajoneara las iniciativas que me parecen malas –muchas me parecen malas- perdería también las buenas. Total, ya te digo, si no funciona… probamos otra vez”.

Frankenstein, el líder de proyecto (XVII).

ATENCIÓN: ¡No sigas si no has leído la dieciseisava parte! Y si no has leído nada empieza por el principio.

---

[Resumen: siguiendo las órdenes de Frankenstein al pie de la letra la criatura silenció los errores, por lo que ante su inevitable ocurrencia el módulo descartó los datos silenciosamente. Luego de un mes de operaciones el equipo descubre que el módulo de Pago a Proveedores nunca funcionó.  Frankenstein, desesperado, recurre al líder técnico, quien le niega su apoyo comprometiéndose solamente a reescribir el módulo lo más rápido posible… que no es mucho.]

Frankenstein salió de la sala de reuniones con la vista clavada en la punta de sus zapatos. Una vez sentado frente a su escritorio su atención vagabundeó distraídamente por la oficina posándose finalmente sobre su creación, que fijaba la suya en la pantalla.

Ya no lo soportaba. La presencia de aquel inútil arreglo de carne y huesos no hacía más que impedirle pasar el mal trago de los últimos días, cargados de cuestionamientos y vanas explicaciones.

Pasó algún tiempo y poco más. La recodificación del módulo avanzaba a cargo del líder técnico. La criatura continuaba cumpliendo pacientemente el ritual de entrada, espera y salida, al que ahora se había sumado Frankenstein. Expulsado de los círculos de confianza de la empresa, se encontraba falto de nuevos proyectos o iniciativas propias.

No tardó mucho en comprender que el equipo lo invitaba a partir. Sabía que eventualmente podría recuperar la confianza de sus superiores pero no el respeto de sus colaboradores. Ante ellos este episodio había descubierto su visión –su incomprensión, dirían ellos- del desarrollo de software. Una visión que no solamente no compartían, sino que despreciaban.

Redactó una carta de renuncia, que presentó la semana siguiente.

Pasaron un par de meses antes de que el líder técnico, sin saber qué hacer con aquel extraño programador caído en desgracia, se decidiera a despedirlo.

- ¿Qué tengo que hacer ahora? –preguntó ingenuamente la criatura luego de que se le comunicara la decisión.

- No sé… –respondió el líder, incomodado por la pregunta- depende de vos ahora… estoy seguro de que buscando podés encontrar algún lugar en el que te sientas cómodo…

La criatura se encontró, en una tarde lluviosa de viernes, parado en una esquina del microcentro porteño. A su alrededor una corriente silenciosa de personas se abría paso entre las bocinas de los autos y colectivos. Sin saber qué hacer, caminó hasta el estudio de Frankenstein.

- ¿Qué hacés acá?

- Me… dijeron que me vaya. ¿Qué tengo que hacer ahora?

- ¿Te echaron? Era de esperarse… fue un error, nunca tendría que haberte creado, ahora lo entiendo.

- ¿Qué tengo que hacer ahora?

Su mirada vacuna revelaba el sinsentido de su existencia. Frankenstein lo miraba horrorizado, no soportaba lo que aquella criatura le decía sobre él mismo, sobre su tozudez, su soberbia, su adicción al poder, al control.

- Hacé tu vida, no quiero volver a verte –le dijo mientras cerraba.

La criatura detuvo la puerta firmemente, y así quedaron por unos segundos. Frankenstein, incrédulo ante aquel atrevimiento y la criatura inmóvil, la vista perdida, intentando resolver aquel enigma… ¿qué hacer ahora?

- ¿Có… cómo me llamo? –preguntó.

- No sé -Nunca le había dado un nombre. La criatura soltó la puerta. Un golpe seco retumbó en los pasillos del edificio. Frankenstein observó por la mirilla mientras ésta volvía sobre sus pasos y desaparecía por el ascensor.

Salió del edificio, hacia la lluvia, y se perdió por las calles de Buenos Aires.

…fin.

Frankenstein, el líder de proyecto (XVI).

ATENCIÓN: ¡No sigas si no has leído la quinceava parte! Y si no has leído nada empieza por el principio.

---

[Resumen: con el sistema ya en producción y en medio de una calma absoluta, el departamento de SAC (Servicio de Atención al Cliente) recibe un informe de error de parte del área de pago a proveedores. El jefe de SAC revisa la base de datos del cliente y consulta al analista a cargo del proyecto, quien luego de confirmar el error renuncia precipitadamente.]

“Esto no hace más que confirmar mis teorías –pensaba Frankenstein luego de leer la carta del analista renunciante-. Este tipo está claramente desequilibrado, qué duda cabe. Se comporta normalmente hasta que un buen día empieza con problemas, se queja de la calidad de su propio trabajo, intenta eludir el compromiso… finalmente lo asume, trabaja a destajo para corregirlo, lo logra… y cuando todo es un éxito… renuncia. Así, sin más explicaciones salvo esta carta de agradecimiento…”.

Estaba de buen humor. Se sentía lleno de energías y nuevos proyectos. Las presentaciones y los informes le habían dado la oportunidad de ganar la confianza de clientes y accionistas y él la había aprovechado. El camino para su nuevo proyecto estaba prácticamente allanado.

“En un año, tal vez en menos –pensaba-, mi único problema, las personas, será sólo un mal recuerdo. El analista será el primero en ser reemplazado por una nueva criatura. El líder técnico está por irse, lo presiento, y será el siguiente. Con un aliado a la cabeza de cada área controlaré el desarrollo. No habrá que preocuparse por los demás, el que no se adapte será reemplazado”.

El jefe de SAC pasó por la puerta de la oficina, interrumpiendo sus ensoñaciones.

- Me imagino por tu buen humor que todavía no viste el reporte que ingresé ayer al sistema. Yo que vos apuraría eso.

Frankenstein ingresó al sistema y leyó el reporte. Dos veces. Con los codos apoyados sobre el escritorio y las manos tomándose la cabeza, bajó la vista y conoció el infierno. El mismo que ya habían atisbado el líder técnico y los demás programadores, sólo que desde otro punto de vista. Todo estaba, como había indicado el líder técnico, irremediablemente perdido.

- Imagino que ya leíste el reporte –el líder técnico, al tanto de la situación desde temprano, estaba ahora sentado frente a él.

- No entiendo… ¿cómo pasó esto?

- Ya te dije que el chico no piensa, que no tiene criterio, que sólo es un muy mal traductor, ni siquiera un intérprete. Supongo que… alguien… le habrá indicado que el módulo debía pasar las pruebas, que no debían verse más errores… o algo por el estilo. Supongo que fuiste vos, ya que no acepta órdenes de nadie más.

- Yo… yo le dije que…

- Le dijiste lo que terminó haciendo. El módulo funciona con los casos de prueba y no se ven errores. ¿No era eso? El problema es que sólo los casos de prueba funcionan y que jamás muestra errores. Así que ahora hay que decirle al cliente que todo el sector de pago a proveedores estuvo un mes entero ingresando datos en un sistema que simplemente los descartaba silenciosamente, que no sabemos por qué, y que tampoco sabemos cómo solucionarlo rápidamente.

- Voy a pedir la documentación de respaldo… les digo que la necesitamos para verificar… lo que sea. Decíle a los programadores que la vayan ingresando al sistema manualmente. Mientras corregí el módulo.

El líder técnico tenía emociones encontradas. Por un lado se sentía íntimamente reivindicado por los acontecimientos. Su visión del mundo se había tambaleado, pero finalmente prevalecido. Lo tranquilizaba el confirmar que aquello que para él era importante lo era también realmente.

Pero al mismo tiempo había confirmado un fracaso, uno importante e inesperado, no sólo personal sino colectivo (todos los éxitos y los fracasos son colectivos, sólo que los primeros suelen ser apropiados por alguien y la responsabilidad de los segundos suele quedar diluida). No sólo Frankenstein se había equivocado con la nueva incorporación y la asignación de responsabilidades. Los gerentes la habían aceptado, los programadores fueron indiferentes, el analista sometido a la voluntad de un programador menos que mediocre y él mismo no había revisado la marcha del módulo hasta demasiado tarde… y encima se había dejado convencer, a pesar de toda su experiencia, de que aquello había funcionado.

“Es hora de aceptarlo y dejar que las cosas caigan por su propio peso”, pensó.

- Er… no –el líder técnico se sentía incómodo. De alguna manera Frankenstein siempre lograba obligarlo a apretar el freno antes que frenar él mismo cuando hubiese correspondido-.

- ¿Cómo?

- Mirá, tenés un equipo de programadores, no los voy a poner a cargar datos… aunque probablemente el nuevo no tenga problema en hacerlo, creo que es el hombre para la tarea. De todas maneras el módulo es, aparte de inútil como su creador, ininteligible e inmodificable.

- Pero tenemos que hacer algo…

- Odio tener que decirlo de esta manera, pero… “Tenemos” me suena a manada, eso ya no es mi problema.

- ¿Qué me estás diciendo?

- Mi trabajo es arreglar este desastre. Arreglarlo en serio, no seguir dando manotazos de ahogado en medio de un pantano, y eso lo que voy a hacer. Desgraciadamente los tiempos y los costos no serán del agrado de nadie, no esperes milagros. Esta es la realidad, y hacer que gerentes, clientes y usuarios la entiendan y acepten es tu trabajo, no el mío.

Frankenstein calló.

El líder se retiró e inmediatamente reunió al equipo de programadores.

- Volvemos a 0. Necesitamos recodificar el módulo de proveedores, lo más rápido posible. Así que todos vamos a trabajar en ello. Lean las especificaciones, mañana a primera hora vemos cómo distribuirnos las tareas.

- ¿Él va a participar? –La pregunta se refería a la criatura, que continuaba aislada en su rincón. El líder la miró. De algún modo percibió que estaba prestando atención, que lo sucedido no le era indiferente. Dudó por unos instantes.

- No –“Y realmente lo siento”, pensó.

…continuará. Actualización: capítulo XVII.

Frankenstein, el líder de proyecto (XV).

ATENCIÓN: ¡No sigas si no has leído la catorceava parte! Y si no has leído nada empieza por el principio.

---

[Resumen: El sistema –incluyendo el módulo de pago a proveedores- se instala y el proyecto es un éxito. Frankenstein alaba la participación de su criatura y critica en duros términos la del resto del equipo en un informe que es presentado a la gerencia. En un clima de calma, el líder de técnico busca un nuevo trabajo mientras que la criatura… no hace nada.]

La semana –la cuarta desde la puesta en producción del sistema- transcurría, como las anteriores, con calma. Calma de la que disfrutaban analistas, programadores, líderes, gerentes y clientes, abocándose a tareas rutinarias, a la búsqueda de nuevos horizontes o a la nada misma, dependiendo el caso.

El trabajo recaía sobre el sector de soporte al cliente. Enfrentados a un nuevo sistema de gestión los usuarios inundaban las líneas con un sinfín de consultas y problemas menores. Pero si bien el trabajo había sido duro en las primeras semanas la gravedad de los incidentes estuvo siempre dentro de los parámetros normales y había entrado rápidamente en una suave pendiente negativa.

El jefe de SAC (Servicio de Atención al Cliente) miraba, un poco aburrido, las estadísticas de las consultas.

- Mirá qué loco… “Incidentes nivel 2 (defectos)… discriminados por módulo… Pago a proveedores… 0”. Ni un error. O no lo están usando o estamos a la vista de un milagro.

- Lo están usando –respondió uno de los operadores telefónicos-. Hay una señora que me estuvo volviendo loco ayer y hoy. Es la encargada de los informes del área y están cerrando el mes. Muy amable y simpática… tenía anotados todos los pasos para sacar los informes en una libretita… “Escribir fecha de inicio, arriba a la izquierda”, “Botón Aceptar”… y claro, ja ja, con el sistema nuevo la libretita voló a la mi…

Sonó el teléfono. El operador señaló el tubo con una sonrisa, dando a entender que se trataba, otra vez, de su nueva mejor amiga. Después de unos minutos –el jefe de SAC jugaba un solitario- cortó.

- Uf… logró sacar el informe. Ahora dice que algunos números no le cierran. Me lo estuvo explicando todo (te lo anoté en el reporte del incidente) y creo que tiene razón. Te lo paso.

- Ya decía yo… no podía ser –respondió el jefe. Leyó el incidente y revisó la documentación del informe.

- Ja, mirá, me juego la vida que es esto. Acá en el documento de análisis dice que hay dos clases de proveedores con los que se pactan diferentes modalidades de pago…  bla, bla, bla… cuestión que lo que dice la señora es que son tres, y me juego a que el informe no está mostrando los registros del tipo que falta. A ver…

Un par de horas después (permisos, explicaciones, autorizaciones) el jefe de SAC se conectaba a la base de datos del cliente.

- Ups… –dijo después de un rato, y salió precipitadamente de la oficina.

Fue directamente a hablar con el analista que estuvo a cargo de las pruebas del módulo, con quien tenía –como casi todos- una muy buena relación. Le explicó detalladamente el problema y lo que había encontrado en la base de datos.

- Ajá. Sí, definitivamente tenés razón –respondió éste luego de ver los datos en la base por sí mismo. Mientras se preparaba para salir-. Mirá, tengo que salir temprano hoy. Pasá el incidente al área de desarrollo, por mí está confirmado -juntó con parsimonia todo lo que había sobre su escritorio, guardándolo prolijamente en un maletín rígido. Saludó a todos y salió. Al día siguiente la empresa recibió un telegrama de renuncia de su parte y Frankenstein una afectuosa carta de agradecimiento por “estos años compartidos”. Nunca más se supo de él.

Entre idas y vueltas se habían hecho las siete de la tarde. Frankenstein recibiría el incidente al día siguiente por la mañana.

El jefe de SAC volvió a su oficina y juntó sus cosas, dispuesto a irse.

- ¿Qué hacemos con la señora de pago a proveedores? Está desesperada, dice que necesita el informe para mañana.

- Decíle que se vaya tranquila. Que pasamos el informe al área de desarrollo y que no hay nada que ella –“o nosotros”, pensó- pueda hacer. Esto va para largo. Me voy. Mañana va a ser un día de aquellos…

…continuará. Actualización: capítulo XVI.

Frankenstein, el líder de proyecto (XIV).

ATENCIÓN: ¡No sigas si no has leído la treceava parte! Y si no has leído nada empieza por el principio.

---

[Resumen: Luego de ver el código del módulo -vasto e ilegible- el líder técnico habla con Frankenstein anunciándole el fracaso en el desarrollo, situación que éste, enfurecido, no acepta. Mientras tanto la criatura termina las correcciones de acuerdo a las instrucciones de Frankenstein y el módulo supera las pruebas. El sistema está oficialmente terminado.]

Frankenstein pasó una semana entre instalaciones, presentaciones, capacitación, ajustes de último momento y reportes finales. El sistema estaba, por fin, instalado y funcionando a plena capacidad.

La tormenta había pasado. El líder de proyecto redondeó su balance y lo presentó a la gerencia.

“El proyecto ha resultado un éxito rotundo. […]

[…] El nuevo integrante del equipo ejecutó impecablemente sus tareas, ajeno a distracciones e inmune a los problemas que afectan a los demás programadores: cansancio, falta de motivación, falta de compromiso.

Si hubo un punto oscuro en esta experiencia, fue que el resto del equipo no estuvo a la altura.

Por un lado, los analistas han demostrado su incapacidad para producir especificaciones completas y correctas en un principio, y para enmendarlas con la debida celeridad después. La velocidad de este programador, su capacidad para trabajar sin descanso a lo largo de varias jornadas, ha compensado estas faltas.

Por el otro, los programadores –y en especial el líder técnico- han confirmado que sólo estarán disponibles cuando los tiempos sean laxos y la tarea de su agrado.

En mi experiencia como líder de proyecto, falto de alternativas, he aprendido a someterme –lo más veladamente posible- a sus caprichos. Veo en la actitud de éstos, taciturna y esquiva hacia mí, y en la tenacidad con la que dejan sentado en todo momento que ninguno de ellos tuvo participación en el módulo encargado al nuevo integrante del equipo, la respuesta típica de quienes ven amenazada la posición dominante que han ostentado desde siempre en esta empresa. […]

[…] Creo que es hora de iniciar un proceso de recambio. Estoy abocado a la elaboración de una propuesta para incorporar más personal con las mismas características sobresalientes de este elemento, con el que conformar un nuevo equipo que […]”

Durante ese tiempo y en las semanas que siguieron, los programadores corrigieron y ajustaron los últimos detalles.

El líder técnico trataba de asumir el golpe. Su autoridad había sido socavada por la imposición de un nuevo miembro al equipo y por la asignación a éste -con buenos resultados- de responsabilidades que le eran propias. Había irrumpido con fallidas visiones apocalípticas que, en definitiva, fueron interpretadas como un berrinche ante la pérdida de poder...

“…y lo que es peor –pensaba-, todo funciona. Todo está bien. Tal vez sea yo… nosotros… tal vez todo esto de la legibilidad, de la resistencia del código a los cambios sea, finalmente, una cuestión menor a la que los resultados son indiferentes…

¿No he pecado de falta de pragmatismo? ¿No son los resultados los que importan? ¿Estoy buscando elegancia, claridad o belleza en una simple herramienta? ¿Cuál es la diferencia entre este módulo y el resto del sistema? ¿Que su código es feo, que es inmodificable? Este tipo ha demostrado que feo no importa y que inmodificable no es, que él puede programar así… habrán, seguramente, más como él… ¿entonces?”

Cansado, desmotivado, aburrido, perdía sus horas leyendo, buscando respuestas en una bibliografía que por primera vez resultaba contraria a su experiencia… buscando también un nuevo trabajo.

“Si todo esto es así, sólo me queda huir lejos de esta gente, lejos de estos proyectos… buscar el lugar en donde el esfuerzo por crear algo bello aparte de funcional tenga sentido… no de cara a los resultados, a los clientes, a los gerentes, sino para mí y para las personas que me rodeen…”

Recorrió la oficina con la mirada, casi a modo de despedida. En el rincón opuesto el programador, inmóvil, la vista al frente, los brazos colgando inertes a los costados del cuerpo, esperaba una nueva asignación. Habían pasado ya tres semanas desde la puesta en producción del sistema. Aún sin nada que hacer la criatura llegaba y se retiraba puntualmente todos los días, que pasaba inmóvil, la vista al frente, los brazos colgando inertes a los costados del cuerpo, esperando una nueva asignación.

…continuará. Actualización: capítulo XV.

Frankenstein, el líder de proyecto (XIII).

ATENCIÓN: ¡No sigas si no has leído la doceava parte! Y si no has leído nada empieza por el principio.

---

[Resumen: Finalmente el líder y los programadores acceden al código de la criatura y a través de él intuyen su naturaleza. Esta visión los horroriza primero e inspira tristeza y lástima después. Pese a su apariencia humana, la criatura no es otra cosa que “un paso más, mecánico, transparente e inútil entre el analista y el software”.]

El líder técnico intentaba imaginar el origen de aquel vacío pero no podía. Luego de algunos minutos vagando entre terrores imposibles entendió que tenía que seguir. Reunió sus escasas fuerzas en un solo impulso con el que logró alcanzar la oficina de Frankenstein, desplomándose en la silla frente a éste.

Frankenstein había escuchado aquel grito y observado la escena desde su cubículo de paneles de vidrio. No entendió qué era aquello que horrorizaba tanto a los programadores pero sí que había un problema, uno grave y, por sobre todas las cosas –esto era lo que más le molestaba-, otro inesperado.

Se acomodó en su sillón, cargado de ansiedad. Si bien -a través de los años- había aprendido a tratar a las personas y sus problemas, hacerlo implicaba para él un trabajo consciente, constante y muy cansador. En momentos de tensión –los clientes presionaban, los directivos presionaban, todos presionaban- esta sobrecarga amenazaba con romper los límites de su autocontrol. Era cuando adoptaba esa actitud resolutiva y enérgica -casi agresiva- tan valorada por sus superiores y el delicado equilibrio entre los medios y los fines se rompía, inclinando la balanza siempre hacia estos últimos.

- ¿Qué pasa? –preguntó al líder técnico que, desparramado en la silla, había agotado sus fuerzas para llegar hasta allí y no lograba iniciar la conversación.

- Ya está, no hay nada que hacer. El módulo de pago a proveedores no sirve… no existe, en realidad. No hay nada que hacer.

- ¿De qué estás hablando? ¿Qué pasa?

El líder describió lo que había visto y lo que ello implicaba.

- ¿Qué tonterías son éstas? –exclamó Frankenstein. Por primera vez en muchos años estaba desbordado-. Escucháme, no me interesan estas boludeces ahora. El módulo está ahí, lo puedo ver, lo puedo usar. Tiene errores y hay que corregirlos, punto. Somos profesionales, tenemos un resultado comprometido y tenemos que cumplir con ese compromiso. Eso es lo único que te pido.

- Lo que me pedís es imposible, ya te expliqué.

- ¿Qué estás diciendo? ¿Cómo imposible? Andá y terminá con esto, por favor. No me interesa cómo, en una semana a más tardar quiero el módulo terminado –Frankenstein estaba fuera de sí. Normalmente el líder técnico hubiese reaccionado, tal vez con violencia. Pero en ese momento estaba demasiado cansado para eso.

- Víctor, no va a estar. Simplemente no va a estar. Ni en una semana, ni en dos ni en tres.

- ¿Entonces cuándo?

- No sé –el líder respondía maquinalmente, sin pensar en las consecuencias de lo que decía-. Ni la documentación del módulo ni su análisis ni su codificación pasaron nunca por mí. Todo fue asignado al nuevo y él no sirve. Estamos en cero.

- No me podés responder eso… es tu responsabilidad…

Por primera vez el líder levantó la vista. Miró fijamente a Frankenstein, que estaba rojo de ira. Una profunda convicción acerca de la imposibilidad de hacer nada a tiempo lo tranquilizaba.

- No creo que sea mi responsabilidad -interrumpió. -Mi primer error fue ceder cuando asignaste esa responsabilidad a un sólo programador, y el segundo quedarme tranquilo confiando en que sabías lo que hacías. Tal vez podría haber evitado todo esto, pero eso no me hace responsable. No es tan importante, de todas maneras. Ya está, el resultado es el mismo.

Frankenstein apenas podía contenerse. Se levantó, recorrió toda la oficina hasta llegar al puesto de su criatura.

- ¿Terminaste las correcciones?

- Sí.

Se dirigió hacia el equipo de analistas y testers.

- Quiero ese módulo probado para hoy a última hora. La que sea.

Y volvió a su oficina. El líder técnico todavía estaba allí.

- No voy a tolerar esto. Esto no va a quedar así. Tengo que ocuparme de esto yo mismo, pero después vamos a hablar. Andá.

El líder trasladó su cuerpo desde la oficina de Frankenstein hasta su escritorio, donde permaneció todo el día leyendo distraídamente. Cuando el reloj marcó la hora de salida tomó sus cosas y se retiró. Frankenstein lo siguió con la mirada.

- ¿Te vas?

- Sí. No tengo nada que hacer.

Un par de horas más tarde un analista tocó en la oficina de Frankenstein.

- ¿Terminaron las pruebas?

- Sí. Está OK, el sistema está cerrado.

… continuará. Actualización: capítulo XIV.

Frankenstein, el líder de proyecto (XII).

ATENCIÓN: ¡No sigas si no has leído la onceava parte! Y si no has leído nada empieza por el principio.

---

[Resumen: Frankenstein encomienda al líder técnico que complete la codificación del módulo, resolviendo las incongruencias y pequeños errores de las especificaciones. El líder accede por primera vez al código de la criatura, descubriendo con horror que es inmenso y completamente ilegible, y por tanto inmodificable. “¿Pero quién carajo es el monstruo que le enseñó a programar a este tipo?”, exclama. Él no lo sabe, pero ese monstruo no es otro que Frankenstein.]

El líder sostenía su cabeza con las manos, los codos apoyados en el borde del escritorio, la silla alejada de éste, la vista perdida entre los detalles de la alfombra.

Algo en el sonido del grito que acababa de liberar –un timbre de genuino horror, una nota que denotaba algo más que un grave problema, algo más que un incidente laboral… una nota que transmitía desesperación, furia, impotencia… locura- había actuado sobre el resto de los ocupantes de la oficina. Todos –todos menos la criatura, que continuaba tipiando impasible- habían interrumpido sus tareas y miraban fijamente en dirección al líder, inmóviles, esperando alguna reacción.

No la hubo. Un programador se acercó tímidamente y observó la pantalla. Detrás de él se aglutinaron los demás. Inclinándose por sobre el cuerpo del líder, el programador corrió un poco el teclado y giró el monitor.

Se enderezó, luego de unos instantes. Cruzó el brazo izquierdo sobre el pecho. En la mano izquierda apoyó el codo derecho, y la mejilla en su mano derecha. Así permaneció, con la boca abierta, mientras los demás repetían aquello que parecía un extraño ritual.

El silencio era absoluto. Algunos se miraban entre sí, otros al piso. Otros volvieron a sus lugares, reconcentrados, incrédulos, intentando asimilar lo que habían visto.

No era la visión de aquel código lo que los horrorizaba, sino el asomarse a la naturaleza de su autor e imaginar su origen.

Un programador ve en el código de otro su lógica, su forma de pensar, el camino que recorre su cerebro en busca de una solución, sus problemas, sus dudas, sus errores. ¿Qué revelaba de la criatura aquel ejemplo abominable?

Una ausencia, un vacío. No una lógica ajena, extravagante, complicada o simplemente equivocada (como estaban acostumbrados a ver de vez en cuando), sino una carencia, un vacío absoluto. Carencia de lógica, de comprensión, de razonamiento.

- Es… siniestro –dijo uno de ellos, rompiendo el silencio.

- ¿Qué es siniestro?

- Cuando lo cotidiano se vuelve extraño.

- Es… como… es como… un compilador de documentación funcional.

Alguno esbozó una sonrisa triste. Era solamente eso, al fin y al cabo. Un autómata de carne y hueso, una máquina de traducción simple, lisa y llana del lenguaje al código, un paso más, mecánico, transparente e inútil entre el analista y el software.

Pero parecía humano. Era esa similitud lo que lo volvía siniestro y -en principio- atemorizante.

El líder sollozaba. Y tal vez algún programador contuvo una lágrima. No por el fracaso del módulo o del proyecto, sino a causa de la profunda tristeza que inspiraba su autor, tan humano en apariencia.

Luego del rechazo, del temor y del horror ante la visión del vacío, éste sólo inspiraba una tristeza absoluta.

Un programador –el mismo que había roto el silencio- se acercó a la criatura y apoyó una mano en su hombro, pero ésta continuaba trabajando, ajena a todo y todos a su alrededor.

- ¿Qué está haciendo? –preguntó alguien desde el otro extremo de la oficina.

- Nada, sólo sigue escribiendo.

…continuará. Actualización: capítulo XIII.

Frankenstein, el líder de proyecto (XI).

ATENCIÓN: ¡No sigas si no has leído la décima parte! Y si no has leído nada empieza por el principio.

---

[Resumen: El módulo de pago a proveedores se atrasa rebotando entre pruebas y correcciones. Los clientes presionan y Frankenstein se ve obligado a tomar cartas en el asunto. Instruye a su criatura que el módulo debe superar las pruebas “a toda costa”. Luego indica al líder de proyecto que complete la codificación superando los errores en la especificación de acuerdo a su criterio, tarea que no puede encargar a su programador por carecer éste, precisamente, de criterio.]

El líder de proyecto llegó temprano. Ordenó sus cosas, resolvió un par de cuestiones pendientes con los demás programadores, se preparó un café y charló un poco con todo el mundo.

Sentía la presión de su nueva asignación –terminar el módulo de pago a proveedores- pero algo lo alejaba de ese código. Extendía el rechazo que le provocaba el programador a su obra. Finalmente tomó impulso, se sentó y abrió el proyecto.

Tardó un poco más de lo esperable en presentarse en pantalla. Finalmente aparecieron ante sus ojos los archivos del proyecto: eran doce. Uno por cada pantalla. Y nada más.

“Qué extraño –pensó-. Ahí están los formularios… ¿y el resto del código, los espacios de nombres, las clases, los módulos con funciones compartidas, las referencias?”.

Abrió el primer formulario. Se dirigió al código que lo controlaba. El entorno de programación dudó por un par de segundos (“¿Por qué está tan lento esto?”) y finalmente reveló su contenido.

El líder quedó inmovilizado, incapaz de reaccionar, de despegar los ojos de la pantalla. El botón de desplazamiento de la barra lateral de la ventana había alcanzado el mínimo. El formulario tenía… 86,042 líneas de código.

Abrió los demás… 93.402… 107.312… 85.324… en total… 1.032.510 líneas de código.

Quien lo hubiese visto en ese momento habría notado en su palidez, en sus manos inmóviles sobre el teclado, en el meñique derecho moviéndose apenas -“Page Down”… “Page Down”…-, el terror de un hombre que observa impotente el infierno que se abre bajo sus pies. “Qué… ¿qué es esto…?”.

Miró fijamente al programador, seguía tecleando impasible en la esquina opuesta de la oficina. Volvió a fijar la vista en la pantalla. Trató de reponerse… se dirigió al código que controlaba el botón “Aceptar” de uno de los formularios. Todo funcionaba en cámara lenta. Obviamente el entorno de desarrollo no estaba pensado para esto, toda la computadora parecía fuertemente sedada. Empezó a recorrer el procedimiento.

Todo estaba allí. Todo. El procedimiento tenía… 92,907 líneas. Comenzaba en la validación de cada uno de los datos de cada uno de los controles, seguían todas las operaciones y cálculos necesarios, las validaciones contra la base de datos, los mensajes, el reporte…

Todo estaba allí. No habían llamadas a otras funciones ni a librerías externas compartidas con los demás formularios. No había capa de datos, de negocio, de presentación. Todo estaba allí… todo y nada al mismo tiempo. Los nombres de los controles… “c1”, “c2”, “c3”… los nombres de las variables “i1”, “i2”, “i3”, “b1”, “b2”, “b3”… “i352”.

Los demás formularios estaban igual. Aquello era… ininteligible, intocable, inmodificable, basura.

Sintió que algo se quebraba dentro suyo. Una presión angustiosa comenzó a subir desde su estómago y se acumuló en su garganta. Finalmente, rojo de ira, levantó la vista al cielorraso y gritó con todas sus fuerzas:

- ¿Pero quién carajo es el monstruo que le enseñó a programar a este tipo?

Como todo en la criatura, sus habilidades de codificación provenían de Frankenstein. Nadie se lo había dicho nunca –tampoco hubo nunca necesidad de hacerlo-, pero todos sabían que programando era tan desastroso como eficaz. Hacía tiempo ya que cualquier aporte suyo había sido descartado y recodificado. Su código era ilegible.

Por algo había llegado rápidamente a líder de proyecto.

…continuará. Actualización: capítulo XII

Frankenstein, el líder de proyecto (X).

ATENCIÓN: ¡No sigas si no has leído la novena parte! Y si no has leído nada empieza por el principio.

---

[Resumen: Las correcciones al módulo de pago a proveedores se atrasan debido al excesivo celo de “Jaime” (tal el apodo dado a la criatura de Frankenstein por el analista a cargo) por la burocracia y al detallismo con el que se apega a las especificaciones. El analista a cargo de las pruebas, preocupado por lo absurdo de la situación, intenta una charla con Frankenstein en la que éste le transfiere la responsabilidad de los retrasos y se muestra inflexible. Trabaja al límite de sus fuerzas para seguir el ritmo del programador, que trabaja día y noche y parece incansable.]

Finalmente llegó el momento en el que todos los módulos estuvieron listos salvo el de pago a proveedores, que seguía rebotando continuamente entre correcciones y pruebas.

Los clientes presionaban. Frankenstein llamó al analista.

-Hago lo que puedo, tal vez deberías hablar con el coso ése –ya no ocultaba su desprecio por el programador, al que consideraba “un autista subnormal con una gran capacidad para romper teclados”.

Frankenstein decidió hablar directamente con el programador. Insertó una reunión en su lista de tareas.

-Tenemos que instalar la semana que viene, y el módulo de pago a proveedores está retrasado. Sé que no es tu culpa pero tenemos que hacer algo.

-… –Frankenstein se dio cuenta de que estaba hablando solo. A la criatura no le afectaría ese tipo de presión… ni ningún otro tipo de presión.

-¿Qué podemos hacer para terminar a tiempo?

-No sé –la respuesta fue, como siempre, tajante.

-Voy a asignarte una tarea. Quiero que el módulo funcione para la semana que viene, ¿ok?

-El módulo ya funciona –dijo secamente la criatura.

-Mmm… dejáme ponerlo en otras palabras: no quiero ver más errores… cada pantalla debe arrojar el resultado previsto para el conjunto de pruebas indicado… éstas son tus únicas prioridades ahora. ¿Podés hacer eso?

-Sí.

-¿Para cuándo podés tenerlo listo?

-Mañana a la mañana.

-Perfecto.

Frankenstein observó con sincero cariño el paso decidido del programador, la firmeza de su mirada, su concentración absoluta. “Es demasiado bueno para este equipo –pensó-. No saben comunicarse con él, ése es el problema. Con especificar las prioridades claramente es suficiente.”

Frankenstein llamó al líder técnico, responsable directo del equipo de programadores.

-Quiero que ayudes a… al chico nuevo con el módulo. Las especificaciones no son buenas y eso está generando retrasos. Quiero que tomes los incidentes pendientes y los revises personalmente. Corregí lo que indiquen y también lo que surja implícitamente de ello: errores en las especificaciones, incongruencias, inconsistencias funcionales, lo que sea. Tenés carta blanca para resolver cualquier tema de acuerdo a tu criterio.

“Te lo dije –pensó el líder, mordiéndose la lengua para no decirlo en voz alta-. Asignarle toda la responsabilidad de un módulo completo a un recién llegado… espero que sea tan bueno como sus recomendaciones.”

El nuevo le daba escalofríos. Luego de un par de vanos intentos de socializar había optado por alejarse de él, dedicándole de vez en cuando una mirada cargada de desconfianza… ¿por qué escribía tanto? Pero nunca se decidió a revisar su trabajo.

“Esto se me fue de las manos, es mi culpa. No debería estar preguntándome estas cosas a esta altura… tendría que haber revisado el código… espero que esté bien… debe estar bien… por algo Frankenstein le tiene tanta confianza.”

Había pasado una hora del horario oficial de salida. En la oficina sólo quedaban el analista a cargo de las pruebas del módulo y el programador en cuestión. Se acercó al primero, tal vez sólo por alejarse del segundo.

-Hola. ¿Trabajando hasta tarde? Quería preguntarte por el módulo de pago a…

-No quiero hablar de eso.

-Frankenstein me pidió que me haga cargo de los incidentes. ¿Por qué no nos juntamos mañana y me hacés un resumen informal, para ver por dónde empezamos?

El analista –que había respondido de espaldas, sin siquiera desviar los ojos de la pantalla o dejar de tipiar- permaneció inmóvil un par de segundos… y se dio vuelta lentamente.

El líder retrocedió un par de pasos, sobresaltado. El analista estaba demacrado, excesivamente flaco, pálido, gris. Los ojos, inyectados de sangre, estaban rodeados por enormes ojeras de color violeta profundo. Estaba desarreglado, despeinado, sucio. Le temblaban las manos y los labios.

-¿Vas a hacerte cargo?

Se abrazó, llorando, a la cintura del líder, que permanecía de pie, sin saber cómo reaccionar.

-Creo que mejor te tomás unos días… de todas maneras hay suficiente como para que empiece por mi cuenta… sí, creo que te hace falta. Nos vemos el lunes ¿ok? No te preocupes, yo me hago cargo.

-Gracias… gracias… –continuó repitiendo el analista mientras tomaba sus cosas y salía. El líder tomó las suyas, dispuesto a irse también.

-¿Te falta mucho? –le dijo de pasada al programador, que continuaba en su puesto.

-Sí.

-Ya no queda nadie. Apagá cuando te vayas.

…continuará. Actualización: capítulo XI

Frankenstein, el líder de proyecto (IX).

ATENCIÓN: ¡No sigas si no has leído la octava parte! Y si no has leído nada empieza por el principio.

---

[Resumen: El módulo de pago a proveedores es terminado justo a tiempo por la recién nacida criatura de Frankenstein y pasa a pruebas. El analista a cargo tiene un extraño intercambio de palabras con el no menos extraño programador a raíz de un pequeño error en la especificación que finalmente es aclarado, pero…]

El analista se sentía mal. El cansancio mental había dado lugar al físico. Las pruebas del módulo de pago a proveedores lo estaban matando.

Los problemas habían comenzado la semana anterior, con aquel primer incidente del campo “Nombre” especificado como fecha… “Tendría que haber dejado las cosas en claro en ese momento, ahora es tarde”, pensó.

El programador había exigido –de una forma no muy sutil- que se corrigieran las especificaciones y se le asignaran las tareas correspondientes y él había accedido. Fue un grave error.

Un día después de aquello se instalaba la versión revisada del módulo. Y el formulario “Alta de responsables de aprobación de pagos” había vuelto a explotar, no sin antes revelar un sinfín de errores menores en la pantalla (una falta de ortografía, un par de tipeo, algún que otro mensaje confuso, botones no alineados). Esta vez, el problema final era que al intentar vincular un usuario que ya estaba vinculado al sistema éste explotaba por un –qué más- error de clave primaria en la base de datos.

La segunda conversación con el programador había transitado más o menos por los mismos carriles del día anterior. “Jaime” -el analista no conocía el nombre del programador y a estas alturas no deseaba saber nada más de él, así que había elegido uno a voluntad. El nombre, que surgió casi de inmediato, hacía referencia a aquel autómata del “Superagente 86”- volvió a dejar en claro con su particular estilo que no haría nada por fuera de las especificaciones o que no le fuera asignado a través del sistema de tareas.

Y él había accedido. Fue un grave error. Una semana después, con más de 200 incidentes ingresados uno por uno al sistema de asignaciones, con la quinta revisión del módulo instalada, tenía que admitir que era poco y nada lo que había avanzado realmente. Fue a hablar con Frankenstein.

-Te quería hablar de Ja… del chico éste, del nuevo.

-Increíble, ¿no?

-Si, realmente. Mirá, ya corrigió más de 200 incidentes y…

-¡En una semana! Es fantástico, este chico.

-Pero…

-¿Pero?

-Esto no funciona. Yo sé que esto te va a sorprender, me siento estúpido por no haberlo sabido parar a tiempo…

-¿Qué? ¿Hay algún problema?

-Es raro, estrictamente hablando, no, no hay. En los papeles está todo bien, quiero decir. Pero el chico se limitó a implementar lo que decían las especificaciones a rajatabla, como si no las hubiese leído realmente. El problema es que cada error, cada incongruencia -por más grosera que fuese- terminó en el sistema.

-Bueno, por fin alguien que respeta las especificaciones. Es cuestión de corregirlas.

-Si, ahora es cuestión de corregirlas y corregir el código, otra no queda. Pero el chico tendría que haberlas detectado y avisado, ¿entendés? Eso es lo que me preocupa. Hay errores que son sutiles en un documento de varias páginas, pero que al programar se vuelven demasiado groseros, demasiado obvios. No es común que pasen de largo. Si no fuera por esas formas tan extrañas que tiene… pensaría que está actuando con malicia. Pero en realidad creo que simplemente no piensa. Es eso, el chico simplemente no piensa.

-¡No es ese su trabajo! Para eso tenemos analistas, ¿no? Habrá que ajustar el trabajo de análisis y la revisión de las especificaciones –a Frankenstein le brillaron los ojos… ¿por qué limitarse a crear sólo programadores?

-Víctor… por más que ajustes las especificaciones éstas nunca serán perfectas… si el programador no le pone aunque sea un poco de ganas…

-Eso ya lo hemos discutido y estamos en desacuerdo. De todas maneras no tiene sentido que nos internemos en esas cuestiones metafísicas ahora, veremos luego. Por lo pronto pasále las correcciones y listo.

-Ése es el problema. Son demasiadas. En su mayoría pequeñeces, un sinfín de pequeñeces que hay que detallar individualmente porque si no simplemente no las corrige. No doy abasto…

Pero Frankenstein estaba cegado.

-Mirá. Las especificaciones estuvieron a cargo del equipo de analistas. Y por lo que me decís durante la codificación se las respetó a rajatabla. Creo que es responsabilidad del equipo de analistas asegurarse de que esa falta de calidad no retrase el proyecto. ¿No te parece?

El analista se sentía mal. Estaba cansado, realmente cansado. Eran las nueve de la noche, ya no podía fijar la vista en el monitor. Decidió irse a casa. Al pasar frente al cubículo de “Jaime” soportó maquinalmente el ritual de despedida al programador:

-¿Te falta mucho?

-Sí.

-Ya no queda nadie. Apagá cuando te vayas –pero sabía que “Jaime” se quedaría toda la noche.

…continuará. Actualización: capítulo X.

Frankenstein, el líder de proyecto (VIII).

ATENCIÓN: ¡No sigas si no has leído la séptima parte! Y si no has leído nada empieza por el principio.

---

[Resumen: Frankenstein asigna a su criatura un módulo completo del sistema superando la resistencia de sus superiores y compañeros de equipo, quienes temen delegar tal responsabilidad “al nuevo” para que trabaje en solitario y sin supervisión. La criatura de extraño comportamiento trabaja constante e incansablemente hasta que termina.]

El módulo se integró al sistema y pasó al área de pruebas al otro día a las 10 de la mañana tal cual lo previsto en la planificación del proyecto.

Frankenstein estaba –por las razones que ustedes y yo conocemos pero que sólo serían comprendidas más adelante- visiblemente emocionado. Si bien el proyecto en general no mostraba un atraso preocupante, el módulo de pago a proveedores fue el único en pasar a pruebas a tiempo.

Imaginaba un ejército de programadores hechos a medida que revolucionarían el desarrollo de sistemas… los proyectos perfectos y a término, no más atrasos, no más imprevistos… y su nombre en bronce.

El analista a cargo de las pruebas del módulo –aquel buen compañero que había invitado a Frankenstein a ver una película- era un hombre de mediana edad pero con bastante experiencia. Sabía lidiar con los egos de los programadores, por lo que reportaba los errores de manera tal que no pareciese nunca culpa de ellos. Así, había conseguido su amistad y esa cuota de esfuerzo extra para corregir y volver a corregir hasta que todo estuviese perfecto. Era metódico, puntilloso y preciso.

Se sintió extrañado ante la reacción del “chico nuevo” ante el primer reporte.

Había comenzado por lo básico. Un formulario trivial, el de “Alta de responsables de aprobación de pagos”. Este formulario simplemente vinculaba ciertos usuarios del sistema con esa funcionalidad, apenas una asignación de permisos…

La pantalla explotaba mostrando el error en tamaño catástrofe. Luego de indagar un poco, llamó al responsable.

-Mirá este error –le dijo-, creo que se debe a que estás tomando el campo “Nombre” como de tipo fecha, ¿lo ves? ¿te parece que sea eso?

-Sí, efectivamente es eso.

-Pero el campo es de tipo alfanumérico… es el nombre del usuario, ¿no?

-Sí.

-¿Podrías corregirlo? Mientras yo voy avanzando con…

-¿Qué cosa? –interrumpió el programador.

-El error.

-¿Qué error?

-El campo “Nombre” que estás tomando como fecha y es alfanumérico, lo que provoca este error.

-No es un error. Así está especificado.

El analista miró fijamente al programador quien lo miró fijamente a su vez. Permanecieron así por unos instantes. No había malicia en la mirada “del nuevo”. Más bien recordaba –pensó el analista- la de un caballo o una vaca pastando… una mirada tranquila, transparente y… lejana.

De acuerdo con esta interpretación, sin de enojarse por lo que era a todas luces una soberana estupidez, consultó la documentación del módulo hallando –por supuesto- el pequeño desliz en la especificación.

-Efectivamente… así está especificado –dijo con una sonrisa cargada con una ironía que la criatura era incapaz de decodificar-… Mirá, para la próxima vez… es más fácil si en vez de codificar el error nos avisás y corregimos la documentación… así nos evitamos estos pasos intermedios, ¿ok?

-Eso no está en mi lista de tareas. Tal vez si hablas con Frankenstein él pueda indicarme que lo haga.

-Claro, claro… eso haré… mientras, ¿podrías corregirlo?

-¿Qué cosa?

El analista, a pesar de toda su buena voluntad, comenzaba a perder la paciencia. Sólo logró contenerse al invocar el peso de todos sus años de experiencia.

-Er… claro. Voy a pasarte la nueva documentación y a agregar un incidente en tu lista de tareas para que corri… para que implementes esta modificación.

La criatura no respondió (ya que nadie le había preguntado nada). Simplemente volvió a su lugar y se sentó, la vista fija sobre el monitor, los brazos inertes a los costados del cuerpo.

Fue la primera brisa que, con el clima aún en calma, precedió al huracán.

…continuará. Actualización: capítulo IX.

Frankenstein, el líder de proyecto (VII).

ATENCIÓN: ¡No sigas si no has leído la sexta parte! Y si no has leído nada empieza por el principio.

---

[Resumen: Después del fracaso de su sistema de control y de la retirada de uno de sus programadores Frankenstein se aboca sin éxito a la búsqueda de un reemplazante que cumpla con sus estándares, llegando a la conclusión de que no existe tal persona. Se dispone a crearlo y luego de dos años lo logra. Las primeras palabras de la criatura son “¿Donde está la lista de tareas?”]

El primer proyecto en el que participó la criatura fue el módulo de pago a proveedores de un ERP para una gran multinacional. Frankenstein, luego de elaborar la planificación del proyecto asignó “al nuevo” el módulo completo, ante la sorpresa de sus compañeros de equipo.

“¿Te parece asignar todo el módulo a una sola persona? Trabajará aislado… encima es nuevo, recién empieza. ¿Qué pasa si se va, si se enferma, o si se retrasa demasiado? ¿Quién tendrá suficiente conocimiento del módulo como para sacar las papas del fuego en ese caso? ¿Quién hará el mantenimiento después?”

Pero Frankenstein sabía que “el nuevo” no se iría ni atrasaría ni se desmoralizaría ante el mantenimiento, por lo que insistió hasta que la asignación de tareas fue aprobada.

La joven promesa llegaba un poco antes que Frankenstein (exactamente 4 minutos y 23 segundos antes). Tenía la costumbre de esperar frente a la puerta mirando fijamente su reloj de pulsera hasta las 8.16. Luego se ponía en marcha (como despertando de un sueño profundo), llegando a su escritorio para presionar la primera tecla exactamente a las 8.30, hora oficial de entrada.

Normalmente completaba sus tareas a tiempo, pero si no lo hacía se quedaba hasta terminar con las asignaciones del día. Una vez lo encontraron temprano a la mañana, en la misma posición y con la misma ropa, los ojos rojos clavados en la pantalla. Un problema en la red de la empresa lo había retrasado, por lo que se había quedado programando toda la noche, y siguió durante todo el día.

Hablaba poco, aunque murmuraba frases sueltas mientras tipiaba. A veces se inclinaba sobre el monitor, la nariz rozando la pantalla. O se quedaba inmóvil durante varios minutos, las manos en reposo sobre el teclado y la vista fija al frente, hasta que comenzaba de nuevo.

Tipiaba a una velocidad constante e increíble durante varias horas seguidas. El programador de al lado pidió -por favor- que le dieran un teclado más silencioso, ya que el parejo trepidar de las teclas de su vecino le crispaba los nervios.

Era amable pero no socializaba ni ayudaba. Respondía siempre en forma seca, categórica, tajante, a veces sin siquiera detenerse. Ante cualquier cosa que representara una distracción afirmaba inevitablemente “No tengo tiempo asignado a eso.” y a veces -las menos- “Tal vez si hablas con Frankenstein él pueda indicarme que lo haga.”

Finalmente todos se acostumbraron a su no-presencia. Rara vez le hablaban. Nadie le pedía u ofrecía nada. Cada tanto, cuando el ruido empezaba a molestar, reemplazaban su teclado por uno nuevo.

Hasta que un día el murmullo apagado de las teclas cesó de repente. Por primera vez el programador apartó las manos del teclado. Permaneció con los brazos colgando inmóviles a los costados, la espalda recta y la vista clavada en la pantalla-. Estuvo así durante varias horas hasta que alguien se acercó.

-¿Te pasa algo?

-No.

-¿Por qué no estás trabajando?

-Terminé.

…continuará. Actualización: capítulo VIII.

Micromanagement y desarrollo de software.

El término micromanagement refiere a un estilo de gestión que pretende controlar la ejecución de una tarea hasta el más mínimo grado de detalle.

Cerebrado describía una de sus formas en Requerimientos: cuando no son asteroides sino sólo polvo cósmico:

Un requerimiento normalmente diría:

El sistema debe detectar que el saldo de una cuenta ingresa en rojo y alertar al ejecutivo de cuentas asignado al cliente.

Pero hay veces en las que dice:

Implementar un trigger sobre la instrucción insert de la tabla cuentas_movimientos. En este trigger, cuando sld_cnt - deb_pnd + crd_pnd sea menor a 0 insertar un registro en la nueva tabla notificaciones con los siguientes valores: ....

En vez de indicar cuál es el resultado esperado de una tarea se especifica cada uno de sus pasos, quedando para el micromanagement zombie la mera ejecución de éstos.

Nos imaginamos entonces al manager obsesivo y malhumorado despotricando cada vez que alguien se aparta un milímetro del nítido camino que marcan sus instrucciones y al pobre esclavo asalariado sometido a través de toda clase de presiones a la ejecución de una lista interminable de mini-tareas de las que no puede deducir ningún objetivo a mediano plazo.

Pero lo primero que pensé es que estas relaciones no serían tan frecuentes si no hubiese también algo que ganar de cada lado. Traté de verlo en forma positiva:

• El jefe gana en eficiencia, control, seguridad. También retiene para sí el conocimiento, la visión global del proceso. De esta manera no depende realmente de nadie y nadie puede hacerle sombra.
• El zombie gana en tranquilidad, despreocupación, falta de responsabilidad. Su trabajo es usualmente fácil aunque tal vez –y sólo tal vez, esto hay que remarcarlo- aburrido. Probablemente su pasión transite por otros caminos.

Imagino que detrás de cada micromanager debe haber una personalidad insegura y por lo tanto desconfiada de aquellos que lo rodean y detrás de cada zombie un trabajador apático, desinteresado, ausente.

Eso puede funcionar muy bien para un picador de piedras o para un trabajador necesitado de la paga. Pero para el desarrollo de software en equipo no.

Por un lado porque las aplicaciones que requieren un equipo de desarrollo son demasiado complejas para una sola persona. Presentan desafíos que requieren experticia en varias áreas: codificación (y con distintos perfiles), administración de base de datos, análisis funcional…

Por otro lado porque en el desarrollo de software todos cometen errores todo el tiempo. Y la única forma de que eso no derive en un fracaso estrepitoso es el control mutuo bien entendido, que implica una actitud atenta y una visión crítica en cada uno de los actores.

Y porque en el desarrollo de software intervienen varios profesionales con visiones y métodos propios que no sólo hay que aprovechar sino respetar. ¿O alguien imagina al director de hospital indicando cómo debe operarse el corazón de cada paciente?

Esto puede sonar a evangelización ágil, así que aclaro: lo anterior es independiente de la metodología. Todas las metodologías proponen algún tipo de control y revisión, que puede ser burocrático y en determinados momentos o súper ágil y permanente, pero que existe. Pero finalmente algo escapará a todo control. Será el momento en el que el programador atento encontrará un problema y lo resolverá o discutirá con el resto del equipo. O el momento en el que un programador que sólo sigue instrucciones despreocupadamente… lo deje pasar.

A nivel personal la relación micromanager-zombie es una relación devastadora para ambos y para todos en el equipo. Un proyect lider que intente retener el control de todo se convertirá rápidamente en un cuello de botella y un torbellino de pequeñas decisiones –producto de su incapacidad para delegar ampliamente- lo perseguirá día y noche. Un programador -analista, administrador o tester- verá su desarrollo profesional estancado y pronto se dará cuenta de que la experiencia acumulada es inútil puesto que no ha aprendido a resolver problemas sino a implementar soluciones.

Y a nivel organizacional también. La organización se vuelve dependiente del manager que acapara el know-how del proceso y es incapaz de generar suficientes cuadros de reemplazo ya que el aprendizaje es imposible. Usualmente debajo de un micromanager de sistemas hay una alta tasa de rotación. Y ni hablar de la actualización tecnológica o metodológica. Es inviable pensar en la prosperidad de una nueva propuesta en un contexto así.

El micromanaging suele llevar al WTFismo: cuando sólo tienes un martillo (la cabeza del micromanager) todos los problemas se resuelven martillando. Si el micromanager es (o fue) experto en base de datos, todo será base de datos, si es (o fue) experto en C todo se hará en C, si aboga por determinada metodología (o participó en ella), se cumplirá a rajatabla… y así. Tanto peor en los casos en los que se impone una solución determinada independientemente de las personas que deben participar en el proceso.

¿Y entre programadores? Cuando respondemos dudas o discutimos soluciones ¿lo hacemos a vuelo de pájaro o tiramos una serie de pasos en estilo pseudocódigo? ¿Dejamos que los demás intenten por sí mismos antes de ayudar?

Los dejo con el test de Kathy Sierra:

1. Do you pride yourself on being "on top of" the projects or your direct reports? Do you have a solid grasp of the details of every project?
2. Do you believe that you could perform most of the tasks of your direct reports, and potentially do a better job?
3. Do you pride yourself on frequent communication with your employees? Does that communication include asking them for detailed status reports and updates?
4. Do you believe that being a manager means that you have more knowledge and skills than your employees, and thus are better equipped to make decisions?
5. Do you believe that you care about things (quality, deadlines, etc.) more than your employees?

A "yes" to any of these -- even a half-hearted "maybe" -- means you might be creating Micromanagement Zombies

…y si eso no te preocupa tarde o temprano estarás en un problema… solo.

Hablando de… ¿peces?

A primera vista parece que la referencia a Liderando en el Tanganica de Jano 2.0 no tiene nada que hacer en este blog. Sean pacientes y lean hasta el final…