✍️Отзыв на книгу Shape Up

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

Я изучал множество методологий менеджмента проектов, читал книжки про Agile, Scrum, даже Путь Toyota от корки до корки. Однако, планирование само по себе - исключительно индивидуальная сущность, которая "настраивается" не просто под сферу (геймдев, например), но и под каждый отдельный проект в частности. И чем больше я изучаю тему планирования, чем больше опыта набираюсь, тем больше в этом убеждаюсь. Это большая тема для дискуссии, отложим ее на потом как-нибудь, сегодня у нас всё же Shape Up.

Методология Shape Up, как по мне, подходит исключительно для уже сформированных крупных проектов, вставших на рельсы монетизации (или же поддержки для B2B), и только для проектов, в которых визуал играет последнюю роль. Я мечтал почерпнуть из книги что-то полезное, однако, получил почти ничего (нового), глядите сами. Тезисно:

- Разработка делится на т.н. "спринты". Это условные периоды, через которые нужно предоставлять рабочий билд. Обычно спринты 1-3 недели. Автор же предлагает 6 недель. За 6 недель в геймдеве может случиться воообще что угодно! Слишком много, слишком

- Планирование происходит в несколько этапов - это ок. Там в книге непривычные названия, которые можно привести к уже знакомым, например препродакшн, во время которого набрасывается идея, грубо говоря на бумаге дизайнерами (в нашем случае геймдизайнерами). Потом оформляется в какой-то визуал (макет), и обратываются "пробелы" вместе с тех командой. На это в книге уходит пара недель. Это ок, если что. Главное здесь (по версии автора) - уложиться в 6 недель производства. Если не влезает - нещадно резать

- Когда случается день Х (планирование), происходит голосование - какие фичи пойдут в работу в следующие 6 недель. Не прошло голосование - фича идет в мусорку. Даже не в бэклог. В книге это подается как плюс - не надо думать о бэклоге, однако, как я и сказал выше, данный пункт подходит к уже сформированным проектам. Для стартапов нельзя обойтись без бэклога, т.к. функционала в принципе еще не существует. В каком-то виде бэклог всё-таки должен быть.

- Если фичу не успели за 6 недель релизнуть, она отменяется. Совсем. Мол, жестко, зато не повадно будет. Потерять 6 недель работы тех команды - это очень дорого. Я уже говорил, что такое могут позволить только уже готовые продукты.

- После 6-недельного спринта идет 2х недельный "перерыв". Пока (гейм)дизайнеры собирают инфу, что же будет в следующем спринте. За эти 2 недели чинятся баги. При чем "по желанию" - имеется ввиду, какие хочешь, такие и чинишь. Странное утверждение, не правда ли? К тому же спринт получается не 6-недельный, а 8 недельный, 2 месяца. В геймдеве это майлстоун уже.

- Больше всего меня возмутила "обрезка" фич, чтобы запихнуть в 6-недельный спринт. В книге говорится, что не нужно жалеть пользователей, если им нужен функционал. Обрезать всё, что только можно, вставить уродливую полурабочую фичу и в релиз. И это правильно - для B2B решений, когда заказчику позарез нужен конкретный функционал ещё вчера. Однако, в геймдеве, где конечный пользователь очень требовательный, такое не прокатит. Функционал должен быть отполирован, интересен, визуал должен свервать и плавно двигаться, и абсолютно точно, он должен быть понятен, иначе в отзывах появится что-то около единички.

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

Но читать подобный материал нужно, конечно. А иначе как найти решения, которые уже существуют и опробовать их? Если они адекватные, конечно.

Хорошей недели!

#полезное