Necesito explicar a los programadores las necesidades de integración de un servicio basado en web en nuestro sitio web. Quiero encontrar la mejor estructura para tal solicitud.
¿Cómo debo describir las características que quiero desde un punto de vista no técnico?
No debe estar definiendo tareas para personas técnicas. En su lugar, debe describir una propuesta de valor y algunos criterios de aceptación comprobables, y luego dejar que sus expertos técnicos encuentren una solución que brinde el valor definido que está buscando.
Las historias de usuario son un buen vehículo para definir el valor. Usar el formato estándar de Connextra de "función, característica, razón" es un buen punto de partida. Por ejemplo:
Como cliente bancario
, quiero poder ver una lista de transacciones recientes
para poder conciliar mi chequera .
El rol (o "consumidor de valor") define la audiencia prevista de la característica. La función en sí describe lo que debe hacer la función y el motivo proporciona un contexto sobre por qué el usuario puede querer la función.
La característica se describe en términos de resultados , en lugar de especificar la implementación técnica subyacente. Restringir la implementación es generalmente una mala idea. En cambio, define un objetivo comercial o de UX y permite que el equipo técnico encuentre la mejor manera de cumplirlo.
La razón (o "contexto") también es muy importante. Usando el ejemplo anterior, hay muchas formas de mostrar un conjunto de transacciones. Sin embargo, al describir un caso de uso específico (por ejemplo, conciliar una chequera), está brindando orientación al equipo que puede ayudarlo a seleccionar la mejor implementación técnica para cumplir el objetivo entre las opciones disponibles.
Lo más importante que uno puede hacer, ya sea usando historias de usuarios o especificaciones, es asegurarse de que los objetivos se presenten de una manera comprobable . Si no es comprobable, es difícil llegar a un verdadero entendimiento entre el negocio y el equipo técnico.
Usando la historia de ejemplo anterior, uno podría usar la salida de la función para conciliar una chequera de muestra. Usted y el equipo técnico pueden definir una cuenta para John Doe de la siguiente manera:
Luego, esto se puede verificar mediante pruebas manuales o automatizadas. Si la prueba pasa, entonces la función se entregó con éxito e incluso se puede perfeccionar más en el futuro. Si las pruebas fallan, obviamente aún se necesita una solución que funcione.
Compare los consejos sobre buenas historias de usuario con una vaga historia de usuario como:
Como cualquier persona
, quiero ver una bonita lista de transacciones
utilizando una fuente atractiva.
Este tipo de historia es completamente subjetiva y no se puede probar. ¿Quién usará esta característica? ¿Qué es "bonita"? ¿Qué fuente se considerará atractiva? Ni el equipo técnico ni el negocio pueden triunfar con criterios tan ambiguos como este.
Por otro lado, la especificación excesiva tampoco es tu amiga. Considere este ejemplo:
Como usuario 321
, quiero ver exactamente 10 transacciones de cheques
en una fuente sans serif de 6 puntos llamada "Obscure Sans".
Este tipo de especificación es probablemente comprobable, pero restringe demasiado la solución. Es posible que la solución implementada solo se aplique a un único usuario, que debe especificarse mediante un ID numérico. No aborda todos los casos extremos posibles (p. ej., ¿qué sucede si el usuario 321 solo tiene 6 transacciones en total?) y fuerza una implementación técnica, como una elección de fuente específica que puede o no funcionar en todos los navegadores, o incluso ser legible. en el tamaño de fuente especificado.
Es probable que tanto las historias vagas como las historias sobreespecificadas den lugar a fallas o errores absolutos. Sin embargo, si tienes que equivocarte, ¡al menos comete un error en el lado de la comprobabilidad!
Las historias siempre deben definirse en términos comerciales . ¿ Por qué tiene que haber integración web? ¿Para quién es? ¿Qué necesita lograr exactamente?
Si no está directamente relacionado con un requisito comercial (poco probable para la integración web, pero teóricamente posible), entonces debería ser una tarea del desarrollador y, por lo tanto, debería ser definida por un desarrollador.
Los desarrolladores definen las tareas del desarrollador. Las personas que no son desarrolladores definen las historias comerciales: si es necesario completar más detalles técnicos, los desarrolladores pueden hacerlo ellos mismos. Idealmente, esto debería hacerse en colaboración con alguien que comprenda el aspecto comercial, para detectar rápidamente malentendidos con respecto a lo que se supone que la historia realmente logrará.
Imagina que vas al hospital y te encuentras con un médico para que te ayude porque tienes dolor en el pecho. ¿Le dices al Dr de inmediato: "Tengo un problema cardíaco, acabo de leer webmd, necesito un trasplante de corazón, prográmalo para mañana"? Obviamente, estoy seguro de que podría entender por qué un Dr. podría sonreír en esta circunstancia.
Lo que sueles hacer es decir “tengo un dolor en el pecho, empezó hace una hora”. El dr podría preguntar "¿qué almorzaste?". Es posible que le hagan un análisis de sangre o le hagan un electrocardiograma. Pueden concluir que solo tiene reflujo ácido.
Mi punto es... Una "integración" es una solución. No es un problema. Explique el problema. Los técnicos se desaniman cuando los no técnicos se acercan a ellos con soluciones. Las personas no técnicas tienden a tropezar accidentalmente con buenas soluciones técnicas, si es que alguna vez lo hacen (énfasis en lo no técnico). Sí, de vez en cuando hay gente muy espabilada que es la excepción... Pero es mejor hacerse el tonto y dejar que lleguen los técnicos. Han tenido demasiados encuentros con la norma que les enseña lo contrario.
Mayormente de acuerdo con @codegnome y solo resumiendo y agregando mis 2 centavos
Piotr Uryga