Estimacion: Suponer es bueno, hay que suponer todo lo posible (Parte 3)

Antes de continuar con mas ejemplos concretos de supuestos, considero importante relatarles que cuando iniciaba con desarrollo de software me tope muchas veces con esta situación:


Lider del proyecto: El cliente dijo que la caracteristica XXX no le parece util. Que no entiende por que la hicimos asi si el necesitaba otra cosa
Programador: Es que yo supuse que...
Lider del proyecto: Pues, para la proxima vez no supongas: pregunta!
Programador: Lo siento, no vuelve a pasar

Y unos dias despues:


Programador: ¿Como debemos hacer la caracteristica YYY?
Cliente: Pues, de modo tal que maximisemos la eficiencia y demos valor al negocio...
Programador: Si, pero, la multiplicidad entre productos y pedidos es uno a muchos? o muchos a muchos?
Cliente: (de que habla este compadre?) Lo siento, tengo otra junta, luego lo vemos
Programador: Pero pero...

Y finalmente:


Lider del proyecto: El cliente dijo que la caracteristica YYY no le parece util. Que no entiende por que la volvimos a quedarle mal, el necesitaba otra cosa
Programador: Si le pregunte, de veras, pero solo me explico muy superficial
Lider del proyecto: Pues, para la proxima vez, obten informacion detallada
Programador: Lo siento, no vuelve a pasar

Y asi, siempre atrapados en lo mismo, sin control, a veces quedando bien, a veces quedando mal, dependiendo de que tanto coincidía la intuicion del programador con la reaccion del cliente al probar el software construido

Lo triste, es que lo que aprende el programador despues de varios ciclos asi, es que suponer es malo.
Conclusion equivocada. Suponer es lo mejor que podemos hacer al iniciar un proyecto de software.
Supongamos todo lo que podamos suponer. Pero seamos explicitos con nuestros supuestos.

Cambiemos el dialogo, negociemos de un modo diferente las cosas, para que se vea asi:


Programador: ¿Como debemos hacer la caracteristica ZZZ?
Cliente: Pues, de modo tal que maximisemos la eficiencia y demos valor al negocio...
Programador: Aqui tengo (muchos supuestos detallados y explicitos) un prototipo de la pantalla, aqui esta mi historia de usuario y ya escribi unos criterios de aceptacion, por favor dales tu VoBo para poderme arrancar a programar
Cliente: Ok, los reviso al rato y te aviso
Programador: Perfecto!

Por supuesto, uno de los problemas mas comunes con los que podemos encontrarnos, es que el cliente finalmente no tenga tiempo para revisar y no nos de nunca VoBo o nos lo de, pero sin haber revisado realmente los supuestos


Lider del proyecto: El cliente dijo que la caracteristica ZZZ no le parece util. Que no entiende por
que la hicimos asi si el necesitaba otra cosa
Programador: Bueno, yo le entregue un prototipo, la historia de usuario y los criterios de aceptacion, y me dio VoBo, si quieres los repasamos para ver que correspondan, pero el Tester ya tiene la evidencia de que hay correspondencia y todos los bugs que habia ya los corregimos
Lider del proyecto: ... Pues, habra que indicarle al cliente que si lo quiere diferente, necesita solicitar un cambio.

Este es el punto al que queremos llegar. Si, lo mejor que podemos hacer, el ideal al que aspira el moviemiento agil, es a construir lo que el cliente realmente necesita, pero a menudo no se llega ahi en el primer intento, por que el primero que no sabe claramente lo que necesita: es el cliente. Y la tecnica para llegar ahi son los supuestos. Pero supuestos explicitos, visibles, claros, si son de pantallas, con prototipos, si son procesos batch, con ejemplos de datos de entrada y datos de salida congruentes.

Lo malo no son los supuestos, lo malo es cuando suponemos en "secreto", sin evidencia, sin dar visibilidad.

En la siguiente parte de esta serie, continuaremos explorando mas supuestos definidos vagamente y como podemos convertirlos en supuestos acotados refutables, , que al ser violados (de parte del cliente) resultan en mas trabajo y tiempo pagado (recuerden, el objetivo no es terminar el proyecto, el software es como una planta, como un ser vivo, el objetivo es cultivarlo, dejarlo crecer, madurar, agregando valor al cliente si es posible, de forma indefinida ).

Debemos buscar hacer lo correcto, sin olvidar hacerlo correctamente

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de AlexSnake

Proactividad?

Eso que mencionas de las supociones buenas me suena como a ser proactivo, no esperar una respuesta para dar un resultado cuando puedes entregar posibles respuestas a la problemática que se plantea, pues sí, no solo debería ser en ese sentido sino en la mayoría de las cosas que realizamos para ser una persona exitosa. Seguiré esperando la parte de la negociación. Saludos.

Imagen de luxspes

Proactividad: tambien afecta la negociacion

Eso que mencionas de las supociones buenas me suena como a ser proactivo, no esperar una respuesta para dar un resultado cuando puedes entregar posibles respuestas a la problemática que se plantea, pues sí, no solo debería ser en ese sentido sino en la mayoría de las cosas que realizamos para ser una persona exitosa.

De acuerdo

Seguiré esperando la parte de la negociación. Saludos.

Hablare mas al respecto mas adelante, pero, en cierto modo, los dialogos aqui ya demuestran como un cambio en la forma de negociar con el cliente (he visto a mas de un programador/analista perder la chamba por entercarse en paralizar el proyecto hasta que el cliente le proporcione TODA la información):

Negocia suponiendo que la información que te dan es incompleta e imprecisa, la información que te falte, suponla, y presentala, hazla visible para todos los participantes, y si es posible, obtén VoBo de los que toman las decisiones

Se proactivo, pero se proactivo de forma visible y transparente (Lo peor que puedes hacer es decidir chutarte todo el proyecto y luego de unos meses validar si esta bien, lo correcto es ser proactivo, y buscar retroalimentacion con mucha frecuencia: supón, valida, construye, valida, repite)

Imagen de tsunllly

No esperar que los demás te solucionen la vida

Es muy probable que cuando le preguntes una duda a tu líder de proyecto el mismo no sepa la respuesta de forma inmediata. Yo he notado que si llegas con esa misma duda pero con opciones de respuesta (posibles soluciones, ejemplos, etc.) la comunicación fluye mejor y se alcanza un mayor entendimiento, además que de vez en cuando te puedes salir con la tuya.