jueves, diciembre 25, 2014
Leído y Recomendado: Feedforward
Excelente artículo para aplicar tanto en el escenario profesional como personal
http://www.marshallgoldsmithlibrary.com/docs/Spanish/Intente-el-FeedForward.pdf
Éxitos
martes, diciembre 23, 2014
¿y las horas de dónde las saco? – Casos de la vida real.
Hola a todos,
Miremos el siguiente escenario
-----
INTRODUCCIÓN
Cliente: ¿tengo unos requisitos* que necesito me cotices?
Proveedor: Claro Mauricio, ¿pásamelo yo lo analizo?
Cliente: Claro que sí. Estímalo tranquilo y dime cuantas horas son.
Poco tiempo después en la oficina del proveedor…
- Carlos. Necesito me estimes estos requisitos
- Vale, déjame los miro y analizo con calma.
Al día siguiente…
-Jefe, le tengo la estimación, son 3 semanas más o menos 140 horas.
- Ok, Carlos muchas gracias. ¿Pero ves algún riesgo, algo que pueda alargar la ejecución?
- No Juan, todo está ok. Con ese dato podemos irnos tranquilos, hasta le puse unas holguras por si algo no sale como lo planeado.
- Excelente unas horas a nuestro favor - que tanta falta nos hacen - .
Luego con el cliente telefónicamente
Proveedor: Hola Mauricio, Ya te tengo la estimación son 140 horas** , y podemos comenzar a trabajar en los requisitos el próximo lunes, la entrega será en 20 días hábiles.
Cliente: Perfecto Juan, quedemos así, hago entonces la reserva en el presupuesto e informaré a los de infraestructura para que preparen el ambiente para el despliegue de esas funcionalidades.
NUDO
Semana 1
Gerente de Proyecto (GP): ¿qué tal el avance, Carlos***?
Carlos: vamos bien, sin ningún lío,
GP: vale, hablemos en una semana
Semana 2
GP: ¿qué tal el avance, Carlos?
Carlos: tengo un problemita con una librería pero entre hoy y mañana lo soluciono
GP: vale, hablemos en una semana. Si necesitas algo o a alguien no dudes en decirme.
Semana 3
GP: ¿qué tal el avance, Carlos, recuerda que esta semana entregamos?
Carlos: el problema tomo más tiempo y el desarrollo creo que estará en 2 semanas más a las estimadas
GP: seguro no puedes terminarlo antes
Carlos: No
GP: ¿y fue error nuestro (1) la mala estimación?
Carlos: la verdad si, aunque el alcance está claro hubo cosas que no vi y me están tomando más tiempo estimado
GP : ¿Seguro no podemos hacerlo en menos tiempo? Vamos a quedar mal con el compromiso
Carlos: pues comenzaré a quedarme al final del día dos horas diarias para ver si lo termino una semana antes (2)
GP: Gracias Carlos, personas como vos son las que necesitamos
Un momento más tarde:-
Proveedor: Mauricio, la entrega la vamos a realizar para la semana 5, no la 4 como te la había informado
Cliente: ¡Que mal Juan!, ¡que problema!, bueno será mover a IT, y cuadrar reasignar a la gente ¿y qué fue lo que paso?¿qué saló mal?
Luego con el cliente telefónicamente
Proveedor: Hola Mauricio, Ya te tengo la estimación son 140 horas** , y podemos comenzar a trabajar en los requisitos el próximo lunes, la entrega será en 20 días hábiles.
Cliente: Perfecto Juan, quedemos así, hago entonces la reserva en el presupuesto e informaré a los de infraestructura para que preparen el ambiente para el despliegue de esas funcionalidades.
NUDO
Semana 1
Gerente de Proyecto (GP): ¿qué tal el avance, Carlos***?
Carlos: vamos bien, sin ningún lío,
GP: vale, hablemos en una semana
Semana 2
GP: ¿qué tal el avance, Carlos?
Carlos: tengo un problemita con una librería pero entre hoy y mañana lo soluciono
GP: vale, hablemos en una semana. Si necesitas algo o a alguien no dudes en decirme.
Semana 3
GP: ¿qué tal el avance, Carlos, recuerda que esta semana entregamos?
Carlos: el problema tomo más tiempo y el desarrollo creo que estará en 2 semanas más a las estimadas
GP: seguro no puedes terminarlo antes
Carlos: No
GP: ¿y fue error nuestro (1) la mala estimación?
Carlos: la verdad si, aunque el alcance está claro hubo cosas que no vi y me están tomando más tiempo estimado
GP : ¿Seguro no podemos hacerlo en menos tiempo? Vamos a quedar mal con el compromiso
Carlos: pues comenzaré a quedarme al final del día dos horas diarias para ver si lo termino una semana antes (2)
GP: Gracias Carlos, personas como vos son las que necesitamos
Un momento más tarde:-
Proveedor: Mauricio, la entrega la vamos a realizar para la semana 5, no la 4 como te la había informado
Cliente: ¡Que mal Juan!, ¡que problema!, bueno será mover a IT, y cuadrar reasignar a la gente ¿y qué fue lo que paso?¿qué saló mal?
Proveedor: Una funcionalidad nos tomó más de lo esperado, nos tocó modificar los componentes x, y, z , que no se identificaron en la estimación , pero también quisiera aprovechar esta conversación para solicitarte el pago de esas horas adicionales
Cliente: Con respecto a la funcionalidad, comprendido, pero respecto al reconocimiento, no Juan, vos sabes que no puedo hacerlo contractualmente.
DESENLACE
- El desarrollador se demoró en total 6 semanas
- La empresa puso de su bolsillo 140 horas adicionales
- El desarrollador puso de su tiempo personal 30 horas (que no sabe si se las reconocerán)
- El cliente está molesto por la entrega tardía (6 semana)
- El proveedor perdió dinero y credibilidad.
- Se decide enviar a Carlos a un curso de Estimación
----
REFLEXIONES, DIATRIBAS Y NÚMEROS:
- El valor total del requisito en horas era 140 (estimado inicial) + 140 (ejecutado adicional) + 30 (horas aportadas por el desarrollador en su error) = 310 horas (un 121% más)
- El argumento que generalmente expone el cliente es:
- Ustedes son los expertos, yo confío y no cuestiono sus estimaciones – salvo que las vea muy desfasadas – por lo tanto, asuman ese error.
- Preguntó:
- ¿Las horas adicionales fueron “robadas”?
- ¿acaso no se dedicaron al objetivo planteado en el requisito?
- ¿el desarrollador la estimó mal, de pura mala intención?
- ¿habría alguien en el equipo en hacer su trabajo mal hecho?
- Si existe una relación de confianza cliente-proveedor ¿Por qué no se reconocen las horas justamente invertidas en los requisitos del cliente?
- ¿Por qué si algo toma menos tiempo es a favor del cliente pero si toma más es en detrimento del proveedor?
- ¿No es acaso esta la causa de que inflemos cronogramas, presupuestos y valor/hora que vendemos en el mercado? En donde tratamos de cubrir la INCERTIDUMBRE asociada al software con sobrecostos.
- ¿Por qué los clientes no pagan las horas, si son JUSTO lo que se invirtió en realizar el requerimiento con su complejidad asociada?
- ¿Por qué nos obstinamos en creer que hacer software es juntar piezas de lego (donde todas son uniformes, bonitas, lisas, y encajan perfectamente)?¿y creemos que cualquier desfase es falta de profesionalismo de cualquiera de los involucrados?
- Pienso que existen muchas formas de hacer y crear esquemas justos, tanto para cliente y proveedor:
- Reconocer el esfuerzo adicional
- La verdad esto no es deshonesto para ninguna de las partes, hora por hora fueron invertidas en el requisito o necesidad
- Pasar al cliente una pre-cotización y cerrarla con lo realmente ejecutado.
- Hay opciones más radicales
- Trabajar por tiempo y materiales con el cliente (en este caso el cliente asume todo el riesgo - ver este post sobre contratos ágiles )
- (la que más me suena) Pagar por sprint (alcance logrado en un ciclo, sea que se haga o no todo lo comprometido)
- (y la más radical de todas) cambiar de cliente.
- Tal vez si todos los proveedores funcionaran de esa forma, el juego de "si estimas mal tu pierdes y yo gano" se acabe
CIERRE
Quedan muchas preguntas por hacer y contestar, mucha cultura en el ambiente de desarrollo de software por cambiar.Espero estar poniendo con esto un pequeño grano de arena hacia ese cambio, hacia:
- un escenario justo,
- transparente y
- de riesgo compartido entre clientes y proveedores.:
Saludos ágiles y feliz navidad
Jorge Abad
----
*Semánticamente es más correcto usar requisito que requerimiento.
** En muchos casos se adicionan horas de riesgos e imprevistos, reservas de gestión, pero para efectos de ejemplo no lo haré, pero observaremos que el resultado será en términos generales el mismo.
*** La persona que estimó fue la misma que está desarrollando
(1) Por lo general le echamos la culpa a la estimación, lo grave es que una estimación no es un compromiso, es un número que tiene asociado una probabilidad de ocurrencia, tal vez sí, tal vez no, cumplamos, pero ojalá si.
(2) En este punto tanto Proveedor (Juan) como Desarrollador (Carlos) están poniendo tiempo de sus bolsillos
----
*Semánticamente es más correcto usar requisito que requerimiento.
** En muchos casos se adicionan horas de riesgos e imprevistos, reservas de gestión, pero para efectos de ejemplo no lo haré, pero observaremos que el resultado será en términos generales el mismo.
*** La persona que estimó fue la misma que está desarrollando
(1) Por lo general le echamos la culpa a la estimación, lo grave es que una estimación no es un compromiso, es un número que tiene asociado una probabilidad de ocurrencia, tal vez sí, tal vez no, cumplamos, pero ojalá si.
(2) En este punto tanto Proveedor (Juan) como Desarrollador (Carlos) están poniendo tiempo de sus bolsillos
domingo, diciembre 21, 2014
Haz pequeños experimentos en tu equipo Scrum
Una de las ventajas que ha traído Scrum al mundo del software (donde la complejidad reina) es la posibilidad de habilitar el aprendizaje y mejora continua de una forma emergente y natural.
En los equipos que siguen juiciosos el framework de Scrum (hay que hacer la claridad, pues hay quienes no, dejando por fuera elementos poderosos con la respectiva pérdida de sus beneficios) encuentran retrospectiva tras retrospectiva elementos que van incorporando en su mejora como :
En los equipos que siguen juiciosos el framework de Scrum (hay que hacer la claridad, pues hay quienes no, dejando por fuera elementos poderosos con la respectiva pérdida de sus beneficios) encuentran retrospectiva tras retrospectiva elementos que van incorporando en su mejora como :
- equipo
- en sus procesos
- y/o herramientas
Si de facto los equipos comenzaran en el Sprint 1 con lo que van a terminar empleando en el Sprint 15:
- ayudas,
- prácticas técnicas,
- formas de comunicarse entre sí y con el cliente,
- revisiones,
- registros,
- métricas
- etc
Quisiera invitarlos a realizar experimentos Sprint tras Sprint, ha realizarle seguimiento e identificar si fueron beneficiosos o no.
Con seguridad ese aprendizaje y mejora continua los llevarán como equipos a fronteras que no se habían imaginado al principio de su inmersión en la construcción del producto.
Saludos ágiles y navideños
Jorge Abad
miércoles, diciembre 10, 2014
Frase de gestión de proyectos: Una cosa no garantiza la otra.
“La buena gestión no puede garantizar el éxito del proyecto. Sin embargo, la mala gestión usualmente lleva al fracaso del proyecto” (Sommerville, 2005).
_
martes, diciembre 09, 2014
miércoles, diciembre 03, 2014
Leido y recomendado :ScrumMasters Should Not Also Be Product Owners
Hoy comienzo una etiqueta en mi blog
Leído y recomendado
Pondré el link al original y rezaré para que no sea removido el artículo.
------------------
ScrumMasters Should Not Also Be Product Owners -
http://www.mountaingoatsoftware.com/blog/scrummasters-should-not-also-be-product-owners
------------------
Saludos ágiles y
hasta el próximo post
Jorge Abad
Leído y recomendado
Pondré el link al original y rezaré para que no sea removido el artículo.
------------------
ScrumMasters Should Not Also Be Product Owners -
http://www.mountaingoatsoftware.com/blog/scrummasters-should-not-also-be-product-owners
------------------
Saludos ágiles y
hasta el próximo post
Jorge Abad
Suscribirse a:
Entradas (Atom)