Nuestros BA (Business Analysts) tienen la molesta costumbre de proporcionarnos los requisitos del sistema, en lugar de los requisitos comerciales. Muchas veces, ni siquiera saben cuál es el requisito comercial.
Me enfurece, porque veo una lista de requisitos, y estará ligada a la forma en que debe implementarse, en lugar del problema que debe resolverse.
Un ejemplo muy artificial sería: "El sistema debe enviar por correo electrónico al cliente una confirmación del pedido". en lugar de "El cliente debe ser informado de que el pedido está confirmado".
De acuerdo, en este caso, probablemente será un correo electrónico. Sin embargo, existe la posibilidad de que tomemos una decisión comercial para ser más agradables y queramos hacer un seguimiento de los pedidos con llamadas telefónicas para verificar que encontraron todo lo que buscaban, etc.
Otros ejemplos son más insidiosos. Estaba trabajando con algo que manejaba la reasignación de la distribución a diferentes ubicaciones en función de las ventas. El pedido se realiza inicialmente enviando un monto de $X a la tienda X, un monto de $Y a la tienda Y y un monto de $Z a la tienda Z. Sin embargo, habían pasado 6 meses desde el pedido inicial y vemos que la tienda Z ahora está superando a la tienda Y , cuyas ventas han bajado. Queremos intercambiar los bienes que estamos distribuyendo entre las tiendas. Las reglas de negocio que me dieron estaban estrechamente ligadas a la implementación y, en muchos casos, donde X->Y, Y->Z y Z->X no se producirían intercambios, aunque nuestros ojos pueden ver que literalmente solo estamos barajar mercancías entre tiendas.
Así que sugerí un nuevo enfoque, poner en cola los pedidos que tenemos, clasificarlos, clasificar las tiendas según las ventas y luego volver a emparejar las listas de esa manera. Garantizar que las tiendas más vendidas obtengan los pedidos más grandes.
Sin embargo, debido a que en realidad no conozco la regla comercial, y solo conozco el algoritmo de barajado que me dieron, que parece incorrecto, solucionarlo implica volver a los usuarios y obtener las reglas comerciales... lo que debería haberse hecho en El primer lugar.
Lo que estoy preguntando es, ¿hay algún truco para recopilar buenos requisitos que se basen en reglas comerciales? ¿Cómo puedo lograr que los BA hagan esto, cuando aún no lo han hecho? Me está costando mucho saber explicar la diferencia entre las reglas del sistema y las del negocio... y claramente no lo entienden. ¿Cómo puedo educar y mejorar sus habilidades?
Cambia el formato. Los requisitos funcionales tradicionales son bastante defectuosos y llevan décadas centrándose en el "qué" y no en el "por qué" o el "quién".
Los requisitos basados en User Stories y User Persona se centran en el "quién" y el "por qué". Si bien ágil es el usuario más obvio de esto hoy en día, no es un concepto nuevo. Aprendí por primera vez sobre este concepto a través de una metodología de gestión de productos de la llamada "Construcción de una organización centrada en el mercado" de la década de 1990.
Tome los bancos estadounidenses en los años 70 y 80. En sus esfuerzos por volverse más competitivos en la era posterior a la desregulación, se acercaron a sus clientes. No comenzaron con qué hacer, comenzaron con hacer preguntas a los clientes. Luego observaron lo que dijeron los clientes: "Horarios más largos, más cajeros". y preguntó cómo podrían resolver esto (sin gastar $ en más horas y más cajeros). El resultado fue aprovechar una tecnología que existía desde mediados de los años 60 pero que languidecía como un dispositivo sin un verdadero mercado. Y así llegaron a pasar los cajeros automáticos.
Así que usa User Personas e User Stories. Mike Cohn ha publicado dos libros muy buenos sobre este tema que recomiendo encarecidamente.
Recientemente hice un blog de dos partes sobre el uso de prácticas ágiles en el nivel de requisitos del producto, para impulsar requisitos utilizables. Si te interesa, mi blog está enlazado en mi perfil. Busque los blogs "Basura entra, gorila sale" y "¿Cuánto cuesta ese gorila en la ventana?".
¿Qué estás haciendo para asegurarte de obtener los requisitos que deseas?
Ejercí como BA durante varios años en una gran empresa. Te diré que este no es un problema poco común que estás teniendo. También puedo decirle que la única forma en que se arregla es cuando usted y el BA están en la misma página.
Sí, se supone que el BA debe documentar los requisitos de una manera que el equipo de desarrollo pueda consumir fácilmente. Se supone que el equipo de desarrollo debe producir un código que funcione y que no genere llamadas de soporte (que no tiene que tomar) también.
De cualquier manera, obtener los requisitos para usted es solo una parte del trabajo de un BA. La otra parte es hacer que los líderes sénior NO técnicos tengan la chequera que les paga a ambos para dar requisitos que tengan sentido y no cambien cada semana. Te puedo prometer que no entienden tu problema en absoluto.
Si comienza a buscar trabajo donde el BA será una estrella de rock, buscará mucho trabajo en su carrera.
¿Por qué no ponerse con el BA al lado? Después del trabajo, para tomar un café o lo que sea y ayudarlos a comprender cuáles son sus necesidades. Entrénelos para hacer las preguntas de modo que recopilen los requisitos de una manera que pueda consumir de manera eficiente. Es un ganar ganar para los dos.
Ah, y codifiqué antes de convertirme en BA y todavía lo hago hoy, así que sé por qué sus requisitos deben ser limpios.
No estoy seguro de si tendría la oportunidad, el tiempo y los recursos para rechazar los requisitos existentes y reescribirlos en función de una perspectiva de uso más empresarial.
Si tiene la oportunidad, intente trabajar con el gerente correspondiente y construyan juntos una plantilla de solicitud comercial/formulario de solicitud de cambio (según el tipo de acción) para demandas futuras. Esta plantilla debe incorporar toda la información relevante desde el nombre del solicitante, las fechas, las especificaciones requeridas y las expectativas del usuario final. Puede agregar tantos campos como necesite para recopilar la información que sea conveniente para usted.
Trate de centrar su atención en las secciones de " uso final " o " expectativas comerciales ", donde el analista tendrá que describir de forma concisa el resultado esperado. Haga que este administrador acuerde el formato con usted (para que en el futuro no considere un rechazo como algo personal) y proporcione ejemplos de la entrada deseada en la plantilla para que solo tengan que sobrescribirla.
Si envían sus solicitudes por correo electrónico adjuntando el formulario correctamente completado, al menos obtendrá un mecanismo sólido que le permitirá rechazar directamente cualquier solicitud que no cumpla con los criterios acordados.
Solo ten en cuenta que la mejora no sucederá de un día para otro y debes trabajar con ellos para que te brinden la información correcta, pero brindarles una solución factible ayudará a lograr tu objetivo.
Encontré un artículo relacionado con la documentación de los requisitos comerciales que incluye información adicional:
No hay truco. Escribir un requisito con la redacción adecuada, en el nivel correcto de abstracción, sin incluir la solución requiere un poco de habilidad, análisis y pensamiento. Es lo que se supone que el BA debe hacer por usted. Comprender el concepto es simple, en realidad escribirlo es un poco más difícil. Si su empleado en este rol ni siquiera puede comprender el concepto, entonces tiene a la persona o personas equivocadas. Eche un vistazo a los requisitos de conocimientos/habilidades que tiene para este puesto, reescríbalos y luego vaya a buscar nuevos talentos. Buscar un "truco" no es un comienzo.
EDITAR: Podría estar a favor de retroceder en el trabajo. En un proceso, el siguiente paso se desencadena por la salida del paso anterior. El paso anterior tiene un criterio de finalización que dice que el trabajo aquí está terminado. De manera similar, el siguiente paso tiene criterios de entrada, contra los cuales se prueba la entrada del paso anterior para garantizar la idoneidad para el servicio. Si falla, se rechaza y no se inicia el paso siguiente.
Revertir el trabajo de BA probablemente causará un poco de revuelo en su organización, pero es un síntoma de un problema en su proceso y podría ser la forma más rápida, aunque políticamente arriesgada, de arreglarlo para siempre, por ejemplo, BA es sustituido.
Predicar con el ejemplo. Haga algunos buenos para compartir o contrate a una estrella de rock. También tienes que averiguar por qué faltan estas personas. Muchos BA hacen el trabajo porque aman el negocio en el que están. Otros lo hacen porque no son lo suficientemente técnicos para programar. El último grupo se enfoca en cómo en lugar de qué o por qué porque no saben mejor.
Centrándome en ser lo más imparcial posible, ofrezco dos puntos de vista:
Desde la perspectiva del Business Analyst: Como ya se mencionó, necesita enfocarse en el QUÉ . Si dice CÓMO , el requisito no es óptimo (desde una perspectiva empresarial). Existe la definición de requisitos óptimos (de BABoK ): se espera que sean cohesivos, completos, consistentes, correctos, factibles, modificables, inequívocos y comprobables. Puede usarlo para encontrar lagunas en los requisitos.
Desde la perspectiva del departamento de TI: La tarea por excelencia de TI es construir de acuerdo con los requisitos . Si el BA confirmó con el negocio que lo que necesitan es que el "Sistema debe enviar por correo electrónico al cliente una confirmación del pedido" y se acuerda entre las partes, no hay nada más que TI pueda (¡ni necesite!) hacer. El negocio aceptó la solución de correo.
Ahora, sobre el flujo de comunicación: si el BA es el canal entre TI y el negocio, entonces:
Si es lo primero, creo firmemente que esta pregunta no se planteó. Entonces, dando esto último por sentado, tenemos roles entrelazados: BA tratando de hacer el trabajo del Analista Funcional y también al revés. Quién sabe... tal vez su BA planteó una pregunta similar en un foro de BA (mi líder de TI no deja de intentar ofrecer diferentes puntos de vista para los problemas que detecté).
¡Éxito!
Lo que estoy preguntando es, ¿hay algún truco para recopilar buenos requisitos que se basen en reglas comerciales?
Si hay un único truco, es asegurarse de que primero tiene una comprensión suficiente de a quién se pretende ayudar con el proyecto. ¿Quién (o de hecho qué) se beneficia de un resultado exitoso de su proyecto? Esto a veces se conoce como análisis de partes interesadas o mapeo de partes interesadas . Según mi experiencia, un proyecto típico de TI tiene entre 20 y 40 partes interesadas, todas las cuales tienen algún tipo de interés, directo o indirecto, en el proyecto. ¡Pero, por supuesto, algunos son más importantes que otros para mantener el proyecto feliz! Sugerencia: los "usuarios" directos del software son solo uno de ellos, y casi seguro que no son los más importantes (p. ej., ¿sus jefes?).
Una vez que haya construido un modelo de las partes interesadas, puede comenzar a concentrarse en cada una de ellas y preguntar: "¿Qué es lo que hacen?" y, crucialmente, "¿Qué es lo que hacen que necesitan mejorar?". Documente "cómo hacen lo que hacen ahora" para obtener información de fondo y definitivamente capture cualquier idea que puedan tener sobre cómo mejorar las cosas. PERO manténgalos separados y segregados en sus especificaciones.
¿Cómo puedo lograr que los BA hagan esto, cuando aún no lo han hecho?
Una técnica comprobada para garantizar una calidad suficiente en los artefactos del proyecto en disciplinas de ingeniería que no son de software es utilizar técnicas de inspección junto con criterios de entrada/salida. No puede entregar un dibujo técnico del ala de un avión a la unidad de fabricación a menos que sepa que tiene un nivel suficiente de "corrección" objetiva (por ejemplo, menos de un posible defecto importante por página de dibujo).
Algunos profesionales aplicaron estas técnicas al software desde la década de 1960 en adelante (por ejemplo, consulte este libro para ver una colección de trabajos anteriores). Recomiendo la técnica de medición basada en el muestreo "Agile SQC" de Gilb. Le dirá, de manera económica y objetiva, cuántos "defectos importantes" (también conocidos como "errores potenciales") puede haber por página de especificaciones producida por sus BA. Entonces puede acordar como organización que es económicamente inaceptable pasar especificaciones de requisitos a un equipo de desarrollo que excedan un determinado nivel de defectos (por ejemplo, digamos "10 por página de 300 palabras"). Realmente puede ayudar a eliminar los egos y las emociones del proceso.
¿Cómo puedo educar y mejorar sus habilidades?
Un maravilloso efecto secundario de usar Agile SQC con el tiempo, si se hace correctamente, es que se vuelve automejorable.
Del documento Gilb Agile SQC :
"A largo plazo, la solución práctica más efectiva es adoptar Agile SQC como parte del proceso corporativo y, lo que es más importante, asegurarse de que cada escritor de especificaciones individual tome en serio los criterios de densidad de defectos (y su consecuencia de 'no salida'). aprenderá a seguir las reglas y, como resultado, reducirá su tasa de inyección de defectos personales. En promedio, la tasa de inyección de defectos personales debería disminuir en aproximadamente un 50 % después de cada experiencia de uso del proceso (Agile) SQC".
SBWorks
caffgeek
Tiago Cardoso