Знаете, что общего между парнем в худи за покерным столом и тимлидом с вечно зумящим ноутбуком? На первый взгляд — ничего. Фишки против джиры, блеф против бэклога, ривер против релиза. Но если копнуть глубже — а давайте копнём, — окажется, что оба они играют в одну и ту же игру. Просто ставки разные: где‑то деньги, где‑то карьера, нервы команды и судьба продукта.

Я не шучу. Профессиональный покерист мыслит не комбинациями — он оперирует математическим ожиданием, диапазонами, управлением банкроллом. IT‑менеджер, который чего‑то стоит, думает ровно о том же: риски, бюджеты, ценность для бизнеса. Просто называет это по‑другому. И это не метафора — это система.

---

Ожидание vs реальность: та самая формула, которую все забывают

В покере каждое действие — колл, рейз, фолд — оценивается через Expected Value. EV, если по‑простому. Это не магия, это математика:

EV = (вероятность выигрыша × сумма выигрыша) — (вероятность проигрыша × сумма проигрыша)

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

Бизнес требует фичу. Стоит она $30,000. Шанс, что она «выстрелит» — 20%, потенциальный доход — $100,000. Красиво? Ага. А теперь калькулятор в руки:

(0.20 × 4,000

Отрицательное ожидание. Чистый минус. Но сколько раз я слышал: «да ладно, у нас есть шанс»? Это не управление рисками, это лудомания. И да, я тоже так ошибался. Не горжусь.

---

Диапазоны, чёрт возьми!

В покере вы никогда не знаете карты соперника. Но вы читаете его — по ставкам, по таймингу, по тому, как он двигает фишки. Вы закладываете его в диапазон. Не в одну руку, а в множество возможных.

В IT вы тоже никогда не знаете всего. Требования? Это миф. Технологии меняются быстрее, чем заказчик формулирует мысль. Архитектура, которая казалась железобетонной, может рухнуть под первой же нагрузкой.

Давайте проведём параллель, которая мне кажется очень точной:

Вывод, который я вынес для себя ещё лет десять назад: нельзя принимать решения, исходя из идеального сценария. Никогда. Нужно закладывать «диапазон» исходов. И всегда — слышите? — всегда иметь план Z. Не Б, не В. Z. Самый худший, самый дурацкий вариант.

---

Банкролл, или Почему нельзя ставить всё на кон

Самый гениальный покерист в мире обанкротится, если сядет играть на все деньги в одной раздаче. Дисперсия — она такая, знаете. Поэтому профи держат запас: минимум 50–100 бай‑инов для своего лимита. Это не жадность, это выживание.

В IT это называется «резервный фонд» и «бюджетирование рисков». Но как часто мы про это забываем!

Покерная ошибка: пойти ва‑банк с 70% на победу. 30% проигрыша — это не «чуть‑чуть», это вероятность остаться с пустыми карманами.

IT‑ошибка: выделить 100% времени команды на жёсткий дедлайн. Без запаса. Без плана Б. А потом — бац! — и сервер упал. Или ключевой разработчик ушёл в запой (или в другую компанию, что иногда страшнее). Или API интеграторов внезапно изменили, и всё, что работало, перестало.

Проект — кранты. Заказчик — в бешенстве. Команда — в стрессе.

Я видел это. Много раз. И каждый раз думал: ну почему мы не заложили хотя бы 20% буфера?

---

Оценка по результату — ловушка для дураков

В покере есть понятие «кулер». Ситуация, когда вы сделали всё идеально, математика была на вашей стороне, а на ривере пришла та самая карта, которая убила вашу комбинацию. Вы проиграли. Но решение было верным. Просто случайность.

В IT мы постоянно совершаем эту ошибку — оцениваем управление по результату.

Проект выстрелил, хотя код был — жесть, тестов — ноль, а риски даже не смотрели. Менеджер — гений! (В покере это называется «фишу доехало», но вслух так не говорят.)

Проект провалился из‑за внешних факторов. Apple поменяла правила, например. Или рынок упал. Хотя архитектура была прекрасна, а риски митигировались как надо. Команда — некомпетентны?

Бред.

Профессиональный подход: оценивать процесс, а не результат одной итерации. Хороший процесс на дистанции всегда побеждает дисперсию. Всегда. Это не вера — это статистика.

---

Четыре стратегии, которые работают везде

Помните, как в покере? У вас есть выбор.

Fold (Пас) = Избегание риска. Видите, что на столе мутные требования, легаси, которое страшно трогать? Просто откажитесь. Потеряете копейки на аналитике — сохраните миллионы на разработке.

Call (Колл) = Принятие риска. Риск есть, но цена входа невелика. Окей, принимаем. Закладываем буфер. Идём дальше.

Bet / Raise (Ставка) = Активное управление. Перехватываете инициативу. Превентивно пишете тесты, проводите нагрузочное тестирование, рефакторите узкие места до того, как они упадут. Не ждёте, пока хабраэффект накроет — вы его опережаете.

---

Покерные техники, которые уже работают в IT

Вы знали, что Planning Poker — это не просто забавное название? Это реальная техника оценки в Agile. Каждый член команды показывает карту с оценкой (по Фибоначчи: 1, 2, 3, 5, 8, 13…). Потом те, у кого оценки максимально разошлись, объясняют свою логику. Команда обсуждает — и приходит к консенсусу.

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

Есть ещё Protection Poker. Это для оценки рисков безопасности. Команда оценивает два параметра: ценность актива и уязвимость. Перемножают — получают риск. Просто, наглядно, работает. Без скучных таблиц и занудных презентаций.

---

Тильт, выгорание и эмоции

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

В IT это называется выгорание. Или «эмоциональное решение». Когда менеджер в панике меняет требования на финальной стадии. Когда разработчик ночами пишет код, потому что «надо успеть». Когда команда принимает решения не головой, а усталостью.

И знаете что? В обоих случаях это самая дорогая ошибка.

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

---

Признавать ошибки — это нормально

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

В корпоративной культуре, особенно в больших компаниях, признавать провалы — сложно. Страшно. Потому что «премия», «репутация», «а что скажет начальник».

Но именно культура, где можно обсуждать риски без страха наказания, — психологическая безопасность, если по‑умному, — лежит в основе нормального риск‑менеджмента.

Я работал в местах, где ошибки замалчивали. И в местах, где их анализировали. Разница — небо и земля.

---

Так что же в итоге?

Гарантий нет. В сложных системах их не бывает.

Есть управление вероятностями.

Считайте EV до того, как пишете код. Сужайте диапазоны неопределённости через MVP. Никогда не ставьте весь бюджет на одну фичу, одну технологию, одно решение. Оценивайте процесс, а не результат одной раздачи.

И да, если вам кажется, что ваш IT‑проект — это не покер, потому что «у нас всё серьёзно»… перечитайте эту статью ещё раз. Или сходите поиграйте в покер. Хотя бы в дурака.

---

P. S. Это только начало

Если вы дочитали до этого места — значит, тема вас зацепила. И это круто.

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

• Математика под капотом: как считать EV в реальных проектах, а не на абстрактных примерах. С шаблонами, калькуляторами и разбором ошибок.

• Работа с неопределённостью: как сужать диапазоны, строить гипотезы и не бояться «не знать». И что делать, когда данных всё равно мало.

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

• Тильт и выгорание: где грань между страстью и саморазрушением. И как спасать проекты, когда команда уже на пределе.

• Покерные техники: Planning Poker, Protection Poker и другие игры, которые работают не в теории, а в реальных командах.

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

А пока — до встречи за следующим столом. Сдавайте карты. Или, в вашем случае, открывайте следующий спринт.

---

А как вы управляете неопределённостью в своих проектах? Были случаи, когда приходилось «сбрасывать карты» и отказываться от фичи или проекта? Или, наоборот, когда вы шли ва‑банк — и это окупилось? Делитесь в комментариях, мне правда интересно.