Надгробья современного геймдева. Феномен самораздувающихся сроков

Материал содержит применяемые в отрыве от современной политики именования и отсылки, а так же длинные слова, которые огорчают Винни-Пуха.

Cyberpunk 2077. Был перенесён больше, чем на полгода.
Atomic Heart. Как ждали бета-версию в конце 2019 года, так и ждём.
Escape from Tarkov. Бета-тестирование длится уже почти пять лет.
Vampire: The Masquerade – Bloodlines 2. Перенесён на бооооольше, чем два года, сильно больше…
Bayonetta 3. За прошедшее с момента первого анонса время уже можно было выпустить игру, спин-офф, тизер сиквела и начать снимать сериал для Netflix — но неееет, всё ещё ждём…
И прочие, и прочие, и прочие.

Ладно, «Побег из Таркова» и Atomic Heart: амбиции, нехватка опыта, технологическая болтанка. Допустим.
Но остальные игры — их как минимум продьюсировали видные деятели в этой сфере. Это не первое их родео в мир ААА-проектов. Что ж так не повезло то им?

А если сместить фокус с геймдева и окинуть взглядом IT в целом?
Куда ни глянь — «не попали в дедлайн», «кранч», «лучше MVP в проде, чем срыв сроков в ххх», etc, etc…

Вдобавок, две недавних публикации (о проектировании в IT в целом и о YOLO-разработке в геймдеве) напомнили мне в очередной раз о потенциальной причине этого феномена.
И имя ему — «феномен самораздувающихся сроков».

Что за феномен?

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

• Надо занять новую нишу сейчас — продукт доработаем потом, если спрос будет.

• Конкуренты слишком выбились вперёд — надо их нагнать любой ценой, а доработаем потом при случае.

• Да бахни ТЗ по-быстрому, делов то, по ходу дела разберёмся, я прикрою.

• Нет, у нас нет документации на уже проведённые по проекту работы — ты же напишешь, а мы потом по ней что-нибудь попланируем?

• Да, выбранное решение — отстой и поддерживать его будет невозможно. Но лучшего то нету, надо было делать быстро.

И так далее, и тому подобные рассуждения на тему «нет времени экономить время».

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

Предпосылка №1: диктатура пролетариата

Давным-давно в область вычислений реальных сроков воплощения проектов в IT проник… коммунизм.
Дух демонического Ленина восстал!
Но вместо наших женщин и кулацких подворий он обобществил право голоса и экспертной оценки сроков.
Story Point Poker — это он.
«Я бы смог это сделать за X времени — но %USERNAME% наверняка успеет за Y» — это тоже его учение.
Неважно, сколько времени работа займёт на самом деле, — ведь оценка времяёмкости проекта идёт не «сверху», а «снизу»!

Только вот беда — оценка «снизу» нужна разве что для того, чтобы гордо заявить: «У нас не waterfall! Мы точно планируем в спринты по твёрдым цифрам оценки!»
Но, увы, переход к пост-коммунизму в оценке задач в IT пока невозможен потому, что…

Предпосылка №2: стейк из ТЗ категории rare

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

• слишком лаконичные — «потому, что всё равно в процессе надо уточнять. Всё предусмотреть невозможно»

• слишком ёмкие — «потому, что многотекста леньчитать»

• слишком авангардные — «давайте попробуем эту методологию… упс, да её надо нам всем подучить!»

• слишком примитивные — «эээээ, а где BPMN?»

• жульены. Нет, это не ошибка, вместо стейка якобы получается жульен из ТЗ потому, что мешанина и недостаточно информационного «мяса», официант, замените блюдо…

Что характерно, если упереться рогом и НЕ делать стейк rare (или заготовить заранее и ТЗ-стейк-rare, и нормально прожареное подготовленное ТЗ с сопутствующими) — то по завершении стадии №4 «депрессия» припасённое в моей заначке сделанное «по уму» блюдо идёт очень даже неплохо… под дружное нытьё «ну зачем так подробно, только время угробил».

Да, и официант из меня, видимо, тоже плохой.
Хотя для ситуации, когда требования к блюду заведомо невыполнимы, — результат неплох.
Только к моменту, когда сделанное «по уму» ТЗ становится востребовано — планы все уже зафиксированы.
(так и запишем: демонический Ленин любит стейки rare из ТЗ)

Предпосылка №3: безумие

Здесь должна была находиться цитата из знаменитого монолога Вааса Монтенегро. Но кто заинтересован — тот её и так знает. Ведь зачем её повторять раз за разом…

Проект 1 начат, попланирован, разрабатывается, не попали в сроки, кранч, седельные корчи и красные глаза, сдали, фух.
Под настроение написали постмортем, в котором поклялись: невермор!
Берём следующий проект.

Проект 2 начат, попланирован, разрабатывается, не попали в сроки, кранч, превозмогание и морковка сзади, сдали, фух.
Под настроение написали постмортем, в котором поклялись: невермор х2!
Берём следующий проект.

Проект 3 начат, попланирован, разрабатывается, не попали в сроки, кранч, «поработай на выходных — иначе не командный игрок!», сдали, фух.
Под настроение написали постмортем, в котором поклялись: невермор х3!
И снова, и снова, и снова…

…видите паттерн?

Да, иногда случается маленькое чудо и кто-то инициирует Большое Собрание, на котором ищутся способы прервать этот порочный круг.
Но демонический Ленин не заинтересован в том, чтобы его разрывать.
Демонический Ленин заинтересован в стейке rare из ТЗ — и чего-нибудь принять. Чисто чтобы запить.

И по итогу на Большом Собрании принимается какой-нибудь комплекс мер по исследованию расширения скоупа сужения времязатрат в контексте ещё более передовых методологий ведения проектов yadda-yadda-yadda…

Но реальная проблема то не там.

Единственная методология, которая более-менее натягивается на любой проект, укладывается в три вопроса:
ЧТО делаем?
КАК делаем?
ПОЧЕМУ делаем?
Причём, прорабатывать эти вопросы детально надо уже на стадии «а не бахнуть ли нам эту фичу в Q4?»
Потому, что настанет Q4 — а что хотели, не помним, что помним, не хотим. Это раздует сроки.
Потому, что недетальная проработка ТЗ и нежелание уделить чтению/обсуждению тоже ГАРАНТИРУЕТ увеличение сроков.

Да, с одной стороны разработка — это творческая работа.
С другой стороны, есть конечное число способов адекватно сделать функционал Х — и есть конечное количество времени, за которое можно сделать функционал Х любым адекватным способом.
И уж наверняка в распоряжении команды есть ветеран, который на детальное ТЗ на функционал может выдать адекватную оценку этого самого времени + 30%.
(и потом не забыть выделить пропорциональную долю на тесты-фиксы-мелкие-поправки)
Это — МОЖНО стандартизировать и избавить себя от призрака коммунизма и его воя! И не тратить впредь на бесконечные планировательногрумерские митинги!

Звучит как ересь… поначалу. Да.
Более того, за такое пьяное откровение мне, наверное, сольют более чем скромные остатки кармы (почему-то не до конца потопленной в статье о coinкойнах).

Но подумайте вот о чём.

Предпосылка №4: разум

«Любое разумное существо стремится как можно меньше работать.» (с) Джим Статхэм

Даже если сотрудник полностью лоялен, даже если мнение его непредвзятое и 100% объективное, выдаваемая им оценка времязатрат будет дана исходя из того, сдельная предстоит работа или почасовая.
И в зависимости от этого она [выданная сотрудником оценка времязатрат] будет… отличаться! Даже при полностью идентичных прочих равных! Даже если умудриться заставить сотрудника дать оценку подсознательно, без времени на размышления!

Британские учёные (или Карл Маркс, или ещё какие-то авторитеты) наверняка успели это поисследовать — но это, в принципе, доказуемо логически без исследований, выводится из самоё природы человеческой.

А раз у нас распространена почасовая оплата труда, тооооооо?..

В детальной проработке проекта ради своевременной сдачи оказывается заинтересован никто.
(и если я попытаюсь заикнуться о том, почему ИМЕННО, — то меня точно отсюда попрут… Все всё знают — но говорить об этом не-при-ня-то)
Соответственно, текущая ситуация с залётами по срокам (что в геймдеве, что в «общем» IT), во-первых, абсолютно ожидаема (даже в силу одной только этой предпосылки, не то что всех четырёх), а во-вторых, совершенно неизбежна…

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

Но чаще либо таких дат нет, либо к дате успели, но вместо релиза выкинули MVP, который внезапно вынужден бороться с давно развившимися конкурентами, как вышло, например, в случае с Hood: Outlaws & Legends … опять…

Что с этим делать…

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

А вы?