Оценка бизнес ценности задачи

Во второй части статьи, посвященной приоретизации проектов, мы расскажем об этапах этого процесса, а также о том, как соотнести количество одновременно исполняемых проектов с возможностями ИТ-отдела и компании.

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

Финансовая ценность проекта

Как правило, единственным и наилучшим мерилом ценности проекта является его финансовая ценность для компании. Существует много методов подсчета финансовой ценности проектов, как то: ROI, время самоокупаемости, NPV, коэффициент возврата и прочие. Независимо от того, как в той или иной компании принято измерять финансовую ценность проекта, предпочтительнее простая оценка доходов и расходов, четкая документация главных расходов и описание источников прибыли. Затраты проекта обычно делятся на две части: однократные затраты на проект и постоянные затраты, возникающие в связи с поддержанием проекта. Аналогичным образом рассматриваются и доходы.

Вебинар «Анализ цепочки создания ценности как инструмент разработки стратегии»

Очень важно понимать ,что для точной оценки доходов от проекта во время проведения процедуры приоритезации времени, как правило, нет. Да и оценка, произведенная с использованием сложных методов и специального программного обеспечения, но основанная на неточных и недостаточно обоснованных допущениях, не имеет смысла. Поэтому оценка финансовой ценности должна быть сделана на основе понятных, оцененных в масштабе всей компании потоков движения денег, а не являться результатом сложных бухгалтерских манипуляций (таблица 1).

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

Предположения, лежащие в основе расчетов, должны отражать реальные временные рамки. Надо помнить, что у менеджмента компании всегда есть проекты, запускаемые в других областях, плановый доход от которых больше. ИТ-директор также должен четко описать расходы, связанные с тем или иным проектом. Здесь важнейший момент — четкое понимание временного расклада затрат на проект необходимого для того, чтобы деньги были доступны, когда они нужны.

Таблица 1. Определение финансовой ценности проекта

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

Проект позволяет улучшить производительность и потенциально может сильно снизить расходы компании. Проект может иметь информационную ценность или помочь лучше контролировать бизнес. Тем не менее конкретную отдачу по проекту трудно измерить.

Ожидаемая окупаемость проекта на уровне 2-5 лет. Доходы от проекта превышают расходы. Большинство допущений при проведении этих оценок имеют под собой определенные основания.

Прогноз и оценка бизнес-ценности в SAFe®

Ожидаемая окупаемость на уровне 0-2 года. Доходы от проекта существенно превышают расходы. Все допущения при проведении этих оценок четко обоснованы.

Риски проекта

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

Таблица 2. Типовые риски проекта

Стратегическая ценность проекта

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

Таблица 3. Типовые категории оценки стратегической ценности проекта

Приоритезация проектов

После того как каждый проект был оценен, оценки (обычно от 1 до 4 для каждой переменной) должны быть сведены в единую таблицу. На основе ранжирования этих данных может быть выведена общая оценка приоритета для каждого проекта. Приоритезация может быть выполнена и в графическом виде по парам из двух параметров. Логика такого процесса здесь очевидна.

Как правило, сначала проводят приоритезацию проектов на основе их стратегической и финансовой ценности. Рисунок 1 (стратегическая ценность/финансовая ценность) показывает, насколько проект «стоит того», а именно, какие проекты обеспечивают наибольшие улучшения в организации. Проекты с самыми низкими относительными финансовыми и стратегическими ценностями расположатся в нижнем левом квадрате. Эти проекты, скорее всего, не войдут в список проектов одобренных к выполнению и дальше рассматриваться не должны.

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

Цель такого анализа состоит в том, чтобы гарантировать получение высокого рейтинга проектами, в которых сочетаются высокая ценность и легкость выполнения (рис. 2, выполнимость/финансовая ценность). Таким образом, обеспечивается, что легкие и быстрые проекты, которые могут принести прибыль, выполняются в первую очередь (они окажутся в верхнем правом квадрате). Проектам, попавшим в этот квадрат, должен быть назначен наивысший приоритет.

Побочные факторы

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

Проектная мощность ИТ-отдела и возможности предприятия

Объем ресурсов ИТ-отдела (проектная мощность ИТ-отдела) зависит от различных факторов, включая число руководителей проектов, набор специальных навыков, распределение персонала между существующими проектами. Особенное внимание надо обращать на возможности управлению проектами.

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

В ходе выполнения проектов

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

Источник: www.iemag.ru

Бэклог задач: Оценка и приоритезация

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

Бэклог

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

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

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

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

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

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

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

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

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

• написать документ по механике работы и расчетам балансировки дейли бонуса — Game 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. Планирование — встреча команды, на которой подзадачи оцениваются и отдаются в работу команде.
11. Приоритеты определяются по принципу — максимальный эффект при минимальных усилиях

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

Источник: progamedev.net

Менеджмент в ИТ

Очень важным этапом работы с Product Backlog является выстраивание задач в порядке их приоритета. Когда мы провели декомпозицию и оценили пользовательские истории необходимо определить, в какой последовательность будет проходить реализация задач, что будет выпущено в первой версии продукта, что может быть включено в последующие поставки, а что может быть оставлено на тот случай, если останется время. Как же определить, что брать за основу при выстраивании приоритезированного списка User Stories?

Провести сортировку бэклога и выстроить тот или иной порядок задач можно базируясь на различных критериях, исходя из разных ценностей. Именно для этого существует множество техник приоритезации, каждая из которых принимает во внимание тот или иной аспекткритерий значимости задачи. Как это свойственно Agile процессу, самым эффективным будет применение и комбинирование различных методов приоритезации. Далее в статье разобраны варианты техник, с помощью которых можно провести сортировку Product Backlog.

Метод 1: Value Based – техника основанная на ценности для бизнеса.

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

Метод 2: Technology Risk Based – техника основанная на технологических рисках.

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

• Использованием новой еще «необкатанной» технологии.
• Большим количеством точек интеграций с внешними системами.
• Сложной логикой и большим количеством условий.
• Наличием устаревшего кода (Legacy code), который более не поддерживается и не дорабатывается, но переиспользуется.

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

Метод 3: «MoSCoW» — метод «Москва».

• При оценке приоритета методом «MoSCoW» для каждой задачи мы подбираем наиболее соответствующее ей 1 утверждение из 4. Каждое из утверждений является индикатором определенного уровня важности задачи. Какое из утверждений больше соответствует действительности, к такой группе приоритета и принадлежит данная пользовательская история:

• Must have this – Это обязательно должно быть. «Must» требования не подлежат обсуждению и в любом случае должны быть реализованы. Если они не поставлены пользователю в ближайших релизах, тогда весь проект не имеет смысла.
• Should have this if at all possible – Следует сделать, если это только возможно. Данные задачи также важны для пользователя иили заказчика, однако, сроки их поставки не так критичны как для «Must». Без данной функциональности продукт уже можно использовать, ее отсутствие не блокирует базовых возможностей из списка «Must» и она может быть выдана немного позже.
• Could have this if it does not affect anything else – Можно сделать, если это не повлияет на что-то другое. Эта категория задач допускает максимально гибкий взгляд на такие основные критерии выполнения как скоуп, сроки, качество и ресурсы. Здесь возможна вариативность и компромиссы.
• Will not have this time but would like in the future – Сейчас на это нет времени, но хотелось бы сделать в будущем. Для этой категории ключевым моментом является то, что данные требования могут быть также важны (также как и «Must»), однако, их можно оставить для более поздних поставок продукта. Категория «Will not» имеет 3 важных эффекта:

• Пользователям и заказчикам не нужно бороться, чтобы включить какое-либо требование в Product Backlog.
• Имея возможность видеть список требований для отдаленных релизов, можно оценить как это будет влиять на то, что будет реализовано в первую очередь.
• На требования из категории «Will not» можно ориентироваться как на долгосрочную тенденцию в развитии продукта, учитывая данные особенности в ранних поставках.

Метод 4: Kano model — модель Кано.

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

• Must-be Quality — обязательные для пользователя характеристики продукта. Это требования, которые заказчикипользователиклиенты ожидают в первую очередь и воспринимаются как должное, они являются необходимыми для выпуска продукта. Когда данные функции реализованы, клиенты воспринимают это как само собой разумеющееся, но когда они не реализованы или сделаны плохо, клиенты очень недовольны.
• One-dimensional Quality — одномерные характеристики. Это функциональность, которая приводит к удовлетворению пользователейклиентов, когда она реализована и недовольству, когда ее нет. Это параметры и возможности продукта, на которых строится конкуренция компаний между собой.
• Attractive Quality – привлекательные для пользователя характеристики. Реализация данных требований обеспечивает удовлетворение пользователей, но при этом когда они не выполняются, это не вызывают неудовлетворенности. Это функционал, который обычно не ожидается и радует пользователя, если он вдруг появился.
• Indifferent Quality – безразличные для пользователя характеристики. Для пользователя требования из этой категории не являются ни хорошими, ни плохими, они не приводят к удовлетворению или неудовлетворенности клиентов. Примером таких задач могут быть различные технические решения, которые скрыты от пользователя.
• Reverse Quality – противоположные характеристики. К этой группе относятся требования, реализация которых улучшает, но при этом усложняет продукт. Это могут быть различные дополнительные функции, которые расширяют необходимый и достаточный функционал продукта. Для ряда клиентов и пользователей сложный высокотехнологичный продукт, с большим количеством функций и возможностей может быть скорее минусом.

Метод 5: Validated Learning – «подтвержденное обучение».

• В этом методе в качестве самых приоритетных выбираются функции и задачи с самым высоким рыночным риском. Это могут быть какие-либо фичипродуктывозможности, которых еще не было на рынке и не понятно как рынок отреагирует на их появление, как примут их пользователи.
• Суть метода сводится к тому, чтобы выпустить задачи с наибольшим рыночным риском как можно раньше, проверить решение экспериментально, получить обратную связь (пройдя тем самым обучение) и далее применить полученные знания в новой итерации.
• Процесс применения Validated Learning обычно состоит из следующих шагов:

• Выбираются пользовательские истории с наибольшим рискомстепенью неопределенности для рынка.
• Определяются метрики и критерии успешности для выбранных задач.
• Требования с самым высоким приоритетом реализуются в первых итерациях и включаются в максимально ранние поставки.
• Проводится анализ достижения установленных метрик.
• В соответствии с полученными результатами в требования и процесс работы вносятся корректировки и начинается следующая итерация приоритезации.

Метод 6: Walking Skeleton – «ходячий скелет».

• В этом методе задачи приоритезируются таким образом, чтобы наиболее тесно связанные между собой требования, которые составляют сквозной бизнес процесс, были реализованы и выпущены одновременно или в течение короткого промежутка времени.
• Вначале отбираются задачи, реализация которых даст минимальный возможный набор end-to-end функционала и позволит выпустить первую рабочую версию продукта. Данные задачи будут иметь максимальный приоритет.
• Остальные задачи также при помощи приоритетов объединяются по группам. Каждая группа требований получает свой приоритет и ее реализация позволяет добавить к продукту новый небольшой функционал (сквозной бизнес процесс).
• Важным принципом при разбиении требований на группы приоритетов с использованием Walking Skeleton является то, что в первом релизе, в начальной версии продукта мы не реализуем сразу конечную архитектуру. Архитектура и функциональные задачи реализуются параллельно в последующих итерациях.

Метод 7: Theme scoring – оценка «тем».

• В рамках данного метода приоритеты определяются при сравнении требований («тем») друг с другом по различным критериям. В процессе приоритезации определяется насколько важно включить ту или иную тему в следующий релиз по каждому из таких критериевусловий.
• Основные этапы метода Theme scoring:

• Определяется порядка 5-9 критериев выбора для сравнения, что важно выпустить в следующем релизе. Критериями для сравнения могут быть, например:

• Полученная прибыль после выпуска задачи
• Важность функционала для пользователейклиентов
• Необходимость решения для последующих доработок продукта
• Уровень технического риска при реализации задачи

Смотр ите также:

• Назад
• Вперед

Источник: doitsmartly.ru