¿Por qué la mayoría de los desarrolladores son tan malos en la comunicación?

La mayor parte de mi vida, he estado en “comunicaciones”. He trabajado como escritor, como maestro (para niños y adultos), como orador público y como director de teatro. También soy programador, que actualmente es mi ocupación de tiempo completo. Esto es lo que he aprendido: la mayoría de las personas son malas para comunicarse.

Los programadores con los que trabajo no son peores que el promedio, y algunos de ellos son comunicadores talentosos. Pero comienzan con un par de desventajas: primero, su trabajo implica una gran cantidad de conocimiento especializado, mucho más que la gente en la mayoría de los otros campos. Incluso los médicos pueden explicar aproximadamente lo que están haciendo, porque comparten un contexto común con sus pacientes: los cuerpos humanos. Pero cuando un programador habla con un no programador, no hay casi nada en común con lo que pueda contar.

En segundo lugar, los programadores tienden a necesitar información muy específica para realizar su trabajo. Muchos de sus compañeros de trabajo no tecnológicos pueden sobrevivir (extremadamente bien) con una conversación más generalizada.

Imagine al capitán de un barco pirata diciéndole a su tripulación que “vaya a la isla y desenterre el cofre del tesoro”. La tripulación exigirá saber dónde deben cavar, porque es una isla grande. El capitán, acostumbrado a hacer cosas más amplias, como atacar barcos, se verá tentado a decir: “No sé. Simplemente comienza a cavar …” Entonces se enojará cuando su tripulación tome tres semanas antes de encontrar el tesoro.

Esta diferencia de alcance es una fuente importante de problemas de comunicación entre desarrolladores y no desarrolladores.

Es importante recordar el cliché (verdadero) de que la comunicación es una calle de doble sentido. La cuestión es que siempre sabes lo que quieres decir, y tu forma de expresarlo te parece clara, porque te entiendes perfectamente. Entonces, cuando hay un colapso, siempre se siente como la culpa del otro tipo. He escuchado a muchos desarrolladores quejarse de cómo sus gerentes no se comunican bien, lo que (desde la perspectiva de un programador) generalmente significa que no hay suficiente precisión.

Los problemas de comunicación son solo del 40% basados ​​en “malas habilidades de comunicación”. Se basan aún más en que cada participante tiene información inicial diferente (cada uno sin darse cuenta de que la otra persona no comparte su información) y contextos o marcos diferentes, por ejemplo, una persona piensa que está hablando de “el panorama general” y el otros piensan que están hablando de los detalles.

Además, algunas personas prefieren un estilo de conversación enunciado mientras que otras disfrutan de un estilo negociado. Aquí hay un ejemplo del estilo explicado:

“Voy a tener una fiesta esta noche, y estás invitado. Si vienes a mi casa en metro, toma la estación Eastern Parkway de 2 o 3 trenes. Sal por las escaleras de la izquierda. Si ves un gran edificio de ladrillo en del mismo lado de la calle que tú, saliste por la salida equivocada. Regresa a la estación y toma la otra escalera … ”

Aquí está el estilo negociado:

“Voy a hacer una fiesta y estás invitado. Aquí está mi dirección: …”.

“¡Genial! Estoy emocionado. Probablemente vendré en tren. ¿A qué estación debo ir?”

“Eastern Parkway”.

[Luego. En el telefono.]

“Hola. Estoy en Eastern Parkway. ¿Qué existe debería usar?”

Cualquiera de los estilos es viable, pero no se mezclan bien. Los tipos de negociación pueden escuchar las instrucciones detalladas y pensar: “¡Demasiada información!” Los tipos explicados pueden escuchar la dirección y pensar: “¿Cómo se supone que voy a llegar allí con instrucciones tan vagas?”

Hay toneladas de excepciones, pero muchos desarrolladores son tipos detallados, mientras que muchos de sus compañeros de trabajo son tipos negociados. Como uno de los primeros, a menudo me irrita la cantidad de correos electrónicos que tengo que enviar para obtener la información que necesito. Recibiré un mensaje de un compañero de trabajo que dice: “Cuando hagas eso, por favor tráelo a la reunión”.

¿Que cosa? Que reunión Y si hago esas dos preguntas, generalmente solo obtendré una respuesta: “Me refiero al Proyecto Rojo”.

Luego tendré que enviar otro correo electrónico preguntando de nuevo qué reunión.

Por irritante que sea para mí, otras personas probablemente estén cansadas de mis largos correos electrónicos con instrucciones de varios pasos.

Finalmente, en cualquier conversación, es probable que te confundas si no actualizas constantemente un modelo de lo que la otra persona sabe. Y esto tendrá que estar parcialmente basado en conjeturas.

Por ejemplo, como programador, trabajo con algo llamado “funciones” cada minuto de cada día. Son tan comunes a lo que hago que me cuesta recordar que los no programadores no necesariamente saben qué es una función. Peor aún, algunos de mis compañeros de trabajo no técnicos han trabajado con desarrolladores el tiempo suficiente como para haber aprendido algo de jerga. Entonces, algunos de ellos saben acerca de las funciones, mientras que otros no. Si momentáneamente olvido con quién estoy hablando y qué es probable que sepan, podría poner un poco de jerga en la conversación que no entenderán.

Como alguien que nunca toma un curso de negocios, tengo el problema opuesto cuando mis gerentes comienzan a hablar de ROI y M&A.

Después de haber trabajado con los desarrolladores durante muchos años y haber incursionado un poco en el área, siento que tengo suficiente experiencia para responder a su pregunta. He trabajado con una variedad de desarrolladores, en una variedad de contextos. Principalmente, estoy en el negocio, diseño y gestión de proyectos, dependiendo en gran medida de los desarrolladores para lograr nuestros objetivos comerciales. He trabajado con desarrolladores como empleados, miembros del equipo, contratistas individuales y grupales, y como desarrollador por un breve período de tiempo.

Existe claramente una gran división entre el mundo de los desarrolladores y el de las personas que les solicitan información o trabajo. Los desarrolladores tienen un trabajo muy difícil, y pocas personas en el mundo de los negocios parecen tener una comprensión clara de lo que hacen. Los desarrolladores también son algunas de las personas más inteligentes que conocerá, y han sido más inteligentes que la mayoría de las personas a su alrededor durante la mayor parte de sus vidas.

Pocas personas que solicitan a los desarrolladores tienen una idea clara de lo que están pidiendo. Si bien la característica o funcionalidad puede parecer una tarea simple de 5 minutos para una persona de negocios, puede llevar horas de tiempo de desarrollo real para ejecutarse y puede abrir muchos problemas adicionales en el camino. Muchas personas de negocios no son empáticas con esto, ya que probablemente tienen poca experiencia de desarrollo real.

La desconexión más grande que he visto es cuando las personas tratan a los desarrolladores como un recurso y no como seres humanos. Por alguna razón, muchas personas de negocios tienen la tendencia de hablar con los desarrolladores y hacer demandas en lugar de solicitudes. Además, pocas personas se toman el tiempo para poner sus ideas y características en una hoja de especificaciones bien pensada cuando las solicitan.

Entonces, al final, la persona de negocios se percibe como alguien que piensa que es superior, no valora su tiempo y ni siquiera comprende el costo del tiempo real y las implicaciones posteriores de la característica o funcionalidad que está solicitando. Ahora repita este ciclo durante una década más o menos, y tendrá un desarrollador que no está muy entusiasmado para responderle a tiempo.

Si sigue las siguientes pautas al trabajar con desarrolladores, creo que logrará un resultado diferente:

1. Trátelos como personas y amigos potenciales. Encuentre un terreno común donde pueda relacionarse.

2. Bríndeles especificaciones muy detalladas y asegúrese de que estén bien pensadas. Asegúrese de que las especificaciones sean lo más completas posible y representen exactamente lo que desea.

3. Proporcione las especificaciones en el contexto de una conversación bidireccional, permitiendo al desarrollador una gran cantidad de información y compromiso, asegurando que el tiempo de todos se use de manera efectiva.

4. Tome un curso de Udacity y aprenda algunas habilidades básicas de desarrollo. Intenta escribir un programa simple para que al menos tengas algo de contexto sobre cómo es ser un desarrollador. Empatizarse.

Espero que encuentres esto útil.

Estás haciendo la pregunta equivocada. En lugar de preguntar por qué la mayoría de los desarrolladores son malos para comunicarse, si se pregunta por qué las personas que tienen dificultades para comunicarse con la mayoría de las otras personas se convierten en desarrolladores, la respuesta es clara.

Para tener éxito en un campo técnico como la ingeniería, debe prestar mucha atención a los detalles, pensar lógicamente y expresarse de manera clara y precisa. En otras palabras, debe cultivar casi exactamente lo contrario de las habilidades que lo harán sentir cómodo con las personas: la capacidad de pasar por alto sus errores, cambiar de tema a tema no relacionado a medida que cambian las conversaciones, y seguir las reglas de etiqueta, que a menudo requieren que seas vago, educado o ambos.

Entonces, como cualquier otra persona, muchos desarrolladores tienden a gravitar hacia las personas con las que se sienten cómodos: aquellos que pueden estar más interesados ​​en los hechos que en las sutilezas sociales, y aquellos que están más interesados ​​en una opinión honesta y en encontrar una solución a un problema que en simpatía o encontrar a alguien a quien culpar.

En mi experiencia en ambos lados de la mesa de discusión, el consejo que ofrece Mike Hittle es perfecto. Permítanme explicar cómo mi empleador pone esto en práctica.

1. Comenzamos con la suposición de que todos quieren hacer el mejor trabajo posible, y tomarán decisiones en el mejor interés del proyecto. Pero también somos transparentes: esperamos que nuestras decisiones, pero no nuestros motivos, sean cuestionadas, y tratamos esas preguntas como solicitudes de información, no como dudas.

2. Hacemos nuestro mejor esfuerzo para acordar objetivos y horarios; rara vez se dictan. Discutimos en lugar de forzar problemas. Hay un viejo dicho: “Bueno, rápido, barato: elige dos”. Todos entendemos que necesitamos hacer compensaciones, que las cosas van mal y que las prioridades cambian. Si necesitamos el producto 2 semanas antes, aceptamos que tengamos que posponer algunas funciones. Y si surge una emergencia del cliente, acordamos que tendrá prioridad sobre el desarrollo y que los cronogramas se perderán.

3. Entendemos, respetamos e intentamos satisfacer las necesidades de los demás. Los gerentes a veces “ejecutan interferencias” para proteger a los desarrolladores de las distracciones (como tratar con clientes o una alta gerencia). Y, a cambio, los desarrolladores son lo más comunicativos posibles sobre el estado, especialmente sobre problemas y retrasos.

4. Después de recuperarnos de una falla o problema inesperado, tenemos una autopsia con el único objetivo de mejorar el proceso. No hay culpa, solo mejora. Si un individuo cometió un error, preguntamos cómo podemos evitar que la próxima persona lo repita. Si fue un evento externo, preguntamos si podemos protegernos del próximo, o al menos asegurarnos de que tengamos alguna advertencia.

5. Casi sin excepción, nos apreciamos y apreciamos sinceramente. Es parte de nuestra cultura. Ir a trabajar es mucho más fácil cuando es una fuente de apoyo y comodidad, y cuando la mayoría de los problemas son técnicos, no políticos.

Si bien acepto las otras respuestas aquí, quiero señalar un factor más: muchos estudiantes de CS e ingeniería piensan que está bien descuidar el desarrollo de sus habilidades de comunicación durante sus años de educación (consulte ¿Son los requisitos generales en la universidad una pérdida de tiempo? ¿Por qué es necesario que un ingeniero de software sepa sobre teoría musical o que un periodista sepa sobre electricidad y magnetismo?), muchas escuelas les permiten descuidar esas habilidades y muchos empleadores buscan “el mejor” recién graduado Los desarrolladores no se preocupan realmente por la falta de amplitud en los cursos y habilidades de los candidatos.

(Divulgación completa: soy un desarrollador con un título en artes liberales).

Habiendo trabajado como periodista (y tratando con todo tipo de personas de relaciones públicas bajo el sol) y ahora trabajando rodeado de desarrolladores, puedo decirte que son dos estilos de trabajo muy diferentes. No diría que cualquiera de las partes es generalmente mala para comunicarse.

Tienen estilos de trabajo muy diferentes. Y eso puede causar una brecha de comunicación bastante desagradable si no tienes cuidado.

Revelador completo, escribí una publicación de blog sobre esto aquí: Cómo comunicarse mejor con colegas de TI

Como persona de relaciones públicas, probablemente estés acostumbrado a un intercambio bastante rápido. Su día está segmentado en intervalos de 1 hora (si no 15 minutos). Mientras que los desarrolladores pueden pasar medio día en un problema. Lleva más tiempo cargar un problema en tu cabeza, por lo que es fácil molestarte con tus pequeñas interrupciones.

Paul Graham lo pone mejor de lo que yo podría: Maker’s Schedule, Manager’s Schedule

Probablemente también tengas la idea de trabajar en “flujo”. Los atletas lo llaman “en la zona”.

Es un estado mental óptimo para el tipo de trabajo que realizan los desarrolladores. En un estudio, investigadores australianos presentaron 40 sujetos de prueba con un complejo desafío para la mente. Ningún sujeto fue capaz de resolver el rompecabezas. Después de que los investigadores indujeron artificialmente un estado de flujo, 23 de los sujetos resolvieron el rompecabezas y lo hicieron en un tiempo récord.

Además, ¿trataste de hablar con los desarrolladores sobre algo que no está relacionado con el trabajo? Si desea comunicaciones menos robóticas, intente tratar a las personas de una manera más humana.

Los que no son desarrolladores a menudo no piensan ni hablan con el rigor y la precisión necesarios para discutir el comportamiento del software y los posibles cambios en ese comportamiento. En lugar de trabajar para mejorar el diálogo con los desarrolladores sobre los temas que necesitan discutir, a menudo simplemente culpan a los desarrolladores por ser “malos comunicadores”. A partir de ahí, necesitan modificar cualquiera de sus comportamientos y no tienen ninguna razón para cambiar ninguno de sus supuestos.

A menudo, las personas del lado empresarial no están dispuestas a comunicarse claramente con los desarrolladores y hacen numerosas suposiciones erróneas sobre lo que el desarrollador sabe. (Generalmente suponen que el desarrollador sabe mucho sobre su trabajo y hacen suposiciones falsas de que el desarrollador tiene una comprensión conceptual del significado de lo que hace el software). Tampoco tienen la paciencia para escuchar a los desarrolladores dar en profundidad explicaciones y no dará respuestas detalladas a las preguntas del desarrollador.

Esto es extremadamente evidente cuando lee los informes de errores y las solicitudes de mejora en un sistema de solicitud de trabajo. Los reporteros a menudo tratan el informe de error como papeleo sin sentido. En lugar de usarlo como una oportunidad para dar a los desarrolladores una explicación detallada de lo que quieren, a menudo escriben informes breves en oraciones incompletas. Estos informes de errores carecen de contexto para explicar cuándo y dónde ocurre el problema y, en general, no son lo suficientemente significativos para que el desarrollador los interprete en una solicitud de función coherente.

Las personas en el negocio a menudo no se dan cuenta de que las omisiones en la información que proporcionan conducen a aumentos exponenciales en la cantidad de tiempo que el desarrollador necesita para estudiar el problema y comprender la situación.

No tenía experiencia en ingeniería y me mudé a ingeniería (hardware y software). Cuando estaba en el campo de la no ingeniería, tenía la misma pregunta que tú.

Ahora, como dijo la otra publicación, lo más probable es que la persona sin tecnología diga algo tan vago que los desarrolladores no lo entiendan. Este es probablemente el caso. Mientras tanto, crees que especificaste. Una vez que comienza a escribir códigos, diseñando su base de datos, se da cuenta de que hay muchos más detalles. Como uno de los ejemplos de tesoros del afiche, el capitán tampoco especificó qué tesoro. Los marineros encontraron algunos rubíes pero estabas anticipando diamantes. Entonces estás decepcionado y llamas a los marineros perezosos y acabas de encontrar lo que vieron primero.

Del mismo modo, la persona no técnica llama a la persona tecnológica tonta y perezosa. (Lo escucho todo el tiempo, lo siento muchachos técnicos). Pero en realidad, no se especificó. A veces los técnicos harán su propia suposición. Así que sé claro, sé muy claro para evitar cualquier falta de comunicación. Y la mejor manera de evitar eso es aprender algo de código y base de datos.