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".
Parece que estás perdiendo el tiempo de la gente
Veo dos problemas en tu pregunta:
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.
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:
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.
Cygnus oscuro
Doctor
aaaaa dice reincorporar a Monica
Cygnus oscuro
Doctor
Cygnus oscuro
Doctor
Justin cueva
Doctor
Doctor