Управлението на конфликти в екип – балансиране или жизнена необходимост?

мото:
Имало едно време таралежът и малкото мече се срещнали в гората.
- Здравей, Ежко!
- Здравей, Мечо!
И така, дума по дума, шега по шега, Таралежът получи удар в лицето от Малката мечка...

По-долу е дискусия от нашия ръководител на екипа, както и от директора за развитие на продуктите на RAS Игор Марнат, относно спецификата на работните конфликти и възможните методи за тяхното управление.

Повечето от конфликтите, които срещаме на работа, се развиват по сценарий, подобен на описания в епиграфа по-горе. Има няколко участници, които първоначално са доста благоприятно настроени един към друг, те се опитват да разрешат някакъв проблем, но в крайна сметка проблемът остава неразрешен и по някаква причина отношенията между участниците в дискусията се оказват развалени.

Животът е разнообразен и в описания по-горе сценарий възникват вариации. Понякога отношенията между участниците първоначално не са много добри, понякога дори няма проблем, който да изисква пряко решение (както например в епиграфа), понякога след дискусията връзката остава същата, както преди да започне, но проблемът в крайна сметка не е решен.

Какво е общото във всички ситуации, които могат да бъдат определени като ситуация на работен конфликт?



Първо, има две или повече страни. Тези страни могат да заемат различни места в организацията, да бъдат в отношения на равнопоставеност (колеги в екип) или на различни нива на йерархията (шеф - подчинен), да бъдат индивидуални (служител) или група (в случаи на конфликт между служител и екип или два екипа) и т.н. Вероятността от конфликт и лекотата на разрешаването му се влияят до голяма степен от нивото на доверие между участниците. Колкото по-добре се познават страните, толкова по-високо е нивото на доверие, толкова по-голям е шансът да постигнат споразумение. Например, членовете на разпределен екип, които никога не са взаимодействали лице в лице, са по-склонни да изпитат конфликт по прост работен проблем, отколкото хората, които са имали поне няколко взаимодействия лице в лице. Следователно, когато работите в разпределени екипи, е много важно да се гарантира, че всички членове на екипа се срещат периодично лично един с друг.

Второ, в ситуация на конфликт на работното място, страните са в ситуация на разрешаване на някакъв въпрос, който е важен за една от страните, за двете страни или за организацията като цяло. В същото време, поради спецификата на ситуацията, страните обикновено разполагат с достатъчно време и различни начини за разрешаването й (официални, неформални, срещи, писма, управленски решения, наличие на цели и планове на екипа, факт на йерархия и др.). Това е различно от ситуацията на разрешаване на служебен (или неработен) проблем в организация от например разрешаването на важен въпрос: „Ех, хлапе, от кой район си?!” на улицата, или конфликтът от епиграфа. При решаването на работен проблем има значение качеството на работния процес и културата на решаване на проблеми в екипа.

Трето, определящият фактор на конфликта (от гледна точка на нашата дискусия) е фактът, че страните в процеса не могат самостоятелно да стигнат до решение на въпроса, което да устройва всички страни. Ситуацията изисква намесата на трето лице, външен арбитър. Тази точка може да изглежда спорна, но по същество, ако конфликтната ситуация е била успешно решена без намесата на външен арбитър, проблемът е решен успешно и отношенията между страните не са се влошили, това е ситуацията, към която трябва да се стремим . Най-вероятно дори няма да знаем за такъв конфликт или ще разберем случайно, след като бъде решен. Колкото повече проблеми един екип може да реши сам, толкова по-ефективен ще бъде той.

Друга характерна черта на конфликта, която си струва да се засегне, е степента на емоционална интензивност по време на решението. Конфликтът не е непременно свързан с високо емоционално ниво. Не е необходимо участниците да крещят и да махат с ръце, за да бъде ситуацията по същество конфликтна. Въпросът не е разрешен, има известно емоционално напрежение (може би не е ясно изразено външно), което означава, че сме изправени пред конфликтна ситуация.

Нужно ли е изобщо да се намесваме в конфликтни ситуации или е по-добре да оставим разрешаването им да върви по пътя си и да изчакаме проблемът да се реши сам? Трябва да. Не винаги е във вашата власт или компетентност да разрешите конфликта напълно, но във всяка ситуация, в конфликт от всякакъв мащаб, можете да заемете позиция на възрастен, като по този начин привлечете към него още няколко души около вас, смекчете негативните последици от конфликт и да допринесе за разрешаването му.

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

При разрешаването на конфликт е важно да сте над битката, а не вътре в нея (това се нарича още „заемане на метапозиция“), тоест да не сте част от една от страните в процеса на разрешаване. В противен случай помощта на външен арбитър при вземането на решение само ще засили позицията на една от страните в ущърб на другата страна. Когато вземате решение, важно е то да бъде морално прието от всички страни, както се казва, „купено“. Така че, дори и страните да не са възхитени от взетото решение, те поне искрено се съгласиха да го изпълнят. Както се казва, да можеш да не се съгласяваш и да се ангажираш. В противен случай конфликтът просто ще промени облика си, тлеещият огън ще остане под торфеното блато и в един момент неизбежно ще пламне отново.

Втората точка, отчасти свързана с първата, е, че ако вече сте решили да участвате в разрешаването на конфликта, вземете го възможно най-сериозно от гледна точка на комуникацията и изучаването на контекста. Говорете лично с всяка от страните. Отделно с всяка, като за начало. Не се задоволявайте с пощата. В случай на разпределен екип, говорете поне чрез видео връзка. Не се задоволявайте със слухове и доклади на очевидци. Разберете историята, какво иска всяка страна, защо го искат, какво очакват, опитвали ли са се да разрешат този проблем преди, какво ще се случи, ако не бъде решен, какви решения виждат, как си представят позицията на другата страна, какво мислят, правилно или грешно и т.н. Заредете целия възможен контекст в главата си, с отворен ум, приемайки, че всички са прави. Вие не сте вътре в конфликта, вие сте извън него, в метапозиция. Ако контекстът е достъпен само в нишка за публикация, поне я прочетете изцяло, както и темите и документите, свързани с него. След като го прочетете, все още говорете с гласа си. Почти гарантирано е, че ще чуете нещо важно, което не е по пощата.

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

Конфликтите обикновено са причинени от една от двете причини. Първият е свързан с това дали човек по време на конфликт е в позицията на възрастен или в позицията на дете (повече за това по-долу). Това се дължи на неговата емоционална зрялост, способността да управлява емоциите си (което, между другото, не винаги е свързано с възрастта му). Втората често срещана причина е несъвършенството на работния процес, което създава ситуации на сиви зони, в които отговорността е разпределена между участниците, очакванията на страните не са прозрачни една за друга, а ролите в процеса са размити.

Съответно при разрешаването на конфликт (както и на всеки друг проблем) мениджърът трябва да има предвид три перспективи: краткосрочна – да разреши проблема/конфликта тук и сега, средносрочна – да минимизира вероятността от възникване на нов конфликт по същата причина и в дългосрочен план - да се култивира култура на възрастни в екипния човек.

Всеки от нас има вътрешно дете на около три-четири години. Той спи през повечето време на работа, но понякога се събужда и поема контрола. Детето си има свои приоритети. За него е важно да настоява, че това е неговият пясъчник, майка му го обича повече, машината му е най-добрата (дизайнът е най-добрият, той програмира най-добре, ...). В ситуация на конфликт детето може да натиска играчки, да тропа с крака и да счупи шпатулата си, но не може да реши проблемите на възрастните (архитектура на решението, подходи за автоматизирано тестване, дати на пускане и т.н.), не мисли за ползите за отбора. Дете в конфликт може да бъде насърчено, утешено и изпратено в леглото, като го помолите да се обади на своя възрастен. Преди да започнете дискусия в конфликтна ситуация, уверете се, че говорите с възрастен, а не с дете, и че вие ​​​​сами сте в позицията на възрастен. Ако вашата честна цел в момента е да разрешите сериозен проблем, вие сте в позицията на възрастен. Ако целта ви е да тропате с крака и да си пукате лопатката, това е детска поза. Изпратете вътрешното си дете в леглото и се обадете на възрастен или пренасрочете дискусията. Човек взема емоционално решение и след това търси рационално оправдание за него. Решение, взето от дете въз основа на детските приоритети, няма да бъде оптимално.

В допълнение към поведението по време на конфликт, позицията на детето или възрастен се характеризира и с нивото на отговорност, което човек е готов да поеме върху себе си. В крайните си проявления детската позиция на програмиста, която съм срещал неведнъж, изглежда така: Написах кода, изпратих го за преглед - работата ми е готова. Рецензентите трябва да го прегледат и одобрят, QA трябва да го провери, ако има проблеми, те ще ме уведомят. Колкото и да е странно, дори доста зрели и опитни хора понякога се държат по този начин. Другият край на скалата е, че човек счита себе си за отговорен да гарантира, че кодът му работи, че е покрит от тестове, че е бил лично проверен от него, че е преминал успешно прегледа (ако е необходимо, няма проблем да пингвате рецензенти, да обсъждате проблеми чрез глас и т.н.) и е бил потиснат, QA ще предостави помощ, ако е необходимо, ще бъдат описани тестови сценарии и т.н. В нормални случаи програмистът или започва по-близо до възрастния край на скалата, или се придвижва там, докато натрупва опит (при условие, че в екипа се култивира правилната култура). В крайни случаи той продължава да работи, като обикновено заема детска позиция, тогава той и екипът периодично имат проблеми и конфликти.

Насърчаването на правилната, зряла култура в екип е важна задача за всеки мениджър. Отнема много време и ежедневни усилия, но резултатът си заслужава. Има два начина да повлияете на екипната култура – ​​водене чрез пример (който определено ще бъде последван; екипът винаги гледа към лидера) и обсъждане и награждаване на правилното поведение. Тук също няма нищо неясно или много формално, просто когато обсъждате проблеми, забележете, че нещо е можело да се направи тук, подчертайте, че сте забелязали кога е решено правилно, похвалите, бележка по време на прегледа на изданието и т.н.

Нека разгледаме няколко типични конфликтни ситуации, от прости до сложни:

Конфликти, които не са свързани с работни проблеми

Доста често на работното място има конфликти, които не са свързани с работни проблеми. Тяхната поява и лекота на разрешаване обикновено са пряко свързани с нивото на емоционалната интелигентност на участниците, степента им на зрялост и не са свързани със съвършенството или несъвършенството на работния процес.

Типични примери: някой не използва достатъчно често пералнята или душа, което не се харесва на други, на някой му е задушно, на други му духа, ако отворят прозореца, някой е твърде шумен, а трети се нуждаят от тишина, за да работят и скоро. По-добре е да не отлагате разрешаването на конфликти от този вид и да не ги оставяте да се развият. Те няма да се решат сами и ще ви отвличат от работата всеки ден и ще тровят атмосферата в екипа. За щастие решаването им обикновено не е голям проблем - просто поговорете спокойно (на четири очи, разбира се) с колега, който пренебрегва хигиената, осигурете удобни места за хора, които предпочитат тишина/прохлада, купете звукопоглъщащи слушалки или инсталирайте прегради и т.н.

Друг пример, с който се сблъсквах няколко пъти по време на работата си, е психологическата несъвместимост на членовете на екипа. По някаква причина хората просто не могат да работят заедно, всяко взаимодействие завършва със скандал. Понякога това се дължи на факта, че хората имат полярни възгледи по някакъв наболял въпрос (обикновено политически) и не знаят как да ги оставят извън работата. Да ги убедите да се толерират или да променят поведението си е доста безполезна задача. Единственото изключение, с което съм се сблъсквал, са млади колеги с отворени възприятия, поведението им все пак може постепенно да се промени чрез периодични разговори. Обикновено проблемът се решава успешно, като се разделят на различни екипи или поне се дава възможност много рядко да се припокриват на работа.

Във всички горепосочени ситуации си струва да говорите лично с всички участници, да обсъдите ситуацията, да попитате дали изобщо виждат проблем в този случай, да попитате какви според тях са решенията и да осигурите тяхното участие в това решение.

От гледна точка на оптимизиране на работния процес (средносрочната перспектива, която споменах) тук не може да се направи много, единственият смисъл на оптимизацията е да се вземе предвид факторът съвместимост при формирането на екип, а не да се поставят хора заедно предварително кой ще конфликтува.

От гледна точка на екипната култура подобни ситуации възникват много по-рядко в екипи със зряла култура, където хората уважават екипа и колегите и знаят как да решават проблемите независимо. Освен това такива конфликти се разрешават много по-лесно (често автоматично) в екипи, където има високо ниво на доверие, хората са работили заедно дълго време и/или общуват често извън работата.

Конфликти, свързани с работни проблеми:

Такива конфликти обикновено са причинени от двете причини едновременно, както емоционални (фактът, че един от участниците не е в позицията на възрастен), така и несъвършенството на самия работен процес. Може би най-често срещаният тип конфликти, с които съм се сблъсквал, са конфликти по време на прегледи на код или дискусии за архитектура между разработчици.

Тук бих подчертал два типични случая:

1) В първия случай разработчикът не може да получи преглед на кода от колега. Корекцията се изпраща за преглед и нищо не се случва. На пръв поглед няма очевиден конфликт между двете страни, но ако се замислите, това е доста конфликт. Проблемът с работата не е решен, една от страните (чакаща преглед) изпитва очевиден дискомфорт. Екстремен подтип на този случай е разработка в общност или в различни екипи, докато рецензентът може да не се интересува от този конкретен код, поради зареждане или други обстоятелства, може изобщо да не обърне внимание на заявката за преглед и външният арбитър (мениджър, общ за двете страни) ) може изобщо да не съществува.

Подходът за решение, който помага в такава ситуация, е свързан именно с дългосрочната перспектива, културата на възрастен. Първо, интелигентната дейност работи. Не трябва да очаквате, че кодът, висящ на рецензията, ще привлече вниманието на самия рецензент. Трябва да помогнем на рецензентите да го забележат. Pingani няколко души, задайте въпрос за syncape, участвайте в дискусии. Очевидно е по-вероятно настойчивостта да навреди, отколкото да помогне, трябва да използвате здрав разум. Второ, предварителната подготовка работи добре. Ако екипът разбира какво се случва и защо, защо изобщо е необходим този код, дизайнът е обсъден и съгласуван предварително с всички, хората са по-склонни да обърнат внимание на такъв код и да го приемат за работа. Трето, авторитетът работи. Ако искате да бъдете прегледани, правете много прегледи сами. Правете висококачествени прегледи с реални проверки, реални тестове и полезни коментари. Ако псевдонимът ви е добре познат в екипа, има по-голям шанс вашият код да бъде забелязан.

От гледна точка на работния процес, възможните подобрения тук са правилно приоритизиране, насочено към подпомагане на разработчика да постигне своите цели и целите на екипа (преглед на другите, писане на писма до общността, придружаване на кода с описание на архитектурата, документация, тестове, участие в дискусии с общност и т.н.), предотвратяване на висенето на пачовете в опашката твърде дълго и т.н.

2) Вторият често срещан случай на конфликти по време на прегледи на код или дизайн са различни възгледи по технически въпроси, стил на кодиране и избор на инструменти. От голямо значение в този случай е нивото на доверие между участниците, принадлежащи към един и същ екип и опит в съвместната работа. Задънена улица възниква, когато един от участниците заема детска позиция и не се опитва да чуе какво иска да му предаде събеседникът. Често и подходът, предложен от другата страна, и първоначално предложеният подход могат да работят успешно и по принцип няма значение кой да изберете.

Един ден програмист от моя екип (да го наречем Паша) подготви корекция с промени в системата за внедряване на пакети, която беше разработена и поддържана от колеги от съседен отдел. Един от тях (Игор) имаше собствено силно мнение относно това как точно трябва да се конфигурират услугите на Linux при внедряването на пакети. Това мнение се различаваше от подхода, предложен в корекцията, и те не можаха да се съгласят. Както обикновено, сроковете изтичаха и трябваше да се стигне до някакво решение, беше необходимо един от тях да заеме възрастен пост. Паша призна, че и двата подхода имат право на живот, но искаше неговият вариант да премине, защото Нито единият, нито вторият вариант нямаха очевидни технически предимства.

Нашата дискусия изглеждаше така (много схематично, разбира се, разговорът продължи половин час):

- Паша, имаме замразяване на функции след няколко дни. Важно е да съберем всичко и да започнем тестовете възможно най-скоро. Как да минем през Игор?
— Той иска да настрои услугите по различен начин, той остави коментари там за мен...
- И какво има, големи промени, много шум?
- Не, има работа за няколко часа, но в крайна сметка няма разлика, така или иначе ще работи, защо е необходимо? Направих нещо, което работи, нека го приемем.
- Слушай, откога обсъждаш всичко това?
- Да, вече седмица и половина отбелязваме време.
- Хм... можем ли да решим проблем за няколко часа, който вече е отнел седмица и половина, и да не го правим?
- Е, да, но не искам Игор да мисли, че съм се поддал...
- Слушай, какво е по-важно за теб, да издадеш освобождаване, заедно с решението си вътре, или да убиеш Игор? Можем да го блокираме, тогава обаче има добър шанс да преминем през освобождаването.
- Е... би било готино, разбира се, да избърша носа на Игор, но добре, освобождаването е по-важно, съгласен съм.
- Наистина ли е толкова важно за вас какво мисли Игор? Честно казано, на него изобщо не му пука, просто иска единен подход на различни места от нещото, за което отговаря.
- Е, добре, позволете ми да направя както той поиска в коментарите и да започнем да тестваме.
- Благодаря ти, Паша! Бях сигурен, че от вас двамата ще бъдете по-зрели, въпреки че Игорек е по-голям от вас :)

Въпросът беше решен, освобождаването беше пуснато навреме, Паша не почувства много недоволство, защото той сам предложи решение и го приложи. Игор като цяло беше доволен, защото... Неговото мнение беше взето предвид и те направиха това, което предложи.

Друг тип по същество същия конфликт е изборът между технически решения/библиотеки/подходи в проект, особено в разпределен екип. В един от проектите, който беше позициониран като използващ C/C++, се оказа, че техническото ръководство на проекта е категорично против използването на STL (Standard Template Library). Това е стандартна езикова библиотека, която опростява разработката и нашият екип е много свикнал с нея. Оказа се, че проектът е много по-близо до C, отколкото до C++, което не вдъхнови много екипа, т.к. ръководството даде всичко от себе си и набра наистина готини плюс играчи. В същото време американската част от екипа, както инженери, така и мениджъри, са работили в компанията дълго време, са свикнали със съществуващото състояние на нещата и са доволни от всичко. Руската част от екипа се събра съвсем наскоро, в рамките на няколко седмици (включително и аз). Руската част от екипа категорично не искаше да се откаже от обичайния подход към развитието.

Започнаха безкрайни писмени дискусии между двата континента, писма на три или четири екрана летяха напред-назад, в групови писма и лични, от програмисти към програмисти и мениджъри. Както обикновено се случва, писма с такава дължина не бяха прочетени от никого, освен от авторите и техните пламенни поддръжници. Чатовете скърцаха от напрежение, преминавайки многоекранни мисли в различни посоки относно техническите предимства на STL, колко добре е тестван, колко безопасен е и като цяло колко прекрасен е животът с него и колко ужасен е без него .

Всичко това продължи доста дълго време, докато накрая разбрах, че обсъждаме техническите аспекти на проблема, но проблемът всъщност не беше технически. Проблемът не е в предимствата или недостатъците на STL или трудността да се работи без него. Проблемът е по-скоро организационен. Просто трябваше да разберем как работи компанията, за която работихме. Никой от нас не е имал опит да работи в такава компания преди. Работата беше, че след като кодът беше разработен и пуснат в производство, поддръжката беше обслужвана от напълно различни хора от други екипи, от други страни. Този огромен инженерен екип от няколко десетки хиляди инженери (общо) можеше да си позволи само един напълно основен минимум от технически средства, така да се каже, минимум minimorum. Всичко, което физически надхвърля инженерния стандарт, установен в компанията, не може да бъде поддържано в бъдеще. Нивото на един отбор се определя от нивото на най-слабите му членове. След като разбрахме истинска мотивация действия на американската част от екипа, този въпрос беше свален от дневния ред и заедно успешно разработихме и пуснахме продукта, използвайки стандартите, приети от компанията. Писмата и чатовете в този случай не работеха добре; бяха необходими няколко пътувания и много лична комуникация, за да се стигне до общ знаменател.

От гледна точка на работния процес, в конкретния случай би било полезно да има описание на използваните инструменти, изисквания към тях, ограничения за добавяне на нови и обосновка за такива ограничения. Такива документи приблизително съответстват на описаните в параграфи Стратегия за повторно използване и среда за разработка на „Наръчник на мениджъра за разработка на софтуер“, разработен в НАСА. Въпреки възрастта си, той перфектно описва всички основни дейности и етапи на планиране на разработката на софтуер от този вид. Наличието на документи като този прави много лесно обсъждането какви компоненти и подходи могат да се използват в даден продукт и защо.

От културна гледна точка, очевидно, с по-зряла позиция, в която страните се опитват да чуят и разберат истинската мотивация на действията на своите колеги и да действат въз основа на приоритетите на проекта и екипа, а не на личното его , конфликтът би се разрешил по-лесно и по-бързо.

При друг конфликт относно избора на техническо решение също ми отне значително време, за да разбера мотивацията на една от страните (това беше много необичаен случай), но след като мотивацията беше ясна, решението беше очевидно.

Ситуацията е следната: в екип от около 20 души се появява нов разработчик, нека го наречем Стас. По това време нашият стандартен инструмент за комуникация като екип беше Skype. Както се оказа по-късно, Стас беше голям фен на отворените стандарти и софтуера с отворен код и използваше само инструменти и операционни системи, чиито източници бяха публично достъпни и които използваха публично описани протоколи. Skype не е един от тези инструменти. Прекарахме много време в обсъждане на предимствата и недостатъците на този подход, опитите за стартиране на аналози на Skype на различни операционни системи, опитите на Стас да убеди екипа да премине към други стандарти, да му пишем лично по пощата, да му се обаждаме лично на телефон, купете му втори компютър специално за скайп и т.н. Накрая разбрах, че този проблем по същество не е технически или организационен, той е по-скоро идеологически, дори, може да се каже, религиозен (за Стас). Дори и в крайна сметка да свържем Stas и Skype (което отне няколко месеца), проблемът ще възникне отново на всеки следващ инструмент. Нямах реални средства на мое разположение да променя мирогледа на Стас и нямаше причина да се опитвам да променя мирогледа на екип, който работи перфектно в тази среда. Човекът и компанията бяха просто ортогонални в мирогледа си. В такива ситуации добро решение е организационното. Прехвърлихме Стас в друг отбор, където той беше по-органичен.

Причината за този конфликт, според мен, е несъответствието между личната култура на конкретен човек (който има твърдо мнение, което не му позволява да прави компромиси) и културата на компанията. В този случай, разбира се, грешката е на мениджъра. Първоначално беше погрешно да го вземем в проект от този вид. В крайна сметка Стас се премести в проект за разработка на софтуер с отворен код и се представи отлично там.

Добър пример за конфликт, породен както от детското отношение на разработчика, така и от недостатъците на работния процес, е ситуация, в която при липса на дефиниция за готово, разработчикът и QA екипът имат различни очаквания по отношение на готовността на функцията е прехвърлена към QA. Разработчикът вярваше, че е достатъчно да напише кода и да прехвърли функцията през оградата на QA - те ще го оправят там. Доста зрял и опитен програмист, между другото, но това беше вътрешният му праг за качество. QA не се съгласи с това и поиска да им покаже и опише какво е проверил самият той, и поиска тестов скрипт за тях. Те са имали проблеми с функционалността от този разработчик в миналото и не искаха да си губят времето отново. Между другото, те бяха прави - функцията наистина не работи, той не провери кода, преди да го изпрати на QA.

За да разреша ситуацията, помолих го да ми покаже, че всичко наистина работи (не работи и той трябваше да го поправи), разговаряхме с екипа и с дефиницията на QA за готово (те не успяха в писане, защото не искахме да правим процеса прекалено бюрократичен ), е, скоро се разделихме с този специалист (за общо облекчение).

От гледна точка на работния процес, възможните подобрения в този случай са наличието на дефиниция за done, изисквания за поддръжка на всяка характеристика на модула и интеграционни тестове, както и описание на тестването, извършено от разработчика. В един от проектите измервахме нивото на покритие на кода чрез тестове по време на CI и ако нивото на покритие падна след добавяне на корекция, тестовете бяха маркирани като неуспешни, т.е. всеки нов код може да бъде добавен само ако има нови тестове за него.

Друг типичен пример за конфликт, тясно свързан с организацията на работния процес. Имаме продукт, екип за разработка на продукти, екип за поддръжка и клиент. Клиентът има проблеми с продукта и се свързва с поддръжката. Поддръжката анализира проблема и разбира, че проблемът е в продукта и прехвърля проблема на продуктовия екип. Екипът на продукта е в натоварено време, наближава издание, така че билет с проблем от клиент, изгубен сред другите билети на разработчика, на когото е назначен, виси няколко седмици без внимание. Поддръжката смята, че разработчикът работи по проблема на клиента. Клиентът чака и се надява, че по проблема му се работи. Реално все още нищо не се случва. След няколко седмици клиентът най-накрая решава да се поинтересува от напредъка и пита поддръжката как вървят нещата. Поддръжката изисква развитие. Разработчикът потръпва, преглежда списъка с билети и намира там билет от клиента. Четейки билет от клиент, той разбира, че няма достатъчно информация за решаване на проблема и се нуждае от повече регистрационни файлове и сметища. Поддръжката изисква допълнителна информация от клиента. И тогава клиентът разбира, че през цялото това време никой не е работил по неговия проблем. И гръм ще удари...

В тази ситуация решението на самия конфликт е съвсем очевидно и линейно (коригиране на продукта, актуализиране на документация и тестове, успокояване на клиента, пускане на актуална корекция и т.н.). Важно е да се анализира работният процес и да се разбере кой е отговорен за организирането на взаимодействието между двата екипа и защо изобщо е възможна тази ситуация. Ясно е какво трябва да се оправи в процеса - някой трябва да следи цялостната картина без напомняния от клиенти, проактивно. Билетите от клиента трябва да се открояват сред другите билети от разработчиците. Поддръжката трябва да види дали екипът за разработка в момента работи върху своите билети и ако не, кога може да започне да работи и кога могат да се очакват резултати. Поддръжката и разработката трябва периодично да комуникират и обсъждат състоянието на билетите, събирането на информация, необходима за отстраняване на грешки, трябва да бъде автоматизирано, доколкото е възможно, и т.н.

Точно както във война врагът се опитва да удари кръстовището между две единици, така и в работата най-деликатната и уязвима точка обикновено е взаимодействието между екипите. Ако мениджърите за поддръжка и развитие са достатъчно възрастни, те ще могат сами да коригират процеса, ако не, процесът ще продължи да генерира конфликти и проблеми, докато не се намеси мениджър, който може да коригира ситуацията.

Друг типичен пример, който съм виждал многократно в различни компании, е ситуация, в която даден продукт е написан от един екип, автоматичните интеграционни тестове за него са написани от втори екип, а инфраструктурата, върху която се работи, е придружена от трети екип. Проблеми при провеждане на тестове възникват непрекъснато, като причината за проблемите в тях може да бъде както продуктът, така и тестовете и инфраструктурата. Обикновено е проблематично да се споразумеят кой трябва да извърши първоначалния анализ на проблеми, файлови грешки, парсиране на логове на продукта, тестове и инфраструктура и т.н. Конфликтите тук са много чести и в същото време еднообразни. В случай на висок емоционален интензитет, участниците често изпадат в детска позиция и в поредицата започват дискусии: „защо трябва да се занимавам с това“, „те се разпадат по-често“ и т.н.

От гледна точка на работния процес, конкретните стъпки за разрешаване на проблем зависят от състава на екипите, вида на тестовете и продукта и т.н. В един от проектите въведохме периодични дежурства, при които екипи наблюдаваха тестовете един по един, седмица по седмица. В другия първоначалният анализ винаги се извършваше от разработчиците на теста, но анализът беше много елементарен и продуктът беше доста стабилен, така че работеше добре. Ключът е да се гарантира, че процесът е прозрачен, че очакванията са ясни за всички страни и че ситуацията се чувства справедлива за всички.

Дали конфликтът изобщо е проблем в една организация? Лош знак ли е, че често (или само периодично) възникват конфликти във вашия екип? Като цяло не, защото ако има растеж, развитие, има някаква динамика, тогава възникват въпроси, които никога не са били решавани, а при решаването им могат да възникнат конфликти. Това е индикатор, че някои области се нуждаят от внимание, че има области за подобрение. Лошо е, ако конфликтите възникват много често, трудно се разрешават или отнемат много време. Това най-вероятно е знак за недостатъчно стройни работни процеси и недостатъчна зрялост на екипа.

Източник: www.habr.com