Hace ya algún tiempo leí en el blog de Jesús Encinar, fundador de idealista.com, una frase que que me ha dado mucho que pensar. Forma parte del post 10 consejos sobre ventas para emprendedores y es la siguiente:

Por cada euro que dedicas a i+d calcula que necesitarás 10 euros más para crear el producto y 100 euros más para el esfuerzo de venta […] Muchos emprendedores se centran en crear un gran producto y olvidan que el éxito de una empresa es vender un gran producto.

Si aplicamos este consejo a una Arquitectura Tecnológica, y cómo ésta tiene que “venderse” a sus clientes, que no son otros que los equipos de desarrollo. Son éstos los que tienen que aplicarla para construir aplicaciones y en definitiva dotar a la compañía de las herramientas informáticas que necesita para respaldar su negocio.

Como técnicos que somos,  normalmente sólo nos preocupamos por investigar una tecnología y desarrollar un componente técnico que los desarrolladores puedan usar. Como mucho, nos molestamos en hacer un manual de usuario que cuente cómo se usa este componente y poco más. Sin embargo nos encontramos con un problema, que puede marcar el éxito o fracaso de una Arquitectura… la comunicación con nuestros “clientes”.

Deberíamos por lo tanto, ampliar el conocido “i+d” y añadirle una muy necesaria parte de divulgación, lo necesario para hacer llegar nuestra Arquitectura a aquellos que la van a usar.

Investigación + Desarrollo + Divulgación

A menudo, dedicamos nuestro esfuerzo y atención a la “i+d” y nos quedamos cortísimos en la última “d”, la de la divulgación.

Viendo los tiempos (o el dinero) que son necesarios para llevar a cabo este i+d+d de una solución tecnológica, encuentro que lo que menciona Jesús Encinar  puede ajustarse a nuestra realidad (tal vez cambiando sus proporciones).

Como arquitectos de T.I. debemos dedicar más tiempo en divulgar la arquitectura y la tecnología, que ponemos a disposición de la empresa, que al desarrollo propiamente dicho de este componente. ¿De que sirve tener la mejor arquitectura si no es conocida ni entendida? Una arquitectura no es buena por ser intrínsicamente buena, sino porque es sencilla de aprender, sencilla de usar y se ha divulgado convenientemente para que todos los componentes de un equipo de desarrollo (desde el Jefe de Proyecto hasta el programador) se empapen de ella y la usen con naturalidad.

¿Sería tan descabellado, por ejemplo, hacer lo siguiente tomando una semana como una unidad de tiempo hipotética?

  • dedicar el lunes a implementar el componente técnico y a pruebas unitarias
  • dedicar el martes y miércoles en realizar una aplicación de ejemplo con el fin de realizar unas pruebas integradas con el resto de la arquitectura
  • Dedicar el jueves y viernes en preparar la documentación para el usuario. Aquí incluyo el manual de referencia técnica pero también realizar una presentación (un powerpoint) con una guía rápida sobre la necesidad que este componente pretende cubrir, como se ha llegado al su diseño y dónde puede ayudar al equipo de desarrollo. En este último día, me reservaría una hora para una charla presencial, con el apoyo de esta presentación, para transmitir oralmente su contenido y más importante, recibir un feedback inmediato de parte de sus futuros usuarios.

Y es que a fin de cuentas, una vez lanzada una Arquitectura Técnológica, basada en un framework de empresa, la construcción de nuevos componentes será lo que menos tiempo ocupará al equipo de Arquitectura. Cambios que por otra parte deben ser pensados para tener el mínimo impacto en sus usuarios (debe ser 100% compatible hacia atrás) y deben encaminarse a simplificar la arquitectura, no a hacerla más compleja (por supuesto dentro de lo racionalmente posible).

carretera de dos sentidos

Termino con esta nueva “d”, la de la divulgación, recordando también que ésta debe ser una carretera de dos direcciones. No debe ser una vía única en la que fluya la información desde el equipo de Arquitectura al equipo de desarrollo. Ésta debe tener un canal de vuelta, en la que las aportaciones de los analistas funcionales, técnicos y programadores puedan ser tenidas en cuenta para mejorar el producto final (tenemos que aprovechar su talento para la mejora de la Arquitectura que a su vez redundará en sus aplicaciones). Con esto también evitaremos otro mal bastante común, que se hagan soluciones que al final nadie va a usar y al revés, que las que realmente se necesitan con prontitud se vean relegadas en el tiempo, hundidas en lo más profundo de la lista de tareas pendientes.

Comparte este artículo…

Anuncios