Почему разработчики не сделают эту простую штуку?

Животрепещущий вопрос, не правда ли?

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

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

Как штука появляется в проекте?

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

Упрощая, каждая идея, для воплощения себя в штуке, должна пройти три этапа:

1. Формулирование — автор идеи должен описать её так, чтобы другие поняли.
2. Анализ — разработчик должен изучить идею, сложность её реализации, соотношение с реалиями проекта и его будущим, после чего сформулировать её в том виде, в каком она появится в проекте. Только после этого этапа штука попадает в какие-то стабильные планы разработки.
3. Реализация — разработчик должен реализовать идею в той форме, к которой он пришёл во время её анализа.

Вопрос «Чего ж вы уже полгода не сделаете такую простую вещь?» возникает обычно сразу после 1-ого этапа (или через полгода после него).

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

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

Как распределяется время между анализом и реализацией?

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

Штука №1 проста с точки зрения анализа, по таким решение принимается сразу при поступлении идеи. После чего она попадает в планы и разработчик всегда может ответить, что «с большой вероятностью данная штука будет сделана в версии N». Таких случаев мало.

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

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

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

Штука №3 является представителем большинства. Конечно, распределение трат времени именно 50/50 редко, но суть отражает.

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

Таким образом, чтобы фича появилась в проекте, разработчик должен:

• во-первых, потратить время на её анализ;
• во-вторых, потратить время на её реализацию.

Так в чём же проблема?

Представьте, что таких «запросов на штуку» у вас 100 (мой случай) или 1000 или 10000 (вполне реальные ситуации). И они не просто есть, каждый день появляются новые, быстрее, чем реализуются старые. Мысль всегда быстрее рук.

Если разработчик будет тратить время на анализ каждой новой идеи, чтобы дать ей чёткий порядковый номер реализации, то в результате он половину времени будет тратить на работу, которая реально потребуется через год (а может и вообще не потребуется). Реальный же прогресс по проекту замедлится, так как будет простаивать реализация актуальных задач. А раз замедлится реализация запланированных штук, то их очередь будет накапливаться ещё быстрее.

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

Что же делать?

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

Откладывание в долгий ящик

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

Группировка анализа и реализации близких фич

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

Пример: задачи по балансу игры, задачи по графике, задачи по монетизации. После группировки они сразу «забываются» пока не придёт время работы над соответствующим компонентом.

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

Исключение из анализа частных случаев

В случае, когда штуку «в общем виде» можно сделать не задумываясь (реализация очевидна или есть некие общепринятые стандарты), но её «оптимальная» реализация имеет много частных случаев, их анализ можно опустить. Мы предполагаем, что практика лучше нас покажет какой из частных случаев как делать. Обычно, большинство частных случаев не оказывают никакого влияния на продукт, а существенны только 1-2 из них. Проблема в том, что сложно предугадать какие конкретно.

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

Реализация частного случая

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

Это же относится к случаю, когда быстрее сделать, чем думать.

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

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

Чистка

По-ихнему — Feature Cut. Со временем задач накапливается всё больше и больше. Уменьшить их количество можно только двумя путями: сделав их все (что нереально) либо удалив лишние.

Хорошим поводом к удалению могут служить следующие признаки:

1. Задача стала неактуальной (развитие проекта свернуло в другую сторону).
2. Задача может быть сделана не ранее чем через большой промежуток времени (например, через год). С большой вероятностью за год в проекте и его концепции многое поменяется, поэтому исходная задача станет неактуальной.
3. Задача незначительна по своей сути (менее значительна чем 100500 других задач).

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

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

Так что же из всего этого следует?

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

Надеюсь, в следующий раз, прежде чем вопрошать: «О боги, да когда же?!» — вы вспомните, что ответ на этот вопрос далеко не прост, пожалеете меня, и, может быть, его не зададите :-)