¡Saludos! Mi nombre es Sergey, y soy analista de negocios / sistemas. He estado trabajando en la industria de TI durante aproximadamente 8 años, comenzando con soporte que fluye hacia las pruebas y continuando con análisis: tanto de negocios como de sistemas. Todavía no he trabajado por separado como empresa y como analista de sistemas.En el curso de mis actividades profesionales en general, incluidas las entrevistas de práctica y personales, y en particular las entrevistas con candidatos potenciales, gradualmente llegué a comprender qué habilidades espera el mercado del analista. Habr no vio artículos nuevos sobre este tema durante mucho tiempo, así que decidí preparar el material yo mismo.Para quien, en mi opinión, el artículo será útil:- Analistas principiantes de negocios / sistemas;
- Los analistas que desean continuar bombeando su prof. Habilidades
- Quizás gerentes de reclutamiento.
Debo decir de inmediato que los puntos a continuación son mi visión subjetiva de la especialización del analista , que se formó durante la práctica. Si su empresa ejecuta un scrum completo con un propietario del producto sentado a un metro de usted, con un diseñador y un arquitecto asignados para el equipo, es posible que algunos de los anteriores no estén en demanda.Sin embargo, al menos todas estas habilidades no serán superfluas y harán que el analista sea aún más competente en sus preguntas. Por supuesto, debe comprender que no enumeré todas las habilidades y capacidades del analista (las mismas anotaciones, habilidades comerciales, sql, etc.).Análisis de negocio
- Eliminar requisitos ambiguos en las primeras etapas
Cuando hable con un cliente comercial, debe tener en cuenta que su idioma puede diferir significativamente del suyo. Un requisito comercial puede expresarse de tal manera que varios participantes en el proceso de aprobación tengan una comprensión diferente de lo que significa este requisito. Se genera la ambigüedad, que es muy costosa para el equipo en las últimas etapas de desarrollo.El problema es más grave cuando hay varios clientes comerciales, cada uno de los cuales presenta sus propios requisitos. Por ejemplo, al integrar dos sistemas, cada uno de los cuales tiene su propio representante de la empresa.Estudio de caso: se dedicó un mes de desarrollo a la función de transferir la lista de actividades del objeto No. 1 al objeto No. 2. En la etapa de las pruebas de aceptación, se descubrió que el cliente esperaba una funcionalidad completamente diferente: copiar, no transferir actividades. En el proceso de rehacer la funcionalidad y detallar la ambigüedad, el equipo de TI, en primer lugar, acordó con el cliente sobre MVP y, en segundo lugar, la necesidad de trabajar con la raíz del problema comercial. Se planteó la hipótesis de que la funcionalidad de copia en sí misma solo es necesaria debido a la funcionalidad insuficientemente implementada para cargar plantillas de actividad.
- No tenga miedo de consultar con el cliente sobre los requisitos del requisito
Me encontré con casos en los que trabajaba cuando se describía la declaración de desarrollo sin fijar un objetivo comercial: ¿qué ayudaría exactamente esta conclusión al negocio? ¿Qué dolor aliviará este refinamiento de los negocios?A menudo, tales mejoras sin propósito llevaron a consecuencias desagradables ya en la etapa de prueba, cuando tanto el desarrollador como el probador no entendieron por qué diseñamos esta funcionalidad. Peor aún, el desarrollador y el probador no recibieron respuestas del analista, y si lo hicieron, a menudo se les ocurrió el analista mismo: objetivos que el analista formó por su cuenta.
Escriba los objetivos junto con el cliente, de modo que absolutamente todos los participantes en el proceso en cualquier momento entiendan por qué están haciendo su trabajo.- Exija la asistencia de sus clientes a las reuniones de negocios.
En la práctica, me encontré con diferentes clientes, algunos de los cuales no estaban listos de inmediato para invitar al analista a sus reuniones fuera de línea. El analista también tendrá que trabajar con esto: acordar y mostrar el resultado de una colaboración bien coordinada., — UX- — « », , . : , , windows-, . , .
Muchos analistas, incluyéndome a mí, en el proceso de formulación de requisitos, enfrentados a una fecha límite difícil, utilizaron la siguiente técnica: escribieron una carta a los participantes del proceso con una fecha límite en la cual la carta debería ser respondida y los requisitos acordados / comentarios deberían hacerse. De lo contrario, los requisitos se reconocerán automáticamente según lo acordado.Como ha demostrado la práctica, no hay nada bueno en este enfoque. Está claro que, trabajando del lado del vendedor y teniendo un acuerdo a mano, debe recurrir a tales métodos, pero aún así tratar de evitar el consentimiento tácito, tratar de entender por qué los participantes no quieren darle una respuesta en este momento y resolver el problema lo antes posible.Es mejor documentar por escrito el hecho de que no se recibió la respuesta de tales personas y usted ve los siguientes riesgos para el proyecto en esto. Sin embargo, el proceso de trabajo no puede detenerse, por lo tanto, se ve obligado a continuar su trabajo analítico, mientras que los riesgos previamente definidos deben ser claros para todos los participantes en el proceso.En el proceso de desarrollo de la integración de los dos sistemas, el director se enfrentó con la formación de requisitos que cubrían las acciones de los usuarios en los dos sistemas, pero la falta de coordinación explícita de estos mismos requisitos del jefe inmediato de la unidad, cuyos empleados eran usuarios del sistema.
Como resultó más tarde, el jefe de la división no entendió en absoluto por qué todas estas mejoras y cómo ayudarían a optimizar los procesos en su área de responsabilidad.
A menudo, los participantes en el proceso de aprobación simplemente tienen miedo de poner su firma, porque no entienden completamente ciertas secciones del proceso comercial actualizado. Su tarea como analista de negocios es eliminar este malentendido.
- Introducir el área temática a los desarrolladores.
Dedique unas horas, pero infórmeles a sus desarrolladores sobre el cliente, los procesos comerciales actuales, los problemas y los planes de desarrollo. Como regla general, los desarrolladores bien motivados no solo hacen su trabajo perfectamente bien, entienden para quién están escribiendo el código, sino que también hacen una valiosa contribución: ofrecen optimización, soluciones alternativas, están más dispuestos a hacer preguntas aclaratorias.Si es necesario (y falta de scrum), atraiga al cliente a dicha reunión. Como regla general, los representantes comerciales aceptan voluntariamente tales iniciativas.- Enseñe al cliente a responder la pregunta "¿Qué?" En lugar de formular requisitos en el formato "Cómo"
El cliente no debe formular un requisito de negocio / usuario desde la posición "Cómo": necesitamos un botón en esta pantalla para generar un informe; necesitamos un enlace a un sistema externo en esta sección; etc.En la etapa del análisis inicial del proceso, antes del diseño en sí, el cliente no debe ofrecer una solución.En cambio, enséñele al cliente a formular el problema, su "dolor": necesitamos generar un informe semanalmente, que es complementado manualmente por un empleado y enviado a la gerencia; En el proceso de trabajar con el cliente, necesitamos analizar información adicional, y dado que no está disponible en el sistema CRM, tenemos que abrir una nueva pestaña en el navegador e iniciar sesión en el sistema adyacente.Habiendo aprendido el dolor del cliente, usted, como especialista, puede ofrecer opciones para optimizar el proceso y su automatización. Por ejemplo, envíe automáticamente el informe generado al correo del empleado, guarde al empleado del trabajo manual con el informe en principio, descargue automáticamente los datos de un sistema adyacente a CRM, y así sucesivamente.En muchos casos, este enfoque se enfrentará a la realidad: plazos y prioridades. Pero usted, en cualquier caso, honestamente lo intentó.
- Asegúrese de dividir a los usuarios en clases
Al aceptar los requisitos del usuario del sistema, sin falta, tenga en cuenta su papel en el proceso de negocio. En la práctica, a menudo hay casos en los que el jefe del departamento forma los requisitos para la función con la que trabajará un empleado ordinario.Divida a los usuarios del sistema en roles, y la funcionalidad que se agudiza para un rol, no se "difumina" bajo otro rol.Una vez, dentro del marco del Sistema, implementamos la visualización de una lista de transacciones con clientes.
Se suponía que tanto los gerentes como los empleados comunes trabajarían con la lista. Desafortunadamente, el cliente no pudo entender la necesidad de dividir la parte de la interfaz de usuario de la revisión en dos listas / pantallas: una lista es para el gerente con fines de análisis y control, la segunda lista es para el empleado con el fin de llevar a cabo actividades operativas.
El resultado fue un cierto monstruo, que posteriormente tuvo que ser finalizado y finalizado.
Aplique las mejores prácticas de UX: resuelva personajes - modelos de usuario. Convencer al cliente para que separe los requisitos de cada personaje.- Usar activamente una lluvia de ideas analítica
Es posible en conjunto con el segundo analista, es posible en conjunto con el diseñador UX. En el proceso de asalto, intente con dos roles: una persona primero genera muchas ideas, factible y no muy, la segunda critica estas ideas, las descompone, las escribe, las piensa; luego cambie de roles y haga el mismo trabajo.Como muestra la práctica, este enfoque acelerará significativamente el proceso de compilación de requisitos funcionales y mejorará su calidad. Pero hay una dificultad en que ambos especialistas deben estar en el contexto de la tarea.- Si estás atrapado en Cascada, no te desesperes y avanza hacia Scrum
En una de las compañías, literalmente en un año, nuestro equipo logró transferir el proceso de introducir mejoras desde el bien establecido a nivel de gerentes gerentes a Waterfall a algún tipo de Scrum. Sí, los plazos "claros" para la gran cantidad de pedidos pendientes, que el cliente exigía constantemente al equipo de TI, se estaban retrasando, mientras que la retórica se mitigaba gradualmente a través de lanzamientos de dos semanas, soluciones MVP y una respuesta rápida a los cambios.- Nunca demonizar al cliente.
Sí, hay todo tipo de clientes. Hay quienes están literalmente furiosos. Sin embargo, un analista de negocios debe resolver este problema por su cuenta o con la participación de un gerente y en ningún caso debe sacar una "pelea fuera de la cabaña" - en el equipo.El equipo debe estar bien motivado para trabajar, y el papel de un analista de negocios en el proceso de formación de motivación es una de las claves.Seriamente. Cuando en el proceso de comunicación con el cliente, escucho inserciones verbales absurdas de mi colega analítico, cuando mi colega analítico interrumpe al cliente sin escucharlo hasta el final, quiero enviarlo a cursos sobre negociación o ética elemental.Intenta escuchar al interlocutor y escúchalo.- Deshágase de las palabras parásitas
Trate de evitar palabras parásitas y menos "muu" en las conversaciones. Al principio es difícil, pero, créanme, es doblemente difícil para el cliente escuchar a un analista que no puede expresar sus pensamientos clara y claramente. Un parásito puede verse afectado por un desarrollador, diseñador, probador, pero no por un analista de negocios que conecta al equipo de TI con el negocio. :
- " ".
- ", : ".
Analítica del sistema
- Al configurar la tarea al frente y atrás, intente describir el diagrama de secuencia
O, en ruso, diagramas de secuencia. Los diagramas demostrarán ser útiles incluso no desde el punto de vista del desarrollo, sino desde el punto de vista de la verificación de sus propios requisitos. Muy a menudo, cuando describía un flujo de mensajes, identificaba "agujeros" en mi propio proceso. Por ejemplo, una API irrelevante.Para "dibujar" rápidamente una secuencia de diagramas, use el complemento PlantUML para Confluence. Me pareció que es más rápido escribir código que ajustar la ubicación de bloques y flechas con bolígrafos. Pero todos en esta parte tienen su propia experiencia y sus propias preferencias.
En términos de análisis, el Editor Swagger le permite cerrar sus propios agujeros en los requisitos. En algún lugar se perdieron el atributo, en algún lugar se olvidaron de crear una tarea en JIRA para finalizar la base de datos. No intente memorizar la sintaxis de Swagger, sino cree plantillas para diferentes tipos de API (directorios, filtros, etc.) para simplificar su vida en el futuro.
- Utilice activamente la herramienta de desarrollador en el navegador de destino para analizar las solicitudes de los clientes y las respuestas del servidor
En primer lugar, durante el proceso de aceptación inicial, puede verificar la API que usted mismo describió. A veces es más rápido verificar algunas de las mejoras mediante solicitudes salientes que mediante la interfaz de usuario, a fin de comprender la raíz del problema en una etapa temprana.Usted, como analista, necesitará mucho menos tiempo para verificar la implementación del desarrollador: datos salientes, datos entrantes, el resultado en la interfaz de usuario.
En segundo lugar, puede verificar la secuencia de llamada correcta. Después de todo, usted mismo lo describió en el marco del diagrama de secuencia.Este enfoque permitió a nuestro equipo llevar a cabo mejoras bastante complicadas a los bailes de graduación como parte de los sprints sin demora. :
- " JavaScript". JSON, , HTML, http / https, .
- . , . " . , , ". , , , .
Adicionalmente
- Sumérgete en la experiencia de usuario
Puede que incluso le guste y quiera evolucionar hacia el análisis de UX. En cualquier caso, estudiar la literatura relevante y las herramientas de diseño se beneficiarán al menos desde el punto de vista de encontrar un lenguaje común con el diseñador UX de su equipo.A menudo, los requisitos que usted, como analista, detalla y anota, posteriormente serán ajustados por el diseñador. Después de todo, no está solo, de hecho, está diseñando la experiencia del usuario.Para estar en la misma longitud de onda, practique su análisis UX. Por ejemplo, en su tiempo libre en Sketch o Figma, de vez en cuando muestra el resultado a su diseñador. Tal experiencia analítica nunca será superflua. :
- " ".
- " ".
- ". ".
- ". ".
*** ¡Gracias por leer el artículo! Estaría agradecido, primero, por los comentarios. En segundo lugar, para recomendaciones sobre literatura, fuentes, mejores prácticas, experiencia personal y recomendaciones.