He pasado los últimos 3 meses en una fase exhaustiva, y agotadora, de recopilación de requisitos de un proyecto importante y he aprendido, sobre todo, que no hay una solución única para todos . No hay ningún proceso, ningún secreto, que funcione en todos los casos. El análisis de requisitos es una habilidad genuina, y justo cuando crees que finalmente lo has resuelto todo, te expones a un grupo de personas totalmente diferente y tienes que tirar todo lo que sabes por la ventana.
Diferentes partes interesadas piensan en diferentes niveles de abstracción.
Es fácil decir "hablar a nivel comercial, no técnico", pero no es necesariamente tan fácil de hacer . El sistema que está diseñando es un elefante y sus partes interesadas son los ciegos que lo examinan . Algunas personas están tan profundamente inmersos en el proceso y la rutina que no se dan cuenta de que no es un negocio. Otros pueden trabajar en el nivel de abstracción que desea, pero son propensos a hacer afirmaciones exageradas o incluso falsas, o participar en una ilusión.
Desafortunadamente, simplemente tiene que conocer a todos los individuos como individuos y comprender cómo piensan, aprender a interpretar las cosas que dicen e incluso decidir qué ignorar.
Divide y conquistaras
Si no quiere que se haga algo, envíelo a un comité.
No te reúnas con los comités. Mantenga esas reuniones lo más pequeñas posible. YMMV, pero en mi experiencia, el tamaño ideal es de 3-4 personas (incluido usted) para sesiones abiertas y 2-3 personas para sesiones cerradas (es decir, cuando necesita una pregunta específica respondida).
Intento reunirme con personas que tienen funciones similares en el negocio. Realmente hay muy poco que ganar y mucho que perder arrojando a la gente de marketing en la habitación con los contadores de frijoles. Busque a las personas que son expertas en un tema y haga que hablen sobre ese tema.
Una reunión sin preparación es una reunión sin propósito.
Un par de otras respuestas / comentarios han hecho referencia a la técnica del hombre de paja, que es excelente para aquellas personas problemáticas de las que parece que no puedes obtener ninguna respuesta. Pero no confíe demasiado en los hombres de paja , o la gente comenzará a sentir que los está engañando. Tienes que empujar suavemente a las personas en la dirección correcta y dejar que se les ocurran los detalles por sí mismos, para que sientan que los poseen (y en cierto sentido, los poseen).
Lo que debe tener es algún tipo de modelo mental de cómo cree que funciona el negocio y cómo debería funcionar el sistema . Debe convertirse en un experto en dominios , incluso si no es un experto en la empresa específica en cuestión. Investigue todo lo que pueda sobre su negocio, sus competidores, los sistemas existentes en el mercado y cualquier otra cosa que pueda estar relacionada de forma remota.
Una vez en ese punto, me pareció más efectivo trabajar con construcciones de alto nivel, como Casos de uso, que tienden a ser agradables para todos, pero aún así es fundamental hacer preguntas específicas. Si comienza con "¿Cómo factura a sus clientes?" , te espera una reunión muy larga. Haga preguntas que impliquen un proceso en lugar de desmentir el proceso desde el principio: ¿Cuáles son las líneas de pedido? ¿Cómo se calculan? ¿Con qué frecuencia cambian? ¿Cuántos tipos diferentes de ventas o contratos hay? ¿Dónde se imprimen? Tienes la idea.
Si pierdes un paso, alguien generalmente te lo dirá. Si nadie se queja, dése una palmadita en la espalda, porque acaba de confirmar implícitamente el proceso.
Aplazar discusiones fuera del tema .
Como analista de requisitos, también desempeña el papel de facilitador y, a menos que realmente disfrute pasar todo el tiempo en las reuniones, debe encontrar una manera de mantener el rumbo. Irónicamente, este problema se vuelve más pernicioso cuando finalmente no que la gente hable. Si no tiene cuidado, puede descarrilar el tren por el que pasó tanto tiempo preparando las vías.
Sin embargo, y aprendí esto de la manera difícil hace mucho tiempo, no puedes decirle a la gente que un problema es irrelevante . Obviamente es relevante para ellos , de lo contrario no estarían hablando de eso. Su trabajo consiste en hacer que la gente diga "sí" tanto como sea posible y colocar una barrera como esa simplemente lo empuja al territorio de "no".
Este es un delicado equilibrio que muchas personas pueden mantener con "elementos de acción", básicamente una cola genérica de discusiones a las que prometieron volver en algún momento , normalmente etiquetadas con los nombres de las partes interesadas que pensaron que era realmente importante. Esto no es solo por el bien de la diplomacia: también es una herramienta valiosa para ayudarlo a recordar lo que sucedió durante las reuniones y con quién hablar si necesita aclaraciones más adelante.
Diferentes analistas manejan esto de diferentes maneras; algunos como la pizarra pública o el registro de rotafolios, otros lo golpean silenciosamente en sus computadoras portátiles y analizan suavemente otros temas. Cualquier cosa con la que te sientas cómodo.
Necesitas una agenda
Esto probablemente sea cierto para casi cualquier tipo de reunión, pero es doblemente cierto para las reuniones de requisitos. A medida que avanzan las discusiones, las mentes de las personas comienzan a perderse y comienzan a preguntarse cuándo llegarán a las cosas que realmente les importan. Tener una agenda proporciona cierta estructura y también lo ayuda a determinar, como se mencionó anteriormente, cuándo necesita diferir una discusión que se está saliendo del tema.
No camine allí sin tener una idea clara de qué es exactamente lo que desea cubrir y cuándo . Sin eso, no tiene forma de evaluar su propio progreso, y los usuarios lo odiarán por siempre correr mucho tiempo (suponiendo que no lo odien por otras razones).
Burlarse de él
Si usa PowerPoint o Visio como herramienta de maqueta, sufrirá el problema de que se vea demasiado pulido . Es casi un valle misterioso de interfaces de usuario; las personas se sentirán cómodas con dibujos de servilletas (o dibujos generados por computadora que parecen dibujos de servilletas, usando una herramienta como Balsamiq o Sketchflow ), porque saben que no es real, la misma razón por la que las personas pueden ver personajes de dibujos animados. Pero cuanto más empiece a parecerse a una interfaz de usuario real, más personas querrán elegirla y tocarla, y más tiempo pasarán discutiendo sobre detalles que en última instancia son insignificantes.
Definitivamente, haga simulacros para evaluar su comprensión de los requisitos ( después de las etapas de análisis iniciales), son una excelente manera de obtener comentarios muy rápidos y detallados, pero manténgalos fijos y no se apresure a burlarse hasta que usted ' estamos bastante seguros de que estás frente a frente con tus usuarios.
Tenga en cuenta que una maqueta no es una entrega , es una herramienta para ayudar a comprender. Del mismo modo que no esperaría ser cautivo de su simulacro al hacer el diseño de la interfaz de usuario, no puede suponer que el diseño está bien simplemente porque le dieron el visto bueno a su maqueta. He visto simulacros utilizados como una muleta, o peor, una excusa para eludir por completo los requisitos; Asegúrate de no hacer eso. Regrese y convierta ese simulacro en un conjunto real de requisitos.
Se paciente.
Esto es difícil de creer para muchos programadores, pero para la mayoría de los proyectos no triviales, no puedes simplemente sentarte una vez y elaborar una especificación funcional completa. No solo estoy hablando de paciencia durante una sola reunión; El análisis de requisitos es iterativo de la misma manera que lo es el código. El Grupo A dice algo y luego el Grupo B dice algo que contradice totalmente lo que escuchó del Grupo A. Luego, el Grupo A explica la inconsistencia y resulta ser algo que el Grupo C olvidó mencionar. Repetir 500 veces y tiene algo más o menos parecido a la verdad .
A menos que esté desarrollando una pequeña aplicación CRUD (en cuyo caso, ¿por qué molestarse con los requisitos?), No espere obtener todo lo que necesita en una reunión, o dos, o cinco. Vas a estar escuchando mucho, y hablando mucho, y repitiéndote mucho. Lo cual no es una cosa terrible, eso sí; Es una oportunidad para establecer una buena relación con las personas que inevitablemente van a firmar su entregable.
No tengas miedo de cambiar tu técnica o improvisar.
Diferentes aspectos de un proyecto en realidad pueden requerir diferentes técnicas de análisis. En algunos casos, el UML clásico (diagrama de caso de uso / actividad) funciona muy bien. En otros casos, puede comenzar con KSI de negocios, o hacer una lluvia de ideas con un mapa mental, o sumergirse directamente en maquetas a pesar de mi advertencia anterior.
La conclusión es que debe comprender el dominio usted mismo y hacer su tarea antes de perder el tiempo de otra persona. Si sabe que un departamento o componente en particular solo tiene un caso de uso, pero es increíblemente complicado, omita el análisis de casos de uso y comience a hablar sobre flujos de trabajo o flujos de datos. Si no usaría la misma herramienta para cada parte de la implementación de una aplicación, ¿por qué usaría la misma herramienta para cada parte de los requisitos?
Mantén la oreja en el suelo.
De todos los consejos y sugerencias que he leído para el análisis de requisitos, este es probablemente el que se pasa por alto con mayor frecuencia. Sinceramente, creo que he aprendido más de espionaje y ocasionalmente de conversaciones de enfriadores de agua de las reuniones programadas.
Si está acostumbrado a trabajar de forma aislada, trate de ubicarse donde se encuentra la acción para poder escuchar la charla. Si no puede, simplemente haga rondas frecuentes, a la cocina o al baño o donde sea. Descubrirá todo tipo de cosas interesantes sobre cómo funciona realmente el negocio al escuchar lo que la gente se jacta o se queja durante sus descansos para tomar café y fumar.
Finalmente, lee entre líneas .
Uno de mis mayores errores en el pasado fue estar tan centrado en el resultado final que no me tomé el tiempo para escuchar lo que la gente decía . A veces, la mayoría de las veces, puede parecer que la gente está parloteando sobre nada o insistiendo en algún procedimiento que le suena completamente inútil, pero si realmente se concentra en lo que dicen, se dará cuenta de que realmente existe un requisito enterrado allí, o varios.
Por cursi e insípido que parezca, el Five Whys es una técnica realmente útil aquí. Siempre que tengas esa reacción instintiva de "eso es estúpido" (no es que alguna vez lo digas en voz alta), detente y conviértela en una pregunta: ¿Por qué? ¿Por qué esta información se vuelve a escribir cuatro veces, luego se imprime, se fotocopia, se escanea, se vuelve a imprimir, se fija en un tablero de partículas, se toma con una cámara digital y finalmente se envía por correo electrónico al gerente de ventas? No es una razón , y es posible que no sabe lo que es, pero es su trabajo para averiguar. Buena suerte con eso. ;)