Portada
mis comunidades
otras secciones
#3:
Depende, si se encarga un product manager junto con un senior después de un brainstorming en el meeting de las three, el goal lo consigues fijo
Comentarios
Depende, si se encarga un product manager junto con un senior después de un brainstorming en el meeting de las three, el goal lo consigues fijo
#3 no te pases que no lo ha llamado "feature"
#3 no digas meeting, di call
Output, outcome, release.
Parece que nos hemos quedado sin palabras en castellano. ¿Alguien amable puede avisar a la RAE?
#1 Todas traducen igual: marronazo
#16 Es verdad, era la del otro comentario. La tuya a la que respondía con lo de agile es:
"La importancia que se le da a un entregable y el poco estudio que se hace posteriormente sobre si realmente mereció la pena el esfuerzo, a veces, cuando incluso los recursos son muy limitados."
Cuando la filosofía de estas metodologías es ir haciendo seguimiento de cada entrega (nunca un gran entregable) y validar con el cliente los cambios que quieren. Eso también evita que el cliente te pida cualquier cosa, lo usen o no. El cliente te pedirá lo que le urge que es razonable que vaya a usar porque le urge. Y, si no lo usa, solo habrás perdido uno o dos ciclos, nunca habrás llegado a crear un producto que no usa.
#c-17" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3399328/order/17">#17 Tampoco es mi comentario
Pero tampoco es un enfoque realista. El cliente te pedirá lo que cree que necesita, sea cierto o no.
Una metodología ágil tiene el beneficio de localizar desacuerdos cliente/producto en una fase temprana. Pero lo que quiere el cliente, y que lo usen o no, son cosas diferentes.
Si tu cliente es tu equipo de ventas. Quiere lo que tiene la competencia aunque los usuarios no lo usen.
Sí tú cliente es el Project Mánager porque es un SAAS, tampoco sabes si lo van a usar. Puede ser algo que tenga la competencia, algo pedido por usuarios, algo que falta...
Si tú cliente es un usuario final en un desarrollo personalizado que aún no han probado... puede que ni siquiera sepan qué es lo que necesitan
Eso, que agile arregla errores de comunicación y de planificación del proyecto, alineado desarrollo y cliente. Pero que el cliente pida algo que realmente necesita es otra historia. Y que sea algo que van a usar (puedes necesitar cosas que no se usan para que no te descarte el equipo de compras de los usuario#), otra
#18 Es que la base de todo esto es que el cliente siempre ha de ser el usuario. Si es un Manager que solo lleva a los que usan el producto, lo que ha de hacer es dejar paso en las reuniones técnicas a alguien de su equipo que lo use y sepa lo que de verdad necesita, y el Manager que se dedique a hablar con un manager del proveedor sobre dinero y recursos, que ese es su trabajo (y no el técnico) .
#19 Bueno, pero es que eso que pides no es posible en la gran mayoría de casos.
De todas formas, dentro de Scrum no se define qué es cliente. Aunque en el examen si que especifican el equipo de ventas como cliente para las Sprint reviews
¿Que acualo?
Más allá de lo creíble que sea o no esta estadística, si que creo que merece la pena reflexionar sobre algo que observo muy comunmente en los equipos que desarrollan productos digitales: La importancia que se le da a un entregable y el poco estudio que se hace posteriormente sobre si realmente mereció la pena el esfuerzo, a veces, cuando incluso los recursos son muy limitados.
Porque este señor no hace plataformas B2C. Cualquier cambio en el sistema lo registras con eventos para ver el impacto en el embudo de ventas.
De todas formas, entiendo la base de su argumento. Pero está dándole demasiada importancia al uso real de la aplicación. El uso real de la aplicación no importa. Si el cliente tiene que elegir entre el mío y el otro idéntico pero con lucecitas elegirá el otro. ¿Qué haces? ponerle más lucecitas que nadie para que elija el mío. El cliente tiene una tabla de excel con características, se las va marcando, y los que menos cruces tengan no pasan la linea de corte. ¿Tiene lucecitas? sí, pues elimino al otro. "Todo es mejor con wifi", dirían en Big Bang Theory.
Se lo digo muchas veces a mis compañeros. "Esto no aporta valor, pero es necesario para el equipo de ventas". Lo hacemos igualmente, pero al menos no se sienten imbéciles. O eso creo. Saben que para el usuario es inútil, pero para la empresa no y eso hace que no sea un trabajo perdido.
#10 siendo el que mejor ha interpretado el artículo, es que va más allá de eso incluso.
Es algo muy utópico, pedir que la organización y las distintas fases desde la adquisición, producción, inventario, venta, marketing, relación con clientes, etc..., de una empresa desde una grande hasta una micropyme se transforme en una organización digitalizada por muchas funcionaladidades que implemente en su sistema si los usuarios no las utilizan o no le sacan el 100% de sus posibilidades.
Se aprovecha lo que les iba bien en su antigua forma de trabajar y ya está, a la gente no les gustan los cambios, diría incluso que les da pánico y no hablo del currito básico, se da con frecuencia a niveles de los ingenieros, jefes de departamento, control de calidad, contables, de sus informes básicos tradicionales no los saques, cuando los sistemas actuales permiten análisis y previsiones que optimizan la gestión, o ayudan a la toma de decisiones que ni las consultan.
Te hablo de Erp, CRM, BBDD documentales, etc..., se implementan funcionalidades para nada, con programitas casi piratas para lo que los usan, y un Excel ya les iría bien para cumplir el expediente
#11 #10 Habéis probado con metodologías agile, creadas casi expresamente para evitar lo que vosotros y el artículo decís?
#13 No veo la relación con mi mensaje.
#14 "se implementan funcionalidades para nada, con programitas casi piratas para lo que los usan, y un Excel ya les iría bien para cumplir el expediente"
En una metodología agile, si no lo usa nadie, no se implementa.
#15 No es mi frase.
De todas formas, no es así. Con metodologias ágiles cambias el desarrollo a lo que te diga el cliente con iteraciones periódicas.
Pero el cliente te.puede pedir cualquier cosa, lo usen o no. Por ejemplo, durante el desarrollo de una solución que aún no esté en el mercado el cliente es el jefe de producto, o el equipo de ventas, o cualquier otro agente.
¿El ouput, es el ostiaputa de siempre?.
Esto suena a producto de software noventero. Perdón, de los nineties.
Lo rentable son las aplicaciones que hacen una sola cosa.
Madre mía qué vergüenza ajena.