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?

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

1 comentario:

  1. Buen post. Esto lo he visto y vivido muchas veces y en varias empresas. Heroísmo inútil, insatisfacción y desmotivación proyecto tras proyecto mientras no se hagan buenas retrospectivas y análisis de lecciones aprendidas. No hay otra forma de mejorar.

    ResponderEliminar