Epígrafe:
Érase unha vez que o Ourizo e o Osiño reuníronse no bosque.
- Ola, ourizo!
- Ola, Osiño!
Así, palabra por palabra, broma por broma, o Ourizo foi golpeado na cara polo Osiño...
A continuación móstrase unha discusión do noso xefe de equipo, así como do director de desenvolvemento de produtos de RAS, Igor Marnat, sobre as particularidades dos conflitos laborais e os posibles métodos para xestionalos.
A maioría dos conflitos que atopamos no traballo desenvólvense segundo un escenario similar ao descrito no epígrafe anterior. Hai varios participantes que se mostran inicialmente bastante favorables entre eles; están tentando resolver algún problema, pero ao final o problema segue sen resolverse e, por algún motivo, as relacións entre os participantes na discusión resultan estropeadas.
A vida é diversa e ocorren variacións no escenario descrito anteriormente. Ás veces a relación entre os participantes non é moi boa inicialmente, ás veces nin sequera hai un problema que requira unha solución directa (como, por exemplo, no epígrafe), ás veces despois da discusión a relación segue sendo a mesma que antes de comezar, pero o problema finalmente non está resolto.
Que é común en todas as situacións que se poden definir como situación de conflito laboral?
En primeiro lugar, hai dous ou máis lados. Estas partes poden ocupar distintos lugares da organización, estar nunha relación de igualdade (compañeiros dun equipo), ou en distintos niveis da xerarquía (xefe - subordinado), ser individuais (traballador) ou grupal (en casos de conflito entre un empregado e un equipo ou dous equipos), etc. A probabilidade de conflito e a facilidade da súa resolución están moi influenciadas polo nivel de confianza entre os participantes. Canto mellor se coñezan as partes, maior será o nivel de confianza, maior será a posibilidade de que cheguen a un acordo. Por exemplo, os membros dun equipo distribuído que nunca interactuaron cara a cara son máis propensos a experimentar conflitos por unha cuestión de traballo simple que as persoas que tiveron polo menos algunhas interaccións cara a cara. Polo tanto, cando se traballa en equipos distribuídos, é moi importante asegurarse de que todos os membros do equipo se reúnan periodicamente en persoa.
En segundo lugar, nunha situación de conflito no traballo, as partes atópanse nunha situación de resolución dalgún asunto que é importante para unha das partes, para ambas ou para o conxunto da organización. Ao mesmo tempo, debido ás especificidades da situación, as partes adoitan ter tempo suficiente e diversas formas de resolvelo (formais, informais, reunións, cartas, decisións de xestión, presenza de obxectivos e plans do equipo, feito dunha xerarquía, etc.). Isto é diferente da situación de resolver un problema laboral (ou non laboral) nunha organización de, por exemplo, resolver unha pregunta importante: "Eh, neno, de que zona es?!" na rúa, ou o conflito dende o epígrafe. No caso de resolver un problema de traballo, a calidade do proceso de traballo e a cultura de resolución de problemas no equipo importan.
En terceiro lugar, o factor determinante do conflito (desde o punto de vista da nosa discusión) é o feito de que as partes do proceso non poden chegar de forma independente a unha solución ao problema que conveña a todas as partes. A situación require a intervención dun terceiro, un árbitro externo. Este punto pode parecer controvertido, pero, en esencia, se a situación de conflito se resolveu con éxito sen a intervención dun árbitro externo, o problema resolveuse con éxito e as relacións das partes non se deterioraron, esta é a situación á que debemos esforzarnos. . O máis probable é que nin sequera coñezamos un conflito deste tipo, ou o decataremos por casualidade despois de que estea resolto. Cantos máis problemas poida resolver un equipo por si só, máis eficaz será.
Outro trazo característico do conflito que merece a pena tocar é o grao de intensidade emocional durante a decisión. O conflito non está necesariamente asociado a un alto nivel emocional. Os participantes non teñen que berrar e axitar os brazos para que a situación sexa, en esencia, un conflito. O tema non está resolto, está presente unha certa tensión emocional (quizais non se expresa claramente cara a fóra), o que significa que estamos ante unha situación de conflito.
É necesario intervir en situacións de conflito en absoluto, ou é mellor deixar que a súa resolución siga o seu curso e esperar a que o problema se resolva? Necesito. Non sempre está no teu poder ou competencia resolver o conflito por completo, pero en calquera situación, nun conflito de calquera escala, podes adoptar unha posición adulta, atraendo así a varias persoas máis ao teu redor, mitigando as consecuencias negativas do conflito e contribuír á súa resolución.
Antes de ver algúns exemplos de situacións de conflito, vexamos algúns puntos importantes comúns a todos os conflitos.
Á hora de resolver un conflito é importante estar por riba da loita, e non dentro dela (a iso tamén se lle chama “asumir metaposición”), é dicir, non formar parte dunha das partes no proceso de resolución. En caso contrario, contar cun árbitro externo que asista a decisión só reforzará a posición dunha das partes en detrimento da outra. Ao tomar unha decisión, é importante que todas as partes a acepten moralmente, como din, "compra". De xeito que, aínda que as partes non estiveran encantadas coa decisión tomada, polo menos acordaron sinceramente aplicala. Como din, para poder discrepar e comprometerse. En caso contrario, o conflito simplemente cambiará a súa aparencia, o lume ardente permanecerá baixo a turbeira e, nalgún momento, inevitablemente volverá arder.
O segundo punto, en parte relacionado co primeiro, é que se xa decidiu participar na resolución do conflito, tómao o máis en serio posible desde o punto de vista das comunicacións e do estudo do contexto. Fala persoalmente con cada unha das partes. Por separado con cada un, para comezar. Non te conformes co correo. No caso dun equipo distribuído, polo menos falar mediante ligazón de vídeo. Non te conformes cos informes de oídas e testemuñas oculares. Comprender a historia, o que quere cada bando, por que o queren, que esperan, intentaron resolver este problema antes, que pasará se non se resolve, que solucións ven, como imaxinan a posición do doutro lado, que pensan, correcto ou incorrecto, etc. Carga todo o contexto posible na túa cabeza, cunha mente aberta, asumindo que todos teñen razón. Non estás dentro do conflito, estás fóra del, nunha metaposición. Se o contexto só está dispoñible nun fío de publicación, polo menos léao na súa totalidade e os fíos e documentos relacionados con el. Despois de lelo, aínda fala coa túa voz. Case seguro que escoitarás algo importante que non está no correo.
O terceiro punto importante é o enfoque xeral da comunicación. Son cousas comúns, nada cósmicas, pero son moi importantes. Non tratamos de aforrar tempo, falamos con todos os participantes, non criticamos á persoa, pero consideramos as consecuencias dos seus actos (non “es maleducado”, senón “quizais os rapaces se lles ofendan. esta cousa”), damos a oportunidade de salvar a cara, levamos a cabo discusións en persoa, non diante da liña.
Os conflitos adoitan ser causados por un dos dous motivos. O primeiro está relacionado con se unha persoa no momento do conflito está na posición de adulto ou na posición de neno (máis información a continuación). Isto débese á súa madurez emocional, á capacidade de xestionar as súas emocións (que, por certo, non sempre está relacionada coa súa idade). O segundo motivo común é a imperfección do proceso de traballo, que crea situacións de zonas grises nas que a responsabilidade se reparte entre os participantes, as expectativas das partes non son transparentes entre si e os roles no proceso son borrosos.
En consecuencia, á hora de resolver un conflito (así como calquera outro problema), un xestor debe ter en conta tres perspectivas: a curto prazo - para resolver o problema/conflito aquí e agora, a medio prazo - para minimizar a probabilidade de que xurda outro conflito. pola mesma razón, e a longo prazo - para cultivar unha cultura adulta na persoa do equipo.
Cada un de nós temos un fillo interior, duns tres ou catro anos. Durme a maior parte do tempo no traballo, pero ás veces esperta e toma o control. O neno ten as súas propias prioridades. É importante que insista en que este é o seu areeiro, a súa nai quéreo máis, a súa máquina é a mellor (o deseño é o mellor, el programa o mellor,...). Nunha situación de conflito, un neno pode presionar xoguetes, pisar os pés e rachar a espátula, pero non pode resolver problemas dos adultos (arquitectura de solucións, enfoques de probas automatizadas, datas de lanzamento, etc.), non pensa en beneficios. para o equipo. Un neno en conflito pode ser animado, consolado e enviado á cama pedíndolle que chame ao seu adulto. Antes de iniciar unha discusión nunha situación de conflito, asegúrate de que estás a falar cun adulto, non cun neno, e que ti mesmo estás na posición dun adulto. Se o teu obxectivo honesto neste momento é resolver un problema serio, estás na posición dun adulto. Se o teu obxectivo é pisar os pés e rachar o omóplato, esta é unha posición infantil. Envía o teu fillo interior á cama e chama a un adulto ou reprograma a discusión. Unha persoa toma unha decisión emocional e despois busca unha xustificación racional para iso. Unha decisión tomada por un neno en función das prioridades dos nenos non será a óptima.
Ademais do comportamento no momento do conflito, a posición dun neno ou adulto tamén se caracteriza polo nivel de responsabilidade que unha persoa está lista para asumir. Nas súas manifestacións extremas, a posición infantil dun programador, que coñecín máis dunha vez, ten o seguinte aspecto: escribín o código, envieuno para revisar - o meu traballo está rematado. Os revisores deben revisalo e aprobalo, o control de calidade debería comprobalo, se hai problemas, avisalo. Curiosamente, ata persoas bastante maduras e experimentadas ás veces se comportan deste xeito. O outro extremo da escala é que unha persoa se considera responsable de asegurarse de que o seu código funciona, está cuberto por probas, foi revisado persoalmente por el, aprobou con éxito a revisión (se é necesario, non hai ningún problema para facer ping aos revisores, discutir problemas). por voz, etc.) e foi suprimido, QA prestará asistencia se é necesario, describiranse escenarios de proba, etc. En casos normais, o programador comeza máis preto do extremo adulto da escala, ou móvese alí a medida que adquire experiencia (sempre que se cultive a cultura adecuada dentro do equipo). En casos extremos, segue traballando, normalmente tomando unha posición infantil, entón el e o equipo teñen periodicamente problemas e conflitos.
Fomentar a cultura correcta e madura nun equipo é unha tarefa importante para calquera directivo. Leva moito tempo e esforzo diario, pero o resultado paga a pena. Hai dúas formas de influír na cultura do equipo: dar o exemplo (que definitivamente se seguirá; o equipo sempre mira ao líder) e discutir e recompensar o comportamento correcto. Tampouco hai nada abstruso nin moi formal aquí, só ao discutir problemas, notar que aquí se puido facer algo, salientar que se decataron cando se decidiu correctamente, eloxio, nota durante a revisión do lanzamento, etc.
Consideremos varias situacións de conflito típicas, de simples a complexas:
Conflitos non relacionados con cuestións laborais
Moitas veces hai conflitos no traballo que non están relacionados con cuestións laborais. A súa aparición e facilidade de resolución adoitan estar directamente relacionadas co nivel de intelixencia emocional dos participantes, o seu nivel de madurez, e non están relacionadas coa perfección ou imperfección do proceso de traballo.
Exemplos típicos: alguén non usa a lavadora ou a ducha con suficiente frecuencia, cousa que a outros non lles gusta, alguén está abafado, mentres que outros reciben vento se abren a fiestra, alguén fai moito ruído e outros necesitan silencio para traballar e así por diante. É mellor non atrasar a resolución de conflitos deste tipo e non deixar que sigan o seu curso. Non se resolverán por si mesmos e distrairánche do traballo todos os días e envelenarán a atmosfera do equipo. Afortunadamente, resolvelos non adoita ser un gran problema: só fale con calma (un a un, por suposto) cun colega que descoida a hixiene, proporcione asentos cómodos para as persoas que prefiren o silencio/fresco, compre auriculares que absorban o son ou instale tabiques. , etc.
Outro exemplo que atopei varias veces durante o meu traballo é a incompatibilidade psicolóxica dos membros do equipo. Por algún motivo, a xente simplemente non pode traballar xuntos; cada interacción acaba nun escándalo. Ás veces, isto débese ao feito de que a xente ten opinións polares sobre algún tema urxente (xeralmente político) e non sabe como deixalos fóra do traballo. Convencelos de que se toleren ou cambien o seu comportamento é unha tarefa bastante inútil. A única excepción que atopei son os mozos colegas con percepcións abertas; o seu comportamento aínda pode cambiarse gradualmente a través de conversas periódicas. Normalmente o problema resólvese con éxito separándoos en diferentes equipos, ou polo menos dándolles a oportunidade de solaparse no traballo moi raramente.
En todas as situacións anteriores, paga a pena falar persoalmente con todos os participantes, discutir a situación, preguntarlle se ven algún problema neste caso, preguntar cales son, na súa opinión, as solucións e asegurar a súa participación na elaboración deste. decisión.
Desde o punto de vista da optimización do proceso de traballo (a perspectiva a medio prazo que mencionei), aquí non se pode facer moito, o único punto de optimización é ter en conta o factor de compatibilidade á hora de formar un equipo e non poñer persoas. xuntos de antemán quen entrará en conflito.
Desde a perspectiva da cultura do equipo, este tipo de situacións xorden con moita menos frecuencia en equipos cunha cultura madura, onde a xente respecta ao equipo e aos compañeiros e sabe resolver os problemas de forma independente. Ademais, estes conflitos resólvense con moita máis facilidade (moitas veces de forma automática) en equipos nos que existe un alto nivel de confianza, as persoas traballan xuntos durante moito tempo e/ou se comunican con frecuencia fóra do traballo.
Conflitos relacionados co traballo:
Estes conflitos adoitan ser causados por ambas razóns á vez, tanto emocionais (o feito de que un dos participantes non estea na posición de adulto) como pola imperfección do propio proceso de traballo. Quizais o tipo máis común de conflitos que atopei sexan os conflitos durante as revisións de código ou as discusións de arquitectura entre desenvolvedores.
Destacaría aquí dous casos típicos:
1) No primeiro caso, o programador non pode obter unha revisión do código dun compañeiro. O parche envíase a revisión e non pasa nada. A primeira vista, non hai un conflito evidente entre as dúas partes, pero se pensas niso, este é un conflito. O tema do traballo non está resolto, unha das partes (á espera dunha revisión) experimenta un malestar evidente. Un subtipo extremo deste caso é o desenvolvemento nunha comunidade ou en diferentes equipos, mentres que o revisor pode non estar interesado neste código en particular, debido á carga ou a outras circunstancias, pode non prestar atención á solicitude de revisión e o árbitro externo. (un xestor común a ambos os dous lados) ) pode non existir en absoluto.
O enfoque de solución que axuda a tal situación refírese precisamente á perspectiva a longo prazo, á cultura dun adulto. En primeiro lugar, a actividade intelixente funciona. Non debe esperar que o código colgado na revisión atraiga a atención do propio revisor. Necesitamos axudar aos revisores a notar nel. Pingani un par de persoas, facer unha pregunta sobre syncape, participar en discusións. Obviamente, é máis probable que a importunidade prexudique que axude, cómpre usar o sentido común. En segundo lugar, a preparación previa funciona ben. Se o equipo entende o que está a suceder e por que, por que se necesita este código, o deseño foi discutido e acordado previamente con todos, é máis probable que a xente preste atención a ese código e o acepte para traballar. En terceiro lugar, a autoridade funciona. Se queres ser revisado, fai moitas críticas ti mesmo. Fai revisións de alta calidade, con comprobacións reais, probas reais e comentarios útiles. Se o teu alcume é moi coñecido no equipo, hai unha maior probabilidade de que se note o teu código.
Desde o punto de vista do fluxo de traballo, as posibles melloras aquí son a correcta priorización destinada a axudar ao desenvolvedor a acadar os seus obxectivos e os do equipo (revisar outros, escribir cartas á comunidade, acompañar o código cunha descrición da arquitectura, documentación, probas, participar en discusións con comunidade, etc.), evitar que os parches colguen na cola durante moito tempo, etc.
2) O segundo caso común de conflitos durante as revisións de código ou deseño son as diferentes opinións sobre cuestións técnicas, estilo de codificación e elección de ferramentas. De gran importancia neste caso é o nivel de confianza entre os participantes, a pertenza a un mesmo equipo, e a experiencia de traballo en común. Prodúcese un camiño sen saída cando un dos participantes toma unha posición infantil e non intenta escoitar o que lle quere transmitir o interlocutor. Moitas veces, tanto o enfoque proposto pola outra parte como o proposto inicialmente poden funcionar con éxito e non importa en principio cal escoller.
Un día, un programador do meu equipo (chamémoslle Pasha) preparou un parche con cambios no sistema de implantación de paquetes, que foi desenvolvido e apoiado por compañeiros dun departamento veciño. Un deles (Igor) tiña a súa propia opinión sobre como se deberían configurar exactamente os servizos Linux ao despregar paquetes. Esta opinión difería do enfoque proposto no parche, e non puideron estar de acordo. Como é habitual, os prazos ían esgotando, había que tomar algún tipo de decisión, era necesario que un deles adoptase unha posición de adulto. Pasha recoñeceu que ambos enfoques teñen dereito á vida, pero quería que a súa opción pasase, porque Nin unha nin a segunda opción tiñan vantaxes técnicas evidentes.
A nosa discusión foi algo así (de forma moi esquemática, por suposto, a conversa durou media hora):
- Pasha, temos unha función conxelada nuns días. É importante reunir todo e comezar a probar canto antes. Como podemos pasar por Igor?
— Quere configurar servizos doutro xeito, meteu comentarios alí para min...
- E que hai, grandes alteracións, moito balbordo?
- Non, hai traballo un par de horas, pero ao final non hai diferenza, funcionará de calquera xeito, por que é necesario? Fixen algo que funciona, aceptémolo.
- Escoita, canto tempo levas discutindo todo isto?
- Si, levamos semana e media marcando tempo.
- Um... podemos resolver un problema nun par de horas que xa leva semana e media, e non facelo?
- Pois si, pero non quero que Igor pense que cedei...
- Escoita, que é máis importante para ti, emitir unha liberación, xunto coa túa decisión dentro, ou matar a Igor? Podemos bloquealo, entón, con todo, hai unha boa oportunidade de voar co lanzamento.
- Pois... estaría ben, claro, limparlle o nariz a Igor, pero vale, a liberación é máis importante, estou de acordo.
- É tan importante para ti o que pensa Igor? Para ser sincero, non lle importa nada, só quere un enfoque unificado en diferentes lugares da cousa da que é responsable.
- Ben, vale, déixame facer o que pide nos comentarios e imos comezar a probar.
- Grazas, Pasha! Estaba seguro de que dos dous serías o máis maduro, aínda que Igorek é maior ca ti :)
O problema foi resolto, o lanzamento foi lanzado a tempo, Pasha non sentiu moita insatisfacción, porque el mesmo propuxo unha solución e a implementou. En xeral, Igor estaba satisfeito, porque... A súa opinión tívose en conta e fixeron o que el suxeriu.
Outro tipo de conflito esencialmente igual é a elección entre solucións técnicas/bibliotecas/enfoques nun proxecto, especialmente nun equipo distribuído. Nun dos proxectos, que se posicionou como usando C/C++, resultou que a xestión técnica do proxecto estaba en contra do uso de STL (Standard Template Library). Esta é unha biblioteca de linguaxe estándar que simplifica o desenvolvemento, e o noso equipo está moi afeito a iso. Resultou que o proxecto está moito máis próximo ao C que ao C++, o que non inspirou moito ao equipo, porque a dirección fixo todo o posible e reclutou xogadores moi interesantes. Ao mesmo tempo, a parte americana do equipo, tanto enxeñeiros como directivos, levaba moito tempo traballando na empresa, estaba afeito ao estado de cousas existente e estaba contento con todo. A parte rusa do equipo xuntouse hai pouco, en poucas semanas (incluíndo eu). A parte rusa do equipo categoricamente non quixo abandonar o enfoque habitual do desenvolvemento.
Comezaron interminables discusións escritas entre os dous continentes, cartas en tres ou catro pantallas voaron de ida e volta, en correos grupais e persoais, de programadores a programadores e xestores. Como adoita suceder, cartas desta extensión non eran lidas por ninguén agás os autores e os seus fervorosos seguidores. Os chats chirrían de tensión, pasando pensamentos multipantalla en diferentes direccións sobre as vantaxes técnicas do STL, o ben probado que está, o seguro que é e, en xeral, o marabilloso que é a vida con el e o terrible que é sen el. .
Todo isto durou bastante tempo, ata que finalmente me decatei de que estabamos discutindo os aspectos técnicos do problema, pero o problema en realidade non era técnico. O problema non son as vantaxes ou inconvenientes de STL nin a dificultade de traballar sen el. O problema é máis ben organizativo. Só necesitabamos entender como funcionaba a empresa na que traballamos. Ningún de nós tiña experiencia traballando nunha empresa deste tipo antes. O caso foi que despois de que o código foi desenvolvido e lanzado á produción, o soporte foi xestionado por persoas completamente diferentes doutros equipos, doutros países. Este enorme equipo de enxeñaría de varias decenas de miles de enxeñeiros (en total) só podía permitirse un mínimo de medios técnicos completamente básicos, por así dicilo, un minimorum mínimo. Todo o que fose máis aló do estándar de enxeñería establecido na empresa fisicamente non podería ser soportado no futuro. O nivel dun equipo está determinado polo nivel dos seus membros máis débiles. Despois de que o entendemos motivación real accións da parte estadounidense do equipo, este problema foi eliminado da axenda e xuntos desenvolvemos e publicamos con éxito o produto utilizando os estándares adoptados pola empresa. As cartas e os chats neste caso non funcionaron ben, foron necesarias varias viaxes e moita comunicación persoal para chegar a un denominador común.
Desde o punto de vista do fluxo de traballo, neste caso concreto, axudaría a ter unha descrición das ferramentas utilizadas, requisitos para as mesmas, restricións para engadir outras novas e xustificación de tales restricións. Estes documentos corresponden aproximadamente aos descritos nos parágrafos Estratexia de reutilización e contorno de desenvolvemento do “Manual do xestor para o desenvolvemento de software”, elaborado en . A pesar da súa antigüidade, describe perfectamente todas as principais actividades e fases de planificación do desenvolvemento de software deste tipo. Ter documentos como este fai que sexa moi sinxelo discutir cales son os compoñentes e enfoques que se poden usar nun produto e por que.
Desde un punto de vista cultural, obviamente, cunha postura máis madura, na que as partes intentan escoitar e comprender a verdadeira motivación da acción dos seus compañeiros e actuar en función das prioridades do proxecto e do equipo, e non do ego persoal. , o conflito resolveríase máis doado e rápido.
Noutro conflito pola elección dunha solución técnica, tamén me levou moito tempo entender a motivación dunha das partes (era un caso moi inusual), pero despois de que a motivación quedou clara, a solución foi obvia.
A situación é esta: un novo desenvolvedor aparece nun equipo dunhas 20 persoas, chamémoslle Stas. Naquel momento, a nosa ferramenta estándar de comunicación como equipo era Skype. Como se viu máis tarde, Stas era un gran fan dos estándares abertos e do software de código aberto, e utilizaba só ferramentas e sistemas operativos cuxas fontes estaban dispoñibles publicamente e que utilizaban protocolos descritos publicamente. Skype non é unha destas ferramentas. Pasamos moito tempo discutindo as vantaxes e desvantaxes deste enfoque, os intentos de lanzar análogos de Skype en diferentes sistemas operativos, os intentos de Stas de convencer ao equipo de cambiar a outros estándares, escribirlle persoalmente por correo electrónico, chamalo persoalmente no teléfono. teléfono, cómprelle un segundo ordenador específicamente para Skype, etc. Finalmente, decateime de que este problema, en esencia, non é técnico nin organizativo, é máis ben ideolóxico, incluso, poderíase dicir, relixioso (para Stas). Aínda que finalmente conectamos Stas e Skype (o que levou varios meses), o problema volvería a xurdir en calquera instrumento posterior. Non tiña medios reais á miña disposición para cambiar a visión do mundo de Stas, e non había motivos para tentar cambiar a visión do mundo dun equipo que funcionaba perfectamente neste ambiente. A persoa e a empresa eran simplemente ortogonais na súa visión do mundo. En tales situacións, unha boa solución é organizativa. Trasladamos a Stas a outro equipo, onde era máis orgánico.
O motivo deste conflito, na miña opinión, é a discrepancia entre a cultura persoal dunha persoa determinada (que ten unha opinión forte que non lle permite ceder) e a cultura da empresa. Neste caso, é, por suposto, un erro do director. Inicialmente foi incorrecto levalo a un proxecto deste tipo. Stas finalmente pasou a un proxecto de desenvolvemento de software de código aberto e destacou alí.
Un bo exemplo de conflito provocado tanto pola actitude infantil do desenvolvedor como polas deficiencias do proceso de traballo é unha situación na que, a falta dunha definición de feito, o desenvolvedor e o equipo de control de calidade teñen expectativas diferentes sobre a preparación do traballo. a función transferida a QA. O desenvolvedor cría que era suficiente escribir o código e botar a función por riba do valado para o control de calidade: resolveríano alí. Un programador bastante maduro e experimentado, por certo, pero ese era o seu limiar interno de calidade. QA non estaba de acordo con isto e esixiu mostrarlles e describirlles o que comprobara el mesmo e esixiu un guión de proba para eles. Tiveran problemas coa funcionalidade deste programador no pasado e non querían volver perder o tempo. Por certo, tiñan razón: a función realmente non funcionaba, non comprobou o código antes de envialo a QA.
Para resolver a situación, pedinlle que me demostrase que todo funcionaba realmente (non funcionou, e tiña que arranxalo), falamos co equipo e coa definición de control de calidade de feito (non o chegaron a escribindo, porque non queriamos facer o proceso demasiado burocrático ), ben, pronto nos separamos deste especialista (para alivio xeral).
Desde o punto de vista do fluxo de traballo, as posibles melloras neste caso son a presenza dunha definición de feito, requisitos de soporte de cada característica da unidade e probas de integración, e unha descrición das probas realizadas polo desenvolvedor. Nun dos proxectos, medimos o nivel de cobertura de código mediante probas durante o CI e se o nivel de cobertura baixaba despois de engadir un parche, as probas marcaban como falladas, é dicir. calquera código novo só podería engadirse se houbese probas novas para el.
Outro exemplo típico dun conflito moi relacionado coa organización do proceso de traballo. Temos un produto, un equipo de desenvolvemento de produtos, un equipo de soporte e un cliente. O cliente ten problemas co produto e contacta co soporte. O soporte analiza o problema e comprende que o problema está no produto e transfire o problema ao equipo do produto. O equipo do produto atópase nun momento axitado, achégase un lanzamento, polo que un ticket cun problema dun cliente, perdido entre os outros tickets do desarrollador a quen está asignado, garda varias semanas sen atención. O soporte pensa que o programador está a traballar no problema do cliente. O cliente espera e espera que se solucione o seu problema. En realidade, aínda non pasa nada. Despois dunhas semanas, o cliente finalmente decide interesarse polo progreso e pídelle ao apoio como van as cousas. O apoio pide desenvolvemento. O programador estremece, mira a lista de tickets e atopa alí un ticket do cliente. Ao ler un ticket dun cliente, entende que non hai información suficiente para resolver o problema e necesita máis rexistros e verteduras. O soporte solicita información adicional ao cliente. E entón o cliente dáse conta de que ninguén estivo traballando no seu problema durante todo este tempo. E o trono golpeará...
Nesta situación, a solución do conflito en si é bastante obvia e lineal (arranxar o produto, actualizar a documentación e probas, apaciguar ao cliente, lanzar un hotfix, etc.). É importante analizar o proceso de traballo e comprender quen é o responsable de organizar a interacción entre os dous equipos, e por que se fixo posible esta situación en primeiro lugar. Está claro o que hai que corrixir no proceso: alguén debe supervisar a imaxe xeral sen recordatorios dos clientes, de forma proactiva. As entradas do cliente deben destacar entre outras entradas dos desenvolvedores. O soporte debería ver se o equipo de desenvolvemento está a traballar actualmente nos seus tickets e, se non, cando pode comezar a funcionar e cando se poden esperar resultados. O soporte e o desenvolvemento deberían comunicar e discutir periodicamente o estado dos tickets, a recollida de información necesaria para a depuración debería automatizarse na medida do posible, etc.
Do mesmo xeito que na guerra o inimigo tenta golpear a unión entre dúas unidades, así no traballo o punto máis delicado e vulnerable adoita ser a interacción entre os equipos. Se os responsables de soporte e desenvolvemento teñen a idade suficiente, poderán arranxar eles mesmos o proceso, se non, o proceso seguirá xerando conflitos e problemas ata que interveña un responsable que poida arranxar a situación.
Outro exemplo típico que vin repetidamente en diferentes empresas é unha situación na que un produto é escrito por un equipo, as probas de integración automáticas para el son escritas por un segundo equipo e a infraestrutura na que está todo operado vai acompañada dun terceiro. equipo. Os problemas ao executar probas xorden todo o tempo, e a causa dos problemas nelas pode ser tanto o produto como as probas e a infraestrutura. Adoita ser problemático poñerse de acordo sobre quen debe realizar a análise inicial de problemas, arquivos de erros, análise de rexistros do produto, probas e infraestrutura, etc. Os conflitos aquí son moi frecuentes e, ao mesmo tempo, uniformes. No caso de alta intensidade emocional, os participantes adoitan caer nunha posición infantil e as discusións comezan na serie: "por que debería xogar con isto", "se rompen con máis frecuencia", etc.
Desde a perspectiva do fluxo de traballo, os pasos específicos para resolver un problema dependen da composición dos equipos, do tipo de probas e produto, etc. Nun dos proxectos, introducimos o deber periódico, no que os equipos supervisaban as probas un a un, semana a semana. No outro, a análise inicial foi sempre realizada polos desenvolvedores da proba, pero a análise era moi básica e o produto era bastante estable, polo que funcionou ben. A clave é garantir que o proceso sexa transparente, que as expectativas sexan claras para todas as partes e que a situación se sinta xusta para todos.
O conflito é incluso un problema nunha organización? É un mal sinal de que os conflitos ocorren con frecuencia (ou só periódicamente) no teu equipo? En xeral, non, porque se hai crecemento, desenvolvemento, hai algún tipo de dinámica, entón xorden cuestións que nunca antes se resolveron, e ao resolvelas poden xurdir conflitos. Este é un indicador de que algunhas áreas precisan atención, de que hai áreas de mellora. É malo se os conflitos xorden con moita frecuencia, son difíciles de resolver ou levan moito tempo. Isto probablemente sexa un sinal de procesos de traballo insuficientemente racionalizados e de madurez insuficiente do equipo.
Fonte: www.habr.com