В погоне за точкой EVPI: как снизить неопределенность цифрового проекта
09.07.2020
Не все IT-проекты получаются успешными. Часто бывает, что проект разработали, а потребители не пользуются: получилось сыро, не функционально, неудобно, некрасиво. При этом после разработки первого релиза зафиксирован перерасход бюджета более чем в два раза, и руководство или инвесторы не очень-то хотят выделять новые средства на дальнейшее развитие. Зачастую проект на этом закрывают с надеждой вернуться к нему в лучшие времена.
В большинстве случае причина в неверных приоритетах: какие функции реализовать в первую очередь. Часто понимание, какой функционал нужен, приходит только после того, как проект запускается в тестирование на пользователях.В нашей практике был пример разработки мобильного приложения для федерального продавца электроники. В те годы, когда они выпустили первый релиз, мобильные приложения было делать модно, и ребята погнались за трендом, сделав мобильное приложение, которое дублировало веб-сайт и его самый важный функционал — каталог товаров. Прошло несколько внутренних итераций разработки, приложение выпустили и получили практически нулевой коммерческий эффект. Пользователи не заказывали через приложение. После более детального анализа выяснилось, что в первой версии исключили раздел, связанный с регистрацией и авторизацией. Можно было сделать только «быструю» покупку, без какого-либо сохранения своих данных, начисления бонусов и так далее. С другой стороны, у сайта была неплохая мобильная версия, которой большинство потребителей и продолжило пользоваться. Мы с проектной группой проанализировали, кто именно скачивал приложение. Выяснилось, что большая часть пользователей была лояльной аудиторией, так называемые адвокаты бренда. Именно они проходили несколько дополнительных шагов конверсии в виде поиска и установки приложения из магазина на свой гаджет. Работа с такой аудиторией предполагает несколько иной подход, чем с той, которая пришла с разных источников трафика на сайт. Следовательно, и ключевой функционал мобильного приложения должен был быть другим.Почему возникают такие проблемы? В частности, из-за методики управления проектами. Изначально подход к реализации IT-проектов строился на основании методов классического менеджмента, который успешно применялся до этого в строительстве и других смежных отраслях. Собирались требования, писался устав проекта, строилась карта рисков и т. д. В итоге, когда пришла эра интернета, цифровые проекты стали реализовывать теми же методами. И большая часть из них стала буксовать. Дело в том, что в цифровой среде внешние факторы, а следовательно, и требования к проекту изменяются гораздо быстрее. То есть в традиционном процессе, которому требуется много времени на реализацию — начиная от сбора требований и заканчивая приемкой проекта, требования уже в процессе выполнения могут измениться. У меня был пример одной банковской организации, где требования менялись быстрее, чем успевала отрабатывать тендерная комиссия по выбору поставщика. Раз в 3–4 месяца ТЗ обновлялось, а процесс буксовал. При более детальном рассмотрении данного кейса удалось качественно упростить требования бизнеса, исключив большую часть ненужного функционала.Эволюция проектного менеджмента привела к появлению «гибких (agile) методологий», и в соответствии с ними уже можно делать проекты с быстро изменяющимися требованиями. Конечно, есть достаточно большой пласт проектов, которые можно и нужно реализовывать с помощью подхода классического менеджмента. Например, когда какой-то процесс делался на бумаге, а потом решили переложить его на компьютер (автоматизировать). Здесь задача ясна, и ценность понятна всей рабочей группе. Требования изменяться не будут. Но что делать в случае, если конечная цель неясна, а бизнес-заказчик не может или не умеет приоритезировать задачи для проектной группы? Как на ранних стадиях проекта определить ценный для пользователей функционал и не сделать лишнего, то есть сэкономить бюджет?В последнее время появились методы, которые позволяют это сделать. Это методы предпроектных исследований, когда техническая группа разработки подключается еще на стадии формирования требований. При этом, инвестируя небольшую часть бюджета проекта в предпроектные исследования, можно качественно снизить затраты на разработку в дальнейшем. За счет чего это происходит?Посмотрим на график ниже:Графики взяты из книги Дугласа Хабарда «Как оценить что угодно», а он в свою очередь взял их из теории информации. На графике нарисованы две кривые. По горизонтальной оси расположено количество информации, а по вертикальной — стоимость. Нижняя кривая (ECI) определяет планируемую стоимость информации, то есть сколько денег в условных единицах (или в попугаях) нам нужно потратить, чтобы получить необходимое количество информации. Верхняя кривая (EVI) показывает планируемую ценность информации — то, насколько мы снизим неопределенность, инвестировав определенную сумму денег. На пересечении двух кривых находится точка EVPI — сумма денег, которую нужно инвестировать, чтобы получить абсолютное понимание или 100%-ю уверенность в чем-то. Конечно, эта точка недостижима, но если рассматривать этот график на практическом примере, то самая крайняя точка — это когда мы уже сделали проект и получили обратную связь, насколько он нужен пользователям. Или, другой пример, который касается оценки стоимости проекта. На стадии «когда все уже сделано», стоимость ясна. Мы можем дать более-менее точную оценку стоимости, когда провели стадию проектирования. И очень-очень приблизительную оценку, когда только имеем вводные требования или размытое описание проекта от бизнеса. Мы придумали модель market-business-clients (MBC), которая позволяет качественно снизить неопределенность проекта на его ранних стадиях. Методика заключается в том, что мы смотрим функционал в трех разрезах: Market (рынок), Business (бизнес) и Clients (клиенты).Во-первых, рынок. Смотрим прямых и косвенных конкурентов. Здесь рекомендуется использовать разные аналитические подходы, для того чтобы определить, какой функционал является базовым в той отрасли, в которой планируется делать проект. Это важно, чтобы не забыть существенно важные вещи на следующих стадиях.Второе — бизнес. Правильная работа с проектной группой на самой ранней стадии, когда она формирует бизнес-требования. Это один из самых важных этапов. В его рамках совместно с проектной группой прежде всего ставится цель, которую мы хотим достичь. Проводится сессия по целеполаганию. Далее исследуются возможные пользователи и выбирается портрет тех, кто может сделать наибольший вклад в развитие нашей цели. Далее для каждой группы пользователей прорабатываются ценности, то есть строятся гипотезы, чем проект может быть им полезен и почему они будут им пользоваться. На финальной стадии вместе с разработчиками прорабатывается, какой функционал требуется создать, чтобы пользователи получили свою пользу. Метод носит название Impact mapping, по сути это ментальная карта, дерево. Для его построения следует ответить на ряд базовых вопросов:– Зачем нам нужен этот проект (цель)?– Кто наши главные пользователи?– Как эти пользователи могут помочь в реализации нашей цели?– Какой функционал проектная группа должна разработать, чтобы пользователи получили пользу?Как только у нас есть подобное дерево, мы учим проектную группу его читать. Условно говоря, каждую ветку, если исключить корень (цель), можно прочитать таким образом:«Я, как такой-то пользователь, хочу функционал, это даст мне пользу».Рассмотрим небольшой пример:Здесь цель — увеличить число удовлетворенных клиентов банка в два раза.Есть пользователи проекта, которые могут помочь в реализации цели. Например, call-center. Он может обрабатывать входящие заявки быстрее. Для этого нужно сделать чат-бота или реализовать чат с оператором. В итоге история будет звучать так: «Я, как представитель (или пользователь) кол-центра, хочу иметь чат-бота. Он избавит меня от части шаблонных обращений и позволит обрабатывать входящие заявки быстрее».Ключевой момент здесь в том, что мы прорабатываем функционал, исходя не из пожелания проектной группы, а из гипотез о ценностях самих пользователей. Озвученные выше предложения в гибких методологиях называются пользовательскими историями. Научив проектную группу работать с данным деревом, мы получаем эффективный инструмент более быстрого обмена и передачи информации. Далее каждую пользовательскую историю приоритезируют (в баллах от 1 до 10) и оценивают разработчики (в часах или в условных единицах). Посчитав удельный вес каждой истории в баллах и трудозатратах, можно отранжировать задачи по степени важности.Заключительный шаг методики предпроектного исследования — это общение с пользователями. Далеко не всегда бизнес выбирает правильные гипотезы, поэтому приоритезацию следует уточнить. Для этого используются различные подходы, например глубинные и проблемные интервью, исследования по макетам и другие.Главное здесь — совместно с проектной группой поставить задачу, принять единый контекст и приоритезировать задачи таким образом, чтобы с наибольшей вероятностью достичь поставленной цели (при небольшом бюджете), качественно понять и спрогнозировать дальнейшие шаги. Ведь от этого зависит успех всех последующих мероприятий. Agile-методология позволяет существенно снизить риски при планировании цифрового проекта и избежать существенных ошибок при разработке продукта.
