Epígrafe
Érase una vez el erizo y el osito que se encontraban en el bosque.
- ¡Hola, erizo!
- ¡Hola, osito!
Así que, palabra por palabra, chiste tras chiste, el Osito golpeó al Erizo en la cara...
A continuación se muestra una discusión del líder de nuestro equipo, así como del director de desarrollo de productos de RAS, Igor Marnat, sobre los detalles de los conflictos laborales y los posibles métodos para gestionarlos.
La mayoría de los conflictos que encontramos en el trabajo se desarrollan según un escenario similar al descrito en el epígrafe anterior. Hay varios participantes que inicialmente tienen una disposición bastante favorable entre sí, están tratando de resolver algún problema, pero al final el problema sigue sin resolverse y, por alguna razón, las relaciones entre los participantes en la discusión se estropean.
La vida es diversa y se producen variaciones en el escenario descrito anteriormente. A veces la relación entre los participantes no es muy buena inicialmente, a veces ni siquiera hay un tema que requiera una solución directa (como, por ejemplo, en el epígrafe), a veces después de la discusión la relación sigue siendo la misma que antes de comenzar, pero el problema finalmente no se resuelve.
¿Qué hay en común en todas las situaciones que se pueden definir como situación de conflicto laboral?
En primer lugar, hay dos o más bandos. Estas partes pueden ocupar diferentes lugares en la organización, estar en una relación de igualdad (compañeros en un equipo), o en diferentes niveles de la jerarquía (jefe - subordinado), ser individuales (empleado) o grupales (en casos de conflicto entre un empleado y un equipo o dos equipos), y así sucesivamente. La probabilidad de que surja un conflicto y la facilidad de su resolución están muy influenciadas por el nivel de confianza entre los participantes. Cuanto mejor se conozcan las partes, mayor será el nivel de confianza y mayores serán las posibilidades de llegar a un acuerdo. Por ejemplo, los miembros de un equipo distribuido que nunca han interactuado cara a cara tienen más probabilidades de experimentar conflictos por un simple tema laboral que las personas que han tenido al menos algunas interacciones cara a cara. Por lo tanto, cuando se trabaja en equipos distribuidos, es muy importante asegurarse de que todos los miembros del equipo se reúnan periódicamente en persona.
En segundo lugar, en una situación de conflicto en el trabajo, las partes se encuentran en la situación de resolver algún tema que es importante para una de las partes, para ambas o para la organización en su conjunto. Al mismo tiempo, debido a las particularidades de la situación, las partes suelen disponer de tiempo suficiente y de diversas formas para resolverla (formales, informales, reuniones, cartas, decisiones de gestión, la presencia de metas y planes del equipo, la hecho de una jerarquía, etc.). Esto es diferente de la situación de resolver un problema laboral (o no laboral) en una organización o, por ejemplo, de resolver una pregunta importante: "Eh, chico, ¿de qué área eres?". en la calle, o el conflicto del epígrafe. En el caso de resolver un problema laboral, la calidad del proceso de trabajo y la cultura de resolución de problemas en el equipo son importantes.
En tercer lugar, el factor determinante del conflicto (desde el punto de vista de nuestra discusión) es el hecho de que las partes en el proceso no pueden llegar de forma independiente a una solución al problema que convenga a todas las partes. La situación requiere la intervención de un tercero, un árbitro externo. Este punto puede parecer controvertido, pero, en esencia, si la situación de conflicto se resolvió con éxito sin la intervención de un árbitro externo, la cuestión se resolvió con éxito y las relaciones entre las partes no se deterioraron, esta es la situación por la que debemos esforzarnos. . Lo más probable es que ni siquiera nos enteremos de tal conflicto, o lo sabremos por casualidad una vez que se haya resuelto. Cuantos más problemas pueda resolver un equipo por sí solo, más eficaz será.
Otro rasgo característico del conflicto que vale la pena mencionar es el grado de intensidad emocional durante la decisión. El conflicto no está necesariamente asociado con un alto nivel emocional. Los participantes no tienen que gritar y agitar los brazos para que la situación sea, en esencia, un conflicto. El tema no está resuelto, hay cierta tensión emocional (quizás no se expresa claramente exteriormente), lo que significa que nos encontramos ante una situación de conflicto.
¿Es necesario intervenir en situaciones de conflicto o es mejor dejar que su resolución siga su curso y esperar a que el problema se resuelva por sí solo? Necesitar. No siempre está en su poder o competencia resolver el conflicto por completo, pero en cualquier situación, en un conflicto de cualquier escala, puede adoptar una posición adulta, atrayendo así a varias personas más a su alrededor, mitigar las consecuencias negativas de la situación. conflicto y contribuir a su resolución.
Antes de ver algunos ejemplos de situaciones de conflicto, veamos algunos puntos importantes comunes a todos los conflictos.
A la hora de resolver un conflicto, es importante estar por encima de la pelea y no dentro de ella (a esto también se le llama “tomar una metaposición”), es decir, no ser parte de una de las partes en el proceso de resolución. De lo contrario, contar con un árbitro externo que asista en la decisión sólo fortalecerá la posición de una de las partes en detrimento de la otra. A la hora de tomar una decisión, es importante que sea moralmente aceptada por todas las partes, como dicen, “comprada”. De modo que, aunque las partes no estuvieran contentas con la decisión tomada, al menos aceptaron sinceramente implementarla. Como dicen, poder discrepar y comprometerse. De lo contrario, el conflicto simplemente cambiará de apariencia, el fuego latente permanecerá bajo la turbera y en algún momento inevitablemente volverá a estallar.
El segundo punto, en parte relacionado con el primero, es que si ya has decidido participar en la resolución del conflicto, tómalo lo más en serio posible desde el punto de vista de la comunicación y del estudio del contexto. Habla personalmente con cada una de las partes. Por separado con cada uno, para empezar. No te conformes con el correo. En el caso de un equipo distribuido, al menos hable a través de un enlace de vídeo. No se contente con rumores e informes de testigos presenciales. Comprender la historia, qué quiere cada parte, por qué lo quiere, qué esperan, si han intentado resolver este problema antes, qué pasará si no se resuelve, qué soluciones ven, cómo imaginan la posición de las partes. otro lado, qué piensan, bien o mal, etc. Cargue todo el contexto posible en su cabeza, con la mente abierta, asumiendo que todos tienen razón. No estás dentro del conflicto, estás fuera de él, en una metaposición. Si el contexto solo está disponible en un hilo de publicación, al menos léelo en su totalidad y los hilos y documentos relacionados con él. Después de haberlo leído, sigue hablando con tu voz. Es casi seguro que escuchará algo importante que no esté en el correo.
El tercer punto importante es el enfoque general de la comunicación. Son cosas ordinarias, nada cósmicas, pero son muy importantes. No intentamos ahorrar tiempo, hablamos con todos los participantes, no criticamos a la persona, pero consideramos las consecuencias de sus acciones (no "eres grosero", sino "quizás los chicos se sientan ofendidos por esto”), damos la oportunidad de salvar las apariencias, llevamos a cabo discusiones en persona, no delante de la fila.
Los conflictos suelen ser causados por una de dos razones. El primero está relacionado con si una persona en el momento del conflicto se encuentra en la posición de un adulto o en la posición de un niño (más sobre esto a continuación). Esto se debe a su madurez emocional, a la capacidad de gestionar sus emociones (que, por cierto, no siempre está relacionada con su edad). La segunda razón común es la imperfección del proceso de trabajo, que crea situaciones de áreas grises en las que la responsabilidad se reparte entre los participantes, las expectativas de las partes no son transparentes entre sí y los roles en el proceso se confunden.
En consecuencia, al resolver un conflicto (así como cualquier otro problema), un gerente debe tener en cuenta tres perspectivas: a corto plazo - para resolver el problema/conflicto aquí y ahora, a mediano plazo - para minimizar la probabilidad de que surja otro conflicto. por la misma razón y a largo plazo: cultivar una cultura adulta en la persona del equipo.
Cada uno de nosotros tiene un niño interior, de unos tres o cuatro años. Duerme la mayor parte del tiempo en el trabajo, pero a veces se despierta y toma el control. El niño tiene sus propias prioridades. Es importante para él insistir en que este es su arenero, su madre lo quiere más, su máquina es la mejor (el diseño es el mejor, él programa mejor,...). En una situación de conflicto, un niño puede presionar juguetes, pisotear y romper una espátula, pero no puede resolver los problemas de los adultos (arquitectura de soluciones, enfoques para las pruebas automatizadas, fechas de lanzamiento, etc.), no piensa en términos de beneficios. para el equipo. Se puede animar, consolar y mandar a dormir a un niño en conflicto pidiéndole que llame a su adulto. Antes de iniciar una discusión en una situación de conflicto, asegúrese de estar hablando con un adulto, no con un niño, y de estar usted mismo en la posición de un adulto. Si tu objetivo honesto en este momento es resolver un problema grave, estás en la posición de un adulto. Si tu objetivo es pisotear y hacer crujir el omóplato, esta es una posición infantil. Envía a tu niño interior a la cama y llama a un adulto, o reprograma la conversación. Una persona toma una decisión emocional y luego busca una justificación racional para ello. Una decisión tomada por un niño basada en sus prioridades no será óptima.
Además del comportamiento en el momento de un conflicto, la posición de un niño o de un adulto también se caracteriza por el nivel de responsabilidad que una persona está dispuesta a asumir. En sus manifestaciones extremas, la posición infantil de un programador, con el que me he encontrado más de una vez, se ve así: escribí el código, lo envié a revisión y mi trabajo está terminado. Los revisores deben revisarlo y aprobarlo, el control de calidad debe verificarlo y, si hay problemas, me lo harán saber. Aunque parezca extraño, incluso las personas bastante maduras y experimentadas se comportan así a veces. El otro extremo de la escala es que una persona se considera responsable de garantizar que su código funcione, esté cubierto por pruebas, haya sido verificado personalmente por él, haya pasado la revisión con éxito (si es necesario, no hay problema en hacer ping a los revisores, discutir problemas por voz, etc.) y ha sido suprimido, QA proporcionará asistencia si es necesario, se describirán escenarios de prueba, etc. En casos normales, el programador comienza más cerca del extremo adulto de la escala o avanza allí a medida que adquiere experiencia (siempre que se cultive la cultura adecuada dentro del equipo). En casos extremos, continúa trabajando, generalmente adoptando una posición infantil, luego él y el equipo surgen periódicamente problemas y conflictos.
Fomentar una cultura madura y adecuada en un equipo es una tarea importante para cualquier directivo. Requiere mucho tiempo y esfuerzo diario, pero el resultado merece la pena. Hay dos formas de influir en la cultura del equipo: predicar con el ejemplo (que definitivamente será seguido; el equipo siempre mira al líder) y discutir y recompensar el comportamiento correcto. Aquí tampoco hay nada abstruso o muy formal, solo cuando se discuten problemas, observe que se podría haber hecho algo aquí, enfatice que notó cuándo se decidió correctamente, elogie, anote durante la revisión del lanzamiento, etc.
Consideremos varias situaciones de conflicto típicas, desde simples hasta complejas:
Conflictos no relacionados con cuestiones laborales.
Muy a menudo hay conflictos en el trabajo que no están relacionados con cuestiones laborales. Su ocurrencia y facilidad de resolución suelen estar directamente relacionadas con el nivel de inteligencia emocional de los participantes, su nivel de madurez, y no están relacionados con la perfección o imperfección del proceso de trabajo.
Ejemplos típicos: alguien no usa la lavadora o la ducha con suficiente frecuencia, lo que a otros no les gusta, alguien está sofocado, mientras que otros respiran si abren la ventana, alguien hace demasiado ruido y otros necesitan silencio para trabajar, y pronto. Es mejor no retrasar la resolución de conflictos de este tipo y no dejar que sigan su curso. No se resolverán por sí solos, te distraerán del trabajo todos los días y envenenarán el ambiente en el equipo. Afortunadamente, solucionarlos no suele ser un gran problema: basta con hablar tranquilamente (uno a uno, por supuesto) con un colega que descuida la higiene, proporcionar asientos cómodos a las personas que prefieren el silencio/frescura, comprar auriculares que absorban el sonido o instalar mamparas. , etc.
Otro ejemplo que encontré varias veces durante mi trabajo es la incompatibilidad psicológica de los miembros del equipo. Por alguna razón, las personas simplemente no pueden trabajar juntas; cada interacción termina en un escándalo. A veces esto se debe al hecho de que las personas tienen opiniones polarizadas sobre algún tema urgente (generalmente político) y no saben cómo dejarlas fuera del trabajo. Convencerlos de que se toleren unos a otros o de que cambien su comportamiento es una tarea bastante inútil. La única excepción que he encontrado son los colegas jóvenes con percepciones abiertas; su comportamiento aún puede cambiarse gradualmente mediante conversaciones periódicas. Por lo general, el problema se resuelve con éxito separándolos en diferentes equipos, o al menos brindándoles la oportunidad de superponerse en el trabajo muy raramente.
En todas las situaciones anteriores, vale la pena hablar personalmente con todos los participantes, discutir la situación, preguntarles si ven algún problema en este caso, cuáles son, en su opinión, las soluciones y garantizar su participación para lograrlo. decisión.
Desde el punto de vista de optimizar el proceso de trabajo (la perspectiva de mediano plazo que mencioné), aquí no se puede hacer mucho, el único punto de optimización es tener en cuenta el factor de compatibilidad a la hora de formar un equipo y no poner personas juntos de antemano quiénes entrarán en conflicto.
Desde la perspectiva de la cultura de equipo, estas situaciones surgen con mucha menos frecuencia en equipos con una cultura madura, donde las personas respetan al equipo y a sus colegas y saben cómo resolver los problemas de forma independiente. Además, estos conflictos se resuelven mucho más fácilmente (a menudo de forma automática) en equipos en los que existe un alto nivel de confianza, las personas han trabajado juntas durante mucho tiempo y/o se comunican con frecuencia fuera del trabajo.
Conflictos relacionados con cuestiones laborales:
Este tipo de conflictos suelen ser provocados por ambos motivos a la vez, tanto emocionales (el hecho de que uno de los participantes no se encuentre en la posición de un adulto) como por la imperfección del propio proceso de trabajo. Quizás el tipo de conflicto más común que he encontrado son los conflictos durante las revisiones de código o las discusiones de arquitectura entre desarrolladores.
Destacaría aquí dos casos típicos:
1) En el primer caso, el desarrollador no puede obtener una revisión del código de un colega. El parche se envía para revisión y no pasa nada. A primera vista, no hay ningún conflicto obvio entre las dos partes, pero si lo piensas bien, es un gran conflicto. El tema laboral no se resuelve, una de las partes (a la espera de revisión) experimenta un evidente malestar. Un subtipo extremo de este caso es el desarrollo en una comunidad o en diferentes equipos, mientras que el revisor puede no estar interesado en este código en particular, debido a la carga u otras circunstancias, puede no prestar atención a la solicitud de revisión en absoluto, y el árbitro externo (un gerente común a ambas partes)) puede no existir en absoluto.
El enfoque de solución que ayuda en tal situación se relaciona precisamente con la perspectiva a largo plazo, la cultura de un adulto. Primero, la actividad inteligente funciona. No debe esperar que el código que aparece en la reseña atraiga la atención del propio revisor. Necesitamos ayudar a los críticos a notarlo. Pingani un par de personas, hacen una pregunta sobre sincape, participan en discusiones. Obviamente, es más probable que la importunidad haga daño que ayude, es necesario utilizar el sentido común. En segundo lugar, la preparación previa funciona bien. Si el equipo entiende lo que está sucediendo y por qué, por qué se necesita este código, el diseño se ha discutido y acordado de antemano con todos, es más probable que las personas presten atención a dicho código y lo acepten para trabajar. En tercer lugar, la autoridad funciona. Si desea que lo revisen, haga muchas revisiones usted mismo. Realice revisiones de alta calidad, con comprobaciones reales, pruebas reales y comentarios útiles. Si su apodo es bien conocido en el equipo, hay más posibilidades de que su código sea notado.
Desde el punto de vista del flujo de trabajo, las posibles mejoras aquí son una correcta priorización destinada a ayudar al desarrollador a lograr sus objetivos y los del equipo (revisar a otros, escribir cartas a la comunidad, acompañar el código con una descripción de la arquitectura, documentación, pruebas, participar en discusiones con comunidad, etc.), evita que los parches permanezcan en la cola durante demasiado tiempo, etc.
2) El segundo caso común de conflictos durante las revisiones de código o diseño son los diferentes puntos de vista sobre cuestiones técnicas, estilo de codificación y elección de herramientas. De gran importancia en este caso es el nivel de confianza entre los participantes, la pertenencia a un mismo equipo y la experiencia de trabajar juntos. Se produce un callejón sin salida cuando uno de los participantes adopta una posición infantil y no intenta escuchar lo que el interlocutor quiere transmitirle. A menudo, tanto el enfoque propuesto por la otra parte como el enfoque propuesto inicialmente pueden funcionar con éxito y, en principio, no importa cuál elegir.
Un día, un programador de mi equipo (llamémoslo Pasha) preparó un parche con cambios en el sistema de implementación de paquetes, que fue desarrollado y respaldado por colegas de un departamento vecino. Uno de ellos (Igor) tenía su propia opinión sobre cómo exactamente deberían configurarse los servicios de Linux al implementar paquetes. Esta opinión difería del enfoque propuesto en el parche y no pudieron ponerse de acuerdo. Como de costumbre, los plazos se estaban acabando y era necesario tomar algún tipo de decisión, era necesario que uno de ellos asumiera una posición adulta. Pasha reconoció que ambos enfoques tienen derecho a la vida, pero quería que se aprobara su opción, porque Ni una ni la segunda opción tenían ventajas técnicas obvias.
Nuestra discusión fue más o menos así (muy esquemáticamente, por supuesto, la conversación duró media hora):
- Pasha, tendremos una función congelada en unos días. Es importante que reunamos todo y comencemos a realizar las pruebas lo antes posible. ¿Cómo podemos superar a Igor?
— Quiere configurar los servicios de otra manera, me puso comentarios ahí...
- ¿Y qué hay, grandes cambios, mucho alboroto?
- No, hay trabajo por un par de horas, pero al final no hay diferencia, funcionará de cualquier manera, ¿por qué es necesario? Hice algo que funciona, aceptémoslo.
- Escucha, ¿cuánto tiempo llevas discutiendo todo esto?
- Sí, llevamos ya una semana y media marcando el tiempo.
- Um… ¿podemos solucionar en un par de horas un tema que ya ha tardado una semana y media, y no hacerlo?
- Bueno, sí, pero no quiero que Igor piense que cedí...
- Escucha, ¿qué es más importante para ti, emitir un comunicado, junto con tu decisión interna, o matar a Igor? Podemos bloquearlo, pero entonces existe una buena posibilidad de superarlo con la liberación.
- Bueno... sería genial, por supuesto, limpiarle la nariz a Igor, pero bueno, la liberación es más importante, estoy de acuerdo.
- ¿De verdad es tan importante para ti lo que piensa Igor? Para ser honesto, le importa un carajo, sólo quiere un enfoque unificado en diferentes áreas de lo que es responsable.
- Bueno, vale, déjame hacer lo que me pide en los comentarios y empecemos a probar.
- ¡Gracias Pasha! Estaba seguro de que de vosotros dos serías el más maduro, aunque Igorek es mayor que tú :)
El problema se resolvió, el lanzamiento se publicó a tiempo, Pasha no sintió mucha insatisfacción, porque él mismo propuso una solución y la implementó. En general, Igor estaba contento, porque... Su opinión fue tomada en cuenta e hicieron lo que sugirió.
Otro tipo de conflicto esencialmente el mismo es la elección entre soluciones/bibliotecas/enfoques técnicos en un proyecto, especialmente en un equipo distribuido. En uno de los proyectos, que se posicionaba como C/C++, resultó que la dirección técnica del proyecto estaba categóricamente en contra del uso de STL (Biblioteca de plantillas estándar). Esta es una biblioteca de lenguaje estándar que simplifica el desarrollo y nuestro equipo está muy acostumbrado a ella. Resultó que el proyecto está mucho más cerca de C que de C++, lo que no inspiró mucho al equipo, porque La gerencia hizo todo lo posible y reclutó jugadores geniales y geniales. Al mismo tiempo, la parte americana del equipo, tanto ingenieros como directivos, llevaban mucho tiempo trabajando en la empresa, estaban acostumbrados a la situación actual y estaban contentos con todo. La parte rusa del equipo se reunió hace poco, en unas pocas semanas (incluyéndome a mí). La parte rusa del equipo categóricamente no quiso abandonar el enfoque habitual de desarrollo.
Comenzaron interminables discusiones escritas entre los dos continentes, cartas en tres o cuatro pantallas iban y venían, en correos grupales y personales, de programadores a programadores y gerentes. Como suele ser el caso, cartas de esta extensión no fueron leídas excepto por los autores y sus fervientes partidarios. Los chats chirriaban de tensión, transmitían pensamientos en varias pantallas en diferentes direcciones sobre las ventajas técnicas del STL, lo bien probado que está, lo seguro que es y, en general, lo maravillosa que es la vida con él y lo terrible que es sin él. .
Todo esto duró bastante tiempo, hasta que finalmente me di cuenta de que estábamos discutiendo los aspectos técnicos del problema, pero en realidad el problema no era técnico. El problema no son las ventajas o desventajas de STL ni la dificultad de trabajar sin él. El problema es más bien organizativo. Sólo necesitábamos entender cómo funcionaba la empresa para la que trabajábamos. Ninguno de nosotros tenía experiencia trabajando en una empresa de este tipo antes. La cuestión es que después de que el código fue desarrollado y lanzado a producción, el soporte estuvo a cargo de personas completamente diferentes de otros equipos, de otros países. Este enorme equipo de ingenieros de varias decenas de miles de ingenieros (en total) sólo podía permitirse un mínimo absolutamente básico de medios técnicos, por así decirlo, un mínimo mínimo. Cualquier cosa que fuera físicamente más allá del estándar de ingeniería establecido en la empresa no podría ser soportado en el futuro. El nivel de un equipo está determinado por el nivel de sus miembros más débiles. después de que entendimos verdadera motivación Gracias a las acciones de la parte estadounidense del equipo, este tema se eliminó de la agenda y juntos desarrollamos y lanzamos con éxito el producto utilizando los estándares adoptados por la empresa. Las cartas y charlas en este caso no funcionaron bien; fueron necesarios varios viajes y mucha comunicación personal para llegar a un denominador común.
Desde el punto de vista del flujo de trabajo, en este caso particular, sería útil tener una descripción de las herramientas utilizadas, sus requisitos, las restricciones para agregar otras nuevas y la justificación de dichas restricciones. Dichos documentos corresponden aproximadamente a los descritos en los párrafos Estrategia de reutilización y entorno de desarrollo del “Manager's Handbook for Software Development”, desarrollado en . A pesar de su antigüedad, describe perfectamente todas las principales actividades y etapas de planificación del desarrollo de software de este tipo. Tener documentos como este hace que sea muy fácil discutir qué componentes y enfoques se pueden utilizar en un producto y por qué.
Desde un punto de vista cultural, obviamente, con una posición más madura, en la que las partes intentan escuchar y comprender la motivación real de las acciones de sus compañeros y actuar en función de las prioridades del proyecto y del equipo, y no del ego personal. , el conflicto se resolvería más fácil y rápidamente.
En otro conflicto sobre la elección de una solución técnica, también me tomó una cantidad considerable de tiempo comprender la motivación de una de las partes (fue un caso muy inusual), pero una vez que la motivación estuvo clara, la solución fue obvia.
La situación es la siguiente: aparece un nuevo desarrollador en un equipo de unas 20 personas, llamémoslo Stas. En aquel momento, nuestra herramienta estándar para la comunicación en equipo era Skype. Como resultó más tarde, Stas era un gran admirador de los estándares abiertos y el software de código abierto, y utilizaba sólo herramientas y sistemas operativos cuyas fuentes estaban disponibles públicamente y que utilizaban protocolos descritos públicamente. Skype no es una de estas herramientas. Pasamos mucho tiempo discutiendo las ventajas y desventajas de este enfoque, los intentos de lanzar análogos de Skype en diferentes sistemas operativos, los intentos de Stas de convencer al equipo de cambiar a otros estándares, escribirle personalmente por correo, llamarlo personalmente por teléfono. teléfono, comprarle una segunda computadora específicamente para Skype, etc. Finalmente, me di cuenta de que este problema, en esencia, no es técnico ni organizativo, sino más bien ideológico, incluso, se podría decir, religioso (para Stas). Incluso si finalmente conectáramos Stas y Skype (lo que llevó varios meses), el problema volvería a surgir en cualquier instrumento posterior. No tenía medios reales a mi disposición para cambiar la visión del mundo de Stas, y no había ninguna razón para intentar cambiar la visión del mundo de un equipo que funcionaba perfectamente en este entorno. La persona y la empresa eran simplemente ortogonales en su visión del mundo. En tales situaciones, una buena solución es organizativa. Transferimos a Stas a otro equipo, donde era más orgánico.
La razón de este conflicto, en mi opinión, es la discrepancia entre la cultura personal de una persona en particular (que tiene una opinión fuerte que no le permite ceder) y la cultura de la empresa. En este caso, por supuesto, se trata de un error del directivo. Inicialmente fue un error contratarlo para un proyecto de este tipo. Stas finalmente pasó a un proyecto de desarrollo de software de código abierto y se destacó allí.
Un buen ejemplo de un conflicto causado tanto por la actitud infantil del desarrollador como por las deficiencias del proceso de trabajo es una situación en la que, en ausencia de una definición de "hecho", el desarrollador y el equipo de control de calidad tienen expectativas diferentes con respecto a la preparación del la característica transferida a control de calidad. El desarrollador creía que era suficiente escribir el código y pasar la función por encima de la valla al control de calidad; ellos lo resolverían allí. Un programador bastante maduro y experimentado, por cierto, pero ese era su umbral interno de calidad. QA no estuvo de acuerdo con esto y exigió mostrarles y describirles lo que él mismo había verificado y les exigió un guión de prueba. Habían tenido problemas con la funcionalidad de este desarrollador en el pasado y no querían perder el tiempo nuevamente. Por cierto, tenían razón: la función realmente no funcionó, no verificó el código antes de enviarlo al control de calidad.
Para resolver la situación, le pedí que me mostrara que todo realmente funcionaba (no funcionó y tuvo que arreglarlo), hablamos con el equipo y con el QA la definición de hecho (no lo lograron en por escrito, porque no queríamos que el proceso fuera demasiado burocrático), bueno, pronto nos separamos de este especialista (para alivio general).
Desde el punto de vista del flujo de trabajo, las posibles mejoras en este caso son la presencia de una definición de lo hecho, los requisitos para el soporte de cada característica de la unidad y las pruebas de integración, y una descripción de las pruebas realizadas por el desarrollador. En uno de los proyectos, medimos el nivel de cobertura del código mediante pruebas durante la CI y si el nivel de cobertura caía después de agregar un parche, las pruebas se marcaban como fallidas, es decir, cualquier código nuevo solo podría agregarse si hubiera nuevas pruebas para él.
Otro ejemplo típico de conflicto muy relacionado con la organización del proceso de trabajo. Tenemos un producto, un equipo de desarrollo de producto, un equipo de soporte y un cliente. El cliente tiene problemas con el producto y contacta con soporte. El soporte analiza el problema y comprende que el problema está en el producto y lo transfiere al equipo del producto. El equipo de producto está muy ocupado, se acerca un lanzamiento, por lo que un ticket con un problema de un cliente, perdido entre los demás tickets del desarrollador al que está asignado, se cuelga durante varias semanas sin atención. El soporte cree que el desarrollador está trabajando en el problema del cliente. El cliente espera y espera que se esté solucionando su problema. En realidad, todavía no pasa nada. Después de algunas semanas, el cliente finalmente decide interesarse por el progreso y pregunta al soporte técnico cómo van las cosas. El soporte pide desarrollo. El desarrollador se estremece, mira la lista de tickets y encuentra allí un ticket del cliente. Al leer un ticket de un cliente, comprende que no hay suficiente información para resolver el problema y necesita más registros y volcados. El soporte solicita información adicional del cliente. Y entonces el cliente se da cuenta de que nadie ha estado trabajando en su problema durante todo este tiempo. Y el trueno caerá...
En esta situación, la solución al conflicto en sí es bastante obvia y lineal (arreglar el producto, actualizar la documentación y las pruebas, apaciguar al cliente, publicar una revisión, etc.). Es importante analizar el proceso de trabajo y comprender quién es responsable de organizar la interacción entre los dos equipos y por qué esta situación fue posible en primer lugar. Está claro lo que hay que corregir en el proceso: alguien debe controlar el panorama general sin recordatorios de los clientes, de forma proactiva. Los tickets del cliente deben destacarse entre otros tickets de los desarrolladores. El soporte debe ver si el equipo de desarrollo está trabajando actualmente en sus tickets y, de no ser así, cuándo puede comenzar a trabajar y cuándo se pueden esperar resultados. El soporte y el desarrollo deben comunicarse y discutir periódicamente el estado de los tickets, la recopilación de información necesaria para la depuración debe automatizarse tanto como sea posible, etc.
Así como en la guerra el enemigo intenta alcanzar el cruce entre dos unidades, en el trabajo el punto más delicado y vulnerable suele ser la interacción entre equipos. Si los gerentes de soporte y desarrollo tienen la edad suficiente podrán arreglar el proceso ellos mismos, si no, el proceso seguirá generando conflictos y problemas hasta que intervenga un gerente que pueda arreglar la situación.
Otro ejemplo típico que he visto repetidamente en diferentes empresas es una situación en la que un equipo escribe un producto, un segundo equipo escribe las pruebas de integración automática y un tercero acompaña la infraestructura en la que se opera todo. equipo. Los problemas al ejecutar pruebas surgen todo el tiempo, y la causa de los problemas en ellas puede ser tanto el producto como las pruebas y la infraestructura. Suele ser problemático ponerse de acuerdo sobre quién debe realizar el análisis inicial de los problemas, archivar errores, analizar los registros del producto, las pruebas y la infraestructura, etc. Los conflictos aquí son muy frecuentes y, al mismo tiempo, uniformes. En el caso de una alta intensidad emocional, los participantes a menudo caen en una posición infantil y en la serie comienzan las discusiones: "¿Por qué debería jugar con esto?", "Se derrumban más a menudo", etc.
Desde la perspectiva del flujo de trabajo, los pasos específicos para resolver un problema dependen de la composición de los equipos, el tipo de pruebas y producto, etc. En uno de los proyectos, introdujimos tareas periódicas, en las que los equipos monitoreaban las pruebas una por una, semana tras semana. En el otro, el análisis inicial siempre lo hacían los desarrolladores de pruebas, pero el análisis era muy básico y el producto era bastante estable, por lo que funcionó bien. La clave es garantizar que el proceso sea transparente, que las expectativas sean claras para todas las partes y que la situación parezca justa para todos.
¿Es el conflicto siquiera un problema en una organización? ¿Es una mala señal que los conflictos ocurran a menudo (o sólo periódicamente) en su equipo? En general no, porque si hay crecimiento, desarrollo, hay algún tipo de dinámica, entonces surgen temas que nunca antes se han resuelto, y al resolverlos pueden surgir conflictos. Este es un indicador de que algunas áreas necesitan atención, de que hay áreas que se pueden mejorar. Es malo que los conflictos surjan con mucha frecuencia, sean difíciles de resolver o lleven mucho tiempo. Lo más probable es que esto sea un signo de procesos de trabajo insuficientemente optimizados y de madurez insuficiente del equipo.
Fuente: habr.com