[agile-spain] Vender un proyecto con metodologia Scrum
1,122 views
Skip to first unread message
Jonathan Vila Lopez
Dec 2, 2009, 6:56:26 AM12/2/09
to agile...@googlegroups.com
Hola.
Soy un total novato en esto de las metodologías ágiles, así que me surge una duda existencial.
Siempre he estado en compañías, generalmente pequeñas, en las que se vendían los desarrollos de software a medida a precio cerrado.
Generalmente se hacia un análisis sencillo y se calculaba ( a ojo ) el tiempo y de ahí se sacaba la duración o plazo de entrega.
Lo del precio ya se hacia de otra forma......muy pedestre...... cuánto valor le aporta al cliente ? cuánto beneficio obtendrá por mi producto ? qué capacidad de pago tiene ? y de ahí salía el precio.....
No entraré a calificar la forma ni a juzgarla.........no es el objetivo de este mail.
Mi pregunta es la siguiente.... en el caso que un posible cliente solicite ofertas a varios proveedores, entre ellos nosotros que somos una compañía inventada que trabaja usando Scrum,...... :
[ ojo , todo en el supuesto que por mi experiencia las compañias "engañan" al cliente con los plazos y se "engañan" a si mismas con el precio ..... pero que parece que es una practica totalmente aceptada ]
1. cómo podemos competir contra ese precio cerrado de las otras compañías ? ya se que nosotros ofreceremos una visión mas real , pero hay muchos clientes que tal vez no sean capaces de ver eso puesto están acostumbrados a otra cosa.........
2. cómo un proyecto que se vaya a desarrollar en metodología Scrum, puede llegar a dar un precio cerrado o algo parecido ?
3. si el cliente no tiene ni idea de Scrum, ni de ninguna otra metodología de desarrollo puesto que es una empresa de frutas ( por poner un caso ) que nos solicita informatizar un área..........
3.1. cómo se le puede rebatir la oferta de las otras compañías que no usan Scrum ?
3.2. cómo se le puede presentar la mejora de "nuestra" metodología en un calculo de ROI o predicción de Valor Ganado ?
4. cómo explicarle que a diferencia de las otras compañías que no incurren en mucha implicación por parte del cliente, nosotros añadimos un "sobre coste" al desarrollo por la alta implicación del cliente ?
Vamos, que yo entiendo que Scrum y cualquier metodología Ágil nos mejora muchísimo el proceso de construcción del software ( y de otros productos ), pero lo que no veo tan claro es cómo se le puede vender eso a alguien que solo entiende de números y dinero.
Entiendo que una metodología Ágil no puede dar precio cerrado a nada porque se basa en una construcción evolutiva y por Sprints.......y que aunque el dueño del producto defina los requerimientos éstos no se detallan hasta el Sprint en que son desarrollados..........
Tal vez estoy totalmente equivocado y espero me lo podáis explicar.......
Muchas gracias.
-----------------------------------------------
Slitzweitz !!!!!!
Soy un total novato en esto de las metodologías ágiles, así que me surge una duda existencial.
Siempre he estado en compañías, generalmente pequeñas, en las que se vendían los desarrollos de software a medida a precio cerrado.
Generalmente se hacia un análisis sencillo y se calculaba ( a ojo ) el tiempo y de ahí se sacaba la duración o plazo de entrega.
Lo del precio ya se hacia de otra forma......muy pedestre...... cuánto valor le aporta al cliente ? cuánto beneficio obtendrá por mi producto ? qué capacidad de pago tiene ? y de ahí salía el precio.....
No entraré a calificar la forma ni a juzgarla.........no es el objetivo de este mail.
Mi pregunta es la siguiente.... en el caso que un posible cliente solicite ofertas a varios proveedores, entre ellos nosotros que somos una compañía inventada que trabaja usando Scrum,...... :
[ ojo , todo en el supuesto que por mi experiencia las compañias "engañan" al cliente con los plazos y se "engañan" a si mismas con el precio ..... pero que parece que es una practica totalmente aceptada ]
1. cómo podemos competir contra ese precio cerrado de las otras compañías ? ya se que nosotros ofreceremos una visión mas real , pero hay muchos clientes que tal vez no sean capaces de ver eso puesto están acostumbrados a otra cosa.........
2. cómo un proyecto que se vaya a desarrollar en metodología Scrum, puede llegar a dar un precio cerrado o algo parecido ?
3. si el cliente no tiene ni idea de Scrum, ni de ninguna otra metodología de desarrollo puesto que es una empresa de frutas ( por poner un caso ) que nos solicita informatizar un área..........
3.1. cómo se le puede rebatir la oferta de las otras compañías que no usan Scrum ?
3.2. cómo se le puede presentar la mejora de "nuestra" metodología en un calculo de ROI o predicción de Valor Ganado ?
4. cómo explicarle que a diferencia de las otras compañías que no incurren en mucha implicación por parte del cliente, nosotros añadimos un "sobre coste" al desarrollo por la alta implicación del cliente ?
Vamos, que yo entiendo que Scrum y cualquier metodología Ágil nos mejora muchísimo el proceso de construcción del software ( y de otros productos ), pero lo que no veo tan claro es cómo se le puede vender eso a alguien que solo entiende de números y dinero.
Entiendo que una metodología Ágil no puede dar precio cerrado a nada porque se basa en una construcción evolutiva y por Sprints.......y que aunque el dueño del producto defina los requerimientos éstos no se detallan hasta el Sprint en que son desarrollados..........
Tal vez estoy totalmente equivocado y espero me lo podáis explicar.......
Muchas gracias.
-----------------------------------------------
Slitzweitz !!!!!!
Juan Carlos Quijano Abad
Dec 2, 2009, 7:13:16 AM12/2/09
to agile...@googlegroups.com
Buenas tardes,
Te remito a un post muy interesante
http://www.proyectosagiles.org/contrato-agil-scrum
--
Un saludo
Juan Quijano
Te remito a un post muy interesante
http://www.proyectosagiles.org/contrato-agil-scrum
--
Un saludo
Juan Quijano
Jonathan Vila Lopez
Dec 2, 2009, 7:22:25 AM12/2/09
to agile...@googlegroups.com
Muchas gracias Juan......... ha sido interesante........... me lo he leído ( no en super profundidad ) pero veo que aunque me ha gustado mucho porque aporta ideas interesantes sobre la contratacion...... sigo sin saber como poder responder a las preguntas que planteaba en mi mail........
Es decir, entiendo el clausulado para proteger a ambas partes..........pero, como hacer con lo del precio cerrado? que le digo ? y en cuanto al plazo ? como puedo competir con las otras compañias que no usan Scrum ? el tema del contrato esta bien una vez ya se han decidido por mi....pero y antes ?
En el articulo que mencionas dice :
"cómo deberá de ser la relación entre cliente y proveedor en la ejecución de un proyecto ágil utilizando Scrum."
"El caso era de regalo para este enfoque, porque el cliente era consciente (por una vez) de que sus requerimientos iban a ir cambiando, y sólo sabía que tenía unos límites temporales y presupuestarios (que por supuesto, eran todo menos holgados)."
Mi duda es basicamente como competir cuando el cliente no tiene idea de metodologias ni la quiere tener y hay competidores que "engañan" usando el metodo tradicional........... pero en cambio se arriesgan a dar un precio y un plazo........
-----------------------------------------------
Slitzweitz !!!!!!
Es decir, entiendo el clausulado para proteger a ambas partes..........pero, como hacer con lo del precio cerrado? que le digo ? y en cuanto al plazo ? como puedo competir con las otras compañias que no usan Scrum ? el tema del contrato esta bien una vez ya se han decidido por mi....pero y antes ?
En el articulo que mencionas dice :
"cómo deberá de ser la relación entre cliente y proveedor en la ejecución de un proyecto ágil utilizando Scrum."
"El caso era de regalo para este enfoque, porque el cliente era consciente (por una vez) de que sus requerimientos iban a ir cambiando, y sólo sabía que tenía unos límites temporales y presupuestarios (que por supuesto, eran todo menos holgados)."
Mi duda es basicamente como competir cuando el cliente no tiene idea de metodologias ni la quiere tener y hay competidores que "engañan" usando el metodo tradicional........... pero en cambio se arriesgan a dar un precio y un plazo........
-----------------------------------------------
Slitzweitz !!!!!!
2009/12/2 Juan Carlos Quijano Abad <juancarl...@gmail.com>
Vicenç Garcia
Dec 2, 2009, 7:26:46 AM12/2/09
to agile...@googlegroups.com
Jonathan,
Si te miras el resto de la web hay un apartado de ventajas de scrum sobre metodologías tradicionales. También te servirá.
Si la pregunta es que puedo hacer para ganar un contrato a una empresa que va a mentir sobre el tiempo y el dinero en que lo hará, la respuesta es que has de convencer al cliente que esta(s) empresa está mintiendo. Tu le presentarás un presupuesto que superará en tiempo y dinero a los otros presupuestos, pero que se ajustará mucho más a la realidad. Si tu cliente a dia de hoy no es capaz de verlo, dá el contrato por perdido. Pero tranquilo que el cliente se va a meter una buena ostia con quien acabe contratando. Con un poco de suerte volverá a ti :D
Suerte!
--
Vicenç García
http://devnettips.blogspot.com
Si te miras el resto de la web hay un apartado de ventajas de scrum sobre metodologías tradicionales. También te servirá.
Si la pregunta es que puedo hacer para ganar un contrato a una empresa que va a mentir sobre el tiempo y el dinero en que lo hará, la respuesta es que has de convencer al cliente que esta(s) empresa está mintiendo. Tu le presentarás un presupuesto que superará en tiempo y dinero a los otros presupuestos, pero que se ajustará mucho más a la realidad. Si tu cliente a dia de hoy no es capaz de verlo, dá el contrato por perdido. Pero tranquilo que el cliente se va a meter una buena ostia con quien acabe contratando. Con un poco de suerte volverá a ti :D
Suerte!
2009/12/2 Jonathan Vila Lopez <jonath...@gmail.com>
--
Vicenç García
http://devnettips.blogspot.com
Ángel Medinilla
Dec 2, 2009, 7:27:20 AM12/2/09
to agile-spain
Hola:
Respuesta corta: Scrum no necesariamente implica "funcionalidad variable". El contrato es una cosa, el proceso de ejecución otra distinta. Ambas deben relacionarse de algún modo, claro. Sí es posible embarcarse en proyectos en los que cierras tiempo, funcionalidad y recursos, pero evidentemente habrá que manejar la incertidumbre en algún tipo de "buffer" / provisión / "colchón" / reserva.
Si tienes tiempo, echa un vistazo a la charla / presentación sobre contratos Ágiles que dimos invitados por Autentia:
http://www.slideshare.net/proyectalis/090603-contratos-giles?type=presentation
http://www.viddler.com/explore/jmbeas/videos/3/
http://www.viddler.com/explore/jmbeas/videos/4/
----------------------------------------------------
Ángel Medinilla
angel.m...@presionblogosferica.net
www.presionblogosferica.com
Respuesta corta: Scrum no necesariamente implica "funcionalidad variable". El contrato es una cosa, el proceso de ejecución otra distinta. Ambas deben relacionarse de algún modo, claro. Sí es posible embarcarse en proyectos en los que cierras tiempo, funcionalidad y recursos, pero evidentemente habrá que manejar la incertidumbre en algún tipo de "buffer" / provisión / "colchón" / reserva.
Si tienes tiempo, echa un vistazo a la charla / presentación sobre contratos Ágiles que dimos invitados por Autentia:
http://www.slideshare.net/proyectalis/090603-contratos-giles?type=presentation
http://www.viddler.com/explore/jmbeas/videos/3/
http://www.viddler.com/explore/jmbeas/videos/4/
----------------------------------------------------
Ángel Medinilla
angel.m...@presionblogosferica.net
www.presionblogosferica.com
2009/12/2 Jonathan Vila Lopez <jonath...@gmail.com>
Muchas gracias Juan......... ha sido interesante........... me lo he leído ( no en super profundidad ) pero veo que aunque me ha gustado mucho porque aporta ideas interesantes sobre la contratacion...... sigo sin saber como poder responder a las preguntas que planteaba en mi mail........
Ángel Medinilla
Dec 2, 2009, 7:30:05 AM12/2/09
to agile-spain
Luego está el argumento de Jeff Sutherland: dejad de quejaos porque el cliente cierra funcionalidad, tiempo y recursos. En vez de eso, haceros el doble de productivos, realizad el proyecto en la mitad de tiempo y embolsaos toda la diferencia.
¿Por qué no? :)
----------------------------------------------------
Ángel Medinilla
angel.m...@presionblogosferica.net
www.presionblogosferica.com
2009/12/2 Vicenç Garcia <vincen...@gmail.com>
Jorge Uriarte Aretxaga
Dec 2, 2009, 7:31:27 AM12/2/09
to agile...@googlegroups.com
Mi impresión personal. No importa la de contratos que redactes, la de
artículos que pases a un cliente, la de cláusulas y detalles que
incluyas en tus ofertas, todo se reduce a una cuestión de confianza.
Esta vendra dada por las referencias, por el conocimiento, por la
impresión en el contacto pre-venta, y tambien por la forma en que
expliques la relación propuesta, y los motivos por los que consideras
que será así.
Luego te encontrarás con clientes que agradecen ese enfoque y lo
abrazan, con otros que lo harían pero no pueden porque su propia
estructura organizativa les fuerza a comprometerse a costes cerrados,
y a otros que no lo harían nunca, creen que les quieres engañar e
intentarán regatear cada céntimo sin remisión.
A los terceros, renuncié hace tiempo. No peleo por ese espacio de mercado.
A los segundos, hay que darles facilidades para que vendan la idea, y
normalmente necesitarás protegerte y excluir del alcance todo aquello
que potencialmente se convierta en un arma.
A los primeros, dales el 150% porque son los que hablarán luego con
sus compañeros de lo bien (o mal!) que les fue con eso de las
metodologías ágiles!!
Pero siempre, a todos, exponles lo que hay, con sinceridad. Ayúdales a
ayudarse, intenta buscar la mejor fórmula de relación para cada caso
concreto, sea "Agile cosher" o no. Busca con libertad enfoques mixtos,
terreno neutral donde puedes hacer que el proyecto funcione. Y
enséñale las zonas oscuras de los requisitos, ilustrando las
diferencias que pueden suponer.
La orientación a cliente, el enfoque al valor de negocio, debe empezar
en la propia labor comercial.
_
Jorge Uriarte Aretxaga
http://www.gailen.es
http://www.linkedin.com/in/jorgeuriarte
2009/12/2 Jonathan Vila Lopez <jonath...@gmail.com>:
artículos que pases a un cliente, la de cláusulas y detalles que
incluyas en tus ofertas, todo se reduce a una cuestión de confianza.
Esta vendra dada por las referencias, por el conocimiento, por la
impresión en el contacto pre-venta, y tambien por la forma en que
expliques la relación propuesta, y los motivos por los que consideras
que será así.
Luego te encontrarás con clientes que agradecen ese enfoque y lo
abrazan, con otros que lo harían pero no pueden porque su propia
estructura organizativa les fuerza a comprometerse a costes cerrados,
y a otros que no lo harían nunca, creen que les quieres engañar e
intentarán regatear cada céntimo sin remisión.
A los terceros, renuncié hace tiempo. No peleo por ese espacio de mercado.
A los segundos, hay que darles facilidades para que vendan la idea, y
normalmente necesitarás protegerte y excluir del alcance todo aquello
que potencialmente se convierta en un arma.
A los primeros, dales el 150% porque son los que hablarán luego con
sus compañeros de lo bien (o mal!) que les fue con eso de las
metodologías ágiles!!
Pero siempre, a todos, exponles lo que hay, con sinceridad. Ayúdales a
ayudarse, intenta buscar la mejor fórmula de relación para cada caso
concreto, sea "Agile cosher" o no. Busca con libertad enfoques mixtos,
terreno neutral donde puedes hacer que el proyecto funcione. Y
enséñale las zonas oscuras de los requisitos, ilustrando las
diferencias que pueden suponer.
La orientación a cliente, el enfoque al valor de negocio, debe empezar
en la propia labor comercial.
_
Jorge Uriarte Aretxaga
http://www.gailen.es
http://www.linkedin.com/in/jorgeuriarte
2009/12/2 Jonathan Vila Lopez <jonath...@gmail.com>:
Jonathan Vila Lopez
Dec 2, 2009, 7:38:20 AM12/2/09
to agile...@googlegroups.com
Me ha gustado mucho el enfoque de Jorge...........
El problema viene cuando en el sector en el que te mueves ( en mi caso hotelero ) parece que casi todos los posibles clientes son de tu tipo 3...........
-----------------------------------------------
Slitzweitz !!!!!!
El problema viene cuando en el sector en el que te mueves ( en mi caso hotelero ) parece que casi todos los posibles clientes son de tu tipo 3...........
-----------------------------------------------
Slitzweitz !!!!!!
2009/12/2 Jorge Uriarte Aretxaga <jorge....@gailen.es>
xavier.albaladejo
Dec 2, 2009, 5:44:39 PM12/2/09
to agile-spain
Totalmente de acuerdo con Jorge, ganarse la confianza con el cliente
ya en la preventa y mantenerla a lo largo de todo el proyecto, ser
socios en lugar de cliente-proveedor.
Por cierto, quizás falta un grupo 4 de clientes: los que su objetivo
es intentar exprimir al máximo posible al proveedor. Hace poco oí la
frase "Hay que ver hasta cuanto es capaz de sangrar un proveedor antes
de dejarle ganar dinero".
On 2 dic, 13:31, Jorge Uriarte Aretxaga <jorge.uria...@gailen.es>
wrote:
> Jorge Uriarte Aretxagahttp://www.gailen.eshttp://www.linkedin.com/in/jorgeuriarte
>
> 2009/12/2 Jonathan Vila Lopez <jonathan.v...@gmail.com>:
ya en la preventa y mantenerla a lo largo de todo el proyecto, ser
socios en lugar de cliente-proveedor.
Por cierto, quizás falta un grupo 4 de clientes: los que su objetivo
es intentar exprimir al máximo posible al proveedor. Hace poco oí la
frase "Hay que ver hasta cuanto es capaz de sangrar un proveedor antes
de dejarle ganar dinero".
On 2 dic, 13:31, Jorge Uriarte Aretxaga <jorge.uria...@gailen.es>
wrote:
>
> 2009/12/2 Jonathan Vila Lopez <jonathan.v...@gmail.com>:
>
> > Muchas gracias Juan......... ha sido interesante........... me lo he leído (
> > no en super profundidad ) pero veo que aunque me ha gustado mucho porque
> > aporta ideas interesantes sobre la contratacion...... sigo sin saber como
> > poder responder a las preguntas que planteaba en mi mail........
>
> > Es decir, entiendo el clausulado para proteger a ambas partes..........pero,
> > como hacer con lo del precio cerrado? que le digo ? y en cuanto al plazo ?
> > como puedo competir con las otras compañias que no usan Scrum ? el tema del
> > contrato esta bien una vez ya se han decidido por mi....pero y antes ?
>
> > En el articulo que mencionas dice :
> > "cómo deberá de ser la relación entre cliente y proveedor en la ejecución de
> > un proyecto ágil utilizando Scrum."
>
> > "El caso era de regalo para este enfoque, porque el cliente era consciente
> > (por una vez) de que sus requerimientos iban a ir cambiando, y sólo sabía
> > que tenía unos límites temporales y presupuestarios (que por supuesto, eran
> > todo menos holgados)."
>
> > Mi duda es basicamente como competir cuando el cliente no tiene idea de
> > metodologias ni la quiere tener y hay competidores que "engañan" usando el
> > metodo tradicional........... pero en cambio se arriesgan a dar un precio y
> > un plazo........
>
> > -----------------------------------------------
> > Slitzweitz !!!!!!
>
> > 2009/12/2 Juan Carlos Quijano Abad <juancarlosquij...@gmail.com>
> > Muchas gracias Juan......... ha sido interesante........... me lo he leído (
> > no en super profundidad ) pero veo que aunque me ha gustado mucho porque
> > aporta ideas interesantes sobre la contratacion...... sigo sin saber como
> > poder responder a las preguntas que planteaba en mi mail........
>
> > Es decir, entiendo el clausulado para proteger a ambas partes..........pero,
> > como hacer con lo del precio cerrado? que le digo ? y en cuanto al plazo ?
> > como puedo competir con las otras compañias que no usan Scrum ? el tema del
> > contrato esta bien una vez ya se han decidido por mi....pero y antes ?
>
> > En el articulo que mencionas dice :
> > "cómo deberá de ser la relación entre cliente y proveedor en la ejecución de
> > un proyecto ágil utilizando Scrum."
>
> > "El caso era de regalo para este enfoque, porque el cliente era consciente
> > (por una vez) de que sus requerimientos iban a ir cambiando, y sólo sabía
> > que tenía unos límites temporales y presupuestarios (que por supuesto, eran
> > todo menos holgados)."
>
> > Mi duda es basicamente como competir cuando el cliente no tiene idea de
> > metodologias ni la quiere tener y hay competidores que "engañan" usando el
> > metodo tradicional........... pero en cambio se arriesgan a dar un precio y
> > un plazo........
>
> > -----------------------------------------------
> > Slitzweitz !!!!!!
>
>
> >> Buenas tardes,
>
> >> Te remito a un post muy interesante
>
> >>http://www.proyectosagiles.org/contrato-agil-scrum
>
> >> --
> >> Un saludo
> >> Juan Quijano
>
> >> El 2 de diciembre de 2009 12:56, Jonathan Vila Lopez
> >> <jonathan.v...@gmail.com> escribió:
> >> Buenas tardes,
>
> >> Te remito a un post muy interesante
>
> >>http://www.proyectosagiles.org/contrato-agil-scrum
>
> >> --
> >> Un saludo
> >> Juan Quijano
>
> >> El 2 de diciembre de 2009 12:56, Jonathan Vila Lopez
German DZ
Dec 2, 2009, 5:58:54 PM12/2/09
to agile...@googlegroups.com
Al 4to grupo de clientes.. es simple, lo único que logran es que la próxima cotización sea mucho más cara (el riesgo siempre se paga) o bien que ese proveedor ya no los provea, con lo cual habrán retrocedido.
Hay que lograr la madurez en la industria del software, en otras ya se ha logrado. Donde el cliente ayuda a desarrollarse a sus proveedores por ejemplo.
Por el momento aún no he visto magia, así que algunos clientes arman una relación sólida, otros una perversa... en definitiva están los que pagan mucho al comienzo, los que lo pagan durante, los que al final. Y también están los que pagan un precio justo y obtienen buenas cosas.
Jorge Uriarte Aretxaga
Dec 2, 2009, 6:17:24 PM12/2/09
to agile...@googlegroups.com
>
> Por cierto, quizás falta un grupo 4 de clientes: los que su objetivo
> es intentar exprimir al máximo posible al proveedor. Hace poco oí la
> frase "Hay que ver hasta cuanto es capaz de sangrar un proveedor antes
> de dejarle ganar dinero".
>
> Por cierto, quizás falta un grupo 4 de clientes: los que su objetivo
> es intentar exprimir al máximo posible al proveedor. Hace poco oí la
> frase "Hay que ver hasta cuanto es capaz de sangrar un proveedor antes
> de dejarle ganar dinero".
>
yo los veo en el 3, pero puede haber matices. Son los que se interesan
por tus costes, deciden que no necesitas "tanto margen", que tu gente
no trabaja lo suficiente, y que piensan que eres un caradura por
intentar ganar dinero a costa de sus necesidades :)
En esos casos, seguid el consejo del mago gris... HUID, INSENSATOS!!!!
_
Jorge
José Manuel Beas
Dec 2, 2009, 6:28:40 PM12/2/09
to agile-spain
Sí, pero el Mago Gris se quedaba para decir: "¡NOOOO PUEDEEEEES PASAAAAAAR!" Y no te cuento cómo acaba la cosa para el Mago Gris (por lo menos en ese DVD: el siguiente no lo encuentro, pero creo que alguien me contó que el Mago Gris encaneció de tanto sufrimiento y le empezaron a llamar el Mago Blanco o algo así). :-)
Un saludo,
Jose Manuel Beas
http://www.agile-spain.com
http://jmbeas.iExpertos.com <-- ¡Me he mudado!
Un saludo,
Jose Manuel Beas
http://www.agile-spain.com
http://jmbeas.iExpertos.com <-- ¡Me he mudado!
2009/12/3 Jorge Uriarte Aretxaga <jorge....@gailen.es>
Juan Carlos Quijano Abad
Dec 3, 2009, 2:18:02 AM12/3/09
to agile...@googlegroups.com
Buenas,
Creo que el error, que es muy común en nuestro sector, es que poner al Mago a parar al Barlog, cuando debieron llamar a un Valar.
Es decir, para "pegarse" con el cliente: un buen director comercial que venda "frigoríficos a los esquimales" y que no solamente saqué el máximo presupuesto posible, si no que además deje al cliente "listillo chupasangre" super contento creyendo que está "tangando" al proovedor cuando en realidad se mantienen los costes en su tamaño razonable (tampoco es convertirse en Saruman y apoyar al maligno metiendo "clavos" a diestro y siniestro). Y si es muy bueno, hasta sin la tutela del director o coordinador técnico para que no nos pillemos los dedos.
Tengo la opinión que un buen equipo comercial es aún más imprescindible que un buen equipo de desarrollo. Los primeros sin los segundos siguen generando dinero, los segundos sin los primeros les toca buscar otra fuente de ingresos. :)
También totálmente de acuerdo con el planteamiento de Jorge
--
Un saludo
Juan Quijano
Creo que el error, que es muy común en nuestro sector, es que poner al Mago a parar al Barlog, cuando debieron llamar a un Valar.
Es decir, para "pegarse" con el cliente: un buen director comercial que venda "frigoríficos a los esquimales" y que no solamente saqué el máximo presupuesto posible, si no que además deje al cliente "listillo chupasangre" super contento creyendo que está "tangando" al proovedor cuando en realidad se mantienen los costes en su tamaño razonable (tampoco es convertirse en Saruman y apoyar al maligno metiendo "clavos" a diestro y siniestro). Y si es muy bueno, hasta sin la tutela del director o coordinador técnico para que no nos pillemos los dedos.
Tengo la opinión que un buen equipo comercial es aún más imprescindible que un buen equipo de desarrollo. Los primeros sin los segundos siguen generando dinero, los segundos sin los primeros les toca buscar otra fuente de ingresos. :)
También totálmente de acuerdo con el planteamiento de Jorge
--
Un saludo
Juan Quijano
Abel Muiño Vizcaino
Dec 3, 2009, 4:02:23 AM12/3/09
to agile...@googlegroups.com
¡Como me gusta leer esto!
:D
Normalmente los técnicos cargamos contra los comerciales (y los comerciales contra nosotros... como me decían a mi "vosotros sólo sois costes").
Si queremos ser socios de los clientes, primero tendremos que ser socios del resto de departamentos de nuestra empresa (y ellos, socios nuestros).
A fin de cuentas, la diferencia entre el fracaso (cerrar la empresa) y el éxito (seguir vivo y pagando los sueldos) no es tu calidad técnica ni el número de post-its por segundo que mueves a la columna "Done".
Es cuánto vendes y cuanto margen te quedas.
El 03/12/2009, a las 8:18, Juan Carlos Quijano Abad escribió:
Tengo la opinión que un buen equipo comercial es aún más imprescindible que un buen equipo de desarrollo. Los primeros sin los segundos siguen generando dinero, los segundos sin los primeros les toca buscar otra fuente de ingresos. :)
--
Abel Muiño - http://ramblingabout.wordpress.com/
Jonathan Vila Lopez
Dec 3, 2009, 4:28:25 AM12/3/09
to agile...@googlegroups.com
Estoy muy de acuerdo con Abel.........
Una cosa en la que , por mi inexperiencia y falta de conocimiento en Scrum, no he visto que se haga mucho incapie en el tema de metodologias agiles es la busqueda de complicidad o la venta interna de la metodologia......
Por lo que he podido leer parece que se forme un grupo estanco en cuanto se habla de Scrum : el equipo tecnico y el cliente...... donde esta el comercial ? que es quien lidera el proyecto de cara al cliente...sobre todo en costes y contrataciones............
Lo mas importante es que en casa todos rememos al unisono y sin dudas........y por tanto es super imprescindible tener la complicidad "a muerte" de la parte comercial y hasta cierto punto tambien de la parte de recursos humanos.......
Y por ultimo....... es muy muy muy muy importante el tipo de organizacion........ la gran mayoria trabajamos en compañias de estructura funcional o como mucho matricial debil o balanceada..... Por lo tanto la importancia y poder de los jefes funcionales es altisima......por lo que habra que contar con su complicidad en alto grado para que cualquier metodologia funcione.......incluso Scrum.
-----------------------------------------------
Slitzweitz !!!!!!
Una cosa en la que , por mi inexperiencia y falta de conocimiento en Scrum, no he visto que se haga mucho incapie en el tema de metodologias agiles es la busqueda de complicidad o la venta interna de la metodologia......
Por lo que he podido leer parece que se forme un grupo estanco en cuanto se habla de Scrum : el equipo tecnico y el cliente...... donde esta el comercial ? que es quien lidera el proyecto de cara al cliente...sobre todo en costes y contrataciones............
Lo mas importante es que en casa todos rememos al unisono y sin dudas........y por tanto es super imprescindible tener la complicidad "a muerte" de la parte comercial y hasta cierto punto tambien de la parte de recursos humanos.......
Y por ultimo....... es muy muy muy muy importante el tipo de organizacion........ la gran mayoria trabajamos en compañias de estructura funcional o como mucho matricial debil o balanceada..... Por lo tanto la importancia y poder de los jefes funcionales es altisima......por lo que habra que contar con su complicidad en alto grado para que cualquier metodologia funcione.......incluso Scrum.
-----------------------------------------------
Slitzweitz !!!!!!
2009/12/3 Abel Muiño Vizcaino <amu...@gmail.com>
Jorge Uriarte Aretxaga
Dec 3, 2009, 5:04:09 AM12/3/09
to agile...@googlegroups.com
Es que esto enlaza con el hilo de las "agile skills". Es muy
importante que todo el equipo sepa alinearse con el cliente, así como
es importante no dejar que el cliente manipule al equipo (no
confundir!).
Las habilidades comerciales, la capacidad de comunicar ventajas e
infundir confianza, son claves para cualquier perfil que tenga
relación con el cliente, no sólo para los comerciales.
Pero creo que tambien depende del tipo de interlocución. Es decir; si
la venta se va a negociar con un departamente de compras, sin
conocimiento técnico, envía a un comercial "al uso". Sus habilidades
específicas serán más importantes. Pero si la negociación es con el
"owner", lleva a perfiles que sepan de producción (eso sí, siempre con
habilidades "mixtas", no lleves a ese gurú del JNI al que no le gusta
hablar con la gente ;) )
2009/12/3 Abel Muiño Vizcaino <amu...@gmail.com>:
importante que todo el equipo sepa alinearse con el cliente, así como
es importante no dejar que el cliente manipule al equipo (no
confundir!).
Las habilidades comerciales, la capacidad de comunicar ventajas e
infundir confianza, son claves para cualquier perfil que tenga
relación con el cliente, no sólo para los comerciales.
Pero creo que tambien depende del tipo de interlocución. Es decir; si
la venta se va a negociar con un departamente de compras, sin
conocimiento técnico, envía a un comercial "al uso". Sus habilidades
específicas serán más importantes. Pero si la negociación es con el
"owner", lleva a perfiles que sepan de producción (eso sí, siempre con
habilidades "mixtas", no lleves a ese gurú del JNI al que no le gusta
hablar con la gente ;) )
2009/12/3 Abel Muiño Vizcaino <amu...@gmail.com>:
Juanjo Falcon
Dec 3, 2009, 9:11:22 AM12/3/09
to agile...@googlegroups.com
Hola a todos, parece que esto se anima.
Aunque llego un poco tarde, me parecen muy interesantes y practicas las reflexiones de calado de este hilo.
Además ultimamente me interesa tratar como podemos manejar estos aspectos comerciales con los clientes.
Totalmente de acuerdo con los tipos de cliente que nos podemos encontrar propuestos por Jorge, y con la forma que propone de encararlos a cada uno de ellos.
Respecto a la propuesta de Abel, va en sintonia con lo que propone Scrum Manager de aplicar tecnicas agiles al conjunto de la empresa para convertirnos asi en una organizacion agil.
Respecto al problema concreto planteado por Jonathan creo que hay dos acciones a realizar.
1) Tenemos que hacer una labor de concienciación y educación imprescindible con nuestros clientes. Esa tarea es una inversión que tenemos que hacer si o si, a medio y largo plazo. Para ello es imprescindible cambiarnos primeramente a nosotros mismos en la propia filosofia de colaboracion y confianza que queremos luego trasladar a nuestros clientes. Aqui tenemos que buscar nuestro "Oceano Azul" [1] y reinventarnos como empresa.
2) Para los casos de lucha titánica "Oceano Rojo" [1] como describe Jonathan con propuestas cerradas, precios abusivos, etc, pues va a ser dificil y dependerá de la situación de nuestra cartera. Si podemos evitarlo mejor, pero habrá ocasiones que no queda más remedio. En esos casos, tendremos que entrar al juego para ver si conseguimos el proyecto. Una vez que consigamos el proyecto y limitando las pérdidas, tendremos que desplegar todo nuestro potencial durante el desarrollo para mostrarle al cliente de un modo practico las mejoras de la forma de hacer de nuestra empresa. Ese es el mejor marjeting o acción comercial que podemos realizar a nuestros clientes para ganar su confianza. Si le gusta repetirá, y asi ya tendremos más argumentos (confianza) para afianzar una relación.
Si no cambia a la siguiente, hay que desprenderse de él cuanto antes porque nos puede hundir! Son riesgos y apuestas que todos hacemos habitualmente y que intentamos minimizar.
¿Alguien lo hace de otra manera?
Un saludo,
Juanjo Falcón
[1] La estrategia del Oceano Azul. W. Chan Kim Es un libro que he leido ultimamente y que recomiendo para aplicar a nuestras empresas. Trata de como crear en el mercado espacios no disputados en los que la competencia sea irrelevante. Casi nada! En este caso podriamos aplicarlo para convertir escenarios del tipo 2) a los del tipo 1) aplicando una metodologia de una forma sistematica. Esto daría para abrir un hilo y ver lo que da de si...
Aunque llego un poco tarde, me parecen muy interesantes y practicas las reflexiones de calado de este hilo.
Además ultimamente me interesa tratar como podemos manejar estos aspectos comerciales con los clientes.
Totalmente de acuerdo con los tipos de cliente que nos podemos encontrar propuestos por Jorge, y con la forma que propone de encararlos a cada uno de ellos.
Respecto a la propuesta de Abel, va en sintonia con lo que propone Scrum Manager de aplicar tecnicas agiles al conjunto de la empresa para convertirnos asi en una organizacion agil.
Respecto al problema concreto planteado por Jonathan creo que hay dos acciones a realizar.
1) Tenemos que hacer una labor de concienciación y educación imprescindible con nuestros clientes. Esa tarea es una inversión que tenemos que hacer si o si, a medio y largo plazo. Para ello es imprescindible cambiarnos primeramente a nosotros mismos en la propia filosofia de colaboracion y confianza que queremos luego trasladar a nuestros clientes. Aqui tenemos que buscar nuestro "Oceano Azul" [1] y reinventarnos como empresa.
2) Para los casos de lucha titánica "Oceano Rojo" [1] como describe Jonathan con propuestas cerradas, precios abusivos, etc, pues va a ser dificil y dependerá de la situación de nuestra cartera. Si podemos evitarlo mejor, pero habrá ocasiones que no queda más remedio. En esos casos, tendremos que entrar al juego para ver si conseguimos el proyecto. Una vez que consigamos el proyecto y limitando las pérdidas, tendremos que desplegar todo nuestro potencial durante el desarrollo para mostrarle al cliente de un modo practico las mejoras de la forma de hacer de nuestra empresa. Ese es el mejor marjeting o acción comercial que podemos realizar a nuestros clientes para ganar su confianza. Si le gusta repetirá, y asi ya tendremos más argumentos (confianza) para afianzar una relación.
Si no cambia a la siguiente, hay que desprenderse de él cuanto antes porque nos puede hundir! Son riesgos y apuestas que todos hacemos habitualmente y que intentamos minimizar.
¿Alguien lo hace de otra manera?
Un saludo,
Juanjo Falcón
[1] La estrategia del Oceano Azul. W. Chan Kim Es un libro que he leido ultimamente y que recomiendo para aplicar a nuestras empresas. Trata de como crear en el mercado espacios no disputados en los que la competencia sea irrelevante. Casi nada! En este caso podriamos aplicarlo para convertir escenarios del tipo 2) a los del tipo 1) aplicando una metodologia de una forma sistematica. Esto daría para abrir un hilo y ver lo que da de si...
jcesarperez
Dec 4, 2009, 3:17:01 AM12/4/09
to agile-spain
No estoy de acuerdo con la premisa del tema inicial hilo de que por
usar Scrum vayas a tener un mayor coste.
En mi experiencia usar metodologías y prácticas ágiles te hace mucho
más productivo y no al revés, por lo que puedes competir sin problemas
con esos presupuestos cerrados y usar la agilidad como valor añadido
en el proceso comercial.
El cliente sería un suicida si fuera a firmarte un contrato ágil en
vuestro primer trato comercial. Vamos yo no lo haría por mucho Scrum y
confianza que me intentaran vender. No hasta que no haya tenido un par
de experiencias positivas con ellos. Y aún así me costaría, porque sin
contratos ágiles hemos funcionado bien, ¿por qué cambiar?
On 3 dic, 15:11, Juanjo Falcon <jjfal...@gmail.com> wrote:
> Hola a todos, parece que esto se anima.
>
> Aunque llego un poco tarde, me parecen muy interesantes y practicas las
> reflexiones de calado de este hilo.
> Además ultimamente me interesa tratar como podemos manejar estos aspectos
> comerciales con los clientes.
>
> Totalmente de acuerdo con los tipos de cliente que nos podemos encontrar
> propuestos por Jorge, y con la forma que propone de encararlos a cada uno de
> ellos.
>
> Respecto a la propuesta de Abel, va en sintonia con lo que propone Scrum
> Manager de aplicar tecnicas agiles al conjunto de la empresa para
> convertirnos asi en una organizacion agil.
>
> Respecto al problema concreto planteado por Jonathan creo que hay dos
> acciones a realizar.
>
> 1) Tenemos que hacer una labor de concienciación y educación imprescindible
> con nuestros clientes. Esa tarea es una inversión que tenemos que hacer si o
> si, a medio y largo plazo. Para ello es imprescindible cambiarnos
> primeramente a nosotros mismos en la propia filosofia de colaboracion y *
> confianza* que queremos luego trasladar a nuestros clientes. Aqui tenemos
> W. Chan Kim<http://www.amazon.com/s/ref=ntt_athr_dp_sr_1?_encoding=UTF8&sort=rele...>Es
usar Scrum vayas a tener un mayor coste.
En mi experiencia usar metodologías y prácticas ágiles te hace mucho
más productivo y no al revés, por lo que puedes competir sin problemas
con esos presupuestos cerrados y usar la agilidad como valor añadido
en el proceso comercial.
El cliente sería un suicida si fuera a firmarte un contrato ágil en
vuestro primer trato comercial. Vamos yo no lo haría por mucho Scrum y
confianza que me intentaran vender. No hasta que no haya tenido un par
de experiencias positivas con ellos. Y aún así me costaría, porque sin
contratos ágiles hemos funcionado bien, ¿por qué cambiar?
On 3 dic, 15:11, Juanjo Falcon <jjfal...@gmail.com> wrote:
> Hola a todos, parece que esto se anima.
>
> Aunque llego un poco tarde, me parecen muy interesantes y practicas las
> reflexiones de calado de este hilo.
> Además ultimamente me interesa tratar como podemos manejar estos aspectos
> comerciales con los clientes.
>
> Totalmente de acuerdo con los tipos de cliente que nos podemos encontrar
> propuestos por Jorge, y con la forma que propone de encararlos a cada uno de
> ellos.
>
> Respecto a la propuesta de Abel, va en sintonia con lo que propone Scrum
> Manager de aplicar tecnicas agiles al conjunto de la empresa para
> convertirnos asi en una organizacion agil.
>
> Respecto al problema concreto planteado por Jonathan creo que hay dos
> acciones a realizar.
>
> 1) Tenemos que hacer una labor de concienciación y educación imprescindible
> con nuestros clientes. Esa tarea es una inversión que tenemos que hacer si o
> si, a medio y largo plazo. Para ello es imprescindible cambiarnos
> confianza* que queremos luego trasladar a nuestros clientes. Aqui tenemos
> que buscar nuestro "Oceano Azul" [1] y reinventarnos como empresa.
>
> 2) Para los casos de lucha titánica "Oceano Rojo" [1] como describe Jonathan
> con propuestas cerradas, precios abusivos, etc, pues va a ser dificil y
> dependerá de la situación de nuestra cartera. Si podemos evitarlo mejor,
> pero habrá ocasiones que no queda más remedio. En esos casos, tendremos que
> entrar al juego para ver si conseguimos el proyecto. Una vez que consigamos
> el proyecto y limitando las pérdidas, tendremos que desplegar todo nuestro
> potencial durante el desarrollo para mostrarle al cliente de un modo
> practico las mejoras de la forma de hacer de nuestra empresa. Ese es el
> mejor marjeting o acción comercial que podemos realizar a nuestros clientes
> para ganar su *confianza*. Si le gusta repetirá, y asi ya tendremos más
>
> 2) Para los casos de lucha titánica "Oceano Rojo" [1] como describe Jonathan
> con propuestas cerradas, precios abusivos, etc, pues va a ser dificil y
> dependerá de la situación de nuestra cartera. Si podemos evitarlo mejor,
> pero habrá ocasiones que no queda más remedio. En esos casos, tendremos que
> entrar al juego para ver si conseguimos el proyecto. Una vez que consigamos
> el proyecto y limitando las pérdidas, tendremos que desplegar todo nuestro
> potencial durante el desarrollo para mostrarle al cliente de un modo
> practico las mejoras de la forma de hacer de nuestra empresa. Ese es el
> mejor marjeting o acción comercial que podemos realizar a nuestros clientes
> argumentos (confianza) para afianzar una relación.
>
> Si no cambia a la siguiente, hay que desprenderse de él cuanto antes porque
> nos puede hundir! Son riesgos y apuestas que todos hacemos habitualmente y
> que intentamos minimizar.
>
> ¿Alguien lo hace de otra manera?
>
> Un saludo,
> Juanjo Falcón
>
> [1] La estrategia del Oceano
> Azul<http://www.amazon.com/estrategia-oceano-Ocean-Strategy-Spanish/dp/958...>.
>
> Si no cambia a la siguiente, hay que desprenderse de él cuanto antes porque
> nos puede hundir! Son riesgos y apuestas que todos hacemos habitualmente y
> que intentamos minimizar.
>
> ¿Alguien lo hace de otra manera?
>
> Un saludo,
> Juanjo Falcón
>
> [1] La estrategia del Oceano
> W. Chan Kim<http://www.amazon.com/s/ref=ntt_athr_dp_sr_1?_encoding=UTF8&sort=rele...>Es
> un libro que he leido ultimamente y que recomiendo para aplicar a
> nuestras empresas. Trata de como crear en el mercado espacios no disputados
> en los que la competencia sea irrelevante. Casi nada! En este caso podriamos
> aplicarlo para convertir escenarios del tipo 2) a los del tipo 1) aplicando
> una metodologia de una forma sistematica. Esto daría para abrir un hilo y
> ver lo que da de si...
>
> El 3 de diciembre de 2009 11:04, Jorge Uriarte Aretxaga <
> jorge.uria...@gailen.es> escribió:
> nuestras empresas. Trata de como crear en el mercado espacios no disputados
> en los que la competencia sea irrelevante. Casi nada! En este caso podriamos
> aplicarlo para convertir escenarios del tipo 2) a los del tipo 1) aplicando
> una metodologia de una forma sistematica. Esto daría para abrir un hilo y
> ver lo que da de si...
>
> El 3 de diciembre de 2009 11:04, Jorge Uriarte Aretxaga <
Jonathan Vila Lopez
Dec 4, 2009, 5:31:35 AM12/4/09
to agile...@googlegroups.com
@Julio : tal vez no he sabido explicarme bien.... en ningun momento creo que usar Scrum vaya a incrementar el coste ( basicamente no tengo la experiencia y conocimientos suficientes para llegar a esa conclusion o a su contrario )......
Mas bien a lo que me refiero es que , almenos en mi sector, los clientes acostumbran a exigir precios y plazos cerrados.... y teniendo en cuenta que Scrum es una metodologia de construccion evolutiva y que hasta no estar en un Sprint ( corrigeme si me equivoco ) no se valora en detalle las funcionalidades............... me da la sensacion que un proyecto que se vaya a construir usando Scrum no puede , por su filosofia misma, aportar esa informacion al inicio del proyecto.
Por tanto y si aun no me he equivocado en mis conjeturas, como puede competir una pyme que quiera desarrollar usando Scrum en un mundo de compañias que usan metodologias tradicionales en el momento de responder con una oferta a un cliente.......sobre todo si aun no nos conocen.
Espero haberme explicado un poco mejor.......
Saludos.
-----------------------------------------------
Slitzweitz !!!!!!
Mas bien a lo que me refiero es que , almenos en mi sector, los clientes acostumbran a exigir precios y plazos cerrados.... y teniendo en cuenta que Scrum es una metodologia de construccion evolutiva y que hasta no estar en un Sprint ( corrigeme si me equivoco ) no se valora en detalle las funcionalidades............... me da la sensacion que un proyecto que se vaya a construir usando Scrum no puede , por su filosofia misma, aportar esa informacion al inicio del proyecto.
Por tanto y si aun no me he equivocado en mis conjeturas, como puede competir una pyme que quiera desarrollar usando Scrum en un mundo de compañias que usan metodologias tradicionales en el momento de responder con una oferta a un cliente.......sobre todo si aun no nos conocen.
Espero haberme explicado un poco mejor.......
Saludos.
-----------------------------------------------
Slitzweitz !!!!!!
2009/12/4 jcesarperez <julio.cesar....@gmail.com>
Abel Muiño Vizcaino
Dec 4, 2009, 6:02:27 AM12/4/09
to agile...@googlegroups.com
No tengo una respuesta, pero quería comentar que entre las "metodologías tradicionales" hay muchas que son evolutivas e incrementales.
Están las que hacen prototipado rápido, la de ciclo de vida en espiral...
Así que tu elección de metodología de desarrollo no debería limitar tu negociación con el cliente.
Intenta proponer al cliente reuniones periódicas para enseñarle el proyecto (o instalarlo en su entorno). No conozco a ninguno que se niegue a entregas mensuales (que serán 2-4 sprints). De esta forma sacas partido de la naturaleza incremental de tu forma de trabajar.
PERO la estimación inicial que vas a poner en el contrato va a tener siempre una gran parte de intuición, en todas las metodologías.
El 04/12/2009, a las 11:31, Jonathan Vila Lopez escribió:
Por tanto y si aun no me he equivocado en mis conjeturas, como puede competir una pyme que quiera desarrollar usando Scrum en un mundo de compañias que usan metodologias tradicionales en el momento de responder con una oferta a un cliente.......sobre todo si aun no nos conocen.
Juan Carlos Quijano Abad
Dec 4, 2009, 6:22:47 AM12/4/09
to agile...@googlegroups.com
Buenas,
Yo intentaría una primera aproximación, no sé si es real porque nunca lo he realizado, en donde sobre un proyecto/presupuesto cerrado se ofreciera el cobro por sprint o grupo de sprint.
Pongamos un ejemplo:
1. Montante total del proyecto 300.000€
2. Tiempo total del proyecto 12 meses.
3. Equipo: <descripción y tarifas del equipo>
A partir de aquí se hace una propuesta en conjunto de:
% de depósito para el inicio del proyecto.
% de dinero por requisitos cubiertos (es casi hacer un backlog pero para decidir cuanto vale cada "pieza" entregada y funcionando)
Al ser un contrato Agil, se puede ampliar o reducir de acuerdo a la capacidad del cliente de modificar las cifras. Lo que no se debiera tocar son las entregas periódicas, ni los pagos a la finalización de los requisitos cubiertos. Si entregas algo funcionando, lo pagan. Y no entregas más hasta que no te paguen.
Se puede vender relativamente facil si señalas que el proyecto se puede detener cuando indique el cliente y no cuando la empresa "consuma" todo el dinero presupuestado. Pero aseguras al cliente que solo pagará por funcionalidades finalizadas y útiles.
Bueno para la empresa: porque el riesgo de impago se reduce mucho.
Malo para la empresa: lo de hacerlo en la mitad para ganar el doble se ha acabado. En todo caso hacerlo en la mitad de tiempo para que nos dén más trabajo y ganar más.
P.D. Con las Administraciones Públicas no se puede hacer.
Un saludo
Juan Quijano
Yo intentaría una primera aproximación, no sé si es real porque nunca lo he realizado, en donde sobre un proyecto/presupuesto cerrado se ofreciera el cobro por sprint o grupo de sprint.
Pongamos un ejemplo:
1. Montante total del proyecto 300.000€
2. Tiempo total del proyecto 12 meses.
3. Equipo: <descripción y tarifas del equipo>
A partir de aquí se hace una propuesta en conjunto de:
% de depósito para el inicio del proyecto.
% de dinero por requisitos cubiertos (es casi hacer un backlog pero para decidir cuanto vale cada "pieza" entregada y funcionando)
Al ser un contrato Agil, se puede ampliar o reducir de acuerdo a la capacidad del cliente de modificar las cifras. Lo que no se debiera tocar son las entregas periódicas, ni los pagos a la finalización de los requisitos cubiertos. Si entregas algo funcionando, lo pagan. Y no entregas más hasta que no te paguen.
Se puede vender relativamente facil si señalas que el proyecto se puede detener cuando indique el cliente y no cuando la empresa "consuma" todo el dinero presupuestado. Pero aseguras al cliente que solo pagará por funcionalidades finalizadas y útiles.
Bueno para la empresa: porque el riesgo de impago se reduce mucho.
Malo para la empresa: lo de hacerlo en la mitad para ganar el doble se ha acabado. En todo caso hacerlo en la mitad de tiempo para que nos dén más trabajo y ganar más.
P.D. Con las Administraciones Públicas no se puede hacer.
Un saludo
Juan Quijano
Jonathan Vila Lopez
Dec 4, 2009, 6:41:55 AM12/4/09
to agile...@googlegroups.com
Por lo que comenta Juan me recuerda a la forma de pago que se tiene en los proyectos de construccion..... por el tema del pago por fase entregada........ es curioso que para ciertos tipos de proyectos la gente entienda que es la forma correcta y en cambio para otros no....................
Siempre he pensado que el tema de la construccion tiene muchas cosas que se podrian hacer igual en software, y el tema de los pagos por fases asi como que el cliente siente que un cambio en el diseño es algo importante es algo interesante...........
-----------------------------------------------
Slitzweitz !!!!!!
Siempre he pensado que el tema de la construccion tiene muchas cosas que se podrian hacer igual en software, y el tema de los pagos por fases asi como que el cliente siente que un cambio en el diseño es algo importante es algo interesante...........
-----------------------------------------------
Slitzweitz !!!!!!
2009/12/4 Juan Carlos Quijano Abad <juancarl...@gmail.com>
José Manuel Beas
Dec 4, 2009, 7:15:41 AM12/4/09
to agile-spain
Con todo el afecto me atrevo a recomendar (mucho) la charla de Angel Medinilla sobre este tema. (Los enlaces, más arriba en este mismo hilo). En la segunda parte, más o menos, habla de todos estos posibles escenarios. Creo que es mucho mejor que escuchéis sus explicaciones, las reflexionéis, y luego hagáis vuestras aportaciones. De lo contrario quedamos en el terreno de la charla del bar con los amigos, aka, "a mi me parece", "yo creo que". Hablar de relaciones comerciales es tremendamente difícil, sobre todo si se trata de "innovar" en las mismas. Lo que funciona entre un cliente y un proveedor puede funcionar con otros, pero también puede que no. Creo que hay que ser muy cautos a la hora de sentenciar.
Respecto a lo de si meter Scrum (o cualquier otra nueva metodología) implica mayor coste. En el "transitorio", por supuesto que es posible. Toda introducción de un cambio en una organización puede provocar un mayor coste. En el "permanente", no sabría decir si Scrum es SIEMPRE menos costoso que otras metodologías. Desde una perspectiva teórica, cuando los requisitos no están muy claros, priorizarlos y hacer entregas frecuentes hace que evitemos caer en malentendidos y en trabajar en funcionalidades innecesarias. Eso es un gran ahorro de costes tanto para el cliente como para el proveedor. Además de las mejoras en las habilidades y las relaciones humanas del equipo (y con el cliente) que favorecen este tipo de metodologías. Una relación de desconfianza con el cliente también es un coste, ¿pero cómo se mide?
En cualquier caso, me temo que muchas organizaciones no son realmente conscientes del coste de lo que producen porque muchas ocultan costes trabajando en base a la premisa de que su estimación inicial es correcta e inmutable.
Juan Mari Huarte
Dec 22, 2009, 7:39:29 AM12/22/09
to agile-spain
Un poco muy tarde pero os comento en breve las dificultades más
relevantes que encuentro al vender metodologías ágiles en mi empresa.
relevantes que encuentro al vender metodologías ágiles en mi empresa.
* Nomenclatura: SCRUM, Spring,... son palabras que no entiende la
gente. Un lenguaje más natural facilita MUCHISIMO la venta.
* Facturación: Establecer un esquema claro de facturación. No es
tan difícil.
* Comerciales de venta. Pues sí. Los comerciales que venden
software ven más interesante vender proyectos gordos que no
iteraciones.
* Gestión. La factura por Springs dificulta las labores
administrativas (paradójicamente) y ponen inconvenientes.
* Dedicación del cliente: La dedicación del cliente final hay que
explicarla muchísimo. No ve claro tantas entregas y, como en mi caso,
tantos puntos de prueba.
Un poco tarde pero aquí os pongo mi peque-aportación.
> http://www.agile-spain.comhttp://jmbeas.iExpertos.com<-- ¡Me he mudado!
Jonathan Vila Lopez
Dec 22, 2009, 7:43:05 AM12/22/09
to agile...@googlegroups.com
Me ha parecido muy interesante el enfoque de Juan Mari Huarte.................... Tendre que profundizar sobre eso...........hay que pensar que tal vez los "informaticos" si que tengamos una mente abierta a usar metodologias agiles, pero....hay que contar con los demas departamentos y hay que saber hacerlo muy bien y saber de antemano cuales van a ser los puntos de conflicto....sobre todo con : depto comercial, depto rrhh, depto facturacion, gerencia.
-----------------------------------------------
Slitzweitz !!!!!!
-----------------------------------------------
Slitzweitz !!!!!!
2009/12/22 Juan Mari Huarte <gusarm...@gmail.com>
--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.
Abel Muiño Vizcaino
Dec 22, 2009, 7:56:52 AM12/22/09
to agile...@googlegroups.com
Eso, ya basta de flagelarnos con el cuento del waterfall y lo tontos que somos... ¡Ahora podemos echarle la culpa a otros! :D
Ya en serio... salvo que una empresa sea dirigida por informáticos, los trabajadores son "gastos" y el poder lo tienen los comerciales (los únicos que generan ingresos). Después está el ego de quien tiene el poder... es un equilibrio de poder y relaciones personales, nada fácil para los que estamos acostumbrados a estudiar los "porqués" y los "cómos" de sistemas predecibles.
Cambiar la forma de trabajo es no sólo un tema técnico o limitado a un departamento. Todo depende lo lejos que se quiera llegar (cambiar yo, mi equipo, mi departamento, mi empresa, mis clientes...)
Juan Mari Huarte
Dec 22, 2009, 8:22:55 AM12/22/09
to agile-spain
Y una cosa que he olvidado:
No hay que engañarse. A muchos programadores no les va nada esto
de tener compromisos, fechas y tareas. Muy a menudo sacrifican el
cumplimiento de las fechas a costa de la calidad de lo entregado.
Falta de controles, ausencia de documentación,.. etc,..). A veces
desmotiva más de lo que parece.
On 22 dic, 13:43, Jonathan Vila Lopez <jonathan.v...@gmail.com> wrote:
> Me ha parecido muy interesante el enfoque de Juan Mari
> Huarte.................... Tendre que profundizar sobre eso...........hay
> que pensar que tal vez los "informaticos" si que tengamos una mente abierta
> a usar metodologias agiles, pero....hay que contar con los demas
> departamentos y hay que saber hacerlo muy bien y saber de antemano cuales
> van a ser los puntos de conflicto....sobre todo con : depto comercial, depto
> rrhh, depto facturacion, gerencia.
>
> -----------------------------------------------
> Slitzweitz !!!!!!
>
> 2009/12/22 Juan Mari Huarte <gusarmien...@gmail.com>
> > agile-spain...@googlegroups.com<agile-spain%2Bunsubscribe@googlegroups.com>
> > Para tener acceso a más opciones, visita el grupo en
> >http://groups.google.com/group/agile-spain?hl=es.- Ocultar texto de la cita -
>
> - Mostrar texto de la cita -
José Manuel Beas
Dec 22, 2009, 9:19:12 AM12/22/09
to agile-spain
2009/12/22 Juan Mari Huarte <gusarm...@gmail.com>
Y una cosa que he olvidado:
No hay que engañarse. A muchos programadores no les va nada esto
de tener compromisos, fechas y tareas. Muy a menudo sacrifican el
cumplimiento de las fechas a costa de la calidad de lo entregado.
Y eso... ¡NO ES SER ÁGIL!
Ser ágil (o agilista) implica una gran dosis de autoexigencia y compromiso. Si no cumplimos nuestros compromisos, ¿cómo podremos pedir a los demás lo mismo?
Falta de controles, ausencia de documentación,.. etc,..). A veces
desmotiva más de lo que parece.
A algunos. El agilismo no es para todos. No quiere decir esto que sólo se pueda aplicar el agilismo con una pequeña élite de superhombres. Lo que quiero decir es que sólo se puede hacer agilismo si se está dispuesto a hacer ciertos esfuerzos y sacrificios. Si no, mejor déjalo y permite que sean otros los que tomen las decisiones y controlen la situación (pero luego no te quejes).
¡Feliz Coding Dojo a todos!
¡Uy! ¿En qué estaría yo pensando? ¡Feliz Navidad a todos!
Un abrazo,
JMB
http://agilismo.es
Harald Messemer
Dec 22, 2009, 1:06:42 PM12/22/09
to agile...@googlegroups.com
Buenas,
Sigo la conversacion y ahora cuando salio la palabra "gastos" se
disparo el alarmo y me engancho.
Tambien percibo que los departamentos que producen "gastos" y no
"ingresos" estan mal vistos en las empresas. Este efecto afecta no
solamente a los informativos, sino tambien a otros como HR, FI. Vamos,
todos los colectivos que no forman parte de la cadena de valor, sino
de la cadena administrativa.
La diferencia es que los pasos en la de valor el input / output han
evolucionado de tal manera que el proceso fluye, agregando valor
objetivo. Por objetivo me refiero a que es transparente que gasto y
que obtengo.
En informatica, sin afan de ofender a nadie, estamos acostumbrados de
dar pocas explicaciones. Iba bien durante un tiempo, pero ahora los
clientes tienen alternativas: outsourcing / externalixacion.
Igualmente creo que hay esperanza. A parte de los metodos agiles que
le den tambien al tema del valor, esta la fraccion del "service
management", "itil" (si, itil) y del "bsm". Si interesa mirad en el
grupo del "itsmf" que estan trabajando en ellos.
Un saludo,
Harald
2009/12/22, Abel Muiño Vizcaino <amu...@gmail.com>:
> --
> Abel Muiño - http://ramblingabout.wordpress.com/
>
> --
>
> Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de
> Grupos de Google.
> Para publicar una entrada en este grupo, envía un correo electrónico a
> agile...@googlegroups.com.
> Para anular tu suscripción a este grupo, envía un correo electrónico a
> agile-spain...@googlegroups.com
> Para tener acceso a más opciones, visita el grupo en
> http://groups.google.com/group/agile-spain?hl=es.
>
>
>
--
Von meinen Mobilgerät aus gesendet
xavier.albaladejo
Dec 22, 2009, 2:04:21 PM12/22/09
to agile-spain
On Dec 22, 1:39 pm, Juan Mari Huarte <gusarmien...@gmail.com> wrote:
> Un poco muy tarde pero os comento en breve las dificultades más
> relevantes que encuentro al vender metodologías ágiles en mi empresa.
>
> * Nomenclatura: SCRUM, Spring,... son palabras que no entiende la
> gente. Un lenguaje más natural facilita MUCHISIMO la venta.
Se puede hablar de lo mismo utilizando terminología más cercana: lista
de requisitos priorizada, demostraciones del producto cada 2 semanas
(o cada 3, o cada mes), etc.
> * Facturación: Establecer un esquema claro de facturación. No es
> tan difícil.
> * Comerciales de venta. Pues sí. Los comerciales que venden
> software ven más interesante vender proyectos gordos que no
> iteraciones.
Se puede vender un proyecto gordo con demostraciones del producto cada
2 semanas (o cada 3, o cada mes).
> * Gestión. La factura por Springs dificulta las labores
> administrativas (paradójicamente) y ponen inconvenientes.
Aunque sea mejor facturar por meses (o trimestres o lo que sea), el
modelo de facturación quizás no es tan relevante como la relación de
socios que hay que mantener durante la duración del proyecto (basada
en la ejecución del proyecto por valor y en la oportunidad de la
replanificación regular para alinear expectativas).
> * Dedicación del cliente: La dedicación del cliente final hay que
> explicarla muchísimo. No ve claro tantas entregas y, como en mi caso,
> tantos puntos de prueba.
Por ejemplo te puedes una cadencia de una demo interna (para tener
siempre un producto estabilizado, cerrar objetivos y avanzar) por cada
demo real con el cliente.
Salud,
Xavier Albaladejo
www.proyectosagiles.org
Juan Carlos Quijano Abad
Dec 23, 2009, 5:01:54 AM12/23/09
to agile...@googlegroups.com
Buenos días,
José María, por una vez no estoy de acuerdo con nada de lo que dices en el post. Y me explico:
El tema de "la calidad no es negociable" no es un concepto originario de Agile, es un concepto que existe prácticamente en todas las métodologías y que, por supuesto, no se cumple en casi ninguna. Además el concepto "calidad" es muy ambigüo y comunmente cada desarrollador/responsable/gerente/directo/cliente/cliente del cliente tiene el suyo propio.
La inmensa mayoría de las veceslas entregas deben realizarse tengan la calidad que tenga, mientras esta sea la mínima necesaria para que aporte valor al Product Owner. El más simple ejémplo: un Power Point o una servilleta escrita a mano.
Por ejemplo en PMI (que de gestión de proyectos saben un rato) ante la duda de plazos o contenido, siempre se opta por cumplir los tiempos (si es posible) porque es mejor para el negocio. El cliente sigue confiando en las previsiones y se apunta en la lista de tareas las actuaciones necesarias para subir el nivel de calidad, si fuese necesario.
El paradigma de Agile de capacidad de cambio no implica solo a los requisitos, si no también a la calidad de lo entregado (realmente implica capacidad de soportar el cambio en casi todo). Porque el que se entregue algo que funcione y que aporte valor, no implica que se tenga que realizar la refactorización u optimización en esa misma entrega y no en la siguiente o en la de más allá. Y por eso y para eso están las diferentes versiones de un mismo producto en donde se mejora la calidad y se corrigen los errores.
Por lo cual afirmar que entregar en fechas a costa de la calidad es igual a "no ser agil" es, desde mi punto de vista, leer entre líneas que la calidad va a ser deficiente e ineficiente. Es entender que quien escribe esas líneas tiene un concepto de calidad erroneo (en españa se dice "chapuzero") y además creo que es confundir, por una visión tal vez demasiado extremista, lo que significa ser Agile. A mi parecer en ese párrafo, se márcaba el acento en el problema de la resistencia al cambio, y no el de la insuficiente calidad que, además, no es privativo de las metodologías Agiles si no de TODAS las métodologías de producción.
Ser ágil (o agilista) implica una gran dosis de autoexigencia y compromiso. Si no cumplimos nuestros compromisos, ¿cómo podremos pedir a los demás lo mismo?
¿Desde cuando el Agilismo dá la capacidad/opción de tomar decisiones o controlar la situación? Vuelvo a insistir que las métodologías Agile son metodologías de producción. Por lo cual la cadena de mandos/decisiones/control tienen poco que ver. Lo que intenta está metodología, específicamente el SCRUM, es abstraer al equipo de los vaivenes que sufre todo proyecto y acercarlos a un entorno ideal en donde sea el propio equipo quien gestione su labor. Pero los que toman las decisiones y controlan la situación en una empresa muy raramente son parte de estos equipos de desarrollo.
¿Cómo que no es para todos?
Mira me pongo la gorra de Director/gerente y digo:
"En esta empresa vamos a trabajar con Scrum en nuestros proyectos: el que no lo quiera hacer allí tiene la puerta".
Yá está, Agilismo para todos. (ese10- 20% que dice Angel que vas a tener que prescindir de ellos)
Creo que mistificas las métodologías Agiles detrás de un "aura" de dureza, autocontrol y compromiso (te está haciendo mal Xavi Gost y su asimilación del desarrollo con las artes marciales XD ). La métodologías Agiles, desde un punto de vista teórico y práctico son para mejorar la forma de trabajar. Para hacer las cosas mejor pero sobre todo más naturales, más faciles y más cómodas para quien trabaja.
Y, desde mi experiencia de CMMI, si a alguién le apetece flagelarse con autodisciplina, compromiso y calidad que se meta en una empresa de nivel 3, que eso es terrible.
José María, por una vez no estoy de acuerdo con nada de lo que dices en el post. Y me explico:
El 22 de diciembre de 2009 15:19, José Manuel Beas <jose....@gmail.com> escribió:
2009/12/22 Juan Mari Huarte <gusarm...@gmail.com>Y una cosa que he olvidado:
No hay que engañarse. A muchos programadores no les va nada esto
de tener compromisos, fechas y tareas. Muy a menudo sacrifican el
cumplimiento de las fechas a costa de la calidad de lo entregado.
Y eso... ¡NO ES SER ÁGIL!
El tema de "la calidad no es negociable" no es un concepto originario de Agile, es un concepto que existe prácticamente en todas las métodologías y que, por supuesto, no se cumple en casi ninguna. Además el concepto "calidad" es muy ambigüo y comunmente cada desarrollador/responsable/gerente/directo/cliente/cliente del cliente tiene el suyo propio.
La inmensa mayoría de las veceslas entregas deben realizarse tengan la calidad que tenga, mientras esta sea la mínima necesaria para que aporte valor al Product Owner. El más simple ejémplo: un Power Point o una servilleta escrita a mano.
Por ejemplo en PMI (que de gestión de proyectos saben un rato) ante la duda de plazos o contenido, siempre se opta por cumplir los tiempos (si es posible) porque es mejor para el negocio. El cliente sigue confiando en las previsiones y se apunta en la lista de tareas las actuaciones necesarias para subir el nivel de calidad, si fuese necesario.
El paradigma de Agile de capacidad de cambio no implica solo a los requisitos, si no también a la calidad de lo entregado (realmente implica capacidad de soportar el cambio en casi todo). Porque el que se entregue algo que funcione y que aporte valor, no implica que se tenga que realizar la refactorización u optimización en esa misma entrega y no en la siguiente o en la de más allá. Y por eso y para eso están las diferentes versiones de un mismo producto en donde se mejora la calidad y se corrigen los errores.
Por lo cual afirmar que entregar en fechas a costa de la calidad es igual a "no ser agil" es, desde mi punto de vista, leer entre líneas que la calidad va a ser deficiente e ineficiente. Es entender que quien escribe esas líneas tiene un concepto de calidad erroneo (en españa se dice "chapuzero") y además creo que es confundir, por una visión tal vez demasiado extremista, lo que significa ser Agile. A mi parecer en ese párrafo, se márcaba el acento en el problema de la resistencia al cambio, y no el de la insuficiente calidad que, además, no es privativo de las metodologías Agiles si no de TODAS las métodologías de producción.
Ser ágil (o agilista) implica una gran dosis de autoexigencia y compromiso. Si no cumplimos nuestros compromisos, ¿cómo podremos pedir a los demás lo mismo?
Me asombra está frase. Primeramente porque le hace mal a la difusión del Agilismo ya que si uno de los gurus del movimiento en España me transmite que hay que aumentar en gran medida el nivel de autoexigencia y compromiso para ganarme el mismo pan que me estoy ganando hasta el dia de hoy o, como están las cosas, aún menos. Pues como que me olvido de lo Agil y sigo con mis 10 horas diarias de currillo que ya tengo bastante autoexigencia y compromiso con mi métodología ASM.
Segundo, en mi experiencia con SCRUM justamente lo que más le gustaba al equipo de desarrollo es que el compromiso y la autoexigencia se transformá en un movimiento cooperativo y gregario. Yá no estás tu solo ante tu pantalla y tu módulo con el excel de plazos y el jefe de proyecto preguntandote ¿qué tal vas? a las 11 de la noche de un sábado. Si no que tu responsabilidad es compartida con todos los miembros del equipo y la autoexigencia se convierte en un movimiento de empuje del grupo, del clan. Y, por supuesto, para un Jefe de Proyecto (como el que escribe), es simplemente maravilloso ver la BurnDown Chart.
Básicamente, las métodologías Agiles y en especial SCRUM lo que hacen es hacerle la vida MUCHO más facil al currante.
Pero lo de: ¿pedir lo mismo? no lo he entendido. ¿Porqué le he de pedir a nadie que tenga mi nivel de autoexigencia o profesionalismo? Si estamos en un cargo de dirección (sea jefe de proyecto o director general) lo que se exije es cumplir la planificación que hemos realizado entre todos y preocuparme del cliente y de las desviaciones en el sprint. No les voy a pedir que hagan una Kata todos los días o que se sepan los cuatrocientos patrones de diseño o que tengan un blog de Agilismo.
Es curioso una triste coincidencia, pero los únicos que conozco con este tipo de exigencias, y los he vivido en mis carnes, son aquellos empresarios que se han echo a sí mismos, que curran como auténticos cabrones (y siempre se ufanan de ello) y que no les entra en la mollera que la mayoría de la gente quiera currar sus ocho horas e irse a sus casas a vivir.
Segundo, en mi experiencia con SCRUM justamente lo que más le gustaba al equipo de desarrollo es que el compromiso y la autoexigencia se transformá en un movimiento cooperativo y gregario. Yá no estás tu solo ante tu pantalla y tu módulo con el excel de plazos y el jefe de proyecto preguntandote ¿qué tal vas? a las 11 de la noche de un sábado. Si no que tu responsabilidad es compartida con todos los miembros del equipo y la autoexigencia se convierte en un movimiento de empuje del grupo, del clan. Y, por supuesto, para un Jefe de Proyecto (como el que escribe), es simplemente maravilloso ver la BurnDown Chart.
Básicamente, las métodologías Agiles y en especial SCRUM lo que hacen es hacerle la vida MUCHO más facil al currante.
Pero lo de: ¿pedir lo mismo? no lo he entendido. ¿Porqué le he de pedir a nadie que tenga mi nivel de autoexigencia o profesionalismo? Si estamos en un cargo de dirección (sea jefe de proyecto o director general) lo que se exije es cumplir la planificación que hemos realizado entre todos y preocuparme del cliente y de las desviaciones en el sprint. No les voy a pedir que hagan una Kata todos los días o que se sepan los cuatrocientos patrones de diseño o que tengan un blog de Agilismo.
Es curioso una triste coincidencia, pero los únicos que conozco con este tipo de exigencias, y los he vivido en mis carnes, son aquellos empresarios que se han echo a sí mismos, que curran como auténticos cabrones (y siempre se ufanan de ello) y que no les entra en la mollera que la mayoría de la gente quiera currar sus ocho horas e irse a sus casas a vivir.
Falta de controles, ausencia de documentación,.. etc,..). A veces
desmotiva más de lo que parece.
A algunos. El agilismo no es para todos. No quiere decir esto que sólo se pueda aplicar el agilismo con una pequeña élite de superhombres. Lo que quiero decir es que sólo se puede hacer agilismo si se está dispuesto a hacer ciertos esfuerzos y sacrificios. Si no, mejor déjalo y permite que sean otros los que tomen las decisiones y controlen la situación (pero luego no te quejes).
¿Desde cuando el Agilismo dá la capacidad/opción de tomar decisiones o controlar la situación? Vuelvo a insistir que las métodologías Agile son metodologías de producción. Por lo cual la cadena de mandos/decisiones/control tienen poco que ver. Lo que intenta está metodología, específicamente el SCRUM, es abstraer al equipo de los vaivenes que sufre todo proyecto y acercarlos a un entorno ideal en donde sea el propio equipo quien gestione su labor. Pero los que toman las decisiones y controlan la situación en una empresa muy raramente son parte de estos equipos de desarrollo.
¿Cómo que no es para todos?
Mira me pongo la gorra de Director/gerente y digo:
"En esta empresa vamos a trabajar con Scrum en nuestros proyectos: el que no lo quiera hacer allí tiene la puerta".
Yá está, Agilismo para todos. (ese10- 20% que dice Angel que vas a tener que prescindir de ellos)
Creo que mistificas las métodologías Agiles detrás de un "aura" de dureza, autocontrol y compromiso (te está haciendo mal Xavi Gost y su asimilación del desarrollo con las artes marciales XD ). La métodologías Agiles, desde un punto de vista teórico y práctico son para mejorar la forma de trabajar. Para hacer las cosas mejor pero sobre todo más naturales, más faciles y más cómodas para quien trabaja.
Y, desde mi experiencia de CMMI, si a alguién le apetece flagelarse con autodisciplina, compromiso y calidad que se meta en una empresa de nivel 3, que eso es terrible.
Juan Mari Huarte
Dec 23, 2009, 5:23:38 AM12/23/09
to agile-spain
Un poco por matizar cuando comentaba este problema.
> >> No hay que engañarse. A muchos programadores no les va nada esto
> >> de tener compromisos, fechas y tareas. Muy a menudo sacrifican el
> >> cumplimiento de las fechas a costa de la calidad de lo entregado.
La situación es la siguiente. En la iteración 5, por prisas, o poco
acoplamiento se hace la entrega.
Dos meses más tarde te "despiertas" con que tienes un código muy poco
robusto, sin documentar o sin aplicar normativas etc,.. y a lo mejor
tienes que hacer una iteración para refactorizar código.
Las respuesta de algunos profesionales es que había que entregar a
tiempo y esas cosas. La lectura que yo hago es que la presión en la
entrega da una TENDENCIA a que personas del equipo desarrollen con una
calidad demasiado ajustada, sobre todo en aquello que es más
"opinable".
De alguna manera, puestos a hablar sobre ello, es como que me hace
falta una palanca en lo ágil que apriete en la calidad de lo que no
suele ser evidente en los desarrollos. Pudiera ser controles,
revisiones, pudiera ser incentivos económicos en función de la
calidad,... esa es la idea que ahora me puede aportar algo en mi
trabajo. ¿Quién sabe como manejar esa palanca?
José Manuel Beas
Dec 23, 2009, 6:21:00 AM12/23/09
to agile-spain
2009/12/23 Juan Mari Huarte <gusarm...@gmail.com>
1) Has incurrido en deuda técnica.
2) Hablas de refactorizar cuando en realidad quieres decir resolver defectos.
3) Y encima se lo haces pagar a tu cliente con una iteración entera para resolver tus cagadas. :-(
¿Y por qué es opinable? ¿No tiene cada historia de usuario una "definition of done"? ¿Un criterio de aceptación?
Eso no es opinable, está hecho o no está hecho.
Además, si debe estar el código documentado, tests unitarios para todo, los procedimientos de puesta en producción, etc... las pruebas de aceptación manuales, los manuales de usuario, etc... si todo eso debe estar y no hemos podido automatizar mucho de esto... tampoco es opinable: está hecho o no está hecho. Es más, al final de la demo, el cliente está satisfecho con lo que habíamos comprometido a entregar en esa iteración o no lo está.
Eso desde el punto de vista del jefe de proyecto. Desde el punto de vista del equipo, si somos ágiles, no debería haber diferencia. Somos responsables de lo que hacemos y a lo que nos comprometemos. No deberíamos comprometernos a cosas que sabemos que son imposibles de cumplir (salvo que renunciemos a la calidad). Por eso se incita desde el agilismo a que el equipo participe en las estimaciones. Es una manera de no crear falsas expectativas.
Otra cosa es que no tengamos ni idea de si podemos o no comprometernos. Eso puede ser por miedo (si te presionan y tu hipoteca depende de que te paguen a fin de mes...) o por falta de capacitación (no tengo ni idea de JSF pero he hecho algo con Struts) o peor aún, por falta de profesionalidad (tengo un amiguete que hizo una aplicación en un par de días, he visto que hay muchos ejemplos en Google y además, yo soy muy listo y seguro que no tengo problema con esto). Todos estos casos tienen remedio porque como caso extremo siempre podemos recurrir al despido del trabajador poco profesional. Sí, tal cual. Porque esto es un negocio, ¿verdad? Y no queremos estar rodeados de gente que no es profesional, ¿verdad?
1) Capacitación profesional. Si tu equipo sólo saber hacer basura, al final de una iteración tendrás basura. (Eso sí, te enterarás antes de que tienes basura en vez de software que funciona).
2) Bajar tus expectativas. Si sabes que no puedes tener una velocidad de un equipo de gurús del Java (o de la tecnología que sea), pues tendrás que aceptarlo y bajar tu velocidad hasta conseguir producir software con un coste predecible. Si el coste es demasiado alto, tienes la opción de capacitar más a tu equipo, despedirlos o dedicarte al cultivo de las alcachofas.
3) Hay muchas buenas prácticas que ayudan a aumentar la capacitación y la calidad de los resultados del equipo: programación por parejas, revisiones de código, retrospectivas, reuniones diarias, propiedad colectiva del código, integración continua... ¿sigo? ;-) Lo que no creo es que con incentivos económicos vayas a conseguir que aprendan a escribir código más limpio, en cambio dejando un par de buenos libros encima de una mesa para que el que tenga ganas lo lea... así creo que tienes más posibilidades.
De todos modos, ¿qué consideras tú como "no evidente en los desarrollos"? (Lo que para uno es evidente, para otro puede no serlo. Quizás haya que explicitarlo tanto con el cliente como dentro del equipo, porque también nos creamos expectativas dentro del seno del equipo).
Un saludo,
JMB
Un poco por matizar cuando comentaba este problema.
La situación es la siguiente. En la iteración 5, por prisas, o poco
> >> No hay que engañarse. A muchos programadores no les va nada esto
> >> de tener compromisos, fechas y tareas. Muy a menudo sacrifican el
> >> cumplimiento de las fechas a costa de la calidad de lo entregado.
acoplamiento se hace la entrega.
Dos meses más tarde te "despiertas" con que tienes un código muy poco
robusto, sin documentar o sin aplicar normativas etc,.. y a lo mejor
tienes que hacer una iteración para refactorizar código.
1) Has incurrido en deuda técnica.
2) Hablas de refactorizar cuando en realidad quieres decir resolver defectos.
3) Y encima se lo haces pagar a tu cliente con una iteración entera para resolver tus cagadas. :-(
Las respuesta de algunos profesionales es que había que entregar a
tiempo y esas cosas. La lectura que yo hago es que la presión en la
entrega da una TENDENCIA a que personas del equipo desarrollen con una
calidad demasiado ajustada, sobre todo en aquello que es más
"opinable".
¿Y por qué es opinable? ¿No tiene cada historia de usuario una "definition of done"? ¿Un criterio de aceptación?
Eso no es opinable, está hecho o no está hecho.
Además, si debe estar el código documentado, tests unitarios para todo, los procedimientos de puesta en producción, etc... las pruebas de aceptación manuales, los manuales de usuario, etc... si todo eso debe estar y no hemos podido automatizar mucho de esto... tampoco es opinable: está hecho o no está hecho. Es más, al final de la demo, el cliente está satisfecho con lo que habíamos comprometido a entregar en esa iteración o no lo está.
Eso desde el punto de vista del jefe de proyecto. Desde el punto de vista del equipo, si somos ágiles, no debería haber diferencia. Somos responsables de lo que hacemos y a lo que nos comprometemos. No deberíamos comprometernos a cosas que sabemos que son imposibles de cumplir (salvo que renunciemos a la calidad). Por eso se incita desde el agilismo a que el equipo participe en las estimaciones. Es una manera de no crear falsas expectativas.
Otra cosa es que no tengamos ni idea de si podemos o no comprometernos. Eso puede ser por miedo (si te presionan y tu hipoteca depende de que te paguen a fin de mes...) o por falta de capacitación (no tengo ni idea de JSF pero he hecho algo con Struts) o peor aún, por falta de profesionalidad (tengo un amiguete que hizo una aplicación en un par de días, he visto que hay muchos ejemplos en Google y además, yo soy muy listo y seguro que no tengo problema con esto). Todos estos casos tienen remedio porque como caso extremo siempre podemos recurrir al despido del trabajador poco profesional. Sí, tal cual. Porque esto es un negocio, ¿verdad? Y no queremos estar rodeados de gente que no es profesional, ¿verdad?
De alguna manera, puestos a hablar sobre ello, es como que me hace
falta una palanca en lo ágil que apriete en la calidad de lo que no
suele ser evidente en los desarrollos. Pudiera ser controles,
revisiones, pudiera ser incentivos económicos en función de la
calidad,... esa es la idea que ahora me puede aportar algo en mi
trabajo. ¿Quién sabe como manejar esa palanca?
1) Capacitación profesional. Si tu equipo sólo saber hacer basura, al final de una iteración tendrás basura. (Eso sí, te enterarás antes de que tienes basura en vez de software que funciona).
2) Bajar tus expectativas. Si sabes que no puedes tener una velocidad de un equipo de gurús del Java (o de la tecnología que sea), pues tendrás que aceptarlo y bajar tu velocidad hasta conseguir producir software con un coste predecible. Si el coste es demasiado alto, tienes la opción de capacitar más a tu equipo, despedirlos o dedicarte al cultivo de las alcachofas.
3) Hay muchas buenas prácticas que ayudan a aumentar la capacitación y la calidad de los resultados del equipo: programación por parejas, revisiones de código, retrospectivas, reuniones diarias, propiedad colectiva del código, integración continua... ¿sigo? ;-) Lo que no creo es que con incentivos económicos vayas a conseguir que aprendan a escribir código más limpio, en cambio dejando un par de buenos libros encima de una mesa para que el que tenga ganas lo lea... así creo que tienes más posibilidades.
De todos modos, ¿qué consideras tú como "no evidente en los desarrollos"? (Lo que para uno es evidente, para otro puede no serlo. Quizás haya que explicitarlo tanto con el cliente como dentro del equipo, porque también nos creamos expectativas dentro del seno del equipo).
Un saludo,
JMB
Jonathan Vila Lopez
Dec 23, 2009, 6:31:44 AM12/23/09
to agile...@googlegroups.com
Buffff habeis tocado un tema que me toca la fibra................
"Todos estos casos tienen remedio porque como caso extremo siempre podemos recurrir al despido del trabajador poco profesional. Sí, tal cual."
No habria que despedir primero al que va a despedir al trabajador ? si hay un trabajador con baja cualificacion, es culpa del trabajador ? si un trabajador no rinde lo necesario, es culpa del trabajador o que el "jefe" no ha trabajado la motivacion del equipo ? si no se llega a plazos, despedimos al trabajador o al gestor que no ha sabido informarse bien de todas las particularidades del proyecto incluyendo el factor humano de su equipo ?
"1) Capacitación profesional. Si tu equipo sólo saber hacer basura, al final de una iteración tendrás basura ..... Si el coste es demasiado alto, tienes la opción de capacitar más a tu equipo, despedirlos o dedicarte al cultivo de las alcachofas."
Tal vez lo importante sera buscar el motivo de porque el equipo hace basura......El tema que aqui veo es que en ningun momento se hace mencion a "presentas la dimision".. tened en cuenta que si un equipo funciona mal, la gran mayoria de las veces es culpa del gestor del equipo.
"...en cambio dejando un par de buenos libros encima de una mesa para que el que tenga ganas lo lea"
Bufffffff, asi de facil ? basando el exito del proyecto en la buena voluntad e implicacion de la gente ? de forma espontanea ? No creo en eso. Como gestores de equipo generalmente no tenemos competencias en sueldo, vacaciones, horarios...etc.......que corresponde a otros departamentos....y si la politica de la compañia no favorece el buen rollo de la gente........tenemos que confiar en que se motiven solos ? No se trata de imponer nada, sino de motivar, movilizar, dar ejemplo y energia, no de esperar que por arte de magia se sientan motivados y se formen solos.
-----------------------------------------------
Slitzweitz !!!!!!
"Todos estos casos tienen remedio porque como caso extremo siempre podemos recurrir al despido del trabajador poco profesional. Sí, tal cual."
"1) Capacitación profesional. Si tu equipo sólo saber hacer basura, al final de una iteración tendrás basura ..... Si el coste es demasiado alto, tienes la opción de capacitar más a tu equipo, despedirlos o dedicarte al cultivo de las alcachofas."
Tal vez lo importante sera buscar el motivo de porque el equipo hace basura......El tema que aqui veo es que en ningun momento se hace mencion a "presentas la dimision".. tened en cuenta que si un equipo funciona mal, la gran mayoria de las veces es culpa del gestor del equipo.
"...en cambio dejando un par de buenos libros encima de una mesa para que el que tenga ganas lo lea"
Bufffffff, asi de facil ? basando el exito del proyecto en la buena voluntad e implicacion de la gente ? de forma espontanea ? No creo en eso. Como gestores de equipo generalmente no tenemos competencias en sueldo, vacaciones, horarios...etc.......que corresponde a otros departamentos....y si la politica de la compañia no favorece el buen rollo de la gente........tenemos que confiar en que se motiven solos ? No se trata de imponer nada, sino de motivar, movilizar, dar ejemplo y energia, no de esperar que por arte de magia se sientan motivados y se formen solos.
-----------------------------------------------
Slitzweitz !!!!!!
2009/12/23 José Manuel Beas <jose....@gmail.com>
--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Juan Mari Huarte
Dec 23, 2009, 6:38:04 AM12/23/09
to agile-spain
Hola Jose Manuel,
Yo sigo con el hilo por si puede ser de interés, aunque igual
llegados a este punto es un tema más para hablar con contextos reales,
y eso es difícil si no es cara a cara con un papel.
La primera cosa, por poner en contexto es que en mi caso yo soy
el cliente. Yo subcontrato desarrollos.
Mi concepto de calidad, a través de los años, y esto es
totalmente discutible se basa fundamentalmente en dos patas, que
llevan a las demás y que son:
* El soft funciona como esperaría un
usuario en aplicaciones similares según las especificaciones dadas.
* El soft es flexible. Es decir, se pueden
hacer cambios trascendentales porque su modularidad, documentación y
calidad lo permiten sin llegar a pensar que es mejor reescribir todo
(esto entiendo que es muy discutible).
La capacitación del personal, que rara vez puedes elegir
realmente con diciona el proyecto, es verdad, y hay que vivir con
ella.
La deuda técnica, cuando existe, es muy difícil de negociar.
Normalmente te casas con los proveedores, y los proveedores con sus
equipos.
Me resulta difícil ver cómo puedo hacer no opinable todo el
código que se escribe. Siempre quedan retazos de cosas que las decide
el programador. De hecho les tengo en muy alta consideración por la
cantidad de cosas que deciden en un desarrollo. Y eso es buen hacer,
opinión o queramos llamarlo. Esto da para libros así que lo dejamos.
Equipo basura: Mi objetivo es convertirlo en bueno. Nunca optar
por cambios. Prefiero palancar para hacer bueno lo malo que cualquier
otra cosa. También opinión personal. Pero descarto los despidos etc, a
priori salvo casos extremos.
Dicho el contexto, vuelvo al principio. Me falta la palanca que
apriete en la calidad, a poder ser a través de la motivación. Y lo
digo porque percibo en Scrumb esa tendencia a ajustarla. Os he puesto
ideas muy genéricas de como puede ser esa palanca, que no tengo en
absoluto maduradas. Otra cosa es que se vea que no es necesario
apretar por aquí.
Saludo y gracias por hacerme pensar ;-)
Juan Mari Huarte -
José Manuel Beas
Dec 23, 2009, 6:45:19 AM12/23/09
to agile-spain
2009/12/23 Jonathan Vila Lopez <jonath...@gmail.com>
Buffff habeis tocado un tema que me toca la fibra................No habria que despedir primero al que va a despedir al trabajador ? si hay un trabajador con baja cualificacion, es culpa del trabajador ? si un trabajador no rinde lo necesario, es culpa del trabajador o que el "jefe" no ha trabajado la motivacion del equipo ? si no se llega a plazos, despedimos al trabajador o al gestor que no ha sabido informarse bien de todas las particularidades del proyecto incluyendo el factor humano de su equipo ?
"Todos estos casos tienen remedio porque como caso extremo siempre podemos recurrir al despido del trabajador poco profesional. Sí, tal cual."
Me autocito: "Como caso extremo" :-)
"1) Capacitación profesional. Si tu equipo sólo saber hacer basura, al final de una iteración tendrás basura ..... Si el coste es demasiado alto, tienes la opción de capacitar más a tu equipo, despedirlos o dedicarte al cultivo de las alcachofas."
Tal vez lo importante sera buscar el motivo de porque el equipo hace basura......El tema que aqui veo es que en ningun momento se hace mencion a "presentas la dimision".. tened en cuenta que si un equipo funciona mal, la gran mayoria de las veces es culpa del gestor del equipo.
Claro que puedes presentar la dimisión. Es lo recomendable (si te lo puedes permitir). Si no te gusta donde trabajas: lo cambias ... o te marchas.
"...en cambio dejando un par de buenos libros encima de una mesa para que el que tenga ganas lo lea"
Bufffffff, asi de facil ? basando el exito del proyecto en la buena voluntad e implicacion de la gente ? de forma espontanea ? No creo en eso. Como gestores de equipo generalmente no tenemos competencias en sueldo, vacaciones, horarios...etc.......que corresponde a otros departamentos....y si la politica de la compañia no favorece el buen rollo de la gente........tenemos que confiar en que se motiven solos ? No se trata de imponer nada, sino de motivar, movilizar, dar ejemplo y energia, no de esperar que por arte de magia se sientan motivados y se formen solos.
Sí. Así de fácil.. y así de difícil. Confiar y dar confianza. Te sorprendería lo que se puede llegar a conseguir así. (Pero no he dicho que sea un camino fácil).
Un saludo,
JMB
Juan Carlos Quijano Abad
Dec 23, 2009, 6:54:25 AM12/23/09
to agile...@googlegroups.com
Buenas,
En lo que he podido experimentar en mis carnes, la mayor palanca para el apriete en la calidad son las reuniones diarias y la restrospectiva al final del sprint. Porque los desarrolladores ponen su conocimiento a la vista de los demás del equipo y eso motiva (y mucho) a hacerlo lo menos mál posible (incluso algunos quieren hacerlo lo mejor que pueden).
También en todo equipo hay siempre quien sabe más que los demás en algo, y se convierte en la persona a quien se le escuchan sus opiniones sobre la calidad o mejoras en ese tema. Lo cual también ayuda a fomentar un mejor nivel de calidad.
Y por último, en mi específico caso, siempre el Scrum master, ha sido o el jefe de proyecto o el lider del equipo. Persona con experiencia suficiente como para que el resto del equipo "trague" con sus decisiones sobre la calidad. Aunque en SCRUM puro este rol sobra.
Ese es el truco de SCRUM para obtener una mayor calidad: expon tus verguenzas al publico pero para mejorar no para ser criticadas.
Igualmente, gracias a todos por el mismo motivo...
Dicho el contexto, vuelvo al principio. Me falta la palanca que
apriete en la calidad, a poder ser a través de la motivación. Y lo
digo porque percibo en Scrumb esa tendencia a ajustarla. Os he puesto
ideas muy genéricas de como puede ser esa palanca, que no tengo en
absoluto maduradas. Otra cosa es que se vea que no es necesario
apretar por aquí.
En lo que he podido experimentar en mis carnes, la mayor palanca para el apriete en la calidad son las reuniones diarias y la restrospectiva al final del sprint. Porque los desarrolladores ponen su conocimiento a la vista de los demás del equipo y eso motiva (y mucho) a hacerlo lo menos mál posible (incluso algunos quieren hacerlo lo mejor que pueden).
También en todo equipo hay siempre quien sabe más que los demás en algo, y se convierte en la persona a quien se le escuchan sus opiniones sobre la calidad o mejoras en ese tema. Lo cual también ayuda a fomentar un mejor nivel de calidad.
Y por último, en mi específico caso, siempre el Scrum master, ha sido o el jefe de proyecto o el lider del equipo. Persona con experiencia suficiente como para que el resto del equipo "trague" con sus decisiones sobre la calidad. Aunque en SCRUM puro este rol sobra.
Ese es el truco de SCRUM para obtener una mayor calidad: expon tus verguenzas al publico pero para mejorar no para ser criticadas.
Saludo y gracias por hacerme pensar ;-)
Juan Mari Huarte -
Igualmente, gracias a todos por el mismo motivo...
Jonathan Vila Lopez
Dec 23, 2009, 6:55:52 AM12/23/09
to agile...@googlegroups.com
Perdonad mi desconfianza...........
Sí. Así de fácil.. y así de difícil. Confiar y dar confianza. Te sorprendería lo que se puede llegar a conseguir así. (Pero no he dicho que sea un camino fácil).
Yo he estado en bastantes compañías y puedo asegurar por mi experiencia que eso no es cierto siempre.......que experiencia práctica en compañías de desarrollo ( no como coach ) avala esa aseveración ?
Como ya he dicho hay muchas cosas que como gestores de equipo no podemos controlar........ vosotros creéis que poniendo libros encima de la mesa y dando confianza ( que no diga que este mal ) obtendremos implicación de parte de un equipo que no cobra lo que cree que debería cobrar, o que cobra a destiempo, o que se ve despreciado por gerencia por las normas impuestas, o que esta temeroso al despido ????
Hay muchas practicas para construccion de equipo y , por poner un ejemplo el PMI del cual estoy certificado propone bastantes y muy interesantes........ pero casi todas pasan por una motivacion activa no por una esperanza en la motivacion espontanea..............
Vuelvo a repetir, perdonam mi desconfianza basada sobre todo en el desconocimiento.......pero a veces me da la sensacion que los "llamados agilistas" viven en un mundo demasiado ideal porque os aseguro que aplicar , tal y como comentais, las metodologias Agiles yo no habria podido aplicarlo en ninguna de las compañias en que he trabajado puesto que seria una lucha constante con todos los departamentos..... pero Dios, si poner una reunion interna los viernes por la tarde ya era casi como traicionar a la empresa y habia que hacerlo casi a escondidas.........
-----------------------------------------------
Slitzweitz !!!!!!
Sí. Así de fácil.. y así de difícil. Confiar y dar confianza. Te sorprendería lo que se puede llegar a conseguir así. (Pero no he dicho que sea un camino fácil).
Como ya he dicho hay muchas cosas que como gestores de equipo no podemos controlar........ vosotros creéis que poniendo libros encima de la mesa y dando confianza ( que no diga que este mal ) obtendremos implicación de parte de un equipo que no cobra lo que cree que debería cobrar, o que cobra a destiempo, o que se ve despreciado por gerencia por las normas impuestas, o que esta temeroso al despido ????
Hay muchas practicas para construccion de equipo y , por poner un ejemplo el PMI del cual estoy certificado propone bastantes y muy interesantes........ pero casi todas pasan por una motivacion activa no por una esperanza en la motivacion espontanea..............
Vuelvo a repetir, perdonam mi desconfianza basada sobre todo en el desconocimiento.......pero a veces me da la sensacion que los "llamados agilistas" viven en un mundo demasiado ideal porque os aseguro que aplicar , tal y como comentais, las metodologias Agiles yo no habria podido aplicarlo en ninguna de las compañias en que he trabajado puesto que seria una lucha constante con todos los departamentos..... pero Dios, si poner una reunion interna los viernes por la tarde ya era casi como traicionar a la empresa y habia que hacerlo casi a escondidas.........
-----------------------------------------------
Slitzweitz !!!!!!
2009/12/23 José Manuel Beas <jose....@gmail.com>
2009/12/23 Jonathan Vila Lopez <jonath...@gmail.com>
José Manuel Beas
Dec 23, 2009, 7:02:03 AM12/23/09
to agile-spain
2009/12/23 Juan Mari Huarte <gusarm...@gmail.com>
Dicho el contexto, vuelvo al principio. Me falta la palanca que
apriete en la calidad, a poder ser a través de la motivación. Y lo
digo porque percibo en Scrumb esa tendencia a ajustarla. Os he puesto
ideas muy genéricas de como puede ser esa palanca, que no tengo en
absoluto maduradas. Otra cosa es que se vea que no es necesario
apretar por aquí.
Scrum no se mete en la cómo obtener calidad porque es más un marco de referencia para gestionar el desarrollo de un producto. Si te fijas, no se mete mucho en cómo se debe desarrollar el software, sino más bien en dos o tres prácticas de higiene que ayudan a que un equipo automotivado, autodisciplinado, autoexigente... vaya obteniendo un producto adecuado a las expectativas del cliente. XP, por ejemplo, se mete mucho más en las prácticas de desarrollo y te aconseja integración continua, propiedad colectiva del código, 40 horas semanales, etc. ¿Por qué? Porque XP está mucho más enfocado al equipo de desarrollo. En cualquier caso, quizás porque es un invento más bien anglosajón, se presupone que la gente va a trabajar con un mínimo de motivación y madurez. Si, como gerente/jefe de proyecto/gestor de un presupuesto... quieres mantener en tu tropa a gente que se dedica a sabotear tu trabajo porque estamos en Navidad y te da pena... bueno, es tu decisión. Yo soy un ogro malo y pienso que cuando la gente no es profesional (no he dicho productiva, he dicho profesional), sólo hay dos opciones: enseñarles en qué consiste ser profesional y exigirles que lo sean y, si eso no funciona, "lo siento mucho, pero te invito a marcharte". (Los puedes cambiar de equipo antes de despedirlos, porque a veces la gente no encaja en un contexto, pero la mecánica es la misma)
En resumen, ¿tiene sentido que mantegamos en un equipo a gente que no quiere ser responsable de sus compromisos? ¿Es conveniente perder energía en arreglar los estropicios de alguien que no tiene ningún interés en hacer las cosas bien? Bueno, lo valoras y ya me dirás si te sale a cuenta. :-)
Creo que era Jonathan el que decía que había que despedir a los responsables de contratar a esta gente poco profesional. Cada uno debería asumir su cuota parte de responsabilidad y no eludirla (que es lo que se hace normalmente). Los jefes de proyecto deberían despedir a la gente de sus equipos que no son profesionales e igualmente los directores de departamento con los jefes de proyecto que no son profesionales... y así hasta la dirección general, el dueño o quien corresponda. Eso es un ideal porque al final las empresas están hechas de personas y las personas tenemos compromisos emocionales. ¡Hay que fastidiarse! :-)
Entended que ayer estuve viendo Star Trek y soy un fan del Dr. Spock. :-D
Saludo y gracias por hacerme pensar ;-)
Juan Mari Huarte -
Idem,
JMB
Juan Mari Huarte
Dec 23, 2009, 7:14:08 AM12/23/09
to agile-spain
Una regla de oro que tengo encima de la mesa es que no despidas si
no estás seguro que vas a obtener un beneficio. Así que piénsalo bien.
Con esto lo dejo claro. Se despide o, en mi caso, dejo de contratar o
cambio de proveedor cuando encuentro un beneficio. Adelanto que no
suele ser fácil salir beneficiado.
no estás seguro que vas a obtener un beneficio. Así que piénsalo bien.
Con esto lo dejo claro. Se despide o, en mi caso, dejo de contratar o
cambio de proveedor cuando encuentro un beneficio. Adelanto que no
suele ser fácil salir beneficiado.
Y sigo con el mismo tema (¡Qué pelma soy!). Si he detectado una
tendencia a la bajada de calidad por la premura de las entregas, pues
busco elementos para incrementarla. Me gusta lo de las reuniones. Creo
que es clave. Pero en ese cuarto de hora mañanero hay que ser bastante
hábil, y la habilidad no siempre abunda. Tampoco quiero llegar a
pensar que esto solo tiene éxito cuando gente super hábil lo gestiona.
Eso sería una trampa. Por eso busco refuerzos, cuantos más mejor.
Cosas de la vida real.
Bueno. Cierro el ordenador a por las merecidas vacatas y ahora lo
abriré menos. No he visto muchos saludos navideños así que os mando un
buen Felices Fiestas a todos de todo corazón. Ya sabéis, será un poco
cursi, pero cultivemos un poco esto de la navidad, que en unos años ya
se va a quedar en nada. :-)
José Manuel Beas
Dec 23, 2009, 7:57:23 AM12/23/09
to agile-spain
2009/12/23 Jonathan Vila Lopez <jonath...@gmail.com>
Perdonad mi desconfianza...........
Está usted perdonado.
Está justificada la desconfianza porque es humano. :-)
Yo he estado en bastantes compañías y puedo asegurar por mi experiencia que eso no es cierto siempre.......que experiencia práctica en compañías de desarrollo ( no como coach ) avala esa aseveración ?
Sí. Así de fácil.. y así de difícil. Confiar y dar confianza. Te sorprendería lo que se puede llegar a conseguir así. (Pero no he dicho que sea un camino fácil).
En una pequeña startup pude montar un pequeño equipo para desarrollar un producto. Por aquel entonces no había leido siquiera sobre Scrum y muy poco sobre XP. Pero le di la confianza a mi equipo en que ellos llegaran a la hora que más les conviniera para conciliar su vida personal y profesional. Y aunque mi jefe viniera muchas veces y se encontrara el "pisito" vacío, el hecho incontestable es que sacabamos el proyecto adelante. Lo podríamos haber hecho mucho mejor si hubieramos sabido hacer las cosas mejor, especialmente el jefe de proyecto (ups, yo), pero el hecho incontestable es que como di confianza recibí confianza. Como les di la posibilidad de ser responsables de su trabajo, la mayoría lo fue. Y el que no lo fue (uno de cuatro), estuve a punto de pedirle a mi jefe que se lo llevara del equipo. No me dio tiempo: se fue él antes. :-)
Como ya he dicho hay muchas cosas que como gestores de equipo no podemos controlar........ vosotros creéis que poniendo libros encima de la mesa y dando confianza ( que no diga que este mal ) obtendremos implicación de parte de un equipo que no cobra lo que cree que debería cobrar, o que cobra a destiempo, o que se ve despreciado por gerencia por las normas impuestas, o que esta temeroso al despido ????
No es una receta milagrosa. Desconfía de las recetas milagrosas. Si alguien te dice que haciendo Scrum vivirás mejor, duda de él. Si alguien te dice que certificandote en CMMI vivirás mejor, duda de él. Si alguien te dice que pidiendo que la gente sea profesional vivirás mejor, duda de él. Mi experiencia es que no hay dos personas iguales, y por tanto, no hay dos equipos/empresa/organización/ministerio... iguales. No hay recetas milagrosas. Sólo puedes aplicar altas dosis de empatía, escuchar mucho y darle a cada uno la medicina que toca. Y si no te queda más remedio que aplicar cirujía, porque en ello le va la vida al paciente, pues tendrás que hacerlo. O estarás siendo un mal médico.
Hay muchas practicas para construccion de equipo y , por poner un ejemplo el PMI del cual estoy certificado propone bastantes y muy interesantes........ pero casi todas pasan por una motivacion activa no por una esperanza en la motivacion espontanea..............
Un buen libro para las Navidades: Agile Coaching. Otro: Collaboration Explained. Y otro: Peopleware. Y otro más: Fearless Change. No quiero con esto validar mis palabras citando a otros, lo que quiero decir es que hay muchas técnicas e incluso patrones para conseguir equipos automotivados. (Aunque ello pase por apartar o apartarse de los que implican un coste demasiado alto para motivarlos). Yo creo que es mejor tener a dos personas automotivadas que produzcan x10 en vez de 20 personas desmotivadas que produzcan x1. La energía para intentar motivar a tanta gente prefiero usarla en otras cosas, como por ejemplo conseguir que esos dos x10 se conviertan en dos x15, lo cuál, además de requerir menos energía, es mucho más gratificante para todos. :-)
Vuelvo a repetir, perdonam mi desconfianza basada sobre todo en el desconocimiento.......pero a veces me da la sensacion que los "llamados agilistas" viven en un mundo demasiado ideal porque os aseguro que aplicar , tal y como comentais, las metodologias Agiles yo no habria podido aplicarlo en ninguna de las compañias en que he trabajado puesto que seria una lucha constante con todos los departamentos..... pero Dios, si poner una reunion interna los viernes por la tarde ya era casi como traicionar a la empresa y habia que hacerlo casi a escondidas.........
En las cervezas después del Coding Dojo de agilismo.es coincidimos hablando de algo parecido. Somos los que estamos convencidos de que se pueden hacer las cosas de otra manera los que tenemos que cambiar nuestro pequeño entorno. ¿Cómo te comes un hipopótamo? Un bocado cada vez. ¡Agilismo de guerrilla! (También con tus compañeros)
Un saludo navideño,
JMB
Jonathan Vila Lopez
Dec 23, 2009, 8:11:22 AM12/23/09
to agile...@googlegroups.com
Gracias Jose Manuel..........me apunto esos libros......buffff se me acumula la lectura !!!! :)
Por otro lado yo confio mucho en dar confianza al equipo y usar tantas herramientas de construccion de equipo como sea posible......... mi punto es que no puedo esperar que se motiven sino que la motivacion del equipo debe ser una parte importante en mi agenda....debo luchar por ello.
Fijate que en la startup de que me hablas tu jefe ya era bastante abierto........ en donde yo he estado como alguien llegue 15 minutos tarde la que se lia......... y creo que muchas empresas son asi.... El tema es que la aplicacion del agilismo se ve frenada fuertemente porque quien cree en ello es el departamento de desarrollo y no los otros departamentos.......y eso hace muy dificil su aplicacion.
Por otro lado hay que pensar bien en lo de "automotivadas"........... que hace que tu te motives por algo ? pues el equipo es igual, sueldo acorde, horario, beneficios sociales, palmaditas en la espalda, comidas , et, etc.........y si nuestra empresa no lo hace....nosotros como gestores de un equipo Scrum no podremos aplicarlo y la gente se desmotivara, pero no por su culpa...........no se si me explico........
-----------------------------------------------
Slitzweitz !!!!!!
Por otro lado yo confio mucho en dar confianza al equipo y usar tantas herramientas de construccion de equipo como sea posible......... mi punto es que no puedo esperar que se motiven sino que la motivacion del equipo debe ser una parte importante en mi agenda....debo luchar por ello.
Fijate que en la startup de que me hablas tu jefe ya era bastante abierto........ en donde yo he estado como alguien llegue 15 minutos tarde la que se lia......... y creo que muchas empresas son asi.... El tema es que la aplicacion del agilismo se ve frenada fuertemente porque quien cree en ello es el departamento de desarrollo y no los otros departamentos.......y eso hace muy dificil su aplicacion.
Por otro lado hay que pensar bien en lo de "automotivadas"........... que hace que tu te motives por algo ? pues el equipo es igual, sueldo acorde, horario, beneficios sociales, palmaditas en la espalda, comidas , et, etc.........y si nuestra empresa no lo hace....nosotros como gestores de un equipo Scrum no podremos aplicarlo y la gente se desmotivara, pero no por su culpa...........no se si me explico........
-----------------------------------------------
Slitzweitz !!!!!!
2009/12/23 José Manuel Beas <jose....@gmail.com>
2009/12/23 Jonathan Vila Lopez <jonath...@gmail.com>
--
José Manuel Beas
Dec 23, 2009, 8:46:03 AM12/23/09
to agile-spain
Pero si todos estáis en el mismo carro de insatisfacción, os ofezco dos opciones:
1) pastilla azul: dedicáos a patalear en los pasillos y a quejaos de lo mal que os trata la empresa. Eso sí, todos juntos, para hacer piña. Que las penas, si son compartidas, son menos penas.
2) pastilla roja: asumid que no podéis enfrentaros a la organización pero que sí podéis mejorar vuestra vida diaria. Un poquito cada vez.
* Un poco de integración continua por aquí. (Nadie tiene que saber que tenéis un hudson instalado en el PC de alguno de vosotros)
* Un poco de automatizar las entregas por allá. (Quién va a saber que empaquetar todo con Maven os ha costado ejecutar "mvn package")
* Un poco de ir mejorando vuestro estilo con el PMD o el checkstyle. (Nadie tiene que ver esos informes en el site construido con Maven)
* Un poco de reuniones diarias. (Las podéis hacer mientras tomáis café para que nadie sospeche)
* Un poco de revisiones colectivas de código. ("No, estamos todos reunidos revisando el código porque hay algo que no está bien y tenemos que revisarlo antes de ponerlo en producción y entonces sea más duro." De paso así pensarán: "Mmmm, que profesionales estos chicos, y qué comprometidos" Ja, y lo mejor es que tendrán razón.)
* Un poco de programar por parejas. ("Buff, estamos juntos para ver si somos capaces de sacar esta junta del émbolo que no trisca la chusca." Un poco de jerga a veces no viene mal para espantar a los curiosos).
En fin, ya ves, hay trucos para mejorar (un poco) tu vida diaria. Y así, poco a poco. Claro que, si tienes mucha prisa, siempre puedes tomarte la pastilla azul y lo verás todo más tranquilo y reposado. :-)
Un saludo,
Jose Manuel Beas
http://agilismo.eshttp://twitter.com/jmbeas
1) pastilla azul: dedicáos a patalear en los pasillos y a quejaos de lo mal que os trata la empresa. Eso sí, todos juntos, para hacer piña. Que las penas, si son compartidas, son menos penas.
2) pastilla roja: asumid que no podéis enfrentaros a la organización pero que sí podéis mejorar vuestra vida diaria. Un poquito cada vez.
* Un poco de integración continua por aquí. (Nadie tiene que saber que tenéis un hudson instalado en el PC de alguno de vosotros)
* Un poco de automatizar las entregas por allá. (Quién va a saber que empaquetar todo con Maven os ha costado ejecutar "mvn package")
* Un poco de ir mejorando vuestro estilo con el PMD o el checkstyle. (Nadie tiene que ver esos informes en el site construido con Maven)
* Un poco de reuniones diarias. (Las podéis hacer mientras tomáis café para que nadie sospeche)
* Un poco de revisiones colectivas de código. ("No, estamos todos reunidos revisando el código porque hay algo que no está bien y tenemos que revisarlo antes de ponerlo en producción y entonces sea más duro." De paso así pensarán: "Mmmm, que profesionales estos chicos, y qué comprometidos" Ja, y lo mejor es que tendrán razón.)
* Un poco de programar por parejas. ("Buff, estamos juntos para ver si somos capaces de sacar esta junta del émbolo que no trisca la chusca." Un poco de jerga a veces no viene mal para espantar a los curiosos).
En fin, ya ves, hay trucos para mejorar (un poco) tu vida diaria. Y así, poco a poco. Claro que, si tienes mucha prisa, siempre puedes tomarte la pastilla azul y lo verás todo más tranquilo y reposado. :-)
Un saludo,
Jose Manuel Beas
Jonathan Vila Lopez
Dec 23, 2009, 8:55:59 AM12/23/09
to agile...@googlegroups.com
Muy bien explicado :)
Estoy totalmente de acuerdo........en ese aspecto imagino que quien mas quien menos todos nos mejoramos el entorno para estar mejor.....sea scrum u otra cosa ( vosotros le poneis nombre generalmente siglas a las cosas y yo uso los conceptos y aplico los que me parecen mejor sean de donde sean) , pero al hilo en el que estaba cuando dije que me habia tocado la fibra........... todo esto esta muy bien, pero........ como luchar contra la desmotivacion que genera la compañia cuando hablabais de la "automotivacion" ? yo creo que el sistema emergente de un equipo autogestionado es muy bonito........pero creo que muchas veces la realidad no permite eso.......y hay que luchar para mantener motivado al equipo...........no crees ?
Supongo que es una charla sin fin..............
-----------------------------------------------
Slitzweitz !!!!!!
Estoy totalmente de acuerdo........en ese aspecto imagino que quien mas quien menos todos nos mejoramos el entorno para estar mejor.....sea scrum u otra cosa ( vosotros le poneis nombre generalmente siglas a las cosas y yo uso los conceptos y aplico los que me parecen mejor sean de donde sean) , pero al hilo en el que estaba cuando dije que me habia tocado la fibra........... todo esto esta muy bien, pero........ como luchar contra la desmotivacion que genera la compañia cuando hablabais de la "automotivacion" ? yo creo que el sistema emergente de un equipo autogestionado es muy bonito........pero creo que muchas veces la realidad no permite eso.......y hay que luchar para mantener motivado al equipo...........no crees ?
Supongo que es una charla sin fin..............
-----------------------------------------------
Slitzweitz !!!!!!
2009/12/23 José Manuel Beas <jose....@gmail.com>
Pero si todos estáis en el mismo carro de insatisfacción, os ofezco dos opciones:
Reply all
Reply to author
Forward
0 new messages