Управување со конфликти во тим - балансирачки чин или витална неопходност?

Епиграф:
Некогаш во шумата се сретнаа Еже и Малата мечка.
- Здраво, Еже!
- Здраво Мече!
Така, збор по збор, шега по шега, Ежето доби удар во лице од Малата мечка...

Подолу е дискусија од нашиот тим лидер, како и директорот за развој на производи на РАС, Игор Марнат, за спецификите на работните конфликти и можните методи за нивно управување.

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

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

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



Прво, постојат две или повеќе страни. Овие страни можат да заземаат различни места во организацијата, да бидат во однос на еднаквост (колеги во тим) или на различни нивоа на хиерархијата (шеф - подреден), да бидат индивидуални (вработени) или групни (во случаи на конфликт помеѓу вработен и тим или два тима), и така натаму. Веројатноста за конфликт и леснотијата на негово решавање се под големо влијание од нивото на доверба меѓу учесниците. Колку подобро се познаваат страните, толку е повисоко нивото на доверба, толку е поголема шансата да се договорат. На пример, членовите на дистрибуиран тим кои никогаш не комуницирале лице-в-лице имаат поголема веројатност да доживеат конфликт за едноставно работно прашање отколку луѓето кои имале барем неколку интеракции лице-в-лице. Затоа, кога работите во дистрибуирани тимови, многу е важно да се осигурате дека сите членови на тимот периодично се среќаваат лично меѓу себе.

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

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

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

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

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

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

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

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

Конфликтите обично се предизвикани од една од двете причини. Првиот е поврзан со тоа дали лицето во моментот на конфликтот е во положба на возрасен или во позиција на дете (повеќе за ова подолу). Ова се должи на неговата емоционална зрелост, способноста да управува со своите емоции (што, патем, не е секогаш поврзано со неговата возраст). Втората честа причина е несовршеноста на работниот процес, што создава ситуации на сиви зони во кои одговорноста е распространета меѓу учесниците, очекувањата на страните не се транспарентни една кон друга, а улогите во процесот се заматени.

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

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

Покрај однесувањето во моментот на конфликт, положбата на детето или возрасното лице се карактеризира и со нивото на одговорност што лицето е подготвено да го преземе врз себе. Во своите екстремни манифестации, детската позиција на програмер, која сум ја сретнал повеќе од еднаш, изгледа вака: го напишав кодот, го испратив на преглед - мојата работа е завршена. Рецензентите треба да го разгледаат и да го одобрат, QA треба да го проверат, ако има проблеми, ќе ме известат. Доволно чудно, дури и прилично зрели и искусни луѓе понекогаш се однесуваат на овој начин. Другиот крај на скалата е дека едно лице се смета себеси за одговорно да се осигура дека неговиот код работи, е покриен со тестови, дека е лично проверен од него, успешно го поминал прегледот (ако е потребно, нема проблем со пинг на рецензентите, дискусија за прашања со глас, итн.) и е потисната, ОК ќе обезбеди помош доколку е потребно, ќе бидат опишани сценарија за тестирање итн. Во нормални случаи, програмерот или започнува поблиску до крајот на скалата за возрасни, или се движи таму додека стекнува искуство (под услов да се одгледува вистинската култура во тимот). Во екстремни случаи, тој продолжува да работи, обично зазема детска позиција, тогаш тој и тимот периодично имаат проблеми и конфликти.

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

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

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

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

Типични примери: некој не користи доволно често машина за перење или туш, што на другите не им се допаѓа, некој е затнат, додека други добиваат ветер ако го отворат прозорецот, некој е премногу бучен, а на другите им треба тишина за да работат, и така натаму. Подобро е да не го одложувате решавањето на конфликтите од овој вид и да не ги оставите да го следат својот пат. Нема да се решат сами и секојдневно ќе ви го одвлекуваат вниманието од работата и ќе ја трујат атмосферата во тимот. За среќа, нивното решавање обично не е голем проблем - само разговарајте смирено (еден-на-еден, се разбира) со колега кој ја запоставува хигиената, обезбедете удобно седење за луѓето кои претпочитаат тишина/ладност, купете слушалки што апсорбираат звук или инсталирајте партиции , итн.

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

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

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

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

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

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

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

1) Во првиот случај, развивачот не може да добие преглед на код од колега. Закрпата е испратена на преглед, и ништо не се случува. На прв поглед, нема очигледен конфликт меѓу двете страни, но ако размислите добро, ова е прилично конфликт. Работното прашање не е решено, една од страните (чека за преглед) доживува очигледна непријатност. Екстремниот подтип на овој случај е развојот во заедница или во различни тимови, додека рецензентот можеби не е заинтересиран за овој конкретен код, поради вчитување или други околности, може воопшто да не обрнува внимание на барањето за преглед, а надворешниот арбитер (менаџер заеднички за двете страни) ) можеби воопшто не постои.

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

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

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

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

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

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

Прашањето беше решено, ослободувањето беше пуштено навреме, Паша не почувствува големо незадоволство, бидејќи тој самиот предложи решение и го спроведе. Игор генерално беше задоволен, бидејќи ... Неговото мислење беше земено предвид и направија како што тој предложи.

Друг тип на суштински ист конфликт е изборот помеѓу технички решенија/библиотеки/пристапи во проект, особено во дистрибуиран тим. Во еден од проектите, кој беше позициониран како користење на C/C++, се покажа дека техничкото управување на проектот е категорично против користењето на STL (Standard Template Library). Ова е библиотека со стандардни јазици што го поедноставува развојот, а нашиот тим е многу навикнат на тоа. Се покажа дека проектот е многу поблиску до C отколку до C++, што не го инспирираше многу тимот, бидејќи управата се потруди и регрутираше навистина кул плус играчи. Во исто време, американскиот дел од тимот, инженери и менаџери, работеа во компанијата долго време, беа навикнати на постојната состојба и беа задоволни со сè. Рускиот дел од тимот беше собран неодамна, во рок од неколку недели (вклучувајќи ме и мене). Рускиот дел од тимот категорично не сакаше да го напушти вообичаениот пристап кон развојот.

Почнаа бескрајни писмени дискусии меѓу двата континента, писмата на три или четири екрани летаа напред-назад, во групни и лични пораки, од програмери до програмери и менаџери. Како што обично се случува, писмата со оваа должина не ги читаше никој освен авторите и нивните жестоки поддржувачи. Муабетите крцкаа од напнатост, пренесувајќи мисли на повеќе екрани во различни насоки во врска со техничките предности на STL, колку е добро тестиран, колку е безбеден и воопшто, колку е прекрасен животот со него и колку е страшен без него. .

Сето ова траеше доста долго, додека конечно не сфатив дека разговараме за техничките аспекти на прашањето, но проблемот во реалноста не беше технички. Проблемот не е во предностите или недостатоците на STL или тешкотијата да се работи без него. Проблемот е прилично организациски. Требаше само да разбереме како функционира компанијата за која работевме. Никој од нас претходно немал искуство со работа во таква компанија. Работата беше во тоа што откако кодот беше развиен и пуштен во производство, со поддршка се справуваа сосема различни луѓе од други тимови, од други земји. Овој огромен инженерски тим од неколку десетици илјади инженери (вкупно) можеше да си дозволи само сосема основен минимум технички средства, така да се каже, минимален минимум. Сè што го надминува инженерскиот стандард воспоставен во компанијата физички не може да биде поддржано во иднина. Нивото на тимот се одредува според нивото на неговите најслаби членови. Откако разбравме вистинска мотивација дејствија на американскиот дел од тимот, ова прашање беше отстрането од дневниот ред и заедно успешно го развивме и објавивме производот користејќи ги стандардите усвоени од компанијата. Писмата и разговорите во овој случај не функционираа добро, потребни беа неколку патувања и многу лична комуникација за да се дојде до заеднички именител.

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

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

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

Ситуацијата е следна: нов развивач се појавува во тим од околу 20 луѓе, ајде да го наречеме Стас. Во тоа време, нашата стандардна алатка за комуникација како тим беше Skype. Како што се испостави подоцна, Стас бил голем обожавател на отворени стандарди и софтвер со отворен код и користел само алатки и оперативни системи чии извори биле јавно достапни и кои користеле јавно опишани протоколи. Skype не е една од овие алатки. Потрошивме многу време дискутирајќи за предностите и недостатоците на овој пристап, обидите за лансирање аналози на Skype на различни оперативни системи, обидите на Стас да го убеди тимот да се префрли на други стандарди, да му пишете лично по пошта, да го повикате лично на телефон, купи му втор компјутер специјално за скајп итн. Конечно, сфатив дека овој проблем, во суштина, не е технички или организациски, тој е прилично идеолошки, дури, може да се каже, религиозен (за Стас). Дури и ако на крајот ги поврзевме Stas и Skype (за што беа потребни неколку месеци), проблемот повторно ќе се појави на кој било следен инструмент. Немав вистински средства на располагање да го променам светогледот на Стас и немаше причина да се обидам да го сменам светогледот на тимот кој работеше совршено во оваа средина. Личноста и компанијата беа едноставно ортогонални во нивниот светоглед. Во такви ситуации, добро решение е организациско. Стас го префрливме во друг тим, каде што беше поорганичен.

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

Добар пример за конфликт предизвикан и од детскиот однос на инвеститорот и од недостатоците на работниот процес е ситуација во која, во отсуство на дефиниција за завршено, развивачот и тимот за ОК имаат различни очекувања во однос на подготвеноста на функцијата пренесена во QA. Програмерот веруваше дека е доволно да се напише кодот и да се фрли функцијата преку оградата до QA - тие ќе ја средат таму. Патем, прилично зрел и искусен програмер, но тоа беше неговиот внатрешен праг за квалитет. QA не се согласи со ова и побара да им покаже и опише што тој самиот проверил и побара скрипта за тестирање за нив. Тие имаа проблеми со функционалноста од овој развивач во минатото и не сакаа повторно да губат време. Патем, тие беа во право - функцијата навистина не функционираше, тој не го провери кодот пред да ја испрати до QA.

За да ја разрешам ситуацијата, го замолив да ми покаже дека сè навистина функционира (не функционираше, а тој мораше да го поправи), разговаравме со тимот и со дефиницијата за QA за завршено (не успеаја пишување, бидејќи не сакавме да го направиме процесот премногу бирократски ), па, наскоро се разделивме со овој специјалист (на општо олеснување).

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

Друг типичен пример на конфликт тесно поврзан со организацијата на работниот процес. Имаме производ, тим за развој на производи, тим за поддршка и клиент. Клиентот има проблеми со производот и контактира со поддршката. Поддршката го анализира проблемот и разбира дека проблемот е во производот и го пренесува проблемот на тимот на производот. Тимот на производи е во зафатено време, се ближи објавување, па тикет со проблем од клиент, изгубен меѓу другите билети на програмерот на кого му е доделен, виси неколку недели без внимание. Поддршката смета дека развивачот работи на проблемот на клиентот. Клиентот чека и се надева дека се работи на нивниот проблем. Во реалноста сè уште ништо не се случува. По неколку недели, клиентот конечно одлучува да се заинтересира за напредокот и бара поддршка како одат работите. Поддршката бара развој. Инвеститорот се згрозува, ја разгледува листата на билети и наоѓа билет од клиентот таму. Читајќи билет од клиент, тој разбира дека нема доволно информации за да се реши проблемот и му требаат повеќе трупци и депонии. Поддршката бара дополнителни информации од клиентот. И тогаш клиентот сфаќа дека никој не работел на неговиот проблем цело ова време. И гром ќе удри...

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

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

Друг типичен пример што сум го видел повеќепати во различни компании е ситуација во која производ е напишан од еден тим, автоматски тестови за интеграција за него ги пишува втор тим, а инфраструктурата на која се работи е придружена со трет. тим. Проблемите при извршувањето на тестовите се појавуваат постојано, а причината за проблемите во нив може да биде и производот и тестовите и инфраструктурата. Обично е проблематично да се договори кој треба да ја изврши првичната анализа на проблемите, грешките во датотеките, анализирањето на дневниците на производот, тестовите и инфраструктурата итн. Конфликтите овде се многу чести, а во исто време и униформни. Во случај на висок емоционален интензитет, учесниците често запаѓаат во детска позиција и започнуваат дискусии во серијата: „зошто да се чепкам со ова“, „почесто се распаѓаат“ итн.

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

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

Извор: www.habr.com