style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">

Estimacion: Negociacion y la diferencia entre hacer lo correcto vs Hacerlo correctamente (Parte 4)

En ingles hay un dicho: There is a difference betwee doing the right thing and doing the thing right.
La traduccion directa seria algo asi como hay una diferencia entre hacer lo correcto y hacerlo correctamente.

En la estimacion de software, y el proceso de negociacion que es necesario para que una consultora le
construya software a un cliente la diferencia entre una cosa y la otra es tremendamente importante.

Para "Hacer lo correcto" debemos entender claramente que es lo que el cliente realmente necesita (independietemente de lo que pida), en cambio, para "Hacerlo correctamente", no es relevante si lo que hagamos realmente le va a servir al cliente o no,lo que es importante es si lo que hicimos esta bien construido.

Un ejemplo extremo:

Un cliente viene y te describe un vehiculo monoplaza de transporte, que le permita viajar a donde quiera. Tu le de construyes una bicicleta, el pensaba usar el vehiculo en alaska, en la nieve, buscaba: una motonieve.

Finalmente, no importa que te tan bien hayas construido la bicicleta (hecha correctamente) al cliente no le sirve, por que lo que el necesitaba (hacer lo correcto) era que le construyeras una motonieve.

En el proceso de negociación llevado a cabo durante la construcción de software, la diferencia entre "hacer lo correcto" y "hacerlo correctamente" tiene una particularidad importante: Quien tiene la información requerida para alcanzar un objetivo, o el otro cambia drasticamente.

Para "hacerlo correctamente", todo el conocimiento esta en la consultora que construye el software, en los tecnicos, en los desarrolladores, en los diseñadores, que si son buenos, haran las pantallas mas usables, y usaran la mejor arquitectura y los mejores algoritmos, apegandose estrictamente a una proceso que ayude a garantizar un producto bien construido.

En cambio, para "hacer lo correcto", la información esta en el cliente. Solo el puede, aunque a menudo no al principio del desarrollo del software, dictaminar si lo que se le esta construyendo es finalmente lo que necesita. Si, y solo si el cliente esta dispuesto a pasar por este proceso de autodescubirmiento, en el cual sus supuestos serán examinados cuidadosamente, podrá finalmente concluir, si esa idea nebulosa en su cabeza, es realmente lo que necesita, o si mas bien, tendria que haber pedido otra cosa desde el principio.

Por supuesto, la consultora, con sus analistas, des arrolladores, arquitectos, testers, etc, debe buscar facilitar el dialogo con el cliente, y ayudarle a entrar pronto en el ciclo de suponer, implementar, validar y volver a suponer, hasta llegar a construir "lo correcto", pero es importante recordar, que finalmente la información proviene del cliente, no de la consultora, y si el cliente, por alguna problemática de su cultura organizacional, no esta dispuesto a invertir el tiempo que se requiere para definir claramente "lo correcto", la consultora no podrá construirlo (se puede llevar al abrevadero al caballo, pero no se le puede obligar a beber)

Hay un oracion que dice "Dios, concédeme la serenidad para aceptar las cosas que no puedo cambiar, el valor para cambiar las cosas que puedo cambiar y la sabiduría para conocer la diferencia". Bueno, en este caso, tenemos que tener muy clara la diferencia: Solo el cliente tiene el poder para ayudarnos a construir "lo correcto", la consultora no es mas que un facilitador, es muy importante recordar esto, por que cuando estemos construyendo la propuesta, debemos asegurarnos que ayude a construir "lo correcto", pero al mismo tiempo, nuestra responsabilidad no debe llegar mas alla de "hacerlo correctamente".

Yo he tenido que lidiar con multinacionales, que me dan apenas unas horas para preparar propuesta de desarrollo de meses. Es absurda la cantidad de esfuerzo que se desperdicia en desarrollos de ese tipo, y sin embargo, de nada me ha valido insistir en que 3 a 6 horas no son suficientes para estimar un proyecto de 3 o 6 meses de duración, hay demasiado que se queda sin especificar. Al principio, cuando me enfrentaba con esta situación, mi actitud era de "no se puede", "evita suponer", "pídele al cliente la información que falta, o si no, no hagas nada". Suena muy bonito, desde una perspectiva abstracta, pero esa actitud no paga las cuentas... así que la cambie.

Sigo diciéndole al cliente siempre que puedo, que el tiempo que me esta dando no es suficiente, y que es muy riesgoso hacer un proyecto con tan poco tiempo para planear, pero una vez que el cliente me indica que mis advertencias están siendo tiradas en saco roto, cambio inmediatamente de estrategia: A este cliente no le interesa que "le construya lo correcto", lo que le interesa es que le construyan algo que "se aproxime lo mas que se pueda a eso" y mas me vale "construirlo correctamente", por que al final, si la aproximacion no es lo suficientemente cercana a lo que el cliente se da cuenta que necesitaba recibir (unos minutos después de haberlo recibido), vendrán las recriminaciones e intentos de penalizacion.

Afortunadamente, "lo correcto" es subjetivo, mientras que "hacerlo correctamente" es completamente objetivo. Si tu necesitabas una motonieve, y yo te construí una bicicleta, y de los muy acotados supuestos de la propuesta son cumplidos por la bicicleta, no habrá forma de que me penalices, o que te niegues a pagarme, y en caso de demanda, al final, perderás, por que estaré cumpliendo con el contrato.

El manifiesto agil dice "Customer collaboration over contract negotiation" esa es otra forma de decir "prefiere hacer lo correcto que hacerlo correctamente", pero el manifiesto agil aclara: "while there is value in the items on the right, we value the items on the left more", es lo mismo con "hacer lo correcto" vs "hacerlo correctamente", ambos son valiosos, y ciertamente lo mejor seria hacer ambos, "lo correcto, correctamente", pero debemos tener la sabiduría para conocer la diferencia entre lo que podemos cambiar... lo que esta en nuestras manos, y lo que es un esfuerzo compartido, y que si la otra parte de plano se niega a cooperar, no sera posible alcanzar.

Es muy importante hacer esto con la cabeza fria, y una actitud entusiasta y alegre. Si un cliente de por si es dificil, y ademas lo tratamos con rudeza, no llegaremos a ninguna parte, puede mas el calor de la amabilidad que el frio de la agresividad . Hasta donde sea posible, debemos buscar terreno común, hacer empata con el cliente, y salir juntos adelante, pero también debemos tener bien dibujados los limites, de forma que si se las cosas se salen de control, podamos cortar por lo sano, sin perdidas irreparables para la continuidad de nuestro negocio, de lo contrario, caeríamos en el síndrome de estolcomo...

No se pierdan los siguientes episodios de esta emocionante sobe la estimación, en donde veremos diferentes ejemplos de situaciones reales a las que pueden llegar a enfrentarse, y como pueden salir victoriosos de ellas...

Update: Me encontre este articulo en InfoQ, que veo muy relacionado con el tema que aquí expongo y me encantó este ejemplo, por lo que aprovecho para compartirlo con Uds:

La gente compra un martillo para clavar un clave para poder colgar un cuadro - ellos saben que pueden conseguir su objetivo (colgar el cuadro) con la adquisición del martillo.

Desafortunadamente, en el contexto del desarrollo de software las cosas no son tan directas entre lo que se te entrega (el software) y el objetivo de negocios que se desea alcanzar. Muchas personas ni siquiera intentan alcanzar el objetivo de negocios. Esto crea un gran riesgo de que el proveedor solo entregue lo que el cliente pidió - un software que satisface un conjunto vago de requerimientos - en vez de lo que el cliente realmente necesita, que es alcanzar su objetivo de negocios

Desafortunadamente, son los mismo clientes los que le dicen al proveedor: Haz exactamente lo que te pedí, apegate al contrato, hazlo correctamente, yo ya decidí previamente que eso era lo correcto... sin darse cuenta del daño que se están haciendo a si mismos. Como proveedores tenemos la responsabilidad de preguntar: ¿por que quieres que te fabrique un martillo? pero si finalmente el cliente se niega a explicarnos el proposito, debemos aceptar que el cliente es el finalmente responsable de su propio bienestar, y fabricarle su martillo, aun si su plan es golpearse con el... imagínense si los fabricantes de cuchillos se la pasaran estresandose por que "que tal si alguien se corta un dedo", o los de las estufas por "que tal si alguien se quema", prácticamente todas
las industrias se acabarían, ya que no hay un limite al mal uso que puede darsele a las cosas...

Los clientes no son niños, y si bien debemos advertirles claramente de las consecuencias de sus actos, la responsabilidad de sus acciones recae sobre ellos.

En la siguiente parte de esta serie, hablare sobre tecnicas para lidiar con peticiones (o exigencias) de desempeño, en situaciones en las que aparentemente no se cuenta con informacion contextual suficiente

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 neko069

Es muy importante hacer esto

Es muy importante hacer esto con la cabeza fria, y una actitud entusiasta y alegre. Si un cliente de por si es dificil, y ademas lo tratamos con rudeza, no llegaremos a ninguna parte, puede mas el calor de la amabilidad que el frio de la agresividad.

Ésto es lo primero que uno siempre SIEMPRE debería tener en cuenta desde el principio de cualquier actividad, cambia totalmente la perspectiva de lo que se esté haciendo. Gran serie, gracias por compartir tu experiencia.

Imagen de avefenix_x

sindrome de estolcomo...

Muy buen articulo.
Hay muchas un 99.99 de cosas que se presentan en la consultora donde trabajo.
Tengo experiencia de dejar ese sindrome en el que estuve cautivo alguna ves. ahora ya deacuerdo a lo vivido es posible Acercarse a "Hacer lo correcto" y "Hacerlo correctamente" no en su totalidad pero es bueno tener un equilibrio entre las dos actividades.
Saludos.

Imagen de Sr. Negativo

El EGO de las personas

Este tipo de problemas surge por el EGO de las personas. Más que la tecnología, herramientas, tiempo y dinero a invertir.

En los 4 posts de @luxpes hay un patrón común:

lucha de egos

jeje

Quien tiene y quien NO tiene la razón.

Esto se da con muchos profesionistas (ingenieros, abogados,etc.) que creen tener la razón en todo y menosprecian la opinión de los demás.

Todos somos así a veces.

Imagen de karl

Politicamente, negociar y maquiavelo

Muy buen articulo,

En ocasiones he pensado que a veces los managers y negociadores se van al "intento de hacer lo correcto" a la manera maquiavelica de que "el fin justifica los medios" y asi se va al extremo de tener los logros y los objetivos a cualquier costo y a costa de lo que sea... pero como bien mencionas lo correcto es buscar la "Eficiacia y la Eficiencia" es decir "hace lo correcto y hacerlo correctamente", pero como el tema implica buscar el balance, implica la intervención humana, el uso de metodologías y de la administración, vamos a entrar ver que como seres humanos no hemos encontrado la formula magica para que la administración logre sus objetivos ni la administración ni la metodologias perfectas.

Entonces como tambien mencionas nos queda lo que se maneja mucho en metodología agil y en scrum hacer iteraciones para buscar "Acercamientos" a lo "que es correcto..." y como buen ciclo el cliente debera ser parte fundamental para determinar que tanto nos acercamos a su motonieve...

Saludos.

style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">