Знаете, что роднит парня в растянутом худи за овальным столом в Лас-Вегасе и командного лида, который пялится в доску с задачами в пятом часу утра? Я бы сказал — ничего. Ну серьезно: фишки против джиры, блеф против бэклога, ривер против дедлайна. Абсолютно разные вселенные. Но это лишь если не присматриваться. А если присмотреться, да еще как следует — становится ясно: оба играют в одну и ту же игру, просто ставки разные. Где-то решается судьба банкролла, а где-то — судьба продукта, нервы команды и ваше собственное реноме.
И не надо тут усмехаться. Профессионал за покерным столом — да он вообще не про комбинации думает, если честно. Математическое ожидание, диапазоны соперников, управление капиталом — вот его реальный инструментарий. Грамотный IT-руководитель, если он чего-то стоит, рассуждает в тех же категориях: риски, бюджеты, бизнес-ценность. Просто называет это иначе. Но суть — она одна. И я бы даже сказал: это не красивая метафора для статьи, это рабочий подход.
Ожидание, реальность и формула, которую все отчего-то игнорируют
Смотрите. В покере любой ход — колл, рейз, фолд — это просчет Expected Value. EV, если на пальцах. Без магии:
EV = (вероятность выигрыша × сумма выигрыша) — (вероятность проигрыша × сумма проигрыша)
А в IT, думаете, иначе? Да та же история, только мы обзываем это ROI и ходим кругами, делаем вид, что тут у нас особенный случай. Ладно, приведу вам пример, который я лично наблюдал, наверное, раз двадцать, если не больше.
Руководство хочет фичу. Стоимость — 30 тысяч долларов. Вероятность того, что она «взлетит» — 20%, а если взлетит — принесет 100 тысяч. Звучит заманчиво? Еще бы. А теперь достаем калькулятор, и — здравствуйте:
(0.20 × $100,000) — (0.80 × $30,000) = $20,000 — $24,000 = -$4,000
Минус. Чистый, некрашеный минус. Отрицательное ожидание. И ведь сколько раз я сам себя ловил на мысли: «ну, может, в этот раз повезет, и формула ошибается». Это не риск-менеджмент, это лудомания чистой воды. И да, я сам так ошибался, чего уж там. Не горжусь, но это часть моего багажа.
Про диапазоны, чтоб их
В покере вы понятия не имеете, что у соперника в руках. Но вы его читаете по манере ставить, по паузам, по тому, как он нервно крутит фишку. Вы не приписываете ему одну конкретную руку — вы закладываете его в диапазон. Набор возможных вариантов.
В IT вы тоже никогда не владеете всей полнотой картины. «Стабильные требования» — это оксюморон, скажу я вам. Технологии меняются резвее, чем заказчик успевает договорить свою мысль. Архитектура, которая казалась монолитной и несокрушимой, может рухнуть при первом же наплыве юзеров, даже не успев понюхать продакшн.
Вот как я это вижу:
· Префлоп — это Discovery и архитектура. Информации — ноль. Рисков — выше крыши.
· Флоп — ваш MVP, первый релиз. Появляются реальные данные от пользователей, туман потихоньку рассеивается.
· Терн и ривер — это уже production и поддержка. Все как на ладони: баги, архитектурные огрехи, которые вы закладывали в спешке.
Кстати, для себя я вынес жесткое правило лет десять назад: никогда, слышите, никогда не принимайте решений, исходя из идеального сценария. Только через призму «диапазона» исходов. И всегда — я настаиваю — имейте план Z. Не Б. Не В. А именно Z — самый дурацкий, самый гиблый вариант.
Банкролл, или почему ва-банк — это глупо
Самый крутой игрок в мире, поверьте, разорится в пух и прах, если поставит все свои деньги на один кон. Дисперсия — дама коварная, не любит, когда ей не уступают. Поэтому профи держат запас: минимум 50–100 бай-инов для своего уровня. Это не скупость — это вопрос выживания.
В IT это называется «резервный фонд» или «бюджетирование рисков». Но кто о нем помнит, когда горят сроки?
Типичная ошибка в покере: пойти ва-банк с 70% вероятностью победы. А ведь 30% проигрыша — это не какая-то мелочь, это реальный шанс остаться с пустыми карманами.
Типичная ошибка в IT: выделить 100% времени команды под жесткий дедлайн. Никакого запаса, никакого плана Б. А потом — бац! — и сервер лег. Или, не дай бог, ведущий разработчик ушел в другую компанию. Или API интеграторов внезапно изменили, и все полетело к чертям.
Итог один — проект в яме, заказчик в истерике, команда в стрессе. Я такое видел — и не раз. И каждый раз я ловил себя на одной и той же мысли: «ну почему, почему мы не заложили хотя бы двадцать процентов буфера?»
Оценка по результату — это ловушка для наивных
В покере есть понятие «кулер». Ситуация, когда вы сделали все идеально. Математика была на вашей стороне. Но на ривере приходит карта, которая убивает вашу комбинацию. Вы проиграли. Но решение-то было верным! Просто случайность.
В IT мы постоянно попадаем в эту же западню — оцениваем качество управления по конечному результату.
Проект вдруг выстрелил, хотя код был — жесть, тестирования не было и в помине, а риски даже не рассматривали. Менеджер — гений! (В покере такое называют «рыбе доехало», но вслух обычно не говорят.)
Другой случай: проект провалился из-за внешних факторов. Apple поменяла правила, например. Или рынок резко упал. Хотя архитектура была великолепна, риски митигировались по всем правилам. Команда — некомпетентна?
Ерунда. Подход профессионала: оценивать процесс, а не результат отдельной итерации. Хорошо отлаженный процесс на длинной дистанции — он всегда переиграет дисперсию. Я не верю в это — я знаю это по статистике.
Четыре стратегии, которые работают и там, и там
Вспомните выбор в покере:
· Фолд (Пас) — избегание риска. Видите мутные требования, старый легаси, который боязно трогать? Скажите «нет». Потеряете немного на аналитике — сохраните бешеные деньги на разработке.
· Колл — принятие риска. Риск есть, но цена входа приемлема. Ладно, заходим, закладываем буфер, двигаемся дальше.
· Бет / Рейз — агрессивное управление. Перехватываете инициативу. Заранее пишете тесты, проводите нагрузку, рефакторите узкие места до того, как они упадут. Вы не ждете хабраэффекта — вы его опережаете.
· Чек — не путать с пасом. Вы просто наблюдаете, экономите ресурсы, ждете более четких сигналов.
Техники из покера, которые уже живут в IT
Слышали про Planning Poker? Это не просто смешное название. Это рабочий инструмент оценки в Agile. Каждый член команды показывает карту с оценкой по Фибоначчи. Те, у кого цифры разошлись, объясняют свою логику. Команда обсуждает и приходит к общему знаменателю.
В чем секрет? Метод убивает «эффект привязки» — когда первое же число, прозвучавшее вслух, неосознанно давит на всех остальных. Когда карты открываются одновременно — каждый думает сам. Исследования, кстати, подтверждают: оценки выходят точнее и менее оптимистичными, а значит — реалистичнее.
Есть еще Protection Poker — для оценки рисков безопасности. Оцениваете два параметра: ценность актива и его уязвимость. Перемножаете — получаете риск. Просто, наглядно, без скучных таблиц. Работает.
Тильт, выгорание и все, что болит
В покере «тильт» — это когда эмоции перекрывают разум. Игрок начинает творить дичь, сливает деньги, а потом пытается отыграться и сливает еще больше.
В IT это называют выгоранием. Или «решением на эмоциях». Когда менеджер в панике перекраивает требования на финальной стадии. Когда разработчик пишет код ночами, потому что «нужно успеть». Когда команда принимает решения не головой, а усталостью.
И знаете, что меня всегда поражало? Это самая дорогая ошибка в обеих играх.
Кто-то умный сказал: «В покере люди проигрывают не из-за плохой карты, а когда отказываются сбрасывать карты». В IT — та же песня. Самый затратный проект — тот, который продолжают финансировать, хотя уже понятно, что он с треском провалится.
Признать ошибку — это нормально, а не стыдно
В покере принято разбирать раздачи. Анализировать косяки. Прямо говорить: «да, мне не повезло» или «да, я просчитался, лоханулся».
В корпоративной среде, особенно в больших конторах, признавать провалы страшно. Очень страшно. Потому что премия, репутация, «а что скажет начальник». Это убивает любую здоровую обратную связь.
Но именно среда, где можно обсуждать риски без страха наказания — психологическая безопасность, если хотите, — вот она, база нормального риск-менеджмента. Мне довелось работать и там, где ошибки замалчивали, и там, где их спокойно разбирали. Разница — как между сумерками и ясным днем.
И что же в сухом остатке?
Гарантий нет. В сложных системах — тем более.
Есть только управление вероятностями.
Считайте EV до того, как пишете код. Сужайте неопределенность через MVP и прототипы. Никогда не ставьте весь бюджет на одну фичу, одну технологию, одно решение. Оценивайте качество процесса, а не отдельную раздачу.
И, если вам вдруг кажется, что IT — это не покер, а нечто более серьезное и ответственное… перечитайте этот текст. Или, на худой конец, сходите сыграйте в «дурака». Хотя бы для эксперимента.
P.S. Это только разминка
Если вы осилили этот текст до конца — значит, тема вас зацепила, и это здорово.
Потому что, по сути, мы только лизнули поверхность. Открыли дверь, а за ней — целый коридор комнат. В следующих материалах я хочу разобрать каждую тему куда глубже:
· Как именно считать EV в живых, реальных проектах, а не на абстрактных цифрах. С шаблонами, калькуляторами и разбором реальных косяков.
· Как работать с неопределенностью на практике, сужать эти проклятые диапазоны и не бояться признавать, что ты чего-то не знаешь.
· Банкролл-стратегия на примерах: сколько закладывать в резерв, как этот резерв «продать» начальству и когда вообще наступает момент выхода из игры.
· Тильт, выгорание и где грань между страстью и саморазрушением.
· Покерные техники — Planning Poker, Protection Poker и другие игры, которые работают не в теории, а в реальных живых командах.
В общем, мы только разогреваемся. Если не хотите пропустить следующее — подписывайтесь, добавляйте в закладки, следите за обновлениями. И, кстати, я всегда рад диалогу. Пишите в комментариях, что для вас самое больное, — может быть, именно это я и разберу в первую очередь.
А пока — до встречи за следующим столом. Сдавайте карты. Или, в вашем случае, открывайте следующий спринт.
ссылка на оригинал статьи https://habr.com/ru/articles/1065166/