Desarrollo de Software: Aprendiendo de la Experiencia

Hace unos meses leí este post de @paulstovell:

Five years at Readify

donde comenta sobre sus cinco años de trabajo en Readify, consultora australiana especializada en tecnologías Microsoft y .NET. En estos días Stovell ha dejado la compañía: http://www.paulstovell.com/last-day-at-readify donde declara “I wouldn’t be half the developer I am today if it weren’t for Readify, and I am sincerely thankful for the opportunities Readify has given me.”

Stovell enumera lo que ha aprendido en ese lugar. Déjenme poner en mis palabras lo que enumera:

Comunicación, comunicación, comunicación

Como desarrolladores de software tendemos a pensar que todo empieza y termina en código. Pero las aplicaciones son para personas. Y trabajamos con otras personas. El comunicar lo que hacemos, lo que hicimos, las alternativas que tenemos por delante, los riesgos, las oportunidades, todo influye en el día a día de trabajo, de convivencia y de desarrollo de proyecto. El comunicar nuestros bloqueos y avances, al cliente y al equipo, debe convertirse en algo natural. Y hay que aprender a comunicar: no sólo con palabras sino con imágenes, énfasis, síntesis y nivel de detalle adecuado.

Trabaje sobre la disonancia cognitiva

Según la wikipedia:

Cognitive dissonance is an uncomfortable feeling caused by holding conflicting ideas simultaneously. The theory of cognitive dissonance proposes that people have a motivational drive to reduce dissonance. They do this by changing their attitudes, beliefs, and actions.

Si pensamos que no entendimos algo del cliente o percibimos que él no entendió algo de lo que comunicamos, no hay que quedarse con esa impresión: hay que preguntar, confirmar que estamos alineados en el tema.

Exprese las expectativas, luego, expréselas de nuevo

Muchos de los problemas y soluciones de la vida salen de: poner las expectativas correctas. Si el cliente tiene diferentes ideas de lo que vamos a entregar, hay que corregir esa diferencia. Hay que poner claro lo que se va a trabajar y cuáles son los resultados esperados. Como es difícil hacer esto de una vez para siempre se trabaja en iteraciones con reuniones de revisión y comunicación casi continua de los avances.

Asuma las mejores intenciones

Cuando alguien hace algo puede que tenga otra información y contexto que nosotros. No hay que asumir que esa persona está haciendo “algo mal” sino tomarse el tiempo para entender su situación y sus motivaciones. Tal vez no conozca otra forma “mejor” de hacer algo o no se siente con confianza para tomar el camino recomendado. O tal vez, su forma de hacerlo es lo mejor para la situación. Pero la idea es: hay que esforzarse en entender las acciones de los otros.

Respetar al cliente

Siendo apasionados de la programación tendemos a saber todo de todo. Hay que respetar al cliente en su conocimiento y experiencia en su negocio. El debe saber más que nosotros sobre el tema. Tomémoslo como una oportunidad para aprender.

Entregar es la clave de la confianza

Ya no importan los sacos, corbatas, portafolios y reuniones en salas impresionantes. Ni los pasados éxitos o lo buenos que somos. Lo que genera confianza, con los clientes, con nuestros compañeros de trabajo, es: entregar. Entregar lo prometido. Y compromenterse a entregar lo que realmente podemos entregar (de nuevo, una cuestión de poner las expectativas correctas). Pero entregar. Nadie quiere pagar por humo.

El sobretiempo nunca es la solución

Yo diría más: trabajar sobretiempo es señal de ser “junior”. Es que pusimos las expectativas incorrectas, planeamos mal, asignamos incorrectamente el tiempo, tuvimos distracciones o no informamos bloqueos. No hay que trabajar sobretiempo. Es señal de haber hecho mal algo y hay que luchar contra eso. Y en general, el trabajo de sobretiempo es de menor calidad. Hay que trabajar en estado normal. Y aprender a ser más efectivos en el uso de nuestro tiempo. Mejorar como profesional se deriva en: no más sobretiempos.

Cuando no se conoce algo, decirlo

En tiempos de tantos cambios en tecnologías, frameworks, patrones, procesos de desarrollo, etc.. es muy fácil encontrarse con algo que no conocemos. Hay que conocer lo que sabemos, y reconocer lo que NO sabemos. Y si hay que trabajar en algo en lo que no tenemos experiencia, decirlo. Tomarlo como una oportunidad de aprendizaje y no como un problema que paraliza.

Pida ayuda

Si estamos bloqueados en algo, tratar de solucionarlo pero si no podemos, pedir ayuda. No somos El Superhéroe Solitario. Puede ser un bloqueo técnico o un problema de comunicación con el cliente. Reconocer los problemas y solucionarlos es lo importante. Y si la solución es: pedir ayuda, entonces buscar esa solución.

Y busquen trabajar en una empresa que les enseñe todo esto que Stovell aprendió.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

This entry was posted in 10549, 3463. Bookmark the permalink.

One Response to Desarrollo de Software: Aprendiendo de la Experiencia

  1. Román Mussi says:

    Muy muy bueno Angel. Gracias por compartir.
    Saludos!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>