10 prácticas recomendadas para un analista empresarial de Salesforce

El analista de negocio de Salesforce tiene un papel único y crítico en cualquier organización – porque el analista de negocio se sitúa entre las partes interesadas del negocio y los constructores técnicos, y gobernará la experiencia del usuario (UX);

El BA tiene muchas responsabilidades, una de las principales es obtener los requisitos de las partes interesadas en relación con el estado futuro deseado para las mejoras, la experiencia del usuario, y la adopción. El BA entonces necesita traducir esos requisitos en Historias de Usuario para que el equipo de construcción los entregue. Esta guía proporciona las mejores prácticas para el analista de negocio de Salesforce.

Antes de continuar, quiero destacar que dependiendo de la organización, las funciones del analista de negocio de Salesforce a veces las realiza el administrador del sistema de Salesforce. Esto es menos común ahora, ya que cada vez más organizaciones tienen personas separadas que realizan la administración del sistema y el análisis empresarial. Dicho esto, estas prácticas recomendadas se aplican a cualquier persona que realice las funciones del analista de negocio de Salesforce.

1. Comprenda el estado actual de Salesforce. Comprender el estado actual de Salesforce

• Conozca la interfaz de la instancia de Salesforce de su organización: Una práctica recomendada del BA es conocer quién utiliza el sistema Salesforce, cómo lo utilizan y las diferentes personas que utilizan Salesforce. El BA también debe saber qué nubes de Salesforce se utilizan en la organización (Sales Cloud, Service Cloud, Marketing Cloud, Experience Cloud, otras) y qué grupos de usuarios las utilizan
• Utilice Salesforce Optimizer: esta herramienta nativa puede ayudar con el análisis del estado actual. Con Optimizer, el BA puede ver información de uso, por ejemplo, como Usuarios móviles, además de otra información. Para acceder a Optimizer, vaya a Configuración de Salesforce [Configuración de Salesforce Optimizer].
• Realizar un análisis del estado actual
• Realice una auditoría de configuración: para familiarizarse con la configuración del back-end de la organización, es una buena práctica revisar manualmente los perfiles, conjuntos de permisos, grupos de conjuntos de permisos, diseños de página, automatizaciones (flujo, etc.), configuración de uso compartido y OWD.
• Configuración de Salesforce [Salesforce Setup Optimizer]
• Usuarios en la sombra: Observe cómo interactúan los usuarios con Salesforce en su trabajo diario y tome notas. Comprenda lo que hacen en Salesforce y cuáles son sus puntos débiles. Intente seguir a los usuarios en diferentes funciones de la organización
• Documentar el estado actual: Utilice una herramienta de su elección.

Requisito para ser un BA de Salesforce Rockstar

• Necesidad de comprender las capacidades de Salesforce: si el BA no es un administrador certificado de Salesforce ni tiene años de experiencia con Salesforce, debe adquirir las habilidades necesarias.
• Si el BA no es un administrador certificado de Salesforce ni tiene años de experiencia con Salesforce, debe adquirir las habilidades necesarias

2. Comuníquese con las partes interesadas

• Documentar quiénes son las partes interesadas y desarrollar relaciones: En primer lugar, el BA necesita que le digan o averiguar quiénes son todas las partes interesadas que el BA está apoyando. A menudo habrá partes interesadas de una variedad de grupos, como Ventas y Servicio, además de partes interesadas en diferentes niveles de la empresa, como el vicepresidente de un departamento o un líder de equipo en las trincheras
• Construir confianza: Una de las mejores prácticas para el BA es generar confianza con las partes interesadas, siendo transparente y receptivo. Establezca una comunicación abierta y programe reuniones individuales con cada una de las partes interesadas. Familiarícese con el papel de cada parte interesada en la organización y las ventajas que desean obtener de Salesforce. Si hay muchas partes interesadas, el BA debe crear un mapa de partes interesadas
• Programe reuniones periódicas con las partes interesadas: Dependiendo de cuántos equipos o proyectos diferentes esté apoyando el BA, estas podrían ser reuniones separadas para diferentes grupos de partes interesadas (es decir, Ventas, Servicio, etc.). Reunirse al menos dos veces por semana es una buena práctica. Utilice vídeo para las reuniones a distancia, no sólo audio. Invite al Propietario de Producto a las reuniones recurrentes en las que se discuta la priorización.

<li

• Configurar MS Teams/Canales Slack con las Partes Interesadas: Configurar estos canales es una mejor práctica y permitirá comunicaciones a grupos donde se puede compartir información y preguntas. El BA probablemente tendrá que configurar varios canales en función de quién necesita estar en el bucle para los diferentes departamentos o proyectos. 

3. Reunir los requisitos de las partes interesadas – Estado futuro

• Entender el Estado Futuro Deseado – el Quién, el Qué y el Por Qué: Una vez que el BA determina quiénes son las partes interesadas correctas para las diferentes áreas del negocio, las partes interesadas tendrán solicitudes de mejora, lo que hará necesario que el analista de negocios obtenga los requisitos.
• Reunir estos requisitos es tanto una habilidad como un arte, con el objetivo de determinar el «Quién» (qué Usuarios necesitan algo), el «Qué» (qué necesitan) y el «Por qué» (por qué razón se está solicitando esto).
• Entender el Estado Futuro Deseado – Quién, Qué y Por qué
• Preguntar al analista de negocios sobre el Estado Futuro Deseado

Haga las preguntas correctas para conectar los detalles

• Entender el «qué»: Pida a las partes interesadas del negocio que le expliquen lo que están buscando y escuche atentamente, haciendo preguntas para obtener más claridad. Pídales que se lo muestren en Salesforce, si es posible.; Los requisitos deben ser medibles (es decir, no «más bonitos»).;Cada requisito debe poder describirse en una frase.;
• Entender el «Qué»: Pida a los interesados que le expliquen lo que buscan y escuche atentamente sus preguntas
• Entender el «Por qué»: Hacer que los Stakeholders del negocio expliquen por qué necesitan lo que están pidiendo.

;Esto es importante porque si el analista de negocio entiende por qué se está solicitando algo, puede ayudar mejor en todos los aspectos de la solicitud.

;Esto incluye proporcionar orientación a los Stakeholders, y explicar al equipo scrum por qué se está solicitando algo.

;Esto incluye proporcionar orientación a los Stakeholders, y explicar al equipo scrum por qué se está solicitando algo.

;Esto incluye proporcionar orientación a los Stakeholders, y explicar al equipo scrum por qué se está solicitando algo

• Necesidad de determinar qué características son «Must Have Now» – el Producto Mínimo Viable (MVP): Muchas características pueden y deben añadirse en iteraciones posteriores. Este es uno de los principios clave de Agile, que se analiza en las secciones siguientes.
• Proceso de desarrollo
• Mapeo de procesos/Prototipado: Para solicitudes de mejora grandes o complejas, las mejores prácticas incluyen: organizar una reunión con las personas adecuadas en la sala para una sesión de trabajo de mapeo de procesos, desarrollar el mapa de procesos basado en las necesidades del negocio, desarrollar pasos nuevos/mejores, ser claro y obtener comentarios. Discutir el MVP.
• Utilizar buenos patrones de diseño, y crear wireframes.
• Discutir el MVP
• Whiteboarding: ya sea virtual o en persona. Esto es útil para una lluvia de ideas, enumerar los requisitos o visualizar los pasos de un proceso o flujo de datos.
• Puede crear un wireframe
• Podría desarrollar POCs directamente en Salesforce: Los BAs pueden utilizar la org de un desarrollador y configurar Salesforce para mostrar cómo se verían y funcionarían ciertas mejoras
• Una reflexión final sobre lo que realmente se necesita o es negociable: normalmente hay una especie de negociación sobre las prioridades, especialmente cuando un proyecto es grande. Recuerde a las partes interesadas que el equipo añadirá funciones cada pocas semanas, así que comience por los elementos más importantes. Tampoco está de más añadir una ganancia rápida fácil

4. Entender los principios clave de la metodología «ágil»

El BA a menudo trabajará dentro de un marco «Ágil», que es una metodología para gestionar proyectos que enfatiza la flexibilidad, el desarrollo iterativo, la colaboración y la mejora continua.La mejor práctica para un BA es aprender la metodología ágil y seguir sus principios clave.

Principios clave de Agile

• Desarrollo iterativo/entrega incremental: la mejor práctica es añadir mejoras incrementales durante cada sprint (que a menudo comienzan y terminan cada dos o tres semanas), culminando con una liberación a Producción desde UAT al final de cada Sprint.
• Los principios clave de Agile son los siguientes
• Colaboración: Con las Partes Interesadas, el Propietario del Producto y el Equipo Scrum.
• Todos deben estar en la misma página
• Adaptabilidad: A medida que cambian los requisitos o las prioridades, Agile puede adaptarse y los Propietarios de Producto/Analistas de Negocio pueden volver a priorizar el backlog (o incluso añadir historias al sprint actual, si es urgente). Por supuesto, no es una buena práctica añadir historias a mitad del sprint, pero es posible. Te aseguro que el Scrum Master no estará encantado, y esto puede requerir mover una o más historias del sprint actual a un sprint futuro.

<li

• Mejora Continua: El equipo y el producto siempre están mejorando. «Getting better all the time» (Los Beatles).
• Mejora continua: El equipo y el producto siempre están mejorando
• Scrum: la mejor práctica es que el BA entienda Scrum, ya que Scrum es el marco Agile más popular en el ecosistema de Salesforce, con entregables y plazos bien definidos. Utiliza iteraciones de duración fija denominadas sprints, además de funciones y ceremonias definidas como una reunión diaria de preparación, refinamiento y planificación de sprints (consulte las ceremonias en la siguiente sección). Este es el marco del que he formado parte en múltiples organizaciones a lo largo de los años.
• Kanning
• Kanban: Este es otro marco Ágil a tener en cuenta, que se centra en visualizar el trabajo y limitar el trabajo en curso. También utiliza un tablero Kanban para realizar un seguimiento de los problemas. He visto que este marco está siendo utilizado por algunos equipos, ya que tiene sus casos de uso, como un equipo de Operaciones que tiene un flujo de trabajo constante y continuo.
• Kanban

5. Participar en ceremonias ágiles

• Planificación Trimestral: El BA debe trabajar con el Propietario de Producto y los Interesados para preparar con tiempo la planificación trimestral, idealmente con semanas de antelación. El equipo debe comenzar a «stub out» Epics e Historias de Usuario, y colocarlas en futuros Sprints en el Backlog.
• Reunión diaria: Llegue a la reunión diaria de standup a tiempo, preparado para responder a las preguntas que el equipo de construcción tiene con respecto a las historias en el sprint actual. Menciona otros elementos clave del día anterior, y discute cualquier bloqueador. Este es también un buen momento para traer a colación bugs de producción o preguntas para el equipo de scrum. Algunas organizaciones tienen un canal Teams/Slack útil llamado «parking lot» para el final del standup diario, para esos elementos adicionales a discutir con el equipo. Pregunte a su Scrum Master acerca de la adición de uno!
• Pre-Refinamiento: Durante el pre-refinamiento, el BA revisará las Historias de Usuario que han comenzado a redactar.
• Este es un buen momento para que el BA discuta los detalles de la historia y posiblemente discuta las opciones de solución con los Desarrolladores y Administradores, centrándose en los requisitos.
• El BA también debe traer a colación cualquier dependencia durante el pre-refinamiento y codificarlas en la historia.
• Pre-refinamiento

Nota: No todas las historias requieren pre-refinamiento (ya que algunas historias son sencillas).;El BA debe revisar las historias con el equipo scrum que ameriten discusión.;

Aunque la «solución» (el «cómo») debería dejarse generalmente en manos del equipo de construcción, en mi experiencia el BA debería discutir con el equipo de construcción ciertas historias durante el pre-refinamiento, ya que el BA sabe lo que las partes interesadas quieren idealmente, o las opciones que probablemente serían aceptables para las partes interesadas.

Si resulta que el BA tiene años de experiencia en Salesforce y conoce la fontanería de Salesforce, el BA está en una posición única para añadir valor a la conversación de solución;

• Refinamiento: Aquí es donde el BA típicamente lee a través de las Historias de Usuario planificadas para el siguiente sprint (explicando el «quién», «qué» y «por qué» al equipo scrum). Trata de ser claro y pintar un cuadro de lo que se necesita. Una buena práctica es que el BA delimite correctamente el alcance del trabajo que se está realizando para la historia de usuario que se está debatiendo (y enumere lo que está fuera del alcance), para que el equipo de scrum pueda delimitar la historia con mayor precisión
• Planificación del Sprint: Antes de que comience cada Sprint, se realiza la Planificación del Sprint.
• Antes de la Planificación del Sprint, la mejor práctica para el BA es asegurarse de que todas las historias que el Propietario del Producto, las Partes Interesadas y el BA esperan que estén en el próximo sprint estén apuntadas a la historia y codificadas para el sprint adecuado.durante la Planificación del Sprint, si hay alguna pregunta sobre las historias, el BA puede aclararla. En cuanto a quién se asigna la construcción de una historia, esto se deja generalmente en manos del scrum master y los administradores/desarrolladores, pero el BA podría opinar si un determinado constructor ha estado trabajando en algo o tiene conocimientos a medida. Por último, una vez que las historias se han asignado a un constructor durante la planificación del sprint, el BA debe ofrecerse a discutir la Historia de Usuario/Construcción con ellos para asegurarse de que hay claridad, y ofrecerse a ver la construcción una vez que está en progreso.
• Construcción de Historias de Usuario
• Demostración del sprint: Al final de cada sprint, es una buena práctica que el BA haga una demostración de las características desplegadas a las partes interesadas.
• Demostración de despliegue
• Gestión de Lanzamiento/Gestión de Cambios: La mejor práctica para cada lanzamiento a Producción es elaborar una lista de Historias de Usuario que se desplegaron a Producción, con capturas de pantalla para mostrar los cambios – y distribuir esto a las partes interesadas. Después de que las historias se han desplegado a Producción, el BA también debe hacer una Validación de Producción, para asegurarse de que las historias se desplegaron
• Retrospectiva: Al final de cada sprint (o a menudo un par de días después de que termine el sprint), tiene lugar la retro. La mejor práctica para el BA es señalar lo que ha ido bien, y lo que se podría mejorar para el siguiente sprint. Por último, siempre está bien felicitar a alguien que haya sido especialmente útil durante el sprint. Mejora continua

6. Perfeccionamiento en la redacción de historias de usuario y criterios de aceptación

Estas son esencialmente las solicitudes de las partes interesadas para las mejoras de Salesforce.

Aquí encontrará algunas de las mejores prácticas para redactar historias de usuario con éxito.

• Reglas generales: Las Historias de Usuario deben ser independientes, valiosas, pequeñas, comprobables y con suficiente detalle para estimar el esfuerzo de trabajo para construirlas.

; Las Historias de Usuario generalmente se agrupan por Epic.

• Título
• Título: La mejor práctica es utilizar un título descriptivo para la Historia de Usuario que indique de qué trata la historia a alto nivel. Por ejemplo: «Mejorar el diseño de la cuenta con una lista relacionada que muestre los «Productos anteriores comprados».»
• Mejorar el diseño de la cuenta con una lista relacionada que muestre los «Productos anteriores comprados»
• Cuerpo: Comience con el enunciado de la Historia de Usuario: «Como X (el ‘quién’), quiero Y (el ‘qué’), para que ocurra Z (parte del ‘por qué’). Es posible que necesite varios enunciados si la historia de usuario tiene varios escenarios relacionados
• El qué y el por qué: Para ayudar al equipo scrum a entender «de qué» trata la Historia de Usuario, y «por qué» se solicita esta mejora (y qué problema resuelve). Es una buena práctica enumerar viñetas o escribir un párrafo para explicar sucintamente esta información en la parte superior de la historia de usuario. Una buena práctica es incluir capturas de pantalla o maquetas en la historia de usuario, utilizando flechas y cuadros de texto para mostrar la mejora solicitada
• Criterios de Aceptación: Cada empresa en la que he trabajado tiene diferentes formas preferidas de escribir los Criterios de Aceptación, pero en todos los casos el A/C debe incluir lo que el Equipo de Pruebas necesitaría probar, y cómo probar (para cada escenario).
• El BA tendrá que incluir a qué Usuarios afecta cada mejora (por perfil u otro criterio), qué probar específicamente, y cuál será el resultado esperado.
• El BA tendrá que incluir a qué Usuarios afecta cada mejora (por perfil u otro criterio), qué probar específicamente, y cuál será el resultado esperado.
• El BA tendrá que incluir a qué Usuarios afecta cada mejora (por perfil u otro criterio), qué probar específicamente, y cuál será el resultado esperado
• Dado, Cuándo, Entonces (GWT): En la última organización en la que trabajé, preferían que el A/C se proporcionara en el formato GWT. Ahora me gusta mucho este formato y los constructores y probadores parecen apreciar su simplicidad.
• Cada escenario requeriría un GWT separado.
• Aquí hay un ejemplo:
• Cuando, Si, Entonces (GWT)

Escenario: El Usuario de Ventas puede Ver ‘Productos Comprados Anteriormente’ en el registro de la Cuenta
DADO: Soy un Usuario de Ventas con Perfil=Ventas Y Rol=Ventas de Productos
Cuando: Selecciono la pestaña Cuentas Y hago clic a través de cualquier registro de Cuenta
ENTONCES: Veré un registro de Cuenta con una Lista Relacionada llamada «Productos Comprados en el Pasado» Y esta Lista Relacionada se colocará directamente debajo de la Lista Rel. «Oportunidad». Oportunidad». Y los campos mostrados en la nueva Lista Relacionada incluirán, en este orden: Nombre del Producto, Fecha de Compra, Cantidad Comprada

Nota: El DADO es la configuración de la situación (y a quién afecta), el «CUANDO» es típicamente una acción, y el «ENTONCES» significa lo que el usuario encontrará después de que ocurra el «Cuando». ¡Pruébalo!

• Notas finales sobre las Historias de Usuario: Si una solicitud de las partes interesadas tiene mucho que ver, se recomienda dividir la Historia de Usuario en varias historias (y enlazar las historias en Jira, por ejemplo). Recuerde, cada Historia de Usuario debe ser pequeña y comprobable. Si una Historia de Usuario larga y complicada está siendo discutida/puntualizada durante el refinamiento, y la gente está sugiriendo 8 o 13 puntos de historia, es probable que la historia se pueda dividir en trozos más pequeños (o el equipo podría crear un Pico de Investigación, si primero es necesario recopilar más información). 
• Si la historia es larga y complicada, es probable que se pueda dividir en trozos más pequeños

Recuerdo que una vez un desarrollador senior hizo una broma durante el refinamiento para una Historia de Usuario larga y compleja que un BA estaba revisando con el equipo scrum – y el desarrollador declaró: «Necesitamos tres puntos sólo para revisar la Historia de Usuario.» LOL. Las Historias de Usuario largas/complicadas son un «anti-patrón» (que es mi Término Ágil favorito; es una forma educada de decir «no recomendado» o «mala idea»).</p

Una mejor práctica final para escribir Historias de Usuario es hacer la investigación/discusión con las partes interesadas al comienzo del sprint, o en un sprint anterior, por lo que el BA tendrá tiempo suficiente para escribir la historia y discutirla durante el pre-refinamiento/refinamiento.

;

7. Asistir con QA y UAT Testing

• Revisión de QA: Como BA proactivo, una de las mejores prácticas es revisar la construcción de una Historia de Usuario una vez que llega al entorno QA (o incluso antes, en el sandbox de un desarrollador), en lugar de esperar a que la Historia de Usuario se despliegue en el entorno UAT.

;Esto asegurará que la Historia de Usuario es correcta antes de que el equipo de pruebas o las partes interesadas la revisen.

• Revisión de QA
• Pruebas UAT: Una vez que una historia se ha desplegado en el entorno UAT, esto es típicamente donde el equipo de pruebas probará a fondo utilizando los escenarios de prueba en los Criterios de Aceptación.
• Una mejor práctica del BA es revisar los cambios en UAT también, y una vez que parece correcto y el equipo de pruebas ha firmado, el BA debe comunicar a las partes interesadas para revisar y aprobar, antes de que se despliegue a Producción.
• Pruebas UAT

8. Realizar la formación de usuarios y preparar los resúmenes de comunicación

• Preparar Materiales de Formación: Antes de cada lanzamiento a Producción, una de las mejores prácticas para el BA es preparar Materiales de Formación para los Usuarios. Estos materiales de formación incluirían capturas de pantalla para cada Historia de Usuario y explicaciones de lo que es nuevo y lo que se espera de los Usuarios.
• Preparar Materiales de Formación
• Preparar Materiales de Formación para los Usuarios
• Realizar Formación de Usuarios: Otra de las mejores prácticas es llevar a cabo la Formación de Usuarios para todas las nuevas características.
• Esto se puede hacer después de cada lanzamiento.
• La formación debe contar una historia.
• Como mínimo, el BA debe capacitar a las partes interesadas.
• Preparación de la Formación de Usuarios
• Preparar resúmenes de comunicación: Una parte de las mejores prácticas del BA es ayudar a comunicar a la gerencia preparando Resúmenes de Comunicación. Estos podrían ser añadidos a la parte inferior de cada Historia de Usuario, y deben incluir una breve descripción de la mejora que se está desplegando, centrándose en los beneficios, además de una captura de pantalla o dos.
• Preparar Resúmenes de Comunicación
• Preparar Resúmenes de Comunicación

9. Desarrollar informes clave, cuadros de mando y vistas de lista

• Crear informes clave: Una mejor práctica para un BA eficaz es trabajar con las partes interesadas para preparar informes significativos, que ayudarán al negocio a medir el éxito. El BA debe crear informes para Oportunidades, Casos y otros objetos que la empresa utiliza. Estos informes podrían incluir el Propietario de los registros, la Etapa, y otras métricas útiles.
• El BA debería crear informes para las Oportunidades, los Casos y otros objetos que utiliza el negocio

LEER MÁS:
10 funciones avanzadas de generación de informes de Salesforce

<li
• Crear cuadros de mando clave: Una vez creados los Informes, el BA también debería crear Cuadros de Mando para los Stakeholders. Algo que me encanta de los cuadros de mando es la posibilidad de filtrar los informes de los cuadros de mando, y Salesforce ha aumentado el número de filtros de cuadros de mando de 3 a 5. Por ejemplo, si crea un panel de ventas, puede incluir más de 10 informes y gráficos de ventas diferentes y, a continuación, añadir filtros de panel que podrían incluir, por ejemplo: Propietario de la Oportunidad, Etapa, Fecha de Cierre, Fecha de Creación e Importe.
• Además, dentro de los filtros del Cuadro de Mando – puede incluir rangos de fechas relativas, como «30 días anteriores», «Esta semana», «Próximos 30 días» o «Este año».

Por último, no se olvide de formar a las partes interesadas y otros usuarios sobre los cuadros de mando y cómo funcionan.

Típicamente, a los directores de ventas les encantará ver un cuadro de mando como este, ya que pueden entender mejor su pipeline, y luego desglosar por Propietario de Oportunidad, Próximos 30 días, etc.

Además, recomiendo restringir el acceso a quién puede «Editar» los cuadros de mando clave.

Un usuario todavía puede Clonar un cuadro de mando para sus propósitos únicos;

LEA MÁS:
10+ Consejos y trucos para el panel de control de Salesforce

• Crear vistas de lista: Una mejor práctica que a menudo se pasa por alto es crear Vistas de Lista significativas para todos los objetos clave. Las Vistas de Lista son muy valiosas para los Usuarios, y el BA puede filtrar las Vistas de Lista para mostrar sólo los registros relevantes (como por un Tipo de Registro u otros criterios). El BA debe trabajar con las partes interesadas para identificar qué campos deben contener las vistas de lista. Una vez más, recomiendo restringir quién puede cambiar las vistas de lista clave
• Vistas de lista clave: Por ejemplo, para Oportunidades, algunas Vistas de Lista podrían incluir: «Todas las oportunidades de venta abiertas», «Nuevas oportunidades de venta creadas en los últimos 7 días», «Oportunidades cerradas-ganadas este mes», «Oportunidades cerradas-perdidas», «Oportunidades de venta abiertas con importe > 50.000 $», «Oportunidades programadas para cerrarse en los próximos 30 días», etc.

• Jira: Una de mis herramientas favoritas para Agile es Jira, que es una herramienta creada por la compañía llamada Atlassian. Esta herramienta basada en la web se puede utilizar como una herramienta de gestión de proyectos, que permite a una organización crear Epics (que son los nombres de proyectos más grandes), y luego bajo cada Epic, el BA crea Historias de Usuario. Jira también puede realizar un seguimiento de otros tipos de elementos, como subtareas, errores y más. (Tenga en cuenta que Epics podrían agruparse bajo «Iniciativas». En una empresa en la que trabajé, agrupamos un montón de Epics bajo una Iniciativa, ya que el CFO quería amortizar los costos de un proyecto importante). 
• Asesorías
• Asignaciones: Cada Historia de Usuario en Jira debe estar siempre «Asignada» a alguien, para que no se escape entre las grietas.<nbsp;Una mejor práctica es que el BA sea asignado a la Historia de Usuario mientras se está escribiendo – hasta que haya sido asignada en la Planificación del Sprint, momento en el que la persona asignada cambiaría al constructor/desarrollador. 
• Asignaciones
• Asignaciones

<li

• Etapa: Todas las Historias de Usuario en Jira también deben tener una Etapa, y estas etapas son definidas por el equipo scrum.
• Etapas: Algunas etapas podrían incluir «No Comenzado», «En Análisis», «Análisis Completo», «Listo para Desarrollo», «En Desarrollo», «Listo para Pruebas», «Desplegado a Prod», etc.
• Etapas
• ADO: esto se refiere a Azure DevOps (un producto de Microsoft), y esta es también una herramienta popular que tiene características similares a las de Jira.
• Jira
• Lucid Charts, Miro Boards, Figma, Excel: cada una de estas herramientas permite al BA crear visualizaciones, flujos de trabajo, flujos de datos y wireframes. ¡Familiarízate con las herramientas que utiliza tu organización!

LEER MÁS:
Qué es un analista de negocio de Salesforce – ¿Cómo llegar a serlo?

Resumen

El papel del BA de Salesforce es crítico porque el BA necesita traducir lo que las partes interesadas quieren en Historias de Usuario que el equipo de construcción pueda crear. Es importante seguir las prácticas recomendadas anteriores para garantizar una experiencia de usuario fantástica;

¿Tienes alguna duda? ¡Pide aclaraciones a las partes interesadas!