Management deficiente (I)

Introducción

La historia del software está plagada de ejemplos de proyectos que fracasaron estrepitosamente, estos por lo general han excedido el presupuesto estimado, el esfuerzo estimado y el  tiempo estimado en muchas veces y si bien parece que la industria viene haciendo avances importantes en estos problemas, aún hoy es común ver u oír de proyectos que fallan de manera espectacular.

Voy a introducir solo algunas de las razones de por qué esto sigue sucediendo, de cómo puede solucionarse y de cómo afecta a los equipos. Pero el foco voy a centrarme en la gente, en cómo los afecta, en sus reacciones y motivaciones (o desmotivaciones) y para ello voy a usar un ejemplo real de un proyecto en el que participé.

Costos

Todos los proyectos que fracasan tienen una característica en común: superan los costos. Sea porque se renegocian o porque pierden dinero o porque no ganan lo esperado, o porque se extienden en el tiempo (también representa un costo) o por el motivo que fuera, los costos están siempre relacionados al fracaso de un proyecto.

Uno de estos costos, y probablemente uno de los que más afectan a la moral de los equipos es el llamado costo de calidad probre, costo de mala calidad o costo de no calidad, esto es, cuanto cuesta (dinero) desarrollar software con defectos (bugs) y luego tener que arreglarlos. Mientras más alto es este costo, más probabilidades existen de que un proyecto fracase.

Una introducción a La Historia

La historia con la que quiero ejemplificar se basa en el desarrollo de una aplicación gubernamental en la que trabajé y a la cual me referiré con el nombre ficticio de “pyjs”. En este proyecto, el costo de calidad pobre era una aberración, cada caso de uso requería un esfuerzo de entre 2,5 y 4 días-hombre de desarrollo y se le hallaban un promedio de 12 bugs. Así, el equipo, formado por alrededor de 13 desarrolladores desarrollaba algo así como 40 casos de uso por sprint de 2 semanas.

Lo interesante de esto es que con esos 40 casos de uso, venían también unos 480 bugs! Digamos que si arreglar cada uno de eso  bugs costara tan solo una hora de desarrollo, esa bolsa de bugs costaría 480 horas-hombre, a digamos algo así como 10 u$/hs serían u$ 4.800 tirados por la ventana cada 2 semanas.

Un poco más sobre este costo

Una de las razones por la que deben atacarse rápidamente las causas de este costo es porque este crece de manera exponencial a medida que la detección de los defectos se aleja de la fase de desarrollo. Así, llevándolo a lo cotidiano, cuesta mucho menos (menos dinero) encontrar un defecto en una revisión de código antes de subirlo al repositorio que encontrarlo durante la etapa de pruebas ya que aquí se debió utilizar tiempo del equipo de pruebas, hay más reportos, más administración, etc. Ni que hablar si en lugar de encontrarlo el equipo, lo encuentra el cliente.

Volvamos a La Historia

En el pyjs la relación testers/desarrolladores era muy baja, no por algún número teórico sino por la simple razón que el equipo de pruebas no daba a basto y por ende se retrasaba cada vez más hasta llegar el punto de que probaban funcionalidad que se había terminado más de un mes atrás. Así las cosas, para cuando reportaban los defectos, el equipo ya estaba desarrollando otras funcionalidades (muchas que dependían del correcto funcionamiento de las anteriores) y una vez acumulados estos bugs se repartían muchas veces a “el equipo de los bugs”, esto es, a miembros del equipo que no habían estado involucrados en el desarrollo de esos casos de uso y que por lo tanto no los conocían, no sabían qué debía hacer esos casos de uso, cómo se relacionaban con otros casos de uso ni nada en lo absoluto. Esto convertía a estos desarrolladores en los “mártires de turno” (digo “de turno” porque alguna vez los cambiaban).

Una cosa curiosa es que la líder de proyecto comentaba que se requería el mismo esfuerzo para desarrollar los casos de uso que para arreglarlos y por esta razón en algunas ocasiones se alternó un sprint para desarrollo y el siguiente para corrección de bugs. Esto quiere decir que a menos que al cliente se le presupuestara 3 o más veces el costo de desarrollo, el proyecto era inviable.

Otra cosa a tener en cuanta es que si los casos de uso no tuvieran defectos, el proyecto podría haberse terminado en quizás en la mitad del tiempo.

Reacciones del management

Ante semejante situación, las reacciones del management fueron las siguientes:

  1. Remover a aquellos desarrolladores que habían participado en el desarrollo de las funcionalidades con mayor número de defectos.
  2. Incrementar el número de desarrolladores e incrementar el “seniority” del equipo incorporando personas con mayor experiencia (incrementando los costos). Esto llevó a la necesidad de “distribuir” al equipo ya que estos nuevos desarrolladores estaban en otras ciudades.
  3. Asignar más presupuesto al proyecto para posibilitar que desarrolladores “externos” al equipo participaran en la creación de casos de uso de manera independiente (desde sus casas y en horarios extralabolares)
  4. Pedir a los desarrolladores que por favor entendieran la situación del proyecto y que no generaran más defectos.
  5. Pedírselo de nuevo
  6. … y de nuevo…. y otra vez más.

Reunión de retrospectiva tras reunión de retrospectiva los líderes de proyecto (digo los porque en realidad eran 2!) repetían que el mismo sermón a los desarrolladores: “Entindan! Les pedimos que por favor entiendan que tienen que generar menos bugs a la vez que necesitamos que incrementen la velocidad!”, “A esta situación llegamos por la falta de compromiso de los desarrolladores”, “Necesitaban más memoria y se las dimos, pidieron cursos y se los estamos gestionando, ahora recapaciten!”

Cómo afectó al equipo

Si esto no bastaba para bajarle la moral a alguien, si alguno con una psiquis de acero todavía permanecía en pie, los reportes de estado del proyecto realizados por teléfono a los superiores argumentando que el proyecto estaba como estaba por una “falta de compromiso”, “por los descuidos”, “por no leer la documentación correctamente” más otras actitudes desmotivantes como los mails pidiendo al equipo que “piensen en las cosas que están haciendo mal”, acabaron con las fuerzas del equipo.

El mismo equipo que reunión de retrospectiva tras reunión de retrospectiva decía que los tiempos estaban muy comprimidos, que los bugs se detectaban muy tarde y que se sentían presionados a entregar aun a sabiendas de que estaban entregando con baja calidad.

Por otro lado, la remoción de prácticamente la mitad del equipo de un plumazo, personas que quizás se desempeñaban algo por debajo del resto pero que hacían valiosos aportes al proyecto (recuerdo que muchos de ellos trabajaban muchas horas de más e incluso cuando se les pidió trabajar un fin de semana lo hicieron de buena gana), no ayudó a mejorar en lo absoluto sino todo lo contrario. De hecho esta fue la primera acción que se tomó.

La moral de un equipo es algo que debe cuidarse celosamente y protegerla porque marca una diferencia enorme en los resultados. Por eso, luego de que la moral bajara al nivel más bajo que recuerdo, el equipo comenzó a realmente desempeñarse por debajo de sus posibilidades, a importarle menos sus resultados, a ser lo que todos los días se les decía que eran: descuidados y poco comprometidos.

Costos de calidad

Existen otros costos de calidad divididos según las tareas específicas que requieren como costo de inspección, costos de prevención y así, pero básicamente lo que se busca es invertir (dinero) en actividades claves que reduzcan el número y severidad de los defectos, idealmente identificándolos en las etapas más tempranas posibles donde el costo de un defecto es menor.

Costos de calidad en esta Historia

En el pyjs la inversión en actividades de “prevención” era prácticamente $ 0,00. La justificación era que no había tiempo, que las entregas al cliente requerían que se utilizara todo el tiempo disponible en el desarrollo de las funcionalidades pactadas. Por esa razón, cuando se pidió al TL que no se siguieran desarrollando las pruebas unitaria y luego cuando propuso volver a realizar las revisiones de código obtuvo un “no hay tiempo para esas cosas”.

Por fortuna, digo que la inversión fue de “prácticamente” $ 0,00 porque se autorizó que el arquitecto desarrollase un generador de código y un set de componentes reutilizables en 4 días, lo que ayudó al proyecto a salir solo un poco de apuros. Esto se autorizó gracias al poder seductor del pensamiento mágico que todo “generador de código” despierta en algunas mentes.

Mi reacción

Como esto estaba muy claro para mi, retrospectiva tras retrospectiva planteaba la necesidad de incorporar aquellas prácticas que todo el mundo sabe que dan resultado: revisiones de código, pruebas unitarias (aunque sea en aquellas funcionalidades más delicadas), reuniones técnicas para aunar criterios o despejar dudas (el equipo se dividía entre 4 ciudades distintas).

Por otro lado, con el fin de obtener feedback más rápido por parte de testing, propuse incrementar el equipo de testing y agilizar las pruebas, filtrar aquellos defectos que no eran realmente defectos o que no se querían o podían arreglar en ese momento (los reportes de defectos en crudo a los desarrolladores es una perdida de tiempo descomunal), no enviar funcionalidades sin probar al cliente (una práctica habitual que encarecía el proyecto y le causaba muchísimo daño).

Por último, no desmotivar al equipo!

Fin de la Historia

Mis recomendaciones cayeron en oídos sordos todas la veces, ni siquiera formaban parte de las minutas de las reuniones de retrospectiva ya que la razón de los problemas no eran ningunas de esas estupideces que yo decía sino que era un tema de falta de compromiso, descuidos y falta de profesionalidad.

A todo esto, la pregunta obvia era: ¿si existe falta de compromiso en algunos miembros entonces por qué no se los remueve?. Y la respuesta fue que no se iba a modificar más el equipo porque la falta de compromiso era general! Yo creo que la razón era otra: si luego de cambiar a la mitad del equipo se cambia a la otra mitad y todo sigue igual…. ¿que se le reporta a los jefes? ¿que los 13 nuevos desarrolladores son tan indolentes como los anteriores?

Conclusión

Yo tenía una hipótesis de que los proyectos sí fallaban la mayoría de las veces por cuestiones técnicas, esto era porque he visto algunos pocos proyectos fallar por problemas técnicos pero ahora está claro que los grandes y monumentales fracasos son en verdad por un management deficiente.

Sin categoría

2 thoughts on “Management deficiente (I)

  1. Lucas, yo tengo la teoría inversa > los proyectos fallan por problemas de gestión. Ahora bien, si alguno falla técnicamente, debe ser 1 de cada 50 porque los otros son por pura negligencia en la gestión

    Nice post / Bad historia 🙁

    Salu2

  2. Primero, veo que en Geeks ya no se puede comentar si no sos miembro registrado y logueado… mmmmm… punto en contra para los que no queremos perder ese tiempo.

    Sobre lo comentado, decir que la aceptación del error, de que todo el conocimiento acumulado y por el cual te has guiado durante gran parte de tu vida está errado, es una de las cosas más frustrantes y desestructurantes a lo que nos podemos enfrentar.

    Imaginemos a alguien que le ha rezado toda su vida al chupacabras, y de golpe existen pruebas irrefutables que el animalejo no existe, que nunca lo hizo y nunca lo hará. No importa el manojo de pruebas que le estampes en la cara, difícilmente aceptará que ha estado haciendo peticiones a un ser que nunca estuvo. Por lo tanto, intentará por todos los medios buscar un escape de la angustia que esto le pueda llegar a traer. Algunas como la racionalización o intelectualización, o simplemente una acción esquizoide para mantener su postura.

    Ahora transportemos esto a la gestión de proyectos. Por definición, y siguiendo un poco un post que habías colocado hace tiempo, el concepto de hacer carrera es el de «ascender», o sea, seguimos creyendo que las organizaciones productoras de software están apuntaladas en el esquema piramidal clásico, por lo que, si soy jefe, soy más, porque indiscutiblemente estoy cada vez más cerca del extremo estrecho de la pirámide. Basado en esto, los que están por debajo están allí por varios motivos. Puede ser porque no tienen mi capacidad, porque tienen que ser dirigidos, porque sin mi dirección no sabrían que hacer y un largo etc. (Aún recuerdo a un manager tirar una frase del estilo: – Si no les digo cual será la dirección que ellos tienen que tener en su carrera, no sabrían cómo hacer su planificación para todo el año)

    Esto nos lleva a otro punto clásico dentro de la teoría administrativa. Si a este pensamiento le sumamos el hecho de que el único objetivo es dirigir para maximizar la productividad, no estamos más que ante las puertas de una teoría administrativa del 30, como si se tratase de un grupo de personas X, olvidándose de que deberíamos estar por la Z.

    Con todo esto, que puede ser consiente o no. Recordemos que muchos (Si no todos) de nuestros actos están regidos por ese conocimiento y experiencias acumulados, si nos rodeamos y aceptamos la idea de la estructura piramidal, teoría X, y demás, nuestras reacciones serán siempre en esa dirección y por lo tanto muy difíciles de revertir. Ahora, si se encuentran que estas teorías no están dando el resultado que ellos esperarían, los mecanismos para preservar la estructura de pensamiento (Lo del chupacabras) harán que la respuesta se escape por los caminos que comentas. No hay compromiso de ELLOS; ELLOS no hacen lo suficiente; Por más que les digo que hagan las cosas bien NO ME HACEN CASO.

    Por más que intentes, que comuniques, será muy complicado el lograr que estas personas acepten un pensamiento dicotómico y que de alguna forma los desautorice, lo único que conseguirás será resistencia, ya que en definitiva vos estás en la base de la pirámide.

    Por supuesto, el cambio no es imposible, pero no es fácil. Posiblemente con algo de condicionamiento operante se podría probar de modificar la conducta. Esto es, por cada acierto en la dirección que buscamos y sabemos que solucionaría el problema, otorgarle a ese manager un reforzador de conducta. Esto podría modificar la estructura que la persona tiene, y de a poco se podría alejar de la estructura aprendida previamente para ver resultado en la nueva.

    Con esto quiero decir que no basta con mostrar los «números» con los resultados correctos de la aplicación de la técnica X o Y o Z o W (Llámese revisión de código, UT, etc.), ya que para él o ella, tu pensamiento está en disonancia con el de él y con lo que él (O ella) considera como válido, por lo que seguramente intentará una vía de escape, como que los números podrían haber sido manipulados, o que no aplicarían para un proyecto específico que es el que él está tratando de actuar.

    Este tipo de cambios los he podido ver en casos donde he dado cursos de Scrum, en especial para aquellos que vienen con una fuerte raíz de metodologías rígidas, los planteos son siempre los mismos, pero acudiendo un poco al pensamiento mágico natural de las personas y con demostraciones que son más propias de un mago experto, terminan saliendo pensando en que «sí, se puede».

    Perdón por el largo del mensaje… pero bueno, es un tema que he estado estudiando recientemente.

Responder a matiasiacono Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *