Epígraf:
Hi havia una vegada, l'eriçó i l'ós petit es van trobar al bosc.
-Hola, eriçó!
- Hola, Osset!
Així doncs, paraula per paraula, acudit per acudit, l'Eriçó va ser colpejat a la cara per l'ós petit...
A continuació es presenta una discussió del nostre líder d'equip, així com del director de desenvolupament de productes de RAS, Igor Marnat, sobre les especificitats dels conflictes laborals i els possibles mètodes per gestionar-los.
La majoria dels conflictes que ens trobem a la feina es desenvolupen segons un escenari semblant al descrit a l'epígraf anterior. Hi ha diversos participants que inicialment estan força favorables els uns als altres; estan intentant resoldre algun problema, però al final el problema segueix sense resoldre i, per alguna raó, les relacions entre els participants en la discussió es fan malbé.
La vida és diversa i es produeixen variacions en l'escenari descrit anteriorment. De vegades la relació entre els participants no és molt bona inicialment, de vegades ni tan sols hi ha un tema que requereixi una solució directa (com, per exemple, a l'epígraf), de vegades després de la discussió la relació segueix sent la mateixa que abans de començar, però el problema finalment no està resolt.
Què és comú en totes les situacions que es poden definir com a situació de conflicte laboral?
En primer lloc, hi ha dos o més costats. Aquestes parts poden ocupar diferents llocs de l'organització, estar en una relació d'igualtat (col·legues en un equip), o en diferents nivells de la jerarquia (cap - subordinat), ser individuals (empleat) o grupal (en casos de conflicte entre un empleat i un equip o dos equips), etc. La probabilitat de conflicte i la facilitat de la seva resolució estan molt influenciades pel nivell de confiança entre els participants. Com millor es coneguin les parts, més alt és el nivell de confiança, més possibilitats d'arribar a un acord. Per exemple, els membres d'un equip distribuït que mai no han interactuat cara a cara tenen més probabilitats d'experimentar conflictes per una qüestió de treball senzilla que les persones que han tingut almenys algunes interaccions cara a cara. Per tant, quan es treballa en equips distribuïts, és molt important assegurar-se que tots els membres de l'equip es reuneixen periòdicament en persona.
En segon lloc, en una situació de conflicte laboral, les parts es troben en una situació de resolució d'alguna qüestió que és important per a una de les parts, per a totes dues o per al conjunt de l'organització. Al mateix temps, a causa de les particularitats de la situació, les parts solen disposar de temps suficient i de diferents maneres de resoldre-la (formals, informals, reunions, cartes, decisions de gestió, presència d'objectius i plans de l'equip, fet d'una jerarquia, etc.). Això és diferent de la situació de resoldre un problema laboral (o no laboral) en una organització de, per exemple, resoldre una pregunta important: "Eh, noi, de quina zona ets?!" al carrer, o el conflicte des de l'epígraf. En el cas de resoldre una qüestió de treball, la qualitat del procés de treball i la cultura de resolució de problemes en l'equip són importants.
En tercer lloc, el factor determinant del conflicte (des del punt de vista de la nostra discussió) és el fet que les parts del procés no poden arribar de manera autònoma a una solució del problema que convé a totes les parts. La situació requereix la intervenció d'un tercer, un àrbitre extern. Aquest punt pot semblar controvertit, però, en essència, si la situació de conflicte es va resoldre amb èxit sense la intervenció d'un àrbitre extern, el problema es va resoldre amb èxit i les relacions de les parts no es van deteriorar, aquesta és la situació a la qual hauríem d'esforçar-nos. . El més probable és que ni tan sols sabrem d'un conflicte d'aquest tipus, o ho sabrem per casualitat després que s'hagi resolt. Com més problemes pugui resoldre un equip per si mateix, més efectiu serà.
Un altre tret característic del conflicte que val la pena tocar és el grau d'intensitat emocional durant la decisió. El conflicte no s'associa necessàriament amb un alt nivell emocional. Els participants no han de cridar i agitar els braços perquè la situació sigui, en essència, un conflicte. El tema no està resolt, hi ha una certa tensió emocional (potser no s'expressa clarament a l'exterior), la qual cosa fa que ens trobem davant d'una situació de conflicte.
És necessari intervenir en situacions de conflicte, o és millor deixar que la seva resolució segueixi el seu curs i esperar que el problema es resolgui? Necessitar. No sempre està en el teu poder o competència resoldre el conflicte completament, però en qualsevol situació, en un conflicte de qualsevol escala, pots adoptar una posició adulta, apropant-hi moltes persones més al teu voltant, mitigant les conseqüències negatives del conflicte i contribuir a la seva resolució.
Abans de veure alguns exemples de situacions de conflicte, analitzem alguns punts importants comuns a tots els conflictes.
A l'hora de resoldre un conflicte, és important estar per sobre de la lluita, i no dins d'ella (això també s'anomena “prendre metaposició”), és a dir, no formar part d'una de les parts en el procés de resolució. En cas contrari, comptar amb l'assistència d'un àrbitre extern a la decisió només reforçarà la posició d'una de les parts en detriment de l'altra. A l'hora de prendre una decisió, és important que sigui moralment acceptada per totes les parts, com diuen, "comprat". De manera que, encara que les parts no estiguessin encantades amb la decisió presa, almenys van acceptar sincerament aplicar-la. Com diuen, per poder discrepar i comprometre's. En cas contrari, el conflicte simplement canviarà d'aspecte, el foc ardent romandrà sota la torba i, en algun moment, inevitablement tornarà a esclatar.
El segon punt, en part relacionat amb el primer, és que si ja t'has decidit a participar en la resolució d'un conflicte, t'ho prens el més seriosament possible des del punt de vista de les comunicacions i de l'estudi del context. Parleu personalment amb cadascuna de les parts. Per separat amb cadascun, per començar. No et conformis amb el correu. En el cas d'un equip distribuït, almenys parlar mitjançant un enllaç de vídeo. No us conformeu amb els informes de testimonis i testimonis. Comprendre la història, què vol cada bàndol, per què ho volen, què esperen, han intentat resoldre aquest problema abans, què passarà si no es resol, quines solucions veuen, com s'imaginen la posició de la l'altra banda, què en pensen, correcte o incorrecte, etc. Carregueu tot el context possible al vostre cap, amb una ment oberta, assumint que tothom té raó. No ets dins del conflicte, estàs fora d'ell, en una metaposició. Si el context només està disponible en un fil de publicació, almenys llegiu-lo sencer i els fils i documents relacionats amb ell. Després d'haver-lo llegit, encara parleu amb la vostra veu. Gairebé segur que escoltareu alguna cosa important que no està al correu.
El tercer punt important és l'enfocament general de la comunicació. Són coses corrents, res còsmics, però són molt importants. No intentem estalviar temps, parlem amb tots els participants, no critiquem a la persona, però tenim en compte les conseqüències de les seves accions (no “ets maleducat”, sinó “potser els nois es poden ofendre per això”), donem l'oportunitat de salvar la cara, fem converses en persona, no davant de la línia.
Els conflictes solen ser causats per una de dues raons. La primera està relacionada amb si una persona en el moment del conflicte està en la posició d'un adult o en la posició d'un nen (més informació a continuació). Això es deu a la seva maduresa emocional, a la capacitat de gestionar les seves emocions (que, per cert, no sempre està relacionada amb la seva edat). El segon motiu habitual és la imperfecció del procés de treball, que genera situacions de zones grises en les quals la responsabilitat s'estén entre els participants, les expectatives de les parts no són transparents entre elles i els rols en el procés es desdibuixen.
En conseqüència, a l'hora de resoldre un conflicte (així com qualsevol altre problema), un gestor ha de tenir en compte tres perspectives: a curt termini - per resoldre el problema/conflicte aquí i ara, a mitjà termini - per minimitzar la probabilitat que sorgeixi un altre conflicte. per la mateixa raó, ia llarg termini, per conrear una cultura adulta en la persona de l'equip.
Cadascun de nosaltres tenim un nen interior, d'uns tres o quatre anys. Dorm la major part del temps a la feina, però de vegades es desperta i pren el control. El nen té les seves pròpies prioritats. És important que insisteixi que aquesta és la seva caixa de sorra, la seva mare l'estima més, la seva màquina és la millor (el disseny és el millor, ell programa el millor,...). En una situació de conflicte, un nen pot prémer joguines, trepitjar els peus i trencar l'espàtula, però no pot resoldre problemes d'adults (arquitectura de solució, enfocaments de proves automatitzades, dates de llançament, etc.), no pensa en beneficis. per l'equip. Un nen en conflicte pot ser animat, consolat i enviat al llit demanant-li que truqui al seu adult. Abans d'iniciar una discussió en una situació de conflicte, assegura't que estàs parlant amb un adult, no amb un nen, i que tu mateix estàs en la posició d'un adult. Si el vostre objectiu honest en aquest moment és resoldre un problema greu, esteu en la posició d'un adult. Si el vostre objectiu és trepitjar els peus i trencar-vos l'omòplat, aquesta és una posició infantil. Envieu el vostre fill interior al llit i truqueu a un adult o reprograma la discussió. Una persona pren una decisió emocional i després busca una justificació racional. Una decisió presa per un nen en funció de les prioritats dels nens no serà òptima.
A més del comportament en el moment del conflicte, la posició d'un nen o adult també es caracteritza pel nivell de responsabilitat que una persona està disposada a assumir. En les seves manifestacions extremes, la posició infantil d'un programador, que he conegut més d'una vegada, es veu així: vaig escriure el codi, l'he enviat a revisió: la meva feina s'ha acabat. Els revisors l'han de revisar i aprovar, l'AQ l'ha de comprovar, si hi ha problemes, m'ho faran saber. Curiosament, fins i tot persones bastant madures i experimentades de vegades es comporten d'aquesta manera. L'altre extrem de l'escala és que una persona es considera responsable d'assegurar-se que el seu codi funciona, està cobert per proves, ha estat revisat personalment per ell, ha superat amb èxit la revisió (si cal, no hi ha cap problema per fer ping als revisors, discutir problemes). per veu, etc.) i s'ha suprimit, QA proporcionarà assistència si cal, es descriuran escenaris de prova, etc. En casos normals, el programador comença més a prop de l'extrem adult de l'escala o s'hi mou a mesura que adquireix experiència (sempre que es cultivi la cultura adequada dins de l'equip). En casos extrems, continua treballant, normalment prenent una posició infantil, aleshores ell i l'equip tenen periòdicament problemes i conflictes.
Fomentar la cultura adequada i madura en un equip és una tasca important per a qualsevol directiu. Es necessita molt de temps i esforç diari, però el resultat val la pena. Hi ha dues maneres d'influir en la cultura de l'equip: liderar amb l'exemple (que definitivament es seguirà; l'equip sempre mira cap al líder) i discutir i recompensar el comportament adequat. Aquí tampoc no hi ha res d'abstrus ni de molt formal, només quan parleu de problemes, noteu que aquí s'hauria pogut fer alguna cosa, emfatitzeu que us heu fixat quan s'ha decidit correctament, elogis, noteu durant la revisió del llançament, etc.
Considerem diverses situacions de conflicte típiques, de simples a complexes:
Conflictes no relacionats amb qüestions laborals
Molt sovint hi ha conflictes a la feina que no estan relacionats amb qüestions laborals. La seva ocurrència i facilitat de resolució solen estar directament relacionades amb el nivell d'intel·ligència emocional dels participants, el seu nivell de maduresa, i no estan relacionades amb la perfecció o imperfecció del procés de treball.
Exemples típics: algú no fa servir la rentadora o la dutxa amb prou freqüència, cosa que als altres no els agrada, algú està atapeït, mentre que altres agafa vent si obren la finestra, algú fa massa soroll i altres necessiten silenci per treballar, i així successivament. És millor no endarrerir la resolució d'aquest tipus de conflictes i no deixar-los seguir el seu curs. No es resoldran sols i et distrairan de la feina cada dia i enverinen l'ambient de l'equip. Afortunadament, resoldre'ls no sol ser un gran problema: només cal parlar amb calma (un a un, per descomptat) amb un company que descuidi la higiene, proporcioneu seients còmodes per a les persones que prefereixen el silenci/la frescor, compreu auriculars que absorbeixin el so o instal·leu particions. , etc.
Un altre exemple que em vaig trobar diverses vegades durant la meva feina és la incompatibilitat psicològica dels membres de l'equip. Per alguna raó, la gent simplement no pot treballar junts; cada interacció acaba en un escàndol. De vegades, això es deu al fet que la gent té opinions polars sobre algun tema urgent (generalment polític) i no sap com deixar-los fora de la feina. Convèncer-los perquè es toleren els uns als altres o canvien el seu comportament és una tasca força inútil. L'única excepció que he trobat són els companys joves amb percepcions obertes; el seu comportament encara es pot canviar gradualment a través de converses periòdiques. En general, el problema es resol amb èxit separant-los en diferents equips, o almenys proporcionant l'oportunitat de solapar-se a la feina molt poques vegades.
En totes les situacions anteriors, val la pena parlar personalment amb tots els participants, discutir la situació, preguntar-li si veuen algun problema en aquest cas, preguntar-se quines són, segons la seva opinió, les solucions i assegurar-se la seva participació per fer-ho. decisió.
Des del punt de vista de l'optimització del procés de treball (la perspectiva a mitjà termini que he comentat), aquí no es pot fer gaire, l'únic punt d'optimització és tenir en compte el factor de compatibilitat a l'hora de formar equip i no posar persones. junts per endavant qui entraran en conflicte.
Des d'una perspectiva de cultura d'equip, aquestes situacions sorgeixen amb molta menys freqüència en equips amb una cultura madura, on la gent respecta l'equip i els companys i sap resoldre els problemes de manera independent. A més, aquests conflictes es resolen amb molta més facilitat (sovint automàticament) en equips on hi ha un alt nivell de confiança, les persones han treballat junts durant molt de temps i/o es comuniquen amb freqüència fora de la feina.
Conflictes relacionats amb temes laborals:
Aquests conflictes solen ser causats per ambdues raons alhora, tant emocionals (el fet que un dels participants no estigui en la posició d'un adult) com la imperfecció del propi procés de treball. Potser el tipus de conflicte més comú que he trobat són els conflictes durant les revisions de codi o les discussions sobre l'arquitectura entre desenvolupadors.
Aquí destacaria dos casos típics:
1) En el primer cas, el desenvolupador no pot obtenir una revisió del codi d'un col·lega. El pegat s'envia a revisió i no passa res. A primera vista, no hi ha cap conflicte evident entre els dos bàndols, però si hi penseu bé, això és tot un conflicte. El problema laboral no està resolt, una de les parts (a l'espera d'una revisió) experimenta un malestar evident. Un subtipus extrem d'aquest cas és el desenvolupament en una comunitat o en diferents equips, mentre que el revisor pot no estar interessat en aquest codi en particular, a causa de la càrrega o d'altres circumstàncies, pot no prestar atenció a la sol·licitud de revisió i l'àrbitre extern. (un gestor comú a ambdues parts) ) pot no existir en absolut.
L'enfocament de la solució que ajuda en aquesta situació es relaciona precisament amb la perspectiva a llarg termini, la cultura d'un adult. En primer lloc, l'activitat intel·ligent funciona. No hauríeu d'esperar que el codi penjat a la revisió atragui l'atenció del propi revisor. Hem d'ajudar els revisors a notar-lo. Pingani un parell de persones, fer una pregunta sobre syncape, participar en debats. Òbviament, és més probable que la importunitat faci mal que ajudi, cal fer servir el sentit comú. En segon lloc, la preparació prèvia funciona bé. Si l'equip entén què està passant i per què, per què es necessita aquest codi, el disseny s'ha discutit i acordat per endavant amb tothom, és més probable que la gent presti atenció a aquest codi i l'accepti per treballar. En tercer lloc, l'autoritat funciona. Si voleu que us opinin, feu-ne moltes. Feu revisions d'alta qualitat, amb comprovacions reals, proves reals i comentaris útils. Si el vostre àlies és conegut a l'equip, hi ha més possibilitats que es noti el vostre codi.
Des del punt de vista del flux de treball, les possibles millores aquí són la priorització correcta destinada a ajudar el desenvolupador a assolir els seus objectius i els de l'equip (revisar els altres, escriure cartes a la comunitat, acompanyar el codi amb una descripció de l'arquitectura, documentació, proves, participar en debats amb comunitat, etc.), evitar que els pegats es pengin a la cua durant massa temps, etc.
2) El segon cas comú de conflictes durant les revisions del codi o del disseny són opinions diferents sobre problemes tècnics, estil de codificació i elecció d'eines. De gran importància en aquest cas és el nivell de confiança entre els participants, la pertinença al mateix equip, i l'experiència de treball conjunt. Es produeix un carreró sense sortida quan un dels participants pren una posició infantil i no intenta escoltar el que l'interlocutor li vol transmetre. Sovint, tant l'enfocament proposat per l'altra part com l'enfocament proposat inicialment poden funcionar amb èxit i en principi no importa quin triar.
Un dia, un programador del meu equip (anomenarem-lo Pasha) va preparar un pedaç amb canvis al sistema de desplegament de paquets, que va ser desenvolupat i recolzat per companys d'un departament veí. Un d'ells (Igor) tenia la seva pròpia opinió ferma sobre com s'haurien de configurar exactament els serveis de Linux en desplegar paquets. Aquesta opinió era diferent de l'enfocament proposat al pedaç, i no es podien posar d'acord. Com és habitual, els terminis s'esgotaven i calia prendre algun tipus de decisió, calia que un d'ells ocupés una posició d'adult. Pasha va reconèixer que ambdós enfocaments tenen dret a la vida, però volia que la seva opció passés, perquè Ni una ni la segona opció tenien cap avantatge tècnic evident.
La nostra discussió semblava a això (molt esquemàticament, és clar, la conversa va durar mitja hora):
- Pasha, tenim una funció congelada d'aquí a uns dies. És important que ho ajuntem tot i comencem a fer proves el més aviat possible. Com podem passar per Igor?
— Ell vol configurar els serveis d'una altra manera, m'ha enganxat comentaris...
- I què hi ha, grans alteracions, molt d'enrenou?
- No, hi ha feina per un parell d'hores, però al final no hi ha diferència, funcionarà de qualsevol manera, per què és necessari? He fet una cosa que funciona, acceptem-ho.
- Escolta, quant de temps portes parlant de tot això?
- Sí, ja fa una setmana i mitja que marquem el temps.
- Um... podem resoldre un problema en un parell d'hores que ja ha trigat una setmana i mitja, i no fer-ho?
- Bé, sí, però no vull que l'Igor pensi que he cedit...
- Escolta, què és més important per a tu, emetre un alliberament, juntament amb la teva decisió interior, o matar l'Igor? Podem bloquejar-lo, però, hi ha una bona oportunitat de volar amb el llançament.
- Bé... estaria bé, és clar, eixugar el nas a l'Igor, però d'acord, l'alliberament és més important, estic d'acord.
- És realment tan important per a tu el que pensa l'Igor? Per ser sincer, no li importa gens, només vol un enfocament unificat en diferents llocs de la cosa de la qual és responsable.
- Bé, d'acord, deixa'm fer el que demana als comentaris i comencem a provar.
- Gràcies, Pasha! Estava segur que de vosaltres dos serieu el més madur, encara que l'Igorek és més gran que vosaltres :)
El problema es va resoldre, el llançament es va publicar a temps, Pasha no va sentir gaire insatisfacció, perquè ell mateix va proposar una solució i la va implementar. L'Igor estava generalment satisfet, perquè... La seva opinió es va tenir en compte i van fer el que va suggerir.
Un altre tipus de conflicte essencialment el mateix és l'elecció entre solucions tècniques/biblioteques/enfocaments en un projecte, especialment en un equip distribuït. En un dels projectes, que es va posicionar com a C/C++, va resultar que la gestió tècnica del projecte estava categòricament en contra de l'ús de STL (Standard Template Library). Aquesta és una biblioteca de llenguatge estàndard que simplifica el desenvolupament, i el nostre equip hi està molt acostumat. Va resultar que el projecte s'acosta molt més al C que al C++, cosa que no va inspirar gaire l'equip, perquè la direcció va fer tot el possible i va reclutar jugadors molt interessants. Al mateix temps, la part nord-americana de l'equip, tant enginyers com directius, havia treballat a l'empresa durant molt de temps, estaven acostumats a l'estat de coses existent i estaven contents amb tot. La part russa de l'equip es va reunir fa poc, en poques setmanes (incloent-me a mi). La part russa de l'equip categòricament no va voler abandonar l'enfocament habitual del desenvolupament.
Van començar interminables discussions escrites entre els dos continents, cartes en tres o quatre pantalles van volar d'anada i tornada, en correus col·lectius i personals, des de programadors fins a programadors i gestors. Com sol ser el cas, cartes d'aquesta extensió no les llegien ningú, excepte els autors i els seus fervents partidaris. Els xats cruixent de tensió, passant pensaments multipantalla en diferents direccions sobre els avantatges tècnics de l'STL, el ben provat que està, el segur que és i, en general, el meravellós que és la vida amb ell i el terrible que és sense ell. .
Tot això va durar molt de temps, fins que finalment em vaig adonar que estàvem discutint els aspectes tècnics del tema, però el problema en realitat no era tècnic. El problema no són els avantatges o desavantatges de STL o la dificultat de treballar sense ell. El problema és més aviat organitzatiu. Només calia entendre com funcionava l'empresa per a la qual treballàvem. Cap de nosaltres no tenia experiència treballant en una empresa així. El cas va ser que després de desenvolupar el codi i llançar-se a producció, el suport va ser gestionat per persones completament diferents d'altres equips, d'altres països. Aquest enorme equip d'enginyers de diverses desenes de milers d'enginyers (en total) només es podia permetre un mínim d'equip tècnic completament bàsic, per dir-ho d'alguna manera, un mínim minimorum. Qualsevol cosa que va més enllà de l'estàndard d'enginyeria establert a l'empresa físicament no es podria suportar en el futur. El nivell d'un equip ve determinat pel nivell dels seus membres més febles. Després que ho entenguéssim motivació real accions de la part nord-americana de l'equip, aquest tema es va eliminar de l'agenda i junts vam desenvolupar i llançar el producte amb èxit amb els estàndards adoptats per l'empresa. Les cartes i els xats en aquest cas no van funcionar bé; van ser necessaris diversos viatges i molta comunicació personal per arribar a un denominador comú.
Des del punt de vista del flux de treball, en aquest cas concret, seria útil tenir una descripció de les eines utilitzades, els requisits per a aquestes, les restriccions per afegir-ne de noves i la justificació d'aquestes restriccions. Aquests documents corresponen aproximadament als descrits als apartats Estratègia de reutilització i Entorn de desenvolupament del “Manual del gestor per al desenvolupament de programari”, desenvolupat a . Malgrat la seva antiguitat, descriu perfectament totes les principals activitats i fases de planificació del desenvolupament de programari d'aquest tipus. Tenir documents com aquest fa que sigui molt fàcil discutir quins components i enfocaments es poden utilitzar en un producte i per què.
Des d'un punt de vista cultural, òbviament, amb una posició més madura, en la qual les parts intenten escoltar i entendre la motivació real de l'actuació dels seus companys i actuar en funció de les prioritats del projecte i de l'equip, i no de l'ego personal. , el conflicte es resoldria més fàcil i ràpid.
En un altre conflicte sobre l'elecció d'una solució tècnica, també em va costar molt de temps entendre la motivació d'una de les parts (era un cas molt inusual), però després que la motivació fos clara, la solució era evident.
La situació és la següent: apareix un nou desenvolupador en un equip d'unes 20 persones, diem-lo Stas. En aquell moment, la nostra eina estàndard de comunicació com a equip era Skype. Com va resultar més tard, Stas era un gran fan dels estàndards oberts i del programari de codi obert, i utilitzava només eines i sistemes operatius les fonts dels quals estaven disponibles públicament i que utilitzaven protocols descrits públicament. Skype no és una d'aquestes eines. Vam passar molt de temps discutint els avantatges i els desavantatges d'aquest enfocament, els intents de llançar anàlegs d'Skype en diferents sistemes operatius, els intents de Stas de convèncer l'equip de canviar a altres estàndards, escriure-li personalment per correu, trucar-li personalment al telèfon, compra-li un segon ordinador específicament per a Skype, etc. Finalment, em vaig adonar que aquest problema, en essència, no és tècnic ni organitzatiu, és més aviat ideològic, fins i tot, es podria dir, religiós (per a Stas). Fins i tot si finalment connectéssim Stas i Skype (que va trigar uns quants mesos), el problema tornaria a sorgir en qualsevol instrument posterior. No tenia cap mitjà real a la meva disposició per canviar la visió del món de l'Stas, i no hi havia cap raó per intentar canviar la visió del món d'un equip que funcionava perfectament en aquest entorn. La persona i l'empresa eren simplement ortogonals en la seva visió del món. En aquestes situacions, una bona solució és organitzativa. Vam traslladar Stas a un altre equip, on era més orgànic.
El motiu d'aquest conflicte, al meu entendre, és la discrepància entre la cultura personal d'una persona concreta (que té una opinió forta que no li permet comprometre's) i la cultura de l'empresa. En aquest cas, és clar, l'error del gerent. Al principi va ser un error portar-lo a un projecte d'aquest tipus. Stas finalment es va traslladar a un projecte de desenvolupament de programari de codi obert i hi va destacar.
Un bon exemple de conflicte provocat tant per l'actitud infantil del desenvolupador com per les mancances del procés de treball és una situació en què, a falta d'una definició de fet, el desenvolupador i l'equip de QA tenen expectatives diferents respecte a la preparació de la característica transferida a QA. El desenvolupador creia que n'hi havia prou d'escriure el codi i llançar la funció per sobre de la tanca al control de qualitat: ho solucionarien. Un programador bastant madur i experimentat, per cert, però aquest era el seu llindar intern de qualitat. QA no estava d'acord amb això i va exigir mostrar-los i descriure'ls què havia comprovat ell mateix, i els va demanar un guió de prova. Havien tingut problemes amb la funcionalitat d'aquest desenvolupador en el passat i no volien tornar a perdre el temps. Per cert, tenien raó: la funció realment no funcionava, no va comprovar el codi abans d'enviar-lo a QA.
Per resoldre la situació, li vaig demanar que em mostrés que tot funcionava realment (no va funcionar, i ell ho havia d'arreglar), vam parlar amb l'equip i amb la definició de control de qualitat de fet (no ho van fer en escriptura, perquè no volíem fer el procés massa burocràtic ), bé, aviat ens vam separar d'aquest especialista (amb relleu general).
Des del punt de vista del flux de treball, les possibles millores en aquest cas són la presència d'una definició de fet, requisits de suport de cada unitat de característica i proves d'integració, i una descripció de les proves realitzades pel desenvolupador. En un dels projectes, vam mesurar el nivell de cobertura del codi mitjançant proves durant CI i si el nivell de cobertura baixava després d'afegir un pedaç, les proves es marcaven com a fallides, és a dir. qualsevol codi nou només es podria afegir si hi hagués proves noves.
Un altre exemple típic de conflicte estretament relacionat amb l'organització del procés de treball. Tenim un producte, un equip de desenvolupament de productes, un equip de suport i un client. El client té problemes amb el producte i contacta amb l'assistència. El suport analitza el problema i entén que el problema està en el producte i el transfereix a l'equip del producte. L'equip del producte es troba en una època ocupada, s'acosta un llançament, de manera que un tiquet amb un problema d'un client, perdut entre els altres tiquets del desenvolupador al qual està assignat, es penja durant diverses setmanes sense atenció. El suport creu que el desenvolupador està treballant en el problema del client. El client espera i espera que es resolgui el seu problema. En realitat, encara no passa res. Al cap d'unes setmanes, el client finalment decideix interessar-se pel progrés i demana assistència com van les coses. El suport demana desenvolupament. El desenvolupador s'estremeix, mira la llista de bitllets i hi troba un bitllet del client. Llegint un bitllet d'un client, entén que no hi ha prou informació per resoldre el problema, i necessita més registres i abocadors. El suport sol·licita informació addicional al client. I aleshores el client s'adona que ningú ha estat treballant en el seu problema durant tot aquest temps. I el tron sonarà...
En aquesta situació, la solució del conflicte en si és força evident i lineal (arreglar el producte, actualitzar la documentació i les proves, apaivagar el client, llançar un hotfix, etc.). És important analitzar el procés de treball i entendre qui és el responsable d'organitzar la interacció entre els dos equips, i per què aquesta situació es va fer possible en primer lloc. Està clar què s'ha de solucionar en el procés: algú ha de supervisar la imatge general sense recordatoris dels clients, de manera proactiva. Les entrades del client han de destacar entre altres entrades dels desenvolupadors. El suport hauria de veure si l'equip de desenvolupament està treballant actualment en els seus tiquets i, si no, quan pot començar a funcionar i quan es poden esperar resultats. El suport i el desenvolupament s'han de comunicar periòdicament i discutir l'estat dels tiquets, la recollida d'informació necessària per a la depuració s'ha d'automatitzar al màxim, etc.
De la mateixa manera que en la guerra l'enemic intenta colpejar la cruïlla entre dues unitats, així en el treball el punt més delicat i vulnerable sol ser la interacció entre equips. Si els responsables de suport i desenvolupament tenen l'edat suficient, podran arreglar el procés ells mateixos, si no, el procés continuarà generant conflictes i problemes fins que intervingui un responsable que pugui arreglar la situació.
Un altre exemple típic que he vist repetidament en diferents empreses és una situació en què un producte està escrit per un equip, les proves d'integració automàtiques d'aquest són escrites per un segon equip i la infraestructura en què funciona tot va acompanyada d'un tercer. equip. Els problemes a l'hora d'executar proves sorgeixen tot el temps, i la causa dels problemes en elles poden ser tant el producte com les proves i la infraestructura. Normalment és problemàtic posar-se d'acord sobre qui ha de realitzar l'anàlisi inicial de problemes, fitxers d'errors, anàlisi de registres del producte, proves i infraestructura, etc. Els conflictes aquí són molt freqüents i, alhora, uniformes. En el cas d'alta intensitat emocional, els participants sovint cauen en una posició infantil i les discussions comencen a la sèrie: "per què hauria de jugar amb això", "es trenquen més sovint", etc.
Des d'una perspectiva de flux de treball, els passos específics per resoldre un problema depenen de la composició dels equips, del tipus de proves i producte, etc. En un dels projectes, vam introduir el deure periòdic, en què els equips supervisaven les proves d'un en un, setmana a setmana. A l'altra, l'anàlisi inicial sempre la feien els desenvolupadors de proves, però l'anàlisi era molt bàsica i el producte era força estable, així que funcionava bé. La clau és garantir que el procés sigui transparent, que les expectatives siguin clares per a totes les parts i que la situació se senti justa per a tothom.
El conflicte és fins i tot un problema en una organització? És un mal senyal que els conflictes es produeixin sovint (o només periòdicament) al vostre equip? En general, no, perquè si hi ha creixement, desenvolupament, hi ha algun tipus de dinàmica, aleshores sorgeixen qüestions que no s'havien resolt mai, i a l'hora de resoldre'ls poden sorgir conflictes. Aquest és un indicador que algunes àrees necessiten atenció, que hi ha àrees de millora. És dolent si els conflictes sorgeixen molt sovint, són difícils de resoldre o triguen molt de temps. És probable que això sigui un signe de processos de treball insuficientment racionalitzats i de maduresa insuficient de l'equip.
Font: www.habr.com