No quiero dar detalles, pero escucho a diario las historias de terror de mi pareja (programadora igual que yo) sufriendo por requerimientos completamente indefinidos y cuando le pregunta al JP este responde "yo imagino que lo que quieren es esto". "Yo imagino" ¿qué podría salir mal?
Justo acá ayer un dev tuvo una retro de QA que le planteo un caso no planteado originalmente en el "requerimiento", y la lead el proyecto dijo lo que debía suceder. Pregunté que decía Producto al respecto. La respuesta fue 'ellos ni siquiera tienen idea de este flujo', así que básicamente nos imaginamos lo que debería ocurrir en esos casos :/
Es todo un tema lo de las HU. Me gusta la mirada del documento de visión, la memoria es muy frágil, las HU a mi modo de ver no logra documentar realmente que realmente cual es el objetivo de lo que se debe construir.
Estoy completamente de acuerdo. Tómalo como un comentario para reforzar tu punto. Aunque en realidad me estaba desahogando: he escuchado demasiadas veces la queja de que los "usuarios escriben malas historias/especificaciones".
Porque somos los informáticos los que se supone que estamos entrenados para preguntar, entender, preguntar, guiar el proceso y redactar historias/especificaciones.
Estás hablando de una especificación o de una historia de usuario, en el texto por historia de usuario me refiero a lo señalado por scrum: como ... quiero .... para ..., puedes aclarar si te refieres a eso?
Aunque las historias son menos complejas que las especificaciones de requerimientos, me refiero a las dos. Ambas deben ser redactados por el informático en colaboración con el usuario/experto en el negocio.
Entiendo, en el texto yo digo “Lo importante es que lo escriba alguien que representa al negocio, llámenlos product owner, product manager, analista de negocios, lo que sea, tiene que ser alguien que haga la investigación necesaria, que conozca la operación, que ojalá viva con o experimente los problemas de primera mano”. Si es o no un informático o un miembro del equipo que construye después me da lo mismo mientras tenga la capacidad de investigar y experimentar el proceso de primera mano.
En mi trabajo los product managers son los que hacen esto, y los ingenieros son los que escriben los diseños.
Creo que lo importante es plasmar bien el “dolor” que se quiere resolver y eso requiere una buena investigación, si lo hace el team o un tercero da lo mismo, en mi opinión, lo relevante es que los usuarios se sientan bien representados por esa especificación (o sean bien representados si se trata de un producto) y quiénes desarrollan sientan que tienen buen material para trabajar.
El punto del post es que cuando se implementan cosas como scrum se tiende a dejar esa responsabilidad a los usuarios, “porque deben estar involucrados” y para facilitarles el trabajo les proponen un artefacto demasiado liviano como la historia de usuario (artefacto que cada vez más encuentro inútil). Esa aproximación no va a funcionar y creo que estamos de acuerdo en eso, en parte porque no están entrenados y en parte porque tal como la vendedora de la historia, es responsabilidad del equipo extraer el requerimiento del cliente y ayudarle a sorprender al usuario final.
"El problema que ocurre es que los usuarios nunca aprenden a escribirlas bien (las historias de usuarios)". Se escucha mucho. En mi opinión, es responsabilidad de uno como informático escribirlas bien (ya sea las historias o las especificaciones), no del usuario.
No quiero dar detalles, pero escucho a diario las historias de terror de mi pareja (programadora igual que yo) sufriendo por requerimientos completamente indefinidos y cuando le pregunta al JP este responde "yo imagino que lo que quieren es esto". "Yo imagino" ¿qué podría salir mal?
Justo acá ayer un dev tuvo una retro de QA que le planteo un caso no planteado originalmente en el "requerimiento", y la lead el proyecto dijo lo que debía suceder. Pregunté que decía Producto al respecto. La respuesta fue 'ellos ni siquiera tienen idea de este flujo', así que básicamente nos imaginamos lo que debería ocurrir en esos casos :/
Es todo un tema lo de las HU. Me gusta la mirada del documento de visión, la memoria es muy frágil, las HU a mi modo de ver no logra documentar realmente que realmente cual es el objetivo de lo que se debe construir.
Estoy completamente de acuerdo. Tómalo como un comentario para reforzar tu punto. Aunque en realidad me estaba desahogando: he escuchado demasiadas veces la queja de que los "usuarios escriben malas historias/especificaciones".
Ese es el drama de fondo, no tienen por qué.
Porque somos los informáticos los que se supone que estamos entrenados para preguntar, entender, preguntar, guiar el proceso y redactar historias/especificaciones.
Estás hablando de una especificación o de una historia de usuario, en el texto por historia de usuario me refiero a lo señalado por scrum: como ... quiero .... para ..., puedes aclarar si te refieres a eso?
Aunque las historias son menos complejas que las especificaciones de requerimientos, me refiero a las dos. Ambas deben ser redactados por el informático en colaboración con el usuario/experto en el negocio.
Entiendo, en el texto yo digo “Lo importante es que lo escriba alguien que representa al negocio, llámenlos product owner, product manager, analista de negocios, lo que sea, tiene que ser alguien que haga la investigación necesaria, que conozca la operación, que ojalá viva con o experimente los problemas de primera mano”. Si es o no un informático o un miembro del equipo que construye después me da lo mismo mientras tenga la capacidad de investigar y experimentar el proceso de primera mano.
En mi trabajo los product managers son los que hacen esto, y los ingenieros son los que escriben los diseños.
Creo que lo importante es plasmar bien el “dolor” que se quiere resolver y eso requiere una buena investigación, si lo hace el team o un tercero da lo mismo, en mi opinión, lo relevante es que los usuarios se sientan bien representados por esa especificación (o sean bien representados si se trata de un producto) y quiénes desarrollan sientan que tienen buen material para trabajar.
El punto del post es que cuando se implementan cosas como scrum se tiende a dejar esa responsabilidad a los usuarios, “porque deben estar involucrados” y para facilitarles el trabajo les proponen un artefacto demasiado liviano como la historia de usuario (artefacto que cada vez más encuentro inútil). Esa aproximación no va a funcionar y creo que estamos de acuerdo en eso, en parte porque no están entrenados y en parte porque tal como la vendedora de la historia, es responsabilidad del equipo extraer el requerimiento del cliente y ayudarle a sorprender al usuario final.
"El problema que ocurre es que los usuarios nunca aprenden a escribirlas bien (las historias de usuarios)". Se escucha mucho. En mi opinión, es responsabilidad de uno como informático escribirlas bien (ya sea las historias o las especificaciones), no del usuario.
Por qué?