Transformación Digital: Pon en forma a Tecnología

Este es el 3er artículo de nuestra serie sobre Transformación Digital. Ya hablamos de que toda empresa es una empresa de software y cómo la transformación digital es mucho más profunda que pasarnos de átomos a bits. En esta entrega hablaremos  de cómo diagnosticar y poner en forma los músculos y capacidades que te permitirán jugar de igual a igual en este mundo digital.

Sin Equipos Tecnológicos de Primera, la Transformación Digital NO tiene Sentido

No se trata de que Transformación Digital gire 100% en torno a las áreas de tecnología (y/o tus partners tecnológicos). Pero son habilitantes claves para que la transformación realmente ocurra. Ir a correr la maratón de Nueva York sin una preparación previa es ingenuo. O, más gráfico aún:

Da lo mismo la visión o las ganas cuando derechamente estás fuera de forma.

Cuando estás fuera de forma y no te preparas: da lo mismo la visión, las ganas, ni siquiera ir en la dirección correcta. No va a salir bien.

Una objeción que escuchamos seguido: “Mi core es otra cosa, y tecnología es una función en la que puedo encontrar partners”. Sin duda es posible, pero lo mismo que  trataremos en este artículo sobre un equipo interno aplica para tus partners. En lugar de formar y hacer crecer un equipo de primera propio, debes saber seleccionar y saber evaluar a tus partners tecnológicos. No es para menos: Cuando toda empresa es una empresa de software, estás poniendo tu negocio en sus manos.

Y no basta con usar software que consideres “world-class”. Tus propios productos, canales y servicios digitales definirán en gran parte tu futuro.

Lo que sigue ahora no es otra descripción escrita en techie de las tendencias tecnológicas actuales. Hablaremos de DevOps, Agilidad, Lean UX, pero en contexto de su utilidad para el negocio y para mostrarte cómo puedes diagnosticar rápidamente qué “músculos” asociados a qué tendencias son los que debes ejercitar más y por qué. Y así saber cuando ya estás al primer nivel y puedes correr la maratón de Nueva York.

Síntomas y Técnicas para Mejorar los típicos problemas de Tecnología

  • Síntomas: Se gasta mucho tiempo una y otra vez en “configuración de ambientes”. Tus desarrolladores o los de los proveedores se demoran días en poder tener las herramientas suficientes funcionando en sus computadores. Armar un nuevo segundo entorno de QA toma días o semanas. Replicar producción en QA es un lío y son tus clientes quienes prueban por primera vez los productos digitales que construyes.

El problema entonces es que tu infraestructura no está automatizada ni es predecible y debes dar una mirada a DevOps: la fusión entre áreas operacionales con desarrollo. Una empresa tecnológica de primera no deja a sus equipos detenidos por días debido a este tipo de problemas.

  • Síntomas: Tus equipos tratan de predecir el futuro, introduciendo complejidad y “parametrización” por si luego “cambian los requerimentos”. Y como consecuencia terminan demorándose muchísimo en poner frente al cliente y sacar al mercado incluso cosas simples (Que por cierto luego cambian de maneras que no fueron las que se predijeron).

Si la respuesta es afirmativa, el problema es que estás generando tecnología con baja probabilidad de producir valor. Y la solución es Desarrollo Ágil. Pero ágil de verdad, no sólo la capa superficial de tener un tablero kanban, de hacer reuniones diarias de pie, o tener “sprints” con objetivos semanales. Uno de los principios claves de la agilidad es responder al cambio en lugar de predecirlo. Las empresas tecnológicas de primer nivel — especialmente las más disruptivas — entienden que el mundo cambia y que la forma de prepararse es hacer soluciones simples que luego evolucionan. Mira cuánto ha cambiado Facebook o GMail; o la simpleza en la que se basó Whatsapp.

Ella se concentra mucho y hace como que pudiera predecir el futuro. El desarrollo ágil no se dedica a eso.

Ella se concentra mucho y hace como que pudiera predecir el futuro. El desarrollo ágil no se dedica a eso.

  • Síntomas: Te pasa que errores que tu equipo ya corrigió una vez vuelven a aparecer No te queda otra que implementar laaaargos procesos de QA manual cada vez que sales a producción aunque sea un cambio pequeño. Los “pasos a producción” son eventos donde asiste un montón de personas para estar “on site” en caso de problemas. Y dar marcha atrás te significa que el par de horas de trasnoche se transforma en pasar de largo hasta la madrugada.

El problema debiera ser más o menos obvio: En una empresa de tecnología de primer nivel, el QA — al igual que la infraestructura — se automatiza. La gran mayoría de tus casos de prueba debieran estar automatizados: ¿significa que las áreas de QA se quedan sin trabajo? No. Significa que dejan ocuparse de volver a ejecutar manualmente los mismos casos de prueba una y otra vez y se pueden dedicar a crear valor diseñando mejores pruebas, entendiendo a fondo el producto que están probando, etc, etc.

Y no basta con quedarse en tener un set de pruebas automatizado: Las empresas de primera multiplican el valor a esas pruebas ejecutándolas en cada cambio que se hace al producto via Continuous Integration e integrándolas al proceso de despliegue (también llamado “paso a producción”) via Continuous Deployment. Esto último requiere que hayas desarrollado tus músculos de DevOps mencionados más arriba. ¿Sabías que empresas de tecnología de primera son capaces de hacer decenas de “pasos a producción” cada día gracias a estas prácticas? Ése es el ritmo que tienes que ser capaz de llevar para competir en este mundo digital.

Pero sigamos, que aún nos quedan dos síntomas de problemas muy importantes:

  • Síntoma: Tus equipos  y/o proveedores sólo producen código y no entienden el negocio o para qué le sirve a alguien lo que están haciendo

En tal caso tus equipos están desconectados del cliente final. Necesitas Equipos Verdaderamente Ágiles. De nuevo, en el sentido original de la agilidad: la comunicación con el cliente es clave y si bien puede ser facilitada, nunca debe ser intermediada al punto en que alguien considera que su trabajo se reduce a producir código o a crear interfaces gráficas o a administrar contenido o a publicar ads. El trabajo de todos es entender el problema que estamos resolviendo, el negocio y su contexto, y producir la mejor solución dadas las restricciones (timing, presupuesto, tecnología disponible, etc.) y la expertise de cada uno.

En Chile la expresión "siempre de huevón" resume muy bien la actitud de quien "hace su pega" sin interesarse en el problema que está resolviendo realmente.

En Chile tenemos la expresión “siempre de huevón”. Resume muy bien la actitud de quien “hace su pega” sin interesarse en el problema que está resolviendo realmente, o su contexto.

  • Síntoma: Tus usuarios o clientes no entienden el producto que desarrollaste, o no les gusta para nada el resultado a pesar de que cumple con las especificaciones que ellos mismos declararon o incluso firmaron.

El problema en esos casos es que no estás validando que lo que estás produciendo satisfaga realmente las necesidades de tus usuarios. En Continuum resolvemos esto con Lean UX . La disciplina del diseño y su orientación al usuario final es una aliado clave en este punto, y si bien existen múltiples desafíos al incorporar UX al corazón de tu desarrollo de productos, su implementación vale completamente la pena. Porque al final siempre harás prototipos. La decisión a tomar es si te vas a gastar muchos meses haciendo ese prototipo sin validación (también llamado “hagamos la versión 1.0 en base a lo que nos dijeron los usuarios o el cliente”) o si prototipas más rápido y barato (sea con técnicas de Lean UX u otras).

Y en nivel más profundo: puedes haber resuelto la experiencia de usuario y la experiencia de cliente en muchos productos, pero si no son consistentes entre sí y con los canales no digitales, tus usuarios y clientes quedarán desorientados. Service Design es la disciplina del mundo del diseño+negocios que te ayuda a alinear canales y crear una experiencia consistente.

En Resumen

Hemos cubierto los más importantes gaps en prácticas y técnicas que se encuentran en áreas tecnológicas. Hay que cubrir estos gaps para poder competir en el mundo donde todas las empresas son empresas de software. Sólo así podremos habilitar nuestra propia transformación digital.

Nuestro slide de resumen de gaps y soluciones para adoptar prácticas digitales de primer nivel, que habilitan una transformación de verdad.

Siguiente Entrega: Habilitantes mas allá de la Tecnología

Si ya estamos al día en las prácticas mencionadas en este artículo, ¿podemos cantar victoria? Volvamos a la definición de transformación digital y el criterio de éxito que vimos anteriormente:

Una Transformación Digital será exitosa si le permite a nuestra organización asumir los cambios como una constante y saber lidiar con eso.

Con tener un equipo y/o partners tecnológicos de primer nivel, la verdad nos quedamos cortos. Es una condición necesaria, pero no suficiente. Porque una organización va mucho mas allá de sus áreas tecnológicas y sus procesos.

De eso se tratará nuestro próximo artículo: Pequeños y grandes detalles, algunos de sentido común, otros poco ortodoxos en la empresa tradicional, que hacen que los equipos interdisciplinarios (como los que vimos implementados en el caso de Facebook) funcionen. Y puedan moverse al ritmo de los cambios cada vez más acelerados que nos tocó vivir.

Suscríbete a nuestro newsletter de tecnología+negocios+diseño y sé el primero en enterarte cuando publiquemos el siguiente artículo de esta serie.

Agregar un comentario

Su dirección de correo no se hará público. Los campos requeridos están marcados *