La ingeniería de software y la mala planificación, ¿condenados a entenderse?

“La fecha de entrega era para dentro de cuatro meses, pero lo necesitamos para dentro de un mes”. Frases malditas en muchos proyectos que nos ha tocado vivir (y nos seguirá tocando), pero huyendo de una organización cuestionable, ¿cómo nos afecta a nivel de desarrollo y de estado de cohesión/ánimo en los equipos?

Antes de afrontar un proyecto cerrado en coste, alcance y tiempo, debemos entender que el desarrollo del software es complejo e incierto y, además, cambiante, por lo que una gran planificación inicial en poco tiempo se habrá quedado desfasada. Dada esta situación, nuestra primera opción debería ser la de negociar una relación de confianza donde ese triángulo de hierro no esté presente.

Si no lo conseguimos, la gestión de proyectos cerrados puede acarrear una serie de problemas y riesgos que deben de tomarse en cuenta, unos ejemplos son los siguientes:

• Imposibilidad de entregar el proyecto tal y como lo había planteado el cliente.
• Problemas futuros debido a dichas prisas.
• Aumento de costes y gastos

Y un largo etcétera que no abordaremos en este post, ya que nos queremos centrar en otro aspecto y es cómo afecta verdaderamente a un equipo de Software y cómo podemos mitigarlo o vivir con ello.

Problemas

Primero, describiremos los principales problemas que puede causar en el equipo tanto funcional como en las relaciones interpersonales entre ellos:

1. Malas prácticas organizativas: al comenzar las prisas y los “necesito para ayer”, comenzarán una serie de malas prácticas como por ejemplo:

• Inexistencia de tickets en las herramientas de gestión para el trackeo de las tareas.
• Falta de una gestión de ramas de desarrollo bien organizadas, lo que conlleva acostumbrarse a una gran mala práctica (y cualquier QA me lo puede corroborar): utilizar Hotfix como excusa para cualquier arreglo.
• Desconexión y desconocimiento del equipo: al tratarse de tareas de “comida rápida” y de aquí para ayer, hace que muchas personas dentro del equipo no se den cuenta de dichas tareas y que no consigan tener el contexto en caso de algún problema/incidencia posterior relacionada con esta tarea.

2. “Clean” Code o Clean Code a posteriori: el ‘ya lo haremos mañana’ se acaba convirtiendo en un arma de doble filo, y en el desarrollo de Software no iba a ser menos. Al tener que hacer tareas e historias de forma apresurada, consiguen que los ingenieros de software y los desarrolladores no hagan tanto hincapié en el cuidado y las buenas prácticas de Clean Code, lo que conlleva en muchos casos a refactorizaciones a posteriori. Cabe diferenciar entre las refactorizaciones “cotidianas” y estas, siendo estas últimas evitables si se tuviese un poco más de tiempo disponible para ello.
3. Cuellos de botella en las comunicaciones: por desgracia siempre hay una o dos personas que acaban cargando con estos problemas de comunicación lo que acaba causando un cuello de botella en dichas personas, que aparte de su trabajo del día a día, acaban siendo intercomunicadores entre el equipo y el cliente (saco de quejas para uno, y saco de boxeo para otro).
4. Mal ambiente y falta de participación: el equipo se acaba convirtiendo en un lugar complicado, se acaban rompiendo las relaciones personales debido a estar constantemente “con la lengua fuera”.

Y se podrían sacar más puntos, pero sabiendo algunos de ellos, ¿cómo podemos mitigarlo desde el punto de vista del equipo para intentar convivir con ello?

Soluciones

Aunque no existe la planificación perfecta y entra en juego la propia naturaleza cambiante del software, algunas de las soluciones siguientes pueden ayudar a mitigar el impacto de las prisas por entregar rápido:

1. Evitar las suposiciones e involucrar a todo el equipo: los errores de comunicación suelen originarse por suposiciones infundadas. La mejor manera de reducir las suposiciones es seguir haciendo preguntas. Los usuarios y las principales partes interesadas deben ser capaces de dar su opinión y ayudar a orientar la visión y la ejecución del proyecto.
2. Gestionar las expectativas: existe una gran diferencia entre acatar y aceptar. En la primera no mostramos la contrariedad de nuestra opinión respecto a algo, en la segunda lo podemos hacer. Esto nos lleva a este punto, debemos comunicar y gestionar las expectativas y los resultados esperados de algo en el tiempo que nos piden, de esta forma podemos intentar “reeducar” a la hora de establecer tareas o requisitos de última hora.
3. Análisis exhaustivo de criterios de aceptación: ya lo decía mi abuela: “mejor prevenir que curar”, y es por eso que es necesario estar especialmente atento y tener un análisis exhaustivo de las tareas/historias de usuario que ya tenemos. Muchas veces las prisas de algunas tareas vienen por la mala definición de otras anteriores, de esta manera podemos evitarlo. A esto le podemos añadir el tener una documentación completa para saber qué es lo que se está haciendo.
4. Regla del Boyscout: se basa en la idea de mejorar el código existente durante el desarrollo. Esto beneficia al equipo y al proyecto al evitar que los errores persistan, facilitando así la vida y el trabajo de los compañeros. Esta regla nos ayudará como equipo y, sobre todo, como proyecto, que los errores de otros no sigan estando presentes para hacer más fácil la vida y el trabajo de nuestros compañeros.
5. Digerir antes de replicar: es común en muchos integrantes del equipo que están en esta situación estar con el ‘arma cargada’, es decir, ante cualquier infortunio o posible cambio, replicar sin sentido o simplemente no aceptar aquello que se está exponiendo. Es importante ser justos y ser imparciales en las diferentes decisiones.
6. Mr. Wonderful sí, pero no por bandera: nunca está mal tener el optimismo y los mensajes de ánimo internamente, pero no es correcto llegar a un punto de engaño personal. Aceptar la realidad, aunque conlleve situaciones incómodas y puede llevar a ciertos desencuentros, es mucho mejor que trabajar en un ambiente de apariencia y no de realidad.

Conclusión

Nos encontraremos a lo largo de nuestra vida profesional muchos proyectos con estas situaciones y, como todo en la vida, no deber ser o blanco o negro, sino vivir con los grises. Es importante seguir manteniendo un buen ambiente de equipo en aquellas situaciones más complicadas y tensionadas que puedan existir en nuestro día a día, pero sin dejar de ser justos.

Referencias

• 7 errores comunes en Proyectos de Desarrollo de Software.
• Las 10 malas prácticas más comunes en la gestión de proyectos.
• ¿Qué problemas de desarrollo de software podemos encontrar y cómo solucionarlos?