En este artículo, trataré de hablar sobre la profesión de analista de negocios para principiantes y para aquellos que desean comenzar su carrera.
Sin experiencia en este campo, puede hacer una pregunta razonable: "¿Cuál es la diferencia entre un analista de negocios y un analista de sistemas?" Intentaron encontrar la respuesta a esta pregunta muchas veces en Habré, nadie tiene una respuesta inequívoca, pero hay muchos buenos artículos.
Uno de ellos: analista de negocios y analista de sistemas en TI. Entendemos las variedades.
Introducción
He estado trabajando como analista de Oracle Siebel CRM durante más de 3 años, durante más de un año he estado preparando pasantes para las duras realidades de los días hábiles. Como regla general, mi estilo de aprendizaje consiste en pequeñas conferencias introductorias y la utilización inmediata del aprendiz para tareas reales con control de calidad.
En las condiciones de autoaislamiento, enfrenté un caso interesante: mientras trabajaba como consultor para una empresa con estrictos requisitos de seguridad, no tuve la oportunidad de consolidar el conocimiento teórico transferido con la aplicación práctica. Esto me llevó a un desafío muy interesante para el mentor: la necesidad de presentar la teoría de tal manera que minimice los conceptos abstractos para el alumno, preparándolo para problemas reales sin experiencia práctica. Intentaré capturar la experiencia adquirida en este artículo.
¿Qué hace un analista?
Por lo general, cuando respondo una pregunta sobre mi profesión, digo que un analista es un traductor del lenguaje de las humanidades al lenguaje de los técnicos. ¿Pero es todo tan simple en el mundo?
De hecho, el análisis consta de los siguientes pasos:
- Recibir una solicitud de revisión del sistema
- Refinando el resultado deseado que el usuario obtiene al final de su proceso
- Aclaración del proceso de trabajo actual.
- Diseño preliminar de la solución.
- Coordinación con el cliente de pasos adicionales del proceso, si son necesarios para lograr el resultado,
- Corrección de la solución
- Coordinación del proceso con el cliente.
- Registro de especificaciones técnicas para el desarrollador.
- Prueba de los principales escenarios de la funcionalidad.
- Preparación de documentación, redacción de instrucciones para el usuario.
- Transferencia de funcionalidad al cliente.
Aprende más sobre cada paso
Recibir una solicitud de revisión
Como regla, los clientes de modificaciones son personas que están lejos de la esfera de TI. Los requisitos rara vez se sistematizan, se describen clara y lógicamente. Esto es algo que deberá solucionar antes de entregar la tarea al desarrollador.
Aclaración del resultado deseado.
Aquí debe aclarar lo que el cliente quiere específicamente. Puede ser cualquier cosa: cambiar el estado de una aplicación, generar un documento, enviar un SMS o correo electrónico, en general, todo lo que un sistema de TI puede hacer.
Utilice siempre las siguientes pautas en esta etapa:
- Para usted, no debe haber un concepto abstracto único en la declaración del problema del cliente. Si no está seguro de si usted y el cliente tienen la misma comprensión de algunas palabras, asegúrese de llegar a un acuerdo.
- No hay preguntas estúpidas, hay preguntas formuladas y abordadas incorrectamente. El analista no es un experto en todas las áreas del negocio, pero debe poder captar rápidamente una nueva área. No tengas miedo de preguntar.
Aclaración del proceso actual.
Muy a menudo, el proceso de trabajo actual se denomina "proceso TAL CUAL".
Después de completar esta etapa, debe imaginar el proceso como un cuadro negro .
Diseño preliminar de la solución.
Esta etapa implica la definición del proceso futuro o, como dicen, el "proceso TO-BE".
Después de completar esta etapa, su caja negra debe volverse blanca, es decir, debe saber exactamente qué está sucediendo dentro del proceso. Se ve así:
Guíese por los siguientes principios:
Es posible que haya notado que "Entrada 3" aparece en el cuadro blanco. A veces puede encontrar que no hay suficientes datos en el sistema para lograr el resultado. Tomemos como ejemplo algún tipo de certificado sobre la conclusión de un acuerdo entre la empresa del cliente y el cliente, que debería reflejar el patronímico del cliente, que no está almacenado en su sistema. En este caso, debe informar al cliente sobre esto y ofrecer una solución al problema, por ejemplo, agregue el campo "Patronímico" al sistema y asegúrese de que se complete. Para los usuarios, esto significa completar un campo adicional cuando se trabaja con el sistema, que debe acordarse con el cliente.
Corrección de la solución
A veces, la coordinación de nuevos pasos en el proceso tiene lugar con comentarios sobre su decisión del cliente. En este caso, debe corregir la solución propuesta. Pero esto no siempre sucede, lo que significa que eres un buen compañero y has terminado el diseño en el paso "Diseño preliminar de la solución"
Coordinación de procesos.
Después de completar el diseño, el proceso debe ser acordado con el cliente. El formato del acuerdo con mayor frecuencia depende de las realidades de una empresa y un cliente en particular. Estas pueden ser descripciones textuales del proceso, una descripción en la notación para describir procesos de negocios o un acuerdo verbal.
Registro de especificaciones técnicas.
El formato de la tarea técnica también depende de las normas adoptadas en las empresas del cliente y el ejecutor y, a menudo, de la competencia del desarrollador: los desarrolladores sin experiencia necesitan una descripción más detallada del proceso. Durante mi carrera, conocí compañías en las que no había especificaciones técnicas y todo se discutió en un formato libre, pero todas las declaraciones tienen una característica común: debe describir las funciones aritméticas y lógicas definidas en el paso del diseño, en texto o visualmente, en forma de bloque esquemas
Prueba funcional
Anticipando la pregunta, sí, los analistas a menudo hacen pruebas. Pero, por regla general, esta prueba es superficial para asegurarse de que el desarrollador lo entienda correctamente. Por lo general, se limita a pasar por los principales escenarios de trabajo para identificar la presencia de defectos críticos, es decir, errores que no permiten lograr el resultado deseado de ninguna manera. Los especialistas en control de calidad se dedican a la búsqueda de defectos menores y pruebas de funcionalidad en diferentes condiciones.
Documentación
Esta es quizás la etapa menos favorita de la mayoría de los analistas, pero su conocimiento experto de la funcionalidad debe registrarse por escrito. Escriba bien la documentación: el proceso debe describirse con suficiente detalle para que una persona no iluminada pueda entender lo que está sucediendo dentro del cuadro blanco, y lo suficientemente breve como para que pueda leerlo y mantenerse despierto.
Las instrucciones para el usuario son una breve nota para el usuario final de su funcionalidad, en la que las acciones del usuario se describen en pasos. Este tipo de documentación debe consistir en una lista de acciones, no debe contener términos técnicos.
El formato de estos documentos también depende de las normas adoptadas en una empresa cliente particular.
Transferencia de funcionalidad al cliente.
La parte más agradable del trabajo. Aquí muestra el trabajo realizado al cliente, recoge los laureles, se enorgullece del trabajo realizado y se carga de emociones positivas para la próxima tarea.
Salida
El trabajo de un analista implica mucha comunicación, lluvia de ideas y el uso de todas las posibilidades de lógica que la naturaleza le ha dotado.
Si le gusta la sistematización y la optimización, si le gusta que todo sea claro y lógico en la vida, trabajar como analista le dará mucho placer y seguramente alcanzará la cima en su carrera.
Espero que mi artículo te haya ayudado a formarte una impresión sobre análisis y te haya dado a conocer tu camino en la vida. ¡Buena suerte!