<\/a><\/noindex>En segundo lugar, en una situaci\u00f3n de conflicto en el trabajo, las partes se encuentran en la situaci\u00f3n de resolver alguna cuesti\u00f3n que es importante para una de las partes, para ambas o para la organizaci\u00f3n en general. En este caso, debido a la especificidad de la situaci\u00f3n, las partes suelen tener suficiente tiempo y diversos m\u00e9todos para resolverla (formales, informales, reuniones, cartas, decisiones de la direcci\u00f3n, existencia de objetivos y planes del equipo, la jerarqu\u00eda, etc.). Esta es la diferencia con respecto a la resoluci\u00f3n de un asunto laboral (o no laboral) en la organizaci\u00f3n en comparaci\u00f3n con, por ejemplo, la resoluci\u00f3n de un tema importante: \u201c\u00a1Eh, chico, \u00bfde qu\u00e9 barrio eres?!\u201d en la calle, o el conflicto del ep\u00edgrafe. En el caso de la resoluci\u00f3n de una cuesti\u00f3n laboral, son importantes la calidad del proceso de trabajo y la cultura de resoluci\u00f3n de problemas en el equipo.<\/p>\n
En tercer lugar, un factor determinante del conflicto (desde el punto de vista de nuestra discusi\u00f3n) es el hecho de que las partes del proceso no pueden llegar por s\u00ed solas a una soluci\u00f3n que satisfaga a todas las partes. La situaci\u00f3n requiere la intervenci\u00f3n de un tercero, un \u00e1rbitro externo. Este punto puede parecer pol\u00e9mico, pero, esencialmente, si la situaci\u00f3n conflictiva se resolvi\u00f3 con \u00e9xito sin la intervenci\u00f3n de un \u00e1rbitro externo, la cuesti\u00f3n se resolvi\u00f3 con \u00e9xito y las relaciones entre las partes no se deterioraron, esa es la situaci\u00f3n a la que hay que aspirar. Probablemente, de tal conflicto ni siquiera nos enteremos, o lo haremos por casualidad despu\u00e9s de su resoluci\u00f3n. Cuantas m\u00e1s cuestiones pueda resolver el equipo por s\u00ed mismo, m\u00e1s eficaz ser\u00e1 su funcionamiento.<\/p>\n
Otra caracter\u00edstica del conflicto que vale la pena abordar es el grado de carga emocional durante la resoluci\u00f3n. Un conflicto no necesariamente est\u00e1 relacionado con un alto grado de emoci\u00f3n. No es imprescindible que los participantes griten y agiten las manos para que la situaci\u00f3n, en esencia, sea conflictiva. La cuesti\u00f3n no se resuelve, existe cierta tensi\u00f3n emocional (puede que no se exprese claramente hacia afuera), lo que significa que estamos ante una situaci\u00f3n de conflicto.<\/p>\n
\u00bfEs necesario intervenir en situaciones conflictivas, o es mejor dejar que se resuelvan solas y esperar a que el problema se disuelva por s\u00ed mismo? S\u00ed, es necesario. No siempre est\u00e1 en tu poder o competencia resolver completamente un conflicto, pero en cualquier situaci\u00f3n, 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\u00f3n.<\/p>\n
Antes de considerar algunos ejemplos de situaciones conflictivas, hablemos de algunos puntos importantes que son comunes a todos los conflictos.<\/p>\n
Al resolver un conflicto, es importante estar por encima del problema y no dentro de \u00e9l (esto tambi\u00e9n se llama \u201cadoptar una metapositi\u00f3n\u201d), es decir, no formar parte de uno de los lados en el proceso de resoluci\u00f3n. De lo contrario, en lugar de actuar como un \u00e1rbitro externo que ayuda a la resoluci\u00f3n, solo reforzar\u00e1s la posici\u00f3n de uno de los lados a expensas del otro. Al tomar una decisi\u00f3n, 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\u00f3n tomada, al menos est\u00e9n sinceramente de acuerdo en cumplirla. Lo que se conoce como estar en disposici\u00f3n de disentir y comprometerse. De lo contrario, el conflicto simplemente cambiar\u00e1 de forma, el fuego humeante permanecer\u00e1 bajo el terreno y en alg\u00fan momento, inevitablemente, volver\u00e1 a resurgir.<\/p>\n
El segundo punto, relacionado en parte con el primero, es que si vas a involucrarte en la resoluci\u00f3n de un conflicto, debes tomarlo muy en serio desde el punto de vista de la comunicaci\u00f3n y el estudio del contexto. Habla personalmente con cada una de las partes. Primero de forma individual. No te limites al correo electr\u00f3nico. 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\u00e9 desea cada parte, por qu\u00e9 lo quiere, qu\u00e9 espera, si han intentado resolver este asunto antes, qu\u00e9 pasar\u00e1 si no se resuelve, qu\u00e9 opciones de soluci\u00f3n ven, c\u00f3mo imaginan la posici\u00f3n de la otra parte, qu\u00e9 consideran correcto o incorrecto, etc. Carga en tu mente todo el contexto posible, de manera imparcial, asumiendo que todos tienen raz\u00f3n. T\u00fa no est\u00e1s dentro del conflicto, est\u00e1s afuera, en una metaposici\u00f3n. Si el contexto solo est\u00e1 disponible en un hilo de correo, al menos l\u00e9elo completo y revisa los hilos y documentos relacionados. Despu\u00e9s de haber le\u00eddo, a\u00fan as\u00ed, habla con voz. Casi garantizado escuchar\u00e1s algo importante que no est\u00e1 en el correo.<\/p>\n
El tercer punto importante es el enfoque general de la comunicaci\u00f3n. Son cosas normales, nada c\u00f3smico, 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\u00e1s los chicos puedan sentirse ofendidos por esto'), damos la oportunidad de mantener la cara, y realizamos las discusiones en persona, no en p\u00fablico.<\/p>\n
Los conflictos suelen ser causados por una de dos razones. La primera est\u00e1 relacionada con si la persona, en el momento del conflicto, est\u00e1 en la posici\u00f3n de un adulto o en la de un ni\u00f1o (sobre esto m\u00e1s adelante). Esto est\u00e1 ligado a su madurez emocional, a la capacidad de gestionar sus emociones (que, por cierto, no siempre est\u00e1 relacionada con su edad). La segunda raz\u00f3n com\u00fan es la imperfecci\u00f3n del proceso laboral, que crea situaciones de zonas grises, en las que la responsabilidad est\u00e1 difusa entre los participantes, las expectativas de las partes no son claras entre s\u00ed y los roles en el proceso son borrosos. <\/p>\n
Por lo tanto, al resolver un conflicto (as\u00ed como cualquier otra cuesti\u00f3n), el gerente debe tener en cuenta tres perspectivas: la a corto plazo \u2014 resolver el asunto\/conflicto aqu\u00ed y ahora, la a mediano plazo \u2014 minimizar la probabilidad de que surja otro conflicto por la misma raz\u00f3n, y la a largo plazo \u2014 fomentar en el equipo una cultura de adulto. <\/p>\n
Dentro de cada uno de nosotros hay un ni\u00f1o interior, de aproximadamente tres a cuatro a\u00f1os. La mayor parte del tiempo en el trabajo, est\u00e1 dormido, pero a veces se despierta y asume el control. El ni\u00f1o tiene sus propias prioridades. Es importante para \u00e9l insistir en que este es su arenero, que mam\u00e1 lo quiere m\u00e1s, que su cochecito es el mejor (su dise\u00f1o es el mejor, programa mejor que nadie, ...). En una situaci\u00f3n de conflicto, el ni\u00f1o puede agarrar juguetes, hacer pucheros y golpear con la pala, pero no puede resolver problemas de adultos (arquitectura de soluciones, enfoques para pruebas autom\u00e1ticas, tiempos de lanzamiento, etc.), no piensa en t\u00e9rminos de beneficio para el equipo. En el conflicto, se puede alentar, consolar y enviar al ni\u00f1o a dormir, pidi\u00e9ndole que llame a su adulto. Antes de comenzar una discusi\u00f3n en un contexto de conflicto, aseg\u00farese de que est\u00e1 hablando con un adulto y no con un ni\u00f1o, y usted mismo debe estar en la posici\u00f3n de adulto. Si su objetivo sincero en este momento es resolver un problema serio, usted est\u00e1 en la posici\u00f3n de un adulto. Si su objetivo es hacer pucheros y golpear con la pala, esa es una posici\u00f3n infantil. Env\u00ede a su ni\u00f1o interior a dormir y llame a su adulto, o posponga la discusi\u00f3n. Una persona toma una decisi\u00f3n emocional y luego busca una justificaci\u00f3n racional para ella. La decisi\u00f3n tomada por el ni\u00f1o, basada en prioridades infantiles, no ser\u00e1 \u00f3ptima.<\/p>\n
Adem\u00e1s del comportamiento en el momento del conflicto, la posici\u00f3n infantil o adulta tambi\u00e9n se caracteriza por el nivel de responsabilidad que una persona est\u00e1 dispuesta a asumir. En las manifestaciones extremas, la posici\u00f3n infantil de un programador, que he encontrado en numerosas ocasiones, se presenta as\u00ed: escrib\u00ed el c\u00f3digo, lo envi\u00e9 para revisi\u00f3n \u2014 mi trabajo ha terminado. Los revisores deben revisarlo y fusionarlo, QA debe comprobarlo; si hay problemas, me lo har\u00e1n 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\u00f3digo funcione, est\u00e9 cubierto por pruebas, sea revisado personalmente, pase con \u00e9xito la revisi\u00f3n (si es necesario, no hay problema en contactar a los revisores, discutir cuestiones de voz, etc.) y sea fusionado; QA, si es necesario, recibir\u00e1 ayuda, se describir\u00e1n los escenarios de prueba, etc. En casos normales, el programador se encuentra inicialmente m\u00e1s cerca del extremo adulto de la escala, o se desplaza hacia all\u00ed a medida que acumula experiencia (siempre que en el equipo se cultive la cultura correcta). En casos extremos, sin embargo, contin\u00faa trabajando, generalmente ocupando una posici\u00f3n infantil, y entonces \u00e9l y su equipo enfrentan peri\u00f3dicamente problemas y conflictos.<\/p>\n
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\u00e1 seguido, el equipo siempre observa al l\u00edder) y la discusi\u00f3n y promoci\u00f3n del comportamiento adecuado. Aqu\u00ed tambi\u00e9n no hay nada complicado o excesivamente formal, simplemente en las discusiones sobre problemas, se\u00f1ala lo que se podr\u00eda haber hecho de otra manera, destaca cuando notas que se ha resuelto correctamente, elogia, menciona en el an\u00e1lisis de la publicaci\u00f3n, etc.<\/p>\n
Veamos algunas situaciones conflictivas t\u00edpicas, de simple a compleja:<\/p>\n
Conflictos no relacionados con cuestiones laborales<\/b><\/p>\n
Con bastante frecuencia ocurren en el trabajo conflictos no relacionados con cuestiones laborales. Su aparici\u00f3n y la facilidad de resoluci\u00f3n suelen estar directamente vinculadas al nivel de inteligencia emocional de los participantes, al nivel de su madurez, y no est\u00e1n relacionadas con la perfecci\u00f3n o imperfecci\u00f3n del proceso de trabajo.<\/p>\n
Ejemplos t\u00edpicos: alguien no utiliza la lavadora o la ducha con suficiente frecuencia, lo que molesta a los dem\u00e1s; 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\u00e1s necesitan silencio para trabajar, y as\u00ed sucesivamente. Es mejor no retrasar la resoluci\u00f3n de conflictos de este tipo y no dejar que se empeoren. Por s\u00ed solos no se resolver\u00e1n y distraer\u00e1n diariamente del trabajo, envenenando la atm\u00f3sfera 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\u00f3n c\u00f3moda para las personas que prefieren el silencio o el frescor, comprar auriculares absorbentes de sonido o instalar tabiques, etc. <\/p>\n
Otro ejemplo, que he encontrado varias veces en mi trabajo, es la incompatibilidad psicol\u00f3gica entre los miembros del equipo. Por alguna raz\u00f3n, las personas simplemente no pueden trabajar juntas; cada interacci\u00f3n termina en un esc\u00e1ndalo. A veces, esto se debe a que las personas sostienen opiniones opuestas sobre alg\u00fan tema candente (generalmente pol\u00edtico) y no saben dejarlo fuera del trabajo. Convencerlas de tolerarse mutuamente o cambiar su comportamiento es un ejercicio bastante f\u00fatil. La \u00fanica excepci\u00f3n que he encontrado son los j\u00f3venes colegas con una percepci\u00f3n abierta; su comportamiento a\u00fan se puede cambiar gradualmente a trav\u00e9s de conversaciones peri\u00f3dicas. Normalmente, el problema se resuelve eficazmente separ\u00e1ndolos en diferentes equipos o, al menos, asegurando que tengan la oportunidad de cruzarse muy rara vez en el trabajo.<\/p>\n
En todas las situaciones mencionadas, es importante hablar con todos los participantes de manera personal, discutir la situaci\u00f3n, preguntarles si ven alg\u00fan problema en este caso, y preguntarles qu\u00e9 caminos ven para resolverlo, asegurando su participaci\u00f3n en la toma de decisiones.<\/p>\n
Desde la perspectiva de optimizaci\u00f3n del proceso de trabajo (la perspectiva a medio plazo que mencion\u00e9), no se puede hacer mucho; el \u00fanico 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. <\/p>\n
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\u00ed mismas. Adem\u00e1s, tales conflictos se resuelven mucho m\u00e1s f\u00e1cilmente (a menudo de manera autom\u00e1tica) en equipos donde hay un alto nivel de confianza, donde las personas han trabajado juntas durante mucho tiempo y\/o tienen frecuencia de comunicaci\u00f3n fuera del trabajo.<\/p>\n
Conflictos relacionados con cuestiones laborales:<\/b><\/p>\n
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\u00f3n adulta) como por la imperfecci\u00f3n del propio proceso laboral. El tipo de conflicto m\u00e1s com\u00fan que he encontrado es el conflicto en el proceso de revisi\u00f3n de c\u00f3digo o discusi\u00f3n de arquitectura entre desarrolladores. <\/p>\n
Destacar\u00eda aqu\u00ed dos casos t\u00edpicos:<\/p>\n
1) En el primer caso, un desarrollador no puede obtener la revisi\u00f3n de c\u00f3digo de un colega. El parche se ha enviado para revisi\u00f3n 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\u00f3n laboral no se resuelve, una de las partes (la que espera la revisi\u00f3n) 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\u00f3digo en particular, debido a su carga de trabajo o a otras circunstancias, puede incluso ignorar la solicitud de revisi\u00f3n, y puede no haber un \u00e1rbitro externo (un gerente com\u00fan para ambas partes) en absoluto. <\/p>\n
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\u00f3digo que est\u00e1 en revisi\u00f3n llame la atenci\u00f3n del revisor por s\u00ed mismo. Hay que ayudar a los revisores a notarlo. Contacta a un par de personas, plantea preguntas en la reuni\u00f3n, participa en las discusiones. Es evidente que ser insistente puede hacer m\u00e1s da\u00f1o que bien, por lo que es necesario aplicar el sentido com\u00fan. En segundo lugar, la preparaci\u00f3n previa funciona muy bien. Si el equipo entiende qu\u00e9 y por qu\u00e9 est\u00e1 sucediendo, y para qu\u00e9 se necesita dicho c\u00f3digo, y si el dise\u00f1o ha sido discutido y acordado con todos de antemano, es m\u00e1s probable que la gente preste atenci\u00f3n a ese c\u00f3digo y lo acepte para su trabajo. En tercer lugar, el autoridad juega un papel importante. Si quieres que revisen tu trabajo, aseg\u00farate de hacer muchas revisiones t\u00fa mismo. Realiza revisiones de calidad, con comprobaciones reales, pruebas efectivas y comentarios \u00fatiles. Si tu nombre es conocido en el equipo por buena razones, hay m\u00e1s posibilidades de que te presten atenci\u00f3n.<\/p>\n
Desde el punto de vista del flujo de trabajo, las posibles mejoras aqu\u00ed 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\u00f1ar el c\u00f3digo con descripciones de arquitectura, documentaci\u00f3n, pruebas, participar en discusiones comunitarias, etc.), evitando que los parches queden demasiado tiempo en la cola, entre otras cosas. <\/p>\n
2) El segundo caso com\u00fan de conflictos en la revisi\u00f3n de c\u00f3digo o dise\u00f1o son las diferentes opiniones sobre cuestiones t\u00e9cnicas, estilo de codificaci\u00f3n y selecci\u00f3n 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\u00e1lisis 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 \u00e9xito, y no importa realmente cu\u00e1l elegir. <\/p>\n
Una vez, un programador de mi equipo (llam\u00e9moslo Pasha) prepar\u00f3 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\u00eda una fuerte opini\u00f3n sobre c\u00f3mo deb\u00edan configurarse los servicios de Linux al desplegar paquetes. Esta opini\u00f3n difer\u00eda del enfoque propuesto en el parche, y no lograban llegar a un acuerdo. Como de costumbre, el tiempo apremiaba, y hab\u00eda que llegar a alguna soluci\u00f3n, alguien ten\u00eda que adoptar una postura madura. Pasha reconoc\u00eda que ambos enfoques eran v\u00e1lidos, pero quer\u00eda que su opci\u00f3n prevaleciera, ya que no hab\u00eda ventajas t\u00e9cnicas evidentes en ninguno de los dos casos. <\/p>\n
Nuestra discusi\u00f3n se parec\u00eda a esto (muy esquem\u00e1ticamente, por supuesto, la conversaci\u00f3n dur\u00f3 media hora): <\/p>\n
\u2014 Pasha, en unos d\u00edas tenemos el congelamiento de caracter\u00edsticas. Es importante que todo est\u00e9 compilado y empecemos las pruebas lo antes posible. \u00bfC\u00f3mo podemos pasar por Igor?
La cuesti\u00f3n se resolvi\u00f3, el lanzamiento se realiz\u00f3 a tiempo, Pasha no estaba especialmente descontento, ya que \u00e9l mismo propuso la soluci\u00f3n y la implement\u00f3. Igor, en general, estaba satisfecho, ya que se tuvo en cuenta su opini\u00f3n y se hizo como \u00e9l hab\u00eda sugerido.<\/p>\n
Otro tipo del mismo conflicto, en esencia, es la elecci\u00f3n entre soluciones t\u00e9cnicas \/ bibliotecas \/ enfoques en el proyecto, especialmente en un equipo distribuido. En uno de los proyectos, que se posicionaba como utilizando C \/ C++, result\u00f3 que la gesti\u00f3n t\u00e9cnica del proyecto estaba categ\u00f3ricamente en contra del uso de la STL (Standard Template Library). Esta es una biblioteca est\u00e1ndar del lenguaje que simplifica el desarrollo, nuestro equipo estaba muy acostumbrado a ella. Result\u00f3 que el proyecto estaba mucho m\u00e1s cerca de C que de C++, lo que no inspir\u00f3 mucho al equipo, dado que la gesti\u00f3n hab\u00eda hecho un gran esfuerzo y hab\u00eda reunido realmente a unos genios de C++. Mientras tanto, la parte americana del equipo, tanto ingenieros como gerentes, hab\u00eda estado trabajando en la empresa durante mucho tiempo, estaban acostumbrados a la situaci\u00f3n actual, todo les parec\u00eda bien. La parte rusa del equipo se reuni\u00f3 recientemente, en unas pocas semanas (incluy\u00e9ndome a m\u00ed). La parte rusa del equipo no quer\u00eda de ninguna manera renunciar al enfoque habitual del desarrollo.<\/p>\n
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\u00eda correos de tal tama\u00f1o. Los chats chirriaban de tensi\u00f3n, compartiendo en distintas direcciones consideraciones de m\u00faltiples pantallas sobre las ventajas t\u00e9cnicas de la STL, cu\u00e1n bien estaba probada, cu\u00e1n segura es y, en general, cu\u00e1n maravillosa es la vida con ella, y cu\u00e1n terrible sin ella. <\/p>\n
Todo esto dur\u00f3 bastante tiempo, hasta que finalmente entend\u00ed que est\u00e1bamos discutiendo aspectos t\u00e9cnicos, mientras que el problema en realidad no era t\u00e9cnico. El problema no radicaba en las ventajas o desventajas de STL o en la complejidad de trabajar sin ella. M\u00e1s bien, era un problema organizativo. Solo necesit\u00e1bamos entender c\u00f3mo estaba estructurada la empresa en la que trabaj\u00e1bamos. Anteriormente, ninguno de nosotros ten\u00eda experiencia en una empresa as\u00ed. El hecho era que despu\u00e9s de desarrollar el c\u00f3digo y lanzarlo a producci\u00f3n, el soporte era manejado por personas completamente diferentes de otros equipos, de otros pa\u00edses. Este enorme equipo de ingenier\u00eda de varios miles de ingenieros (en total) solo pod\u00eda permitirse un m\u00ednimo absolutamente b\u00e1sico de medios t\u00e9cnicos, por as\u00ed decirlo, el minimum minimorum. Todo lo que iba m\u00e1s all\u00e1 del est\u00e1ndar t\u00e9cnico que exist\u00eda en la empresa no pod\u00eda ser soportado f\u00edsicamente en el futuro. El nivel de un equipo se define por el nivel de sus miembros m\u00e1s d\u00e9biles. Despu\u00e9s de que entendimos la motivaci\u00f3n real<\/i> de las acciones del equipo estadounidense, este asunto fue retirado de la agenda, y juntos desarrollamos y lanzamos el producto, utilizando los est\u00e1ndares aceptados en la empresa. En este caso, los correos y los chats funcionaron mal, necesitaron varios viajes y mucha comunicaci\u00f3n personal para llegar a un entendimiento com\u00fan.<\/p>\n
Desde el punto de vista del flujo de trabajo, en este caso espec\u00edfico, ser\u00eda \u00fatil contar con una descripci\u00f3n de las herramientas utilizadas, sus requisitos, las limitaciones para agregar nuevas, y las justificaciones de tales limitaciones. Dichos documentos corresponden aproximadamente a los descritos en los puntos Estrategia de Reutilizaci\u00f3n y Entorno de Desarrollo del manual \"Manager's Handbook for Software Development\", desarrollado en NASA<\/a><\/noindex>. A pesar de su antig\u00fcedad, describe muy bien todas las actividades principales y las etapas de planificaci\u00f3n del desarrollo de software de este tipo. La existencia de tales documentos simplifica mucho el proceso de discusi\u00f3n sobre qu\u00e9 componentes y enfoques pueden ser utilizados en el producto y por qu\u00e9.<\/p>\nDesde el punto de vista cultural, es evidente que con una postura m\u00e1s madura, en la que las partes intentan escuchar y entender la motivaci\u00f3n real de las acciones de sus colegas y act\u00faan bas\u00e1ndose en las prioridades del proyecto y del equipo, en lugar de su ego personal, el conflicto se resolver\u00eda de manera m\u00e1s sencilla y r\u00e1pida.<\/p>\n
En otro conflicto relacionado con la elecci\u00f3n de una soluci\u00f3n t\u00e9cnica, tambi\u00e9n me tom\u00f3 un tiempo considerable entender la motivaci\u00f3n de una de las partes (el caso era bastante inusual), pero una vez que la motivaci\u00f3n se hizo clara, la decisi\u00f3n fue evidente. <\/p>\n
La situaci\u00f3n es la siguiente: en un equipo de aproximadamente 20 personas, aparece un nuevo desarrollador, llam\u00e9moslo Stas. Nuestra herramienta est\u00e1ndar para la comunicaci\u00f3n en el equipo en ese momento era Skype. Como luego se descubri\u00f3, Stas era un gran fan\u00e1tico de los est\u00e1ndares abiertos y del software de c\u00f3digo abierto, y solo utilizaba herramientas y sistemas operativos cuyos c\u00f3digos fuente estaban disponibles p\u00fablicamente y que utilizaban protocolos descritos p\u00fablicamente. 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\u00e1ndares, escribi\u00e9ndole personalmente por correo, llam\u00e1ndole por tel\u00e9fono, compr\u00e1ndole un segundo ordenador especialmente para Skype, etc. Finalmente, me di cuenta de que este problema, en esencia, no era t\u00e9cnico ni organizacional; era m\u00e1s bien una cuesti\u00f3n de cosmovisi\u00f3n, incluso se podr\u00eda decir que era religiosa (para Stas). Incluso si hubi\u00e9ramos logrado conectar a Stas con Skype (lo cual ya hab\u00eda tomado varios meses), el problema surgir\u00eda nuevamente con cualquier herramienta siguiente. No ten\u00eda medios reales para cambiar la cosmovisi\u00f3n de Stas, y no hab\u00eda motivos para intentar cambiar la cosmovisi\u00f3n de un equipo que funcionaba perfectamente en ese entorno. La persona y la empresa simplemente eran ortogonales en t\u00e9rminos de cosmovisi\u00f3n. En situaciones como esta, una buena opci\u00f3n de soluci\u00f3n es organizativa. Transferimos a Stas a otro equipo, donde \u00e9l encajaba mejor.<\/p>\n
La raz\u00f3n de este conflicto, en mi opini\u00f3n, radica en la discrepancia entre la cultura personal de un individuo concreto (que tiene una opini\u00f3n 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\u00f3 a un proyecto de desarrollo de software abierto y all\u00ed prosper\u00f3 maravillosamente.<\/p>\n
Un buen ejemplo de conflicto, causado por la postura infantil del desarrollador y las deficiencias en el proceso de trabajo, es la situaci\u00f3n en la que, en ausencia de la definici\u00f3n de terminado, el desarrollador y el equipo de QA tienen diferentes expectativas sobre la preparaci\u00f3n de una caracter\u00edstica pasada a QA. El desarrollador cre\u00eda que era suficiente escribir el c\u00f3digo y pasar la caracter\u00edstica al QA; ah\u00ed se encargar\u00edan de ello. Por cierto, era un programador bastante maduro y experimentado, pero ten\u00eda un umbral de calidad interno muy bajo. El equipo de QA no estaba de acuerdo y exig\u00eda que se les mostrara y describiera qu\u00e9 hab\u00eda verificado por su cuenta, adem\u00e1s de requerir un escenario de prueba para ellos. Ya hab\u00edan tenido problemas en el pasado con la funcionalidad de este desarrollador y no quer\u00edan perder su tiempo otra vez. De hecho, ten\u00edan raz\u00f3n: la caracter\u00edstica realmente no funcionaba; no verific\u00f3 el c\u00f3digo antes de enviarlo a QA. <\/p>\n
Para resolver la situaci\u00f3n, le ped\u00ed que me mostrara que todo funcionaba realmente (no funcionaba y tuvo que arreglarlo), hablamos con el equipo y con QA sobre la definici\u00f3n de terminado (no decidimos escribirla, ya que no quer\u00edamos burocratizar demasiado el proceso), y pronto nos despedimos de este especialista (para alivio general).<\/p>\n
Desde el punto de vista del proceso de trabajo, las posibles mejoras en este caso son la existencia de una definici\u00f3n de terminado, los requisitos para acompa\u00f1ar cada caracter\u00edstica con pruebas unitarias e integradas, y la descripci\u00f3n de las pruebas realizadas por el desarrollador. En uno de los proyectos, medimos el nivel de cobertura de c\u00f3digo con pruebas durante CI, y en caso de que el nivel de cobertura cayera despu\u00e9s de agregar un parche, las pruebas se marcaban como fallidas, es decir, cualquier nuevo c\u00f3digo solo pod\u00eda ser agregado si contaba con nuevas pruebas para ello. <\/p>\n
Otro ejemplo t\u00edpico de conflicto, estrechamente relacionado con la organizaci\u00f3n 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\u00f3n est\u00e1 en el producto, por lo que pasa el problema al equipo del producto. El equipo del producto est\u00e1 en una \u00e9poca de mucho trabajo, se avecina un lanzamiento, as\u00ed que el ticket con el problema del cliente, perdido entre otros tickets del desarrollador al que se le asign\u00f3, queda sin atenci\u00f3n durante varias semanas. El soporte piensa que el desarrollador est\u00e1 trabajando en el problema del cliente. El cliente espera y conf\u00eda en que su problema est\u00e1 siendo atendido. En realidad, no est\u00e1 ocurriendo nada. Despu\u00e9s de unas semanas, el cliente finalmente decide preguntar por el progreso y pregunta al soporte c\u00f3mo 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\u00f3n para resolver el problema es insuficiente y que necesita m\u00e1s registros y volcado de datos. El soporte solicita informaci\u00f3n 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\u00e1...<\/p>\n
En esta situaci\u00f3n, la soluci\u00f3n del conflicto es bastante evidente y lineal (arreglar el producto, actualizar la documentaci\u00f3n y las pruebas, apaciguar al cliente, lanzar un hotfix, etc.). Es importante analizar el flujo de trabajo y entender qui\u00e9n es responsable de organizar la interacci\u00f3n entre ambos equipos y por qu\u00e9 esta situaci\u00f3n se hizo posible en primer lugar. Est\u00e1 claro que hay que arreglar el proceso: alguien deber\u00eda monitorear la imagen general sin recordatorios de los clientes, de forma proactiva. Los tickets del cliente deber\u00edan destacarse entre los dem\u00e1s tickets de los desarrolladores. El soporte debe ver si el desarrollo est\u00e1 trabajando en sus tickets en ese momento; si no, cu\u00e1ndo podr\u00e1 comenzar a trabajar, cu\u00e1ndo se puede esperar un resultado. El soporte y el desarrollo deben comunicarse peri\u00f3dicamente y discutir el estado de los tickets, la recolecci\u00f3n de la informaci\u00f3n necesaria para la depuraci\u00f3n debe ser lo m\u00e1s automatizada posible, etc.<\/p>\n
As\u00ed como en la guerra el enemigo intenta golpear en la uni\u00f3n entre dos unidades, en el trabajo el aspecto m\u00e1s delicado y vulnerable suele ser la interacci\u00f3n entre los equipos. Si los gerentes de soporte y desarrollo son lo suficientemente maduros, podr\u00e1n solucionar el proceso por s\u00ed mismos; de lo contrario, el proceso seguir\u00e1 generando conflictos y problemas hasta que intervenga un gerente capaz de arreglar la situaci\u00f3n.<\/p>\n
Otro ejemplo caracter\u00edstico que he encontrado repetidamente en diferentes empresas es la situaci\u00f3n en la que un equipo desarrolla el producto, un segundo equipo realiza las pruebas de integraci\u00f3n automatizadas y la infraestructura en la que todo esto se ejecuta es gestionada por un tercer equipo. Los problemas durante la ejecuci\u00f3n de las pruebas surgen constantemente, y las causas pueden ser tanto el producto como las pruebas y la infraestructura. Suele ser problem\u00e1tico ponerse de acuerdo sobre qui\u00e9n debe llevar a cabo el an\u00e1lisis 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\u00f3n infantil y comienzan discusiones como: \"\u00bfpor qu\u00e9 debo ocuparme de esto?\", \"es m\u00e1s frecuente que se rompa por su parte\", etc. <\/p>\n
Desde el punto de vista del flujo de trabajo, los pasos espec\u00edficos para abordar el problema dependen de la composici\u00f3n de los equipos, el tipo de pruebas y del producto, etc. En uno de los proyectos, implementamos turnos peri\u00f3dicos donde los equipos monitoreaban las pruebas por turnos, semanalmente. En otro, el an\u00e1lisis inicial siempre lo realizaban los desarrolladores de las pruebas, pero dicho an\u00e1lisis era bastante b\u00e1sico y el producto era lo suficientemente estable, as\u00ed que funcionaba razonablemente bien. Lo principal es garantizar la transparencia del proceso, la claridad de las expectativas para todas las partes y la sensaci\u00f3n de justicia en la situaci\u00f3n para todos.<\/p>\n
\u00bfEs realmente el conflicto en la organizaci\u00f3n un problema, es un mal indicio que en su equipo surjan conflictos a menudo (o simplemente de manera peri\u00f3dica)? En general, no, porque si hay crecimiento, desarrollo, hay cierta din\u00e1mica, surgen preguntas que nunca antes se hab\u00edan resuelto, lo que puede generar conflictos. Esto indica que hay \u00e1reas a las que deber\u00eda prestarse atenci\u00f3n, que hay oportunidades de mejora. Es negativo si los conflictos surgen con demasiada frecuencia, son dif\u00edciles 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.habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u042d\u043f\u0438\u0433\u0440\u0430\u0444: \u0412\u0441\u0442\u0440\u0435\u0442\u0438\u043b\u0438\u0441\u044c \u043a\u0430\u043a-\u0442\u043e \u0432 \u043b\u0435\u0441\u0443 \u0401\u0436\u0438\u043a \u0438 \u041c\u0435\u0434\u0432\u0435\u0436\u043e\u043d\u043e\u043a. \u2014 \u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439, \u0401\u0436\u0438\u043a! \u2014 \u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439, \u041c\u0435\u0434\u0432\u0435\u0436\u043e\u043d\u043e\u043a! \u0422\u0430\u043a, \u0441\u043b\u043e\u0432\u043e \u0437\u0430 \u0441\u043b\u043e\u0432\u043e, \u0448\u0443\u0442\u043a\u0430 \u0437\u0430 \u0448\u0443\u0442\u043a\u043e\u0439, \u0438 \u043f\u043e\u043b\u0443\u0447\u0438\u043b \u0401\u0436\u0438\u043a \u043e\u0442 \u041c\u0435\u0434\u0432\u0435\u0436\u043e\u043d\u043a\u0430 \u043f\u043e \u043c\u043e\u0440\u0434\u0435 \u2026 \u041f\u043e\u0434 \u043a\u0430\u0442\u043e\u043c \u0440\u0430\u0441\u0441\u0443\u0436\u0434\u0435\u043d\u0438\u044f \u043d\u0430\u0448\u0435\u0433\u043e \u0442\u0438\u043c\u043b\u0438\u0434\u0430, \u0430 \u0442\u0430\u043a\u0436\u0435 \u0434\u0438\u0440\u0435\u043a\u0442\u043e\u0440\u0430 \u043f\u043e \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u044e \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u0430 RAS \u2014 \u0418\u0433\u043e\u0440\u044f \u041c\u0430\u0440\u043d\u0430\u0442\u0430 \u043e \u0441\u043f\u0435\u0446\u0438\u0444\u0438\u043a\u0435 \u0440\u0430\u0431\u043e\u0447\u0438\u0445 \u043a\u043e\u043d\u0444\u043b\u0438\u043a\u0442\u043e\u0432 \u0438 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u044b\u0445 \u043c\u0435\u0442\u043e\u0434\u0430\u0445 \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u0438\u043c\u0438. \u0411\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u043a\u043e\u043d\u0444\u043b\u0438\u043a\u0442\u043e\u0432, […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":27283,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[702],"tags":[],"class_list":["post-36457","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-news"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"\u00bfGesti\u00f3n](\"\/wp-content\/uploads\/2019\/07\/de379c9eedec8cecda6651b5339a0277.jpg\")