¿Cuál es la mejor manera de motivar a sus compañeros para que "lean al respecto" en lugar de explicarles todo en ese instante?

Tenemos muchos casos en los que colegas con diferentes niveles de experiencia están en una reunión y discuten posibles diseños de software. Y otro grupo de ingenieros que no "entienden" y prefieren simplificar todo; por simplificación quiero decir "simplificar para su comprensión" y no necesariamente adoptar los principios/prácticas sugeridas en nuestro dominio.

A veces, las reuniones se han descarrilado solo para que podamos proporcionar un volcado de conocimientos, lo cual es agotador con todas las preguntas cruzadas/enseñanza, etc., y luego están a bordo.

Tuvimos una discusión en la que explícitamente les dimos un volcado de conocimiento y proporcionamos enlaces/libros/referencias para hacer un seguimiento de los demás. Sin embargo, el "seguimiento" nunca ocurre y volvemos al punto de partida. Parece que hay resistencia en hacer el esfuerzo de "leer sobre el tema" y luego volver con preguntas/aclaraciones/sugerencias en lugar de discutirlo allí mismo y volver sin sentirse convencido y simplemente dejarlo en un punto muerto.

¿Cuáles son buenas maneras de "motivar a los compañeros" a "estudiar/aprender" cosas nuevas frente a descarrilar las reuniones para explicarles todo?

ACTUALIZACIÓN : Esto no es tan sencillo como "Googlearlo". Es más difícil que una búsqueda de palabras clave, pero más de comprender los conceptos subyacentes y por qué las cosas se hacen/prefieren de una manera particular. A veces, los libros hacen un trabajo mucho mejor que Google. La idea es probablemente profundizar un poco más en el tema y dar sentido a las diferentes fuentes de información para comprender algo que puede llevar algunas horas de reflexión/comprensión en lugar de unos minutos de búsqueda en Google. Se trata de "falta de experiencia en el dominio" y falta de voluntad para "construirlo" frente a "explícamelo ahora mismo".

@DarkCygnus: en mi humilde opinión, no es completamente "compatible con Google", esto es más profundo que solo "búsqueda de palabras clave", pero más como "conocimiento adquirido", probablemente múltiples búsquedas en Google que vinculan ideas dispares. Desafortunadamente, es difícil "googlearlo" exactamente, por lo que tendemos a guardar libros, enlaces, referencias cuando lo encontramos...
¿Cuál es tu trabajo y cómo exactamente esta situación te impide hacerlo?
Le sugiero que lea la publicación y las respuestas, y no solo juzgue una publicación por su título... Hay varias respuestas que se aplican a la situación que describe aquí, estoy seguro de que al menos le darán algunos consejos... tal vez requiere varias búsquedas en Google, pero en un sentido más amplio, "googlearlo" significa "intentar encontrarlo por su cuenta"
@DarkCygnus: también leí las respuestas. ¿Por qué debería leer el título? :)
De todos modos, estoy seguro de que la publicación proporcionará algunos consejos que serán útiles :) y está bien, no se preocupe, seguramente alguien más eventualmente responderá a su publicación, solo quería compartir la que encontré relevante para su situación. ¡salud!
No te preocupes, agradezco los consejos. Podrían ser igualmente útiles, pero en mi lugar de trabajo decir "Google it" es aceptable :) Lo que busco hacer es decir "ve a aprender sobre eso" y realmente "entiende". Te "ayudaremos", pero no haremos el aprendizaje por ti...
¿Todos en la reunión son realmente necesarios? No parece productivo incluir ingenieros junior en una reunión de diseño cuando carecen de los antecedentes para comprender las decisiones de diseño que se toman. Parecería tener más sentido limitar las reuniones de diseño a personas que están al día en el fondo y trabajar por separado para poner al día a los ingenieros jóvenes. Eso puede implicar una reunión dedicada de "introducción a x", puede implicar algún tipo de programa de capacitación/tutoría oficial o semioficial donde se les dan libros y artículos para leer y otras oportunidades para aprender.
@JoeStrazzere - no literalmente "debate". "Discutimos" el diseño y lanzamos diferentes ideas; algunas requieren una comprensión más profunda de los conceptos para saber por qué lo sugerimos.
@JustinCave: estamos planeando hacer precisamente eso. Pero dado que tenemos varios equipos pequeños, aterrizamos involucrando a los jóvenes también, de lo contrario, carecen de contexto. Pero veo que estás en lo cierto y hemos comenzado a restringirlo.

Respuestas (3)

Parece que estás perdiendo el tiempo de la gente

Veo dos problemas en tu pregunta:

  1. Tiene reuniones que tratan sobre un tema general (diseño de software), pero no parecen tener un objetivo o propósito concreto, al menos no por la descripción en la pregunta y los comentarios sobre la pregunta.
  2. Algunas personas que asisten a la reunión no parecen estar dispuestas o en condiciones de contribuir en nada.

Sospecho que el Problema 1 causa en parte el Problema 2.

Las reuniones deben tener un objetivo o propósito específico

Al menos en mi trabajo en la industria del software, no tenemos discusiones abstractas sobre el diseño de nuestro software, porque estamos ocupados trabajando. Tenemos discusiones de diseño cuando estamos diseñando algo nuevo, o cuando estamos haciendo un cambio en algo que ya hicimos, es decir, cuando estamos a punto de hacer algún trabajo que afectará específicamente a otros miembros identificables del equipo.

Si se trata de una reunión en la que las personas simplemente "lanzan ideas" sobre cómo debería verse el diseño, no parece que haya suficiente planificación de la agenda de la reunión con anticipación para cualquiera que sea el tema de la reunión. Quienquiera que dirija esta reunión debe saber lo suficiente sobre lo que se debe hacer o qué problema específico resolverá la reunión, de modo que pueda preparar a los demás asistentes para la reunión con anticipación (por ejemplo, con documentación, notas, diapositivas, lo que sea) para que la gente pueda llegar a esta reunión sabiendo por qué están allí y de qué están hablando. Lo que lleva a tu otro problema:

Las invitaciones a la reunión deben limitarse a las personas que pueden contribuir a ella

Usted dice en la pregunta que estas personas que no están aprendiendo lo que le gustaría que hicieran son compañeros. En otras palabras, que no eres su jefe. Supongo que eso significa que tienen un jefe que tiene expectativas diferentes a las suyas y que sus compañeros toman esas expectativas más en serio. ¿Consideró que tal vez sus compañeros no quieren estar en esta reunión? Quiero decir, si quisieran estar allí, creo que harían todas estas lecturas que usted quiere que hagan sin tener que evocar cómo lograr que lo hagan. O si su jefe quisiera que estuvieran allí, que harían todo este trabajo. Tu jefe no tiene que preguntarse cómo motivar a la gente, ¿verdad?

También es posible que haya sobreestimado su capacidad relativa para comprender o preocuparse por el tema de estas reuniones por alguna otra razón. ¿Quizás no son realmente tus compañeros? ¿Quizás esperas que se desempeñen a tu nivel cuando no están allí?

Esas son solo dos posibilidades; hay innumerables más. Independientemente de las razones, está claro que no pueden contribuir productivamente a la reunión. Entonces, no los invites.

Esto se remonta a la planificación de la reunión con un objetivo o propósito específico. Si el objetivo es discutir el diseño de la función X, entonces solo necesita personas que implementarán X y personas que comprendan los requisitos de la función X. Tal vez también tenga los probadores para la función X (si su organización tiene probadores).

Si cree que la lista de asistencia a la reunión ya es tan limitada, entonces necesita mejorar la preparación previa a la reunión para que todos tengan al menos una idea de lo que todos están hablando.

Las reuniones tienen un objetivo específico y solo se invita a aquellos que necesitan estar allí. Es cuando estamos hablando de un diseño específico y es posible que otros no lo “entiendan” cuando surgen los problemas. Una sugerencia actual es simplificar aún más la agenda de la reunión y discutir sobre el metaaprendizaje para ver si ayuda.
Parece que sus colegas que tienen menos experiencia podrían beneficiarse de algún tipo de capacitación (interna o externa) sobre los temas que son los puntos más problemáticos para su equipo. Podría ser razonable invertir algo de tiempo en organizar esto, tal vez un seminario de 2 o 3 días para permitir que estos colegas se pongan al día con el resto de ustedes.

Necesitas mostrarle a la gente por qué están equivocados o aceptar que podrías estarlo.

Si el problema es que las personas realmente carecen del conocimiento del dominio relevante, entonces debe explicarles por qué su enfoque es problemático. Por ejemplo, si el problema es la ejecución en paralelo, debe mostrar por qué un enfoque ingenuo podría conducir a condiciones de carrera.

En verdad, a nadie le gusta que le demuestren que está equivocado y, después de esa explicación, es más probable que confíe en sus ideas.

Si es realmente una cuestión de opinión.

Por supuesto, también es posible que haya leído el libro X, que se entusiasmó con un diseño en particular, y sus colegas no. Eso no los hace equivocados, y también pueden tener una experiencia valiosa u otro enfoque igualmente válido.

En software, hay muchos, muchos libros y muchas, muchas opiniones. Si cree que su enfoque tiene valor, véndalo, explique por qué es especialmente aplicable al dominio del problema, pero esté preparado para respetar y aceptar que el consenso puede ir en una dirección diferente.

Descartar a sus colegas como ignorantes o necesitados de educación simplemente porque no son entusiastas de su libro o autor favorito no lo llevará muy lejos. Y no caiga en la trampa de pensar que "todos" resuelven un problema de una manera particular porque su libro así lo dice.

La verdadera solución no está en tus manos, sino en las de tu jefe (o de quien esté a cargo del proyecto). Todo lo que necesitas hacer es dejar eso claro para ellos.

Primero explícales el problema en términos muy simples:

  1. Tiene la tarea de idear diseños de solución.
  2. Estos diseños requieren la participación de otros equipos.
  3. Los otros equipos carecen de la experiencia necesaria para comprender sus diseños y por qué son preferibles.
  4. Tus intentos de impartir el conocimiento que les ayudaría a entender están fallando (sin culpa tuya).
  5. Esto está provocando retrasos en el proyecto y trabajo adicional para usted.
  6. La falta de experiencia en sí misma debería generar inquietudes sobre la viabilidad de que ese equipo/individuos sean permitidos en el proyecto o en la empresa.
  7. La falta de experiencia es comprensible y remediable, pero la falta de aprendizaje proactivo, especialmente el seguimiento de las recomendaciones que tiene, realmente no lo es.

Luego, pregúntales cómo les gustaría que manejaras esto. Aquí hay algunas opciones:

1 - Ser responsable de entrenar al otro equipo

Esto requerirá tanto una asignación de tiempo como la autoridad para instruirlos. Sin embargo, hay algunas cosas que simplemente no puedes entrenar a alguien para que sea si no son apasionados y proactivos, y parece que no lo son, por lo que no funcionará.

2 - Tener autoridad sobre el otro equipo

Haga que los jefes reconozcan que usted sabe lo que está haciendo y el otro equipo no, así que elimine la necesidad de su aprobación, o incluso de su comprensión, y esencialmente déjelo a usted a cargo.

3 - Pida que el equipo sea reemplazado por uno más competente

Es posible que pueda subcontratar, reclutar, colocar parte de su equipo en el de ellos o una combinación de ellos.

4 - Sigue explicando las cosas como lo haces

Lo que incurrirá en retrasos y hará perder el tiempo de la empresa.

5 - Deja de explicar las cosas

Lo que solo creará un punto muerto.

Por supuesto, ninguna de estas soluciones es aceptable, y presentarlas a sus jefes al menos les hará comprender la situación en la que se encuentran. Si no toman una decisión, su única solución es implementar la opción 5 y seguir repitiendo lo mismo. cosa en las reuniones:

Esta es la mejor solución. Lamentamos que le falte la experiencia para entender por qué es así. No estamos en condiciones de brindarle la capacitación necesaria para que alcance el nivel de experiencia necesario para comprenderlo. Os hemos dado indicaciones y no las habéis tomado. Nuestras manos están atadas.

Esto creará un silencio muy incómodo en las reuniones. Solo sonríe y no hagas nada. El reloj sigue corriendo, y las personas que más se preocupan por el tictac del reloj pronto harán algo al respecto.