Cómo hablar de automatización del SDLC sin un ROI inventado

Toda propuesta de automatización termina ofreciendo un retorno. Algunos de esos números se modelan desde la línea de base del propio comprador. Muchos se toman prestados de una diapositiva que el comprador no generó. S·CORP no le va a entregar un retorno que no hayamos medido en su tubería. Lo que sí haremos es decir qué relojes vale la pena medir, quién tiene que aceptar que la línea de base es real, y cómo debe comportarse un camino automatizado cuando ya existe.

La automatización de la entrega de software no es un bot que escribe código. Es la eliminación de rituales privados entre una decisión y producción: preparación de entornos, revisión, evidencia de pruebas, aprobación del cambio, liberación y el registro que permite explicar la liberación después. La IA puede sentarse dentro de ese camino. No lo reemplaza.

Cuente el camino que tiene, no el que desearía

Antes de que alguien proponga una herramienta, escriba el camino que hoy recorre un cambio normal. No el camino feliz del manual de ingeniería. El camino que el equipo usa de verdad cuando el cambio es ordinario, y el camino que usa cuando tiene miedo. Suelen ser distintos, y en el segundo se esconden el tiempo y el riesgo.

Elija unidades que un patrocinador pueda auditar. El tiempo desde "listo para construir" hasta "corriendo en producción." El número de traspasos que obligan a una persona a volver a escribir información que ya está en un sistema. La proporción de cambios que dejan una incidencia, un cambio confirmado y un registro de despliegue atados. El número de defectos de entorno hallados después de un despliegue que en realidad eran "el entorno no era el que probamos." No hace falta un estudio del sector para saber si su propio equipo puede responder esas preguntas. Si no puede, ese es el primer hallazgo.

Acuerde la línea de base por escrito con las personas que hacen el trabajo. Una línea de base tomada de una estimación del comité de dirección se va a discutir después, y la discusión se usará para descartar la automatización. Una línea de base tomada de un mes de cambios ordinarios, con el equipo en la sala, es más difícil de ignorar.

Automatice la evidencia, no solo el paso

Una tubería más rápida y muda no es una mejora en un negocio regulado. La banca, los seguros y cualquier firma que responde a clientes por la disponibilidad necesitan que la liberación sea explicable. La automatización debe adjuntar la evidencia al cambio: qué pruebas corrieron, qué se omitió y por qué, quién aprobó, qué artefacto se desplegó y cómo volver atrás. Si la evidencia vive en una conversación, no existe para la persona que tiene que responder el trimestre que viene.

ISO 27001 aparece aquí como gestión del cambio y seguridad de las operaciones, no como un logo. El control es "podemos mostrar qué cambió." PCI DSS aparece si el sistema está en el entorno de datos de titular de tarjeta: la separación de funciones y un registro del cambio no son un adorno. Un agente que abre una solicitud de cambio puede ser útil. Un agente que aprueba su propio camino a producción es un control que falta.

La IA dentro de la tubería tiene un trabajo estrecho y honesto. Puede redactar una prueba, resumir la diferencia del cambio para quien revisa, o señalar una línea de registro que coincide con un fallo conocido. No debe ser quien aprueba. Quien revisa sigue siendo responsable, lo que significa que la superficie de revisión tiene que mostrar la diferencia del cambio y la evidencia, no un párrafo que dice que la diferencia estaba bien.

De dónde sale de verdad el retorno

El retorno, cuando es real, sale de un camino más corto y más predecible, de menos fallos repetidos de preparación, y de menos tiempo reconstruyendo qué pasó. Es específico de la línea de base que usted escribió. Un equipo que ya despliega cambios pequeños con evidencia verá un resultado distinto del de un equipo cuya liberación es una ceremonia de fin de semana. Quien le cite un solo porcentaje para los dos equipos no está hablando de su SDLC.

Modele el retorno en la unidad que el socio de finanzas ya confía. Horas devueltas a ingeniería. Tiempo de entrega. Despliegues fallidos que ya no necesitan una llamada de puente. El esfuerzo de un entorno que se puede reconstruir en lugar de cuidarlo. Ponga los supuestos al lado del modelo, incluido el supuesto del que está menos seguro. Si el modelo solo funciona cuando nada sale mal, no es un modelo.

No esconda la adopción. Un camino automatizado que la mitad de los equipos rodea en silencio no es el camino. El rodeo es el camino. Mida la proporción de cambios que de verdad pasan por la ruta automatizada. Si esa proporción es baja, el trabajo es de producto sobre el camino, no una campaña para que la gente cumpla.

Qué rechazar en el caso de negocio

Rechace un caso que dependa de una reducción de personal que usted no ha acordado quitar. La automatización que libera tiempo no reduce un equipo de forma automática. A veces el punto es gastar a las mismas personas en trabajo que no se estaba haciendo: correcciones de seguridad, profundidad de pruebas, defectos de cara al cliente. Diga cuál de las dos es.

Rechace un caso que trate al modelo como el activo y a la tubería como un detalle. El activo es un sistema de entrega al que un equipo nuevo puede unirse sin una orientación privada. Rechace un caso sin vuelta atrás y sin dueño de la tubería. La tubería es producción. Necesita un dueño, un proceso de cambio y una forma de notar que está mintiendo.

El Marco de Gestión de Riesgos de IA de NIST sigue aplicando cuando la "IA" es un ayudante dentro de la cadena de herramientas. Gobierne el uso, mapee dónde puede aterrizar el código o las pruebas generadas, mida si quienes revisan atrapan defectos que el ayudante introdujo, y gestione al proveedor que aloja al ayudante. Las mismas reglas de datos aplican: el código fuente, los datos de clientes en los juegos de prueba y los secretos no pertenecen a una traza de proveedor que usted no ha leído.

Una secuencia práctica

Empiece con un equipo y una clase de cambio. Instrumente la línea de base durante una ventana corta y acordada. Automatice el paso que más a menudo obliga a una persona a reescribir o a esperar: por lo general la creación del entorno, la evidencia de pruebas, o el vínculo entre la incidencia y el despliegue. Deje a una persona en la aprobación. Revise el primer conjunto de cambios con el equipo que es dueño de la operación, no con una diapositiva. Después decida si el camino está en condiciones de extenderse.

Esa secuencia no cabe en una baldosa de retorno de la inversión, y no debe caber. La baldosa puede venir después de que la línea de base sea real. Si un proveedor o un socio no puede trabajar en ese orden, está vendiendo el número, no el camino.