Descubriendo el impacto de negocio detrás de los proyectos tecnológicos
Resulta que muchas veces, a los informáticos, nos piden desarrollar soluciones que una vez implementadas, añaden escaso o nulo valor al negocio. ¿Pero por qué? ¿A qué se debe?
Para ello, primero debemos preguntarnos:
¿De dónde nacen los proyectos tecnológicos?
Aquí les comparto un buen ejemplo: Video disfraz de castor.
¿Cuántas veces les ha pasado algo similar a lo del video? Trabajar mucho en proyectos que están mal orientados es por desgracia más bien la norma que la excepción.
¿A qué se debe esto?
Los proyectos tecnológicos son una forma de resolver problemas tanto en los productos o servicios que reciben los clientes, o en los procesos que las organizaciones siguen para entregar los anteriores. Y esta resolución de problemas está compuesta de 3 lenguajes
- El lenguaje de negocio: que habla en términos de generación de valor al negocio y tiene que ver con escoger el problema que vamos a solucionar.
- El lenguaje funcional: Es el que se usa en términos de eficacia, para encontrar y barajar las distintas soluciones para solucionar el problema.
- El lenguaje técnico: Es el que se usa en la implementación, para construir las soluciones correctamente en términos de eficiencia y robustez.
Si recuerdan el famoso juego del teléfono descompuesto (los que no, aquí pueden ver un video que lo documenta en su versión de imitación de gestos), en cada traspaso puede perderse una cantidad importante de información.
Cuando hay 3 lenguajes, hablados por distintas personas, significa que al menos hay 2 traducciones, lo que implica que puede suceder como en el típico juego del teléfono, que la información se pierde y distorsiona en el camino, lo que aumenta mientras más grande es la empresa y la complejidad.
El lenguaje funcional, debiera ser donde se unen los lenguajes de negocio y tecnología. Es el lenguaje común que debiéramos usar para ver qué hacemos.
¿Acaso no debemos hacerle caso al “cliente”?
Hay una inercia histórica: las áreas de tecnología se han asumido como tomadores de pedido, por ende reciben peticiones de soluciones para problemas que NO entienden porque nunca se les habla del problema de negocio a resolver. Entonces es muy probable que probable que no podamos aportar al negocio.
Al igual que en el video, en la vida real, sucede que cuando analizamos de dónde vienen los requerimientos, en general es de un ente todopoderoso, llamado “Jefe”, o en métodos ágiles, “Product Owner”, al que se le pregunta: ¿qué es lo que quieres que haga?
Estamos acostumbrados a que nos digan qué tenemos qué hacer.
Por eso es clave darnos cuenta en qué lenguaje estamos hablando. Como hay tres lenguajes, si nos están hablando de tecnología, claramente no nos están hablando del problema de negocio.
Un ejemplo: Nos piden crear “una app para la empresa”.
- ¿Pero para qué?
- ¿Para tener un sistema más resiliente?
- ¿Atender a más clientes?
Y al hacer estas preguntas, es que hablamos de distintos temas del negocio, uno habla de nivel de servicio y el otro de ganar mercado.
Es decir, la clave es que tenemos que entender el contexto, y ese contexto está compuesto de tres lenguajes. Es necesario que el área de tecnología entienda lo básico del lenguaje de negocios, y viceversa, el negocio entienda lo básico de tecnología. En definitiva, debemos comunicarnos usando un mismo Contexto de Entendimiento Compartido.
¿Cómo desarrollar este contexto común?
Solemos comunicarnos a partir de la solución evidente, y con esto podemos estar dirigiéndonos al fracaso, tal como lo podemos ver en este video.
En el caso del video la orden fue “subir gente a los botes”, o en casos más cercanos será “implementa un sistema de machine learning”. Cuando el jefe o product owner, nos pide un requerimiento, por ejemplo, una app, damos por hecho que esa es la solución.
Muchas veces la solución está influenciada por los recursos de los que se tiene conciencia en ese momento, en el caso del video, son los botes. Así podemos estar perdiendo la oportunidad de encontrar soluciones más oportunas y adecuadas. ¿Cómo podemos entonces salir de esa trampa?
Aquí les presentamos un esquema de cómo hacerlo, siguiendo el ejemplo del video reciente:
El barco se está hundiendo entonces hay que subir gente a los botes.
¿Para qué? Para salvar a los pasajeros.
¿Por qué nos están pidiendo esta solución? Para eso necesitamos entender qué propiedades tiene ella y que podríamos extrapolar. En este caso ¿Qué hace de esta solución que salvemos a los pasajeros? Los botes, me permiten sacar a la gente del barco seca, porque flotan.
Entonces si subimos gente a cosas que flotan, podemos encontrar más cosas que flotan, no solo los botes.
En un caso real en tecnología:
Una empresa de seguros nos pidió un “join” entre base de datos, lo que generaba un montón de problemas de seguridad para darles acceso a la base central a usuarios de negocio. Sin embargo, terminamos descubriendo que necesitaban un cruce de datos. Y solicitaban el “join” porque querían obtener los datos de forma autónoma, es decir, que no querían tener que recurrir a los de tecnología para tener acceso. Entonces lo más simple fue hacer una sábana de datos, un scd con el cruce hecho y ellos simplemente cargarlo, algo muy distinto al requerimiento inicial.
En definitiva, si queremos que nuestras soluciones aporten valor, entonces hay que hablar desde el problema, el desafío, no desde la solución. Y eso está en tus manos. ¿A qué esperas?
