Comunicación con No Ingenieros

Este artículo fue publicado originalmente el 15 de junio 2016 en eng.lyft.com.

Como Release Manager (gestionador de entregas de software), veo muchas de las conversaciones que ocurren entre ingeniería y otros departamentos. Puedo relacionarme con ambos lados. Cuando me uní a Lyft, creía que petición (request) y respuesta (response) sólo eran verbos utilizados en vez de escribir la palabra “decir" (said) demasiadas veces. Viniendo de un entorno fuera de las Ciencias de la Computación, he sentido qué tan intimidante puede ser trabajar con un desarrollador y no comprender cada quinta palabra que está diciendo. Desde que formo parte de ingeniería hace ya año y medio, también me he dado cuenta qué difícil resulta comunicar en qué estás trabajando.

Comencemos con algunos ejemplos de una variación que todo ingeniero ha escrito en cierto momento:

Mi PR no ha sido unido en GitHub, los cambios no se reflejarán en master.

Preguntas que un no ingeniero tiene:

¿Por qué ya estamos hablando con los de PR (relaciones públicas) sobre esto?

Creo que has escrito “git” en vez de “get”.

O qué tal:

La causa es una respuesta 500 que viene de una llamada HTTP a Stripe.

Esto puede encaminar a muchas preguntas:

500 es un número grande. ¿Debería preocuparme?

¿Stripe? Relacionado con pagos. Probablemente.

Http, ¿como un sitio web?

Y, una conclusión confusa:

Algo está siendo causado por un número grande en un sitio web que podría estar relacionado con los pagos.

Entonces, ¿qué puedes hacer para que la otra persona no esté buscando desesperadamente en Google frases de tu correo?

Tengo tres consejos para tener en mente que te ayudarán a navegar conversaciones en tu compañía. Si tu trabajo no interactúa con múltiples equipos, estos consejos podrían ayudarte a hablar con la familia, tus primeras citas o esa cierta persona en tu vida que aún tiene su correo de AOL.

Baja el ritmo.

Es importante tener esto en cuenta independientemente de cuál sea tu trabajo. Existe un equilibrio entre simplificar las cosas y la necesidad de mantenerse exacto y preciso, pero basta con elegir diferentes palabras para ayudar. La manera más fácil de comenzar a hacerlo es cortando los acrónimos, jerga y palabras técnicas. Al final del día, se trata de traducir tus pensamientos a un lenguaje común que tenga sentido.

Benoit Hediard publicó uno de mis diagramas preferidos que explica claramente un tema de ingeniería. Utiliza imágenes para expresar relaciones y, si miras de nuevo el diagrama, notarás que no se usa ninguna jerga o vocabulario complejo para expresar el punto. (Como nota adicional, estaré personalmente emocionada cuando logremos la "arquitectura de pizza".)

Toda persona que se encuentra en tu compañía es experta en algo; son tan capaces de escupir alguna terminología oscura como tú. Imagina que estuvieras en sus zapatos y tuvieras que explicar un detalle de su trabajo.

Piensa en el acceso.

El segundo consejo es considerar el nivel de acceso que otros equipo tienen. Pedirle a un compañero del equipo de soporte que busque algo en MongoDB podría no llevarte muy lejos. También considera que diferentes equipos de soporte tienen distintos accesos a datos. Por ejemplo, los equipos de riesgo y fraude tendrán más información accesible en la punta de los dedos que un equipo de soporte estándar. Una buena manera de aprender esto es observar a alguien en un equipo diferente al tuyo en tu compañía mientras realiza sus tareas; tendrás la oportunidad de ver cómo usan las herramientas y las maneras de mejorarlas.

Si el proyecto en el que están trabajando juntos tiene múltiples componentes, sé el puente que ayuda a conectar a otras personas. Por ejemplo, ¿deberían el diseñador y el redactor hablar entre ellos y no a través de alguien más? Este es otro tipo de acceso: acceso social. ¿Hay alguien que necesita conocer a otra persona y tú puedas facilitarlo? ¿Hay alguien más informado sobre el proyecto con quien podrían estar hablando?

Escucha.

Le pregunté a un amiga de nuestro equipo de Driver Operations (equipo de operaciones dedicado a los conductores) qué ingenieros son buenos comunicadores y por qué. Ella dijo: “Se trata menos de que sean buenos para explicarme cosas técnicas, aunque son buenos para eso, son buenos para escuchar que yo no hablo de manera técnica y para traducir sus palabras de una manera accesible.” Me acerqué a uno de los ingenieros que ella destacó durante nuestra conversación para averiguar qué hace. Me dijo que siempre le gusta preguntar primero a la otra persona si está familiarizada con la tecnología. Esta es una buena recomendación porque sabrás en qué nivel necesitas hablar y te dará pistas para saber qué vocabulario utilizar durante la conversación. Esto, claro, nos regresa al primer consejo.

Un truco que encontré útil en mi vida pasada como maestra era que la otra persona repitiera lo que aprendió de ti. Esto te ayudará a asegurarte de que entendieron lo que estaba siendo comunicado y te ayuda a comprender lo que puedes explicar mejor la próxima vez.

Volvamos a uno de los ejemplos con los que comenzamos:

Mi PR no ha sido unido en GitHub, los cambios no se reflejarán en master.

Y ajustémoslo un poco para que sea:

Los cambios para solucionar el error de la aplicación no están aún en vivo. Publica aquí si en media hora el problema continua.

Por lo tanto, recuerda: baja el ritmo, piensa en el acceso y escucha lo que dice la otra persona.

¡Lyft está contratando ingenieros de software increíbles de todos los orígenes! Revisa nuestra página de vacantes para más información.