Выстраивание производственных процессов — распространенная боль в IT-разработке. Это большая и комплексная задача, с которой неизбежно приходится сталкиваться на проектах, чтобы доставить фичу в срок. Однозначного и единственно правильного решения здесь нет. Зато есть множество маркеров: кранчи, выгорание, фичекат, — указывающих на то, что что-то вы все-таки делаете не так.
Изменение воркфлоу — процесс, способный растянуться не на один год, и, конечно, не обойдется без собственных набитых шишек. Ниже я расскажу об опыте команды War Robots: с чего мы когда-то начинали и каких результатов добились сейчас. И, поверьте, для нас это того стоило.
Модули. Как это было
Три года назад я присоединилась к команде War Robots — как раз в самый разгар разработки нового крупного монетизационного слоя игры, «Модулей». Дизайн фичи был амбициозным: нужно было реализовать ее поддержку в мете игры, а также выпустить порядка 12 новых единиц контента с уникальными механиками. Разработка такой фичи от концепта до релиза может занимать от 4 до 6 месяцев. Бизнес рассчитывал на ее быстрый выход в прод, так что нам нужно было хорошенько постараться и ускорить и без того интенсивные темпы, чтобы успеть к запланированной дате релиза.
Фича вышла в прод в назначенный срок. Казалось, что теперь можно расслабиться, забыть все как страшный сон и радоваться тому, как хорошо фича перформит. Но душа требовала изменений — тем более, что планы на следующий год были еще более амбициозные. И хотя по итогу команда сработала достойно, очевидно, нужно было что-то менять.
Проанализировав «со стороны» процесс работы над «Модулями», я подметила для себя следующее — думаю, каждый из вас замечал подобное и у себя на проектах:
Нас заливало постоянными и неконтролируемыми изменения (добросами) в дизайне фичи. В работе рождались новые идеи и допилы. Мы брались за все изменения без какого-либо анализа, не спрашивали себя: «А нам действительно это нужно для первого релиза фичи?»
Мы забывали обновлять документацию, а потому не вся команда была в курсе последних изменений. Из-за постоянных правок мы забывали актуализировать ГДД. И тут речь идет не про мелочи, а про важные концептуальные изменения в дизайне. К середине разработки мало кто понимал, как все должно выглядеть в финале.
Мы двигали фичу из релиза в релиз, потому что не были готовы. Тут наложилось много факторов, и это было лишь очевидным следствием вышеперечисленных проблем.
На статусах было мало конструктива в обсуждениях — или, по-простому, обычно все сводилось к тому, что «фича — говно». Мы искали виноватых в происходящем, каждый винил соседа.
Сюда же можно добавить овертаймы, расширение команды и т. д. Иными словами, типичные проблемы продакшена.
Пилоты. Изменения: итерация 1
Я не любитель внедрять сразу сложные и комплексные решения. Поэтому начала с небольших и быстрых правок, эффективность которых можно сразу же оценить и в случае успеха докручивать дальше.
По плану у нас шла фича «Пилоты», с которой и началось изменение воркфлоу. Сформировался следующий план:
Дизайн фичи оцениваем всей командой, определяем must-have часть для релиза. Это позволяет высказаться и поучаствовать в дизайне каждому участнику, задать вопрос и получить на него ответ. Цель на данном этапе: команда должна согласиться с концепцией и дизайном фичи и вместе пойти на следующий этап разработки. Это позволяет избежать в будущем конфликтов внутри команды на тему того, что мы делаем не то или не так, что дизайн придумали плохой или что фича вообще не зайдет игрокам. Вдобавок, обсуждение на ранних этапах позволяет утрясти вопрос дороговизны разработки и прикинуть возможные варианты реализации сложных моментов. Тут мы не жалели времени: важно, чтобы команда смогла проговорить все беспокоящие вопросы совместно, определиться с must-have частью для релиза фичи.
Сравниваем capacity команды и complexity фичи по расписанным задачам = фичекат. Обычно ГД хотят много и красиво, но позволить в разработке мы можем намного меньше, а бизнес хочет как можно раньше. У меня не было на руках никакой статистики по работе команды, поэтому на тот момент я заложила стандартные 20% рисков + отпуска + больничные. Пришлось пойти на фичекат. Первые разы — это было больно.
Обсуждаем все изменения в дизайне фичи в открытых Slack-каналах/на синках и не забываем обновлять документ. Не только в самом начале, но и с каждой новой идеей мы стали задавать себе вопрос: это must-have для первого релиза фичи или может подождать? Все доработки, не проходившие этот тест, сразу же уезжали дальше. Это позволило нам фильтровать поток идей и отдавать приоритет самым важным и критичным изменениям в дизайне.
Ставим индикацию на все новые задачи после старта активной фазы разработки. В нашем случае мы ставили Labels на тикетах в Jirа. Например, если мы забыли декомпозировать какие-то задачи по ГДД, задачу помечали лейблом DEV.
ВАЖНО: тут нужно понимать, что эти лейблы нужны для ретроспективного анализа: можем ли мы улучшить какие-то процессы, чтобы минимизировать наши изменения в будущем? А не для того, чтобы по факту релиза фичи ругать отделы за их добросы.
Пилоты. Результаты итерации 1
Мы зарелизили «Пилотов» с первыми правками в процессах, но по итогам нам все еще было над чем подумать. Данные я собирала из разных источников, иногда — практически руками из Jira и чатов, а потом все заносила в Excel. И получила следующее.
Во-первых, оказалось, что мы хотим по дизайну очень много, а времени на разработку у нас мало. На «Пилотах» уже на стадии обсуждений дизайна мы сразу отсекли дорогостоящую реализацию и функционал, который не являлся must-have для первой итерации.
Во-вторых, стало понятно, что нам не хватает 20% рисков. Разброс цифр удивил: по факту, нам нужно закладывать от 33% до 60% рисков в зависимости от направления.
Мы были слишком оптимистичны, поэтому с этой фичей нам все еще пришлось овертаймить и увеличивать количество людей в команде. Но — нам удалось выкатить фичу в нужный релиз!
В-третьих, мы стали брать в разработку действительно важные must-have изменения, без которых не мог случиться релиз. Как следствие, атмосфера в команде немного наладилась, появился конструктив в обсуждениях.
В-четвертых, мы провели анализ всех новых задач в фиче, и оказалось, что увеличение скоупа происходит не только за счет изменений дизайна фичи: есть и технические задачи, и не декомпозированные задачи по ГДД. Например, стало понятно, что мы забываем вовремя сходить в отдел саппорта, чтобы обсудить с ними реализацию, или в отдел аналитики, чтобы договориться о реализации продуктовых метрик. Эти знания мы учли на следующих фичах.
Наши best practices. Итерации N+1
И все же положительная динамика была, и это было круто. Но в то же время было очевидно, что нужно продолжать анализировать, что и как мы делаем, и вносить новые изменения. Мы прошли N+1 итерацию изменений и вывели из них несколько важных для себя правил:
Собираем всю команду для обсуждения фичи как можно раньше. Появился концепт — значит, пришло время формировать команду из лидов. Мы обсуждаем не только дизайн фичи, но и определяем MVP для релиза, разбираемся со сложными и трудозатратными кусками функционала, ищем альтернативные варианты решений.
Оцениваем фичу на стадии концепта. Мы даем «черновые» оценки фичи (это неточные оценки на базе концепта, а не полностью расписанной документации). Мы понимаем, что погрешность оценки может быть высокой, но засчет экспертизы лидов мы все равно на раннем этапе отказываемся от действительного больших и дорогостоящих кусков функционала.
Делаем UI-прототипы и прототипы кор-механик фичи. Эта практика была у нас давно, но прибегали к ней мы только в определенных случаях. Теперь же на крупных фичах мы этот шаг не пропускаем никогда. Это позволяет избежать больших изменений в мете или кор-механике фичи на позднем этапе. Чем ближе к релизу, тем сложнее переобуваться.
Обязательно делаем расчет capacity команды (с учетом процента рисков, отпусков и потенциальных больничных) и сравниваем с complexity фичи. Если эти два числа не сходятся, обязательно проводим фичекат.
Забираем в добросах только те изменения, которые относятся к категории must-have. На этом этапе мы обязательно снова проверяем: умещаемся ли мы в нужную дату готовности фичи? И при необходимости сразу договариваемся о новой дате релиза.
Собираем статистику по работе команды из любых доступных источников. От менее полезной статистики мы отказываемся, для наиболее показательной делаем автоматизированный сбор и анализ. Для сбора и хранения данных мы выбрали Jira, а для дальнейшего анализа и визуализации — Tableau.
Что можно выделить полезного из нашей статистики:
процент фичеката относительно общей стоимости фичи — то есть, процент задач (сумма оценок), которые мы решили не брать в работу по итогу сравнения capacity команды и complexity фичи;
процент доброса относительно общей стоимости фичи — это все новые задачи, которые появились после декомпозиции задач и старта активной разработки фичи;
типизацию добросов по проблематике и дальнейший анализ.
И, возможно, самое главное — атмосфера в команде. Вся команда должна идти к общему результату и помогать друг другу на пути к цели. Настрой команды зависит от каждого ее участника, в том числе от ПМ и продюсера. Если мы все — про результат и дальнейшие улучшения, мы сумеем поблагодарить соседа за крутую совместную работу, а также провести анализ своих слабых сторон, которые являются для нас точкой роста и делают нас еще круче.
Титаны, Дроны, Орбитальная поддержка. Результаты итерации N+1
Пользуясь этими правилами, в 2019 году мы взяли в работу фичу «Титаны», годом позже — «Дроны». Совсем недавно у нас прошел релиз очередной крупной фичи «Орбитальная поддержка», где мы получили максимальные результаты.
Теперь в цифрах — что изменилось в процессах за прошедшие пару лет?
Мы сократили фичекат с 30-45% до 4-10%. Плотный контакт команды на раннем этапе позволяет убрать дорогостоящий функционал. Один из запоминающихся фичекатов мы провели на «Титанах»: процесс проходил очень болезненно, все анимации и красивости отрывали от сердца. Нам пришлось отказаться примерно от 45% фичи только по разработке, а были еще отделы UI/UX и ГД. Вслед за ними шла фича «Дроны», и там мы уже отказались от 15-25% функционала. В этом году выпустили фичу «Орбитальная поддержка», где отказались от реализации всего 4-10% фичи в зависимости от направления.
Мы сократили риски с 35-60% до 15-30% в зависимости от направления. Мы попадаем в нужный релиз, перестали овертаймить и расширять команду. Для нас текущая цифра выглядит приемлемой: сейчас мы отпускаем человека в отпуск безболезненно для реализации фичи, при этом остаемся достаточно гибкими и готовы брать в работу действительно важные изменения в дизайне. У нас нет цели сделать эту цифру совсем нулевой: мы понимаем, что это невозможно, да и хочется оставить место для маневра на случай важных изменений. Для удобства команды мы лишь прикрутили автоматическую нотификацию в Slack-канал по фиче при создании новых задач на доработки в эпике.
Мы концентрируемся на совместной конструктивной работе над фичей. В команде перестали искать виноватого и кидаться друг в друга упреками, мы сконцентрированы на поиске оптимального пути реализации и анализе проделанной работы. И, как показывает опрос, сама команда не видит в коммуникациях никаких проблем:
И just for fun: чтобы разбавить обстановку, проводим Health Check команды в онлайн-формате с гифками, чтобы убедиться, что команда не выгорела в ходе работы:
Конечно, нам еще есть над чем работать дальше, ведь эта гонка улучшения процессов может быть бесконечной. Тем не менее, результат налицо: работа становится более эффективной, и это видно как по цифрам, так и по общему настрою команды.
А какие изменения в процессы вводите вы в своих студиях и каких результатов достигаете? Давайте обсудим.