Mi primer proyecto completamente de backend como Analista de Negocios (BA) fue todo un despertar. Me vi sumergido en un tsunami de tecnicismos, terminología de la nube, diagramas arquitectónicos, sin una interfaz de usuario o clientes finales a la vista. Las reuniones solían convertirse en discusiones animadas sobre clústeres de Kubernetes y gráficos de Helm huérfanos. Estar perdido era la norma, hasta el punto de que incluso cuestioné mi capacidad para contribuir. Me llevó un tiempo, pero finalmente comprendí que las habilidades de un BA trascienden el tipo de producto que estás entregando, ya que se centran en conceptos clave universales. Incluso si no tienes un BA dedicado en tu equipo, pero quieres mejorar la eficiencia de tu entrega, aquí hay algunas cosas que debes tener en cuent
1. Simplificación
A los desarrolladores les encanta resolver problemas, casi tanto como les gusta contarte cómo lo hicieron. Pueden adentrarse en cuestiones con un montón de tecnicismos, lo cual desafortunadamente a veces puede perder a la audiencia. Por fascinante que pueda ser escuchar cómo el equipo evitó hábilmente un posible incidente de producción aumentando los nodos de trabajo de t3.medium a m4.large, esto puede no ser necesario en todas las conversaciones. En nuestro mundo de reuniones virtuales seguidas, es posible que los interesados no tengan el tiempo o la capacidad de atención para asimilar todo el contexto, por lo que es importante llegar al meollo del asunto rápidamente, utilizando los términos más simples posibles.
Esto es especialmente útil al hablar con audiencias más amplias (por ejemplo, demostraciones de productos) y con interesados de nivel superior menos involucrados. Si tienes problemas con esto, piensa en situaciones en las que has hablado con alguien que tiene menos fluidez en tu idioma nativo; ¿te has encontrado hablando más despacio, utilizando un vocabulario más simple y siendo más directo? De la misma manera, intenta simplificar la forma en que tu equipo se comunica para asegurarte de que tus interesados estén completamente informados y comprometidos durante todo el proceso de entrega.
2. Optimización de procesos
Los BAs dedican mucho tiempo a analizar los procesos existentes e intentar mejorarlos. Estos pueden variar desde algo genérico como incorporar nuevos miembros al equipo hasta la selección de alertas críticas de seguridad en múltiples equipos, líneas de tiempo de respuesta y foros burocráticos. Establecer procesos permite que los equipos se centren más en su trabajo y menos en navegar por la complejidad. Si tienes trato con muchos equipos externos, esto es especialmente importante, ya que el trabajo que requiere colaboración lleva significativamente más tiempo que el trabajo individual.
Gran parte de esto se debe a la falta de comunicación, suposiciones incorrectas, cambios de contexto, demoras en la validación y lograr el momento adecuado para que ambas partes estén listas para continuar el trabajo durante las múltiples entregas. Si necesitas visualizar estos cuellos de botella, configurar un tablero de control en tu plataforma de gestión de proyectos preferida puede ser de gran ayuda. Por lo tanto, revisa tus procesos actuales y comienza a determinar qué aspectos deben mejorarse. Tu equipo te lo agradecerá.
3. Mirar el panorama general
Una de las cosas más difíciles en el desarrollo de infraestructura es definir los hitos, ya que gran parte del trabajo no encaja en "funcionalidades" tradicionales como tal. Esto tiene algunas implicaciones. Una de ellas es la apatía en el desarrollo, donde las entregas tienden a volverse rutinarias (¿Qué pasa? ¿El equipo Alfa está celebrando su décimo lanzamiento? ¿Deberíamos comenzar a celebrar cómo no tuvimos problemas durante nuestro último escaneo de vulnerabilidades?). Otra es que se vuelve difícil hacer un seguimiento del trabajo que está constantemente en progreso debido a las mejoras continuas. Después de todo, somos ágiles y estamos constantemente iterando.
Entonces, ¿cómo estableces un límite lógico para el trabajo, uno que no sea demasiado ambicioso pero aún así lo suficientemente significativo como para llamarlo un hito? Aquí es donde debes comenzar a pensar en grande. ¿Qué estamos tratando de lograr realmente? ¿Qué significará esto para los otros equipos que dependen de nosotros? ¿Cómo se alinea esto con la visión general del producto? Una vez que des un paso atrás para ver el valor general del trabajo, finalmente puedes comenzar a crear hitos significativos y rastreables que brinden a los interesados una mejor visibilidad del trabajo y faciliten la priorización.
4. Medir el éxito
Finalmente, los productos más exitosos miden continuamente su éxito. Esto es especialmente importante si deseas tener conversaciones significativas con tus interesados sobre qué construir a continuación e influir en la estrategia del producto. Los indicadores de éxito pueden provenir de la satisfacción del cliente, mayores ventas, uso del producto, etc
Desafortunadamente, para la infraestructura, saber que existes a veces puede significar que algo ha salido terriblemente mal. Entonces, ¿cómo traducir el valor a los interesados cuando tu éxito se basa en problemas que no afectan a tus usuarios finales? Un enfoque excelente es utilizar las cuatro métricas clave para evaluar la salud de tu entrega. Alternativamente, intenta tener conversaciones con tus interesados para establecer los criterios de éxito (idealmente basados en tus hitos) y llegar a un acuerdo sobre cómo realizar un seguimiento de ellos.
Espero que lo anterior te haya animado a probar algunas técnicas típicas de BA. No dudes en pedir consejo a nuestra vibrante comunidad de BA. A nosotros también nos encanta resolver problemas, casi tanto como contarte cómo lo hemos hecho.
Aviso legal: Las declaraciones y opiniones expresadas en este artículo son las del autor/a o autores y no reflejan necesariamente las posiciones de Thoughtworks.