Estimación: ¿Es asumir la madre de todos lo males? ¿o quizá es suponer? ¿o mas bien, es nuestra propia ignorancia? (Parte 2)

Hace poco lei, un tweet que decia:

Felicidades a "Asumir" por ser la MADRE DE TODOS LOS ERRORES DE ESTIMACIÓN en los desarrollos de software!!!!

— SoftwareEvangelist (@vanessa_amaya) May 10, 2013

¿se dara cuenta la autora... que esta asumiendo que asumir es el problema?

Revisemos primero el significado de la palabra

asumir:
asumir. (Del lat. assumere).
1. tr. Atraer a sí, tomar para sí.
2. tr. Hacerse cargo, responsabilizarse de algo, aceptarlo.
3. tr. Adquirir, tomar una forma mayor.

En general, en software, el significado que en mi experiencia solemos utilizar es el de "Hacerse cargo, responsabilizarse de algo, aceptarlo." ¿De que nos hacemos responsables? De que los supuestos que utilizamos para construir nuestra estimación. ¿ debiéramos buscar mas bien ser irresponsables? En mi opinion el problema son mas bien los supuestos. Si lo supuestos acaban no coincidiendo con la realidad, terminaremos entregando mal las cosas, por ejemplo en el ejemplo que manejaba Ezamudio en el post anterior de esta serie, el problema se disparó por que el tecnico suponia que habia elegido la pieza correcta, en desarrollo de software es mas complicado, ya son varios supuestos entrelazados. Pero volviendo al principio ¿es asumir realmente la madre de todos los problemas? No. ¿Suponer es entonces la madre de todos los problemas? Tampoco estoy de acuerdo con eso, revisemos el significado de suponer:

suponer. (Del lat. supponere).
1. tr. Dar por sentado y existente algo.
2. tr. Fingir, dar existencia ideal a lo que realmente no la tiene.
3. tr. Traer consigo, importar. La nueva adquisición que ha hecho supone desmedidos gastos de conservación.
4. tr. Conjeturar, calcular algo a través de los indicios que se poseen.
5. intr. Tener representación o autoridad en una república o en una comunidad.

El significado que solemos usar en software, (al menos los que colaboramos en su construccion) es el de Conjeturar, calcular algo a través de los indicios que se poseen, mientras que cosideramos que el cliente lo ve mas como "Dar por sentado y existente algo". ¿Contradictorio? Superficialmente podriamos pensar que si, pero si lo examinamos mas profundamente, no existe contradiccion. Suponer es un algo necesario, nos levantamos de la cama, y suponemos que estamos despiertos, tomamos agua del jarrafon y suponemos que no es toxica, salimos a la calle y manejamos al trabajo y suponemos que sera relativamente seguro. No tenemos la absoluta certeza, pero tampoco nos torturamos, actuamos dandolo por hecho, y si al final el agua o comida nos causa indigestion, lidiamos con ello, si empezamos a tener indigestion varios dias seguido (si no alcanza a matarnos) cambiaremos nuestra dieta, y el agua que tomamos. Lo mismo aplica a los supuestos de software.

Suponer es una actividad necesaria en el metodo científico (paso 3):
1) Observación: Observar es aplicar atentamente los sentidos a un objeto o a un fenómeno, para estudiarlos tal como se presentan en realidad, puede ser ocasional o causalmente.
2) Inducción: La acción y efecto de extraer, a partir de determinadas observaciones o experiencias particulares, el principio particular de cada una de ellas.
3) Hipótesis: Planteamiento mediante la observación siguiendo las normas establecidas por el método científico. <---- SUPUESTO!
4) Probar la hipótesis por experimentación.
5) Demostración o refutación (antítesis) de la hipótesis.
6) Tesis o teoría científica (conclusiones).

Básicamente, Observamos, Analizamos, Suponemos, y Probamos. Si funciona, conservamos el supuesto, si no funciona, repetimos hasta encontrar el supuesto "correcto". Ahora, esto es lo mas importante del método científico: Nunca se llega a lo correcto, el camino es hacia la verdad es como el limite en el calculo infinitesimal, cada vez estamos mas cerca, pero nunca llegamos.

La leccion mas importante del metodo cientifico esta implicita: Es un Mandala de Arena. Se hacen supuestos, solo para ser reemplazados por mejores supuestos. Asi pues, en el software, asumir que nuestros supuestos son verdad, no es un error, es parte del método, el error viene cuando nos olvidamos de que estamos apenas en el paso 3, todavía viene el 4, en donde, sin dejar de lado nuestras responsabilidad, probamos si nuestros supuestos coinciden con la realidad. Por lo tanto, asumir y suponer no son la madre de todos los problemas, la madre, es mas bien, la falta de experimentación, y esa falta de experimentación, deriva de que se escribe a los supuestos de forma incorrecta.

La primer regla que hay que seguir para los supuestos, es de nuevo una regla que viene del metodo cientifico, el supuesto debe ser refutable (principio de falsabilidad) que es lo que esto significa? debe haber un modo concreto, mediante una observación particular, de poder declarar al supuesto (provisionalmente) verdadero o falso. (Un supuesto no refutable, seria uno que requiriera una busqueda exahustiva de todas las posibilidades para refutarlo) Por ejemplo, me han entregado RFP para hacer sistemas que dice "el sistema deberá implementar todas la reglas de negocio relevantes para el proceso de negocio a automatizar" y luego, nada, ninguna lista de cuales reglas son. Demostrar si estamos cumpliendo o no con ese supuesto, no se puede refutar, la lista de reglas es potencialmente infinita (y vaya que los clientes toman ventaja de eso). ¿Que podemos hacer?

Cuando era mas joven, lo que solía hacer era exigir la lista de reglas, o decir que no podría hacer nada y negarme a estimar el tiempo que seria necesario. Sobra decir que esa actitud solo me consiguió problemas con mis jefes, negocios perdidos y clientes insatisfechos. Aunque ese es el camino indicado en los libros de estimación, no es el camino correcto en el mundo real

Por supuesto, hay clientes que si estan dispuestos a darte la lista de reglas, asi cuando estes en esta situación, no dejes de pedir la lista, pero si no te la pueden (o quieren) dar, no sufras, acéptalo, y continua... pero con cuidado, hace unos meses me toco ver a una consultora naciente fallecer una muerte horrible y entrar en modo zombie: vendieron un sistema con los supuestos asi, abiertos, segun ellos, lo iban a terminar en 2 semanas, cuando los conoci ya tenian 1 año gratis trabajando para el gobierno, bajo amenza de demanda por incumplimiento de contrato si se llegaban a "rajar" y no terminar de implementar todas las reglas que se le llegaran a ocurrir al cliente. Yo ya no podia ayudarles, lo que necesitaban era un buen abogado. ¿Como evitar caer en ese hoyo entonces?

Algunos diran: Simplemente rechaza el negocio. Si, suena bonito cuando tienes mucha lana, no tienes responsabilidades y si no recibes ingresos el único que no come eres tu. ¿Pero y si tu familia depende de ti? ¿Realmente te puedes dar el lujo de rechazar el trabajo? Claro que no. No lo rechaces entonces, ni te canses explicando por que no puedes "implementar todas la reglas de negocio relevantes para el proceso de negocio a automatizar", la respuesta correcta, es: acotar tu mismo el alcance.

Coloca un supuesto en tu propuesta de la siguiente forma: "Se asume que dichas reglas de negocio no seran mas 10. Se asume que se recibirá la lista de todas las reglas de negocio a implementar X dias despues de haber iniciado el proyecto. Las reglas deberán estar definidas como series de pasos a seguir de forma algorítmica, constando cada una de ellas de no mas de 10 CFP (Cosmic Function Points de conformidad con el estandar standard ISO/IEC 14143/1:2003). Se asume que toda la información a ser utilizada por las reglas de negocios es aquella que se alimenta al sistema mediante las user stories definidas en la sección de alcance de la presente propuesta. En caso de no recibir la lista de reglas de negocio en ese momento, o recibir un numero mayor de reglas se ejecutara el procedimiento cambio al alcance descrito en el presente documento, el cual podría tener un impacto en los tiempos y costos del proyecto." Ya quedo acotado.

Al hacer esto, básicamente lo que estas haciendo es contestar la pregunta que seguramente te harían algunos clientes cuando les dijeras que no puedes "implementar todas la reglas de negocio relevantes para el proceso de negocio a automatizar".
Algunos clientes preguntarían: ¿Por que no?.
Y tu les dirias: Por que no se cuantas son, ni que tan complejas son, y tu solo me estas dando 3 meses para hacerlas.
Bueno, diria el cliente: ¿Cuantas puedes hacer en 3 meses?.

Y ahi es, donde, cuando joven, mas fuertemente me estrellaba con la realidad, simplemente: no podía contestar a esa pregunta! Solo podía decir "por que no", cuando la respuesta correcta es decir "como si". Esto no es una bala de plata, habra clientes que no esten dispuestos a aceptarte un alcance acotado. En esos casos, si el cliente no esta dispuesto a pagar por tiempo y materiales, entonces si, la respuesta correcta es gracias, pero no gracias, no puedo hacer el proyecto.

En la siguiente parte de esta serie, ahondaremos en los beneficios de suponer, y por que se generado el mito de que no se debe suponer.

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 ezamudio

pochismo

Fue una mala traducción. Hay unos refranes en inglés:

When you ASSUME, you make an ASS out of U and ME.

Assumptions are the mother of all fuckups.

When you make an ASSUMPTION, you make an ASS out of U and UMPTION.

Pero en inglés, assume es hacer una suposición. También tiene el significado que tiene en español, pero más comúnmente se usa para decir "suponer" que para, por ejemplo, "asumir un cargo/responsabilidad".

Fuera de eso, mucho de lo que dices pues se puede resumir como poner prioridades, no? Decirle al cliente "No hay manera que pueda entregarte todo esto en 3 meses, dime qué cosas son las más importantes para enfocarnos a esas y terminarlas primero". Sé que obviamente hay cosas que tal vez no estarían como prioridad para el cliente y que sin embargo son fundamentales para poder realizar lo que el cliente pide, pero esas ya son limitaciones técnicas que obviamente hay que considerar también. Esto va muy de la mano con lo de involucrar al cliente en el proyecto y con lo del desarrollo iterativo, etc.

Imagen de luxspes

La prioridad no limita, la prioridad ordena.

Fue una mala traducción. Hay unos refranes en inglés:
When you ASSUME, you make an ASS out of U and ME.
Assumptions are the mother of all fuckups.
When you make an ASSUMPTION, you make an ASS out of U and UMPTION.

jajaja

Pero en inglés, assume es hacer una suposición. También tiene el significado que tiene en español, pero más comúnmente se usa para decir "suponer" que para, por ejemplo, "asumir un cargo/responsabilidad".

Interesante, aunque de cualquier modo, cubro tambien el significado de suposicion en el post. Y el problema no esta en suponer, por el contrario debemos suponer. Sin suposiciones (hipótesis) el método científico, la mejor herramienta que tenemos para entender el mundo, no funcionaria.

Lo importante es suponer, y dejar claro que pasa si la suposición se rompe. ¿Pero evitar suponer? sencillamente no se puede.

Fuera de eso, mucho de lo que dices pues se puede resumir como poner prioridades, no? Decirle al cliente "No hay manera que pueda entregarte todo esto en 3 meses, dime qué cosas son las más importantes para enfocarnos a esas y terminarlas primero".

Es cierto que hay que pedirle proridades al cliente (De prioridades hablare mas a fondo mas adelante) pero al cliente de este ejemplo no funcionó pedirle prioridades, esta pidiendo "el sistema deberá implementar todas la reglas de negocio relevantes para el proceso de negocio a automatizar", ¿la prioridad?, este cliente (cuyo nombre no menciono, era una multinacional, pero esto fue un caso real) me contestó: la prioridad es "implementar todas la reglas de negocio relevantes para el proceso de negocio a automatizar" .

La prioridad no limita, la prioridad ordena.

Suponer, cuando se hace con cuidado, si limita.

Sé que obviamente hay cosas que tal vez no estarían como prioridad para el cliente y que sin embargo son fundamentales para poder realizar lo que el cliente pide, pero esas ya son limitaciones técnicas que obviamente hay que considerar también.

Totalmente de acuerdo

Esto va muy de la mano con lo de involucrar al cliente en el proyecto y con lo del desarrollo iterativo, etc.

Quizá debí ser mas especifico, aqui estoy hablando de el inicio, al nivel de la propuesta, el punto donde todo inicia, el punto en que el cliente me dijo: "Quiero este sistema en 3 meses, y tienes las siguientes 4 horas para enviarme la propuesta... y por favor, no me molestes con tus tontas dudas".

No todos los clientes son asi... pero si te encuentras con uno estos, esta estrategia te permitirá entregar la propuesta sin miedo a terminar siendo su esclavo por el resto de tu vida

Imagen de ezamudio

uno de esos

Si me encuentro con uno de esos la verdad prefiero evitarlo. Si así se ponen desde que les estamos enviando la propuesta, no quiero imaginarme cómo se van a poner si nos la aceptan...

Imagen de ezamudio

otro tema

Y ese es otro tema. No es nomás ponerse uno sus moños para aceptar proyectos; pero es común que empresas que se dedican al desarrollo de software acepten proyectos que realmente ni les conviene desarrollar. Tal vez por desesperación, o porque el cliente es de renombre o por una variedad de razones; comúnmente porque los que vieron al cliente primero nunca hablaron con nadie técnico y no se dan cuenta que lo que el cliente pide es imposible en el tiempo que lo pide, etc.

Hay que saber decir que no. Cuando un cliente se pone en ese plan y lo mandas a volar, van a pasar dos cosas cuando se ponga a buscar otras opciones:

1. Va a encontrar alguien que le diga que sí, y a la mera hora por supuesto no le puede cumplir, o...
2. Nadie se anima y al final regresa contigo, o no, pero esto por lo general les hace darse cuenta de que lo que estaban pidiendo es imposible y se ponen más "amables" o al menos más dispuestos a escuchar propuestas razonables (esto ya me ha pasado).

Obvio existe la opción 3 donde encuentran a alguien que les dice que sí y lo entrega en tiempo, pero es lo menos probable, incluso si el presupuesto del cliente fuera infinito. Lo más común es la primera, que alguien en algún momento se anima y toma la propuesta (por las razones que mencioné al principio) y pues no puede cumplir a la mera hora y se meten en cualquier cantidad de broncas. A veces el cliente regresa contigo o con algún otro proveedor, buscando que les arregles lo que los otros hicieron mal y es aún peor, o de plano ya entendieron su lección y pues tienen que desechar el proyecto mal hecho y empezar de nuevo con otro proveedor.

Imagen de luxspes

Mejor paso... Herramientas o Armas, tenlas listas

Si me encuentro con uno de esos la verdad prefiero evitarlo.

Totalmente de acuerdo, siempre que puedo, los evito (pero a veces... no puedo)

Si así se ponen desde que les estamos enviando la propuesta, no quiero imaginarme cómo se van a poner si nos la aceptan...

Como 10 veces mas roñozos... ;-). Pero si todos tus supuestos están en su lugar, y lo usas correctamente, todo saldra bien:

Los supuestos no son el enemigo, los supuestos son el contexto de tu comunicación con el cliente, úsalos bien, son herramientas para dar un gran servicio, pero también son armas y escudos muy útiles si las cosas se ponen feas

Imagen de luxspes

Aprender: Nadie escarmienta en cabeza ajena

Lo más común es la primera, que alguien en algún momento se anima y toma la propuesta (por las razones que mencioné al principio) y pues no puede cumplir a la mera hora y se meten en cualquier cantidad de broncas.

Me encanta cuando esto pasa, es el mejor modo de que aprendan

A veces el cliente regresa contigo o con algún otro proveedor, buscando que les arregles lo que los otros hicieron mal y es aún peor, o de plano ya entendieron su lección y pues tienen que desechar el proyecto mal hecho y empezar de nuevo con otro proveedor.

Totalmente de acuerdo

Imagen de echan

suponer es un proceso natural

suponer es un proceso natural en la elaboracion de un proyecto .. a futuro solo puedes asumir y suponer porque las cosas no han pasado. Hacer un plan es asumir y suponer como se va desarrollar el proyecto, no hacerlo es cerrar los ojos y ver que pasa.

el problema es la candidad de cosas que supongas y asumas, si no tienes experiencia suficiente seguro serán más las cosas que supongas y el elemento de riesgo se dispara y terminas como los compañeros que trabajan gratis.

Pero mucho de eso creo que sólo lo obtienes con la experiencia, despues de haber desarrollado una metodologia efectiva de trabajo y la intuición en éste negocio del software, que dicho sea de paso y sin afan de hechar de menos el trabajo de nadie, muy pocos son los que desarrollan y a la vez tiene la formación o en su defecto el callo suficiente para sacar a flote un proyecto de software, lo que me lleva a pensar que si no tienes capacidad más allá de la técnica, es indispensable que encuentres a alguien que te eche la mano en ese aspecto o dicho de otra manera el bisnes es una cosa y lo que vendes es otra muy diferente o como decimos mas comunmente zapataro a tu zapato.

Imagen de luxspes

Entre mas supuestos: mejor

suponer es un proceso natural en la elaboracion de un proyecto ..

De acuerdo

a futuro solo puedes asumir y suponer porque las cosas no han pasado. Hacer un plan es asumir y suponer como se va desarrollar el proyecto

Tambien de acuerdo

, no hacerlo es cerrar los ojos y ver que pasa.

Mmmm, contradictorio, no me queda claro que quisiste decir aqui...

el problema es la candidad de cosas que supongas y asumas,

No...

si no tienes experiencia suficiente seguro serán más las cosas que supongas y el elemento de riesgo se dispara y terminas como los compañeros que trabajan gratis.

Al contrario, entre mas y mas especificos sean tus supuestos: mejor. Supon, supon, y vuelve a suponer, pero se especifico, se detallado, entiende las implicaciones de lo que estas suponiendo, se muy claro al explicar al cliente tus supuestos, para que quede claro en que se estan metiendo ambos.

Pero mucho de eso creo que sólo lo obtienes con la experiencia, despues de haber desarrollado una metodologia efectiva de trabajo y la intuición en éste negocio del software, que dicho sea de paso y sin afan de hechar de menos el trabajo de nadie, muy pocos son los que desarrollan y a la vez tiene la formación o en su defecto el callo suficiente para sacar a flote un proyecto de software,

De acuerdo, el modo como suele obtenerse es por experiencia, pero la experiencia te hara suponer mas, no menos.

lo que me lleva a pensar que si no tienes capacidad más allá de la técnica, es indispensable que encuentres a alguien que te eche la mano en ese aspecto

De acuerdo

o dicho de otra manera el bisnes es una cosa y lo que vendes es otra muy diferente

No entiendo...

o como decimos mas comunmente zapatero a tu zapato.

Conozco ese dicho, pero no estoy seguro de con que intencion lo mencionas aqui...

Imagen de echan

ok .. creo que estamos

ok .. creo que estamos hablado de lo mismo .. a los "supuestos" yo le llamo "requerimientos" y si estan bien elaborados no tendrás muchos problemas en cumplirlos .. y vuelvo a reiterar "el problema es la candidad de cosas que supongas y asumas" completandolo con "si no tienes idea de lo que esto implica" .. aun asi estimar tiempo y recursos no es ciencia exacta y se requiere conocimiento de lo que se va a construir. Por poner un ejemplo, si vas a elaborar un sistema de nomina y no sabes como se hace "a mano" la especulacion es más alta y depende de tu habilidad para capturar adecuadamente los requerimientos, por otra parte, con conocimiento de causa es más efectiva la medición de cada proceso que pretende cumplir tu sistema.

o dicho de otra manera el bisnes es una cosa y lo que vendes es otra muy diferente

No entiendo...

o como decimos mas comunmente zapatero a tu zapato.

Conozco ese dicho, pero no estoy seguro de con que intencion lo mencionas aqui.

Ok seguro no lo expresé bien ... la administracion del proyecto es un cosa pero contruirlo deberia ser una etapa muy sencilla si tu analisis fue adecuado. De ahi que la administración de proyectos sea todo un tema y mientras tanto la historia es más común de lo pensamos.

Imagen de echan

me retracto un poco .. "

me retracto un poco .. " contruirlo deberia ser una etapa muy sencilla" pfff programar no es facil y quien diga lo contrario que aviente el primer código.. lo que quize decir es que más fácil hacerlo si sabes qué es lo que tienes que hacer.. en lugar de estar inventando por no tener las cosas claras.

Imagen de luxspes

quien diga lo contrario que aviente el primer código!

me retracto un poco .. " contruirlo deberia ser una etapa muy sencilla" pfff programar no es facil y quien diga lo contrario que aviente el primer código..

Totalmente de acuerdo ;-)

lo que quize decir es que más fácil hacerlo si sabes qué es lo que tienes que hacer.. en lugar de estar inventando por no tener las cosas claras.

Bueno... saber lo que se tiene que hacer no lo hace mas o menos dificil... solo mas o menos claro.

Andar inventando no es malo (si Edision no hubiera andado inventando no hubiera inventado el foco, si Jobs no hubiera andando inventando no habria iPhone, si...), andar inventando es bueno, lo malo es no dejarle claro al cliente que estas inventando.

Imagen de avefenix_x

saber lo que se tiene que hacer no lo hace mas o menos dificil..

De acuerdo con el comentario:

Saber lo que se tiene que hacer no lo hace más o menos difícil... solo más o menos claro

El objetivo de suponer, suponer y suponer sobre un tema es acercarse más a lo real de lo que se tiene que hacer, el conocer más del tema hace que tu producto sea más apegado a la realidad del cliente y que no necesariamente es la tuya.
El como desarrollar la solución esa.. esa…. es otra historia por que puede ser tan fácil o difícil como uno lo plantee.
Saludos.