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

Епиграф:
Срещнали се веднъж в гората Ѝжко и Мечето.
— Здравей, Ѝжко!
— Здравей, Мечето!
Така, дума по дума, шега по шега, и Ѝжко получи от Мечето по носа …

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Бих отделил два типични случая:

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

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

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

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

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

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

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

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

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

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

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

От гледна точка на работния процес, в този конкретен случай, наистина щеше да помогне наличието на описание на използваните средства, изискванията към тях, ограниченията за добавяне на нови и обосновани ограничения. Такива документи приблизително съответстват на описаните в пунктовете Reuse Strategy и Development Environment от ръководството “Manager’s Handbook for Software Development”, разработено в NASA. Въпреки възрастта си, то отлично описва всички основни дейности и етапи на планиране на разработка на софтуер от този вид. Наличието на подобни документи значително улеснява процеса на обсъждане на това, кои компоненти и подходи могат да бъдат използвани в продукта и защо.

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

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

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

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

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

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

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

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

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

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

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

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

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

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