Funciones de TI: Proyectos | Alessandro Galletto

Funciones de TI: Proyectos

La gran mayoría de todos los proyectos empresariales requiere que TI aporte un sistema que soporte los procesos de negocio. Tanto en el caso de adaptar sistemas ya existentes como en el caso de requerir nuevas capacidades informáticas, es necesario definir qué se necesita.

Tradicionalmente, se abordaba el proceso con una toma de requerimientos para el que el equipo informático entendiese todo lo que se necesita por parte de negocio. Incluso, se hacía firmar el diseño funcional para que todo el mundo estuviese seguro de lo que se pedía. Después de unos meses, aparecía una nueva aplicación. En ese punto se producía un efecto de caja de las sorpresas. Tanto podía suceder que las áreas de negocio afectadas les encajase la solución como todo lo contrario. En el peor de los casos, se empezaban a generar excels con listas de incidencias, mejoras, cambios… listados que podían tener 300 puntos. ¿De quién era la culpa? ¿De negocio que se dejó la mitad de los puntos en el tintero? ¿Del equipo de técnicos que no preguntó? ¿De falta de sentido común de todos ellos?

Tuve un cliente -CIO de una multinacional con muchos proyectos- que tenía una frase muy buena y que solía repetir con cierta frecuencia: 

"El sentido común es el menos común de todos"

En mi opinión, es una frase muy acertada. Confiar en que todo el conocimiento de procesos de negocio se pueda transferir a un equipo de técnicos durante unas cuantas reuniones -interminables- desafía la cita que os acabo de indicar.

Sin embargo, durante un par de décadas, era la forma de trabajar: la metodología en cascada.

Los sistemas han ido madurando y la forma de abordar proyectos también. De ahí, aparecieron las metodologías Agile. De forma muy simplificada, lo que se consigue es construir la solución informática de forma iterativa codo con codo con negocio. Los desarrollos y adaptaciones se hacen de forma mucho más fragmentada -cada dos semanas- entregándolas continuamente a las áreas de negocio afectadas reduciendo mucho el riesgo de malos entendidos y permitiendo unir los caminos de negocio y de informática.

Esto permite que el equipo de informática aprenda mucho más de negocio y pueda aprender ese "sentido común" y por otro lado, las áreas de negocio van conociendo la solución que se les aportará así como las ventajas y limitaciones. 

Mi experiencia es muy buena aunque lo más complicado sea la gestión del cambio. En compañías que está muy establecida la metodología tradicional, es muy complicado que negocio abandone la forma de trabajo anterior: escribir la lista a los reyes y volver a centrarme en el día a día es muy atractivo. Sólo se valora cuando después de unos meses, se entrega la aplicación a los usuarios y empiezan a aflorar todas las necesidades que faltan y los malos entendidos. 

Es necesario un esfuerzo elevado hacer entender a las áreas de negocio afectadas que cuando se entregue una aplicación, en realidad, es cuando se va a empezar a trabajar y que va a ser muy complicado enderezar un desarrollo sobre el que se ha construido sobre una base de confusiones. Es complicado convencer las diferentes áreas implicadas pero los beneficios de conseguir las dedicaciones suficientes de todos los implicados para trabajar más coordinados supera con creces el posponer esa dedicación.



alessandro@galletto.cat - www.galletto.cat © Alessandro Galletto 2011-2016