Cada uno de nosotros debe haber escuchado la misma pregunta de nuestros padres o amigos que no de la "fiesta del programador": "¿Qué estás haciendo allí?"
Por lo general, después de un intento de respuesta, sigue un comentario sin cambios: "Oh, programador, ni siquiera puedes arreglar el refrigerador". ¿Qué podemos decir sobre los analistas de negocios que realmente no pueden explicar a sus colegas lo que están haciendo?
Yo mismo a menudo escucho esta pregunta de mi padre, pero aún así no puedo encontrar la respuesta correcta. Y la verdad es lo que hacemos en el trabajo: ¡lo analizamos!
¿En qué gasta el tiempo un analista de TI?
Especialmente para este artículo, tuve que profundizar en los archivos de JIRA de los últimos tres lugares de trabajo. No puedo garantizar una precisión absoluta (sí, tampoco me gusta pintar todas mis clases hasta el último minuto), pero la imagen general realmente coincide con mis propios sentimientos de las tareas realizadas.
La distribución aproximada del trabajo se puede describir de la siguiente manera:
- Reuniones - 20%
- Documentación - 30%
- Trabajo en equipo: 25%
- Prueba - 5%
- Viajes de negocios - 5%
- Autodesarrollo - 15%
Y aquí está el número exacto de horas en los últimos 3 meses:
Como puede ver, la imagen es muy similar. Pequeñas diferencias (la ausencia de viajes de negocios y las largas horas de trabajo con el equipo) surgen debido al cambio reciente en el lugar de trabajo y, en consecuencia, el proceso de integración en el nuevo entorno.
Ahora veamos cada elemento con más detalle.
Reuniones
Comencemos con lo más importante, con lo que, de hecho, comienza el análisis comercial, con las reuniones de negocios, que incluyen reuniones con clientes y reuniones internas con el equipo.
En primer lugar, este es el análisis del área temática y la recopilación de requisitos. Es aquí donde descubrimos qué quiere el cliente que hagamos, qué problemas tiene, ofrecemos las primeras ideas para la implementación y juntos elaboramos un plan preliminar del proyecto.
Otros elementos importantes de las reuniones con los clientes son la discusión del trabajo completado, la planificación del cambio, las presentaciones y los entrenamientos donde decimos cómo usar el producto propuesto.
Quizás las reuniones son la base de nuestro trabajo, ya que proporcionan a los analistas y sus equipos más tareas, por lo que vale la pena prepararse para ellas con mucho cuidado.
Trabajar con documentación
Yo diría que si el analista no está en la reunión, entonces él está sentado y trabajando con la documentación. No me malinterpreten, esto no significa que solo necesiten tocar estúpidamente el teclado, por el contrario, es aquí donde deben usar todas las capacidades de nuestro intelecto, esta parte es la que requiere más trabajo.
Estos son solo algunos ejemplos de lo que tiene que lidiar regularmente:
- La especificación de requisitos es la transformación de un vuelo libre de los pensamientos del cliente en un documento estructurado que describe claramente lo que el equipo debe hacer. Más tarde, este documento se aprueba con el cliente y forma la base del proyecto en curso.
- Solicitud de cambio (Solicitud de cambio): el proceso iniciado por el cliente en caso de que se requieran cambios en el producto después del inicio del desarrollo o incluso después de su finalización. El documento describe qué parte del sistema y cómo debe modificarse, contiene una evaluación del desempeño del trabajo en tiempo y costo.
- Manual de usuario y otros materiales de capacitación: es obvio que después del final del proyecto, debe escribir documentación para el cliente, que describirá cómo usar el sistema, brindará consejos y respuestas a preguntas comunes.
Cada analista tiene su propio juego de herramientas favorito para trabajar con documentación: a alguien le gusta dibujar diagramas y alguien escribe un lienzo de texto en Word. En cualquier caso, le aconsejaría que se familiarice con los conceptos básicos de UML, BPMN, los conceptos de Historias de usuarios y Criterios de aceptación. Es probable que se encuentren en todos los empleadores.
Trabajo en equipo
En mayor medida, para el equipo es el analista, la voz del cliente. En cualquier situación incomprensible, acudirán a él con las preguntas "¿Qué se entiende aquí?" y será con él que confirmarán si el cliente lo quería.
Siempre digo que los analistas de negocios en TI desempeñan el papel de una especie de puente entre los desarrolladores y las empresas, pudiendo hablar simultáneamente los idiomas de los clientes y programadores. En el trabajo diario, tenemos que discutir conjuntamente los requisitos, planificar y distribuir tareas, y responder las preguntas actuales de los programadores.
A menudo sucede que un analista de negocios pasa mucho tiempo con cada miembro del equipo y desempeña un papel peculiar como subdirector. En mi práctica, incluso ha habido casos en los que un gerente vino a mí para discutir cuál de los colegas debería dar un premio y quién no.
Prueba
Es obvio que, lo mejor de todo, entendiendo los requisitos del cliente, tendremos que verificar los resultados del trabajo de los programadores.
Se espera que un analista de negocios ejecute las llamadas Pruebas de aceptación del usuario: pruebas de aceptación del usuario. Nadie necesita escribir scripts automatizados o verificar los tamaños y colores de los botones en el sitio. Todo lo que se requiere es presentarse como usuario y aprovechar el producto terminado. Compruebe si existen inconvenientes al usarlo, si el sistema funciona en general como el usuario lo desea, si hay errores obvios o inconsistencias con los requisitos.
Un punto importante! Debe recordarse que los analistas pasan todo el tiempo con el equipo, participan en debates y conocen los diversos "hacks" y cuellos de botella del programa. Al mismo tiempo, al realizar pruebas, debemos entender que el cliente no tiene este conocimiento, no sabe dónde hacer clic y dónde no. Es absolutamente necesario evaluar el sistema con una mente abierta y señalar todos los errores a los desarrolladores: cuanto antes se puedan identificar, más fácil será solucionarlos.
Autodesarrollo
Dicen que para mantenerse al día con todas las nuevas tecnologías en programación, necesita aprender nuevos marcos casi todos los días, probar nuevas versiones de sus idiomas favoritos y seguir las mejores prácticas de todo el mundo.
Afortunadamente, los fundamentos del análisis empresarial no cambian con tanta frecuencia. Sin embargo, como dije en mi último artículo, para sobresalir de la multitud de analistas de negocios, debes ser el especialista más desarrollado.
También necesita monitorear los cambios en TI, debe desarrollar sus habilidades blandas, aprender la gestión empresarial, los conceptos básicos de las finanzas, comprender las áreas temáticas de los clientes, etc. En general, resulta que a menudo necesitarás aún más tiempo para entrenar que otros programadores.
En conclusión, le daré consejos sobre el autodesarrollo: acepte su necesidad y hable con su líder. Para el desarrollo empresarial, es de vital importancia no meterse en el marco de los procesos establecidos, porque mañana aparecerá un nuevo cliente y un nuevo proyecto desde una esfera completamente diferente. Un analista de negocios debe poder acostumbrarse rápidamente a un entorno cambiante y prepararse para trabajar con una nueva área temática. Es aquí donde todo el tiempo que pasó expandiendo sus horizontes lo ayudará.