Эпіграф:
Сустрэліся неяк у лесе Вожык і Медзведзяня.
- Добры дзень, Вожык!
- Добры дзень, Медзведзяня!
Так, слова за слова, жарт за жартам, і атрымаў Вожык ад Медзведзяняці па мордзе…
Пад катом развагі нашага тымліда, а таксама дырэктара па развіцці прадукта RAS – Ігара Марната аб спецыфіцы працоўных канфліктаў і магчымых метадах кіравання імі.
Большасць канфліктаў, з якімі мы сутыкаемся на працы, развіваюцца па сцэнарыі, падобным да апісанага вышэй у эпіграфе. Ёсць некалькі ўдзельнікаў, першапачаткова настроеных адзін да аднаго добразычліва, яны спрабуюць вырашыць нейкае пытанне, але ў выніку праблема так і застаецца нявырашанай, ды і адносіны паміж удзельнікамі абмеркавання чамусьці аказваюцца сапсаваны.
Жыццё - шматстайная, у апісаным вышэй сцэнары здараюцца варыяцыі. Часам адносіны паміж удзельнікамі бываюць не вельмі добрымі першапачаткова, часам няма нават пытання, якое патрабуе непасрэднага рашэння (як, напрыклад, у эпіграфе), часам пасля абмеркавання адносіны застаюцца такімі ж, што і да яго пачатку, але пытанне ў выніку так і не вырашана.
Што ж ёсць агульнага ва ўсіх сітуацыях, якія можна вызначыць як сітуацыя працоўнага канфлікту?
Па-першае, гэта наяўнасць двух ці больш бакоў. Гэтыя бакі могуць займаць рознае месца ў арганізацыі, знаходзіцца ў адносінах роўнасці (калегі ў камандзе), або на розных узроўнях іерархіі (начальнік - падначалены), быць індывідуальнымі (супрацоўнік) або групавымі (у выпадках канфлікту паміж супрацоўнікам і камандай або двума камандамі), і гэтак далей. На верагоднасць канфлікту і прастату яго вырашэння вельмі ўплывае ўзровень даверу паміж удзельнікамі. Чым лепш бакі ведаюць адзін аднаго, чым вышэй узровень даверу, тым вышэй шанец, што яны дамовяцца. Да прыкладу, супрацоўнікі размеркаванай каманды, якія ніколі не размаўлялі асабіста, з большай верагоднасцю ўвойдуць у сітуацыю канфлікту пры вырашэнні простага працоўнага пытання, чым людзі, якія хаця б некалькі разоў размаўлялі асабіста. Таму, працуючы ў размеркаваных камандах, вельмі важна забяспечыць перыядычныя асабістыя сустрэчы ўсіх чальцоў каманды сябар з сябрам.
Па-другое, у сітуацыі канфлікту на працы бакі знаходзяцца ў сітуацыі вырашэння нейкага пытання, важнага для нейкага з бакоў, для іх абодвух або для арганізацыі ў цэлым. Пры гэтым, у сілу спецыфікі сітуацыі, бакі звычайна маюць дастаткова часу і разнастайных спосабаў яго вырашэння (фармальных, нефармальных, сустрэчы, лісты, рашэнні кіраўніцтва, наяўнасці мэт і планаў каманды, факт наяўнасці іерархіі, і г.д.). У гэтым адрозненне ад сітуацыі рашэння працоўнага (ці не працоўнага) пытання ў арганізацыі ад, да прыкладу, рашэнні важнага пытання: "Э, дзяцюк, ты з якога раёна?!" на вуліцы, ці канфлікту з эпіграфа. У выпадку рашэння працоўнага пытання маюць значэнне якасць працоўнага працэсу і культура рашэння пытанняў у камандзе.
Па-трэцяе, вызначальным фактарам канфлікту (з пункту гледжання нашага абмеркавання) з'яўляецца той факт, што бакі працэсу не могуць самастойна прыйсці да вырашэння пытання, якое задавальняе ўсе бакі. Сітуацыя патрабуе ўмяшання трэцяга боку, знешняга арбітра. Гэты пункт можа здацца спрэчным, але, па сутнасці, калі канфліктная сітуацыя паспяхова вырашылася без умяшання знешняга арбітра, пытанне вырашана паспяхова і адносіны бакоў не пагоршыліся, гэта тая сітуацыя, да якой трэба імкнуцца. Мы пра такі канфлікт нават, хутчэй за ўсё, і не даведаемся, ці даведаемся выпадкова пасля яго вырашэння. Чым больш пытанняў каманда можа вырашыць самастойна, тым больш эфэктыўна яна будзе працаваць.
Яшчэ адна характэрная рыса канфлікту, якой варта закрануць - ступень эмацыйнага напалу пры вырашэнні. Канфлікт не абавязкова звязаны з высокім эмацыйным градусам. Удзельнікам не абавязкова крычаць і махаць рукамі, каб сітуацыя была, па сутнасці, канфліктнай. Пытанне не вырашаецца, пэўная эмацыйная напруга пры гэтым прысутнічае (магчыма, яно не выяўлена па-за відавочна), значыць, перад намі сітуацыя канфлікту.
Ці трэба ўвогуле ўмешвацца ў канфліктныя сітуацыі, ці лепш пусціць іх рашэнне на самацёк і чакаць, калі праблема рассмокчацца сама? Трэба. Не заўсёды ў вашай уладзе ці кампетэнцыі вырашыць канфлікт цалкам, але ў любой сітуацыі, у канфлікце любога маштабу, вы можаце заняць дарослую пазіцыю, тым самым вывеўшы на яе яшчэ некалькі чалавек вакол сябе, змякчыць негатыўныя наступствы канфлікту і паспрыяць яго вырашэнню.
Перад тым як разгледзець некалькі прыкладаў канфліктных сітуацый, спынімся на некалькіх важных момантах, агульных для ўсіх канфліктаў.
Пры вырашэнні канфлікту важна быць над сутычкай, а не ўнутры яе (гэта яшчэ называюць "заняць метапазіцыю"), гэта значыць, не апынуцца ў працэсе рашэння ў складзе аднаго з бакоў. У адваротным выпадку з вонкавага арбітра, які дапамагае рашэнню, вы толькі ўзмоцніце пазіцыю адной з бакоў у шкоду іншаму боку. Пры прыняцці рашэння важна, каб яно было маральна прынята ўсімі бакамі, як кажуць, "куплена". Каб, нават калі бакі і не былі ў захапленні ад прынятага рашэння, яны хаця б былі шчыра згодныя яго выконваць. Што называецца, быць у стане disagree and commit. Інакш канфлікт проста зменіць выгляд, тлеючы агонь застанецца пад тарфянішчам і ў нейкі момант непазбежна разгарыцца зноў.
Другі момант, збольшага звязаны з першым - калі вы ўжо ўзяліся ўдзельнічаць у рашэнні канфлікту, пастаўцеся да гэтага максімальна сур'ёзна з пункта гледжання камунікацый і вывучэнні кантэксту. Пагаварыце асабіста з кожным з бакоў. Асобна з кожнай, для пачатку. Не здавольвайцеся поштай. У выпадку размеркаванай каманды – паразмаўляйце хаця б па відэасувязі. Не здавольвайцеся чуткамі і пераказамі сведак. Зразумейце гісторыю, чаго хоча кожны з бакоў, чаму ён гэтага хоча, чаго чакае, ці спрабавалі вырашыць гэтае пытанне раней, што будзе, калі яно не будзе вырашана, якія варыянты рашэння яны бачаць, як уяўляюць пазіцыю іншага боку, што, на іх погляд , правільна ці няправільна, і г.д. Загрузіце ў сваю галаву ўвесь магчымы кантэкст, непрадузята, мяркуючы, што ўсе маюць рацыю. Вы не ўнутры канфлікту, вы звонку яго, у метапазіцыі. Калі кантэкст даступны толькі ў паштовым трэдзе - хаця б прачытайце цалкам яго і якія адносяцца да яго абмеркавання трэды і дакументы. Пасля таго як прачыталі - усё роўна пагаворыце голасам. Амаль гарантавана вы пачуеце нешта важнае, чаго няма ў пошце.
Трэці важны момант - агульны падыход да зносін. Гэта звычайныя рэчы, нічога касмічнага, але яны маюць вельмі вялікае значэнне. Не спрабуем зэканоміць час, размаўляем з усімі ўдзельнікамі, крытыкуем не чалавека, а разглядаем наступствы яго дзеянняў (не "ты грубы", а "мабыць, хлопцы могуць на гэтую штуку пакрыўдзіцца"), даем магчымасць захаваць асобу, абмеркаванні праводзім асабіста, а не перад строем.
Канфлікты звычайна бываюць выкліканы адной з двух прычын. Першая звязана з тым, ці знаходзіцца чалавек у момант канфлікту ў пазіцыі дарослага або ў пазіцыі дзіцяці (пра гэта ніжэй). Гэта звязана з яго эмацыйнай сталасцю, здольнасцю кіраваць сваімі эмоцыямі (што, дарэчы, зусім не заўсёды злучана з яго ўзростам). Другая распаўсюджаная прычына - недасканаласць працоўнага працэсу, якое стварае сітуацыі шэрых зон, у якой адказнасць размазана паміж удзельнікамі, чаканні бакоў не празрыстыя адзін для аднаго, ролі ў працэсе размытыя.
Адпаведна, у вырашэнні канфлікту (як і любога іншага пытання) менеджэр павінен мець на ўвазе тры перспектывы: кароткатэрміновую - вырашыць пытанне / канфлікт тут і цяпер, сярэднетэрміновую - мінімізаваць верагоднасць узнікнення іншага канфлікту па такой жа прычыне, і доўгатэрміновую - выхаванне ў камандзе культуры дарослага чалавека.
У кожным з нас ёсць унутранае дзіця, прыкладна трох-чатырох гадоў. Вялікую частку часу на працы ён спіць, але часам прачынаецца і бярэ кіраванне на сябе. У дзіцяці свае прыярытэты. Яму важна настаяць на тым, што гэта яго пясочніца, мама любіць яго больш, яго машынка лепш за ўсіх (дызайн лепш за ўсіх, ён праграмуе лепш за ўсіх, …). У сітуацыі канфлікту дзіця можа прыціскаць цацкі, тупаць нагамі і трэснуць лапаткай, але ён не можа вырашаць дарослыя пытанні (архітэктура рашэння, падыходы да аўтаматычнага тэсціравання, тэрміны рэлізу, і г.д), ён не думае ў тэрмінах карысці для каманды. Дзіця ў канфлікце можна падбадзёрыць, суцешыць і адправіць спаць, папрасіўшы яго паклікаць свайго дарослага. Перад пачаткам абмеркавання ва ўмовах канфлікту пераканайцеся, што вы зараз размаўляеце з дарослым, а не з дзіцем, і самі стаіце на пазіцыі дарослага. Калі ваша сумленная мэта ў дадзены момант - вырашыць сур'ёзнае пытанне, вы на пазіцыі дарослага чалавека. Калі ваша мэта - тупаць нагамі і трэснуць лапаткай - гэта дзіцячая пазіцыя. Адпраўце сваё ўнутранае дзіця спаць і паклічце дарослага, або перанясіце абмеркаванне. Чалавек прымае эмацыйнае рашэнне, а затым шукае яму рацыянальнае абгрунтаванне. Рашэнне, прынятае дзіцем, зыходзячы з дзіцячых прыярытэтаў, не будзе аптымальным.
Акрамя паводзін у момант канфлікту, дзіцячая ці дарослая пазіцыя характарызуецца гэтак жа ўзроўнем адказнасці, якую чалавек гатовы ўзяць на сябе. У крайніх праявах, дзіцячая пазіцыя праграміста, якую я сустракаў неаднаразова, выглядае так: я код напісаў, адправіў яго на рэўю - мая праца скончаная. Рэв'юеры павінны яго прагледзець і смержыць, QA павінны яго праверыць, калі будуць праблемы - яны мне паведамяць. Як ні дзіўна, нават даволі дарослыя і дасведчаныя людзі часам паводзяць сябе падобнай выявай. Іншы край шкалы - чалавек лічыць сябе адказным за тое, каб яго код працаваў, быў пакрыты тэстамі, быў правераны асабіста ім, паспяхова прайшоў рэўю (калі трэба, няма праблем папінгаваць рэўюераў, абмеркаваць пытанні голасам, і г.д.) і быў смержен , QA пры неабходнасці будзе аказана дапамога, апісаны сцэнары тэсціравання, і г.д. У нармальных выпадках праграміст альбо першапачаткова знаходзіцца бліжэй да дарослага краю шкалы, альбо ссоўваецца туды па меры назапашвання досведу (пры ўмове, што ў камандзе культывуецца правільная культура). У экстрэмальных жа выпадках ён працягвае працаваць, займаючы звычайна дзіцячую пазіцыю, тады ў яго і каманды перыядычна ўзнікаюць праблемы і канфлікты.
Выхаванне ў камандзе правільнай, дарослай культуры - важная задача любога мэнэджэра. Яна патрабуе працяглага часу і штодзённых намаганняў, але вынік таго варты. Ёсць два спосабы паўплываць на культуру каманды - асабісты прыклад (якому абавязкова будуць прытрымлівацца, каманда заўсёды глядзіць на лідэра) і абмеркаванне і заахвочванне правільных паводзін. Тут таксама няма нічога мудрагелістага ці моцна фармальнага, проста пры абмеркаванні праблем заўважайце, што тут можна было б зрабіць вось так, падкрэслівайце, што заўважылі, калі вырашана правільна, пахваліце, адзначайце на разборы рэлізу, і г.д.
Разгледзім некалькі тыповых канфліктных сітуацый, ад простага да складанага:
Канфлікты, не звязаныя з працоўнымі пытаннямі
Даволі часта на працы здараюцца канфлікты, не звязаныя з працоўнымі пытаннямі. Іх узнікненне і лёгкасць дазволу звычайна напрамую звязаны з узроўнем эмацыйнага інтэлекту ўдзельнікаў, узроўнем іх даросласці, і не звязаны з дасканаласцю або недасканаласцю працоўнага працэсу.
Тыповыя прыклады - хтосьці недастаткова часта карыстаецца пральнай машынай ці душам, што не падабаецца навакольным, камусьці душна, а іншаму дзьме, калі адчыняць акно, хтосьці занадта шумны, а навакольным патрэбна цішыня для працы, ну і гэтак далей. З вырашэннем канфліктаў такога роду лепш не зацягваць і не пускаць на самацёк. Самі сабой яны не рассмокчуцца і будуць штодня адцягваць ад працы і атручваць атмасферу ў камандзе. На шчасце, вырашыць іх звычайна вялікіх праблем не складае - досыць спакойна пагаварыць (зразумела, сам-насам) з калегам, грэбуюць гігіенай, забяспечыць камфортную рассадку людзей, якія аддаюць перавагу цішыню / прахалоду, купіць гукапаглынальныя навушнікі або паставіць перагародкі, і г.д.
Іншы прыклад, які сустракаўся мне за час працы некалькі разоў - псіхалагічная несумяшчальнасць чальцоў каманды. Па нейкіх прычынах людзі проста не могуць працаваць разам, кожныя зносіны заканчваюцца скандалам. Часам гэта звязана з тым, што людзі прытрымліваюцца палярных поглядаў па нейкім актуальным пытанні (звычайна палітычным) і не ўмеюць пакідаць іх за межамі працы. Пераконваць іх пацярпець адзін аднаго або змяніць свае паводзіны - занятак досыць бесперспектыўны. Адзінае выключэнне, якое я сустракаў - маладыя калегі з адкрытым успрыманнем, іх паводзіны яшчэ можна паступова змяніць перыядычнымі размовамі. Звычайна пытанне паспяхова вырашаецца развядзеннем іх па розных камандах, ці, прынамсі, забеспячэннем магчымасці вельмі рэдка перасякацца па працы.
Ва ўсіх прыведзеных сітуацыях з усімі ўдзельнікамі варта пагаварыць персанальна, абмеркаваць сітуацыю, пацікавіцца, ці бачаць яны ўвогуле праблему ў дадзеным выпадку, спытаць, якія, на іх думку, ёсць шляхі вырашэння, забяспечыць іх удзел у прыняцці гэтага рашэння.
З пункту гледжання аптымізацыі працоўнага працэсу (сярэднетэрміновая перспектыва, пра якую я згадваў), зрабіць тут можна не вельмі шмат, адзіны момант для аптымізацыі - улічваць фактар сумяшчальнасці пры фармаванні каманды і загадзя не ставіць разам людзей, якія будуць канфліктаваць.
З пункту гледжання культуры каманды, такія сітуацыі ўзнікаюць нашмат радзей у камандах з дарослай культурай, дзе людзі паважаюць каманду і калег і ўмеюць вырашаць пытанні самастойна. Акрамя таго, такія канфлікты вырашаюцца нашмат прасцей (часта аўтаматычна) у камандах, дзе высокі ўзровень даверу, людзі даўно працуюць разам і/ці часта маюць зносіны па-за працай.
Канфлікты, звязаныя з працоўнымі пытаннямі:
Такія канфлікты выкліканыя звычайна абедзвюма прычынамі адразу, і эмацыйнай (тым, што нехта з удзельнікаў не знаходзіцца на пазіцыі дарослага), і недасканаласцю самага рабочага працэсу. Самы, мабыць, часты выгляд канфліктаў, які я сустракаў - канфлікты падчас рэўю кода ці абмеркаванні архітэктуры паміж распрацоўнікамі.
Я б вылучыў тут два тыповыя выпадкі:
1) У першым выпадку распрацоўшчык не можа дамагчыся рэўю кода ад калегі. Патч адпраўлены на раўчу, і нічога не адбываецца. На першы погляд, відавочнага канфлікту паміж двума бакамі няма, але, калі ўдумацца, гэта цалкам канфлікт. Працоўнае пытанне не вырашаецца, адна з бакоў (якая чакае рэўю) адчувае відавочны дыскамфорт. Экстрэмальны падвід такога выпадку - распрацоўка ў кам'юніці або ў розных камандах, пры гэтым рэўюер можа быць не зацікаўлены ў гэтым канкрэтным кодзе, у сілу загрузкі або іншых абставін можа наогул не звяртаць увагі на запыт на раўью, і знешняга арбітра (агульнага для абодвух бакоў мэнэджара ) можа наогул не быць.
Падыход да рашэння, які дапамагае ў такой сітуацыі, адносіцца якраз да доўгатэрміновай перспектывы, культуры дарослага чалавека. Па-першае, працуе разумная актыўнасць. Не варта чакаць, што які вісіць на рэўю код зверне на сябе ўвага рэўюера сам. Трэба дапамагчы рэўюерам яго заўважыць. Пінгані пару чалавек, задай пытанне на сінкапе, удзельнічай у абмеркаваннях. Відавочна, што назойлівасць хутчэй зашкодзіць, чым дапаможа, трэба ўключаць разумны сэнс. Па-другое, добра працуе папярэдняя падрыхтоўка. Калі каманда разумее, што і чаму адбываецца, навошта гэты код наогул патрэбен, дызайн быў абмеркаваны і ўзгоднены загадзя з усімі, людзі хутчэй звернуць увагу на такі код і прымуць яго ў працу. Па-трэцяе, працуе аўтарытэт. Калі ты хочаш, каб цябе ревьюили - рабі шмат ревью сам. Рабі якасныя рэўю, з рэальнымі праверкамі, рэальнымі тэстамі, карыснымі каментарамі. Калі твой нік вядомы ў камандзе з добрага боку, больш шанцаў, што на твой код звернуць увагу.
З пункту гледжання працоўнага працэсу, магчымыя паляпшэнні тут — правільная расстаноўка прыярытэтаў, накіраваная на тое, каб дапамагчы распрацоўніку дасягаць сваіх мэт і мэт каманды (рабіць рэўю іншых, пісаць лісты ў кам'юніці, суправаджаць код апісаннем архітэктуры, дакументацыяй, тэстамі, удзельнічаць у абмеркаваннях з кам'юніці, і г.д.), не дапускаць занадта доўгага завісання патчаў у чарзе, і гэтак далей.
2) Другі распаўсюджаны выпадак канфліктаў пры рэўю кода або дызайну - розныя погляды на тэхнічныя пытанні, стыль кадавання, выбар інструментара. Вялікае значэнне пры гэтым мае ўзровень даверу паміж удзельнікамі, прыналежнасць да адной каманды, вопыт сумеснай працы. Тупік надыходзіць тады, калі нехта з удзельнікаў займае дзіцячую пазіцыю, не спрабуе пачуць, што яму хоча данесці суразмоўца. Часта пры гэтым і падыход, прапанаваны іншым бокам, і падыход, прапанаваны першапачаткова, цалкам могуць паспяхова працаваць і не мае прынцыповага значэння, які менавіта абраць.
Аднойчы праграміст з маёй каманды (назавём яго Паша) падрыхтаваў патч са зменамі ў сістэму разгортвання пакетаў, якую распрацавалі і падтрымлівалі калегі з суседняга дэпартамента. У аднаго з іх (Ігара) было сваё моцнае меркаванне адносна таго, як менавіта трэба наладжваць сэрвісы Лінукса пры разгортванні пакетаў. Гэтае меркаванне адрознівалася ад падыходу, прапанаванага ў патчы, і дамовіцца ў іх не атрымлівалася. Як звычайна, тэрміны падціскалі, і было трэба прыйсці да нейкага рашэння, трэба было, каб нехта з іх заняў дарослую пазіцыю. Паша прызнаваў, што абодва падыходы маюць права на жыццё, але яму хацелася, каб ягоны варыянт прайшоў, т.я. відавочных тэхнічных пераваг не было ні ў аднаго, ні ў другога варыянту.
Наша абмеркаванне выглядала прыкладна так (вельмі схематычна, вядома, размова была на паўгадзіны):
- Паша, у нас праз некалькі дзён feature freeze. Важна, каб мы ўсё сабралі і пачалі тэсціраванне як мага хутчэй. Як бы нам прайсці праз Ігара?
- Ён хоча наладжваць сэрвісы па іншаму, каментароў там наляпіў мне ...
- І што там, вялікія пераробкі, многа валтузні?
- Ды не, там працы на пару гадзін, але ў выніку розніцы ж няма, і так, і так будзе працаваць, навошта гэта трэба? Я зрабіў працуючую рэч, давай яе і прымем.
- Слухай, а колькі ўжо вы гэта ўсё абмяркоўваеце?
- Ды ўжо тыдні паўтара топчамся.
- Эм ... мы можам за пару гадзін вырашыць пытанне, якое ўжо заняў паўтары тыдні, і не робім гэтага?
— Ну, так, але мне не хочацца, каб Ігар падумаў, што я прагнуўся…
- Слухай, а табе самому што важней, рэліз выпусціць, разам з тваім рашэннем усярэдзіне, ці Ігара забараць? Можам забароць, тады, праўда, ёсць добры шанец праляцець з рэлізам.
— Ну… было б прышпільна, вядома, нос Ігарку выцерці, але добра, рэліз важней, згодзен.
- Табе рэальна так важна, што думае Ігар? Сапраўды кажучы, яму наогул больш-менш па барабане, ён проста жадае адзінага падыходу ў розных месцах той штукі, за якую ён адказвае.
- Ну, ок, давай я зраблю так, як ён просіць у каментарах, і пачнем тэсціраванне.
- Дзякуй, Паша! Я быў упэўнены, што з вас дваіх ты апынешся дарослым, хоць Ігарок і старэйшы за цябе:)
Пытанне вырашыўся, рэліз выпусцілі ў тэрмін, Паша асаблівай незадаволенасці не адчуваў, т.я. ён сам прапанаваў рашэнне і рэалізаваў яго. Ігар наогул быў задаволены, т.я. яго меркаванне ўлічылі і зрабілі так, як ён прапаноўваў.
Іншы выгляд такога ж, па сутнасці, канфлікту - выбар паміж тэхнічнымі рашэннямі / бібліятэкамі / падыходамі ў праекце, асабліва ў размеркаванай камандзе. У адным з праектаў, які пазіцыянаваўся, як які выкарыстоўвае C/C++, у выніку аказалася, што тэхнічны менеджмент праекта катэгарычна супраць выкарыстання STL (Standard Template Library). Гэта стандартная бібліятэка мовы, якая спрашчае распрацоўку, нашая каманда да яе вельмі прывыкла. Аказалася, што праект нашмат бліжэй да C, чым да C++, што не вельмі натхняла каманду, т.я. менеджмент пастараўся і набраў рэальна крутых плюсавікоў. Пры гэтым, амерыканская частка каманды, і інжынеры, і менеджэры, працавалі ў кампаніі даўно, абвыклі да існуючага стану рэчаў, іх усё задавальняла. Расейскую ж частку каманды сабралі разам зусім нядаўна, за некалькі тыдняў (у тым ліку і мяне). Расейская частка каманды катэгарычна не жадала адмаўляцца ад звыклага падыходу да распрацоўкі.
Пачаліся бясконцыя пісьмовыя абмеркаванні паміж двума кантынентамі, лісты па тры-чатыры экраны лёталі туды-сюды, у групавой рассылцы і асабістыя, ад праграмістаў - праграмістам і менеджэрам. Як гэта звычайна бывае, ліста такога памеру ніхто, акрамя аўтараў і іх гарачых прыхільнікаў, не чытаў. Чаты паскрыпвалі ад напругі, перадаючы ў розныя бакі шматэкранныя меркаванні адносна тэхнічных пераваг STL, наколькі добра яна пратэставаная, бяспечная, і наогул, як выдатнае жыццё з ёй, і як жудасная без яе.
Доўжылася гэта ўсё даволі доўга, да таго часу, пакуль я нарэшце не зразумеў, што мы абмяркоўваем тэхнічныя бакі пытання, а праблема ў рэальнасці не тэхнічная. Праблема не ў добрых якасцях або недахопах STL або складанасці працы без яе. Праблема хутчэй арганізацыйная. Нам трэба было проста зразумець, як уладкованая кампанія, у якой мы працавалі. Раней ні ў кога з нас досведу працы ў такой кампаніі не было. Справа была ў тым, што пасля распрацоўкі кода і выпуску яго ў production, падтрымкай займаліся зусім іншыя людзі з іншых каманд, з іншых краін. Гэтая велізарная інжынерная каманда з некалькіх дзясяткаў тысяч інжынераў (у сукупнасці) магла сабе дазволіць толькі зусім базавы мінімум тэхнічных сродкаў, так бы мовіць, minimum minimorum. Усё, што выходзіла за рамкі інжынернага стандарту, які склаўся ў кампаніі, фізічна не магло быць падтрымана ў далейшым. Узровень каманды вызначаецца ўзроўнем найслабых яе чальцоў. Пасля таго як мы зразумелі рэальную матывацыю дзеянняў амерыканскай часткі каманды, гэтае пытанне было знята з парадку дня, і мы ўсе разам паспяхова распрацавалі і выпусцілі прадукт, выкарыстоўваючы стандарты, прынятыя ў кампаніі. Лісты і чаты ў гэтым выпадку працавалі дрэнна, каб прыйсці да агульнага назоўніка, спатрэбілася некалькі паездак і шмат асабістых зносін.
З пункту гледжання працоўнага працэсу, у гэтым канкрэтным выпадку, дапамагло б наяўнасць апісання выкарыстоўваных сродкаў, патрабаванні да іх, абмежаванні на даданне новых, абгрунтаванне такіх абмежаванняў. Такія дакументы прыкладна адпавядаюць апісаным у пунктах Reuse Strategy і Development Environment кіраўніцтва "Manager's Handbook for Software Development", распрацаванага ў . Нягледзячы на свой узрост, ён выдатна апісвае ўсе асноўныя актыўнасці і этапы планавання распрацоўкі ПЗ падобнага кшталту. Наяўнасць падобных дакументаў вельмі спрашчае працэс абмеркавання таго, якія кампаненты і падыходы могуць быць скарыстаны ў прадукце, і чаму.
З пункту гледжання культуры ж, відавочна, пры больш дарослай пазіцыі, пры якой бакі спрабуюць пачуць і зразумець рэальную матывацыю дзеянняў калег і дзейнічаюць зыходзячы з прыярытэтаў праекта і каманды, а не асабістага эга, канфлікт вырашыўся б прасцей і хутчэй.
У іншым канфлікце з-за выбару тэхнічнага рашэння мне таксама спатрэбіўся прыкметны час, каб зразумець матывацыю аднаго з бакоў (вельмі ўжо незвычайны быў выпадак), але пасля таго як матывацыя была зразумелая, рашэнне было відавочнае.
Сітуацыя такая: у камандзе з прыкладна 20 чалавек з'яўляецца новы распрацоўшчык, назавем яго Стас. Нашым стандартным інструментам для зносін у камандзе быў на той момант скайп. Як потым высветлілася, Стас быў вялікім фанатам адкрытых стандартаў і апенсорснага ПЗ, і карыстаўся толькі інструментамі і аперацыйнымі сістэмамі, зыходнікі якіх даступныя публічна, і якія выкарыстоўваюць апісаныя публічна пратаколы. Скайп да такіх прылад не ставіцца. Мы патрацілі процьму часу на абмеркаванні добрых якасцяў і недахопаў гэтага падыходу, спроб запуску аналагаў скайпа на розных аперацыйных сістэмах, спробах Стаса пераканаць каманду перайсці на іншыя стандарты, пісаць яму персанальна па пошце, тэлефанаваць яму персанальна па тэлефоне, купіць яму другі кампутар спецыяльна для скайпа, і г.д. Нарэшце я зразумеў, што гэта праблема, па сутнасці, не тэхнічная і не арганізацыйная, яна хутчэй светапоглядная, нават, можна сказаць, рэлігійная (для Стаса). Нават калі б мы ў выніку злучылі Стаса і скайп (на што ўжо сышло некалькі месяцаў), на любой наступнай прыладзе праблема паўстала бы зноў. У мяне ў распараджэнні не было рэальных сродкаў змяніць светапогляд Стаса, і не было падстаў спрабаваць змяніць светапогляд каманды, якая выдатна працавала ў гэтым асяроддзі. Чалавек і кампанія проста былі артаганальныя па светапоглядзе. У падобных сітуацыях добры варыянт рашэння - арганізацыйны. Мы перавялі Стаса ў іншую каманду, дзе ён быў больш арганічны.
Прычына гэтага канфлікту, на мой погляд, у неадпаведнасці асабістай культуры канкрэтнага чалавека (у якога ёсць моцнае меркаванне, якое не дазваляе яму ісці на кампрамісы), культуры кампаніі. У дадзеным выпадку гэта, вядома, памылка мэнэджара. Было першапачаткова няправільна браць яго на праект падобнага кшталту. Стас у выніку перайшоў на праект па распрацоўцы адкрытага ПЗ і выдатна там атрымаў поспех.
Добры прыклад канфлікту, выкліканы адначасова дзіцячай пазіцыяй распрацоўніка і недахопамі працоўнага працэсу – сітуацыя, у якой у адсутнасць definition of done у распрацоўніка і QA каманды ёсць розныя чаканні адносна гатоўнасці фічы, перададзенай у QA. Распрацоўнік лічыў, што дастаткова напісаць код і перакінуць фічу праз плот у QA – там разбяруцца. Даволі дарослы і дасведчаны, дарэчы, праграміст, але такі ўжо ў яго быў унутраны парог якасці. QA з гэтым былі нязгодныя і патрабавалі паказаць і апісаць ім, што ён праверыў сам, і патрабавалі сцэнар тэсціравання для іх. Яны ўжо мелі ў мінулым праблемы з функцыяналам ад гэтага распрацоўшчыка і не хацелі марнаваць свой час дарма яшчэ раз. Дарэчы, яны мелі рацыю – фіча сапраўды не працавала, код перад перадачай у QA ён не праверыў.
Для вырашэння сітуацыі я папрасіў яго паказаць мне, што ўсё сапраўды працуе (яно не працавала, і яму прыйшлося правіць), мы прагаварылі з камандай і з QA definition of done (рабіць яго пісьмовым не сталі, бо не хацелі занадта бюракратызаваць працэс ), ну а з гэтым спецыялістам мы неўзабаве расталіся (да агульнага палягчэння).
З пункту гледжання працоўнага працэсу магчымыя паляпшэнні ў дадзеным выпадку – наяўнасць definition of done, патрабаванні да суправаджэння кожнай фічы юніт і інтэграцыйнымі тэстамі, апісанне тэсціравання, праведзенага распрацоўшчыкам. У адным з праектаў мы замяралі ўзровень пакрыцця кода тэстамі падчас CI і ў выпадку, калі ўзровень пакрыцця пасля дадання патча, падаў, тэсты пазначаліся як непройденные, г.зн. любы новы код мог быць дададзены толькі пры наяўнасці новых тэстаў для яго.
Яшчэ адзін тыповы прыклад канфлікту, цесна звязанага з арганізацыяй працоўнага працэсу. У нас ёсць прадукт, каманда распрацоўкі гэтага прадукта, каманда падтрымкі і заказчык. У замоўца ўзнікаюць праблемы з прадуктам, ён звяртаецца да падтрымкі. Падтрымка аналізуе праблему і разумее, што праблема ў прадукце, перадае праблему прадуктовай камандзе. У прадуктовай каманды гарачая пара, рэліз на падыходзе, таму тыкет з праблемай ад заказчыка, які згубіўся сярод астатніх тыкетаў у распрацоўніка, якому ён прызначаны, вісіць некалькі тыдняў без увагі. Падтрымка думае, што распрацоўшчык працуе над праблемай заказчыка. Замовец чакае і спадзяецца, што над яго праблемай працуюць. У рэальнасці нічога пакуль не адбываецца. Праз некалькі тыдняў заказчык вырашае пацікавіцца прагрэсам і пытаецца ў падтрымкі, як справы. Падтрымка пытаецца распрацоўку. Распрацоўнік уздрыгвае, праглядае спіс тыкетаў і выяўляе там тыкет ад заказчыка. Чытаючы тыкет ад заказчыка ён разумее, што інфармацыі для вырашэння праблемы недастаткова, і яму патрэбны яшчэ логі і дампы. Падтрымка запытвае дадатковую інфармацыю ад заказчыка. І тут заказчык разумее, што над яго праблемай увесь гэты час ніхто не працаваў. І грымне гром…
У гэтай сітуацыі вырашэнне самога канфлікту даволі відавочнае і лінейна (паправіць прадукт, абнавіць дакументацыю і тэсты, улагодзіць заказчыка, выпусціць хотфікс, і г.д). Важна прааналізаваць працоўны працэс і зразумець, хто нясе адказнасць за арганізацыю ўзаемадзеяння паміж дзвюма камандамі, чаму такая сітуацыя ўвогуле стала магчымай. Зразумела, што трэба паправіць у працэсе - хтосьці павінен маніторыць агульную карціну без напамінкаў ад заказчыкаў, проактивно. Тыкеты ад заказчыка павінны вылучацца сярод астатніх тыкетаў у распрацоўшчыкаў. Падтрымка павінна бачыць, ці працуе распрацоўка над яе тыкетамі ў сапраўдны момант, калі не - калі зможа пачаць працаваць, калі можна чакаць выніку. Падтрымка і распрацоўка павінны перыядычна мець зносіны і абмяркоўваць статут тыкетаў, збор патрэбнай для адладкі інфармацыі павінен быць максімальна аўтаматызаваны, і т.д.
Як на вайне супернік імкнецца стукнуць у стык паміж двума падпадзяленнямі, так і ў працы самым тонкім і ўразлівым месцам звычайна апыняецца ўзаемадзеянне паміж камандамі. Калі менеджэры падтрымкі і распрацоўкі дастаткова дарослыя, яны змогуць паправіць працэс самастойна, калі не - працэс будзе працягваць генераваць канфлікты і праблемы, пакуль не ўмяшаецца менеджэр, які зможа паправіць сітуацыю.
Іншы характэрны прыклад, які я сустракаў неаднаразова ў розных кампаніях – сітуацыя, у якой прадукт пішацца адной камандай, аўтаматычныя інтэграцыйныя тэсты для яго – другой камандай, інфраструктура, на якой гэта ўсё эксплуатуецца, суправаджаецца трэцяй камандай. Праблемы пры прагонах тэстаў узнікаюць увесь час, і чыннікам праблем у іх можа быць як прадукт, так і тэсты і інфраструктура. Праблематычным звычайна бывае дамовіцца, хто павінен вырабляць першасны аналіз праблем, файліць багі, парсіць логі прадукта, тэстаў і інфраструктуры, і г.д. Канфлікты тут вельмі частыя, і ў той жа час аднастайныя. У выпадку высокага эмацыйнага напалу ўдзельнікі часта звальваюцца ў дзіцячую пазіцыю і пачынаюцца абмеркаванні з серыі: "чаму я павінен з гэтым калупацца", "у іх часцей за ламаецца", і г.д.
З пункту гледжання працоўнага працэсу канкрэтныя крокі для вырашэння пытання залежаць ад складу каманд, віду тэстаў і прадукта, і г.д. У адным з праектаў мы ўвялі перыядычныя дзяжурствы, пры якіх каманды сачылі за тэстамі па чарзе, па тыдні. У іншым першасны аналіз заўсёды праводзілі распрацоўшчыкі тэстаў, але пры гэтым аналіз быў вельмі базавы і прадукт дастаткова стабільны, так што гэта нядрэнна працавала. Галоўнае - забяспечыць празрыстасць працэсу, яснасць чаканняў для ўсіх бакоў і адчуванне справядлівасці сітуацыі для ўсіх.
Ці з'яўляецца наогул канфлікт у арганізацыі праблемай, ці дрэнная гэта прыкмета, што ў вашай камандзе часта (ці проста перыядычна) здараюцца канфлікты? У цэлым, не, бо калі адбываецца рост, развіццё, ёсць нейкая дынаміка, то ўзнікаюць пытанні, якія ніколі не вырашаліся раней, пры іх вырашэнні могуць узнікаць канфлікты. Гэта індыкатар таго, што на нейкія вобласці трэба звярнуць увагу, што ёсць вобласці для паляпшэнняў. Дрэнна, калі канфлікты ўзнікаюць вельмі часта, вырашаюцца цяжка ці доўга. Гэта, хутчэй за ўсё, прыкмета недастаткова адладжаных працоўных працэсаў і недастатковай даросласці каманды.
Крыніца: habr.com