> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/es/2021/w03-digital-workflow.md).

# W03-Flujos de trabajo digitales

Mientras preparábamos la planificación de 2021, Jerry me hizo una pregunta: ¿cómo medir la capacidad de las personas para comprender el negocio?

Pensé en varios ángulos. Desde los resultados, podríamos observar cuánto apoya la arquitectura al negocio, si la planificación técnica es razonable o cuántos problemas de negocio se han resuelto mediante mejoras de ingeniería. Desde el proceso, cuánto tiempo se dedica a aprender sobre el dominio, si la participación en las discusiones de requisitos y planificación es suficiente, o qué opinan los compañeros de otras funciones. Es evidente que ninguna de estas dimensiones cumple bien los criterios SMART. Convertir una capacidad tan abstracta en un indicador medible resulta realmente difícil.

Esto me llevó a una observación algo irónica. Nos dedicamos a digitalizar, pero nuestro propio trabajo está poco digitalizado. Sin suficiente digitalización no podemos abstraer ni estandarizar bien y, por tanto, tampoco escalar. No podemos extraer y difundir la experiencia de nuestros mejores empleados, y cuesta construir modelos de capacidades como la comprensión del negocio.

Desde el punto de vista de la gestión organizativa, hoy solo vemos datos sobre la distribución del esfuerzo de cada persona en relación con los requisitos. Prácticamente no hemos digitalizado el esfuerzo dedicado a otras actividades.

Incluso un solo requisito completo atraviesa una larga cadena de acciones: revisión de requisitos, diseño técnico, programación, integración, revisión de código, pruebas propias, despliegue del entorno, lanzamiento gradual y observación en producción. Tenemos datos de cada parte, pero carecen de detalle. Abundan los datos de resultados y escasean los de procesos y comportamientos. Además, los datos de cada etapa apenas están conectados. En Ones, por ejemplo, los estados de los requisitos y las tareas se actualizan manualmente. Siempre hay cambios olvidados o tardíos, así que los datos solo ofrecen una idea aproximada. Lo ideal sería que, como usuarios, en la mayoría de los casos ni siquiera tuviéramos que prestar atención a herramientas de gestión de requisitos como Ones.

Esto me hizo pensar en los Cloud IDE. Antes no entendía bien el valor de llevar el IDE a la nube, pero desde la perspectiva de la organización es algo considerable. Creo que su mayor valor está en digitalizar el flujo de trabajo. El IDE es la herramienta que más utilizan los desarrolladores y, aun siendo tan importante, cada uno usa uno distinto. Los comportamientos y los datos que genera quedan desconectados. En la nube, el IDE podría actuar como una plataforma conectada con muchos procesos anteriores y posteriores: asociar directamente ramas con requisitos, enviar a pruebas con un clic, desplegar con un clic, etc. Algunos datos básicos bastarían para actualizar Ones de forma automática. También permitiría resolver problemas de eficiencia y seguridad, como unificar el entorno de desarrollo y proteger el código fuente evitando que se guarde en el disco del desarrollador.

Podemos imaginar ese futuro: un diseño genera, mediante generación inteligente y con un clic, código que se puede seguir desarrollando. El código se importa en un Cloud IDE para ajustarlo y, con otro clic, se construye y despliega una aplicación que funciona en varias plataformas. Todos los datos y activos quedarían en la plataforma, y cada etapa podría optimizarse de forma específica con abundantes datos.