Как в игровых студиях принимаются технические решения, когда на кону денюжки

Представьте: в игре хорошо работает фича, которая приносит деньги. Команда хочет развить её дальше и ставит себе цель. Инженер, приценившись, говорит: «Нам нужно три недели». А бизнес вставляет: «Но у нас есть только две!».

Кто из них прав?

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

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

Дисклеймер

Я работаю в геймдеве, поэтому примеры здесь будут из разработки игр. Однако сама логика применима к любому IT-продукту.

Технически правильное решение может быть неправильным

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

• Инженер говорит, что для реализации фичи надо, по-хорошему, отрефакторить существующую систему, и запрашивает 3 недели работы, иначе придётся прикручивать на костылях, а потом ещё и ноги оторвёт при следующих решениях.

• А бизнес хочет успеть к празднику, который, например, через 2 недели, чтобы, попав в тематику праздника, продать больше тематического контента.

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

Иными словами: порой технически правильное решение — не такое уж и правильное.

Бизнес и инженеры решают одну задачу

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

Время инженера стоит денег, задержка релиза стоит денег, обслуживание серверов стоит денег, и технический долг тоже в конечном счёте стоит денег.

Поэтому, когда «бизнес» просит поскорее — чаще всего на это есть весомые причины. Проволочки по срокам легко могут превратиться в финансовые проблемы, которые также быстро приводят и к развалу компаний. А кроме провалов, хочется ещё и расти: инвестировать в улучшение условий, в новые проекты и т. д.

В реальности нет одного правильного решения

В компаниях, где принято оптимизировать только один параметр, легко попасть в одну из двух крайностей:

• Сделать всё идеально. Тут уже не важно, инженерно, или визуально, или ещё как-то. Идеальность требует ошеломительных трудовых затрат (читай: ресурсов), это очень дорого. А самый большой вопрос тут: а окупятся ли усилия? Спойлер: почти всегда — не окупятся.

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

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

В реальности в коммерческой разработке редко существует одно правильное техническое решение. Обычно есть несколько вариантов с разной стоимостью, сроком, риском и последствиями. Это, наверное, важнейшая мысль всей этой статьи!

Технический долг — это кредит

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

Я бы сказал, что выражение «никогда не избавишься» близко к правде на практике. Но тут не всё так просто.

Давайте разберёмся на примере из начала статьи — фичи, которую нужно выпустить за пару недель.

Бизнес заявляет, что тематическое обновление должно привести в игру новую кровь, новые продажи: скачок доходов на период праздника и какой-то «хвост» на графиках после. За счёт этого «скачка» можно будет продолжать разработку ещё полгода и принести в игру ещё чего-то интересного. С другой стороны, можно пропустить этот праздник, не получить дополнительных доходов и выпустить качественную фичу, когда она уже никому не нужна. Возникает ситуация «пу-пу-пуу».

Бизнес слёзно просит не делать рефакторинг, а инженеры могут пойти на уступки, объявив, что согласны сделать всё на костылях, но только если выделят пару недель на исправление ситуации после.

Иными словами, можно сказать, что технический долг — это долг не инженера. Технический долг — это кредит проекта, кредит всего бизнеса. Который, к слову, не всегда и возвращать-то надо.

Я бы сказал, что технический долг стоит возвращать тогда, когда стоимость его существования становится выше стоимости погашения. В принципе, не всякий технический долг нужно погашать. Нужно понимать, какой именно долг мы взяли, зачем мы его взяли и сколько он нам будет стоить. Вспомним наш пример, чтобы понять лучше: бизнесу выгоднее взять «кредит», который, по всем правилам, нужно будет отдавать с процентами, и сделать фичу на костылях и заработать, а потом, если костыли будут действительно мешать — оплатить их двумя-тремя условными неделями разработки вместо одной. А возможно, и вовсе не заплатить, если фича окажется слабенькой для игроков и поддерживать и развивать её не будет смысла — тогда и долг возвращать не нужно. Выпиливать из проекта тогда тоже придётся, но это уже другая история.

Самый дешёвый код — тот, который не пришлось писать

Кстати, в инструментарии бизнеса и инженеров есть ещё один важный пункт — умение выкидывать. Не технический долг: сделаем плохо сейчас, доработаем потом, если будет хорошо, а выкидываем сейчас, потому что это сейчас в принципе не очень-то нужно.

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

MVP фичи (Minimum Viable Product) строится вокруг гипотезы: что мы хотим проверить этой фичой? В случае с нашим примером с тематической фичей гипотеза примерно такая: хотим сделать тематическое обновление, чтобы посмотреть, интересно ли игрокам получать тематический контент, в том числе в конкретной фиче, стоит ли развивать это направление? Правильное построение цели и гипотезы помогает откинуть много лишней работы, чтобы сократить сроки на разработку.

Ещё хочу тут подсказать инженерам, что это часть вашей ответственности — подсказывать бизнесу, как и что можно отпилить, изменить, подкрутить, чтобы сократить сроки. Потому что часто бизнес приходит к разработчику с запросом: сделай фичу А: полный фарш со свистелками, подсказками, туторами, звуками, уведомлениями за две недели, а разработчик немногословно говорит, что надо три. В этом месте вопрос превращается в конфликт: бизнес «требует» быстро, разработчик «ругается», что бизнес совсем обнаглел. Но запомните, если инженер отвечает на запрос «нам нужно за две недели» только словами «это займёт три», он выполнил только половину своей работы.

Вместо «нет» нужно приносить варианты

Вырисовывается вопрос: так как же найти общий язык и разработать хороший продукт/игру? Ответ простой — варианты.

Когда бизнес говорит, что в какой-то срок нужна фича А (кратко, но в красках описывает её), чаще всего он не понимает технической сложности её реализации от слова совсем, ну или совсем уж поверхностно, это нормально. Тут на сцену выходят исполнители, чтобы не просто сказать «нет», а:

• Объяснить, почему это сложно/невозможно, а может, всё окей и всё получится (но это сказка какая-то, так не бывает).

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

В идеале у команды должно быть хотя бы несколько рабочих вариантов. Например, три:

• Идеально — то есть проработать всё, что задумано. Самый долгий вариант.

• MVP — минимально возможная работа, чтобы закрыть цели на релиз. Самый быстрый и самый рисковый вариант.

• Компромисс — на уступки идут все, чтобы получить продукт, лучше чем MVP, в приемлемые сроки.

Теперь вопрос «кто прав?» исчезает. Инженер не спорит с бизнесом о том, можно ли сделать фичу за две недели. Он показывает, что именно можно получить за две недели и какую цену придётся за это заплатить.

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

Нужен диалог, получается.

Риски-ириски

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

Риски бывают по срокам — если разработка имеет какие-то «дыры» с неизвестными параметрами (отсутствие экспертизы, отсутствие контекста и др.), можно неправильно оценить сроки.

Есть риски потерять человеческий ресурс: отпуска, увольнения, выгорания, больничные и т. д.

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

При этом высокие риски — не значит, что это плохо. Риск сам по себе не делает решение плохим. Решение становится плохим, когда риск не был замечен или принят случайно.

Возможно, потенциальная выгода настолько большая, что с лихвой окупает все риски. Задача разработчиков — накинуть вариантов, обложить рисками, порекомендовать что-то, где-то сказать: «Вот это я очень не рекомендую, потому что X, Y и Z», а задача ответственного за продукт — принять решение, какой из вариантов и какой набор рисков компания готова принять.

Горизонты решений

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

Горизонт 1: Сейчас — что мы будем иметь на релизе, если реализовать это решение: выполнятся ли цели на этот релиз?

Горизонт 2: Следующие 3–6 месяцев — какие ограничения накладывает решение на следующие 3–6 месяцев разработки? Не добавит ли нам это существенно больше работы в следующие месяцы? А если добавит, то насколько это критично?

Горизонт 3: Дальше — какие ограничения накладывает решение в принципе на проект. Сможем ли мы дальше развивать игру/продукт, как планировали? Сколько работы добавит такое решение при внедрении новых фич в связке с этой? Сколько работы добавит скейлинг фичи? Возможен ли в принципе скейлинг фичи с таким решением? Безопасно ли оно?

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

Чеклист принятия решений

Чтобы было проще и, наверное, понятнее, я подсобрал список вопросов, ответы на которые помогут в принятии решений в разработке продукта, будь то игра или ещё что:

1. Какую бизнес-проблему мы решаем?

Если ничего не ответилось — то, возможно, ничего делать и не надо.

2. Что будет, если мы ничего не будем делать?

Проверка первого пункта: есть вероятность, что проблема надумана.

3. Что будет, если сделать максимально дешёвый вариант?

Какова цена будущего?

4. Что мы покупаем дополнительной технической работой?

Скорость? Стабильность? Масштабирование? Снижение риска?

5. Насколько мы уверены, что это вообще понадобится?

Если это эксперимент — не стоит строить прочный фундамент заранее. А если мы уверены, что фича нужна, но не уверены, в каком виде она должна работать, стоит прикинуть варианты реализации и не строить всё сразу.

6. Что можно выкинуть/сократить/изменить?

7. Какой риск мы сознательно принимаем?

Потому что нулевого риска не существует.

8. Кто принимает окончательное решение?

Исполнитель не всегда должен принимать эту ответственность на себя.

В коммерческой разработке техническая идеальность не является целью сама по себе. Цель — создать максимальную долгосрочную бизнес-ценность при приемлемой стоимости и риске.

Но и здесь есть двойное дно: долгосрочная бизнес-ценность важнее краткосрочной.

Поэтому «сделать быстро» иногда действительно является правильным решением. «Сделать идеально» тоже иногда является правильным решением.

Плохим является не компромисс. Плохим является компромисс, о цене которого никто не подумал.