Alguien ha enviado una pregunta:

Llevo varios años en la industria de Internet y la mayoría del personal técnico que he conocido tiene los siguientes problemas:

• ①, Taciturnos y maleducados;
• ②, Al colaborar, no les gusta informar del progreso (por ejemplo, están haciendo algo y de repente se detienen y no sabes a qué otra cosa se han ido; si no se les apremia, no te lo cuentan);
• ③, No responden por QQ; si responden, reaparece el punto 1.

¿Es un problema generalizado? ¿Cómo lo ven los técnicos?

A continuación se presentan extractos de algunas respuestas excelentes

I. Li Nan

Los problemas de comunicación con el personal técnico recaen principalmente en el personal de producto. La razón es sencilla: ellos se dedican a la tecnología, no a comunicarse con los usuarios y transmitir los requisitos al personal técnico. Si entras en su contexto y te familiarizas con su lógica, a menudo descubrirás que puedes comunicarte con ellos de manera eficiente.

El mal control del progreso recae principalmente en el personal de gestión de proyectos. La razón también es sencilla: ellos se dedican a la tecnología, no a gestionar y controlar el progreso. Tú necesitas organizar reuniones, establecer sistemas, recopilar el progreso y evaluar los resultados.

Los mejores programadores, por supuesto, se comunican con fluidez, se autogestionan bien y tienen una visión global.

Sin embargo, personalmente no me importan los programadores taciturnos a los que no les gusta informar del progreso, siempre que cumplan las reglas y puedan entregar código utilizable. También he visto a muchos programadores elocuentes que siempre ofrecen bonitos informes de progreso. Pero la estabilidad de su código puede ser tan mala que me vea obligado a reorganizar el equipo para que lo reescriba.

¿El autor del hilo parece ser de producto o de gestión de proyectos? Mi consejo es: no pienses siempre en echarle la culpa a los demás, haz bien tu propio trabajo, igual que un técnico taciturno te soluciona una fuga de memoria.

II. Fan Kai

Estoy bastante de acuerdo con la opinión de @李楠.

>>1. Taciturnos y maleducados.

El trabajo técnico requiere ser realista y sumergirse en las tareas; con el tiempo se desarrolla una personalidad relativamente introvertida. Si te topas con un técnico lleno de dulces palabras, de verdad tienes que tener cuidado. Este tipo de técnico suele causarte grandes problemas, como mentir sobre los resultados del trabajo, armar líos dentro del equipo, sembrar rumores y crear discordia. Estas son las dolorosas lecciones que he aprendido en la contratación de personal.

>>2. Al colaborar, no les gusta informar del progreso. Por ejemplo, están haciendo algo tuyo y de repente se detienen y se van a hacer otra cosa; si no se les apremia, no te lo cuentan.

Si se trata de una relación de "colaboración", usar la palabra "informar" resulta bastante problemático. Ya que él está al mismo nivel que tú en la colaboración, ¿por qué tendría que informarte de su trabajo? Como mucho, solo tendría la obligación de informar a su propio líder.

Por ejemplo, el equipo de I+D, el equipo de producto y el equipo de operaciones que dirijo colaboran juntos en un proyecto. Los ingenieros de I+D no tienen ninguna obligación de informar del progreso al personal de producto o de operaciones; el equipo de I+D solo tiene la obligación de informarme a mí. Entonces, ¿cómo fortalecer la comunicación entre los equipos? El método que utilizo es:

Cada equipo me informa del progreso a mí, y hago que el personal de producto elabore un informe semanal del progreso del proyecto, que se envía a todos por correo electrónico para que todos conozcan el avance del proyecto. Además, a partir de 30 días antes del lanzamiento del proyecto, cada día antes de salir del trabajo, reúno a todos los miembros del equipo del proyecto para una rápida reunión de revisión diaria del progreso.

He utilizado este método de gestión de proyectos una y otra vez con éxito; la eficiencia de colaboración entre los equipos de producto, I+D y operaciones es muy alta. Por lo tanto, la situación que describes, en mi opinión, es una falla del líder. El personal de producto no tiene autoridad para dirigir directamente al personal de I+D del mismo nivel. El líder de nivel superior ha abandonado sus responsabilidades.

>>3. No responden por QQ; si responden, reaparece el punto 1.

No me gusta abrir QQ durante el trabajo; si lo abro, es en modo no molestar. Si tienes algo, envíame un correo. Esta es la filosofía que inculco en todo el equipo.

Déjame añadir algo más: la profesión de programador es muy especializada. No digamos ya comunicarse con gente ajena al campo; incluso los desarrolladores que trabajan en áreas diferentes casi no pueden comunicarse. Por ejemplo, los que hacen proyectos web, los que hacen desarrollo embebido y los que hacen motores de juegos tienen sistemas de conocimiento que rara vez se superponen, por lo que es casi imposible una comunicación profesional eficaz, y mucho menos con personal no técnico; sin duda es fácil que surjan obstáculos.

Pongo un símil: la profesión médica también está muy especializada, por lo que sientes que es difícil comunicarse con los médicos, y que normalmente no están dispuestos a mantener conversaciones profundas con los pacientes. Es lo mismo que con los programadores: los sistemas de conocimiento difieren demasiado. A menos que alguien tenga una capacidad de comunicación especialmente fuerte, es difícil establecer una comunicación eficaz.

Por último, una nota más: comprobar el progreso del trabajo de los programadores no es difícil para un jefe con formación técnica. De hecho, aunque los programadores no me informen, igualmente sé cuál es su progreso. La razón es sencilla: tengo los permisos más altos en el servidor git interno de la empresa. Periódicamente hago pull del código fuente de cada proyecto para ver quién ha enviado qué commits últimamente, jeje.

III. Gran Árbol

Llevo casi 5 años dedicándome al desarrollo de software. Los fenómenos que menciona el autor del hilo, efectivamente, existen de forma generalizada entre mis colegas.

1. La taciturnidad, creo que en su mayoría es un comportamiento inconsciente. Es decir, en las experiencias de estudio y trabajo de muchos desarrolladores faltan oportunidades para comunicarse con otras personas, y mucho menos para comunicarse bien con otros colegas. Mi propia experiencia es que me esfuerzo por comunicarme e interactuar con otros colegas e incluso con cualquiera, pero como carezco de experiencia y habilidades en este campo, cometo errores, y soy sensible a darme cuenta de que una mala comunicación provoca emociones desagradables en los demás. Siento una sensación de fracaso, y esa sensación de fracaso vuelve a dañar mi confianza para comunicarme con los demás. En resumen, este es un problema que yo mismo aún no he resuelto.

Al mismo tiempo, al estar mucho tiempo frente a las máquinas, uno se acostumbra a ser directo. Por ejemplo, si la máquina da un "hello world", el programador probablemente solo piensa en una función main y en una llamada a printf, y no se da cuenta de que quien se comunica con él es una persona viva con otras ideas; se olvida de considerar lo humano.

Por ejemplo, cuando un PD pregunta si se puede implementar una función compleja, algunos colegas programadores, basándose en su experiencia real, dan de inmediato una respuesta directa, fría y sin lugar a negociación: que no se puede. En realidad, si se suavizara un poco, por ejemplo, "el costo de tiempo es bastante alto; si tuviera un poco más de tiempo, estaría dispuesto a intentarlo", haría sentir más cómodo al PD. Esto da a ambas partes una oportunidad de que la conversación se desarrolle de manera más profunda y agradable.

Otro fenómeno no tan bueno que podría estar realmente relacionado con el propio grupo de programadores: muchos colegas programadores son bastante arrogantes. Esa arrogancia puede venir de un buen rendimiento académico, de unos ingresos relativamente mejores que los de sus pares, o incluso solo de haber resuelto un bug. En una autoconciencia carente de comunicación, estos factores pueden no hacerles darse cuenta de que no tienen nada de extraordinario.

Para mejorar mi forma de hablar y llevarme bien con los demás, incluso compré un libro que parece muy aburrido, "El arte de hablar de Cai Kangyong" (蔡康永说话之道). Puede que no haya mejorado mucho mi técnica para hablar, pero me hizo darme cuenta de que hablar es toda una disciplina.

2. No informar del progreso del trabajo: o es por pereza, o por falta de planificación del propio trabajo. Si quieres ser alguien en quien los demás puedan confiar y quieres dejar a tus colegas una impresión de que se puede contar contigo, debes ser fiel a lo que se te ha encomendado. Debido a la particularidad del sector de TI, deberías aumentar la frecuencia con la que das retroalimentación sobre tu progreso laboral. Esta es una actitud para hacer las cosas, y no se limita a la industria de TI. Si no eres confiable, no esperes poder asumir grandes responsabilidades.

Para no olvidar lo que otros colegas me han encargado, anoto las cosas en un memorándum y lo tengo a mano. Sé en qué trabajos estoy y cuándo necesito dar retroalimentación sobre cada tarea.

3. Si no responden por QQ, usa el correo electrónico o llama directamente. Intenta usar lo menos posible QQ para la comunicación laboral. Puedes ir a su puesto de trabajo a charlar, usa cualquier forma que creas que pueda involucrarlo.

Todo programador que no pueda llevarse bien con sus colegas debería reflexionar sobre estas cuestiones.

Fuente:Zhihu