Crónicas del Buen Programador: Comunicación es Clave

Tener las mejores ideas, el código más elegante y limpio, las mejores prácticas de programación y profesionalismo es completamente inútil a menos que sepamos empaquetar y presentar nuestras ideas y productos a otras personas.

Deficiencias comunicativas tienden a ser un síntoma común en empresas que tienen problemas para entregar productos que mantienen a sus clientes y socios felices.

A continuación una lista de ideas que pueden servir para mejorar e instituir una cultura de buena comunicación en tu equipo.

En mi caso, odio las reuniones, considero que la mayoría de las veces son una pérdida de tiempo, si eres como yo te puede parecer que la gente generalmente dice algo en 100 palabras cuando pudo haberlo dicho en 10 (por ende puede que seas entonces tímido o no tengas mucho que decir en reuniones sociales, nos compadezco). Si este es tu caso, sufres de lo que bautizo en este momento como “impaciencia-social”, tu mente probablemente funciona de forma más abstracta que verbal, y tanto código y pensamiento en optimización te puede estar afectando hasta en la forma de hablar, esperemos que yo sea el único que sufre de este problema.

Debemos estar claros que la mayoría de la gente no puede entender terminología técnica que puede resumir ideas complejas a un manojo de palabras, ejemplo:”Con un manejador de colas expirables procesadas en paralelo aprovecharemos el tiempo de ejecución y el tiempo promedio de los mensajes disminuirá en proporción al número de colas y procesadores”. Trata de explicar eso a un Gerente de proyecto que nunca haya programado un sistema con Hilos o Colas de mensajes (Tip: Asegúrate que el manager sea un “duro” y sepa liderar por ejemplo, a.k.a. que no sólo administre los recursos del proyecto, sino que participe y sepa hablar el mismo idioma, aquí resurge de nuevo el tema de este post, comunicación).

Como desarrollador (queramos o no) estamos constantemente en la necesidad de comunicarnos en diferentes niveles. Nos hacen perder horas en meetings (que pudieran muchas veces resolverse con un parde correos, o en un foro), a algunos nos toca interactuar con usuarios, entender sus necesidades, explicarles cómo funcionan las cosas y educarlos en cómo deben expresar sus problemas con nuestro software.

A otros nos toca escribir propuestas, memos, peticiones de recursos, negocios, o resolver conflictos entre miembros del equipo, reportar el estado del proyecto, documentamos código, creamos manuales, explicando cómo deberían funcionar las cosas, cómo procesos pudieran ser cambiados para funcionar de mejor manera, pasamos gran parte de nuestro tiempo comunicándonos, así que debemos hacerlo bien.

Asegúrate de saber lo que quieres decir

Lamentablemente hay personas que antes de escribir un correo, o un manual empiezan a escribir sin pensar o al menos crear un esqueleto de las ideas que desean expresar.

Planea lo que quieres decir, escribe una lista de las ideas que quieres expresar (a menos que sea una sola cosa), obsérvalas y evalúa si esto será suficiente para hacer que tu punto llegue correctamente. Luego refina esta lista hasta que lo haga, si es posible hasta lee lo que vas a enviar en voz alta y ve si tiene sentido cuando te escuchas a ti mismo.

Este método funciona no sólo a la hora de escribir, es muy efectivo a la hora de hacer reuniones, llamadas, o antes de grabar un video (si te interesa hacer video podcasting por ejemplo).

Conoce tu Audiencia

Sólo logras comunicarte cuando logras enviar información útil. Para hacer esto debes entender las necesidades, intereses y capacidades de tu audiencia. A muchos nos ha ocurrido que en medio de una conversación algún ridículo empieza a hablar sobre algo vagamente relacionado al tema, o de sí mismo, y si analizamos lo que dijo el tipo, perdió 5 minutos auto-adorándose, troleando sobre una tecnología, contando anécdotas que no vienen al caso, además que el meeting estaba lleno de ejecutivos que no tienen la más mínima idea de qué es lo que estaba hablando el tipo. Esto no es comunicar, eso es sólo platicar.

Dependiendo de tu audiencia entrega el mensaje inclusive de diferentes formas. A tus desarrolladores quizás basta con enviar un correo, no hace falta que les hagas un power point y los aburras hasta la muerte. A marketing quizás puedas hablarle en persona, y a un tipo de negocios que lo has visto haciendo presentaciones con diapositivas quizás le convenga un power point con las ideas más interesantes, o un video. Habla su lenguaje.

Por último, revisa tu ortografía (hay personas que pueden dejar de tomar tus ideas en serio de tan sólo ver errores ortográficos) y presenta tus ideas en un formato que enaltezca tus ideas ante ellos.

Elige el momento correcto

Es viernes, son las 5:30pm de la tarde, la hija de tu jefe está enferma y la esposa está llamando por teléfono para que venga a su casa, llueve afuera y posiblemente a todo el mundo le toque una cola interminable en el tráfico para llegar a casa… probablemente no es el momento adecuado de pedirle a tu jefe nuevos monitores y sillas con soporte lumbar para el equipo de desarrollo.

Un manager le acaban de formar un lío porque se perdió el código fuente de un sistema viejo, quizás éste es el momento de empezar a evangelizar el uso de backups automatizados y sistemas de control de revisiones (GIT, Mercurial, SVN), el tipo estará más interesado en ayudarte y tendrás un aliado en tu cruzada evangelizadora.

Envuelve a tu audiencia

Tus ideas no tienen que llegar por sorpresa, puede que logres envolver a los participantes en madurar tus ideas, comparte borradores con ellos, itera, y verás que estarán más interesados a la hora de tu entrega o presentación, además tu idea puede que termine siendo refinada y mejor de tus conceptos originales.

Escucha y Responde

Si quieres que te escuchen debes prestar atención a las personas a quienes quieres hacerles llegar un mensaje, si ven que hay un genuino interés de tu parte estarán más dispuestos a escuchar lo que tienes que decir. Haz que la gente hable, haz preguntas, o hazlos sumarizar lo que acabas de decir para saber que en realidad te entendieron, muchas veces te darás cuenta que entendieron mal lo que intentabas comunicar, asegúrate de que la comunicación sea más un diálogo que un monólogo.

Si te escriben, o te deján mensajes, crea el hábito de siempre responder lo más rápido posible así sea para decir que vas a responder más tarde cuando tengas un poco más de tiempo (esto no quiere decir que tengas respuestas automatizadas para todos tus correos…), es bueno mantener a los participantes “en el loop”, esto ayuda a ganar tiempo, confianza y comprensión, de este modo tendrán seguridad de que estás “escuchándolos” y que no te vas a olvidar de ellos.

Esto es sumamente importante si estás haciendo negocios con terceros (y no tienes muchas ganas de dar respuestas definitivas al momento), esto puede ayudar a crear la ilusión de que son importantes y que entregas tus promesas más rápido que el resto, también ayuda a disminuir un poco la posible ansiedad del otro lado.

Escuchar y responder aplica también a las necesidades de tus usuarios. Generalmente me gusta crear grupos de testers con un ambiente un poco informal, hay gran cantidad de gente en internet dispuesta a probar software alpha o beta, su feedback y la creación de un sentido de comunidad detrás de tu producto puede ayudarte a refinar tus ideas o inclusive cambiar la dirección de tu proyecto antes de salir al mercado. A su vez, comunidades en línea pueden servir para promocionar tus productos de forma orgánica desde antes que estén listos. De nada sirve crear soluciones a problemas que existen sólo en tu mente, una vez más la comunicación, en este caso con tus usuarios, prueba ser de suma importancia para crear productos que tengan sentido de ser y que se adapten a la realidad de tus consumidores.

Mientras seas más efectivo(a) en comunicarte, ya sea con compañeros de trabajo, con tus clientes, con tus socios, con terceros, inclusive considerando cómo tu software se comunica con el usuario, mayor influencia e impacto tendrás en donde sea que te desenvuelvas.

[ad#Google Adsense-468x15ContentLinkunit]

Sobre el Autor

Angel León (aka Gubatron) es un Ingeniero de Software Venezolano (UCAB) que ha desarrollado desde sencillos sistemas con bases de datos relacionales, servicios webs distribuidos para millones de visitantes mensuales, software p2p de uso masivo, hasta aplicaciones para dispositivos mobiles, todo esto empleando gran variedad tecnologías abiertas (Linux, Android, Java, Python, PHP, C++, Javascript).

Estas crónicas son inspiradas en el libro “The Pragmatic Programmer” (un libro que debería ser un texto obligatorio en todo curso de Ingeniería de Software) junto con las experiencias de Angel León durante los últimos 8 años desarrollando software en Venezuela y los Estados Unidos.

[ad#Gubatron-AmazonAd-PPBook-120×240]