¿Cuántas veces os han dicho que tenéis dos días para “cumplir con los requisitos” cuando realmente necesitamos dos semanas o incluso dos meses? Incluso que el análisis se puede hacer “durante el sprint” mientras los desarrolladores están diseñando y desarrollando.
Sabemos que el análisis no se puede omitir, pero ¿cómo justificamos el tiempo que se necesita para obtener buenos requisitos?
En este artículo, daré mi opinión sobre por qué es importante estimar y tener un plan de análisis, algunos consejos sobre cómo hacerlo y las diferencias entre los enfoques tradicionales y ágiles al estimar.
El análisis empresarial es un trabajo complejo. Si estas ocupando el rol de análisis de negocios, ya sea con el rol de Analista de negocios, Analista de sistemas, Propietario de producto u otros debemos entender que hacer para generar valor comercial y cuánto tiempo nos tomará obtener esa comprensión compartida. ¿Por qué? Para estimar con precisión el trabajo a fin de justificar el tiempo que realmente lleva obtener buenos requisitos.
La recompensa de obtener buenos requisitos antes del diseño técnico y el desarrollo se ha demostrado una y otra vez. Si nos fijamos en los estudios de Standish, IBM y otros grupos publicados en los últimos diez años, el coste de los malos requisitos o los que faltan es enorme. He visto cifras entre 100 y 2900 veces el coste que se han encontrado en la interfaz o en el análisis. En otras palabras, ¡el coste de incluso una hora de análisis puede devolverle a una organización entre 100 y 2900 veces! Incluso en el cálculo bajo, este dato es bastante sorprendente.
¿Por qué necesitaremos más tiempo?
Los analistas comerciales y los propietarios de los productos rara vez tienen suficiente tiempo para obtener, analizar y confirmar los requisitos. ¿Por qué? Una razón puede ser que no la solicitemos, o tal vez no sepamos CÓMO solicitarla.
Recuerdo que cuando volví a trabajar en proyectos, teníamos una tarea larga en la estructura de desglose de trabajo que se llamaba algo así como “Reunir requisitos”. A mi parecer, habían al menos dos cosas mal en esta tarea. En primer lugar, los requisitos no deben estar tumbados para recogerlos como las hojas de su jardín. Hay mucho que entra en análisis, como todos sabemos. No es solo fácil “recoger esas cosas”. ¡La palabra “reunir” lo hace parecer fácil!
En segundo lugar, debemos dividir las tareas en niveles lo suficientemente bajos como para poder estimarlos con relativa precisión. Una gran tarea es muy difícil de estimar. Una importante habilidad del analista de negocios es la capacidad de estimar con precisión la cantidad de tiempo requerida para realizar el trabajo de análisis y ser capaz de explicar y justificar a nuestros gerentes de proyecto y patrocinadores.
Un caso con un plan de análisis
La mejor manera de solicitar y recibir suficiente tiempo es construir su caso cuantitativamente para poder explicar al equipo qué se va a hacer durante ese tiempo y por qué este trabajo es importante. Mi sugerencia es que desarrolles estimaciones dividiendo las tareas en pequeños pedazos. Mientras más pequeña sea la tarea, más fácil y precisa será la estimación para su plan de análisis. Este detalle también ayuda a justificar el tiempo.
La forma en que desgloses el trabajo depende, como todo en el análisis comercial, de ti, tus partes interesadas de las que obtienes requisitos y con quienes creas soluciones, el enfoque del proyecto y la naturaleza del proyecto en sí. Vamos a estudiar esos factores con algunos ejemplos.
En un proyecto tradicional, a menudo construyo mi plan de análisis dividiendo mi trabajo por las capacidades, los procesos comerciales, que afectaré en el proyecto. En otras palabras, ¿qué procesos, funciones o tareas del negocio voy a ayudar a hacer mejor, más rápido, menos costoso o más fácil? Por ejemplo, si estuviera en un proyecto para un minorista en línea, podría estar trabajando en una nueva solución para el pago. Tomaría esa capacidad de alto nivel, tal vez llamada “Pedido completo del cliente” y la dividiría un poco más. Uno de los procesos o tareas de nivel inferior involucrados en completar el pedido podría ser “Elemento de pedido de captura”. Ahora, estoy en un nivel que es relativamente fácil comenzar a estimar el esfuerzo para un buen análisis de negocios para ese proceso.
Empiezo a planificar y a estimar cómo obtendré y comunicaré los requisitos para “Elemento de pedido de captura”. En general, hay al menos cuatro tareas que necesitaré estimar:
- Investigar los problemas y los procesos involucrados
Esto podría significar revisar el alcance, el caso de negocios u otra documentación previa, crear un flujo de trabajo estatal actual o entrevistar a las partes interesadas. Necesito estimar el tiempo de investigación en función de mi técnica de obtención de información, las partes interesadas de las que necesito obtener información, la disponibilidad de buena información y el tiempo que creo que tomará obtener la información que necesito. Supongamos por este esfuerzo, que planificamos y ejecutamos un workshop facilitado con los expertos en la materia. Podría estimar 2 horas para esta tarea.
- “Pensar” en cada proceso
Necesito tomar toda la información que he aprendido en mi investigación y estructurarla. A mi parecer, esto significa modelar subprocesos, datos y / o reglas comerciales. En otras palabras, aquí es donde realizo el verdadero análisis necesario para garantizar que comprendamos por completo el (los) problema (s) actual (es) y lo que intentamos incorporar a una solución. “Pensando en” el proceso es donde entra gran parte de mi análisis profundo. ¡Y esto probablemente genere más preguntas! Recuerda que todos estos pasos son generalmente iterativos de alguna manera. Podría estimar 3 horas para esta tarea.
- Obtener aprobación de la dirección
Basado en el análisis que surge del paso anterior, empiezo a trabajar con el negocio y tal vez con el equipo técnico (si la solución involucra IT) para evaluar las opciones que tenemos para la solución. Se me puede pedir que ayude con la viabilidad y / o el coste-beneficio de las opciones. Una vez que elijamos una opción, necesito asegurarme de que se cuente con los acuerdos o aprobaciones correspondientes. Si estoy en un equipo ágil, esto tiene lugar dentro del equipo, pero aún debe suceder. Todo esto significa obtener una comprensión compartida de lo que se necesitará para proporcionar el valor comercial necesario. Podría estimar 1 hora para esta tarea.
- Obtener el detalle necesario para los requisitos funcionales y no funcionales
Esta tarea se realiza una vez que tenemos la aprobación de la dirección, en función de la decisión tomada en la tercera tarea anterior. El nivel de detalle depende principalmente de las personas involucradas. Quiero producir los detalles necesarios para:
- Negocios para comprender qué implica la solución y cómo funcionará desde la perspectiva comercial.
- Equipo técnico involucrado para poder diseñar y desarrollar la solución de una manera que proporcione el valor comercial esperado.
- Un equipo de calidad o pruebas involucrado para poder garantizar que la solución logre el resultado deseado y brinde el valor comercial esperado.
Podría estimar 3 horas para esta tarea.
Para las tareas enumeradas anteriormente, he estimado 9 horas de trabajo. Si hago esto para todos los procesos que estamos afectando en este proyecto y lo desglosamos a este nivel de tarea, ¡ahora tengo algunas buenas municiones para defender mi tiempo! En este ejemplo simplificado, si me piden que “lo haga en dos días” y tengo 5 procesos similares para analizar, tengo 45 horas de trabajo en mi plan de análisis. Ahora ya podré mostrar todos los procesos y las tareas involucradas y hacer que la persona que me solicitó solo dos días me diga que ahora se ha demostrado que requiere al menos una semana.
Asegúrate de guardar este trabajo de proyecto a proyecto también, de modo que cuando alguien tenga un marco de tiempo poco realista, tenga una base para justificar su tiempo disponible. Esto es especialmente útil para proyectos similares.
¿Qué diferencia hay en un proyecto ágil?
¡Nada! El tiempo puede ser diferente. Las capacidades para su plan de análisis se dividirían en historias de usuarios. Los entregables pueden variar.
¿Pero igualmente es necesario investigar y comprender esas historias de usuarios y el problema que estamos tratando de resolver? ¡Sí!
¿Es necesario analizar historias de usuarios y asegurarse de que podamos manejar las reglas de datos y de negocios (o criterios de aceptación) requeridas para esa historia de usuario? ¡Sí!
¿Es necesario asegurarse de que tenemos una comprensión compartida dentro del equipo? ¡Sí!
¿Es necesario proporcionar expectativas de funcionalidad a los desarrolladores para que puedan desarrollar algo de valor para la empresa? ¡Sí!
¿Es necesario preparar las historias para un desarrollo técnico efectivo? ¡Sí!
Puedo llamar a las tareas y entregables por diferentes nombres, es necesario realizar todo.
Sí. ¡Vale la pena el esfuerzo!
Al igual que cualquier tipo de planificación, el esfuerzo de crear un plan de análisis en sí lleva tiempo, pero si constantemente te presionan para que realices tu análisis demasiado rápido, piensa dividir tu trabajo en trozos para que puedas estimar el trabajo y tener la munición cuantitativa para defender tu trabajo. Por lo general, vale la pena el esfuerzo!
Autora del artículo
Alison (Ali) Cox tiene experiencia desde mediados de la década de 1980 en diversas áreas, incluido el análisis empresarial, desarrollo de metodología de proyectos y capacitación, desarrollo de sistemas y gestión de telecomunicaciones. Alison tiene certificaciones en BA , CBAP, PMP y SAFe Agilist (SA). Alison comenzó su carrera en el área de servicios financieros y luego pasó al desarrollo de sistemas para sistemas contables. Ha brindado consultoría y capacitación en análisis de negocios y gestión de proyectos para pequeñas empresas y corporaciones de Fortune 500 en todo el mundo.