¿Cómo muevo un cliente de maquetas de UI a un conjunto de requisitos reales?

Supongamos que tiene una maqueta de 25 pantallas de los estados visuales de su aplicación. La expectativa es que esto es suficiente para que tengamos la confianza de que podemos desarrollarlo y entregarlo al interesado o cliente original como una aplicación finalizada, y estarán satisfechos. Naturalmente, terminará haciéndoles nuevamente a los interesados ​​muchas preguntas que se utilizaron para crear la IU, lo cual es un desperdicio.

Sin embargo, muchas veces he descubierto que esto no es suficiente, en el transcurso del desarrollo de la aplicación, los requisitos se vuelven borrosos por el hecho de que estamos replicando una interfaz y, al final, el cliente no está tan contento como parecía. cuando les pedimos toda la información para crear la interfaz de usuario.

Simplemente no estoy seguro de qué más pedir, he tratado de ser específico y solicitar requisitos y una comprensión del objetivo general, pero no sé qué debo pedir. Si acabo de comenzar ahora, se perderá mucho tiempo volviendo a codificar toda la información que conduce a la interfaz de usuario y durante esta fase se perderán muchas razones importantes que el cliente tenía originalmente.

¿Cómo puedo hacer que la gente entienda que no podemos bloquear los requisitos basados ​​en maquetas de UI al pedir algo procesable que puedan crear para mí?

¿Con qué comenzaría idealmente para ejecutar correctamente la tarea de desarrollar una aplicación para usuarios finales?

Algunas otras cosas que puede necesitar son:

• Casos de uso o descripciones de flujo de trabajo: solo porque sabe cómo se ve una pantalla, ¿sabe cómo se maneja la entrada incorrecta? ¿Sabes cómo hacer la transición entre pantallas en TODOS los casos? También puede incluir el manejo de errores aquí.

• Descripción del sistema de alto nivel: Algo que explica para qué sirve todo el sistema para estas 25 pantallas y para qué sirve.

• Modelo de datos: ¿es posible inferir un modelo de datos a partir de estas pantallas? ¿Existe un modelo de datos que deba usarse o puede diseñar el suyo para hacer el trabajo?

• Requisitos técnicos: ¿son las tecnologías específicas que se deben utilizar debido a la licencia o por razones de integración?

• Requisitos de rendimiento: si hay una pantalla de búsqueda, ¿hay expectativas de qué se puede buscar y qué tan rápida debe ser la respuesta? ¿Qué pasa con las respuestas para otros tipos de acciones? ¿Pueden o deberían ser algunos de ellos asíncronos (el usuario envía el trabajo y vuelve más tarde)?

• Requisitos de seguridad: ¿La aplicación almacena datos potencialmente confidenciales / personales y, de ser así, qué tipo de datos y qué debe hacerse para mantenerlos seguros? ¿Necesita cumplir con algún nivel de cumplimiento (como el cumplimiento de PCI para realizar pagos con tarjeta de crédito)?

Además, ¿hay algún conocimiento especial de dominio comercial en el que pueda necesitar que lo ayuden? Algunas industrias como los seguros, la banca, los registros médicos de salud, etc. tienen todo tipo de lógica empresarial compleja. Tales proyectos no deben intentarse sin la ayuda de un analista de negocios que conozca ese dominio. Pero si se trata solo de un sitio de carrito de compras / información para widgets genéricos, es posible que no necesite un miembro de dicho equipo.

Cómo hacer que la gente entienda que los simulacros de UI no son suficientes para crear un programa de trabajo:

Yo manejaría esto con una analogía. Como soy un poco loco por los autos, voy por esa ruta.

"Imagina que no sé nada de autos. Me das algunas fotos de un Ferrari. Un par desde afuera y otro desde adentro (tomado del asiento del conductor para que pueda ver los controles del auto). Ahora me preguntas para fabricarte un Ferrari. Regreso con una cosa que se parece a las fotos y tiene todos los controles. Desafortunadamente, esos controles no están conectados a nada porque (ya que no sé nada sobre autos) no sé cuáles son esos los controles deberían hacerlo. Ni siquiera puedo adivinar porque ni siquiera sé qué se supone que deben hacer los automóviles. Entonces tenemos una conversación como esta:

"Entonces, ¿qué hace un Ferrari?" "Me permite moverme rápidamente de un punto a otro". "Está bien. Entonces, ¿qué hace este círculo?" "Oh, ese es el volante. Al girarlo, puedes cambiar en qué dirección apuntan las ruedas en el exterior del automóvil. Esto cambiará en qué dirección se mueve el automóvil". "Bien, ¿y qué hay de esta cosa del pedal?" "Ese es el acelerador. Hace que el motor vaya más rápido, lo que hace que el auto vaya más rápido". ... unos minutos más tarde ... "Ok, entonces, ¿qué tipo de motor necesita? He investigado un poco y he encontrado motores para carritos de golf y algunos para autos deportivos. ¿Cuál debo usar?" ... etc. ... "

Entonces puedes explicar la analogía. Entregarles a los desarrolladores simulacros de pantallas solo les dice cómo se ve, no qué hace. Los desarrolladores necesitan saber qué problema resuelve el programa o cómo se usará (como saber lo que hace un automóvil, hace que sea más fácil diseñar el automóvil y adivinar con conocimiento de qué deben hacer las cosas). Necesitan saber qué tipo de cosas se espera que usen (es decir, el motor del carrito de golf frente al motor del automóvil deportivo) y qué otros requisitos no relacionados con la interfaz de usuario existen (el automóvil debe ir rápido).

Cosas que pediría:

Descripción del problema general / de alto nivel

Casos de uso / historias de usuario

Requisitos de desempeño

Tecnologías / plataforma requeridas (Windows, Linux, Web)

Todo lo frustrado con las formas tiene en su respuesta

Algo en el sentido del 80% del esfuerzo de desarrollo va hacia el 20% de los casos de uso marginal. Las capturas de pantalla no le informarán sobre los casos de uso, por lo que estará en la oscuridad durante el 80% de su desarrollo activo.

Es bueno que esté tratando de averiguar más y tratando de comunicar lo importante que es para el cliente estar más involucrado en los requisitos del proyecto, sin embargo, si no lo hacen, están configurando el proyecto para el fracaso, y Eso no es tu culpa.

La mayoría de los proyectos de software fallan porque el cliente no está lo suficientemente involucrado en el proceso de desarrollo de software. Este no es un problema nuevo y ciertamente no es un misterio por qué los proyectos de software fallan, pero ocurre continuamente una y otra vez en la industria debido a situaciones como esta.

No puede simplemente arrojar una pequeña cantidad de información sobre una pared y esperar recuperar todas sus esperanzas y sueños en forma de un paquete de software. El desarrollo de software simplemente no funciona de esta manera. Ya sea que sea una tienda Agile o Waterfall, es necesaria una sólida dirección del cliente para el éxito o el fracaso de un proyecto.

Una cosa que la gente parece olvidarse de preguntar es, ¿para qué se utilizarán los datos después de ingresarlos? ¿Necesitas informes? ¿Necesita generar un albarán y enviarlo al almacén para su envío, etc. Si los datos se utilizan para tomar decisiones de gestión y se necesitan informes, eso puede cambiar el diseño de la base de datos. También puede agregar una gran cantidad de tiempo al desarrollo, dependiendo de la complejidad de los informes.

También debe asegurarse de que haya un camino para cada posible decisión. Entonces, si algo requiere la aprobación de la administración, entonces, ¿qué hacer si se desaprueba y qué hacer si se aprueba? Si no se aprueba o desaprueba en X cantidad de tiempo, ¿qué le sucede? Si seleccionan un producto y está agotado, ¿qué sucede con el pedido? Ese tipo de preguntas.

También necesita saber si hay límites específicos sobre qué datos deben colocarse en cada campo. ¿Hay valores requeridos? ¿De dónde vas a conseguirlos? ¿Cómo serán actualizados? Necesita saber cómo manejar los errores. Debe saber si la base de datos necesita una auditoría o si necesita poder recrear datos desde una perspectiva histórica (volviendo a esos informes molestos).

Otra cosa que veo que sucede es que las aplicaciones pueden diseñarse solo para llegar a la versión sin tener en cuenta cómo se mantendrán los datos después. ¿Necesita una página de administrador para asegurarse de que puedan actualizar sus listas de valores requeridos? ¿Necesita enviar datos de un lado a otro a otros sistemas? ¿Cómo va a obtener los datos iniciales en la base de datos?

Personalmente, pediría una reunión de medio día a día con el cliente para analizar su diseño de interfaz de usuario y sus objetivos y asegurarme de que todo esté alineado.

Comience simple. Haz que comprendan que con la información que te han dado, ninguna de esas pantallas haría nada . No hay detalles sobre casos de uso, comportamiento de entrada incorrecto, etc. Simplemente no funcionará. Explicar una generalización contundente es más fácil que explicar detalles, porque el punto no puede perderse. Intentar darles una justificación más complicada de por qué las maquetas de pantalla no es suficiente les da la oportunidad de discutir sus definiciones en lugar de reconocer el problema. Pídales que imaginen que el desarrollador de back-end no hablaba inglés (o el idioma en que se presentan las pantallas). Luego pregunte qué tan diferente es esta situación para un desarrollador que no tiene ningún conocimientode sus procesos de negocio. Luego desarrollen el ejemplo más realista de ustedes mismos, que tienen algún conocimiento, pero están justificados en creer que no es apropiado decidir su lógica de negocios para ellos.

Las personas que no han desarrollado software no saben lo que los desarrolladores de software necesitan saber. No se puede esperar que produzcan especificaciones de requisitos y casos de uso por su cuenta. Debe aplicar la obtención de requisitos. técnicas de para obtener la información que necesita saber. Trabaje con el cliente (y con suerte una muestra de usuarios de varios roles) para determinar qué necesitan o desean. Las técnicas comunes para esto son entrevistas y / u observación de usuarios, identificación de casos de uso e historias de usuarios, y creación de prototipos.

Recomiendo encarecidamente la aplicación de técnicas de desarrollo iterativas e incrementales en este caso, ya que tiene requisitos vagos, incompletos o poco conocidos. Mire las diversas metodologías ágiles junto con el modelo espiral para abordar la planificación del ciclo de vida.

Comience por obtener el objetivo comercial que impulsa el desarrollo de este software. Entreviste al cliente y a los usuarios, y si puede, mírelos en el trabajo. Intenta determinar qué problema están tratando de resolver. Vea qué herramientas están usando actualmente y cómo las usan para que pueda mejorar su forma actual de hacer las cosas. Aproveche esta oportunidad para aprender el dominio y su idioma: será infinitamente más fácil comunicarse si los desarrolladores de software y los clientes / usuarios hablan el mismo idioma (y no esperan que el cliente / usuarios hablen en términos de software).

Una vez que comprenda cuáles son los objetivos, puede comenzar a trabajar con las maquetas de diseño de interfaz de usuario que tiene y los casos de uso de "ingeniería inversa" y las historias de usuario de ellos en función de cómo encajan varias pantallas. El formato de la historia del usuario probablemente funcionaría bien para tratar con una audiencia no técnica. El formato de As a <user type>, I want to <action> so that <reason>funciona en términos de lograr que los desarrolladores y clientes / usuarios hablen el mismo idioma. Una vez que pueda comenzar con las historias de los usuarios, adoptaría un enfoque de desarrollo de prototipos.

Creo que abordaría esto con el uso de prototipos. Podría abordar esto desde una perspectiva de prototipos evolutivos o de prototipos desechables , pero primero consideraría un enfoque de prototipos evolutivos. Comience con las historias de usuario con las que se sienta más cómodo y validado, y comience a implementarlas. A medida que los implemente, obtenga comentarios del cliente y desarrolle nuevas historias de usuarios, casos de uso y resuelva malentendidos.

Además, no piense en esto como "implementar una interfaz de usuario con funciones debajo de ella". En cambio, piense en ello como finas rebanadas verticales. No implemente toda la interfaz de usuario a la vez y luego preocúpese por las características. En su lugar, use las maquetas de la interfaz de usuario para identificar características y otros requisitos, y luego implemente un corte vertical desde la interfaz de usuario hasta la lógica de negocios y el almacenamiento de datos. Repita esto para cada corte vertical. También debe sentirse libre de hacer sugerencias para mejorar la interfaz de usuario en función de los requisitos y principios de usabilidad.

Recomendaría leer dos libros de Karl Wiegers: Requisitos de software y más sobre los requisitos de software . Creo que estos lo ayudarán con la ingeniería de requisitos y las mejores prácticas en esta área.

Bueno, esta es una referencia inicial vergonzosamente obvia, pero Wikipedia podría ser un lugar para que usted y los usuarios comiencen. El hecho de que haya una entrada sobre estas cosas podría ayudarlos a convencerlos de que este es un problema real, no que usted sea un problema.

Más específicamente, ¿está desconcertado sobre lo que hace la aplicación, incluso después de repasar las maquetas? Si es así, admítelo y trata de explicar que no tienes idea de qué datos debe mostrar cada formulario, o de dónde vendrían, ¿son de otras pantallas o datos externos?

Si tiene alguna idea, intente encontrar ejemplos de cosas que no sabe cómo hacer ("¿la lista de plantillas para seleccionar será una lista global o alguna de ellas será por Usuario, o alguna otra? Si es no por el usuario, ¿debería dejar que dos personas lo editen a la vez? ¿Qué debería mostrar la interfaz de usuario si alguien más lo está editando? ¿Hay una pantalla para eso? ¿Debería ese cambio propagarse a lo que hicieron con la plantilla? ").

Deje en claro que con su nivel actual de conocimiento necesitará que le contesten preguntas aproximadamente cada 90 segundos durante el resto del ciclo de desarrollo, y que la mayor parte del tiempo no podrá seguir trabajando hasta que obtenga una respuesta. El objetivo debe ser dejar en claro por qué tener algún tipo de proceso lo hará todo más fácil. Mencione también que QA necesitará la misma información que usted, por lo que será más fácil escribirlo todo para que esté disponible para todos y nadie olvide nada.

Puede ser útil mencionar que parte del código que escribe afecta a más de una pantalla a la vez, por lo que si obtiene la mayor cantidad de respuestas por adelantado posible, podría ser más fácil escribir ese código de manera adecuada y no tener que cambiarlo más tarde.

Si aún no puede obtener los requisitos y realmente no sabe cómo proceder, envíe correos electrónicos cada vez que necesite más información (es decir, requisitos), y si no puede continuar trabajando sin esa información, indique claramente que desafortunadamente, no pueden continuar trabajando, porque el código que necesita escribir será muy diferente dependiendo de la (s) respuesta (s) a su (s) pregunta (s). No se queje, solo hágales saber muy profesionalmente que no puede escribir el programa hasta que sepa lo que debe hacer.

Debe conocer los límites y rangos para cada campo en la aplicación. Por ejemplo, si el campo es el número de teléfono, ¿esperan que maneje +1? ¿Qué campos son obligatorios? ¿Qué quieren que haga la aplicación si el usuario escribe "abc" en el campo de número de teléfono? ¿Están todas las 25 pantallas en el orden en que deben proceder todos los usuarios?

De lo contrario, simplemente cree todo como campos de texto y ¡listo! ¿Quieres apostar a que irá como un globo de plomo?