No es ningún secreto que los analistas son una de las profesiones más libremente interpretadas y multifacéticas. Y, a pesar de la presencia de hasta dos estándares profesionales, cada compañía describe individualmente el rango de tareas asignadas al especialista que ocupa este puesto. En mi artículo quiero compartir mi experiencia personal y decirle qué roles puede combinar un analista durante un proyecto ordinario, qué tareas cerrar, y también dónde desarrollar si el empleo principal del proyecto se vuelve completamente aburrido.
Espero que mi historia te ayude con sorpresa a descubrir cuáles son tus hermanos en mente, y también resaltar posibles puntos de crecimiento y desarrollo.
Descargo de responsabilidad
Todo lo que se discutirá más adelante es una experiencia puramente personal en un tipo de actividad muy específico, que consiste en el desarrollo e implementación de soluciones personalizadas basadas en un sistema específico con su propia plataforma y lenguaje de programación.
Además, esta actividad está limitada adicionalmente por los detalles del sistema implementado, así como por las tecnologías internas del proveedor que actúan como estándares locales.
Bueno, como guinda del pastel: esta actividad se lleva a cabo en beneficio de la empresa sangrienta. Y cuando hablo de la sangrienta empresa, me refiero a proyectos en empresas muy grandes: casi todo el petróleo y el gas, los principales bancos, industriales, minoristas, etc.
En consecuencia, el analista, que se discutirá en el artículo, es una persona que existe dentro de todo el paradigma mencionado anteriormente. Además, esta es una persona muy real y viva, no importa cuán esférico parezca un caballo en el vacío durante la lectura.
Juegos previos
En general, el tema de la autodeterminación del analista en el espacio es bastante explosivo. Cada vez que surge la pregunta "quiénes son estos malditos analistas al final" en comunidades profesionales, foros, reuniones, conferencias o en salas de chat de telegramas, comienzan feroces alarmas, durante los cuales algunos analistas prueban a otros analistas que cada uno de ellos debería y no debería hacer.
Se vuelve aún más divertido (o más triste) cuando varios eychars o metodólogos comienzan a discutir este tema.
En todos estos holivares, prefiero tomar una posición, cuya esencia radica en una sola palabra: especificidad. En otras palabras, todos deben comprender que el conjunto de funciones y tareas del analista siempre variará enormemente según el empleador, el proyecto y el equipo final.
Quizás te estés preguntando: ¿por qué decidí de repente que podía hablar de eso? Todo es simple Es suficiente enumerar los roles que cambio a lo largo de mi proyecto:
- analista de negocios;
- analista de sistemas;
- Diseñador de UI / UX;
- escritor técnico
- probador
- maestra
- apoyo
Si hablamos de proyectos de mayor complejidad y escala, con un equipo de varios analistas, entre los cuales puede haber principiantes, se agregan roles adicionales:
- mentor
- Jefe de tecnología;
- Jefe de equipo
Y en toda esta variedad de roles, he estado trabajando durante casi ocho años.
El mercado
Sin embargo, comencemos desde lejos. O más bien, con la situación que se ha desarrollado en el mercado en este momento.
Si va, por ejemplo, a un cazador de cabezas y lleva la palabra "analista" a la línea de búsqueda, toda la riqueza de fantasías e interpretaciones sobre el tema recaerá sobre nosotros.
Por supuesto, los analistas ordinarios son los más comunes. Sin ninguna aclaración, lejos del pecado. En la descripción de estas vacantes, puede ver muchas funciones, tareas, responsabilidades laborales y requisitos diferentes para los candidatos.
Algunos empleadores se atreven a expresar la categorización en analistas de negocios y sistemas en sus vacantes y, por lo tanto, prácticamente cavan un agujero para ellos mismos. Ni siquiera se imaginan cuántos analistas fueron asesinados en esta sangrienta batalla.
La categoría simplificada y amplia de analistas de TI es bastante popular. En su descripción, por lo general, todo el campo ruso de experimentos con responsabilidades, limitado, de hecho, solo a la esfera de TI. Estas vacantes me recuerdan la mayoría de las historias sobre los programadores de programación a los que regularmente se les pide que arreglen una aspiradora o un hervidor de agua.
Honestamente, están actuando aquellos que al menos intentan indicar en el título qué exactamente será necesario "analizar". Como resultado, aparecen vacantes completamente diferentes, como "Analista SQL", "Analista de procesos de negocio", "Analista de requisitos", "Analista 1C", "Analista de ventas", "Analista de marketing", etc. Sin embargo, esto no salva la diferencia en las tareas, incluso en vacantes con dos nombres idénticos.
Normas
Parece que el punto en esta historia debería haber sido establecido por estándares profesionales, cuya tarea es precisamente fijar los objetivos de una actividad profesional en particular y proporcionar una descripción exhaustiva de las funciones laborales de un especialista, las acciones realizadas en el marco de su implementación, así como el conocimiento requerido y habilidades
Pero ahí estaba.
Por supuesto, debe alegrarse de que todavía existan estándares, aunque aparecieron hace relativamente poco. El estándar para el analista de sistemas en el otoño tendrá cinco años. Significativamente más tarde, el estándar para el análisis de negocios se endureció: ni siquiera tenía un año.
Es interesante que estos estándares ya estén declarando la diferencia entre una empresa y un analista de sistemas a nivel de códigos de área profesionales: para un analista de sistemas, se indica el código 06, y para un analista de empresas - 08. En otras palabras, un analista de sistemas está clasificado como un profesional en el campo de "comunicaciones, información y comunicación tecnología ", y analista de negocios - en el campo de" finanzas y economía ". Y no hay TI para ti.
Si pasamos a los objetivos de la actividad profesional, consagrados en los estándares, la diferencia será aún más obvia y entretenida. El analista de sistemas, ya que se le refiere a la esfera de TI, se encarga de trabajar con los requisitos con la conciencia tranquila, mencionando el software, los sistemas automatizados, en general, todo lo que amamos. El analista de negocios, a su vez, no trabaja con requisitos, sino con necesidades, pero su objetivo se centra en los cambios en la organización que son beneficiosos. Y, fíjate, ni una palabra sobre sistemas o sistemas de hardware y software.
Al mismo tiempo, una gran cantidad de aquellos involucrados en la creación de varios tipos de productos de software tienen una simple entrada "analista de negocios" en su libro de trabajo. Sin embargo, ¿por qué ir lejos? Personalmente, durante ocho años, a quienquiera que me llamaran, realizaba las mismas funciones. Por lo tanto, para no involucrarme en disputas terminológicas, en la narración posterior utilizaré la palabra más general y neutral "analista".
Misiones
Pasemos a los detalles.
Cualquier proyecto en el que nuestro analista participe de una forma u otra pasa por 4 misiones globales, llamémoslas preventa, anteproyecto, proyecto e implementación. Por supuesto, el analista puede no participar en todas las misiones, pero conectarse de forma aislada con cualquiera de ellas, pero como estamos cambiando al modo superhéroe, hablemos en detalle sobre cada una. Haré una reserva de inmediato; eliminé la escolta como misión de manera bastante deliberada, porque Considero inapropiado mantener un especialista de alto nivel en estas tareas.
Preventa
La primera misión es, por supuesto, preventa.
Vale la pena señalar que no todos y no siempre conectan a los analistas con esta misión, considerando la preventa del feudo de vendedores y gerentes de proyectos. Sin embargo, con el tiempo, los analistas pudieron demostrar su utilidad y viabilidad en esta etapa.
En primer lugar, el analista en preventa es útil, por supuesto, con experiencia. Por otra parte, tanto sujeto como sistema. Cuando viaja con un vendedor a reuniones y demostraciones, el analista habla el mismo idioma con el tema y ayuda al vendedor a eliminar varias situaciones asociadas con el vocabulario y la terminología profesional característicos. Además, al poseer un conocimiento más profundo del sistema que se vende y una vasta experiencia en proyectos, el analista se enfoca de manera rápida y más precisa en las posibilidades de cumplir los deseos del Cliente, además de hablar de manera convincente sobre la experiencia existente para resolver problemas similares.
Después de una serie de reuniones exitosas, el analista comienza a trabajar en forma aislada del vendedor y se va al cliente por su cuenta, realizando un estudio expreso de los procesos, los sistemas existentes que requieren reemplazo, la infraestructura que deberá integrarse, etc.
Los resultados de todas estas actividades son los contornos delineados del futuro proyecto, así como los requisitos técnicos preliminares, según los cuales será posible llevar a cabo una evaluación inicial del tiempo, la mano de obra y el costo del trabajo.
Prediseño
Una vez que se completa la venta y comienzan las medidas organizativas para firmar el contrato y los bailes rituales para inicializar el proyecto, el analista ya no puede permanecer inactivo, sino comenzar el trabajo preliminar.
En esta etapa, es posible que ya tenga a su disposición mucha información para la investigación: estos son los resultados del análisis expreso, y las notas de las reuniones, y los ToR finales a los que se suscribió el equipo, y, con suerte, un montón de diversas normas y reglamentos de clientes, cuyos requisitos deberá tenerse en cuenta en el diseño futuro. En otras palabras, es una montaña de datos no estructurados que debe procesarse y formularse en su cabeza un concepto para una solución futura.
Muy a menudo, esta misión es típica para proyectos a gran escala con un gran equipo. Es en ellos que el analista se convierte en un experto técnico y decide qué, en sentido figurado, construiremos sobre este proyecto: un barco o un avión. También coordina al equipo a lo largo del proyecto, ayudando a elegir las mejores soluciones técnicas y sustantivas, así como asegurando la consistencia del sistema diseñado.
Al sumergirse gradualmente en el contexto del proyecto futuro, el analista dibuja su marco y determina qué componentes aislados condicionalmente se pueden dividir en él. Después de lo cual, ya junto con el gerente del proyecto, distribuye el equipo entre los bloques asignados. Es muy importante tener en cuenta las interconexiones de los módulos del sistema futuro y comprender exactamente qué cantidad de trabajo se puede asignar de forma segura a una unidad independiente.
Después de estudiar toda la información actualmente disponible, el analista construye el concepto de automatización, donde el esqueleto del sistema futuro se proyecta con grandes golpes. Son estas decisiones las que formarán la base de todo el trabajo posterior y establecerán la dirección para que los analistas resuelvan sus problemas locales en bloques independientes. Además, además del concepto, ya pueden aparecer los primeros diagramas de proceso, aún de nivel superior. Muy a menudo, esto es, de alguna manera, un efecto secundario de sumergir al analista en el proyecto, el resultado del análisis de la información disponible. Pero en el futuro, estos diagramas también podrán ser guiados por analistas en los bloques cuando acudan al Cliente para un estudio detallado.
Además, el concepto está estrechamente relacionado con la arquitectura de la solución: aquí el analista ya interactúa con el desarrollador líder, integrando el sistema futuro en el panorama existente del Cliente e identificando los volúmenes de integración y migración requeridos, tanto de inicio como regulares.
Al mismo tiempo, el analista no solo se prepara para el próximo proyecto, sino que también prepara para él un grupo de trabajo del Cliente: aquellas personas que se convertirán en las principales fuentes de requisitos para el sistema futuro en el futuro. El analista mantiene reuniones con el grupo de trabajo y muestra una versión en caja del sistema, prestando especial atención a los módulos y funciones que se verán afectados por la próxima implementación. La tarea principal aquí es sumergir al Cliente en el contexto del sistema para reducir la barrera y lograr una actitud más informada hacia la generación de requisitos. En las demostraciones, el analista "en vivo" muestra cómo los artículos TK se ajustan o se ajustarán al sistema existente. Aquí tienen lugar los primeros puntos de acoplamiento de TK y las necesidades reales del Cliente.
Proyecto
El trabajo principal, por supuesto, comienza directamente en el proyecto. Es en esta etapa que los roles cambian constantemente.
Primero, el analista trabaja estrechamente con el Cliente como analista de negocios. Al mismo tiempo, puede ir ocasionalmente a reuniones y entrevistas, o incluso estar en el territorio del Cliente en modo de tiempo completo. En esta etapa, se lleva a cabo un estudio en profundidad de los procesos de la compañía, se identifican los cuellos de botella y las necesidades de automatización, se proporcionan consultas sobre posibles soluciones a los problemas encontrados. Además, estas decisiones pueden ser no solo sistémicas, sino también administrativas y organizativas. Con base en los resultados del estudio, nacen diagramas detallados y descripciones de los procesos de negocio "tal cual" y "ser", con todas las sutilezas y posibles opciones para el desarrollo de eventos. En el camino, se identifican y recopilan los requisitos para los objetos del sistema futuro.
Cuando se recopila la información, el analista de negocios se transforma en un analista de sistemas, colocando los requisitos del Cliente en las capacidades de un sistema en particular. En esta etapa, se lleva a cabo el diseño de los módulos del sistema, mientras que un analista experimentado evalúa de forma independiente la viabilidad de implementar un requisito particular y busca formas de evitar posibles limitaciones de la plataforma. Sin embargo, la falta de experiencia siempre se puede compensar consultando con el desarrollador principal del proyecto.
En la misma etapa, el analista se convierte en diseñador, diseñando y dibujando diseños de futuras interfaces del sistema. Es importante tener en cuenta no solo el componente visual, sino también los postulados básicos de UX, así como la lógica de los procesos en los que participarán los objetos diseñados. Tarde o temprano, todas las formas de pantalla tendrán que formar una única imagen lógica y armoniosa, y el sistema tendrá que responder igualmente a acciones idénticas del usuario.
Una etapa separada es el diseño de todo tipo de integraciones y migraciones. Todo depende de la experiencia del analista y las competencias de su sistema. En general, el analista debe comprender el lugar del sistema en el panorama general y tener una buena idea de su interacción con otros sistemas del Cliente. Esta interacción debe describirse al menos a nivel de entidades superpuestas, reglas para datos transmitidos y mapeo de detalles. La parte técnica del diseño generalmente la realiza el desarrollador.
Después de diseñar todas las soluciones, el analista se convierte en un escritor técnico y escribe un documento grande y hermoso que proporciona una descripción detallada del sistema futuro. Este documento incluye esquemas previamente desarrollados y descripciones de procesos e interfaces, con una descripción detallada de la lógica aplicada de los elementos y otras descripciones de modificaciones que deben realizarse en el sistema para implementar las soluciones diseñadas. Aquí la analítica es ayudada por la estructura verificada del documento y las plantillas preparadas que le permiten no perderse nada.
Después de completar la fase de documentación, el trabajo fundamental se somete al menos a dos revisiones: el analista líder y el desarrollador líder del equipo. Y si es posible, también una revisión externa por colegas de otros equipos y proyectos. Después de revisar el documento se envía para su aprobación al Cliente. Además, no recae sobre él en un Talmud de varias páginas incomprensible, sino que se muestra primero en forma de una presentación con explicaciones, canciones, bailes e imágenes divertidas. Además, el analista acompaña el proceso de aprobación, respondiendo las preguntas del Cliente, corrigiendo ciertas formulaciones y, si es necesario, otros requisitos y soluciones. Después de completar con éxito la aprobación, el documento se envía al desarrollo.
En este momento, nuestro analista tiene un ligero respiro. En el curso del desarrollo, él, por supuesto, está conectado al trabajo en el proyecto, pero con una carga notablemente menor. Sus tareas son principalmente respuestas a preguntas de desarrolladores y actualizaciones periódicas de requisitos con el Cliente.
Cuando se completa el desarrollo, el analista se convierte en un probador y realiza una prueba larga, reflexiva y rigurosa de las soluciones desarrolladas. Notaré de inmediato que estamos hablando de pruebas de usuarios, pero esto no significa que sea superficial. Cada botón está marcado, cada ventana, cada rama de ruta, se crean todos los formularios de informes, se inician todos los scripts. Al mismo tiempo, las pruebas se dividen en dos grandes etapas. El primer paso es verificar las funciones básicas. Todo aquí debería funcionar tal como está escrito en la documentación, y como si un usuario experimentado y con conocimiento estuviera sentado en la computadora. Después de que se hayan verificado todos los escenarios de uso positivo, el analista comienza a "romper" el sistema y probarlo desde la perspectiva de un usuario inexperto que es demasiado vago como para leer las instrucciones. También me gustaría llamar la atención sobre el hecho de que en esta etapa, puede haber un mayor refinamiento de los requisitos y la finalización de las decisiones. Cuando la prueba finalmente se complete, estamos listos para la próxima misión.
Implementación
En esta etapa, el analista participa en la implementación y configuración del sistema en los servidores del Cliente. Inicialmente, se establece un circuito de prueba en el que el grupo de trabajo, junto con el equipo del proyecto, llevará a cabo la prueba final de la solución. Para garantizar esta prueba, el analista escribe casos de prueba, considerando qué escenarios deberá realizar el Cliente para cubrir el máximo de funciones durante un período de prueba limitado y convencer al grupo de trabajo de que todo funciona como debería.
Por supuesto, la fase de prueba nuevamente conduce a un ciclo de especificación de requisitos, mejoras del sistema y pruebas repetidas, pero los deseos inagotables del Cliente deben estar significativamente limitados por el tiempo y la mano de obra, tratando de tomar solo los momentos más críticos en el trabajo. La tarea principal es poner rápidamente en funcionamiento a los usuarios en vivo, sin importar cuán inhumano pueda sonar.
En esta etapa, el analista se convierte en un entrenador, educando a los usuarios comunes del sistema futuro. La capacitación se puede realizar de varias maneras: cursos de tiempo completo con tareas prácticas y certificaciones finales, seminarios, seminarios web, videos, screencasts, etc. Las instrucciones para el usuario están escritas en paralelo (aunque en general, su desarrollo comienza en la etapa de prueba interna).
, , , . , – , .
, , , . , , , .
, , .
Bonus-level
, , .
– . 3-4 . , , , , .
, , . , , .
– . . – .
– , , ..
, , - , , .
Epic-fail
, . . – overqualified.
. , , . , , .
, -. , , , . , . – , . . , .
, . – !