«Команда перестала сперечатися — і це погана новина»: анатомія соціотехнічного конфлікту

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

Якщо продуктова та технічна команди раптом припинили сперечатися, не поспішайте радіти. Можливо, вони справді навчилися домовлятися, але є й інший варіант: суперечки просто втратили сенс.

Я кілька разів бачив саме другий сценарій. Спочатку інженери приходять із застереженнями, сперечаються про технічний борг, архітектуру чи строки, потім бачать, що результат від цього не змінюється, і поступово замовкають. Ззовні все навіть стає краще: менше суперечок, швидше планування, простіше ухвалювати рішення, але проблема в тому, що разом із конфліктом із системи може зникнути важливий зворотний зв’язок.

Давайте розберемо детальніше саме цей сценарій.

Що є конфліктом?

У побутовому розумінні конфлікт зазвичай асоціюється із суперечкою, протистоянням чи навіть кризою відносин. Ми звикли думати, що це аномалія, якої треба уникати, але в будь-якій складній системі, де різні сторони роблять спільну справу, конфлікт — природна реакція на те, що учасники бачать спільну ціль під різними кутами.

Мені тут близький погляд Томаса Шеллінга зі «Стратегії конфлікту». Він працює із ситуаціями, де сторони не є ані чистими союзниками, ані чистими противниками: частина їхніх інтересів збігається, частина — ні, але для досягнення власних цілей вони все одно залежать одна від одної. Взаємодія продуктової та технічної команд дуже на це схожа.

Якщо перенести цю логіку на продуктову розробку, я бачу щонайменше три місця, де інтереси регулярно розходяться:

1. Швидкість проти стабільності. Бізнесу важливо отримати результат раніше, а інженерам — не зробити наступну зміну втричі дорожчою. Це, зокрема, класичний конфлікт навколо технічного боргу, про природу якого я писав у попередній статті Технічний борг: керувати, а не перемагати.
2. Тактика проти стратегії. Гіпотезу іноді справді треба перевірити за тиждень, хоча технічно правильне рішення потребує місяця.
3. Межі автономії. Хто вирішує, що саме ми будуємо, а хто — як це буде реалізовано.

Самі по собі ці суперечності не означають, що в компанії щось зламано. Навпаки, вони цілком природні, причому на практиці ці три суперечності рідко існують окремо.

Припустимо, продукту потрібно вийти з новою функціональністю за два тижні. Спочатку ми сперечаємося про швидкість і стабільність: чи можемо дозволити собі технічний компроміс заради строку. Потім — про тактику і стратегію: це справді тимчасове рішення для перевірки гіпотези чи код, з яким нам доведеться жити наступні три роки?

А закінчитися все може суперечкою про автономію: продуктова сторона пропонує конкретний технічний шлях, бо він здається найшвидшим, а інженери у відповідь починають сперечатися вже не про ризик рішення, а про те, хто взагалі має право його приймати.

Одна продуктова задача таким чином проходить одразу через усі три площини. І якщо для кожної з них немає хоча б приблизно зрозумілих правил, командам доводиться щоразу домовлятися не тільки про саму задачу, а й про те, як вони взагалі будуть домовлятися.

Де починається проблема

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

На короткій дистанції така логіка навіть працює: можна відкласти рефакторинг, швидко випустити потрібну функціональність і повернутися до проблеми пізніше. Я сам багато разів приймав такі рішення, і далеко не завжди вони були помилковими, але сама проблема починається зі слова «пізніше».

Якщо одна сторона раз за разом отримує короткостроковий виграш за рахунок іншої, змінюється не конкретне рішення, а поведінка людей у наступних переговорах. У продуктовій розробці ми не домовляємося один раз: ті самі люди повертаються до переговорів наступного спринту, потім ще раз, і ще. Тому важливо не тільки те, хто виграв конкретну суперечку — важливо, що ця суперечка зробила з наступною. Якщо мої аргументи десять разів поспіль ні на що не вплинули, на одинадцятий я, найімовірніше, просто не витрачатиму на них час.

Чому ми приречені на конфлікт: системна перспектива

Я сам колись два роки працював у команді, яка намагалася бути максимально «зручною» для бізнесу. Ми уникали суперечок, посміхалися на демо й пишалися своєю безконфліктністю.

Результат? Платформа поступово перестала розвиватися технічно, а найкращі сеньйори тихо звільнилися.

Тоді я вперше серйозно задумався, чи був наш «мир» ознакою здорової взаємодії. Причому це не сталося в один момент — ніхто не зібрав команду й не сказав: «Відсьогодні ми більше не сперечаємося з бізнесом». Просто кожна наступна дискусія ставала коротшою. Десь ми погоджувалися, бо дедлайн справді був важливим, десь вирішували повернутися до проблеми наступного спринту, а десь уже просто не хотілося витрачати годину на розмову, результат якої всі могли передбачити заздалегідь.

Саме тому я довго не сприймав це як проблему. Зсередини така деградація не дуже схожа на деградацію — вона більше схожа на те, що команда нарешті перестала сперечатися через кожну дрібницю. Щотижневі компроміси накопичуються — кожен окремо може бути цілком виправданим, але разом вони поступово змінюють поведінку системи.

І ось тут мені вже цікавіше дивитися не на окремих людей, а на систему.

У «Thinking in Systems» Донелла Медоуз показує, наскільки сильно поведінка системи залежить від її структури: накопичень, потоків, затримок і зворотних зв’язків. Якщо подивитися таким чином на взаємодію продуктової та технічної команд, виходить цікава картина.

Петля стабілізації

У найпростішому варіанті система сама починає чинити опір накопиченим проблемам:

Технічний борг зростає → зміни стають дорожчими → проблеми вже неможливо ігнорувати → з’являється час на стабілізацію

Нічого магічного, у якийсь момент вартість бездіяльності просто стає більшою за вартість виправлення. Але поруч працює інша петля:

Потрібен результат швидше → погоджуємося на компроміс → випускаємо швидше → цей темп стає новим очікуванням → наступний результат теж потрібен швидше

І тут важливий момент: ніхто не зобов’язаний приймати очевидно дурні рішення. Кожен окремий компроміс може бути цілком виправданим — саме тому ця історія небезпечна. Проблема стає видимою тільки після того, як таких рішень накопичилося достатньо.

Щоб перевірити цю логіку не лише на рівні текстового міркування, я спробував формалізувати її у невеликій симуляції. Модель на GitHub поєднує System Dynamics з агентною моделлю інженера та продакт-менеджера: технічний борг, тиск делівері, реакція на інженерні сигнали та готовність команди ці сигнали подавати впливають одне на одного через петлі зворотного зв’язку й затримки.

Центральне питання моделі просте: чи може організація виглядати дедалі більш узгодженою саме в той момент, коли її технічний ризик зростає? У симуляції можна побачити, як технічний ризик та видимий конфлікт починають розходитися, а також перевірити, як на цю динаміку впливають не лише поведінка сторін, а й структурні правила на кшталт заздалегідь виділеної capacity на стабілізацію, бюджетом помилок та чітких меж технічної автономії.

А потім команда замовкає

Найцікавіше відбувається далі. Інженери кілька разів піднімають одну й ту саму проблему, а рішення щоразу відкладається — через якийсь час люди роблять цілком раціональний висновок: повторювати аргумент немає сенсу, і сигналів стає менше.

Для продуктової сторони картина при цьому покращується: раніше на плануванні постійно сперечалися про архітектуру, технічний борг і ризики, а тепер перестали, планування проходить швидше, roadmap рухається.

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

Я не хочу сказати, що чим більше суперечок, тим здоровіша команда — це очевидно не так. Але є принципова різниця між «нам нема про що сперечатися» і «ми більше не бачимо сенсу сперечатися». Ззовні ці два стани можуть виглядати однаково.

Для мене це і є головний висновок: відсутність незгоди сама по собі нічого не говорить про здоров’я системи. Іноді це просто означає, що один із каналів зворотного зв’язку вже не працює.

І ще одна проблема — час

Технічний компроміс ми робимо сьогодні, а платити за нього можемо почати через пів року, і за цей час контекст губиться. Коли проста зміна раптом починає займати три тижні замість трьох днів, продуктова команда бачить проблему сьогодні, інженери, у свою чергу, можуть бачити її причину в рішеннях, які приймалися кілька кварталів тому.

Звідси й класичне:

— «Чому ви не попередили раніше?»

— «Ми попереджали».

І обидві сторони можуть говорити абсолютно щиро — тут дуже легко перейти до взаємних звинувачень. Продуктова сторона бачить, що команда стала повільнішою, технічна — що нарешті проявилася ціна старих компромісів. Проблема в тому, що між причиною і наслідком минуло достатньо часу, щоб вони вже не виглядали частинами одного рішення — і наступного разу домовлятися буде ще складніше.

Що з цим робити?

Прибрати конфлікт не вийде, та й не потрібно, у продуктової та технічної сторін різні зони відповідальності, різний контекст і різний горизонт планування — вони будуть дивитися на одне рішення по-різному. Питання в іншому: як зробити так, щоб ці суперечності не перетворювалися ані на постійну війну, ані на мовчання однієї зі сторін?

Для цього самого заклику «давайте краще комунікувати» недостатньо. Якщо щоразу з нуля сперечатися про час на стабілізацію, допустимий технічний ризик або про те, хто має останнє слово в способі реалізації, ми просто відтворюватимемо той самий конфлікт у кожному наступному спринті.

Потрібні заздалегідь зрозумілі орієнтири для тих самих трьох площин, з яких ми починали: швидкості й стабільності, тактики й стратегії, меж автономії. Не універсальна відповідь на всі суперечки, а швидше точки, від яких сторони можуть відштовхнутися, коли їхні інтереси знову розійдуться.

Скільки технічного ризику ми готові взяти заради швидкості? За яким сигналом перестаємо експериментувати й повертаємося до стабілізації? Де закінчується право продуктової сторони визначати результат і починається право технічної визначати спосіб його реалізації?

У термінах Шеллінга тут стає цікаво говорити про фокальні точки — орієнтири, навколо яких сторони можуть координуватися, не починаючи кожні переговори з чистого аркуша. Саме їх я й хочу розібрати в наступній статті.

Використані матеріали

• Thomas C. Schelling. The Strategy of Conflict. Harvard University Press, 1960.
• Donella H. Meadows. Thinking in Systems: A Primer. Chelsea Green Publishing, 2008.