Управљање конфликтима у тиму – балансирање или витална потреба?

епиграф:
Једном давно у шуми су се срели Јеж и медвед.
- Здраво, Јеж!
- Здраво, мали медо!
Дакле, реч по реч, шалу по шалу, Јежа је ударио у лице Мали медвед...

У наставку је дискусија нашег вође тима, као и директора развоја производа РАС Игора Марната, о специфичностима радних сукоба и могућим методама за њихово управљање.

Већина конфликата са којима се сусрећемо на послу развијају се по сценарију сличном оном описаном у горњем епиграфу. Постоји неколико учесника који су у почетку прилично наклоњени једни према другима, покушавају да реше неко питање, али на крају проблем остаје нерешен, а односи између учесника у дискусији из неког разлога испадају покварени.

Живот је разнолик, а варијације се јављају у горе описаном сценарију. Понекад однос између учесника у почетку није баш добар, понекад чак и не постоји питање које захтева директно решење (као, на пример, у епиграфу), понекад након дискусије однос остаје исти као пре почетка, али проблем на крају није решен.

Шта је заједничко у свим ситуацијама које се могу дефинисати као ситуација радног конфликта?



Прво, постоје две или више страна. Ове странке могу заузимати различита места у организацији, бити у равноправном односу (колеге у тиму), или на различитим нивоима хијерархије (шеф – подређени), бити појединачне (запослени) или групне (у случајевима сукоба између запослени и тим или два тима) и тако даље. На вероватноћу сукоба и лакоћу његовог решавања у великој мери утиче ниво поверења између учесника. Што се стране боље познају, што је већи ниво поверења, већа је и шанса да се договоре. На пример, већа је вероватноћа да ће чланови дистрибуираног тима који никада нису комуницирали лицем у лице доживети сукоб због једноставног посла него људи који су имали бар неколико интеракција лицем у лице. Стога, када радите у распоређеним тимовима, веома је важно осигурати да се сви чланови тима периодично састају лично једни са другима.

Друго, у ситуацији конфликта на послу, странке су у ситуацији да решавају неко питање које је важно за једну од страна, за обе, или за организацију у целини. Истовремено, због специфичности ситуације, странке обично имају довољно времена и различите начине да је реше (формални, неформални, састанци, писма, одлуке управе, присуство циљева и планова тима, чињеница хијерархије итд.). Ово се разликује од ситуације решавања радног (или нерадног) питања у организацији од, на пример, решавања важног питања: „Ех, мали, из ког си краја?“ на улици, или сукоб из епиграфа. У случају решавања радног питања важан је квалитет процеса рада и култура решавања питања у тиму.

Треће, одлучујући фактор сукоба (са тачке гледишта наше расправе) је чињеница да стране у процесу не могу самостално да дођу до решења питања које одговара свим странама. Ситуација захтева интервенцију треће стране, спољног арбитра. Ова тачка може изгледати контроверзна, али, у суштини, ако је конфликтна ситуација успешно решена без интервенције спољног арбитра, питање је успешно решено и односи страна се нису погоршали, то је ситуација којој треба тежити. . За такав сукоб највероватније нећемо ни знати, или ћемо случајно сазнати након његовог разрешења. Што више проблема тим може да реши сам, то ће бити ефикаснији.

Још једна карактеристична карактеристика сукоба коју вреди дотакнути је степен емоционалног интензитета током одлуке. Конфликт није нужно повезан са високим емоционалним нивоом. Учесници не морају да вичу и машу рукама да би ситуација била, у суштини, сукоб. Питање није решено, присутна је одређена емоционална напетост (можда није јасно изражена споља), што значи да смо суочени са ситуацијом конфликта.

Да ли је уопште потребно интервенисати у конфликтним ситуацијама или је боље пустити њихово решавање да иде својим током и сачекати да се проблем реши сам од себе? Морати. Није увек у вашој моћи или надлежности да у потпуности решите конфликт, али у било којој ситуацији, у сукобу било ког обима, можете заузети став одрасле особе, доводећи на тај начин још неколико људи око себе, ублажити негативне последице сукоба и доприносе његовом решавању.

Пре него што погледамо неколико примера конфликтних ситуација, погледајмо неколико важних тачака заједничких за све конфликте.

Приликом решавања сукоба важно је бити изнад борбе, а не унутар ње (ово се још назива и „заузимање мета-позиције“), односно не бити део једне од страна у процесу решавања. У супротном, помоћ спољног арбитра у одлуци само ће ојачати позицију једне од страна на штету друге стране. Приликом доношења одлуке важно је да она буде морално прихваћена од свих страна, како кажу, „купљена“. Тако да су странке, чак и ако нису биле одушевљене донетом одлуком, барем искрено пристале да је спроведу. Како кажу, да умеју да се не слажу и обавежу. У супротном, сукоб ће једноставно променити свој изглед, тињајућа ватра ће остати испод тресетишта и у неком тренутку ће се неминовно поново распламсати.

Друга тачка, делимично повезана са првом, јесте да ако сте већ одлучили да учествујете у решавању конфликта, схватите то што је могуће озбиљније са становишта комуникација и проучавања контекста. Разговарајте лично са сваком од страна. Одвојено са сваким, за почетак. Не задовољавајте се поштом. У случају распоређеног тима, барем разговарајте путем видео везе. Немојте се задовољити причама из друге руке и извештајима очевидаца. Схватите причу, шта свака страна жели, зашто то жели, шта очекују, да ли су већ покушавали да реше ово питање, шта ће се десити ако се не реши, каква решења виде, како замишљају позицију друга страна, шта они мисле, исправно или погрешно, итд. Учитајте сав могући контекст у своју главу, отвореног ума, под претпоставком да су сви у праву. Нисте унутар конфликта, ви сте изван њега, у метапозицији. Ако је контекст доступан само у теми поста, барем га прочитајте у целини и теме и документе који се односе на њега. Након што га прочитате, и даље говорите својим гласом. Готово је загарантовано да ћете чути нешто важно што није у пошти.

Трећа важна тачка је општи приступ комуникацији. То су обичне ствари, ништа космичко, али су веома важне. Не покушавамо да уштедимо време, разговарамо са свим учесницима, не критикујемо особу, али разматрамо последице његових поступака (не „ти си безобразан“, већ „можда су момци увређени због ову ствар”), дајемо прилику да сачувамо образ, водимо разговоре лично, а не испред реда.

Конфликти су обично узроковани једним од два разлога. Први се односи на то да ли је особа у тренутку сукоба у положају одрасле особе или у положају детета (о томе више у наставку). То је због његове емоционалне зрелости, способности да управља својим емоцијама (што, иначе, није увек повезано са његовим годинама). Други чест разлог је несавршеност процеса рада, што ствара ситуације сивих зона у којима је одговорност распоређена између учесника, очекивања страна нису транспарентна једна другој, а улоге у процесу су замагљене.

Сходно томе, у решавању конфликта (као и сваког другог питања), менаџер мора да има на уму три перспективе: краткорочну – да реши проблем/конфликт овде и сада, средњорочну – да минимизира вероватноћу избијања новог конфликта. из истог разлога, а дугорочно – да негује културу одраслих у тиму.

Свако од нас има унутрашње дете, старо око три или четири године. Већину времена спава на послу, али се понекад пробуди и преузме контролу. Дете има своје приоритете. Важно му је да инсистира да је ово његов сандук, да га мајка више воли, да му је машина најбоља (дизајн је најбољи, он најбоље програмира, ...). У ситуацији конфликта, дете може да притисне играчке, да гази ногама и да лопати лопатицу, али не може да реши проблеме одраслих (архитектура решења, приступи аутоматизованом тестирању, датуми пуштања у продају итд.), не размишља у смислу користи за тим. Дете у сукобу се може охрабрити, утешити и послати у кревет тако што ћете га замолити да позове своју одраслу особу. Пре него што започнете дискусију у конфликтној ситуацији, уверите се да разговарате са одраслом особом, а не са дететом, и да сте и сами у позицији одрасле особе. Ако је ваш искрени циљ у овом тренутку да решите озбиљан проблем, ви сте у позицији одрасле особе. Ако вам је циљ да газите ногама и напукнете лопатицу, ово је детињаста позиција. Пошаљите своје унутрашње дете у кревет и позовите одраслу особу или поново закажите дискусију. Човек доноси емоционалну одлуку, а затим тражи рационално оправдање за то. Одлука коју дете донесе на основу дечјих приоритета неће бити оптимална.

Поред понашања у тренутку сукоба, положај детета или одрасле особе карактерише и ниво одговорности који је особа спремна да преузме на себе. У својим екстремним манифестацијама, детињаста позиција програмера, коју сам срео више пута, изгледа овако: написао сам код, послао га на преглед - мој посао је завршен. Рецензенти треба да га прегледају и одобре, КА треба да провери, ако буде проблема, обавестиће ме. Чудно је да се чак и прилично зрели и искусни људи понекад понашају на овај начин. Други крај скале је да особа себе сматра одговорном да осигура да његов код функционише, да је покривен тестовима, да је он лично проверио, да је успешно прошао преглед (ако је потребно, нема проблема да пингује рецензенте, да дискутује о проблемима гласом, итд.) и потиснут је , КА ће пружити помоћ ако је потребно, биће описани сценарији тестирања итд. У нормалним случајевима, програмер или почиње ближе крају скале за одрасле, или се креће тамо како стиче искуство (под условом да се у тиму гаји права култура). У екстремним случајевима, он наставља да ради, обично заузима детињасту позицију, тада он и тим повремено имају проблеме и сукобе.

Неговање праве, зреле културе у тиму је важан задатак за сваког менаџера. Потребно је много времена и свакодневног труда, али резултат је вредан тога. Постоје два начина да се утиче на тимску културу – вођење примером (који ће се свакако следити; тим увек гледа на вођу) и дискусија и награђивање исправног понашања. Ни ту нема ничег апструозног или веома формалног, само када се расправља о проблемима, приметите да је овде могло нешто да се уради, нагласите да сте приметили када је то исправно одлучено, похвалите, приметите приликом прегледа издања итд.

Хајде да размотримо неколико типичних конфликтних ситуација, од једноставних до сложених:

Сукоби који нису везани за радна питања

На послу често долази до сукоба који нису везани за радна питања. Њихова појава и лакоћа решавања обично су у директној вези са нивоом емоционалне интелигенције учесника, степеном њихове зрелости, а нису у вези са савршенством или несавршеношћу процеса рада.

Типични примери: неко не користи довољно често веш машину или туш, што се другима не свиђа, некоме је загушљиво, док други добија ветар ако отворе прозор, неко је превише бучан, а другима је потребна тишина за рад, и ускоро. Боље је не одлагати решавање оваквих сукоба и не дозволити им да иду својим током. Неће се сами решити и свакодневно ће вас одвлачити од посла и тровати атмосферу у тиму. Срећом, њихово решавање обично није велики проблем - само мирно разговарајте (један на један, наравно) са колегом који занемарује хигијену, обезбедите удобно седење људима који воле тишину/хладноћу, купите слушалице које апсорбују звук или инсталирајте преграде , итд.

Други пример са којим сам се неколико пута сусрео током свог рада је психолошка некомпатибилност чланова тима. Из неког разлога људи једноставно не могу да раде заједно; свака интеракција се завршава скандалом. Понекад је то због чињенице да људи имају поларне ставове о неком хитном питању (обично политичком) и не знају како да их оставе ван посла. Убедити их да толеришу једни друге или да промене своје понашање је прилично узалудан задатак. Једини изузетак са којим сам се сусрео су младе колеге отворене перцепције, чије понашање се и даље може постепено мењати кроз периодичне разговоре. Обично се проблем успешно решава тако што се они раздвоје у различите тимове, или барем дају прилику да се врло ретко преклапају на послу.

У свим горе наведеним ситуацијама, вреди лично разговарати са свим учесницима, продискутовати ситуацију, питати да ли уопште виде проблем у овом случају, питати која су, по њиховом мишљењу, решења и обезбедити њихово учешће у изради овог одлука.

Са становишта оптимизације процеса рада (средњорочна перспектива коју сам поменуо), ту се не може много урадити, једино што треба оптимизовати је да се при формирању тима води рачуна о фактору компатибилности и да се не стављају људи. заједно унапред ко ће се сукобити.

Из перспективе тимске културе, овакве ситуације се много ређе јављају у тимовима са зрелом културом, где људи поштују тим и колеге и знају како да самостално решавају проблеме. Осим тога, такви сукоби се много лакше (често аутоматски) решавају у тимовима у којима постоји висок ниво поверења, људи дуго раде заједно и/или често комуницирају ван посла.

Конфликти у вези са пословима:

Овакве сукобе најчешће изазивају оба разлога одједном, како емоционални (чињеница да један од учесника није у позицији одрасле особе) тако и несавршеност самог процеса рада. Можда најчешћи тип сукоба на који сам наишао су сукоби током прегледа кода или дискусија о архитектури између програмера.

Овде бих истакао два типична случаја:

1) У првом случају, програмер не може добити преглед кода од колеге. Закрпа је послата на преглед и ништа се не дешава. На први поглед не постоји очигледан сукоб између две стране, али ако боље размислите, ово је прилично сукоб. Питање рада није решено, једна од страна (која чека преглед) доживљава очигледну нелагодност. Екстремни подтип овог случаја је развој у заједници или у различитим тимовима, док рецензент можда неће бити заинтересован за овај конкретан код, због учитавања или других околности, можда уопште не обраћа пажњу на захтев за ревизију, а спољни арбитар (менаџер заједнички за обе стране) ) можда уопште не постоји.

Приступ решења који помаже у таквој ситуацији односи се управо на дугорочну перспективу, културу одраслог човека. Прво, паметна активност функционише. Не треба очекивати да ће код који виси на рецензији привући пажњу самог рецензента. Морамо помоћи рецензентима да га примете. Пингани пар људи, постави питање на синкапе, учествује у дискусијама. Очигледно је да ће упорност пре наштетити него помоћи, морате користити здрав разум. Друго, претприпрема добро функционише. Ако тим разуме шта се дешава и зашто, зашто је овај код уопште потребан, дизајн је са свима унапред размотрен и договорен, већа је вероватноћа да ће људи обратити пажњу на такав код и прихватити га за рад. Треће, ауторитет функционише. Ако желите да будете рецензирани, урадите много рецензија сами. Урадите рецензије високог квалитета, са стварним проверама, правим тестовима и корисним коментарима. Ако је ваш надимак добро познат у тиму, већа је шанса да ће ваш код бити примећен.

Са тачке гледишта тока посла, могућа побољшања су исправан приоритет који има за циљ да помогне програмеру да постигне своје циљеве и циљеве тима (прегледа друге, пише писма заједници, пропрати код описом архитектуре, документацијом, тестовима, учествује у дискусијама са заједница, итд.), спречити да закрпе предуго висе у реду и тако даље.

2) Други уобичајени случај сукоба током прегледа кода или дизајна су различити погледи на техничка питања, стил кодирања и избор алата. Од великог значаја у овом случају је ниво поверења између учесника, припадност истом тиму и искуство заједничког рада. Слепа улица настаје када неко од учесника заузме детињасту позицију и не покушава да чује шта саговорник жели да му пренесе. Често, и приступ који је предложила друга страна и приступ који је првобитно предложен могу добро функционисати и у принципу није важно који ћете изабрати.

Једног дана, програмер из мог тима (назовимо га Паша) припремио је закрпу са изменама система за имплементацију пакета, коју су развиле и подржале колеге из суседног одељења. Један од њих (Игор) је имао своје чврсто мишљење о томе како тачно треба конфигурисати Линук сервисе приликом постављања пакета. Ово мишљење се разликовало од приступа предложеног у закрпи и нису се могли сложити. Као и обично, рокови су истицали и требало је донети неку одлуку, било је потребно да неко од њих заузме одраслу позицију. Паша је признао да оба приступа имају право на живот, али је желео да његова опција прође, јер Ни једна ни друга опција нису имале очигледне техничке предности.

Наша дискусија је изгледала отприлике овако (веома шематски, наравно, разговор је трајао пола сата):

- Паша, имамо замрзавање функције за неколико дана. Важно је да све скупимо и почнемо да тестирамо што је пре могуће. Како можемо прећи преко Игора?
— Жели другачије да постави сервисе, ту ми је закачио коментаре...
- А шта је ту, велике преправке, велика гужва?
- Не, има посла на пар сати, али на крају нема разлике, радиће и онако, зашто је ово потребно? Направио сам нешто што функционише, хајде да то прихватимо.
- Слушај, колико дуго о свему овоме расправљаш?
– Да, већ недељу и по обележавамо време.
- Хм... можемо ли за пар сати да решимо проблем који је већ трајао недељу и по, а да то не урадимо?
- Па да, али нећу да Игор помисли да сам поклекнуо...
- Слушај, шта ти је важније, да издаш ослобођење, уз своју одлуку унутра, или да убијеш Игора? Можемо га блокирати, међутим, постоји добра шанса да прођемо са ослобађањем.
- Па... било би кул, наравно, Игору обрисати нос, али добро, важније је ослобађање, слажем се.
- Да ли вам је заиста толико важно шта Игор мисли? Да будем искрен, њега уопште не занима, он само жели јединствен приступ на различитим местима ствари за које је одговоран.
- Добро, добро, да урадим како он тражи у коментарима и да почнемо да тестирамо.
- Хвала ти, паша! Био сам сигуран да ћеш од вас двоје бити зрелији, иако је Игорек старији од вас :)

Питање је решено, ослобађање је пуштено на време, паша није осећао велико незадовољство, јер сам је предложио решење и спровео га у дело. Игор је генерално био задовољан, јер... Његово мишљење је узето у обзир и урадили су како је он предложио.

Друга врста суштински истог конфликта је избор између техничких решења/библиотека/приступа у пројекту, посебно у дистрибуираном тиму. У једном од пројеката, који је позициониран као да користи Ц/Ц++, показало се да је техничко управљање пројектом категорично против употребе СТЛ (Стандард Темплате Либрари). Ово је библиотека стандардног језика која поједностављује развој, а наш тим је веома навикао на то. Испоставило се да је пројекат много ближи Ц него Ц++, што није много инспирисало тим, јер менаџмент је дао све од себе и регрутовао заиста цоол плус играче. Истовремено, амерички део тима, и инжењери и менаџери, дуго су радили у компанији, навикли на постојеће стање и свиме су били задовољни. Руски део тима је окупљен сасвим недавно, за неколико недеља (укључујући и мене). Руски део тима категорички није желео да напусти уобичајени приступ развоју.

Почеле су бескрајне писане расправе између два континента, писма на три или четири екрана су летела напред-назад, у групним и личним порукама, од програмера до програмера и менаџера. Како то обично бива, писма ове дужине није читао нико осим аутора и њихових ватрених присталица. Четови су шкрипали од напетости, преносећи мисли на више екрана у различитим правцима у вези са техничким предностима СТЛ-а, колико је добро тестиран, колико је сигуран, и уопште, како је диван живот са њим, а како је ужасан без њега .

Све је то трајало доста дуго, док нисам коначно схватио да смо разговарали о техничким аспектима проблема, али проблем у стварности није био технички. Проблем нису предности или недостаци СТЛ-а или тешкоћа рада без њега. Проблем је пре организационог карактера. Требало је само да схватимо како функционише компанија за коју смо радили. Нико од нас раније није имао искуство рада у таквој компанији. Ствар је била у томе што су након што је код развијен и пуштен у производњу, подршком су се бавили потпуно другачији људи из других тимова, из других земаља. Ова огромна инжењерска екипа од неколико десетина хиљада инжењера (укупно) могла је себи да приушти само сасвим основни минимум техничких средстава, да тако кажем, минимални минимум. Све што је превазилазило инжењерски стандард успостављен у компанији физички није могло бити подржано у будућности. Ниво тима је одређен нивоом његових најслабијих чланова. Након што смо разумели стварна мотивација акцијама америчког дела тима, ово питање је скинуто са дневног реда и заједно смо успешно развили и пустили производ користећи стандарде које је усвојила компанија. Писма и ћаскања у овом случају нису добро функционисала, било је потребно неколико путовања и много личне комуникације да би дошли до заједничког имениоца.

Са становишта тока посла, у овом конкретном случају, било би од помоћи да постоји опис коришћених алата, захтеви за њих, ограничења за додавање нових и оправдање за таква ограничења. Такви документи приближно одговарају онима описаним у параграфима Стратегија поновне употребе и развојно окружење „Приручника за менаџере за развој софтвера“, развијеног у НАСА. Упркос својој старости, савршено описује све главне активности и фазе планирања развоја софтвера ове врсте. Поседовање оваквих докумената олакшава дискусију о томе које компоненте и приступи се могу користити у производу и зашто.

Са културолошке тачке гледишта, очигледно, са зрелијом позицијом, у којој странке покушавају да чују и разумеју стварну мотивацију поступака својих колега и делују на основу приоритета пројекта и тима, а не личног ега. , сукоб би се лакше и брже решио.

У другом сукобу око избора техничког решења, такође ми је требало приметно време да разумем мотивацију једне од страна (то је био веома необичан случај), али након што је мотивација била јасна, решење је било очигледно.

Ситуација је следећа: нови програмер се појављује у тиму од око 20 људи, назовимо га Стас. У то време, наш стандардни алат за тимску комуникацију био је Скипе. Како се касније испоставило, Стас је био велики љубитељ отворених стандарда и софтвера отвореног кода и користио је само алате и оперативне системе чији су извори били јавно доступни и који су користили јавно описане протоколе. Скипе није један од ових алата. Провели смо доста времена разговарајући о предностима и недостацима овог приступа, покушајима да се лансирају аналоги Скипе-а на различитим оперативним системима, Стасовим покушајима да убеди тим да пређе на друге стандарде, пише му лично поштом, зове га лично на телефон, купи му други рачунар посебно за скајп итд. Коначно, схватио сам да овај проблем, у суштини, није технички или организациони, већ је идеолошки, чак, рекло би се, религиозни (за Стаса). Чак и када бисмо на крају повезали Стаса и Скипе (што је трајало неколико месеци), проблем би се поново појавио на сваком следећем инструменту. Нисам имао на располагању реална средства да променим Стасов поглед на свет, а није било ни разлога да покушавам да променим поглед на свет тима који је савршено функционисао у овој средини. Особа и компанија су једноставно били ортогонални у свом погледу на свет. У таквим ситуацијама добро решење је организационо. Стаса смо пребацили у други тим, где је био више органски.

Разлог за овај сукоб је, по мом мишљењу, несклад између личне културе одређене особе (која има чврсто мишљење које му не дозвољава компромис) и културе компаније. У овом случају је, наравно, грешка менаџера. У почетку је било погрешно узети га на пројекат ове врсте. Стас је на крају прешао на пројекат развоја софтвера отвореног кода и ту се истакао.

Добар пример конфликта изазваног детињастим ставом програмера и недостацима процеса рада је ситуација у којој, у недостатку дефиниције урађеног, програмер и КА тим имају различита очекивања у погледу спремности карактеристика пренета на КА. Програмер је веровао да је довољно написати код и бацити функцију преко ограде у КА - они ће то средити тамо. Иначе, прилично зрео и искусан програмер, али то је био његов унутрашњи праг квалитета. КА се није сложио са овим и захтевао је да им покаже и опише шта је сам проверио, и захтевао је тестни сценарио за њих. Имали су проблема са функционалношћу овог програмера у прошлости и нису желели да поново губе време. Иначе, били су у праву - функција заиста није радила, није проверио код пре него што га је послао КА-у.

Да бих решио ситуацију, замолио сам га да ми покаже да све заиста функционише (није функционисало, а он је морао да поправи), разговарали смо са тимом и са КА дефиницијом готово (нису успели у писање, јер нисмо желели да процес буде превише бирократски), па, убрзо смо се растали са овим специјалистом (на опште олакшање).

Са становишта тока посла, могућа побољшања у овом случају су присуство дефиниције урађеног, захтева за подршку сваке карактеристике јединице и интеграционих тестова, као и опис тестирања које спроводи програмер. У једном од пројеката смо мерили ниво покривености кода тестовима током ЦИ и ако је ниво покривености пао након додавања закрпе, тестови су означени као неуспели, тј. било који нови код се могао додати само ако постоје нови тестови за њега.

Још један типичан пример сукоба уско везан за организацију радног процеса. Имамо производ, тим за развој производа, тим за подршку и купца. Купац има проблема са производом и контактира подршку. Подршка анализира проблем и схвата да је проблем у производу и преноси проблем на производни тим. Тим производа је у гужви, ближи се излазак, па тикет са проблемом од купца, изгубљен међу осталим тикетима програмера коме је додељен, виси неколико недеља без пажње. Подршка сматра да програмер ради на проблему корисника. Купац чека и нада се да ће се њихов проблем решити. У стварности се још ништа не дешава. После неколико недеља, корисник коначно одлучује да се заинтересује за напредак и пита подршку како ствари иду. Подршка тражи развој. Програмер се стресе, прегледа листу тикета и тамо пронађе тикет од купца. Читајући тикет од купца, он схвата да нема довољно информација за решавање проблема и да му је потребно више дневника и депонија. Подршка захтева додатне информације од корисника. И тада купац схвата да нико није радио на његовом проблему све ово време. И гром ће ударити...

У овој ситуацији, решење самог конфликта је прилично очигледно и линеарно (поправите производ, ажурирајте документацију и тестове, умирите купца, објавите хитну исправку, итд.). Важно је анализирати процес рада и разумети ко је одговоран за организовање интеракције између два тима и зашто је ова ситуација уопште постала могућа. Јасно је шта треба поправити у процесу - неко мора проактивно пратити укупну слику без подсетника купаца. Карте од купаца треба да се издвајају међу осталим улазницама од програмера. Подршка треба да види да ли развојни тим тренутно ради на својим тикетима, а ако не, када може да почне да ради и када се могу очекивати резултати. Подршка и развој треба да периодично комуницирају и разговарају о статусу тикета, прикупљање информација неопходних за отклањање грешака треба да буде аутоматизовано што је више могуће, итд.

Као што у рату непријатељ покушава да погоди спој између две јединице, тако је у раду најделикатнија и најрањивија тачка обично интеракција између тимова. Ако су менаџери за подршку и развој довољно стари, моћи ће сами да поправе процес, ако не, процес ће наставити да генерише конфликте и проблеме све док се не умеша менаџер који може да поправи ситуацију.

Још један типичан пример који сам више пута виђао у различитим компанијама је ситуација у којој производ пише један тим, тестове аутоматске интеграције за њега пише други тим, а инфраструктуру на којој све ради прати трећи тим. тим. Проблеми при покретању тестова се јављају стално, а узрок проблема у њима може бити и производ и тестови и инфраструктура. Обично је проблематично договорити се ко треба да изврши почетну анализу проблема, грешака у фајловима, парсирање дневника производа, тестова и инфраструктуре итд. Сукоби су овде веома чести, а уједно и једнообразни. У случају високог емоционалног интензитета, учесници често падају у детињасту позицију и у серији почињу дискусије: „зашто да се петљам са овим“, „чешће се кваре“ итд.

Из перспективе тока посла, конкретни кораци за решавање проблема зависе од састава тимова, врсте тестова и производа итд. У једном од пројеката увели смо периодично дежурство, у којем су тимови пратили тестове један по један, из недеље у недељу. У другом, почетну анализу су увек радили програмери теста, али анализа је била врло основна и производ је био прилично стабилан, тако да је добро функционисао. Кључно је осигурати да процес буде транспарентан, да су очекивања јасна за све стране и да је ситуација праведна за све.

Да ли је конфликт чак и проблем у организацији? Да ли је лош знак да се сукоби често (или само повремено) јављају у вашем тиму? Генерално, не, јер ако постоји раст, развој, постоји нека динамика, онда настају питања која никада раније нису била решена, а приликом њиховог решавања могу настати сукоби. Ово је показатељ да неким областима треба обратити пажњу, да постоје области за побољшање. Лоше је ако се сукоби јављају врло често, тешко их је решити или трају дуго. Ово је највероватније знак недовољно усавршених радних процеса и недовољне зрелости тима.

Извор: ввв.хабр.цом