Estimacion: Por que estimamos (Parte 1)

Hay quienes consideran que estimar es imposible y una perdida de tiempo, una inutilidad, hay quienes consideran que si puede hacerse, pero solo bajo ciertas condiciones y hay quienes piensan que el secreto en seguir un cierto método... Sin embargo yo quisiera antes de platicar al respecto de dichos puntos de vista, centrarme en una pregunta a menudo omitida en los artículos y libros de estimación:

Por que estimamos? Y no hablo de por que en el sentido teórico que típicamente se utiliza en los libros del tema, si no de, afuera, en el mundo real. No quisiera generalizar, asi que lo que diré a continuación lo digo acotado únicamente a mi experiencia.

No estimamos para saber cuanto tardara el proyecto, el cliente generalmente ya estableció un deadline que difícilmente moverá.

Por que estimamos entonces? Estimamos para ver si podemos hacer algo que quepa dentro del tiempo y presupuesto que ya están establecidos y que le suene al cliente a lo que pidió (por que si algo es cierto es que la mayoría de los clientes no sabe realmente lo que quiere hasta que no se le han hecho un par de demostraciones de avance )

La comunidad ágil nos dice: no estimes, has todo por tiempo y materiales, aunque en realidad lo que esta diciendo es "no estimes mas allá del siguiente sprint" y "pierde a todo cliente que solo este dispuesto a comprar proyectos a costo y tiempo fijo". Que bonito seria el mundo si fuera tan fácil, pero el hecho es que no es asi: la mayoría de los clientes que ha conocido en el mundo de la consultoría quieren un presupuesto por adelantado... A los que nos gustaría que todo el mundo entendiera Scrum nos parece a veces absurdo, una muestra de su ignorancia dicen algunos, pero pongámonos en su lugar: quien cuando lleva su auto al taller espera que le contesten: vamos a arreglar su coche iterativamente, denos su tarjeta bancaria con voucher abierto y ahí luego checa su saldo para saber cuanto fue al terminar...

Y sin embargo vamos al medico, y si bien cada consulta suele tener un costo fijo, no le pedimos al medico que nos de el costo de las medicinas antes de diagnosticarnos, ni lo obligamos a decirnos por adelantado el numero máximo de consultas que necesitaremos... El tratamiento medico es completamente iterativo... Quizá algún dia reconoceremos las similitudes entre curar al sistema biológico mas sofisticado que conocemos y crear o componer nuevos sistemas... Mientras tanto pensemos... Por que hay proyectos a costo fijo que si funcionan? El nivel de incertidumbre claramente visible para la mente educada al inicio del proyecto debería garantizar que eso nunca pase... ¿Que es distinto en esos proyectos? Quizá no es obvio, pero en mi experiencia es bien simple: el alcance estaba mejor acotado, ya sea por que el cliente mismo ya había realizado una labor de pre análisis, ya sea por que el equipo de la consultora hizo lo mismo.... SACRILEGIO! me estoy atreviendo acaso a decir que el modo correcto de sacar un proyecto es con Waterfall?

NO! El creer eso es ignorar el principio de diminishing returns: quien cree que esto indica que Waterfall es la respuesta, cae en el error de creer que si algo de análisis es mejor que nada, el doble o el cuádruple de análisis traerá un beneficio directamente proporcional. Bueno, pues bienvenidos al mundo real: las cosa no funcionan asi, si haces un chorro de análisis, también consumes un chorro de tiempo y si bien tu entendimiento de la situación se vuelve mas preciso, también se vuelve progresivamente desactualizado... El mundo no deja de cambiar por que tu analices un punto determinado del mismo en el tiempo y para cuando volteas a comparar tu análisis con la realidad actual, el mundo ya cambió: las conclusiones de tu análisis son ahora obsoletas.

Cero análisis? Malo. Análisis exhaustivo? Malo... Que hacer entonces? Encontrar cuanto es "lo suficiente" pero hay que entender primero lo suficiente para que? Muchos libros de estimación hablan de conseguir 75% de precisión, como el objetivo último de una estimación bien lograda. En mi experiencia esa percepción es errónea. De que te sirve decirle a un cliente: para tener éxito en lo que me pide, necesito 1 millón de pesos, si el cliente solo tiene (o dice tener) una tercera parte de eso? De nada, el cliente no tendrá su producto, y nosotros no tendremos nuestro proyecto.
Que hacer entonces?

Buscar el "como si", la primera ves que escuche esa frase me pareció ingenua: hacer en proyecto de 1 millón por la tercera parte? Imposible! Pero entonces sucedía que algunas personas me preguntaban: por que? Y yo me complicaba la vida dando mil explicaciones sobre las complejidades que forman parte del desarrollo de software (muchas de las cuales no comprendía entonces... y muchas de las cuales sigo sin comprender del todo ahora) y... no lograba convencerlos, y acababa atrapado en horroroso proyectos Dead March de los que no solo recibía presión de parte del cliente, desesperado por que el proyecto no pintaba ni remotamente para terminarse en el deadline, si no tambien de parte de la empresa para la que trabajaba, igualmente desesperada al ver que el margen del proyecto se erosionaba hasta desaparecer...

Y al terminar ese proyecto... nos embarcábamos en otro igual... ¿Como romper ese ciclo? Es verdad, como leí hace poco en twitter, que, el asumir, es la madre de todos los problemas en el desarrollo de sistemas? De eso hablare en mi siguiente post...

Comentarios

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 Sr. Negativo

"No Estimamos para saber

"No Estimamos para saber cuanto tardara el proyecto, el cliente generalmente ya estableció un deadline que difícilmente moverá"

o_0

Imagen de luxspes

Quien manda vs quien cree que manda

Efectivamente, "No Estimamos para saber cuanto tardara el proyecto, el cliente generalmente ya estableció un deadline que difícilmente moverá", pero el truco esta en no caer en la desesperación (como le pasa a Dilbert). La clave esta en darse cuenta que el PHB rara vez entiende lo que pide, y eso es un arma de 2 filos, puede cortarnos, haciendonos sangrar incontables horas de desvelos... o puede permitirnos recortar y ajustar el alcance y las expectativas, permitiéndonos entregar algo que haga feliz al PHB, le permita a la empresa ganar dinero y evitar desvelarnos, pero solo si jugamos correctamente nuestras cartas.

Por eso siento impracticos a la mayoria de los libros de estimacion que he leido, se concentran en como estimar correctamente, en un contexto probabilistico, son muy bueno para que nosotros los que construimos el software, entendamos por que no debemos sobre-estimar nuestra capacidad predictiva, pero suelen dejar el tema de "y ahora como le digo a mi jefe que no vamos a poder terminar en la fecha que el quiere" fuera... La clave, por supuesto, es que "lo que hay que terminar en la fecha" suele estar tan vagamente definido en la mente del cliente o del jefe, como lo esta en la tuya, el trabajo de estimacion no consiste en decirla al jefe "no se puede" por que en realidad no tenemos la informacion para decir eso, el trabajo consiste en establecer que si se puede, y averiguar si eso que se puede se puede ajustar para darle al cliente/jefe el valor de negocios que el anda buscando

Imagen de ezamudio

Del lado del cliente

Acabo de tener una experiencia como cliente, con esto de los estimados. Se descompuso mi lavadora, llamé un técnico que vino a hacer un diagnóstico, obviamente no hay estimado de tiempo para el diagnóstico, sólo te dicen que cuando te entreguen el diagnóstico, si les das la chamba de arreglar la lavadora pues adelante pero si no lo quieres hacer entonces te cobran $100 por el diagnóstico. Me parece más que justo.

Obviamente cuando me explicaron la falla y me dieron el costo de la reparación, pues no tenía mucha opción así que les pedí que lo arreglaran. En ese momento me dieron el estimado de costo y además el de tiempo: en tres días vendría un técnico con las refacciones necesarias a hacer la reparación y tenía que pagarles en ese momento. Si era transferencia interbancaria pues tenía que hacer el movimiento mientras estaba el técnico haciendo su chamba, para entregarle el recibo al final.

Llega el técnico el día que dijeron, se dispone a trabajar, desarman la lavadora, mientras tanto pues hago el movimiento bancario. Y al poco tiempo, "joven qué cree? el que hizo el diagnóstico anotó mal el número de parte y traje una pieza que no es..." total que no pueden arreglar la lavadora. Que si no hay problema con que me dejen todo ahí desarmado, porque pues vienen al día siguiente con la parte correcta. Pues órale.

Al día siguiente no viene nadie, llamo para reclamar y me explican que la pieza faltante la tuvieron que pedir y están esperando que llegue pero que seguramente en dos días más ya les llega y me vienen a terminar la reparación. A los dos días llamo y nada, que no ha llegado la pieza. Y así estuve, llamando diario para preguntar qué dia; yo ya sólo quería que me dieran un estimado de tiempo, pero seguían con la fantasía de que "ya mañana". Así me trajeron 10 días. Yo ya les había pagado.

Al final de los 10 días vienen, la reparan, les doy su maldito recibo (que seguramente ya ni necesitaban porque hasta el estado de cuenta les había llegado con mi depósito) y se largan.

Qué pasó? Se apegaron al estimado de costo, eso sí, no salió nada adicional. Pero el tiempo les falló abismalmente. Y no por cambios en los requerimientos, simplemente porque no levantaron bien sus requerimientos al principio. Me dieron algún descuento? Obvio no. Los volvería a contratar? JAMÁS! Realmente era muy difícil decirme "la pieza va a tardar una semana" en vez de estarme dando largas cada vez con que "mañana llega"?

Y otra cosa: El que vino a hacer el diagnóstico es una persona, el que vino a hacer la reparación es otra, la que me decía que "mañana" en el teléfono es otra, y el que una vez tomó la llamada ya que le estaba mentando la madre a la que me decía que "mañana" era otra (ese último fue el que me dijo que ya en dos días más llegaba la pieza, así que hicieron upgrade de "mañana" a "pasado mañana"). Y parece que el problema es falta de comunicación interna... lo cual, regresando ahora al lado del proveedor, me parece muy común: Los vendedores dan una fecha de entrega y un costo, los project managers quieren apegarse a eso, los programadores dicen que no se puede, hacen su propio estimado y pues cuando la realidad no concuerda con lo que ya le dijeron al cliente, y nadie quiere dar la cara. Tal vez lo mejor sería que le dijeran al programador "ahora de castigo, tú le dices al cliente que no va a estar en el tiempo que le dijimos". Así el programador podría hablar con el cliente y decirle "mire señor, estos tarados que no saben nada de lo que se tiene que hacer le dijeron una cosa, pero la realidad es ésta". Pero... precisamente ésa es la razón por la que prácticamente ninguna consultora quiere que los programadores tengan contacto con el cliente. Cosa muy difícil de lograr cuando luego resulta que el cliente quiere a los programadores en su oficina (nunca he entendido por qué), pero eso ya es otra historia.

Imagen de luxspes

Cocinando lento, el valor de la transparencia, como decir algo

Acabo de tener una experiencia como cliente, con esto de los estimados. Se descompuso mi lavadora, llamé un técnico que vino a hacer un diagnóstico, obviamente no hay estimado de tiempo para el diagnóstico, sólo te dicen que cuando te entreguen el diagnóstico, si les das la chamba de arreglar la lavadora pues adelante pero si no lo quieres hacer entonces te cobran $100 por el diagnóstico. Me parece más que justo.

Es caso de "fix", eso ayuda a que el diagnostico pueda manejarse así, por que como no es funcionalidad nueva, no hay que inventar nada, nada mas hay que revisar lo ya existente para saber por donde se "amoló", eso hace que sea efectiva esta estrategia.

Obviamente cuando me explicaron la falla y me dieron el costo de la reparación, pues no tenía mucha opción así que les pedí que lo arreglaran.

Si habia opciones, pudiste haber elegido comprar otra lavadora, si te hubiera parecido muy cara la cotización, o pudieras haber decidido repararla tu mismo (si quisieras volverte ahora hacker de lavadoras ;-) ). Pero te pareció que la mejor opción era dejar que la arreglaran. Un aspecto interesante es que te "explicaron" la falla, una accion puramente psicologica, por que obviamente no les interesaba que entendieras (ni a ti entender), mas alla de lo que podia costar / tardar.

En ese momento me dieron el estimado de costo y además el de tiempo: en tres días vendría un técnico con las refacciones necesarias a hacer la reparación y tenía que pagarles en ese momento. Si era transferencia interbancaria pues tenía que hacer el movimiento mientras estaba el técnico haciendo su chamba, para entregarle el recibo al final.
Llega el técnico el día que dijeron, se dispone a trabajar, desarman la lavadora, mientras tanto pues hago el movimiento bancario.

Error, no debiste pagar hasta no recibir el servicio a satisfacción. Esto no siempre aplica, si fuera algo muy largo, por etapas, hubiera hecho sentido que pagaras para obtener un valor de negocio intermedio, pero en este caso, no había valor de negocio intermedio que obtener (a menos que fuera necesario tu pago para traer la pieza, pero no indicas eso en tu relato)

Y al poco tiempo, "joven qué cree? el que hizo el diagnóstico anotó mal el número de parte y traje una pieza que no es..." total que no pueden arreglar la lavadora. Que si no hay problema con que me dejen todo ahí desarmado, porque pues vienen al día siguiente con la parte correcta. Pues órale.

Esto es algo que los PM siempre olvidan y que herramientas como Microsoft Project son incapaces de representar ¿y si alguien se equivoca?. Las herramientas como Microsoft Project suelen simplemente ignorar este hecho. Para representar esto correctamente es necesario contar con una herramienta que soporte "Event chain methodology", la única que he podido encontrar en internet es Intaver ... un proyecto interesante seria crear una herramienta de este tipo (con un modelo opensource quiza? O tal vez a traves de Indiegogo...)

De nuevo, aquí se refleja el "entendimiento del cliente", si realmente hubieras entendido el problema (lo que implicaría que sabrías de reparación de lavadoras, y mas aun de esa lavadora en particular) tu mismo te hubieras dado cuenta de que no era la pieza correcta desde el principio... pero no, ni entendiste (como lo haría un experto) ni te interesaba entender...

Al día siguiente no viene nadie, llamo para reclamar y me explican que la pieza faltante la tuvieron que pedir y están esperando que llegue pero que seguramente en dos días más ya les llega y me vienen a terminar la reparación. A los dos días llamo y nada, que no ha llegado la pieza. Y así estuve, llamando diario para preguntar qué día; yo ya sólo quería que me dieran un estimado de tiempo, pero seguían con la fantasía de que "ya mañana". Así me trajeron 10 días.

Ese es uno de los factores psicológicos complejos, hay clientes a los que si les dices de golpe 10 días, te van a querer matar, y conviene mas decirles mañana y luego mañana y luego mañana.... Son de las cosas que se aprenden solo interactuando con cada cliente, por eso siempre debemos considerar mas riesgoso trabajar con alguien desconocido, por que podemos aplicar la estrategia equivocada y perder el negocio

Yo ya les había pagado.

Ya eras cliente "cautivo", en eso ciertamente no ayudo a tu posición, aunque, al no ser la lavadora algo critico para tu supervivencia, hubieras podido inclusive mandarlos al diablo y comprar otra... eso es algo que los proveedores suelen olvidar...

Al final de los 10 días vienen, la reparan, les doy su maldito recibo (que seguramente ya ni necesitaban porque hasta el estado de cuenta les había llegado con mi depósito) y se largan.

Algo similar me paso en mi contratación de internet, al final lo conseguí, pero me cambiaron la fecha 5 veces... afortunadamente, yo no había pagado... curiosamente, lo que mejor funciono, fue cuando les dije "ya no quiero el servicio"...

Qué pasó? Se apegaron al estimado de costo, eso sí, no salió nada adicional. Pero el tiempo les falló abismalmente. Y no por cambios en los requerimientos, simplemente porque no levantaron bien sus requerimientos al principio. Me dieron algún descuento? Obvio no. Los volvería a contratar? JAMÁS! Realmente era muy difícil decirme "la pieza va a tardar una semana" en vez de estarme dando largas cada vez con que "mañana llega"?

De nuevo, el componente psicológico, tal vez si te hubieran dicho 10 días... te hubieran podido hacer enfurecer al punto de exigir en ese momento tu dinero de vuelta... Mejor te cocinaron lento

Y otra cosa: El que vino a hacer el diagnóstico es una persona, el que vino a hacer la reparación es otra, la que me decía que "mañana" en el teléfono es otra, y el que una vez tomó la llamada ya que le estaba mentando la madre a la que me decía que "mañana" era otra (ese último fue el que me dijo que ya en dos días más llegaba la pieza, así que hicieron upgrade de "mañana" a "pasado mañana"). Y parece que el problema es falta de comunicación interna...

Exacto, decisiones distorsionadas y acumuladas, parece simple desde la perspectiva del cliente, pero desde la perspectiva del proveedor del servicio es posible que hubiera mas cosas atoradas. Un típico ejemplo de como la eficiencia (mínimo de recursos, tratando con múltiples peticiones) le da fragilidad al proceso. Si fuera 1 persona de principio a fin, y no iniciara un servicio hasta terminar el anterior, se vería mas ineficiente en el papel, pero en realidad, funcionaria mucho mejor . Y si usaran "pair fixing" (como en pair programming) tal vez el par se hubiera dado cuenta de se estaba apuntando la pieza incorrecta desde el principio... pero claro, precisamente, como no computamos el esfuerzo necesario considerando que las redundancias no son siempre mas caras que los errores...

lo cual, regresando ahora al lado del proveedor, me parece muy común: Los vendedores dan una fecha de entrega y un costo, los project managers quieren apegarse a eso, los programadores dicen que no se puede, hacen su propio estimado y pues cuando la realidad no concuerda con lo que ya le dijeron al cliente, y nadie quiere dar la cara.

El problema es precisamente, que no pensamos en los ciclos de retroalimentacion, dejamos que la cosa fluya en una sola dirección, los programadores acumulan desprecio por las decisiones de los vendedores... y viceversa. En vez de pensar en las cosas como separadas hay que integrar, buscar incrementar la comunicación entre ambos lados, para que se ayuden en vez de atacarse (nada facil, por supuesto, pero ya hablaré mas adelante a detalle de ese tema)

Tal vez lo mejor sería que le dijeran al programador "ahora de castigo, tú le dices al cliente que no va a estar en el tiempo que le dijimos".

La pregunta es ¿castigo para quien? ;-) Finalmente no elegimos al programador (ni somos programadores) por su (nuestra) habilidad para poder decirle estas cosas al cliente de un modo que evite que este ultimo pierda el control y mande todo al diablo (quizá deberíamos capacitarles(/capacitarnos) en esto?)

Ponte a pensar... ¿te hubiera gustaro recibir una catedra detallada en reparacion de lavadoras? No creo... y sin embargo, es lo que mas probablemente te hubiera podido explicar detalladamente el mecanico... (informacion verdadera, y util en muchos contextos, pero no en el tuyo)

Así el programador podría hablar con el cliente y decirle "mire señor, estos tarados que no saben nada de lo que se tiene que hacer le dijeron una cosa, pero la realidad es ésta".

En algunos caso podría ser buena idea, pero en mi experiencia, el programador no suele tener el entrenamiento para explicar el problema de un modo que el cliente lo entienda de un modo que tenga valor para dicho cliente ( a cuantos clientes a los que se les descompone les interesa realmente entender como opera una lavadora? o el acceso a la información, por ejemplo es posible que te dijeran "mañana", y no pudieran decirte otra cosa, por que, dentro de la empresa, "mañana" es lo que el área encargada de traer las piezas les contestaba a ellos). Y por supuesto, el mecánico muy probablemente no podría tampoco explicarte el por que del proceso de negocios que llevo a separar el área de reparaciones del área de compras...

En software es todavía peor, por que a menudo lo único que el programador sabe... es que no sabe cuando va a quedar... ahí es donde es importante entrenarle en poder describir su trabajo en incrementos intermedios con valor visible para el usuario... (pero de eso, al menos en mis tiempos, no había materia en la carrera, lo cual es una de las razones por la que quiero escribir esta serie de blog posts). Y ahi es donde tambien el PM falla, por que, igualmente, lo entrenaron (si es que en algo lo entrenaron) para darle seguimiento a un plan, no para estructurarlo de un modo en quede claro el valor intermedio que se le esta dando al cliente en términos de historias de usuario. Ni lo que sabe el programador, ni lo que sabe el PM, le interesa al usuario...

Pero... precisamente ésa es la razón por la que prácticamente ninguna consultora quiere que los programadores tengan contacto con el cliente.

La razón siendo, que tienen miedo de que planteen las cosas de un modo que haga enfurecer al cliente mas rápido? si.

Cosa muy difícil de lograr cuando luego resulta que el cliente quiere a los programadores en su oficina (nunca he entendido por qué), pero eso ya es otra historia.

Oh, vamos, el por que es muy simple, te da sensación de control (y a veces, hasta algo de verdadero control) reduce el numero de intermediarios entre quien pide la chamba y quien la realiza, etc, etc. Dices que te hubiera gustado saber la verdad desde el principio... igual y si todas las llamadas de los técnicos las hubieran hecho desde tu casa, con tu teléfono, en speaker, hubieras podido darte cuenta que cual era el problema... por ejemplo que las piezas las fabrican en un lugar donde las carreteras estaban bloqueadas por manifestantes.... y entonces, tal vez, si volverías a contratar a la empresa, por que los considerarías victimas involuntarias de eventos mas allá de su control... (o quizá no... pero esa como dices, ya es otra historia...). A menos intermediarios, menos oportunidades para que se atore el flujo de informacion, por eso se busca tener equipos con miembros multidisciplinarios, que no te digan "pase a la siguiente ventanilla"

Imagen de ezamudio

entender

Entender? qué hay que entender? En este caso, la verdad si me tengo que poner en plan de "me voy a volver experto en lavadoras" y me pongo a investigar qué pieza se necesita cambiar, etc, pues mejor ya voy al centro a comprarla yo o a ver dónde la consigo y la instalo. Pero como dices, ni me interesa, ni tengo el tiempo para hacerlo, y por eso estoy contratando a alguien que *se supone* que sabe del tema y que espero que lo haga bien a la primera.

Es lo que se espera de nosotros también, no? A fin de cuentas hay muchos problemas que tenemos que resolver nosotros y que al cliente no le interesan, por eso nos contrataron; no quieren saber cómo lo vamos a resolver, sólo cuánto tiempo tardamos y cuánto les va a costar. Hay casos en lo que esto no puede ser porque se requiere cierta intervención del cliente, cuando son cosas que afectan su negocio, etc pero hay cosas que no. Por ejemplo, a un cliente que no tiene absolutamente ningún sistema porque está empezando (me imagino ahorita tal vez un restaurante por ejemplo), no debería importarle si la aplicación se la hacen en .NET o en Java o en Qt o en lo que sea, que si va a correr sobre Mac/Windows/Linux o que si está hecho en Java va a usar Spring/JEE/RichFaces/Grails/Scala/etc; lo que le importa es que los equipos que tendrá que comprar no sean muy caros y que aguanten el trato que van a recibir en ese ambiente, que el sistema haga lo que tiene que hacer, responda rápido, sea fácil de usar, etc; lo de siempre.

Con clientes más grandes obviamente hay otros criterios: si ya invirtieron en alguna tecnología previamente pues quieren sacarle provecho, no quieren tener que mantener 20 cosas distintas, quieren tener un ambiente lo más homogéneo posible, etc.

Todo esto ya no tiene que ver con estimados, solamente comento todo esto porque me saltó mucho ese comentario de "ni entendiste porque no te pusiste en plan experto, ni quisiste entender".

Imagen de AlexSnake

Estimacion: Quien deberia estimar.?

La estimación del desarrollo la debe hacer alguien que debe conocer sobre la programación o al menos debe tener un poco de noción porque si el cliente o el PM no tienen ni idea de que se debe hacer (programando) "solo porque se escucha fácil", es donde meten en problemas al programador(es) incluso al mismo proyecto dando fechas muy cortas.

Se me hace buen post , incluso deberias hacer uno previo. Estimacion: como debes estimar?

Imagen de ezamudio

miles

Hay miles de posts en internet acerca de cómo estimar. Como ya dijo luxspes, hay libros enteros dedicados al respecto. Ninguno toca el por qué se hacen los estimados, porque es un tema muy escabroso. Todos nos hemos topado con esa situación mencionada al inicio: el cliente ya puso una fecha de entrega, sin importarle si es factible o no. Yo he estado varias veces en una situación en que me dicen que pues la fecha es tal día, así que debo hacer un estimado donde salga que se puede entregar tal día. Es una estupidez, yo siempre termino discutiendo que pues si ya el cliente dijo eso pues ora sí que "a darle" y a ver si llegamos, porque pues así como se puso de arbitrario con la fecha, ese día nos pondremos de arbitrarios con que si estuvo o no estuvo. También me he puesto en plan de "no va a estar ese día y háganle como quieran", explicando por qué no va a estar ese día. Tienen opciones, como menciona luxspes con mi caso de la lavadora... yo no consideré las opciones de arreglarla yo mismo o de buscar alguien más que la arreglara pero pues ya estaba el tipo ahí y consideré que por tiempo, lo mejor era que ya lo hiciera este proveedor. Así el cliente y la empresa donde trabajo también tienen opciones: el cliente puede mandarnos al carajo y buscar otro proveedor, o la empresa puede mandarme al carajo a mí y buscar otro programador. Pero en muchas ocasiones he visto que no se trata de otra cosa que el mismo regateo que se ve en los tianguis, un vil "cuánto es lo menos" de ambos lados. Al final el cliente cede un poco con esa fecha, y el proveedor cede un poco con el costo, o agregan features o alguna otra cosa a los entregables, etc.

Suena muy pretencioso tal vez, pero es que hay veces en que uno debe considerar: es mejor que me corran ahorita, y busco otra chamba estando un poco más tranquilo y que quede asentado que la razón de mi salida fue mi "poca disposición a cooperar" o como quieran llamarle porque dije que no se iba a poder entregar el proyecto en la fecha arbitrariamente establecida? o que me corran después porque no pudimos entregar el sistema en esa fecha arbitrariamente establecida, pero ya estoy super cansado de todas las desveladas y regaños que sufrí durante el proyecto (que sabía que no ibamos a poder entregar a tiempo)? Otra opción: renunciar en ese momento. Imagínense si TODOS los programadores del mundo hicieran eso: renunciar cuando les imponen una fecha de entrega arbitraria que todo mundo sabe que es imposible cumplir. Utópico, sí, pero pues uno no puede depender de que los demás hagan lo que deberían. Nunca he llegado al grado de renunciar por esta situación que describo, pero sí he gritado pataleado y me he tirado al suelo hasta tener la atención de todo mundo para poder explicar por qué no se va a poder. Y al final decir simplemente "no va a estar". Y el cliente o el jefe se ponen en plan "ok entonces va a estar para tal día" (como que no me oyeron) y yo digo otra vez "no, no va a estar para ese día"... "pues a ve cómo le haces" y yo "ajá, no va a estar", etc. Cuando se vuelve concurso de necedad pues es bien simple, gana el más necio...

Imagen de luxspes

Lo que uno quiera entender

Entender? qué hay que entender?

Hay que entender, que lo que a unos nos puede parecer interesante e importante entender a otros no... a ti, por ejemplo, no te interesaba, entender como funcionaba la lavadora (y estas completamente en tu derecho).

Del mismo modo un cliente de un sistema de software, igualmente, puede no interesarle entender como se programa o repara ese sistema que desea comprar.

En este caso, la verdad si me tengo que poner en plan de "me voy a volver experto en lavadoras" y me pongo a investigar qué pieza se necesita cambiar, etc, pues mejor ya voy al centro a comprarla yo o a ver dónde la consigo y la instalo.

Exacto (eso haría mi papá, yo, como tu, lo dejaría en manos del técnico). ¿Que es mejor? Depende de tus prioridades particulares

Pero como dices, ni me interesa, ni tengo el tiempo para hacerlo, y por eso estoy contratando a alguien que *se supone* que sabe del tema y que espero que lo haga bien a la primera.

Exacto, pero... ¿de que tema se supone saben? ¿de arreglar lavadoras? ¿o de llevar negocios de reparaciones de lavadoras?. Lo que que aqui fallo, no fue la reparación en si misma, si no el procedimiento para requisitar la pieza correcta.

Así pues, el técnico en lavadoras no tiene el conocimiento para explicarte por que fallo, por que el problema no corresponde a su ámbito, el problema es uno del proceso del negocio, y como tal, si te interesa saber el por que del fallo, tendría que ser alguien experto en dicho ámbito quien te lo explique (de nuevo, solo si te interesa, a la mayoría de las personas en tu situación no les interesan explicaciones del ROI y nivel de riesgo en que se incurre llevar el proceso de compras de piezas de tal o cual manera... Y aun dicho experto, siendo capaz de explicar la falla, y el por que se asume dicho riesgo, no seria el adecuado para responderte... eso a ti, como dueño de una lavadora descompuesta no te interesa ¿o si?)

Es lo que se espera de nosotros también, no? A fin de cuentas hay muchos problemas que tenemos que resolver nosotros y que al cliente no le interesan, por eso nos contrataron; no quieren saber cómo lo vamos a resolver, sólo cuánto tiempo tardamos y cuánto les va a costar.

Esa Chochos, es la pregunta correcta. ¿Eso es realmente lo que se espera? Ciertamente el cliente no espera que le enseñemos a programar... así que, estrictamente hablando, que el programador sea su punto de contacto, no es la mejor idea ¿o si?. En realidad quien debiera llevar esto, debiera ser un analista de negocios (nada impide que el programador pueda jugar también ese rol (de hecho yo pienso que hace falta saber programar para poder ser un analista de negocios efectivo en la traducción entre cliente y programador), pero es importante recordar la diferencia).

Hay casos en lo que esto no puede ser porque se requiere cierta intervención del cliente, cuando son cosas que afectan su negocio, etc pero hay cosas que no.

Claro, depende, todo depende....

Por ejemplo, a un cliente que no tiene absolutamente ningún sistema porque está empezando (me imagino ahorita tal vez un restaurante por ejemplo), no debería importarle si la aplicación se la hacen en .NET o en Java o en Qt o en lo que sea, que si va a correr sobre Mac/Windows/Linux o que si está hecho en Java va a usar Spring/JEE/RichFaces/Grails/Scala/etc; lo que le importa es que los equipos que tendrá que comprar no sean muy caros y que aguanten el trato que van a recibir en ese ambiente, que el sistema haga lo que tiene que hacer, responda rápido, sea fácil de usar, etc; lo de siempre.

Exacto, pero, si te pones a pensarlo, en esta parrafo tu mismo te contradijiste, no debería importarle si la aplicación se la hacen en .NET o en Java o en Qt o en lo que sea, que si va a correr sobre Mac/Windows/Linux o que si está hecho en Java va a usar Spring/JEE/RichFaces/Grails/Scala/etc y luego dijiste lo que le importa es que los equipos que tendrá que comprar no sean muy caros y que aguanten el trato que van a recibir en ese ambiente, que el sistema haga lo que tiene que hacer, responda rápido, sea fácil de usar, etc; lo de siempre y la realidad es que unos factores si inciden sobre los otros (por ejemplo, es muy dificil que en a un cliente interesado en bajos costos en corto plazo quiera una Mac. O que prefiera Windows a iOs en una tablet si lo que busca es facilidad, o que prefiera un iPad a un dispositivo rugged dado el trato que le va a dar (etc, etc)

Por supuesto que me doy cuenta, que si bien estos factores estan conectados, en cierto tambien que en cierto sentido no le interesan al cliente, precisamente lo que se tiene que hacer es un mapeo entre lo que le interesa al cliente y el como y cuando conseguirlo... y ahi es donde precisamente entra la labor de un analista y un project manager. El problema es que muchas empresas si no yerran de un modo yerran del modo contrario (poner a un programador no capacitado a negociar con el cliente el alcance o los tiempos es tan malo como poner a un analista no capacitado a decidir que version de que framework de Java se usara, o dejarle decidir el project manager si se hara con applets o con html5)

Esto no quiere decir que no sea el programador el que dice cuanto se tarda en hacer X, si, el programador (debidamente capacitado en técnicas de estimación para programador) debe estimar los tiempos, pero no le toca decidir como decirle eso al cliente, eso es algo que el programador no suele estar capacitado para hacer (por supuesto, algunos si, pero esa labor ya no es una labor estricta de programacion, por eso Scrum solicita equipos en donde no haya como tal "programadores", "analistas", "project managers" o "testers", equipos donde cualquiera pueda ponerse cualquier cachucha, pero conseguir gente así de buena no resulta nada fácil) .

Con clientes más grandes obviamente hay otros criterios: si ya invirtieron en alguna tecnología previamente pues quieren sacarle provecho, no quieren tener que mantener 20 cosas distintas, quieren tener un ambiente lo más homogéneo posible, etc.

Exacto.

Todo esto ya no tiene que ver con estimados

Por el contrario, tiene todo que ver, si estos factores alteran lo que vas a entregar, y eso altera el tiempo que vas a tardar en hacer las cosas alterando el estimado.

Solamente comento todo esto porque me saltó mucho ese comentario de "ni entendiste porque no te pusiste en plan experto, ni quisiste entender".

Perdón si sonó agresivo, no era mi intención, este medio escrito luego le da un "sonido" incorrecto a ciertas frases y hace muy fácil meter la pata, pero, supongo estarás de acuerdo, no te interesaba, y aun ahora, no puedes explicar por que tardaron tanto en traerte la pieza ¿ o si ?

Imagen de luxspes

Escabrosisimo

Hay miles de posts en internet acerca de cómo estimar. Como ya dijo luxspes, hay libros enteros dedicados al respecto. Ninguno toca el por qué se hacen los estimados, porque es un tema muy escabroso.

Exacto!

Pero en muchas ocasiones he visto que no se trata de otra cosa que el mismo regateo que se ve en los tianguis, un vil "cuánto es lo menos" de ambos lados. Al final el cliente cede un poco con esa fecha, y el proveedor cede un poco con el costo, o agregan features o alguna otra cosa a los entregables, etc.

Mas exacto todavia! Y precisamente el tema que quiero cubrir. Si, no se puede estimar el desarrollo de software bien si no se sabe programar, pero si no se sabe levantar requerimientos, y plantearlos y venderlos, el asunto tampoco llegara a buen termino. Y la mayoria de los libros se concentra unicamente en como ayudarle al programador a estimar, y olvida que si no se le entrena en como regatear, por muy solida que este su estimacion desde una perspectiva tecnica y probabilistica perderá la discusión

Imagínense si TODOS los programadores del mundo hicieran eso: renunciar cuando les imponen una fecha de entrega arbitraria que todo mundo sabe que es imposible cumplir. Utópico, sí, pero pues uno no puede depender de que los demás hagan lo que deberían. Nunca he llegado al grado de renunciar por esta situación que describo, pero sí he gritado pataleado y me he tirado al suelo hasta tener la atención de todo mundo para poder explicar por qué no se va a poder.

La intención de este serie, sera, precisamente, como ser lo mas efectivos posibles en negociar un estimado. Como redactarlo de forma que quede bien claro hasta donde se podra llegar, en suma, tal vez es algo pretencioso, pero el objetivo es formalizar el procedimiento de hacerle ver al cliente que si se puede, pero solo si tales condiciones (que dependen del cliente) se cumplen. Si como programadores nos ponemos roñozos en terminos que el cliente no puede entender, es mas dificil llegar a un buen acuerdo, asi pues, asi como convertimos los requerimientos en codigo, hagamos la traduccion contraria y expliquemos, en terminos que el cliente pueda entender, que haria falta para terminar el la fecha que pide (si lo hacemos bien, sera el cliente mismo quien nos ayudara... o quien se rajará, pero no sera por nuestra culpa)

Cuando se vuelve concurso de necedad pues es bien simple, gana el más necio...

Si, la realidad es que "estará el dia que tenga que estar, ni un dia antes, ni un dia despues". Pero si logramos que el cliente entienda por que, en sus terminos, quiero creer que un mundo con menos desvelos, perdidas de dinero y tiempo es posible... imagina...

Imagen de luxspes

Quien?

La estimación del desarrollo la debe hacer alguien que debe conocer sobre la programación o al menos debe tener un poco de noción

En mi opinión, tener conocimientos de programación es condicion necesaria, pero no suficiente para estimar y presentar correctamente dicha estimacion a un cliente

porque si el cliente o el PM no tienen ni idea de que se debe hacer (programando) "solo porque se escucha fácil", es donde meten en problemas al programador(es) incluso al mismo proyecto dando fechas muy cortas.

Correcto, pero incompleto, si, tener conocimientos de programación es condicion necesaria, pero no es suficiente, hay que tener tambien conocimientos de levantamientos de requerimientos, y saber como convertir la medicion del tamaño del proyecto a esfuerzo en horas, y saber de probabilidades, y riesgos y de como negociar una venta

Si solo sabes de programacion, estas tan ciego para presentar una estimacion, como si solo sabes de 1 de los otros temas, todos ellos son con condición necesaria, pero no suficiente, solo con la combinación de todos los factores, te permite y presentar de forma efectiva una estimacion.

Se me hace buen post

Gracias!

incluso deberias hacer uno previo. Estimacion: como debes estimar?

Ultimamente, pienso que con el primer paso es con COSMIC, y de hecho, hablare de el en esta serie, pero no sera precuela ;-)

Imagen de AlexSnake

Sin mas que decir.

Creo que todo eso que mencionan es muy cierto, espero que tu próximo post también hables de la negociaciones o al menos saber negociar porque me parece muy fundamental saberlo hacer. Y en cuanto a lo de como estimar me refería tal vez algunos puntos importantes, tal vez los más rescatables pero mejor googleo y me quito de dudas.

En referencia a lo que menciona ezamudio me doy cuenta que entonces que es muy común o más bien se da muy seguido dar plazos cortos, tal vez por lo que comenta luxspes por que no se tiene el conocimiento completo o tal vez por quedar bien con el cliente para mas proyectos.

En fin seguire aprendiendo de sus siguientes post, saludos.

Imagen de ezamudio

negociar

Yo también quiero ver qué nos dice luxspes de negociar, a ver si ha aprendido algo en estos años, porque la última vez que lo tuve el privilegio de verlo negociar algo, me quería dar de topes en la pared...

Imagen de luxspes

algo he aprendido

Algo he aprendido... ya tiene un poco mas de una decada desde entonces ;-).

Imagen de Pedro Galván

Por qué estimamos

Antes que nada, #yoconfieso que aunque sí lei todo el post original, ya no leí todos los comentarios, estaban kilométricos. Así que me atengo a la pregunta original de "¿por qué estimamos?" corriendo el riesgo de que alguien más ya puso lo mismo en comentarios.

A mi juicio, estas son las razones principales para estimar:
1. Necesitamos saber con anticipación si es costeable hacer un proyecto o no. Así como proyectamos el beneficio de realizar un proyecto (nos ahorrará X dinero al año, generará ventas por Y), entonces deberíamos ser capaces de tener una idea de cuanto cuesta hacerlo. Si no, corremos el riesgo de que el costo sea mayor que el beneficio.

2. Necesitamos coordinar la interacción con el resto de la operación de la empresa. Si estás haciendo un producto de software para un startup, donde el producto es el negocio en si, no importa nada más; es decir, mientras no tengas el producto de software no hay empresa, ni clientes, ni ingresos, ni soporte, ni nada. Pero en los proyectos de TI empresariales, que típicamente están orientados a mejorar/cambiar la operación del negocio, necesitamos empatar la liberación de un sistema de software con el resto de la operación de la empresa; esto puede incluir interacción con otros sistemas que se están desarrollando en paralelo (o que se van a reemplazar), ejercicio del presupuesto en el periodo fiscal adecuado, contratación, liberación o capacitación de personal, etcétera. El reto de los proyectos de software empresarial no es el software en sí, sino el construirlo y desplegarlo mientras el negocio sigue operando.

3. Necesitamos darnos una idea de la cantidad de personas que requerimos para poder ejecutar el proyecto. Si para un proyecto vamos a necesitar contratar y/o entrenar desarrolladores, sería bueno poder decirle al área de RH si estamos hablando de 1, 5 o 10 personas. Digo, después de todo los desarrolladores no caen de los árboles.

Aquí la clave es el entendimiento de la palabra ESTIMAR. Estimar != exacto. Es simplemente una aproximación que nos permite no estar en la obscuridad y entonces poder tomar decisiones.

Imagen de luxspes

una lucecita en la oscuridad

Antes que nada, #yoconfieso que aunque sí lei todo el post original, ya no leí todos los comentarios, estaban kilométricos.

Te recomiendo leerlos, la anecdota de la lavadora de Ezamudio (y la conversacion subsecuente) tocan temas muy interesantes

Así que me atengo a la pregunta original de "¿por qué estimamos?" corriendo el riesgo de que alguien más ya puso lo mismo en comentarios.
A mi juicio, estas son las razones principales para estimar:

A ver...

1. Necesitamos saber con anticipación si es costeable hacer un proyecto o no. Así como proyectamos el beneficio de realizar un proyecto (nos ahorrará X dinero al año, generará ventas por Y), entonces deberíamos ser capaces de tener una idea de cuanto cuesta hacerlo. Si no, corremos el riesgo de que el costo sea mayor que el beneficio.

Es una de las razones tipicas para estimar, coincido. Pero hay un error en esta "razon": Cuando el cliente pide estimar, el generalmente ya tiene una idea en la cabeza, donde lo mas claro es el tiempo y el dinero y muy raro (y maravilloso, he encontrado algunos) es el cliente que en verdad sabe lo que quiere (en cuanto a funcionalidad) y su duda es cuanto cuesta/tarda lo que quiere...

La mayoría tiene una idea muy indefinida de como va funcionar lo que quiere (me ha pasado lo mismo con sistemas para la tiendita de la esquina que con sistemas para multinacionales) ... y si no sabe como va a funcionar, pues es muy dificil saber cuanto cuesta y cuanto tarda construirlo... mas bien lo que quiere es escuchar un ejemplo de lo que puedes construir en el tiempo y presupuesto ya establecidos (cosa que a veces para acabar de complicar el asunto aunque lo saben, no te lo quieren decir) , y comprar eso con su imagen mental... y si eso los lleva por una dirección que les agrada, te compran la idea.

2. Necesitamos coordinar la interacción con el resto de la operación de la empresa. Si estás haciendo un producto de software para un startup, donde el producto es el negocio en si, no importa nada más; es decir, mientras no tengas el producto de software no hay empresa, ni clientes, ni ingresos, ni soporte, ni nada.

De acuerdo...

Pero en los proyectos de TI empresariales, que típicamente están orientados a mejorar/cambiar la operación del negocio, necesitamos empatar la liberación de un sistema de software con el resto de la operación de la empresa; esto puede incluir interacción con otros sistemas que se están desarrollando en paralelo (o que se van a reemplazar), ejercicio del presupuesto en el periodo fiscal adecuado, contratación, liberación o capacitación de personal, etcétera. El reto de los proyectos de software empresarial no es el software en sí, sino el construirlo y desplegarlo mientras el negocio sigue operando.

Exacto, aqui es donde de nuevo, la tipica idea de "te voya decir cuando termino" no fuciona, el cliente ya tiene deadlines que tiene que cumplir, fechas en las que tiene que presentar "algo". De nuevo, no puedes saber si eso que quiere el cliente puede estar en esa fecha, por que el cliente mismo ( con sus maravillosas excepciones) no tiene claridad de lo que quiere. Y tampoco puedes pasar 3 meses analizando que podria querer, por que para cuando termines, tendras una definicion, quiza muy precisa, de lo que podria haber querido hace 3 meses, pero no de lo que quiere (o necesita ahora). ¿Que hay que hacer?

Suponer! Probar! Sirve? Adelante! No sirve? VUELTA! Suponer otra cosa! Probar! Sirve? Adelante! OTRA VUELTA! RAPIDO!

3. Necesitamos darnos una idea de la cantidad de personas que requerimos para poder ejecutar el proyecto. Si para un proyecto vamos a necesitar contratar y/o entrenar desarrolladores, sería bueno poder decirle al área de RH si estamos hablando de 1, 5 o 10 personas. Digo, después de todo los desarrolladores no caen de los árboles.

Ciertamente un aspecto clave!

Aquí la clave es el entendimiento de la palabra ESTIMAR. Estimar != exacto.

De acuerdo, sin embargo, como describo en la parte 2. Si bien no es exacto en cuanto a que puedes construir (el sistema deberá implementar todas la reglas de negocio relevantes para el proceso de negocio a automatizar), si debes ser de lo mas exacto en cuanto a tus limites y los puntos en los que debes recibir información del cliente (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 5 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) ¿Por que?

Por que el cliente no sabe lo que quiere, lo que quiere es saber hasta donde puedes llegar, quiere escuchar un compromiso de tu parte "yo puedo poner 4 paredes en 4 semanas" y con base en eso, decidir de cuantas habitaciones te encarga la casa

Es simplemente una aproximación que nos permite no estar en la obscuridad y entonces poder tomar decisiones.

Cierto, aunque tambien es importante recordar que si bien nos saca de la oscuridad, es solo una lucecita, que no nos permite ver muy lejos, que nos permite empezar a caminar, pero que si nos olvidamos de sus limites y empezamos a correr, puede llevarnos a una situaicion en la que vayamos corriendo hacia un barranco demasiado rapido para detenernos: De ahi la importancia del proceso iterativo, que actua como una revision constante de si vamos por camino firme

Imagen de rodrigo salado anaya

¿Por qué las cebras atraviesan un rio lleno de cocodrilos?

¿Por qué estimamos?, yo creo que como simios mayores estimamos por que es algo que evolutivamente nos a salido muy bien (conste que no digo que otras ramas de la evolución no lo hagan!). Lo interesante es la forma en como lo hacemos, esa capacidad que tenemos para tratar de manipular nuestro presente para dar forma a cosas futuras es impresionante.

Creo que cuando estimamos creamos una ficha que encaja en un rompecabezas que tiene diferentes formas en diferentes cabezas, ya sea de algún cliente o de nuestro equipo (un rompecabezas muy david lynch-esco).

Estaría padre hacer un árbol donde se vieran todas las ramas en las que se apoya una estimación.

Otro punto que me gusto que se tocara en los comentarios es el psicológico y me gustaría que se tocara más a fondo,. Cuando se habla de estimación el tema psicológico tiene un peso muy importante puede cambiar el curso total de un proyecto, para bien o para mal (ó algo diferente no me cierro a ideas nuevas).

Me gusta pensar que la analogía de “tenemos una maquina en la cabeza” es solo eso, somos muy diferentes a una maquina en muchisisisismos sentidos pero la palabra estimación luego luego me trae la idea que ya existe un modelo donde yo puedo meter valores y me da un resultado o en este caso una “estimación”

: )

Imagen de ezamudio

Estimaciones

Dilbert, en cuanto a estimaciones http://search.dilbert.com/comic/Estimate

Me gusta en particular el último: you're the kind of guy who will remove useful qualifiers and distribute a figure as if it is true in all cases.

Cuántas veces no hemos estado en ese caso? Te preguntan "oye para cuándo puede estar esto?" y la respuesta es "pues puede estar para el viernes, SIEMPRE Y CUANDO se cumplan las condiciones A, B y C, y lo que te pregunté la semana pasada de que si esto era X o Z, me lo contestes ahorita y sea X. Si es Z entonces tardará una semana más". Y llega el viernes y no te dijeron si era X o Z, o no se cumplieron todas las condiciones A, B y C, pero eso sí... "qué? no que estaba para hoy?"

Imagen de luxspes

Lo que sustenta una estimacion

Estaría padre hacer un árbol donde se vieran todas las ramas en las que se apoya una estimación.

Exacto! Una estimación se apoya en ramas (supuestos). Y estos deben ser visibles, un diagrama así es muy buena idea.

la palabra estimación luego luego me trae la idea que ya existe un modelo donde yo puedo meter valores y me da un resultado o en este caso una “estimación”

En cierto sentido si lo hay, existen inclusive empresas como QSM o Galorath que venden productos que lo hacen, inclusive hay empresas que se dedican a recopilar informacion para esos proposito (como el ISBSG). Desafortunadamente, ambas son herramientas muy caras... y supongo que ademas no tan populares, debido precisamente a que (en mi opinion) la gente las utiliza mal:

Analista: Necesito que por favor me des toda esta informacion para alimentarla en mi herramienta y predecir cuanto tardara el proyecto.
Cliente: Mmm, lo siento, pero no cuento mas que con respuestas para 15 de las 60 preguntas que tienes y necesito la estimacion para dentro de 4 horas
Analista: Pero, recopilar lo que falta llevara 2 meses...

Y con eso basta para mandar a la basura a la herramienta.

La solucion esta en los supuestos ¿te faltan 45 datos? SUPONLOS y haz EXPLICITA tu suposicion, que al cliente le quede claro por que concluiste lo que concluiste, y que necesitarias para ajustar mas a su realidad (pero no para ser mas preciso, preciso eres, pero bajo los supuestos establecidos). Y si asi decide ir adelante con el proyecto, no habra luego sustento para recriminaciones del tipo: "Tu me dijiste que si podias", por que siempre podras contestar "si, yo te dije eso, pero quedamos que solo si se cumplia X, Y y Z de tu parte, y nada de eso se cumplio, yo con gusto me ajusto, pero a diferentes supuestos, diferentes tiempos y costos.

Imagen de luxspes

Dilbert: cualquier similitud con la realidad no es coincidencia

El de http://dilbert.com/strips/comic/2010-04-19/ fue la que te aplicaron los tecnicos de la lavadora (claro que ni te preguntaron, se fueron por default por la opcion que te hiciera mas feliz en el corto plazo). ;-)

Me gusta en particular el último: you're the kind of guy who will remove useful qualifiers and distribute a figure as if it is true in all cases.

A mi tambien, muy adhoc a lo que trato de exponer aqui, lo malo no es sustentar el estimado en suposiciones, lo malo es presentar el estimado, y olvidar el contexto (las suposiciones) que lo sustentan.

Cuántas veces no hemos estado en ese caso? Te preguntan "oye para cuándo puede estar esto?" y la respuesta es "pues puede estar para el viernes, SIEMPRE Y CUANDO se cumplan las condiciones A, B y C, y lo que te pregunté la semana pasada de que si esto era X o Z, me lo contestes ahorita y sea X. Si es Z entonces tardará una semana más". Y llega el viernes y no te dijeron si era X o Z, o no se cumplieron todas las condiciones A, B y C, pero eso sí... "qué? no que estaba para hoy?"

La historia de mi vida... a las palabras de las lleva el viento... pero papelito habla, los supuestos siempre deben quedar claramente asentados y ser visibles para todos.

Imagen de ezamudio

PSP y TSP

De hecho PSP y TSP se jactan de ser las metodologías que ofrecen los estimados más exactos, abarcando tamaño, tiempo y calidad del software desarrollado. Todo basado en estadísticas, pero el precio de esto es altísimo: el overhead de estas metodologías es gigantesco, al grado de requerir gente dedicada únicamente a llevar el proceso, sin aportar nada directamente al proyecto más que ser una especie de capataz para estar contínuamente recordándole a todos los integrantes (especialmente los programadores por supuesto) que deben de llenar sus formatos de PSP/TSP (que son varios), tomar sus tiempos de la forma más estricta posible, etc.

A cambio de todo eso, se convierte precisamente es lo que Rodrigo dice: un modelo donde se meten valores y da un resultado. En PSP/TSP, se meten valores contínuamente: un montón de datos acerca del tiempo que cada programador se tardó en codificar algo, el tiempo que tomó compilarlo, el número de errores encontrados en compilación, el tiempo que tomó corregirlos, el tiempo en volver a compilar, número de errores encontrados en la siguiente iteración, etc. Al final se tienen datos muy exactos: el número de líneas de código generadas, el tiempo que tomó generarlas, el número de defectos encontrados en ese código, el tiempo que tomó corregirlos, etc. Y con eso se pueden hacer estimados muy exactos del tamaño que va a tener un sistema (en líneas de código), el tiempo que va a tomar (puede llegar al grado de tener una precisión en minutos), e incluso la cantidad de defectos que va a contener. Si al cliente no le molesta que simplemente hacer un estimado tome muchísimo tiempo y que se le cobre porque es bastante trabajo, y que el desarrollo se tarde bastante más de lo normal porque los programadores pasan una buena parte de su tiempo tomándose el tiempo que se tardan en hacer las cosas, y luego hay personal dedicado a compilar todos esos datos para estar actualizando la estadística individual y ajustar constantemente la estimación y compararla contra los cálculos iniciales... y... y...

Pero eso... también es otra discusión.

Imagen de luxspes

IFPUG, COSMIC, MARK

Hay varias metodologias de estimacion, y te piden recopilar diferentes datos dependiendo de la que uses.

TSP y PSP van un poco mas alla, buscando mas bien ser "proceso" para llevar el dia a dia de tu actividad. Por eso prefiero a IFPUG, COSMIC o MARK, que si bien te piden recopilar una cantidad importante de datos, te dejan hacer las cosas, hasta cierto punto, como te de la gana (siempre que juntes los datos que necesitan).

Una diferencia importante, es que el ISBSG ya tiene miles de proyectos cuya informacion se registro mediante metodologias como IFPUG, COSMIC o MARK, asi que si necesitas hacer una prediccion, y no tienes datos de como se comporta tu empresa en particular, puedes usar estos datos para dar estimados de acuerdo con el "estandar de la industria". (Por supuesto, para tener resultados mas apegados a tu realidad, nada como hacer tu propia recopilacion, pero eso puede tomar, literalmente: años)

Mas adelante les hablare de COSMIC, en mi opinon, el metodo de estimacion al que le yo le veo mas utilidad hoy y en el futuro