Выстраивание производственных процессов — распространенная боль в 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 команды в онлайн-формате с гифками, чтобы убедиться, что команда не выгорела в ходе работы:
Конечно, нам еще есть над чем работать дальше, ведь эта гонка улучшения процессов может быть бесконечной. Тем не менее, результат налицо: работа становится более эффективной, и это видно как по цифрам, так и по общему настрою команды.
А какие изменения в процессы вводите вы в своих студиях и каких результатов достигаете? Давайте обсудим.
Комментарии (15)
awfun
16.10.2021 03:24+1Привет бывшим коллегам,
>Обсуждаем все изменения в дизайне фичи в открытых Slack-каналах
На текущем проекте тоже пришли к тому что любой диалог, требующий координации больше чем двух сотрудников, должен обсуждаться в соответствующем общем чате. Это особенно актуально во время удаленной работы.
yanavinokurova Автор
18.10.2021 17:08Привет))
Плюсую) удаленка прям подтолкнула вести общение максимально открыто на всех... теперь не получится услышать новости на кухне во время обеда) Слак стал практически всем миром))))
x0rHamster
16.10.2021 20:04Расскажите подробней про Capacity и Complexity
На основе чего вы рассчитываете Capacity команды? Вы ведете time sheets или что-то более простое для учета времени, потраченного на задачи? Просто считаете количество задач (тогда как вы суммируете задачи разных размеров)? Заранее оцениваете в "не-временнЫх" единицах вроде "берем идеальную задачу и сравниваем остальные с ней - такая же, дольше, проще" или "прогноза подводных камней - просто, нужно подумать, вообще не понятно" (а есть переоценка во время work in progress)?
Как вы измеряете Complexity? Эти единицы можно складывать? Как они сопоставляются с Capacity?
yanavinokurova Автор
18.10.2021 17:44Как считаем Complexity - это сумма Оценок задач в Эпике. Задачи мы оцениваем в Story Point. Оценку дает команда разработки целиком (у нас есть разбиение на клиентских и серверных разработчиков, они оценивают по-отдельности) через Покер планирование. Так сложилось, что 0.5SP у нас выливается в 1 день разработки, 1SP - 1.5-2 дня, 2 SP - 4-5 дней (сейчас меня могут закидать помидорами, потому что SP как бы низя переводить в дни, но мы так делаем))). Есть важное правило - мы не берем в работу задачи с оценкой больше чем в 2 SP, т.к. это как черный ящик, поэтому мы инвестируем доп. время на этапе расписания на проведение RnD, чтобы дать более точные оценки и декомпозировать задачу. Лучше это делать в самом начале, чем в середине разработки понять, что там скрылся рефакторинг на 10SP. Периодически мы проверяем, попадаем ли мы в оценки - через данные в Jira + сравниваем успели мы сделать планируемый скоуп к нужному времени или нет))
Как считаем Capacity - закладываем, что за 2 недели мы делаем 5 Story Point (эта цифра взята из практики, а не из головы). Мы учитываем, в какую дату сможет подключиться каждый из разработчиков, закладываем на каждого разработчика время на отпуск + возможный больничный + риски на возможные изменения в скоупе фичи (это число мы как раз рассчитываем).Оба числа просто сравниваются и если Complexity>Capacity, то из фичи убираются задачи пока Complexity и Capacity не станут равным.
x0rHamster
18.10.2021 20:24Спасибо! Хотя я еще вопросов принес :)
Наверняка у вас встречаются ситуации, когда одна задача становится заблокированой на некоторое время (нужно чего-то дождаться, отвлечься на срочное - да тот же отгул на день). Вы как-то учитываете это при проверках "попадаем в оценки или нет"? Сколько суммарно времени может уходить на "задача в работе, но не делается"?
Как много у вас задач-прилетов "все в огне, нужно сделать вчера", не связанных с бэклогом итерации? Какое соотношение между ними и выявленными "подводными камнями" задач в работе, без которых не запуститься?
Также кажется, что у найденного подводного камня есть две судьбы - либо без него вообще нельзя, и на задачу будет потрачено больше времени (и это вы не только закладываете заранее, но и проверяете впоследствии), либо это "можно отложить". Вопрос - есть ли у вас в бэклоге такие фиче- и технические долги? Как вы их приоритизируете относительно новых фич-реквестов, по какому принципу набираете в бэклог итерации?
И есть ли у вас какие-нибудь best practicies и прочие трюки, чтобы сформулировать Definition of Done, с которым все (разработчики и стейкхолдеры) будут иметь в виду одно и то же? (что также должно минимизировать расхождение между прогнозируемой сложностью и фактическими затратами, ведь nice to have, который не подразумевался заранее, можно с чистой совестью отложить или даже выкинуть)
yanavinokurova Автор
20.10.2021 12:46Да, конечно, учитываем. Если человек уходит в отпуск/отгул/заболел, то такие кейсы учитываются в нашем изначальном Capacity команды еще перед стартом разработки, поэтому это не должно сказываться на финальной дате. Если это что-то незапланированное, то у нас всегда есть запас из % рисков. Если уже что-то сверху, мы рассчитываем оставшееся Capacity команды и оставшееся Complexity фичи и снова их сравнивать, главное понимать - сколько будет простаивать задача.
“Сколько суммарно времени может уходить на “задача в работе, но не делается“? ” - тут не совсем поняла вопрос, можешь раскрыть?В нашем случае - крупной фичей занимается выделенная команда, мы ее не трогаем совсем и тут могут быть только изменение дизайна/незапланированный рефакторинг/забытый функционал . Но при этом у нас есть еще часть людей , кто может заниматься залетными задачами или другими менее крупными фичами и вот тут мы можем стопать работу менее приоритетной фичи и давать что-то критичное.
Задачи-прилеты - это всегда вопрос приоритетов для бизнеса. Тут должен задаваться только 1 вопрос - Что для нас важнее на текущий момент? Продюсер/Product Owner должен делать выбор. Сделать сразу 2 задачи и при этом не изменить срок готовности или не увеличить состав команды - так не получится) Поэтому для нас залетные задачи - это только те, что могут полностью заблокировать работу игры на проде. Например, упали серваки - естественно, это становится приоритетом №1 в работе команды.Технический долг, естественно, есть) Каждый спринт мы выделяем у команды разработки 5%-10% их времени на техдолг (это просто волевое решение)). Если есть что-то крупное и важное, что требует длительной активной разработки, то мы выделяем прям как фичу и эта фича лежит в нашем продуктовом бэклоге и у нее есть ценность для бизнеса в том числе. Мы понимаем, что забить на техдолг нельзя... иначе продукту в определенный момент будет очень плохо)
У нас нет внешних стейкхолдеров, только заказчик в лице Продюсера или Геймдизайре, которые находятся внутри команды. Пока мы обходимся без формализованного процесса составления DoD. Но нам помогает быть на одной волне - хорошая атмосфера в команде, плотный контакт и нацеленность на единый результат. Все друг другу помогают, готовы ответить на вопросы. Мы часто показываем промежуточные результаты работы и даем фидбэк. В условиях удаленки - обязательно нужны общие синки (обсуждайте вместе все проблемы и задавайте вопросы), максимальная открытость в переписке в каналах (команде должно быть комфортно высказывать свое мнение. привлекайте в обсуждения людей). Пока мы обходимся без формализованного процесса составления DoD
x0rHamster
20.10.2021 20:501. Кажется, я замудрил с вопросом, поэтому позволь переобуться на ходу. Как именно вы проверяете, попадаете вы в оценки или нет? Если используете реально затраченное время - откуда его берете и как обеспечиваете его адекватность?
Немного контекста моего интереса. У нас есть проблемы а-ля "недожарили задачу, а стейкхолдеры не могут ответить прямщаз" и "делали задачку, и вдруг прод загорелся - отвлеклись на 2-3 дня". Мы пытались помечать unexpected-задачи, чтобы на основе статистики понять процент рисков для такой же "закладки" и отработать их причины - вышло по-бюрократически муторно и не очень точно ¯\_(ツ)_/¯ Например, мы забываем двигать или тегать карточки, таск-трекер не считает, сколько времени задача была в статусе "заблокировано", ну и ситуации бывают куда гибче и хитрее этих ваших процессов и инструментов :)
4. Я не могу не спросить. Бывает такое, что в стремлении сделать как можно лучше разработчики слишком увлекаются "игрой со шрифтами" и в итоге продалбывают какой-нибудь важный кусочек функциональности?
yanavinokurova Автор
25.10.2021 15:09Отвечу по-частям:
1.1 Сбор статистики - в трекинга всегда грязные данные и их чистить очень сложно. Из Jira я беру только те данные, которые можно быстро почистить. Смена статусов с большой командой - это очень сложно и жестко контролировать точно не получить (будете контролировать - будет гнев команды на вас)) не стоит заставлять)
Если хотите оценить попадаете ли вы в оценку, то смотрите на больших цифрах.... Предположим, у вас делает 1 итерации весом 50SP всего 1 разработчик - по времени это, например, 50 дней. Когда завершается итерация/фича - вы смотрите в целом, ваши 50SP уложились в 50 дней? Если +/- да, значит в целом всё норм, если 50SP вы сделали за 100 дней - то тут уже явно всё плохо, значит нужно углубляться в детали. Обычно я смотрю меридиану потраченного времени для разных весов задач - 0.5SP/ 1SP/ 2SP/ 3SP. Именно так мы нашли, что задачи на 3SP всегда занимают разное время - от 0.5 дня до 2х недель, поэтому от такого веса мы отказались и декомпозируем.
1.2. Unexpected-задачи - в моем понимании, это задачи с приоритетом Блокер (т.е. важнее текущая фича и прод без этой задачи просто развалиться) + это всегда неожиданная хрень (для нас, например, это выход idfa - это внешний фактор) + повлиять на появление таких задач практически невозможно. Но тут нужно понимать:
- если вы постоянно встречаетесь с одной и той же проблемой “прод загорелся ” - это уже не unexpected-задача (при этом причины в проблем прода могут быть всегда разные). Значит, нужно системно бороться с этой проблемой, т.е. выделять время разработки на фиксы (это нужно еще уметь продать вашему product owner, но зачастую продуктовики сами заинтересованы в стабильности своего продукта). Если выделить время на системное решение проблемы не получается, то просто увеличивайте риски при разработке основной итерации. Прям считайте, сколько примерно в среднем времени (не пытайтесь оценить точно ... это тут не нужно) вы тратите каждый раз на тушение пожаров и это время закладывайте в риски.
- если всё-таки всё, что прилетает это действительно unexpected-задача - то просто закладывайте в риски. Вы не сможете это контролировать факт появления, только вы можете митигировать эту потенциальную проблему, например, заложив это в риски разработки.
1.3 Заблокированные задачи - нужно понимать частоту появлений и кто-кого блочит. Если это внутри команды - попробуйте на раннем этапе проставить зависимости между задачами, на статусах обсуждать заранее - кто и кого может заблочить по работе и у кого какие планы (тут снова должны быть хорошие коммуникации у команды). Если блокеры со стороны внешних стейкхолдеров и к ним копиться всегда много вопросов - то стоит налаживать контакт с ними... не могут ответить в моменте , значит организуйте чаще с ними мини-созвоны, где можно будет обсудить все вопросы. Если постоянно возникают вопросы, которые можно было задать и на раннем этапе - то пробуйте выделять больше времени при декомпозиции фичи. Это уже проблема не в том, что стейкхолдеры не отвечают, а в том, что разработка не детально расписывает задачи.Да, такое бывает) Нам помогают синки. Лид/ПМ видит, что человек уже 2 дня делает одну задачу и застрял на одном месте, а должен был уже сдавать в куа - значит, стоит туда капнуть и узнать в чем затык) Возможно человек просто не знает как решить задачку и ему нужна просто помощь) ну или он чем-то увлекся)
x0rHamster
25.10.2021 17:51Обычно я смотрю меридиану потраченного времени для разных весов задач - 0.5SP/ 1SP/ 2SP/ 3SP
Если я правильно понял, то речь идет о медиане, она же 50th percentile. Физический смысл - "половина задач будет сделана за это или меньшее время". Вам достаточно того, что вы прогнозируете только половину задач? Или вы (вообще кто-то кроме тебя ходит на эти экраны Jira?) проверяете и другие характеристики распределения? Боюсь, я не настолько дружу со статистикой, чтобы что-то предполагать...
yanavinokurova Автор
25.10.2021 19:11Да, речь про медиану) Значение - половина значений находится ниже этого значения, а другая половина находится выше этого значения. Кроме самого значения медианы , важна плотность распределения задач относительно медианы + правильно построенная выборка. Грубо говорят, если бОльшая часть задач находит близко к медиане, то значит оцениваем норм. Если нет и разброс очень большой, то возможно тут проблема и стоит покопать. Очень грубый пример -
1day , 1.5d, 1.9d, 2.1d, 2.2d, 2.3d, 2.5d - распределение норм
1d , 1.5d, 1.9d, 2.1d, 3d, 6d, 9d - распределение не норм
Невозможно найти какую-то одну единственную статистику , которая покажется вам - всё хорошо или всё плохо, к сожалению. Поэтому смотрим кучу разных разрезов и каждая из них может дать сигнал в совершенно разных ситуациях. Пробуйте разные и не бойтесь грязных данных, даже они могут быть показательны. главное, делать это регулярно.x0rHamster
26.10.2021 08:20Большое спасибо за ответы! Кажется, одно это обсуждение уже тянет на еще одну статью :)
Caraul
А аналитика у вас нет? Бизнес-идеи вбрасываются непосредственно в разработку?
yanavinokurova Автор
У нас есть аналитики, но они продуктовые и сфокусированы на метриках продукта.
Про идеи - тут нужно понимать, что допилы/добросы могут быть как по дизайну, так и технические. Изменение дизайна сначала обсуждались Гейм Дизайнерами (+ иногда с привлечением Продюсера/Аналитиков или других отделов) и потом вкидывались непосредственно в команду. Технические задачи генерит сама команда разработки (например, сделать рефакторинг). Зачастую и те, и другие изменения не являются критичными для первого релиза фичи, поэтому их всегда можно отложить на будущее.
Caraul
Забыл поворчать в пятницу - поворчу сейчас. Вы все сделали совершенно правильно, вот только такие статьи - не обижайтесь, сам хожу по этим граблям - напоминают построение велосипедов. Методологии построения работы, лучшие практики и пр. давно уже разработаны и описаны, осталось их применять (где-то допиливая по месту). У вас есть системные аналитики, просто по факту их роль играет разработка. Соответственно, все, что Вы сделали - заставили разработчиков эту роль правильно играть. И вот когда они стали фильтровать все входящие свистелки и хотелки, обсуждать их с соседскими командами, смотреть на объявленные ранее сроки и т.д. - а это все как раз работа системного аналитика - "Вот тут-то мне карта и попёрла!". И да, если документация идет как часть выходных артефактов, то и время на нее должно закладываться, как и на прочую работу.
yanavinokurova Автор
Да, мы, безусловно, берем в основу известные методологии разработки - куда без этого) Но реализация этих методологий на практике всегда разная. Зачастую все команды встречаются с одинаковыми проблемы, но решение у всех своё. Не зря же на Ретро поднимаются и обсуждают сложные кейсы. Команда вправе сама решать - как им изменять и улучшать процессы... и это нормально. Поэтому у всех свой прекрасный велосипед , который в основе имеет один и тот же механизм работы (методологию)) Я пришла к выводу, что велосипеды неизбежны и одного красивого масштабного решения нет ... как только приняла это, стало намного проще в работе применять простые (но эффективные) решения. А в этой статье решила поделиться именно практикой, а не писать лекцию - какой плохой или хороший Agile/Waterfall)
Затрону еще вопрос с Системным аналитиком - считаю, что в рамках Enterprise это полезная роль, но в GameDev есть особенность работы - фича - это не бизнес-процесс, который мы автоматизируем, правим или заново выстраиваем. У нас дизайн игровых фичей, точные результаты успешности фичи мы получаем только с реальных данных, т.е. покупают игроки в игре что-то или нет) Поэтому над определением дизайна работают много людей - это и Гейм Дизайнер, Продюсер, Аналитики, отдел Монетизации и т.д. Если бы был кто-то 1 , кто точно знал - как оптимально делать, то мы бы с радостью забрали такого человека в команду) В нашем случае мы не перекладываем решение по дизайну на разработку, мы лишь обсуждаем всей командой - насколько изменение критично для нашего релиза, нам важно услышать мнение специалистов в своей сфере и взять полезный от них фидбэк)