¿Por qué el desarrollo de software es un proceso de negocio?

Hace unos días, alguien reflexionaba que el desarrollo de software es “el arte de capturar necesidades, comunicarlas y construir soluciones usando bits”. Es una observación interesante. Expresa que el desarrollo de software tiene diferentes facetas, más allá de la programación. Buena parte de la energía que se invierte en un proyecto es efectivamente un ejercicio brutal de comunicación que a veces eclipsa todo lo otro: comunicación con el cliente, comunicación dentro del equipo, comunicación con otros equipos… El solo hecho de comprender y descifrar las necesidades de los usuarios para que el equipo pueda construir algo útil requiere de muchísima comunicación. Toneladas de comunicación. 

Muchas veces creemos que la comunicación termina cuando los requerimientos que vienen del área de negocio y del cliente quedan recogidos en las historias de usuario. Pero eso es solo el comienzo del camino. La comunicación también es necesaria para diseñar las pruebas, mejorar la usabilidad, desplegar y poner en marcha los cambios, preparar demos, actualizar documentación, monitorizar entornos, etc. Más toneladas de comunicación. 

En todo este proceso ocurren un montón de transformaciones sucesivas de artefactos abstractos y con niveles diferentes de granularidad. La comunicación es el motor que las hace posible. Así, una iniciativa que se envía a los analistas de negocio en forma de épica se desgrana en requerimientos, que se envían a los equipos de desarrollo, y éstos a su vez los convierten en features, historias de usuario, código, planes de pruebas automatizadas, etc. Encontrar los límites y granularidad de cada nivel es un arte que requiere de mucha experiencia y conocimiento. 

Aplicando los valores de la agilidad para conectar los eslabones

Los marcos ágiles de trabajo tratan de conectar los eslabones de esa larga cadena. Pero sigue siendo difícil. Muchas veces, cuando tratamos de cerrar el bucle de vuelta con los clientes, nos damos cuenta de que lo que ellos pidieron no es lo que realmente esperaban—ni lo que obtienen. 

Es interesante ver que muchas organizaciones están adoptando las prácticas ágiles para mejorar la entrega de valor a sus clientes. Pero a veces, lo que en realidad ocurre es que solamente los equipos de desarrollos y pruebas han hecho la transición—con Scrum, Kanban o DevOps. En muchas de estas organizaciones, las otras áreas siguen funcionando como silos aislados y son gestionadas con una mentalidad basada en el control: las cosas se hacen según el plan trazado, sin importar mucho el impacto global y cuánto aportan a los clientes. Una visión local. 

El problema con los silos de información y conocimiento es que se interponen en la generación y entrega de valor. Demasiada burocracia. Bloqueos. Falta de alineamiento. Poca colaboración. No hay una visibilidad global, de principio a fin, de toda la cadena. 

 ¿Cómo mejoramos el desarrollo, la distribución y la puesta en marcha del software? ¿Cómo logramos alinear todas las disciplinas que participan? 

Definition of Done aplicado a Value Streams

Una manera de aliviar el problema es haciendo que los equipos de desarrollo amplíen el alcance de su Definition of Done. ¿Cuándo consideramos que un feature está terminado? ¿Al hacer commit del código y solicitar el despliegue? ¿O cuando ha sido desplegado en producción y recibimos feedback de usuarios reales?  

La segunda opción ofrece una visión mucho más amplia del compromiso con el cliente. También involucra a muchos más actores. Es un cambio radical con mucho foco en la colaboración y en la comunicación efectiva. Bajo esta perspectiva, el desarrollo de software se ve como un proceso completo de negocio: desde la fase de ideación, pasando por todo el proceso de implementación, hasta la entrega de valor al cliente.  

Esta secuencia de actividades, personas y herramientas encaja muy bien con la definición de value stream. Este concepto, que proviene de los procesos de fabricación industrial, se refiere a todo el flujo o cadena de valor, de principio a fin, desde que llega una solicitud hasta que ponemos el resultado en manos del usuario final. En el desarrollo de software, podemos hablar de value streams a diferentes niveles. Los más locales se refieren al proceso que arranca con una historia de usuario y termina en el despliegue. Pero es mucho más interesante tener una visión más amplia, que empieza con una solicitud del área de negocio y continua con el proceso que ensambla todos los componentes—el arte de convertir los requerimientos en bits—y se materializa cuando el software está desplegado en producción. 

Creación de equipos cross-funcionales

Cuando hablamos de value streams nos referimos a la manera en la que nos comunicamos. La adopción de un mindset orientado a value streams agiliza la comunicación, pero requiere de cambios en la organización. ¿Por dónde comenzar? La creación de equipos cross-funcionales es una buena estrategia. La idea de tener equipos cross, transversales y con todas las competencias necesarias funciona muy bien en las áreas de tecnología. ¿Por qué no aplicar este concepto para conectar todos los eslabones?  

La realidad nos demuestra que todo es más complejo en las organizaciones grandes, con miles de empleados, con portfolios con muchos productos y servicios—que en algunos casos están sometidos a muchas regulaciones. En estos casos, la especialización, las áreas y las disciplinas son reales—aparecen pintadas en un organigrama que gobierna sus relaciones. Los organigramas suelen mostrar líneas de comunicación en sentido vertical, pero no horizontal. Cada silo está dedicado a determinadas actividades: las unidades de negocio por un lado, los equipos de tecnología por otro, más allá están los equipos que ponen en marcha y monitorizan las soluciones, los de soporte. Cada disciplina tiene sus propias herramientas, sus necesidades, su inercia. Pivotar hacia equipos realmente cross-funcionales es complejo. Pero ciertamente necesitamos tender puentes y crear vasos comunicantes. 

Optimizar la entrega de valor utilizando métricas

Pero no alcanza con conectar y tener una visión global del trabajo de los equipos. Las organizaciones ágiles son organismos complejos y adaptables; no son sistemas mecánicos y lineales. Necesitamos métricas que enlacen a todas las áreas para poder gestionar el flujo activamente y tomar decisiones globales basadas en datos objetivos. Debemos poder medir el impacto de esto sobre el resultado final y responder a preguntas de este tipo: ¿dónde están los retrasos? ¿qué funciona bien? ¿cómo estamos avanzando en cada momento? ¿cómo de eficiente es el flujo de información por toda la cadena? ¿cómo está funcionando la adopción de DevOps, Agile, SAFe? ¿cuál es nuestra velocidad para innovar? 

El software se ha convertido en el factor diferencial de muchísimas organizaciones. No se me ocurren ni un solo ejemplo de una empresa que no dependa de software para ofrecer sus productos y servicios. Cada vez más, la competitividad y la innovación dependen del software. Y por ello es tan importante hacer cambios en las estructuras para agilizar la manera en la que las áreas de tecnología diseñan, construyen y ponen en marcha las soluciones—apoyando y siendo apoyadas por las áreas de negocio. Transparencia. Alineamiento. Colaboración. Visión global. Métricas. ¡Y comunicación fluida! 

¿Por qué pasar de silos organizaciones a Value Streams? Netmind Talks