БЭКЛОГ ЗАДАЧ: ОЦЕНКА И ПРИОРИТЕЗАЦИЯ

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

Бэклог

Список всех задач (Backlog) проекта, начиная от сырых идей и заканчивая хорошо декомпозированными и описанными, готовыми в работу, планами спринтов. Этот список задач, будет основным артефактом продюсера, инструментом для достижения максимальных показателей эффективности в работе над проектом.

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

Эпики и подзадачи

При планировании, возникновении идеи или бага в бэклог заносятся Эпики — корневые задачи / цели. Например в игру нужно внедрить ежедневный бонус, чтобы усилить механизмы удержания. Продюсер вписывает эпик «Добавить Дейли бонус» и собирает команду. Вместе они разбивают задачу на подзадачи. Дизайнер интерфейсов говорит, что ему надо нарисовать пару скетчей, и просит художника подготовить графику согласно стиля игры. Программист просит гейм диза расписать принципы работы, перед тем как собирать окно. Бэкэнд спрашивает на сколько много можно добавить бонусов, и нужно ли синхронизировать сбор бонусов с часовым поясом. Команда обсудила идею Дейли бонуса, и теперь её можно разбить на подзадачи. Подзадачам присваиваются метки, определяющие тип работы над задачей — программирование, графика или гейм дизайн.

• Добавить в приложение Ежедневный бонус — Epic

• написать логику — Client

• написать бэкэнд по работе дейли бонуса — Server

• подготовить конфиг балансировки бонуса — Balance

• написать документ по механике работы и расчетам балансировки дейли бонуса — Game Design

• собрать графику — Tech Design

• разработать интерфейс окна — UI

• нарисовать арт для окна — Art

• написать документацию по визуализации дейли бонуса — Game Design

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

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

Оценка задач

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

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

Я рекомендую для оценки сложности использовать «Ряд Фибочначи» — последовательность чисел, где каждая следующая равна сумме двух предыдущих: 1, 2, 3, 5, 8, 13, 21…

1. очень легко — задача, которая делается за 10-15 минут (например, перекрасить кнопку).

2. легко — задача, которая делается в пределах 1 часа. Таких задач в день можно сделать порядка 10.

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

5. сложно — задача, решение которой требует созидания, анализа. Такая задача не решается за 1-2 дня и требует подготовки.

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

13. не использую

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

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

После оценки задач Менеджер проекта может включать в состав спринта, учитывая эстимейты команды.

Определение Бизнес Ценности

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

Для оценки ценности используем тот же «Ряд Фибоначчи», умноженный на 1000, чтобы визуально отличался от оценки сложности.

Вот мои рекомендации для запущенного приложения.

21 000 — Критически важная задача — задача, которая влияет на работоспособность приложения, на его корректурную работу. Такие задачи берутся в работу в первую очередь.

13 000 — Задачи, от которых напрямую зависят финансовые показатели — например, добавление системы акций в игру, активация пей-воллов, изменение кривой сложности…

8 000 — Косвенно, влияющие на монетизацию задачи — такие, как сплит платежного меню, изменение воронки оплат…

5 000 — Задачи, на прямую влияющие на возврат пользователей, их удержания — например: прикрутка ФБ-коннекта, использование OG, и обмен подарками в игре…

3 000 — Задачи, влияющие на вовлечение пользователей — тут и графика, и анимации и звук, и прочие компоненты игры, на основании которых пользователь складывает впечатление от игры.

2 000 — Идеи, которые хотелось бы добавить в игру, но их полезность не очевидна. Тут могут быть разные мысли, вплоть до замены дракона на кошку на прелоадере.

1 000 — Очевидная чушь, которая попала в бэклог. Задачи, которые надо запомнить, чтобы не делать. Да такие тоже есть))

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

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

Расставляем приоритеты

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

• вначале в работу идут задачи с наивысшей бизнес ценность

• в работу идут задачи с наименьшей сложностью при одинаковой бизнес ценности

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

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

По-понятиям:

1. Бэклог — инструмент продюсера

2. Бэклог является открытым для каждого участника проекта.

3. Бизнес ценность задачи — это показатель, на сколько задача важна для проекта в данный момент времени. Этот показатель определяет продюсер.

4. Сложность задачи — это показатель, на сколько сложна задача, сколько ресурсов надо на ее решение. Сложность задача определяет команда.

5. Эпик — это основная задача / цель, которая оценивается по максимальной ценности и максимальной оценке сложности её подзадач.

6. Метки — определитель типа работ над задачей.

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

8. Задача — Блокер — задача, без которой, другая задача не может быть взята в работу.

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

10. материал взят http://bank-explorer.ru/optimizaciya-processov/vizualnyj-menedzhment-i-upravlenie-po-celyam.html http://progamedev.net/beklog-zadach-ocenka-i-prioritezaciya/

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