Alineación entre negocio y desarrollos IT

Hay entornos, donde la rapidez en dar una respuesta es crucial. Esto es un hecho. Desde la gestión lo único que se ve es el tiempo que se tarda en dar la solución a un problema determinado. Muchas veces, este tiempo engloba una serie de tareas que en muchas ocasiones son transparentes para la capa de gestión del proyecto. Ya en varias ocasiones me he encontrado con comentarios como:

-“¡No se puede tardar tanto tiempo en resolver una incidencia en producción!”

Este tipo de comentario, habitualmente se refieren o van dirigidos a los equipos de desarrollo pero no siempre es el desarrollo el que genera estos tiempos. Como medida de contingencia, se suele aplicar presión a los desarrolladores. En muchas ocasiones se les llega a presionar hasta extremos en los que no se les da tiempo ni para pensar en la mejor solución, hacer las pruebas necesarias, o para asegurar el comportamiento normal de la operativa para la que se desea realizar el cambio o la corrección, o asegurar que los desarrollos que se realizan funcionan de una manera correcta.

Con esta forma de trabajo lo único que se consigue, es que los desarrollos que se realizan, en la mayoría de las ocasiones, contengan errores. Y con esto, dilatar aún más los tiempos de corrección de las incidencias, o generar nuevas problemas. Todo ello se podría evitar conociendo el resto de tareas que intervienen, teniendo alineadas las necesidades de negocio y los procesos implementados para la gestión del desarrollo de Software y apostando por la calidad, aunque sea en perjuicio de la rapidez. A la larga, esto, repercutirá de forma positiva en la calidad y la velocidad de las implementaciones.

Me gustaría poner como ejemplo determinados entornos, que claman por rapidez en los desarrollos, y sin embargo, cuentan con unos procesos tan rígidos, que el simple retraso en una hora de la codificación o las pruebas del Software, pueden llegar a retrasar hasta una semana la puesta en producción de las soluciones.

Quiero romper una lanza a favor de los desarrolladores. Desde la dirección de muchas empresas, se les suele acusar tanto de los retrasos, como de los fallos. Es evidente, que al ser ellos quienes hacen el código, van a ser los que cometan los fallos, y añadiéndoles presión solo se empeora la situación. Respecto a los retrasos, recomiendo que se miren todas las tareas involucradas en las subidas a producción, porque pueden ser responsables, de dilatar los tiempos, si no están alineadas con las necesidades de negocio. Si quieres velocidad, crea entornos flexibles, de lo contrario estarás penalizando los tiempos.