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

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

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

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

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

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



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

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

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

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

Необходимо ли вмешиваться в конфликтни ситуации, или лучше оставить их решение на самотек, ожидая, когда проблема разрешится сама? Да, необходимо. Не всегда в ваших силах или компетенции полностью решить конфликт, но в любой ситуации, независимо от масштаба конфликта, вы можете занять взрослую позицию, тем самым вовлекая в это ещё несколько человек вокруг себя, смягчить негативные последствия конфликта и способствовать его разрешению.

Перед тем как рассмотреть несколько примеров конфликтных ситуаций, обратим внимание на несколько важных моментов, общих для всех конфликтов.

При решении конфликта важно оставаться вне него, а не находиться внутри (это также известно как 'занять метапозицию'), то есть не принимать одну из сторон. В противном случае, вместо того чтобы быть внешним арбитром, помогающим в решении, вы только укрепите позицию одной из сторон в ущерб другой. При принятии решения важно, чтобы оно было морально поддержано всеми сторонами, чтобы, как говорится, 'было куплено'. Чтобы, даже если стороны не в восторге от принятого решения, они хотя бы искренне согласны с его исполнением. Как говорят, быть в состоянии disagree and commit. В противном случае конфликт просто изменит свою форму, тлеющий огонь останется под торфяником и в какой-то момент неизбежно вспыхнет снова.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

От гледна точка на работния процес, в този конкретен случай, наличие на описание на използваните средства, изисквания към тях, ограничения за добавяне на нови и обосновка на такива ограничения би помогнало. Подобни документи приблизително съответстват на описаното в точките 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