2021-04-22La práctica del paradigma de la demanda: cómo evitar la disipación y la distorsión en el proceso de transmisión de la demanda.

Para evitar al máximo la disipación y distorsión de esta información de la demanda, puedo resumirla de dos maneras. Una es minimizar la longitud de la cadena de transmisión y la otra es intentar que la información sea entendida por ambas partes.

Este artículo registra la práctica de "replicación de requisitos" que intentamos en el proyecto para ayudar al equipo del proyecto a alcanzar una comprensión consistente de los requisitos. Sería muy gratificante inspirar y ayudar a los compañeros.

La persona a cargo del lado de la demanda, a, me llamó y me dijo que había discutido los requisitos con el ingeniero de demanda P, pero que le preocupaba que P no entendiera nada. Me volvió a describir las necesidades, dijo tres cosas, balabala, unos minutos. Pensó que era relativamente simple y me pidió que prestara atención para ver si P entendía las necesidades. Como no estaba familiarizado con mi experiencia empresarial, comencé a perder la concentración durante el discurso de A.

Encontré a P, le pregunté al respecto y descubrí que A se lo había contado verbalmente. Hizo una estimación de la carga de trabajo y también mencionó algunas dudas al describirla, pero ya estaba listo para empezar. Le pedí que organizara los requisitos en documentos y luego le pedí a la Organización A que celebrara una reunión para discutir y confirmar.

A concertó una cita con los jefes de dos departamentos de ventas, y luego la tarde comenzó a la 1:40 y la discusión terminó a las 5:00. Durante la discusión, descubrimos muchas cosas que no se habían mencionado antes y también confirmamos muchos escenarios comerciales y operaciones funcionales específicas.

Después de varias horas de intensa discusión, todos pensaron que todos los puntos clave a discutir estaban cubiertos. Sin embargo, todavía no estaban seguros de si P lo entendía bien, por lo que le pidieron que hablara sobre los requisitos al revés. y traiga los roles utilizados. Vaya a los escenarios específicos de cada enlace y describa el proceso comercial completo desde la perspectiva de las operaciones comerciales. Entonces P estaba un poco confuso al principio. Después de ajustes simples, explicó con fluidez el proceso comercial y las operaciones funcionales, y encontró varias inconsistencias. Después de discutir y confirmar con el personal de la empresa, finalmente todos llegaron a un acuerdo.

Este proceso de discusión de requisitos requiere mucho tiempo y es laborioso, pero evita una serie de retrabajos en el período posterior.

Un día, en la reunión de pie, el evaluador dijo que era necesario revisar un punto de prueba para esta iteración. Lo mencioné y al juzgar, él hablaba primero de las necesidades.

Analistas y desarrolladores de requisitos participaron en la reunión de revisión, y los ingenieros de pruebas unieron los requisitos basándose en escenarios comerciales. En general, se puede ver que la lógica de negocios entendida por los evaluadores y la lógica de negocios entendida por los analistas de requisitos son consistentes.

En el proceso de hablar, el analista de requisitos obtuvo la perspectiva de un espectador que piensa en los requisitos, descubrió cosas que no se habían descrito claramente antes y también descubrió cosas que los evaluadores no habían notado, pero durante el proceso. proceso de comunicación de requisitos Algo que efectivamente se mencionó.

Debido a que cada iteración no tiene demasiados puntos funcionales, la reunión de revisión durará unos 20 minutos. Es una reunión sencilla pero eficaz.

La inversión de requisitos aumentará el tiempo de una sola reunión, pero puede evitar la duplicación causada por una comprensión inconsistente en el futuro.

Pero si hay demasiado contenido que discutir, hablar de necesidades se vuelve poco realista. Por lo tanto, es muy importante dividir los requisitos en pequeñas iteraciones para su comunicación y confirmación.

Por supuesto, cuando hay mucho contenido de comunicación al mismo tiempo, también puedes seleccionar puntos clave individuales y los importantes para revisarlos y confirmarlos.

Además, al explicar los requisitos a los desarrolladores, puede elegir entre varios ingenieros de desarrollo para decidir quién hablará sobre un módulo por turno, lo que también puede mantener la atención de los participantes.