Epígrafe:
Un día, en el bosque, se encontraron Yozhik y Medvezhonok.
— ¡Hola, Yozhik!
— ¡Hola, Medvezhonok!
Así, palabra por palabra, broma tras broma, Yozhik recibió un golpe de Medvezhonok...
A continuación, reflexiones de nuestro líder de equipo, así como del director de desarrollo de productos RAS, Igor Marnat, sobre la naturaleza de los conflictos laborales y posibles métodos para gestionarlos.
La mayoría de los conflictos que enfrentamos en el trabajo se desarrollan de acuerdo con un escenario similar al descrito anteriormente en el epígrafe. Hay varios participantes, inicialmente bien dispuestos entre sí, que intentan resolver un asunto, pero al final el problema permanece sin resolver, y las relaciones entre los participantes de la discusión se ven perjudicadas por alguna razón.
La vida es diversa, en el escenario descrito anteriormente ocurren variaciones. A veces, las relaciones entre los participantes no son muy buenas desde el principio, a veces no hay ninguna cuestión que requiera una solución inmediata (como en el epígrafe), a veces después de la discusión las relaciones permanecen igual que antes de comenzar, pero el asunto finalmente no se resuelve.
¿Qué tienen en común todas las situaciones que pueden definirse como una situación de conflicto laboral?
En primer lugar, existe la presencia de dos o más partes. Estas partes pueden estar en diferentes niveles dentro de la organización, ser iguales (colegas en el equipo) o estar en diferentes niveles jerárquicos (jefe — subordinado), pueden ser individuales (empleado) o grupales (en el caso de un conflicto entre un empleado y un equipo o entre dos equipos), etc. El nivel de confianza entre los participantes influye mucho en la probabilidad de conflicto y en la facilidad para resolverlo. Cuanto mejor se conocen las partes, cuanto mayor sea el nivel de confianza, mayor será la posibilidad de que lleguen a un acuerdo. Por ejemplo, los miembros de un equipo distribuido que nunca han interactuado en persona tienen más probabilidades de entrar en una situación de conflicto al resolver un simple asunto laboral que aquellas personas que se han encontrado al menos unas pocas veces en persona. Por lo tanto, al trabajar en equipos distribuidos, es muy importante asegurar reuniones personales periódicas entre todos los miembros del equipo.
En segundo lugar, en una situación de conflicto en el trabajo, las partes se encuentran en la situación de resolver alguna cuestión que es importante para una de las partes, para ambas o para la organización en general. En este caso, debido a la especificidad de la situación, las partes suelen tener suficiente tiempo y diversos métodos para resolverla (formales, informales, reuniones, cartas, decisiones de la dirección, existencia de objetivos y planes del equipo, la jerarquía, etc.). Esta es la diferencia con respecto a la resolución de un asunto laboral (o no laboral) en la organización en comparación con, por ejemplo, la resolución de un tema importante: “¡Eh, chico, ¿de qué barrio eres?!” en la calle, o el conflicto del epígrafe. En el caso de la resolución de una cuestión laboral, son importantes la calidad del proceso de trabajo y la cultura de resolución de problemas en el equipo.
En tercer lugar, un factor determinante del conflicto (desde el punto de vista de nuestra discusión) es el hecho de que las partes del proceso no pueden llegar por sí solas a una solución que satisfaga a todas las partes. La situación requiere la intervención de un tercero, un árbitro externo. Este punto puede parecer polémico, pero, esencialmente, si la situación conflictiva 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, esa es la situación a la que hay que aspirar. Probablemente, de tal conflicto ni siquiera nos enteremos, o lo haremos por casualidad después de su resolución. Cuantas más cuestiones pueda resolver el equipo por sí mismo, más eficaz será su funcionamiento.
Otra característica del conflicto que vale la pena abordar es el grado de carga emocional durante la resolución. Un conflicto no necesariamente está relacionado con un alto grado de emoción. No es imprescindible que los participantes griten y agiten las manos para que la situación, en esencia, sea conflictiva. La cuestión no se resuelve, existe cierta tensión emocional (puede que no se exprese claramente hacia afuera), lo que significa que estamos ante una situación de conflicto.
¿Es necesario intervenir en situaciones conflictivas, o es mejor dejar que se resuelvan solas y esperar a que el problema se disuelva por sí mismo? Sí, es necesario. No siempre está en tu poder o competencia resolver completamente un conflicto, pero en cualquier situación, en un conflicto de cualquier magnitud, puedes adoptar una postura madura, sacando a otras personas a tu alrededor, suavizando las consecuencias negativas del conflicto y contribuyendo a su resolución.
Antes de considerar algunos ejemplos de situaciones conflictivas, hablemos de algunos puntos importantes que son comunes a todos los conflictos.
Al resolver un conflicto, es importante estar por encima del problema y no dentro de él (esto también se llama “adoptar una metapositión”), es decir, no formar parte de uno de los lados en el proceso de resolución. De lo contrario, en lugar de actuar como un árbitro externo que ayuda a la resolución, solo reforzarás la posición de uno de los lados a expensas del otro. Al tomar una decisión, es esencial que sea moralmente aceptada por todas las partes, como se dice, 'comprada'. Para que, incluso si las partes no estaban emocionadas con la decisión tomada, al menos estén sinceramente de acuerdo en cumplirla. Lo que se conoce como estar en disposición de disentir y comprometerse. De lo contrario, el conflicto simplemente cambiará de forma, el fuego humeante permanecerá bajo el terreno y en algún momento, inevitablemente, volverá a resurgir.
El segundo punto, relacionado en parte con el primero, es que si vas a involucrarte en la resolución de un conflicto, debes tomarlo muy en serio desde el punto de vista de la comunicación y el estudio del contexto. Habla personalmente con cada una de las partes. Primero de forma individual. No te limites al correo electrónico. En el caso de un equipo distribuido, habla al menos por videoconferencia. No te conformes con rumores y relatos de testigos. Comprende la historia, qué desea cada parte, por qué lo quiere, qué espera, si han intentado resolver este asunto antes, qué pasará si no se resuelve, qué opciones de solución ven, cómo imaginan la posición de la otra parte, qué consideran correcto o incorrecto, etc. Carga en tu mente todo el contexto posible, de manera imparcial, asumiendo que todos tienen razón. Tú no estás dentro del conflicto, estás afuera, en una metaposición. Si el contexto solo está disponible en un hilo de correo, al menos léelo completo y revisa los hilos y documentos relacionados. Después de haber leído, aún así, habla con voz. Casi garantizado escucharás algo importante que no está en el correo.
El tercer punto importante es el enfoque general de la comunicación. Son cosas normales, nada cósmico, pero tienen una gran importancia. No tratemos de ahorrar tiempo, hablemos con todos los participantes, critiquemos no a la persona, sino consideremos las consecuencias de sus acciones (no 'eres grosero', sino 'quizás los chicos puedan sentirse ofendidos por esto'), damos la oportunidad de mantener la cara, y realizamos las discusiones en persona, no en público.
Los conflictos suelen ser causados por una de dos razones. La primera está relacionada con si la persona, en el momento del conflicto, está en la posición de un adulto o en la de un niño (sobre esto más adelante). Esto está ligado 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 laboral, que crea situaciones de zonas grises, en las que la responsabilidad está difusa entre los participantes, las expectativas de las partes no son claras entre sí y los roles en el proceso son borrosos.
Por lo tanto, al resolver un conflicto (así como cualquier otra cuestión), el gerente debe tener en cuenta tres perspectivas: la a corto plazo — resolver el asunto/conflicto aquí y ahora, la a mediano plazo — minimizar la probabilidad de que surja otro conflicto por la misma razón, y la a largo plazo — fomentar en el equipo una cultura de adulto.
Dentro de cada uno de nosotros hay un niño interior, de aproximadamente tres a cuatro años. La mayor parte del tiempo en el trabajo, está dormido, pero a veces se despierta y asume el control. El niño tiene sus propias prioridades. Es importante para él insistir en que este es su arenero, que mamá lo quiere más, que su cochecito es el mejor (su diseño es el mejor, programa mejor que nadie, ...). En una situación de conflicto, el niño puede agarrar juguetes, hacer pucheros y golpear con la pala, pero no puede resolver problemas de adultos (arquitectura de soluciones, enfoques para pruebas automáticas, tiempos de lanzamiento, etc.), no piensa en términos de beneficio para el equipo. En el conflicto, se puede alentar, consolar y enviar al niño a dormir, pidiéndole que llame a su adulto. Antes de comenzar una discusión en un contexto de conflicto, asegúrese de que está hablando con un adulto y no con un niño, y usted mismo debe estar en la posición de adulto. Si su objetivo sincero en este momento es resolver un problema serio, usted está en la posición de un adulto. Si su objetivo es hacer pucheros y golpear con la pala, esa es una posición infantil. Envíe a su niño interior a dormir y llame a su adulto, o posponga la discusión. Una persona toma una decisión emocional y luego busca una justificación racional para ella. La decisión tomada por el niño, basada en prioridades infantiles, no será óptima.
Además del comportamiento en el momento del conflicto, la posición infantil o adulta también se caracteriza por el nivel de responsabilidad que una persona está dispuesta a asumir. En las manifestaciones extremas, la posición infantil de un programador, que he encontrado en numerosas ocasiones, se presenta así: escribí el código, lo envié para revisión — mi trabajo ha terminado. Los revisores deben revisarlo y fusionarlo, QA debe comprobarlo; si hay problemas, me lo harán saber. Curiosamente, incluso personas bastante adultas y experimentadas a veces se comportan de esta manera. En el otro extremo de la escala, una persona se considera responsable de que su código funcione, esté cubierto por pruebas, sea revisado personalmente, pase con éxito la revisión (si es necesario, no hay problema en contactar a los revisores, discutir cuestiones de voz, etc.) y sea fusionado; QA, si es necesario, recibirá ayuda, se describirán los escenarios de prueba, etc. En casos normales, el programador se encuentra inicialmente más cerca del extremo adulto de la escala, o se desplaza hacia allí a medida que acumula experiencia (siempre que en el equipo se cultive la cultura correcta). En casos extremos, sin embargo, continúa trabajando, generalmente ocupando una posición infantil, y entonces él y su equipo enfrentan periódicamente problemas y conflictos.
Fomentar una cultura adecuada y adulta en el equipo es una tarea importante para cualquier gerente. Requiere tiempo prolongado y esfuerzos diarios, pero el resultado vale la pena. Hay dos maneras de influir en la cultura del equipo: el ejemplo personal (que será seguido, el equipo siempre observa al líder) y la discusión y promoción del comportamiento adecuado. Aquí también no hay nada complicado o excesivamente formal, simplemente en las discusiones sobre problemas, señala lo que se podría haber hecho de otra manera, destaca cuando notas que se ha resuelto correctamente, elogia, menciona en el análisis de la publicación, etc.
Veamos algunas situaciones conflictivas típicas, de simple a compleja:
Conflictos no relacionados con cuestiones laborales
Con bastante frecuencia ocurren en el trabajo conflictos no relacionados con cuestiones laborales. Su aparición y la facilidad de resolución suelen estar directamente vinculadas al nivel de inteligencia emocional de los participantes, al nivel de su madurez, y no están relacionadas con la perfección o imperfección del proceso de trabajo.
Ejemplos típicos: alguien no utiliza la lavadora o la ducha con suficiente frecuencia, lo que molesta a los demás; a algunas personas les hace calor, mientras que a otras les da corriente si se abre la ventana; alguien es demasiado ruidoso, mientras que los demás necesitan silencio para trabajar, y así sucesivamente. Es mejor no retrasar la resolución de conflictos de este tipo y no dejar que se empeoren. Por sí solos no se resolverán y distraerán diariamente del trabajo, envenenando la atmósfera en el equipo. Afortunadamente, resolverlos generalmente no es un gran problema: basta con hablar calmadamente (por supuesto, uno a uno) con el colega que descuida la higiene, asegurar una disposición cómoda para las personas que prefieren el silencio o el frescor, comprar auriculares absorbentes de sonido o instalar tabiques, etc.
Otro ejemplo, que he encontrado varias veces en mi trabajo, es la incompatibilidad psicológica entre 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 a que las personas sostienen opiniones opuestas sobre algún tema candente (generalmente político) y no saben dejarlo fuera del trabajo. Convencerlas de tolerarse mutuamente o cambiar su comportamiento es un ejercicio bastante fútil. La única excepción que he encontrado son los jóvenes colegas con una percepción abierta; su comportamiento aún se puede cambiar gradualmente a través de conversaciones periódicas. Normalmente, el problema se resuelve eficazmente separándolos en diferentes equipos o, al menos, asegurando que tengan la oportunidad de cruzarse muy rara vez en el trabajo.
En todas las situaciones mencionadas, es importante hablar con todos los participantes de manera personal, discutir la situación, preguntarles si ven algún problema en este caso, y preguntarles qué caminos ven para resolverlo, asegurando su participación en la toma de decisiones.
Desde la perspectiva de optimización del proceso de trabajo (la perspectiva a medio plazo que mencioné), no se puede hacer mucho; el único aspecto que se puede optimizar es considerar el factor de compatibilidad al formar equipos y no reunir anticipadamente a personas que van a entrar en conflicto.
Desde el punto de vista de la cultura del equipo, tales situaciones ocurren con mucha menos frecuencia en equipos con una cultura madura, donde las personas respetan al equipo y a sus colegas y son capaces de resolver problemas por sí mismas. Además, tales conflictos se resuelven mucho más fácilmente (a menudo de manera automática) en equipos donde hay un alto nivel de confianza, donde las personas han trabajado juntas durante mucho tiempo y/o tienen frecuencia de comunicación fuera del trabajo.
Conflictos relacionados con cuestiones laborales:
Tales conflictos suelen ser causados por ambas razones a la vez, tanto emocionales (debido a que uno de los participantes no se encuentra en una posición adulta) como por la imperfección del propio proceso laboral. El tipo de conflicto más común que he encontrado es el conflicto en el proceso de revisión de código o discusión de arquitectura entre desarrolladores.
Destacaría aquí dos casos típicos:
1) En el primer caso, un desarrollador no puede obtener la revisión de código de un colega. El parche se ha enviado para revisión y no sucede nada. A primera vista, no hay un conflicto evidente entre las dos partes, pero, al reflexionar, se trata de un conflicto en toda regla. La cuestión laboral no se resuelve, una de las partes (la que espera la revisión) experimenta un claro malestar. Un extremo de este caso es el desarrollo en comunidad o en diferentes equipos, donde el revisor puede no estar interesado en este código en particular, debido a su carga de trabajo o a otras circunstancias, puede incluso ignorar la solicitud de revisión, y puede no haber un árbitro externo (un gerente común para ambas partes) en absoluto.
El enfoque para resolver situaciones como esta se refiere a una perspectiva a largo plazo y a la cultura de un adulto. Primero, la actividad razonable es crucial. No se debe esperar que el código que está en revisión llame la atención del revisor por sí mismo. Hay que ayudar a los revisores a notarlo. Contacta a un par de personas, plantea preguntas en la reunión, participa en las discusiones. Es evidente que ser insistente puede hacer más daño que bien, por lo que es necesario aplicar el sentido común. En segundo lugar, la preparación previa funciona muy bien. Si el equipo entiende qué y por qué está sucediendo, y para qué se necesita dicho código, y si el diseño ha sido discutido y acordado con todos de antemano, es más probable que la gente preste atención a ese código y lo acepte para su trabajo. En tercer lugar, el autoridad juega un papel importante. Si quieres que revisen tu trabajo, asegúrate de hacer muchas revisiones tú mismo. Realiza revisiones de calidad, con comprobaciones reales, pruebas efectivas y comentarios útiles. Si tu nombre es conocido en el equipo por buena razones, hay más posibilidades de que te presten atención.
Desde el punto de vista del flujo de trabajo, las posibles mejoras aquí son el establecimiento correcto de prioridades, que ayuda al desarrollador a alcanzar sus metas y las del equipo (revisar el trabajo de otros, escribir correos en la comunidad, acompañar el código con descripciones de arquitectura, documentación, pruebas, participar en discusiones comunitarias, etc.), evitando que los parches queden demasiado tiempo en la cola, entre otras cosas.
2) El segundo caso común de conflictos en la revisión de código o diseño son las diferentes opiniones sobre cuestiones técnicas, estilo de codificación y selección de herramientas. El nivel de confianza entre los participantes, la pertenencia al mismo equipo y la experiencia en trabajos conjuntos tienen un impacto enorme. La parálisis ocurre cuando uno de los participantes adopta una postura infantil y no intenta escuchar lo que su interlocutor quiere comunicar. Con frecuencia, tanto el enfoque propuesto por la otra parte como el inicialmente sugerido pueden funcionar con éxito, y no importa realmente cuál elegir.
Una vez, un programador de mi equipo (llamémoslo Pasha) preparó un parche con cambios en el sistema de despliegue de paquetes, que fue desarrollado y mantenido por colegas de un departamento vecino. Uno de ellos (Igor) tenía una fuerte opinión sobre cómo debían configurarse los servicios de Linux al desplegar paquetes. Esta opinión difería del enfoque propuesto en el parche, y no lograban llegar a un acuerdo. Como de costumbre, el tiempo apremiaba, y había que llegar a alguna solución, alguien tenía que adoptar una postura madura. Pasha reconocía que ambos enfoques eran válidos, pero quería que su opción prevaleciera, ya que no había ventajas técnicas evidentes en ninguno de los dos casos.
Nuestra discusión se parecía a esto (muy esquemáticamente, por supuesto, la conversación duró media hora):
— Pasha, en unos días tenemos el congelamiento de características. Es importante que todo esté compilado y empecemos las pruebas lo antes posible. ¿Cómo podemos pasar por Igor?
— Él quiere configurar los servicios de otra manera, me llenó de comentarios…
— ¿Y qué, son grandes cambios, mucho trabajo?
— No, en realidad solo son un par de horas de trabajo, pero al final no hay diferencia, funcionará de una forma u otra, ¿para qué hacerlo? Hice algo que funciona, aceptémoslo.
— Oye, ¿cuánto tiempo llevas discutiendo esto?
— Ya llevamos más de una semana con esto.
— Em… ¿podemos resolver en un par de horas un problema que ya ha tomado una semana y media y no lo estamos haciendo?
— Bueno, sí, pero no quiero que Igor piense que capitulé…
— Oye, ¿qué es más importante para ti, lanzar la versión con tu solución o vencer a Igor? Podemos vencerlo, aunque, de verdad, tenemos una buena posibilidad de fallar con el lanzamiento.
— Bueno… sería genial, por supuesto, darle una lección a Igor, pero está bien, el lanzamiento es más importante, acuerdo.
— ¿Realmente te importa tanto lo que piensa Igor? Honestamente, a él le importa bastante poco, solo quiere un enfoque uniforme en diferentes partes de la cosa por la que es responsable.
— Bueno, vale, haré lo que él pide en los comentarios y empezaremos las pruebas.
— Gracias, Pasha! Estaba seguro de que de ustedes dos serías el más maduro, aunque Igor sea mayor que tú :)
La cuestión se resolvió, el lanzamiento se realizó a tiempo, Pasha no estaba especialmente descontento, ya que él mismo propuso la solución y la implementó. Igor, en general, estaba satisfecho, ya que se tuvo en cuenta su opinión y se hizo como él había sugerido.
Otro tipo del mismo conflicto, en esencia, es la elección entre soluciones técnicas / bibliotecas / enfoques en el proyecto, especialmente en un equipo distribuido. En uno de los proyectos, que se posicionaba como utilizando C / C++, resultó que la gestión técnica del proyecto estaba categóricamente en contra del uso de la STL (Standard Template Library). Esta es una biblioteca estándar del lenguaje que simplifica el desarrollo, nuestro equipo estaba muy acostumbrado a ella. Resultó que el proyecto estaba mucho más cerca de C que de C++, lo que no inspiró mucho al equipo, dado que la gestión había hecho un gran esfuerzo y había reunido realmente a unos genios de C++. Mientras tanto, la parte americana del equipo, tanto ingenieros como gerentes, había estado trabajando en la empresa durante mucho tiempo, estaban acostumbrados a la situación actual, todo les parecía bien. La parte rusa del equipo se reunió recientemente, en unas pocas semanas (incluyéndome a mí). La parte rusa del equipo no quería de ninguna manera renunciar al enfoque habitual del desarrollo.
Comenzaron discusiones escritas interminables entre dos continentes, correos de tres a cuatro pantallas volaban de un lado a otro, en distribuciones grupales y personales, de programadores a programadores y gerentes. Como suele suceder, nadie, excepto los autores y sus fervientes partidarios, leía correos de tal tamaño. Los chats chirriaban de tensión, compartiendo en distintas direcciones consideraciones de múltiples pantallas sobre las ventajas técnicas de la STL, cuán bien estaba probada, cuán segura es y, en general, cuán maravillosa es la vida con ella, y cuán terrible sin ella.
Todo esto duró bastante tiempo, hasta que finalmente entendí que estábamos discutiendo aspectos técnicos, mientras que el problema en realidad no era técnico. El problema no radicaba en las ventajas o desventajas de STL o en la complejidad de trabajar sin ella. Más bien, era un problema organizativo. Solo necesitábamos entender cómo estaba estructurada la empresa en la que trabajábamos. Anteriormente, ninguno de nosotros tenía experiencia en una empresa así. El hecho era que después de desarrollar el código y lanzarlo a producción, el soporte era manejado por personas completamente diferentes de otros equipos, de otros países. Este enorme equipo de ingeniería de varios miles de ingenieros (en total) solo podía permitirse un mínimo absolutamente básico de medios técnicos, por así decirlo, el minimum minimorum. Todo lo que iba más allá del estándar técnico que existía en la empresa no podía ser soportado físicamente en el futuro. El nivel de un equipo se define por el nivel de sus miembros más débiles. Después de que entendimos la motivación real de las acciones del equipo estadounidense, este asunto fue retirado de la agenda, y juntos desarrollamos y lanzamos el producto, utilizando los estándares aceptados en la empresa. En este caso, los correos y los chats funcionaron mal, necesitaron varios viajes y mucha comunicación personal para llegar a un entendimiento común.
Desde el punto de vista del proceso de trabajo, en este caso específico, habría sido útil tener una descripción de los medios utilizados, requisitos para ellos, limitaciones para la adición de nuevos, justificación de tales limitaciones. Dichos documentos corresponden aproximadamente a los descritos en los puntos Reuse Strategy y Development Environment del manual “Manager’s Handbook for Software Development”, desarrollado en . A pesar de su antigüedad, describe muy bien todas las actividades principales y las etapas de planificación del desarrollo de software de este tipo. La existencia de tales documentos simplifica mucho el proceso de discusión sobre qué componentes y enfoques pueden ser utilizados en el producto y por qué.
Desde el punto de vista cultural, es evidente que con una postura más madura, en la que las partes intentan escuchar y entender la motivación real de las acciones de sus colegas y actúan basándose en las prioridades del proyecto y del equipo, en lugar de su ego personal, el conflicto se resolvería de manera más sencilla y rápida.
En otro conflicto relacionado con la elección de una solución técnica, también me tomó un tiempo considerable entender la motivación de una de las partes (el caso era bastante inusual), pero una vez que la motivación se hizo clara, la decisión fue evidente.
La situación es la siguiente: en un equipo de aproximadamente 20 personas, aparece un nuevo desarrollador, llamémoslo Stas. Nuestra herramienta estándar para la comunicación en el equipo en ese momento era Skype. Como luego se descubrió, Stas era un gran fanático de los estándares abiertos y del software de código abierto, y solo utilizaba herramientas y sistemas operativos cuyos códigos fuente estaban disponibles públicamente y que utilizaban protocolos descritos públicamente. Skype no pertenece a estas herramientas. Pasamos una cantidad ingente de tiempo discutiendo las ventajas y desventajas de este enfoque, intentando ejecutar alternativas a Skype en diferentes sistemas operativos, intentando convencer a Stas de que el equipo adoptara otros estándares, escribiéndole personalmente por correo, llamándole por teléfono, comprándole un segundo ordenador especialmente para Skype, etc. Finalmente, me di cuenta de que este problema, en esencia, no era técnico ni organizacional; era más bien una cuestión de cosmovisión, incluso se podría decir que era religiosa (para Stas). Incluso si hubiéramos logrado conectar a Stas con Skype (lo cual ya había tomado varios meses), el problema surgiría nuevamente con cualquier herramienta siguiente. No tenía medios reales para cambiar la cosmovisión de Stas, y no había motivos para intentar cambiar la cosmovisión de un equipo que funcionaba perfectamente en ese entorno. La persona y la empresa simplemente eran ortogonales en términos de cosmovisión. En situaciones como esta, una buena opción de solución es organizativa. Transferimos a Stas a otro equipo, donde él encajaba mejor.
La razón de este conflicto, en mi opinión, radica en la discrepancia entre la cultura personal de un individuo concreto (que tiene una opinión fuerte que no le permite comprometerse) y la cultura de la empresa. En este caso, es, por supuesto, un error del gerente. Fue incorrecto desde el principio contratarlo para un proyecto de este tipo. Al final, Stas se unió a un proyecto de desarrollo de software abierto y allí prosperó maravillosamente.
Un buen ejemplo de conflicto, causado por la postura infantil del desarrollador y las deficiencias en el proceso de trabajo, es la situación en la que, en ausencia de la definición de terminado, el desarrollador y el equipo de QA tienen diferentes expectativas sobre la preparación de una característica pasada a QA. El desarrollador creía que era suficiente escribir el código y pasar la característica al QA; ahí se encargarían de ello. Por cierto, era un programador bastante maduro y experimentado, pero tenía un umbral de calidad interno muy bajo. El equipo de QA no estaba de acuerdo y exigía que se les mostrara y describiera qué había verificado por su cuenta, además de requerir un escenario de prueba para ellos. Ya habían tenido problemas en el pasado con la funcionalidad de este desarrollador y no querían perder su tiempo otra vez. De hecho, tenían razón: la característica realmente no funcionaba; no verificó el código antes de enviarlo a QA.
Para resolver la situación, le pedí que me mostrara que todo funcionaba realmente (no funcionaba y tuvo que arreglarlo), hablamos con el equipo y con QA sobre la definición de terminado (no decidimos escribirla, ya que no queríamos burocratizar demasiado el proceso), y pronto nos despedimos de este especialista (para alivio general).
Desde el punto de vista del proceso de trabajo, las posibles mejoras en este caso son la existencia de una definición de terminado, los requisitos para acompañar cada característica con pruebas unitarias e integradas, y la descripción de las pruebas realizadas por el desarrollador. En uno de los proyectos, medimos el nivel de cobertura de código con pruebas durante CI, y en caso de que el nivel de cobertura cayera después de agregar un parche, las pruebas se marcaban como fallidas, es decir, cualquier nuevo código solo podía ser agregado si contaba con nuevas pruebas para ello.
Otro ejemplo típico de conflicto, estrechamente relacionado con la organización del flujo de trabajo. Tenemos un producto, un equipo de desarrollo de este producto, un equipo de soporte y un cliente. El cliente tiene problemas con el producto y se pone en contacto con el soporte. El soporte analiza el problema y se da cuenta de que la cuestión está en el producto, por lo que pasa el problema al equipo del producto. El equipo del producto está en una época de mucho trabajo, se avecina un lanzamiento, así que el ticket con el problema del cliente, perdido entre otros tickets del desarrollador al que se le asignó, queda sin atención durante varias semanas. El soporte piensa que el desarrollador está trabajando en el problema del cliente. El cliente espera y confía en que su problema está siendo atendido. En realidad, no está ocurriendo nada. Después de unas semanas, el cliente finalmente decide preguntar por el progreso y pregunta al soporte cómo van las cosas. El soporte consulta al desarrollo. El desarrollador se sorprende, revisa la lista de tickets y descubre el ticket del cliente. Al leer el ticket del cliente, se da cuenta de que la información para resolver el problema es insuficiente y que necesita más registros y volcado de datos. El soporte solicita información adicional al cliente. Y en ese momento el cliente se da cuenta de que nadie ha estado trabajando en su problema todo este tiempo. Y el trueno retumbará...
En esta situación, la solución del conflicto es bastante evidente y lineal (arreglar el producto, actualizar la documentación y las pruebas, apaciguar al cliente, lanzar un hotfix, etc.). Es importante analizar el flujo de trabajo y entender quién es responsable de organizar la interacción entre ambos equipos y por qué esta situación se hizo posible en primer lugar. Está claro que hay que arreglar el proceso: alguien debería monitorear la imagen general sin recordatorios de los clientes, de forma proactiva. Los tickets del cliente deberían destacarse entre los demás tickets de los desarrolladores. El soporte debe ver si el desarrollo está trabajando en sus tickets en ese momento; si no, cuándo podrá comenzar a trabajar, cuándo se puede esperar un resultado. El soporte y el desarrollo deben comunicarse periódicamente y discutir el estado de los tickets, la recolección de la información necesaria para la depuración debe ser lo más automatizada posible, etc.
Así como en la guerra el enemigo intenta golpear en la unión entre dos unidades, en el trabajo el aspecto más delicado y vulnerable suele ser la interacción entre los equipos. Si los gerentes de soporte y desarrollo son lo suficientemente maduros, podrán solucionar el proceso por sí mismos; de lo contrario, el proceso seguirá generando conflictos y problemas hasta que intervenga un gerente capaz de arreglar la situación.
Otro ejemplo característico que he encontrado repetidamente en diferentes empresas es la situación en la que un equipo desarrolla el producto, un segundo equipo realiza las pruebas de integración automatizadas y la infraestructura en la que todo esto se ejecuta es gestionada por un tercer equipo. Los problemas durante la ejecución de las pruebas surgen constantemente, y las causas pueden ser tanto el producto como las pruebas y la infraestructura. Suele ser problemático ponerse de acuerdo sobre quién debe llevar a cabo el análisis inicial de los problemas, registrar los errores, analizar los registros del producto, de las pruebas y de la infraestructura, etc. Los conflictos son bastante frecuentes y, a su vez, bastante uniformes. En situaciones de alta carga emocional, los participantes a menudo adoptan una posición infantil y comienzan discusiones como: "¿por qué debo ocuparme de esto?", "es más frecuente que se rompa por su parte", etc.
Desde el punto de vista del flujo de trabajo, los pasos específicos para abordar el problema dependen de la composición de los equipos, el tipo de pruebas y del producto, etc. En uno de los proyectos, implementamos turnos periódicos donde los equipos monitoreaban las pruebas por turnos, semanalmente. En otro, el análisis inicial siempre lo realizaban los desarrolladores de las pruebas, pero dicho análisis era bastante básico y el producto era lo suficientemente estable, así que funcionaba razonablemente bien. Lo principal es garantizar la transparencia del proceso, la claridad de las expectativas para todas las partes y la sensación de justicia en la situación para todos.
¿Es realmente el conflicto en la organización un problema, es un mal indicio que en su equipo surjan conflictos a menudo (o simplemente de manera periódica)? En general, no, porque si hay crecimiento, desarrollo, hay cierta dinámica, surgen preguntas que nunca antes se habían resuelto, lo que puede generar conflictos. Esto indica que hay áreas a las que debería prestarse atención, que hay oportunidades de mejora. Es negativo si los conflictos surgen con demasiada frecuencia, son difíciles de resolver o tardan mucho en solucionarse. Esto es, probablemente, un signo de procesos de trabajo poco definidos y de una falta de madurez en el equipo.
Fuente: habr.com
