IT и покер. Часть 2: Диапазоны вместо карт

В покере вы понятия не имеете, что у соперника в руках. Но вы его читаете по манере ставить, по паузам, по тому, как он нервно крутит фишку. Вы не приписываете ему одну конкретную руку - вы закладываете его в диапазон. Набор возможных вариантов.

В IT вы тоже никогда не владеете всей полнотой картины. «Стабильные требования» - это оксюморон, скажу я вам. Технологии меняются резвее, чем заказчик успевает договорить свою мысль. Архитектура, которая казалась монолитной и несокрушимой, может рухнуть при первом же наплыве юзеров, даже не успев понюхать продакшн.

Вот как я это вижу:

· Префлоп - это Discovery и архитектура. Информации - ноль. Рисков - выше крыши.

· Флоп - ваш MVP, первый релиз. Появляются реальные данные от пользователей, туман потихоньку рассеивается.

· Терн и ривер - это уже production и поддержка. Все как на ладони: баги, архитектурные огрехи, которые вы закладывали в спешке.

Кстати, для себя я вынес жесткое правило лет десять назад: никогда, слышите, никогда не принимайте решений, исходя из идеального сценария. Только через призму «диапазона» исходов. И всегда - я настаиваю - имейте план Z. Не Б. Не В. А именно Z - самый дурацкий, самый гиблый вариант.

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

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

Типичная ошибка в покере: пойти ва-банк с 70% вероятностью победы. А ведь 30% проигрыша - это не какая-то мелочь, это реальный шанс остаться с пустыми карманами.

Типичная ошибка в IT: выделить 100% времени команды под жесткий дедлайн. Никакого запаса, никакого плана Б. А потом - бац! - и сервер лег. Или, не дай бог, ведущий разработчик ушел в другую компанию. Или API интеграторов внезапно изменили, и все полетело к чертям.

Итог один - проект в яме, заказчик в истерике, команда в стрессе. Я такое видел - и не раз. И каждый раз я ловил себя на одной и той же мысли: «ну почему, почему мы не заложили хотя бы двадцать процентов буфера?»