Dos en caja (si se puede) y todos en documentación (siempre).
En un contexto de TI, "dos en una caja" se refiere a dos servidores o componentes que están diseñados para trabajar juntos para brindar redundancia y mayor confiabilidad. Esta configuración puede garantizar que si un componente falla, el otro se hará cargo de sus operaciones, manteniendo así la continuidad del servicio. El objetivo de tener "dos en una caja" es proporcionar alta disponibilidad y recuperación ante desastres. Esto también se aplica a los roles humanos en una organización; sin embargo, rara vez se implementa.
Veamos un ejemplo relevante de Analytics. Es probable que todos conozcamos a una persona en nuestra empresa u organización por su nombre que es la persona a quien acudir para Analytics. Son los que tienen informes o tableros con su nombre: Informe de Mike o Tablero de Jane. Claro, hay otras personas que saben de análisis, pero estos son los verdaderos campeones que parecen saber cómo hacer las cosas más difíciles y superar los plazos. El problema es que estas personas están solas. En muchos casos, bajo presión, no trabajan con nadie, ya que eso puede ralentizarlos y ahí es donde comienza el problema. Nunca pensamos que vamos a perder a esta persona. Me abstendré del típico “digamos que los atropella un autobús” o usando un ejemplo aprovechando las oportunidades del mercado laboral actual y diré algo positivo como “¡se ganaron la lotería!”, porque todos debemos hacer nuestra parte para ser positivos. estos días.
La historia que hay detrás
Llega el lunes por la mañana, y nuestro experto en análisis y campeón MJ ha presentado su renuncia. MJ ganó la lotería y ya se fue del país sin un cuidado en el mundo. El equipo y las personas que conocen a MJ están emocionados y celosos, pero el trabajo debe continuar. Ahora es cuando el valor y la realidad de lo que estaba haciendo MJ está por entenderse. MJ fue responsable de la publicación final y la validación de los análisis. Siempre parecían poder mejorar la eficiencia o hacer ese cambio difícil antes de proporcionar los análisis a todos. A nadie realmente le importaba cómo se hizo y estaba seguro de que acababa de suceder, y MJ era una estrella de Rock individual de Analytics, por lo que se otorgó un nivel de autonomía. Ahora que el equipo comienza a recoger las piezas, las solicitudes, los problemas diarios, las solicitudes de modificación, están perdidos y comienzan a revolverse. Los informes/paneles se encuentran en estados desconocidos; algunos recursos no se actualizaron durante el fin de semana y no sabemos por qué; la gente pregunta qué está pasando y cuándo se arreglarán las cosas, las ediciones que MJ dijo que se hicieron no aparecen y no tenemos idea de por qué. El equipo se ve mal. Es un desastre y ahora todos odiamos a MJ.
Las lecciones
Hay algunas conclusiones fáciles y obvias.
- Nunca permita que una persona trabaje sola. Suena bien, pero en equipos ágiles más pequeños, no tenemos el tiempo ni las personas para que esto suceda. Las personas van y vienen, las tareas son muchas, por lo que se divide y vencerá en nombre de la productividad.
- Todos deben compartir sus conocimientos. También suena bien, pero ¿estamos compartiendo con la persona o personas adecuadas? Tenga en cuenta que muchos ganadores de la lotería son compañeros de trabajo. Hacer sesiones de intercambio de conocimientos también le quita tiempo a las tareas y la mayoría de las personas solo invierten en habilidades y conocimientos justo en el momento en que se necesitan.
Entonces, ¿cuáles son algunas soluciones reales que todos pueden implementar y respaldar?
Comencemos con la gestión de la configuración. Usaremos esto como el término general para varios temas similares.
- Gestión del cambio: El proceso de planificación, implementación y control de cambios en los sistemas de software de forma estructurada y sistemática. Este proceso tiene como objetivo garantizar que los cambios se realicen de manera controlada y eficiente (con la capacidad de revertir), con la mínima interrupción del sistema existente y el máximo beneficio para la organización.
- Gestión De Proyectos: La planificación, organización y control de proyectos de desarrollo de software para garantizar que se completen a tiempo, dentro del presupuesto y con los estándares de calidad deseados. Implica la coordinación de recursos, actividades y tareas a lo largo del ciclo de vida del desarrollo de software para lograr los objetivos del proyecto y entregar el producto de software a tiempo.
- Integración Continua y Entrega Continua (CI/CD): El proceso de automatización de la construcción, prueba e implementación de software. La integración continua requiere la fusión periódica de cambios de código en un repositorio compartido y la ejecución de pruebas automatizadas para detectar errores en las primeras etapas del proceso de desarrollo. La entrega/implementación continua implica la liberación automática de cambios de código probados y validados en producción, lo que permite lanzamientos rápidos y frecuentes de nuevas funciones y mejoras.
- Control de versiones: El proceso de administrar cambios en el código fuente y otros artefactos de software a lo largo del tiempo utilizando herramientas de software especializadas. Permite a los desarrolladores colaborar en una base de código, mantener un historial completo de cambios y experimentar con nuevas funciones sin afectar la base de código principal.
Todo lo anterior se refiere a buenas prácticas de desarrollo de software. Los análisis que impulsan y ejecutan el negocio no merecen menos, ya que son una misión crítica para la toma de decisiones. Todos los activos de análisis (trabajos de ETL, definiciones semánticas, definiciones de métricas, informes, paneles, historias, etc.) son solo fragmentos de código con una interfaz visual para el diseño y los cambios aparentemente menores pueden causar estragos en las operaciones.
Usar Configuration Management nos cubre para seguir funcionando en buen estado. Los activos están versionados para que podamos ver lo que ha sucedido en su vida útil, sabemos quién está trabajando en qué junto con el progreso realizado y los plazos, y sabemos que la producción continuará. Lo que no está cubierto por ningún proceso puro es la transferencia de conocimiento y la comprensión de por qué las cosas son como son.
Cada sistema, base de datos y herramienta de análisis tiene sus propias peculiaridades. Cosas que los hacen ir rápido o lento, elementos que los hacen comportarse de cierta manera o producir un resultado deseado. Estos pueden ser configuraciones a nivel de sistema o global o cosas dentro del diseño de activos que hacen que funcionen como deberían. El problema es que la mayoría de estas cosas se aprenden con el tiempo y no siempre hay un lugar donde documentarlas. Incluso cuando pasamos a sistemas en la nube donde ya no controlamos cómo se ejecuta la aplicación y confiamos en el proveedor para que lo haga lo más rápido posible, el ajuste de las definiciones continúa dentro de nuestros activos para desbloquear exactamente lo que estamos buscando. Este conocimiento es lo que necesita ser capturado y compartido poniéndolo a disposición de otros. Este conocimiento tiene que ser requerido como parte de la documentación de los activos y debe ser una parte integral del control de versiones y del proceso de verificación y aprobación de CI/CD y, en algunos casos, incluso como parte de una lista de verificación antes de la publicación de cosas por hacer y no hacer. hacer.
No hay respuestas mágicas o IA para cubrir los atajos en nuestros procesos de análisis o la falta de ellos. Independientemente del tamaño del equipo que mantiene el flujo de datos y análisis, una inversión en un sistema para rastrear cambios, versionar todos los activos y ayudar a documentar el proceso de desarrollo y capturar conocimiento es imprescindible. La inversión en procesos y tiempo por adelantado ahorrará una tonelada de tiempo desperdiciado más tarde al resolver las cosas para mantener un estado saludable de nuestro análisis. Las cosas pasan y es mejor tener una póliza de seguro para MJs y otros ganadores de lotería.
