Теория всей ху*йни: почему мы опаздываем
YouTube | Подкаст | Слушать

Из книг Джейсона Шрейера об игровой индустрии можно сделать одно интересное наблюдение: траектория что успешных, что неуспешных проектов, примерно одинакова. Выглядит так: начинается проект лучшей в мире игры. Там есть и караваны, и открытый мир, и классные механики, — вообще все. Начинается разработка, которая идет поначалу довольно бойко. И тут вдруг появляется призрак дедлайна: экспо, выставка и тп. Теперь начинается настоящая работа. Ближе к релизу, когда внезапно выясняется, что вместо года нам нужно 7, команда ухает в мир кранча и ночной пиццы. Чем ближе дедлайн, тем больше приходится отрывать от лучшей игры в миры. Выпуская самую обычную на свете игру, разработчики устало расползаются по отпускам и психушкам.

Эта картина повторяется из компании в компанию. Из страны в страну.

Но почему так получается? Сколько лет опыта у каждого разработчика, неужели они не могут понять, успеют ли в срок или нет? У каждого за спиной годы кранчей, соскучившиеся дети и несчастные жены. Каждый полученный опыт максимально болезненный. И все равно каждый раз одно и то же.

Теория всей ху*йни, которую я предложил в прошлом эпизоде, на самом деле предельно ясно объясняет этот феномен. Дело в том, что здесь в ход вступает временная дистанция и связанное с ней временное дисконтирование: чем дальше дата релиза, тем меньше мозг концентрируется на деталях реализации, но тем более на высокоуровневом представлении, акцентируя внимание на желаемом. Это приводит к тому, что чем дальше релиз, и чем более абстрактно мы о нем думаем, тем больше желаемых вещей мы в эту модель добавляем. Нам-то кажется, что мы занимаемся проработкой и моделированием, и это правда так. Только есть нюанс: прорабатывая абстрактную модель из высокоуровневых представлений, мы в первую очередь утрясаем эту модель в голове, уточняя набор желаний. И когда нам кажется, что мы наконец-то получили точную картину, мы ни на шаг не приблизились к прояснению продукта, как реализации этой модели, который будет строится относительно наших возможностей и ресурсов.

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

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

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

Но мне кажется, нам надо подходить к эстимациям иначе: стоит оценивать не время, а вот этот образ в голове. Отличный способ — t-shirt sizing. Так можно представлять работу в виде некоторых кубиков, а майлстоуны проекта — как коробоки, куда может поместится только определенный набор этих кубиков (если у нас скрам, то стоит взять майлстоун в десяток, например, спринтов — тут какими размерностями привыкли думать). Либо выстроить правило: одновременно команда может делать только 1 XL-задачу, 2 — L, 3 — M, 4 — S. Здесь может быть целое пространство этих вариантов.

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