Епіграф:
Зустрілися якось у лісі Їжачок та Ведмедик.
— Доброго дня, Їжачку!
— Привіт, Ведмедику!
Так, слово за слово, жарт за жартом, і отримав Їжачок від Ведмедика по морді.
Під катом міркування нашого тимліду, а також директора з розвитку продукту 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