Равновесие Нэша в инхаусе ИТ, или кто первый моргнёт

Картина знакома почти каждому, кто работал в команде ИТ‑департамента внутри компании. Задачи прилетают в мессенджер конкретному аналитику/программисту, приоритет определяется громкостью заказчика, доработки проверяются прямо в рабочей базе. Бизнес недоволен скоростью и качеством, ИТ — бесконечными пожарами и невозможностью что‑либо планировать и распределять ресурсы.

При этом все понимают, что необходимы изменения и организация рабочих процессов.

Почему же ничего не меняется? Неожиданный ответ мне подсказала теория игр (спасибо университету за это!) и она же подсказывает, как из этой ловушки выбраться.

Немного теории

Равновесие Нэша — это ситуация, в которой ни одному игроку невыгодно менять стратегию в одиночку. Важно: равновесие не означает положение «выиграл‑выиграл», оно может быть и плохим для всех — главное, она устойчиво и устраивает все стороны. 

Однако если одна из сторон решает играть по новым правилам, другой стороне выгодно играть так же, и наоборот.

Такое взаимодействие называется «Охота на оленя» (Stag Hunt). Два охотника могут вместе добыть оленя или поодиночке добыть по зайцу. Олень лучше, но тот, кто пошёл за ним один, остается с пустыми руками.

В этой игре два равновесия: «оба охотятся на зайцев» и «оба охотятся на оленя». Проблема не в жадности, а в доверии: никто не хочет рисковать первым.

Игра «ИТ и бизнес»

Предположим, что у каждого игрока две стратегии: работать «по‑старому» или «по‑новому».

• ИТ по‑старому: пожарный режим, задачи берутся в работу сразу, ресурсы перераспределяются в мгновение ока, без оценки и плана.

• ИТ по‑новому: единый бэклог, оценка, релизный цикл, качественное тестирование, документация.

• Бизнес по‑старому: задачи напрямую сотруднику ИТ, всё «срочно», полноценное тестирование только на рабочей базе.

• Бизнес по‑новому: владельцы процессов, приоритизация, участие в постановке и приёмке.

Матрица выигрышей (ИТ; Бизнес), баллы условные:

В матрице два равновесия Нэша. Левое верхнее (2; 2) — плохое, но устойчивое: тот, кто из него выйдет один, потеряет. Правое нижнее (4; 4) — целевое, и оно тоже устойчиво, если до него добраться.

Почему односторонние изменения проваливаются

Когда меняется только одна сторона, система попадает в клетку хуже исходной и возвращается обратно.

Сценарий 1: ИТ внедряет процесс, бизнес его игнорирует. Руководитель проекта/департамента ИТ вводит заявки через единое окно, оценку трудоёмкости, регулярные релиз‑комитеты и приоритизацию. Бизнес продолжает писать в мессенджер и эскалировать через ИТ‑директора. ИТ тратит силы на формальности, а бизнес видит лишь замедление и бюрократию. Через пару недель весь процесс заброшен.

Сценарий 2: бизнес готов меняться, ИТ — нет. Компания решает организовать процессный офис, оцифровывает процессы, назначает владельцев процессов, готовит функциональные требования и все ждут плана. ИТ продолжает тушить пожары, не составляет план‑графиков, сроки срываются. Вложенное время бизнеса пропадает, и он возвращается к своему привычному паттерну — «свяжусь‑ка я с исполнителем напрямую».

В итоге случается самое неприятное: каждая неудачная попытка только цементирует плохое равновесие. У обеих сторон появляется опыт «мы пробовали, не работает» — и следующий первый шаг стоит ещё дороже, никто больше не хочет пробовать что‑то изменить.

Как перейти в хорошее равновесие

Игры координации решаются не уговорами «давайте жить дружно», нужно менять условия игры: снижать риск первого шага или повышать уверенность в партнёре.

1. Третий игрок. Собственник или генеральный директор меняет правила для обеих сторон одновременно. Например, делает приоритизацию через релиз‑комитет единственным способом попасть в план. Так синхронный переход перестает быть вопросом доверия.

2. Обязательства. Каждая сторона публично фиксирует, что даст другой. ИТ — SLA и прозрачный план релизов, бизнес — владельцев процессов и сроки приемки.

3. Повторяющаяся игра. Не перестраивать всё сразу, а начать с пилота в одном подразделении. Короткие циклы дают быстрые победы, а каждая победа повышает доверие к следующему раунду.

4. Сигналы. Первый шаг должен быть заметным и полезным для другой стороны. Если ИТ начинает не с регламента, а с дашборда или любой другой понятной визуализации «что и когда будет сделано», бизнес сразу видит выгоду.

И давайте честно: у бизнеса обычно больше власти, поэтому первым чаще всего ходит ИТ. Значит, задача ИТ — сделать свой ход максимально дешёвым на случай неудачи и максимально заметным на случай успеха.

Практический план для ИТ

Переход стоит строить так, чтобы на каждом шаге обе стороны менялись вместе и видели результат.

1. Договоритесь с «третьим игроком». Покажите руководству цену текущего хаоса: сколько часов уходит на переделки, баги и переключения между задачами. Цифры убеждают лучше эмоций.

2. Выберите пилот. Одно подразделение с лояльным руководителем и заметной болью: склад, закупки, производство.

3. Зафиксируйте взаимные обязательства. ИТ дает прозрачный бэклог и сроки, бизнес — владельца процесса, приоритеты и участие в приемке.

4. Вводите практики по одной. Сначала единая точка входа задач, потом оценка, потом тестовая база и релизный цикл. Толстый регламент в первый же день — путь в никуда.

5. Показывайте результат. Раз в месяц — цифры пилота: сколько задач сделано в срок, сколько ошибок доехало до прода.

6. Масштабируйте. Успешный пилот сам продает себя следующим подразделениям, уже без уговоров.

Вывод

Хаос в инхаусе ИТ держится не на некомпетентности и не на лени. Он держится на вполне рациональном расчёте: меняться в одиночку невыгодно.

Поэтому вопрос не «кто виноват — ИТ или бизнес?». Вопрос ‑кто и как синхронизирует переход. Когда обе стороны делают шаг вместе, новое равновесие оказывается таким же устойчивым, как старое. Только теперь выигрывают все.