4.3 Esto no es agilidad, es fatalidad (II)

Lo quieren para ayer

En primer lugar, me gustaría decir que las estimaciones temporales son aproximaciones y no deberían ser consideradas como contratos inflexibles. En otras palabras, los plazos de tiempo no tendrían que ser inamovibles. En segundo lugar, también hay que tener en cuenta que a medida que se acerca la fecha de entrega aumenta la presión sobre el equipo y cuando esto ocurre es más fácil cometer errores, que pueden resultar fatales. Por lo tanto, es muy recomendable dejar un margen de tiempo prudencial a la hora de planificar las tareas.

Por supuesto, hay que tener en cuenta la opinión de los expertos a la hora de hacer las estimaciones de tiempo y recursos en función de la complejidad prevista para cada tarea, en vez de forzarlos a hacerlo más rápido y a toda costa usando cualquier excusa barata. Es más, en ocasiones, personas sin los conocimientos técnicos suficientes acerca del ámbito que gestionan toman decisiones comprometidas o sin mucho sentido, cuando se niegan a escuchar a los expertos que los asesoran, y esto puede acarrear graves consecuencias. Ten por seguro que la falta de buen criterio, tiempo y/o recursos hará aumentar el número de chapuzas y apaños provisionales por hora, pero lo peor de todo es que en muchísimas ocasiones acabarán siendo definitivos.

Paradójicamente, a veces nos vemos obligados a bajar el ritmo o incluso a parar los desarrollos porque los clientes o los responsables no nos proporcionan la información o el feedback necesarios para seguir desarrollando y tenemos que esperarnos. A veces incluso parece que te estén haciendo un favor a ti, cuando te dicen que van a buscar un hueco en su apretada agenda para poder atenderte y proporcionarte la información o el feedback que necesitas, cuando en realidad tú estás desarrollando algo que supuestamente era urgente para ellos. La moraleja aquí es que en muchas (demasiadas) ocasiones lo que quieren no es tan urgente ni tan importante como decían.

No entienden lo que querían

A veces se da la situación en la que una vez implementado lo que los clientes querían no entienden lo que ellos mismos habían pedido porque el resultado suele ser demasiado complejo y no es usable.

En estos casos normalmente hay que simplificar y/o dividir. Por ejemplo, puede ser muy fácil perderse en la navegación de una pantalla donde se muestren demasiados formularios juntos. Una posible solución podría ser separarlos en varias pantallas, en distintas pestañas dentro de la misma pantalla o incluso intentar simplificar los propios formularios.

No les gusta lo que querían

A veces el problema es puramente estético, aunque no por eso es menos importante. Muchas veces el diseño o los colores finales no quedan tan bien como se había pensado en un inicio. Los cambios estéticos son muy frecuentes y me he encontrado en situaciones en las que el desarrollo se ha demorado considerablemente debido a cambios constantes de diseño.

Los cambios de diseño, en situaciones donde todo tiene que ser estrictamente «pixel perfect» en las diferentes resoluciones y además tiene que haber compatibilidad con los distintos dispositivos y navegadores, pueden ser muy complicados de gestionar. En una ocasión, un diseñador me dijo que los componentes a implementar no eran elementos responsive, sino que eran «líquidos» porque, según él, se tenían que adaptar siempre a la perfección. Esto me recordó a Bruce Lee cuando decía: «Be water, my friend»… Aunque, como podrás imaginar, a la hora de la verdad no todo es tan fácil ni tan bonito, principalmente cuando se introducen nuevos cambios constantemente en el «diseño definitivo».

Este tipo de cambios gráficos normalmente implica muchas modificaciones en cascada para que los elementos se vuelvan a adaptar bien en los diferentes casos. Con lo cual, tener el diseño claro de entrada es un aspecto realmente importante.

Lo que querían no es usable

Una interfaz bonita y agradable a la vista puede no ser usable ni accesible. Si la aplicación debe cumplir cierto nivel de usabilidad y accesibilidad se tiene que tener en cuenta desde el principio, si no, esto puede suponer un incremento importante del coste del proyecto. No es una buena idea hacer las revisiones correspondientes una vez finalizado el trabajo porque nos podemos llevar sorpresas muy desagradables que impliquen rehacer buena parte de la interfaz de usuario.

Por este motivo, si nos piden el desarrollo de componentes complejos y vemos a priori que no van a ser usables, tenemos que comunicarlo cuanto antes mejor para tomar las medidas oportunas en cada caso. Hay que tener en mente que cuanto más sencillo, mejor.

No recuerdan lo que querían

En repetidas ocasiones me han pedido cosas que literalmente ya estaban hechas. Es decir, piden supuestas nuevas funcionalidades, pero realmente ya están implementadas y probablemente subidas a producción desde hace tiempo. Por desgracia, estos desarrollos habían caído en el olvido y nadie les había dado la menor importancia una vez realizados.

Por suerte, algunas veces había implementado yo mismo estas «funcionalidades olvidadas», días, semanas o incluso meses atrás, con lo cual, pude responder rápidamente que eso ya estaba hecho. No obstante, a veces quien lo ha desarrollado no eres tú y aquí la cosa se complica. Con un poco de suerte, te vas a dar cuenta antes de ponerte manos a la obra, pero en otras ocasiones no será así y te vas a dar cuenta al final, o incluso se te va a pasar por alto completamente y se va a terminar duplicando la funcionalidad.

Otras veces ocurre que los desarrollos ya terminados permanecen en el olvido durante meses, pendientes de validar o de subir a producción, hasta que alguien se ilumina y de repente todo son prisas y el trabajo debería estar hecho para ayer. ¿Te resulta familiar?

No quieren lo que querían

Los requerimientos, por suerte o por desgracia, cambian constantemente y tenemos que adaptarnos a ellos. Una de las peores situaciones a las que nos podemos enfrentar es que nuestros clientes ya no quieran lo que nos habían pedido. Dado el caso, siempre es mejor abortar el proyecto cuando está en fase de desarrollo que una vez ya esté finalizado.

Por desgracia, lo he vivido varias veces, tanto en proyectos en desarrollo como en proyectos finalizados y listos para desplegar en producción. Estas situaciones desmotivan por el tiempo y esfuerzo invertidos en algo que no se va a usar. En estos momentos te acuerdas de las horas invertidas en buscar soluciones a los problemas que iban surgiendo y piensas que no ha servido de nada, aunque hayas facturado el proyecto. El «consuelo» está en que la experiencia adquirida no se va a la basura y, probablemente, algunas de las herramientas que habías desarrollado para este proyecto abortado las podrás aprovechar en el futuro.

En algunas ocasiones, es posible que al cabo de un tiempo (pueden pasar años) vuelvan a cambiar de opinión y quieran reemprender el proyecto, cuando tú prácticamente ni te acuerdas de él.

Lo que querían no es lo que necesitan

A la hora de empezar a usar el producto desarrollado se dan cuenta de que lo que querían no es realmente lo que necesitaban. Esto es como querer un coche deportivo, cuando realmente necesitas un utilitario para desplazarte cómodamente por la ciudad.

En estos casos, debe quedar claro que el trabajo realizado corresponde a lo que el cliente quería para que no haya discusión posible y no se trate del caso en que no se ha sabido plasmar lo que quería. Si se está de acuerdo en este punto, entonces lo que hay que hacer es buscar la manera de conseguir que lo que se ha desarrollado sirva para lo que realmente necesita y no para lo que «quería». A veces es suficiente con introducir algunos cambios porque lo que se quiere normalmente tiene que ir alineado con lo que se necesita, pero está claro que no siempre es así.

Esto no funciona

Si llega un momento en el que aparecen errores por todos lados, esto puede ser debido a varios factores, como: mala toma de requerimientos, mal diseño, mala implementación, mal uso, infraestructura inadecuada, etc. En cada caso hay que ver dónde está el problema y a partir de ahí revisar lo que se ha hecho mal y tratar de arreglarlo. En el peor de los casos, puede suceder que a pesar de todo el tiempo, esfuerzo y dinero invertidos en un proyecto se llegue a un punto en el que se considere inviable, ya sea por el coste que supondría arreglarlo o porque el plazo de finalización sea inalcanzable.

Suele ser habitual que al poner en producción un nuevo sistema ocurran errores y haya problemas, pero una vez superada la etapa de puesta en marcha y posterior estabilización, el proyecto debería funcionar correctamente. Si los errores se suceden sin tregua y el sistema no funciona, se puede llegar a situaciones de incumplimiento de contrato y esto hay que evitarlo a toda costa porque no va a aportar nada positivo para ninguna de las partes.

También se puede dar el caso contrario en el que un proyecto funcione correctamente desde el punto de vista técnico, pero no funcione desde el punto de vista económico y tenga que ser abandonado por falta de rentabilidad o inversión, pero este ya es otro tema…