Cómo expresar "tener problemas para comunicarse" con un individuo en particular

He trabajado como desarrollador de software en solitario para el gobierno durante poco más de un mes. Básicamente, una persona me contrató porque no sabe programar. Me resulta difícil hacer bien mi trabajo, ya que hay una gran desconexión en los cuerpos de conocimiento: las personas con las que trabajo son silvicultores. Para remediar esto, he intentado tomarme el tiempo para hablar con mi supervisor inmediato y hacerle preguntas. Esto no ha funcionado tan bien.

Le mencioné a otro supervisor que tengo problemas de comunicación y lo describió como 1) la persona creció en la Unión Soviética y tiene una cultura muy diferente a la nuestra 2) Necesito ganarme su respeto antes de que esté abierto a nuevas ideas.

Creo que me están malinterpretando. 1) Entiendo que hay una diferencia cultural, pero hago preguntas como "¿este módulo siempre llamará a este módulo o podría llamarlo algún otro módulo?" No estoy seguro de cómo reformularlo para que se ajuste mejor a su cultura. 2) No estaba tratando de hacer las cosas de manera diferente. Estaba haciendo lo que me pedían (o al menos mi interpretación de ello).

Realmente quiero comunicar la distinción entre "Tengo problemas para entender a esta persona" y "No me gusta la cultura/estilo de comunicación de esta persona".

Para los técnicamente inclinados: implementé los requisitos utilizando un enfoque orientado a objetos. Los requisitos pedían "2 módulos", por lo que uno era el archivo principal y el otro era una clase. Se requería que el lenguaje de programación fuera Python, pero se requería un archivo ejecutable. Para hacer esto, usé un convertidor de Python a ejecutable, pero solo generó 1 archivo exe y mi gerente quería más de 1. Le pregunté si el segundo módulo sería llamado por algo excepto el primero y dijo que no. Este es solo un ejemplo y no tengo prejuicios, solo no estoy seguro de cómo evitar que esto vuelva a suceder en el futuro.

Respuestas (2)

Es bueno que reconozca los problemas de comunicación, pero parece estar adoptando el enfoque de que la otra persona necesita cambiar para que usted tenga éxito. No tienes control sobre tu supervisor, pero hay cosas que puedes hacer por tu parte para que la comunicación sea más efectiva:

  • Piense en las suposiciones que podría estar haciendo y confirme a su supervisor que usted y él realmente están en la misma página. Por ejemplo, "Dices que el programa debe tener dos módulos. Quiero estar seguro de que entiendo lo que quieres decir con módulo. ¿Te refieres a clases, paquetes u otra cosa?"
  • Explique lo que está haciendo y pida una confirmación explícita antes de actuar. Por ejemplo, "Dijiste que estos módulos nunca se llamarían entre sí, así que planeo combinarlos en un solo ejecutable. ¿Está bien?"
  • Pida retroalimentación intermedia sobre lo que está haciendo. Por ejemplo, "Ayer acordamos que habría dos módulos. Una vez que entré en detalles, no tenía sentido que fueran dos ejecutables separados. Así es como se ve ahora. ¿Está bien?"
  • Además, después de cualquier comunicación verbal donde se tome una decisión, envíe una nota de seguimiento para confirmar la decisión. Por ejemplo, "Hola XXX, como discutimos hoy, implementaré esto como dos módulos separados dentro de un solo ejecutable. Saludos, Codey12"
  • Antes de saltar a su pregunta real, asegúrese de proporcionar suficiente contexto a su supervisor para que pueda entender por qué está haciendo esa pregunta. Por ejemplo, compare estos:
    • "¿Puedo implementar esto como un solo ejecutable?"
    • "Ayer discutimos la implementación de esto como dos módulos. Comencé a crear dos clases diferentes como discutimos. Parece que tiene más sentido ponerlas en un solo ejecutable. ¿Qué piensas?"
  • Asegúrese de aclarar por sí mismo cuál es su verdadera pregunta e intente hacerla primero. Compara estos dos ejemplos:
    • "¿Está bien si combino estos dos módulos en un solo ejecutable?"
    • "¿Se llamarán estos módulos alguna vez?" .. "No" .. "¿Está 100% seguro de que estos módulos nunca se llamarán entre sí?" .. "No" .. "¿Todavía estás seguro de que quieres que sean dos módulos separados?" .. "Sí" ...

Estás diciendo que tu gerente no entiende de programación y luego comienzas a hacerle preguntas de programación. Como señala Eric, no puedes cambiar sus habilidades de comunicación, sino solo las tuyas. Y debes dejar de hablarle geek y comenzar a hablar un idioma que entienda.

Evitar hablar en jerga puede ser difícil, pero cuando hablas con personas sin conocimientos técnicos, es muy importante. Debe comprender de qué está hablando cuando dijo que hiciera "2 módulos", debe preguntar qué significa realmente (si la especificación no lo aclara de manera técnica). Debe comprender las necesidades comerciales de 2 módulos y luego resolver el problema de cualquier manera técnica que tenga sentido y se ajuste a los requisitos comerciales.

Si pide algo que no tiene ningún sentido técnico (como 2 ex), entonces trata de entender cuáles son sus verdaderas preocupaciones. Pero tendrá que hablar solo en su idioma y omitir toda la jerga técnica. Si no es técnico, ni siquiera debería saber o preocuparse por la solución subyacente, la cantidad de ejecutables. Muéstrele lo que hace y vea si está resolviendo su necesidad y ajustándose a los requisitos. Palabras como 'orientado a objetos', 'ejecutable'... evita palabras como esa a menos que sepas que él realmente entiende de lo que estás hablando. En este momento, parece que no lo hace.