Separación de poderes (Parte 2)

Suponiendo un proceso automático y razonable de gestión del cambio ya implantado (nota mental: como montar uno) , hay pocos motivos buenos para intentar saltárselo y muchas excusas para tapar problemas o colar cosas (similar a violar una cadena de custodia. Toda linea de codigo en produccion debe ser auditable durante todo el proceso de cambio: desde quien la desarrolló, por los entornos que ha pasado, quien la ha promocionado, cuando, etc.).

Sin embargo es normal que haya presiones para saltárselo, casi siempre con la excusa de la “flexibilidad“. Y es difícil negarse si dirección permite vulnerar las normas y seguridad mira para otro lado. Es un camino que lleva al caos y la anarquía así que si se da la situación hay que entender la causa y minimizar daños.

Modificaciones en el entorno de produccion

La causa más común es que no han probado la aplicación previamente, se sube a produccion y el usuario se da cuenta que hay tipos o palabras mal escritas. Otra veces son funcionalidades que no han probado y cuando entran producen un fallo. Suelen necesitar soluciones tontas, modificar un texto, subir una clase, no son cambios masivos y juegan con “¿por esta tonteria hay que rehacer todo el proceso?) .

El problema es que el proceso existe para que todo quede registrado, si se modifica directamente no queda registro. A veces estos cambios no exigen reiniciar y son un fix rapido. No hay muchas alternativas, el compromiso es que sea una petición oficial de negocio con copia a jefes de IT (para evitar ir de tapadillo) y un cambio de emergencia siguiendo el proceso normal para la siguiente ventana de instalación. En estos casos el fix no registrado dura el menor tiempo posible online.

Modificaciones en el entorno de integración o pruebas de usuario

Con gente de la casa no suele existir el problema pero esto es facil que suceda si subcontratas proyectos a consultoras externas. Se sienten encorsetados y empiezan a poner pegas de si no van a llegar en fechas (un clásico).

Si esto sucede, la causa principal es falta de calidad del equipo de desarrollo. No saben trabajar en local e integrar cambios y necesitan acceder directamente a una maquina para tener algo funcionando a base de prueba y error. Esto es como ver un lemming, ya sabes que va acabar despeñado.  Contención de daño, si dirección no hace nada al respecto tu objetivo es que no te arrastren (a ti y al resto de aplicaciones).

Monta una estructura paralela de entornos, crea entornos de desarrollo y que trabajen con ellos. Estos equipos no duran mucho más que la creación de la aplicación y el marrón del mantenimiento se lo comen otros, lucha para que el mantenimiento este integrado en el proceso oficial de cambio (no es dificil, ya que la excusa es la flexibilidad para sacar el nuevo proyecto y una vez fuera ya esta cubierta, los actores se han ido o apunto de irse, y las medallas colgadas en el hombro de algun jefe, funcione… o no.)

Para ello hay que asegurarse que la aplicacion se integra con el proceso de cambio, construye e instala en todos los entornos. Y la construcción se atiene a unas normas de la compañía.

A veces, la causa es puramente ego de un jefe de proyecto, querer estar por encima de las normas. Normalmente nadie le para lo pies e incluso esta muy bien valorado por dirección. Dale cuerda, pero recuerda esta gente nunca se ahorca siempre encuentran a alguien que ocupa su sitio en el nudo. No seas tu.

 

Leave a Reply

Your email address will not be published. Required fields are marked *