Dirigir sesiones de captura de requisitos
Normalmente, el arquitecto de soluciones es quien dirige las sesiones de captura de requisitos. El objetivo de estas sesiones es desarrollar las necesidades de alto nivel en requisitos implementables. Si el arquitecto de soluciones ya participó en la fase de preventa, es posible que ya conozca las necesidades del cliente y los factores para el éxito. De no ser así, el arquitecto de soluciones debe asegurarse de estar bien informado antes de la primera sesión. Esta información debe usarse para guiar la conversación con los asistentes.
A medida que adquiera más experiencia dirigiendo estas reuniones, irá adoptando la metodología de su elección. Debe estar preparado para variarla en función de las necesidades concretas de un proyecto o un cliente específico. Lleve a las sesiones un plan, plantillas y los resultados que desea obtener; no obstante, procure no ser demasiado rígido, pues podría reprimir la conversación, la creatividad y las soluciones.
Qué aspecto tiene un requisito
La forma específica en que un proyecto documenta un requisito puede ser específica de una metodología determinada. Sin embargo, en todos los casos, los requisitos deben capturar quién, qué y por qué. Estos parámetros se pueden capturar en casos de usuario o pueden ser requisitos individuales, pero en cualquiera de los casos deben poder probarse y cuantificarse. Un buen requisito tiene en cuenta los siguientes factores:
Quién necesita el requisito
Qué necesita el cliente
Por qué el cliente hace lo que hace
Los requisitos o casos más grandes deben desglosarse en partes más manejables. Las diversas metodologías usan diferentes términos para referirse a estas partes, por ejemplo, el enfoque de Ágil generalmente las denomina «epopeyas». Independientemente del nombre, el arquitecto de soluciones debe estar atento para asegurarse de que este proceso tiene lugar.
Priorización
En cada proyecto, la cantidad de tiempo y recursos que se pueden aplicar para implementar los requisitos es limitada. El arquitecto de soluciones, junto con el equipo del proyecto y, a menudo, el cliente, debe priorizar la lista/el registro de requisitos.
Debido a que los proyectos de aplicaciones empresariales se prestan a implementaciones incrementales, los equipos a menudo otorgan mayor prioridad a un producto viable mínimo (MVP). Un MVP identifica los requisitos que deben completarse para la puesta en marcha inicial. A continuación, los elementos restantes se asignan a iteraciones o sprints futuros.
El arquitecto de soluciones debe usar los objetivos empresariales esenciales identificados para evaluar los requisitos. Debe otorgar mayor prioridad a los requisitos que ayudan a cumplir los objetivos. Este enfoque también puede ayudar a identificar una desconexión de los objetivos esenciales si identifica un requisito que es claramente importante pero que no contribuye a lograr los objetivos esenciales.
Viabilidad
El arquitecto de soluciones debe evaluar los requisitos para asegurarse de que son factibles. Busque requisitos que, a pesar de ser atractivos, no se puedan cumplir por diversos motivos, por ejemplo, requisitos que precisan:
Datos de los que no dispone.
Actualizaciones de otros sistemas cuya realización no es posible en el plazo de tiempo dado.
Una buena pregunta que el arquitecto de soluciones puede hacerse: "¿Hay algo que puede impedir que estos requisitos se cumplan?"
Administración de asistentes
Las expectativas deben establecerse antes de las sesiones para garantizar la asistencia de las personas adecuadas. Debe asegurarse de que asisten personas con experiencia que entienden las áreas tratadas. La celebración de varias sesiones, más reducidas y breves, puede ser más específico y productivo. Invitar a diferentes personas para que se ocupen de distintas partes de un proceso es un recurso útil, pues le ayuda a hacerse una idea general de cómo funciona cada parte del proceso. A menudo, este enfoque le ahorrará tener que hacer un seguimiento para obtener la información que le falta para conocer cómo funciona algo.
Invitar a la dirección a asistir a la sesión también puede ser útil, porque a menudo ofrece información más decisiva. Sin embargo, tenga en cuenta que la presencia de un director sénior puede afectar a la disposición del personal para participar. En muchos casos, el personal permanecerá callado y esperará a que el director responda para no decir algo incorrecto o equivocado. Si se da esa situación negativa, puede abordarlo de dos modos: haciendo un seguimiento independiente de los asistentes o pidiéndole al director que no asista a todas las sesiones.
Trabajo previo a las sesiones
Antes de la sesión, el arquitecto de soluciones debe tratar de obtener la mayor cantidad de información posible sobre la solución actual y sus procesos. Es conveniente que examine esta información antes de la sesión, pues puede ayudarle a formular preguntas que luego puede usar para mantener vivo el debate. Esta fase de preparación también puede ayudar a los asistentes a reunir documentos y ejemplos que pueden aportar a las sesiones.
Además, recuerde reunir el material que el equipo de preventa recopiló. Procure que los clientes no tengan que comenzar de cero de nuevo y repetir información que ya se ha tratado. Determine si se realizaron grabaciones de demostración para ayudarle a estar mejor informado.
Dirigir las conversación para establecer requisitos claros
A menudo, la declaración de requisito inicial de un usuario empresarial no es el requisito real. El arquitecto de soluciones deberá realizar un trabajo de investigación para guiar al usuario o comunicarse con otras personas para llegar al requisito real. El arquitecto de la solución debe aprender a preguntar "¿Por qué?" sin molestar al usuario ni transmitir la sensación de que
el usuario es inepto para hacer su trabajo. El verdadero objetivo de las preguntas es comprender el problema principal para poder diseñar la mejor solución.
Por eso, tener una serie de preguntas frecuentes ya preparada puede ayudarle a obtener información:
¿Puede describir un día de vida de ese proceso?
¿Quién más está involucrado en este proceso?
¿De dónde proviene esa información?
¿Puede ayudarme a entender por qué ese proceso es necesario?
Si comienza con preguntas abiertas destinadas a llegar a los requisitos y las necesidades reales, puede finalizar con una pregunta que exija un Sí o un No como respuesta para confirmar que lo ha entendido. El siguiente ejemplo es un sencillo intercambio entre un arquitecto de soluciones (SA) y usuarios empresariales:
Usuario: Necesitamos un informe impreso de todas las transacciones vencidas de los últimos 30 días.
SA: ¿Quién usa el informe?
Usuario: Lo usan los directores.
SA: Director, ¿cómo usa el informe? ¿Tiene que ser un informe o la verdadera finalidad es simplemente poder ver las transacciones vencidas del último mes?
Director: Solo consultamos ese informe una vez al mes, por lo que con eso bastaría.
SA: ¿Qué busca cuando revisa los datos?
Director: Buscamos cualquier transacción superior a 50 000 USD y, a continuación, revisamos exhaustivamente las transacciones identificadas.
SA: Entonces, ¿sería útil si el sistema solo incluyera las transacciones vencidas de más de 50 000 USD para su revisión?
Director: Si, eso sería estupendo.
Requisito revisado: Los directores deben revisar las transacciones vencidas de más de 50 000 USD mensualmente.
Si el arquitecto de soluciones no hubiera preguntado con tanto detalle, el equipo habría creado un informe en papel. Pregunte siempre "¿Por qué?" y llegue al punto donde sienta que realmente entiende la necesidad.
Resolver requisitos en conflicto
Ocurre con frecuencia que distintos usuarios empresariales crean requisitos en conflicto. Es fundamental que el cliente tenga a alguien encargado de decidir en estos casos. El arquitecto de soluciones puede ayudar sugiriendo ideas y compromisos que orienten a las partes hacia una conclusión; sin embargo, no debería involucrarse en la política corporativa.
Defienda su perspectiva
Un arquitecto de soluciones debe saber plantear, siempre con respeto, objeciones sobre los requisitos. Parte de esta tarea es saber comunicar claramente la visión de la solución que ha ideado y ayudar al cliente a ver cómo esta visión ayuda a lograr sus objetivos. Los arquitectos de soluciones inexpertos a menudo tienen problemas en esta fase, por parecer condescendientes. Asegúrese de que, al guiar al cliente hacia su visión, no manifiesta desprecio por sus ideas.
Ejercicio: Planificar las sesiones de captura de requisitos
Revise los equipos de Woodgrove Bank. Determine qué equipos agruparía para reunir los requisitos. Determine qué equipos no agruparía para reunir los requisitos. Explique el motivo de ambas decisiones.