Creación de mejores procesos Parte I: ¿Deben los procesos estar impulsados ​​por herramientas o por requisitos?

Este artículo analizará por qué, conceptualmente, los procesos deben basarse en los requisitos. También abordará cómo establecer objetivos para lograr procesos que reflejen dichos requisitos, con el fin de avanzar hacia un resultado ideal. La segunda parte ofrecerá orientación sobre cómo ponderar los requisitos e incorporarlos a la visión de cómo deberían ser los procesos en última instancia.

Al construir procesos ágiles para DevOps En las organizaciones inmersas en la transformación digital, los líderes de TI buscan centrarse en la optimización. Los procesos ideales contemplan todos los entregables necesarios, incorporan prioridades como la gobernanza y buscan la creación de valor más eficiente posible, permitiendo a la vez mejoras iterativas tanto del producto como del propio proceso. 

Sin embargo, muchos líderes de TI pueden encontrarse con un obstáculo: las herramientas. DevOps Los equipos suelen dictar el flujo de trabajo y la arquitectura del proceso integral. Entonces surge la pregunta: ¿debería ceder y dejar que las herramientas dicten la estructura de nuestro proceso? ¿O debería evaluarse continuamente dicha estructura en función de los requisitos reales de nuestros objetivos?

Para responder directamente a la pregunta principal: los procesos deben estar basados ​​en requisitos, sin más. Si no se cumplen los requisitos, esto puede afectar negativamente al producto e impedir que la organización alcance su máximo potencial productivo. El personal se frustrará y se consumirá una gran cantidad de energía simplemente gestionando el proceso en lugar de generar valor tangible para los clientes finales y las partes interesadas internas.

Llegar al punto en que los requisitos pueden impulsar el proceso

Decir que «todo debe estar basado en requisitos» es fácil, pero esto implica que las organizaciones deben dedicar tiempo a generar ideas, investigar y desarrollar un método para cuantificar dichos requisitos. Además, los requisitos deben basarse en criterios que garanticen la creación de productos de mayor valor y que el trabajo interno produzca resultados de calidad de forma eficiente y constante.

Insistir en que los procesos reflejen los requisitos no excluye el uso de herramientas específicas. Esto es especialmente cierto en sectores verticales que pueden necesitar herramientas específicas, como una herramienta de monitorización del cumplimiento para el desarrollo de software aeroespacial y de defensa. En estos casos, sin embargo, las herramientas en sí mismas son importantes porque no existe otro medio disponible para cumplir con los requisitos.

Otro desafío que pueden enfrentar las organizaciones es que resulta más sencillo buscar soluciones para cada producto individualmente que buscar criterios o características que cumplan con requisitos específicos. A menudo, las organizaciones deben partir de un requisito para determinar qué características y criterios de la herramienta son necesarios para satisfacerlo. Finalmente, es posible que una organización deba hacer concesiones en algunos requisitos para cumplir con otros. 

Aun con estos desafíos reconocidos, el objetivo general de crear un nuevo proceso o revisar uno existente debería ser no permitir que las herramientas (o sus atractivas características) dicten la arquitectura de su proceso. DevOps En lugar de basarse en un pipeline, deje que los requisitos controlen esta arquitectura y concéntrese en los resultados que sus equipos desean obtener. Luego, plantee preguntas difíciles sobre los cambios de proceso necesarios para descubrir qué herramientas se adaptan mejor a las necesidades de los equipos.

Las organizaciones se enfrentan a opciones limitadas, lo que las obliga a trabajar a la inversa, desde los requisitos hasta la comparación de herramientas.

En un mundo centrado en los productos, garantizar que los procesos se basen completamente en los requisitos puede parecer poco realista. Las soluciones preconfiguradas y listas para usar suelen ofrecer solo un conjunto específico de capacidades y características. Cuando una solución se puede personalizar, las organizaciones generalmente se ven limitadas a un menú de opciones.

Las organizaciones también pueden optar por desarrollar soluciones personalizadas desde cero, pero esto puede resultar costoso si se implementa de forma generalizada en todos los procesos. La organización puede verse obligada a «reinventar la rueda» y construir un flujo de trabajo pieza por pieza, cuando en realidad debería estar desarrollando un producto que aporte valor. 

Además, es posible que la organización desconozca las funcionalidades exactas que debe integrar en estas soluciones propietarias. A menos que sean proveedores de soluciones, no pueden crear especificaciones desde cero. Deben basarse principalmente en las soluciones existentes para definir la configuración de sus alternativas propias. Existen algunas excepciones notables, como el caso de Slack, donde un equipo ha creado una arquitectura completamente nueva; sin embargo, en muchos casos, las empresas simplemente intentan desarrollar su propia versión de soluciones existentes, a menudo combinando funcionalidades de las herramientas más populares.

Por lo tanto, los procesos de una organización inevitablemente reflejarán las herramientas que utilice, ya sean adquiridas o desarrolladas internamente. Ante esta realidad, resulta arduo priorizar los requisitos en las decisiones de adquisición o los cambios de procesos, pero es una batalla crucial que librar. De lo contrario, las herramientas terminarán dictando los flujos de trabajo y estableciendo las expectativas de rendimiento. Los equipos acabarán sintiendo que el fruto de su trabajo se limita a las capacidades de sus herramientas, en lugar de reflejar la visión final del resultado que producen sus procesos.

Haga que sus procesos se basen en los requisitos, ya sea buscando soluciones o construyendo una DevOps o renovación de su canalización actual

Es innegable que resulta difícil centrarse exclusivamente en los requisitos cuando las opciones disponibles obligan a priorizar conjuntos de características o funcionalidades específicas. Incluso al desarrollar desde cero o al personalizar, las organizaciones suelen sentirse limitadas a enfoques concretos dictados por lo que está disponible o por lo que se considera razonablemente factible.

Los problemas pueden surgir cuando la sensación de estar atrapado en un proceso específico genera resultados insatisfactorios. Al igual que un cocinero aficionado cuyas opciones culinarias se ven limitadas a un conjunto reducido de ingredientes básicos, las organizaciones pueden sentirse insatisfechas cuando permiten que las herramientas dicten lo que son capaces de crear.

Para garantizar que se reconozcan los requisitos, y mucho menos que se cumplan, las organizaciones deben revisar periódicamente sus necesidades y cuestionar las soluciones actuales. Deben crear una lista de características y funcionalidades que satisfagan los requisitos acordados y, posteriormente, evaluar las soluciones para, a partir de ahí, adquirir o desarrollar herramientas que ofrezcan la mejor combinación de las funcionalidades necesarias. Asimismo, deben reevaluar periódicamente las opciones elegidas para mejorar los procesos o cambiar las herramientas según sea necesario. 

Los líderes organizacionales pueden colaborar para desarrollar una lista, marco o matriz de requisitos formalizados y utilizarlos para evaluar si las soluciones o los procesos cumplen con los requisitos. Algunos ejemplos de herramientas de evaluación incluyen: CMMI — Integración del modelo de madurez de capacidadesLa organización también puede establecer un marco similar a Herramienta de evaluación de productos basada en la normativa DO-178B de la industria aeroespacial.

Sea cual sea el enfoque, no se deje deslumbrar por las herramientas en sí. Al fin y al cabo, cualquier organización puede usar las mismas. Es como ir a una feria de artesanía donde todos ofrecen los mismos productos, elaborados con un solo tipo de kit comprado en una tienda de manualidades: sin diferenciación ni innovación. Solo cuando las herramientas se combinan para ajustarse a requisitos específicos y alineadas con una visión única, una organización puede ofrecer algo de un valor precioso e irremplazable.

La segunda parte de esta publicación ofrecerá información sobre cómo elaborar una lista de requisitos, priorizarlos y luego utilizarlos para formar una visión de los procesos que reflejen mejor los resultados previstos.

Aprenda a evaluar las opciones de herramientas y a visualizar cómo sus elecciones afectan el proceso de principio a fin. DevOps En nuestro reciente seminario web se mencionó el siguiente tema:Desmitificar el DevOps Paisaje con el Periodic Table of DevOps Instrumentos & DevOps Generador de diagramas"