verificación de requisitos del usuario, ¿cómo?

Mi pregunta es: ¿cómo puede verificar los requisitos de los usuarios al inicio del proceso de creación de software?

Muestro las especificaciones de usuario, prototipos, demostraciones ... pero aún así los usuarios se olvidan de compartir algunos "detalles insignificantes" sobre el proceso o las reglas y datos comerciales. Que aparece después de la prueba final como algunas "excepciones realmente pequeñas y raras", que se convierten en solicitud de cambio y acumulan mucho trabajo.

Entonces, ¿cómo prototipa (o verifica) los requisitos de los usuarios al principio del proyecto?

Utilice el desarrollo iterativo que le obliga a tener comentarios frecuentes al cliente / usuario.

También aumente la colaboración entre desarrolladores y usuarios al eliminar intermedios (generalmente inútiles) como los gerentes de proyectos o incluso los analistas de negocios (esto último puede ser muy necesario en dominios comerciales muy complejos).

Eso son solo algunas recomendaciones. Hay mucho que decir sobre el tema.

Le recomiendo que eche un vistazo a Scrum . Lo que me salvó la vida.

Comience por no deshacerse de intermediarios como los analistas de negocios, porque en realidad están capacitados en esto. Si no tiene esas personas, acepte que al menos uno de sus desarrolladores necesitará desarrollar esta habilidad.

Luego, con el tiempo, acumule un conjunto de instintos sobre el tipo de cosas que la gente suele pedir tarde en los proyectos, y créelos en una conversación al principio del proyecto. "¿El descuento será siempre el mismo para todos los pedidos o varía según el cliente?" "¿Todos los usuarios pueden ver cada informe, o algunos son solo para supervisores?" "¿El impuesto a las ventas es siempre el mismo o depende de dónde está el cliente?" y así.

Además, intente escribir su código para que esté aislado de este tipo de cambios que llegan tarde, porque algunos llegarán tarde sin importar lo que pase. Si tiene lógica empresarial en los controladores de clic para sus botones, estos cambios realmente duelen. Si tiene una lógica de negocios en una clase específica cuyo nombre hace que sea fácil para usted encontrarla, y puede aprovechar el polimorfismo para, por ejemplo, tener pedidos regulares y pedidos urgentes y cada pedido calcula su propio cargo de envío, entonces el cambio que han realizado pedir es mucho menos doloroso.

No puede evitar cambios tardíos. Las leyes cambian, los impulsores comerciales (clientes, qué ventas prometen, la gran idea que tiene el CEO mientras lee algo en el avión) cambian. Evite lo que pueda y adopte el resto diseñando su código para que sea modificable.

Realmente solo necesita asegurarse de cumplir con los criterios enumerados allí. Por ejemplo, si dice "la funcionalidad x debería estar disponible para todos los usuarios", asegúrese de que esto sea cierto.

Al principio del proceso de desarrollo, esto será difícil, pero más cerca de la fecha límite, más podrá verificar.

Quizás las cosas que aún no ha implementado, puede verificar que están en las consideraciones de diseño para que sepa que se están considerando durante el desarrollo temprano.

Recuerdo haber estado en una reunión de negocios y que uno de los analistas de negocios dijera que debe ser genial ser un desarrollador que siempre tiene una especificación fija para trabajar.

En el mundo real, hay algunas cosas que ayudan mucho con esto. El primero, es aceptar que estos detalles de última hora son una realidad. La única especificación 100% completa del producto final es el código fuente. Si el cliente ya tiene esto, entonces no tiene necesidad de que usted lo escriba, ¿verdad?

Lo segundo que debe hacer es tratar activamente de eliminar los detalles de especificación faltantes. ahora puede intentar que el cliente firme documentos de casos de uso de 300 páginas y otros mecanismos contractuales, pero al final, puedo decir con 100% de confianza, la mejor manera es entregar software a sus clientes. Haga que lo revisen, lo usen, aliéntelos activamente a cambiar la especificación según sus necesidades (y cuando sea apropiado, cobrarles por el trabajo). Incluso cuando solo se implementan algunas de las características, la retroalimentación de los clientes es clave.

El tercero, al leer la especificación, piense en lo que causaría que este requisito cambie y cómo podría manejar las variaciones. a menudo no es sensato exagerar los cambios que pueden no aparecer, pero tener un plan y, lo que es más importante, no diseñar en dificultades adicionales hará que su vida sea mucho más fácil, y los puntos de brownie adicionales para mantener la calma y tener confianza cuando dice "podemos manejar eso ... y nos llevará unos 4 días". inspirará a otros a tener confianza en ti.

Creo que no debes olvidar el otro lado. Para cualquier usuario es difícil producir una lista completa de detalles de lo que desea. Piensa en ti mismo, piensas en cosas nuevas todo el tiempo.

Es un trabajo increíblemente difícil encontrar todos los requisitos y detalles de algo de lo que solo tengas una idea vaga. No creo que nadie pueda.

Tengo un libro aquí de los años 70 llamado "por qué fallan los proyectos de software". Cuando leo en blogs y obtengo revistas de TI, leo en la portada "por qué fallan los proyectos de software". Y cuando comparo el contenido del libro con los listados actuales ... nada cambió. Desarrollo iterativo: sí, muchas variaciones y ayuda a cierto nivel. Pero después de todo este tiempo, el contenido de las revistas tiene las mismas portadas. Si no me crees, busca algo mágico del pasado y ve cómo puedes copiar y pegar el texto hasta ahora.

Este problema no se puede resolver en el extremo de TI. Hemos estado inventando nuevas herramientas, procesos, listas de verificación, esquemas de análisis de requisitos, casos de uso (comerciales), marcos de desarrollo, BPM, SOA, lo llaman y todavía existe el mismo problema ...

Necesita optimizar esto en torno al 'especificador de requisitos'. Por lo tanto, debe proporcionar a esas personas las herramientas adecuadas, lo que sea que les permita elevar su nivel:

Entonces, por ejemplo, para estas personas: patrones de especificaciones listos para usar, aportes de otros proyectos y compañías que hacen la misma copia de sus requisitos de resultados finales y lecciones, atraen a personas que han pasado por la suciedad y pueden ayudar a esta persona a especificar las cosas eso causó los mayores problemas y no es "trivial", pero solo se puede aprender después de hacerlo (por ejemplo, consultores técnicos superiores que hacen lo mismo en otras empresas), les da a estas personas herramientas de compositor de requisitos, para seguros, bancos, telecomunicaciones, etc. : no invente sus propios procesos, compre los procesos genéricos listos para usar, etc. ... NECESITAN herramientas al igual que los desarrolladores necesitan herramientas, patrones y marcos.

No lo resuelve, pero lo mejora significativamente. En mi humilde opinión, la mejora debería estar en esa área y no más adelante.

Al igual que un desarrollador, estas personas solo intentan hacer lo mejor que pueden. Pero a diferencia de los desarrolladores para su campo, la mayoría de las cosas que damos por sentado después de 30 años ni siquiera están presentes en ese campo. En general, sus herramientas son Outlook, Excel, Word y un tablero. Sus procesos son sesiones de lluvia de ideas. Se pueden hacer muchas mejoras en este campo. Por supuesto, el problema es principalmente que están sentados "fuera" de TI, por lo que incluso los planes del CIO para mejorar la situación en ese campo caen en oídos sordos ... pero esa es otra pregunta: cómo "vender" esto.

Problema de huevo y gallina

Lo que está luchando se llama un problema de huevo de gallina en la fase de análisis de requisitos de software. Los clientes no comparten los detalles de los requisitos porque no conocen la arquitectura detallada y los arquitectos no pueden hacer la arquitectura detallada porque no conocen el detalle de todos los requisitos.

Solución de pico doble

Sin embargo, hay una solución bien conocida de este problema. Ese es el modelo de doble pico. En este modelo, debe realizar varias iteraciones de comunicación con los clientes, desde requisitos generales hasta requisitos específicos, así como también debe evolucionar su arquitectura de detalles generales a específicos.

Ventajas del modelo Twin-Peak:

• Los requisitos tienen en cuenta los límites del sistema
• Desarrollo rápido de alternativas de diseño.
• Creación rápida de prototipos.
• Desarrollo eficiente de la arquitectura mediante el uso de soluciones existentes.
• La carga de trabajo de los requisitos se puede estimar a partir del primer plan de arquitectura aproximada
• Reducción de costos porque los requisitos "poco realistas" se identifican antes de la solución en desarrollo
• Reducción de riesgos en el desarrollo.

Referencia

Debe informar a los usuarios que cuanto más tarde se identifique un "requisito" en el proyecto, más costará. Pueden decidir que realmente no necesitan el cambio después de todo. Si insisten en los cambios, pero rechazan los costos adicionales / retraso de tiempo, tiene un problema que debe negociarse. Eso no se resolverá a través de la tecnología o la planificación, sino a través de la gestión de ventas y relaciones con el cliente.

Continuamente poner el software en funcionamiento frente a ellos Y exigirles que hagan el esfuerzo de usar / probar / evaluar es su mejor opción. No comprenderán completamente los contratos, especificaciones, diagramas e historias de usuarios.

Esto es parte de la prueba de Joel. Tome a cualquiera que pueda encontrar para probar el software tanto como sea posible durante todo el proceso de desarrollo.

Si realmente desea hacer el trabajo correctamente, antes de comenzar a trabajar en el código o diseñar una arquitectura, siéntese con algunas de las personas que serán los usuarios de su código (no su administración o cualquier otra parte interesada de nivel superior) y consígalos para mostrarte cómo hacer su trabajo. Lo ideal es hacer el trabajo por un día o dos. Eso le dará una idea de cómo funciona el sistema actual y el tipo de personas que lo están haciendo. También le mostrará las frustraciones que tienen con el sistema actual y las cosas que están afectando su productividad. También debe escuchar todas las quejas y molestias diarias, lo que puede significar que tiene que hacer lo necesario para asegurarse de que sus comentarios se detengan con usted o su equipo de diseño, si la idea de transmitir sus puntos de vista a otros miembros de su organización es es probable que inhiba eso.

Para cada grupo de usuarios, necesita que alguien que trabaje en el desarrollo de esa parte del software haga lo mismo. Luego, todos pueden reunirse y discutir lo que han aprendido en los roles que han sombreado para ver si hay áreas de cruce y cómo pueden facilitar las cosas para todos los involucrados.

No sugiero que esto reemplace otros procesos de recopilación de requisitos, pero es un complemento que le permite comprender lo que los usuarios reales necesitan de su sistema. Independientemente de lo que la gerencia piense que necesitan, es probable que los gerentes y analistas de negocios no sean los usuarios reales del sistema, pero si puede hacer que el sistema funcione bien para esos usuarios, los hará más productivos, haciendo que los gerentes estén contentos y felices. haciendo que su empresa se vea bien.