¿Qué es un estándar de calidad apropiado para las especificaciones de requisitos?

En mi función como analista comercial que trabaja para una empresa en el extranjero (7 desarrolladores, 4 QA, 1 PM, 1 arquitecto) pero estando en el sitio, reviso los documentos de requisitos comerciales, epopeyas e historias informadas por los propietarios del producto (PO) y escribo un especificaciones más detalladas para un equipo offshore. Es un sprint de 2 semanas, y las historias, los diseños a menudo llegan no más de 2 o 3 días antes del día de planificación del sprint. Sin mencionar que los diseños son manejados por un equipo separado en sí mismo y, a veces, también hay una desconexión entre PO y Diseño. Además, hay clientes que tienen sus propios propietarios de productos y diseñadores que realizan solicitudes, cambios y prioridades de última hora para personalizarlo o marcarlo en blanco para ellos.

Para agregar más complejidad, NO participo en las discusiones de PO-Design o PO-Client. Con esto dicho, intento leer los documentos en wiki, ver los diseños que están disponibles actualmente, mientras que Diseño está tratando de pulirlos y afinarlos (en su mayoría son diseños iniciales mínimos básicos obsoletos), lea Documentos de requisitos comerciales-BRD (que a menudo están en un nivel alto y en su mayoría no están actualizados como lo que está en el Diseño actualmente)

Entonces, con estas limitaciones, retomo las historias (alrededor de 8 a 10) que están programadas específicamente para el equipo offshore.

  1. Revise las historias que están listas para trabajar (responsabilidad documentada dicha por el Cliente; parece bastante amplia y cubre la mayor parte del trabajo a continuación),
  2. Definir casos extremos
  3. Proporcione información más detallada sobre cada línea de Criterios de aceptación (AC)
  4. Agregue los recursos necesarios a la descripción de la historia/característica (cualquier contenido como XML que deba usarse, cualquier wiki que deba señalarse para obtener más información o elementos de diseño que falten)
  5. Coordine con Design, PO, PM, Scrum Master para que todo sea perfecto
  6. Facilite llamadas de conferencia para repasar todas las historias (Story Time) cada jueves de Sprint. Explíquelas tanto como sea posible.
  7. Responder sus consultas/aclaraciones que llegan todos los días (a veces son preguntas demasiado obvias y poco claras; a menudo me toma todo el día)
  8. Demostración de historias completadas por el equipo Offshore (preparación de la página Wiki, información, datos de prueba)
  9. Realice pruebas de aceptación para historias de equipos en alta mar, prepare un documento y páselo a los PO reales
  10. Revisión diaria del foro de discusión de Rally y respuesta, contactando a los líderes tecnológicos y desarrolladores necesarios en el sitio para obtener información sobre esto
  11. Revisar casos de prueba y aprobar

Con todas estas cosas hechas, cuando cualquier pequeño problema se arrastra para detener la finalización de la historia según la definición de hecho. El equipo offshore me señala por completo con el dedo.

¿Qué es un estándar de calidad apropiado para una especificación de requisitos? ¿Cómo podemos diseñar un proceso para adaptarse de manera más flexible a los cambios en los requisitos?

Hola, Oneworld, aquí hay muchas preguntas, lo que dificulta que los usuarios voten por las mejores respuestas, ya que algunos solo elegirán responder ciertas preguntas. Le sugiero que lo edite para centrarse en una pregunta específica y luego lo marque y podamos volver a abrirlo. También es posible que tenga más de una pregunta que pueda publicar por separado, siempre que las preguntas estén enfocadas. ¡Buena suerte! :)
Ahora lo he hecho más centrado en los requisitos, espero que esto ayude a abrir esta pregunta.
Hice una edición rápida: parte del material que eliminé es un candidato para el lugar de trabajo.stackexchange.com. Intenté centrar la pregunta en el problema que es más relevante para PM: la especificación de sus requisitos se mantiene en un estándar de calidad irrazonable (100 % libre de errores). Esa podría ser una meta, pero creo que tienen que darle un camino para llegar a esa meta, y sospecho que usted no es el único actor en el proceso, y una meta del 100 % requerirá un esfuerzo heroico por parte de todos los actores en el proceso. proceso.
+1 Muchas gracias por editar. Su respuesta también es excelente, y espero poder transmitirla de esta manera a mi alta gerencia y a mis compañeros de equipo. ¡Lo aprecio! ¡Espero que la pregunta se vuelva a abrir y las sugerencias fluyan!
¡Buen trabajo de edición @MarkC.Wallace y oneworld! Seguiré adelante y reabriré. Debido a que esta es una pregunta subjetiva, lo ideal es que las respuestas sean exhaustivas. Deje comentarios aclaratorios para ayudar a otros a proporcionar respuestas buenas y completas. ¡Buena suerte! :)
Solo quería señalar que tal vez revisar el flujo de trabajo y las responsabilidades y responsabilidades del paquete de trabajo podría ayudar en su situación. El equipo extranjero (entiendo que son los implementadores reales) lo ve como el propietario de sus requisitos, por lo que siempre se refieren a usted por requisitos insuficientes cada vez que hay un aumento de requisitos o un problema. Creo que este comportamiento podría ser la única opción que tienen, y si es así, no puedo culparlos. El problema, según entendí, no es solo la calidad de los requisitos.

Respuestas (1)

Esta sigue siendo una pregunta muy compleja, y creo que es posible que una respuesta clave una parte y pase por alto el todo. Todavía estoy pensando en el problema, pero mientras tanto, encontré la siguiente cita hoy

La especificación de diseño debe regirse de manera diferente a los requisitos. Si los requisitos se rigieron adecuadamente, y si los requisitos comienzan predominantemente con el término "El sistema debe...", entonces nuestros líderes de diseño y desarrolladores deben tener en cuenta nuevos factores al regir la fase de diseño. Dado que el diseño es la traducción de los requisitos comerciales y técnicos en una especificación que se puede desarrollar, en este punto del proyecto debemos considerar lo siguiente

Lo que sigue son algunos criterios para traducir los requisitos en una especificación de diseño.

Creo que tiene un problema de garantía de calidad, y la solución es observar el proceso de transformación de historias incipientes en diseños producibles. Nominalmente hay tres etapas que podrían fallar.

  1. Los datos subyacentes que obtenga podrían ser defectuosos. Parece que obtienes MUCHOS datos, y tengo que preguntarme si algunas de las fuentes son más confiables que otras. Si priorizar aquellas fuentes que dan como resultado requisitos mejorados y especificaciones de diseño no mejoraría el proceso.
  2. Tú. Es posible que le falten los conocimientos, habilidades, habilidades, etc. necesarios para trabajar en el proceso. Si es así, entonces su gerente debe organizar una capacitación para mejorar su habilidad. No digo esto para insultarte, sino para ser comprensivo.
  3. Salida: tal vez los requisitos sean buenos, pero la traducción a las especificaciones de diseño es inadecuada. Tal vez la interfaz entre usted y el equipo de diseño tenga algo de ruido. (Parte del material que edité de su pregunta y le recomendé que llevara a Workplace SE puede respaldar esta tesis, pero buscaría una confirmación objetiva).

Si estuviera en tu lugar, estaría buscando un par de cosas.

  • Algún tipo de métrica de calidad acordada: algún estándar objetivo y acordado que podríamos usar para gestionar la mejora. Número de requisitos que se implementan sin cambios. Número de reuniones requeridas para producir un requisito exitoso. Pero tiene que ser una métrica que usted, su gerencia y sus clientes intermedios (los que se quejan) acepten. Averigüe cuál es la calidad hoy y comprométase a mejorarla en un N% para X fecha. (Incluso si lo mejor que puede hacer es "25 % de los requisitos son exitosos, pero para el 30 de junio 30 % de los requisitos serán exitosos", o "17 % de los requisitos necesitan 3 o más reuniones para aclarar; para el 1 de julio, ese número será el 10% de los requisitos necesita 3 o más reuniones..."
  • Análisis de causa raíz de cada requisito fallido. ¿Por qué este requisito no fue satisfactorio? ¿Qué era necesario cambiar y en qué punto del proceso debería haberse detectado el error? ¿No tenías los datos correctos? ¿El equipo de diseño está usando una definición diferente de términos comunes?
  • Apoyo de la gerencia. Infiero de su pregunta que tiene algunos procesos disfuncionales y fuera de control, y que estos están generando fricciones dentro de la empresa. Todas las partes involucradas (usted, el equipo de diseño, el PO, la gerencia corporativa, el resultado final, el cliente) se beneficiarán al reducir esa fricción y mejorar el proceso. Pero cambiar los procesos sin el apoyo activo de los gerentes de ambas partes es... arriesgado.

Estás trabajando en algún tipo de variante de scrum, y no estoy iniciado en el Evangelio de Scrum; Me encantaría escuchar los comentarios de algunos de nuestros Diáconos de Scrum sobre el problema. Según mi comprensión limitada de scrum, creo que tiene un problema importante. Mi impresión es que se supone que Scrum facilita una comunicación más efectiva, y no parece estar haciendo esto en su caso.

+1 por dos cosas: mencionar el análisis de causa raíz para requisitos fallidos y métricas para mejorar. Sin embargo, me pregunto si estos se pueden aplicar prácticamente en un lugar de trabajo sin causar aún más fricción: hay gente que señala con el dedo, y podría tomar algunos viajes, cara a cara, esfuerzos de formación de equipos para fusionar las perspectivas.
¿Qué es un estándar de calidad apropiado para las especificaciones de requisitos?
RespuestasAquíPolítica de privacidad1y, 0v