El síntoma más cotidiano en los equipos de desarrollo de software con problemas de desempeño es el caos. Este caos frecuentemente tiene una causa raíz en común, para ilustrarlo imaginemos la siguiente historia …
Todo inicia en la reunión de dos compañías, el cliente “Somos Grandes Inc” y un proveedor de TI “Monkeys Devs”. En la reunión un gerente de línea de negocio quiere resolver un problema por medio de una solución tecnológica pero no sabe realmente cómo hacerlo, así que el director comercial de Monkeys Devs toma nota de la información que puede para entonces crear una propuesta comercial.
El director comercial está consciente de que la única forma de crear una propuesta adecuada es primero haciendo un análisis detallado, o proponiendo un modelo iterativo que permita ir descubriendo la solución por fases. Pero sabe que su principal competidor está dispuesto a dar una propuesta comercial sin dicho análisis, aun cuando el riesgo de desviarse sea amplio. Así que entrega una propuesta basada en supuestos.
Durante las juntas de revisión de la propuesta inicia el estire y afloje debido a que la propuesta rebasa el presupuesto del cliente, y al final, después de mucha magia y decisiones que desafían las leyes del tiempo y la materia, se aprueba el proyecto. Así que se da inicio al proyecto, y el equipo de trabajo no tiene acceso al contrato acordado (no vaya a ser que los desarrolladores se enteren cuánto se cobra por ellos), y por lo tanto no se tiene todo el detalle del compromiso adquirido.
—–
Este sería un buen momento para hacer un alto en el camino y cuestionar todas las malas decisiones que se han ido tomando, tal como los cambios sin sentido en el plan de trabajo, o cotizar una tarifa fija sin tener un análisis, pero cortaríamos el suspenso de esta historia.
—–
Una vez iniciado el proyecto, se inicia el análisis real. Se crea una nueva lista de requerimientos distinta a la del contrato, pero no se cuestiona porque los analistas no tienen acceso a éste. Se llenan documentos y minutas sin ton ni son y empieza la vorágine de los compromisos adquiridos durante las juntas, en donde el miedo a decir “eso no estaba en el alcance” hace su aparición. Por lo tanto, al final del análisis se cuenta con un nuevo compromiso.
Lo triste es que no importa cuánto te hayas tardado en el análisis, una vez terminado empiezan los cambios. Y por supuesto nadie quiere documentarlos; como si negar su existencia nos fuera a permitir ignorarlos. Así que empiezan los malos entendidos y juntas interminables en las que se habla de los cambios y todos se quedan callados; nadie quiere exponerse y entonces en muchas ocasiones se asume que el cambio se realizará.
La historia podría continuar y continuar, y si has llegado hasta esta parte de la historia es probable que recuerdes la sensación que tuviste alguna vez que te pasó lo mismo en un proyecto. Pero, ¿sabes algo? No estás solo, está es la vida de miles de personas que se dedican al desarrollo de aplicaciones. Y si nunca te ha pasado es probable que todavía no te haya tocado estar en un proyecto lo suficientemente complejo.
Ahora, si analizamos esta historia veremos que la mayoría de estas pesadillas se resuelven atendiendo la enfermedad.
¿Cuál es esa enfermedad? El miedo. Miedo a perder el proyecto por hacer el análisis, miedo a compartir el contrato con los desarrolladores, miedo a ser honestos y entregar el plan de trabajo con la estimación de los desarrolladores, miedo a administrar los cambios, miedo a reconocer que las cosas se tienen que hacer diferentes.
Es por ello que veo con esperanza cuando las compañías implementan prácticas ágiles y son capaces de sobreponerse al miedo, reconociendo que: el cliente quiere obtener valor continuo aún cuando no sabe de manera detallada lo que quiere, que es imposible planear de forma detallada lo que hará un desarrollador en 6 meses, ni siquiera se tiene dominio de las tecnologías requeridas para crear la solución. Es por ello que la entrega continua de compromisos de 3 a 4 semanas me parece tan adecuada y facilita las conversaciones cuando los cambios se solicitan, porque simplemente cada ciclo empezamos de nuevo.
La forma más tangible de encontrar la solución al problema es enfrentándonos nosotros mismos a romper el miedo de perder nuestra área de confort. Y en el camino encontraremos nuevos miedos y retos a enfrentar.
Así que estimado lector, ¿cuál es su primer miedo a romper?
Fuente: Revista SG
