¿Cómo gestionar los desajustes entre las especificaciones de diseño y los ajustes posteriores al diseño?

¿Cómo manejas este escenario?

  • UX y diseño visual una característica.
  • PO y DEV decidieron, después de que se aprobó el diseño, ignorar algunas especificaciones de implementación, por lo que tenemos algo diferente a las especificaciones de diseño.

¿Dónde debe ubicarse esta información? Porque SM terminó con una discusión con las partes interesadas (PO está enfermo) y después de su verificación del ticket de JIRA, vio que el diseño y la implementación del sitio web no estaban alineados. Después de haber creado un error, un DEV le dijo que se discutió con PO para implementarlo así. Por lo tanto, la implementación de diseño diferente no se informa en ninguna parte.

En mi opinión, estas actualizaciones de especificaciones (ignoradas) deberían permanecer en la página de diseño (Zeplin, Confluence, lo que sea...). ¿Estás de acuerdo? Porque de lo contrario, para cualquiera que pierda esa información, este escenario puede parecer un ERROR. La parte que falta podría convertirse en una nueva CARACTERÍSTICA, con comentarios nuevamente agregados.

¿Estás de acuerdo? ¿Qué piensas?

Una falta de comunicación obvia es que la parte interesada no se mantuvo al tanto cuando la OP decidió ignorar algunas partes de las especificaciones. Esto es independiente de si/dónde debe documentarse el cambio.

Respuestas (1)

Parece que su organización usa los tickets de Jira como su fuente central de información (es decir, su SM mira los tickets de Jira), por lo que los tickets de Jira deben contener comentarios breves sobre cómo han cambiado las decisiones de implementación y por qué.

Ponga un enlace en el ticket que apunte al directorio de diseño apropiado. De esta forma, el ticket siempre hace referencia a la versión más reciente del diseño visual.

Como usted dice, en un mundo ideal, el diseño en sí debería haber sido reelaborado, o al menos anotado, para señalar las funciones que se entregarían en diferentes momentos... pero eso rara vez es posible en un lugar de trabajo acelerado.

Definitivamente convierta las características "sobrantes" o sin prioridad en historias separadas para la acumulación. Y márquelos como relacionados con la historia original, para la continuidad.

JIRA es nuestro backlog, pero en nuestra empresa también contamos con Zeplin para nuestros proyectos de diseño. Así que creo que, una vez que se resuelve un ticket de JIRA y desaparece del backlog, esas notas de JIRA podrían perderse. Por eso creo que Zeplin o Confluence podrían ser un buen lugar para anotar esa información.
@axel En mi opinión, nunca está de más escribir algunas palabras en un ticket para describir un cambio. Sí, si su organización tiene el ancho de banda para volver a hacer el diseño/notas de diseño, y tiene la autoridad para instruir al departamento de diseño para que lo haga, el área de diseño es el mejor lugar. Sin embargo, no siempre es factible.
no me malinterpreten, los tickets de JIRA también pueden contener esa información, especialmente durante el progreso del ticket de ABIERTO a LISTO, pero en mi opinión no es suficiente. Hice la pregunta porque sobre este tema escuché muchas formas de cuidarlo, así que también pongo mi pregunta aquí.
¿Cómo gestionar los desajustes entre las especificaciones de diseño y los ajustes posteriores al diseño?
RespuestasAquíPolítica de privacidad1y, 0v