Lucas Ontivero

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.