pizarronComo programador, no te va a salir todo bien todo el tiempo, y no siempre vas a entregar a tiempo lo prometido. Quizás subestimaste. Quizás no entendiste los requerimientos. Quizás el framework que elegiste no era el indicado. Quizás supusiste cosas en vez de recolectar datos. Si probás cosas nuevas, hay probabilidad de que falles de vez en cuando. Sin probar, no aprendés. Y sin aprender, no podés ser efectivo.

Es importante ser honesto con uno mismo y con el cliente, y tomar los errores como oportunidades para mejorar. Cuanto antes todos sepan el verdadero estado de las cosas, antes vos y tus colegas van a poder llevar adelante acciones y ayudar al cliente a obtener el software que realmente quería. Esta idea de feedback frecuente y ajustes es el corazón de los métodos ágiles.

También es una idea útil para aplicar a nuestra propia práctica profesional, sin importar del enfoque que use el equipo de desarrollo.

Se necesita coraje para admitir que algo no está funcionando. Muchas organizaciones fomentan a que las personas digan las cosas de forma hiper-positiva e irreal, en vez de ser honestas. Esto es contraproducente. Decirle a las personas lo que quieren oir tan sólo sirve para retrasar el inevitable momento de enterarse que no obtendrán lo que esperan. Además le negamos la oportunidad de reaccionar a la información.

Por ejemplo, quizás una característica sólo sirva implementarla si su costo es igual al estimado original; por lo tanto, sería beneficioso para el cliente cambiar el alcance. Admitir que la característica no va a estar a tiempo le da al cliente el poder de tomar esta decisión. Al ocultar el problema dejamos este poder del lado del equipo de desarrollo - y ese es el lugar equivocado.

La mayoría de las personas prefieren que se cumplan sus expectativas en vez de obtener todo lo que piden. Al recibir malas noticias los clientes pueden sentirse traicionados. Podemos manejar esta situación ofreciendo alternativas, pero sólo si creemos que son realistas.

No ser honestos sobre nuestros errores nos cierra las puertas para aprender y reflexionar sobre qué podríamos haber hecho mejor. Allí tenemos una oportunidad para mejorar nuestra estimación o habilidades técnicas.

Podemos aplicar esta idea a cosas importantes como reuniones de parado y retrospectiva de iteración, y también a cosas pequeñas, como hacer que alguien revise el código que escribimos ayer y darnos cuenta que no era tan bueno como creíamos, o admitir que no sabemos la respuesta cuando alguien nos hace una pregunta.

Para hacer que las personas admitan sus errores se necesita que la organización no penalice las fallas y a las personas que están dispuestas a admitir y aprender de sus errores. Aunque no siempre podemos controlar a la organización, siempre podemos cambiar la forma en la que encaramos el trabajo, y cómo trabajamos con nuestros colegas.

Los errores son inevitables. Admitirlos y aprender de ellos nos brinda mucho valor. Por otro lado, negar los errores significa que hemos perdido el tiempo.

Traducido de Acknowledge (and learn from) failures, por Steve Berczuk.

Inspiración.

"Si tú tienes una manzana y yo tengo una manzana e intercambiamos las manzanas, entonces tanto tú como yo seguiremos teniendo una manzana cada uno. Pero si tú tienes una idea y yo tengo una idea, e intercambiamos las ideas, entonces ambos tendremos dos ideas"

Bernard Shaw