Мы в MobileUp заметили, что у некоторых клиентов, которые к нам приходят, нет сформулированных и продуманных требований к продукту, достаточных для оценки проекта. На такие пресейлы мы тратили в два раза больше времени: чтобы правильно оценить проект, начинали подбирать недостающие детали вместе с заказчиком, а что-то и вместо заказчика. Мы, конечно, отталкивались от задачи, но часть оценки была нашей фантазией. То есть мы делали работу, которая вроде была нужна клиенту в моменте. Но действительно ли она была нужна? В то же время даже не в параллельной, а в нашей вселенной, другие компании также брифовали этого клиента. И тоже приходили к своему результату.
Цель предпроекта — снижение неопределенности при разработке цифрового продукта. Предпроект позволяет выявить требования и ограничения до начала работ и избежать критических ошибок на старте, да и на финише, что уж там.
На брифинге мы задавали клиенту вопросы про продукт. А клиент этого еще не придумал, ведь продукта как такового и нет. Решили, что к таким проектам нужен другой подход и придумали предпроект.
Глеб Гусько, аналитик MobileUpНужен или нет — зависит не от типа клиента, а от степени проработанности задачи. Корпорации часто приходят с проектом на уровне идеи, как и стартапы. А стартапы могут прийти с четко сформулированным продуктом, метриками.
Обычно на этом этапе понятна проблема, которую проект решает. Здорово, когда есть экспертиза и референсы. Часто рассматриваются идеальные сценарии, в отрыве от контекста. А что им предшевствует? А как авторизоваться? А через почту или смс? А кто эквайер на проекте?
В этом случае обычно нет понимания, что вокруг: можем вместе подумать про ретеншен, монетизацию, поддержку, авторизацию. Если степень проработанности требований высокая — такая штука не нужна. Но если у вас в арсенале только документ на полторы страницы, остальное должно появиться в ходе проработки.
К нам пришел клиент, который хотел создать продукт на базе уникальной технологии, в мире такого еще никто не делал. Как он будет использовать технологию — не знает. Но задача вот такая, хочет продать и привлечь инвесторов. Сколько это будет стоить?
Разговор у нас получился достаточно жесткий. Как применить технологию вы не знаете, мы тоже не знаем. Так давайте потратим некоторое время, привлечем вас и нас и сформулируем описание продукта, архитектуру, накидаем флоу, кейсы и вместе придумаем, как это будет.
Глеб Гусько, аналитик MobileUpПривлекли команду из трех человек (аналитик, разработчик, СТО) и на выходе получили документ, который описывает, что это за приложение, какие у него функции, как будет работать. То есть получили описание бизнес-функций продукта и технических деталей.
Не все получилось с первого раза. Мы почти доделали первый драфт, когда от команды заказчика прилетели уточнения, которые принципиально меняли логику работы сервиса. Это жизнь, так бывает, обновили документ и добавили новые вводные. На финальном этапе пришли безопасники и попросили дочертить еще пару формул, которые тоже затронули логику работы. Еще раз переписали документ. В итоге все равно потратили в разы меньше ресурсов, чем если бы сразу стартанули разработку.
Спойлер: а мог бы помочь, если бы мы такую услугу придумали два года назад.
У нас был проект, где заказчик не определил скоуп на старте, еще не придумал, что там должно быть. В итоге проектирование разошлось и напроектировало, дизайн надизайнил. Скоуп конечно же начал раздуваться и после дизайна оценка устремилась вверх.
Если бы был предпроект, мы бы сразу увидели, что оценка не валидна. А чтобы сделать ее валидной, надо было подумать и урезать конкретные штуки, которые не дадут продукту потерять в целостности. Да, мы бы потратили на месяц больше времени, но выявили бы требования и зафиксировали их на старте.
Разделили предпроект на четыре этапа: погружение, анализ, синтез, оценка. В среднем исследование занимает 1-2 месяца. Срок работ может меняться в зависимости от объема необходимых работ и глубины проработки материалов.
Получить общее представление о проекте от заказчика и ключевых стейкхолдеров. Формализовать цели бизнеса, обоснование проекта и ожидания.
Благодаря этому этапу мы формируем более целостное представление о самом продукте, его месте на рынке и том как он может работать с технической точки зрения.
Оценить возможности и ограничения текущей и целевой технической инфраструктуры
Сформировать модель предметной области. Понять, какие процессы существуют в компании и как они связаны с продуктом
Понять, как аналогичные задачи решаются сейчас в рамках компании и собрать релевантные кейсы с рынка
Разделить аудиторию на логичные группы с разными потребностями. Получить глубокое понимание пользователей и их задач
Все это — концептуальная схема и иногда нужна только часть. Например когда клиент приходит с идеей, то в анализе важно начинать с «Определения сегментов», те всего остального пока и нет. А если например приходит с задачей сделать приложение для существующего Бизнес-продукта, тогда уже анализ в полном объеме нужен, а информация по пользователям у клиента уже может быть.
Александр Юдин, арт-директор MobileUpВ результате мы готовим артефакты, которые содержат описание бизнес- и функциональных требований к продукту, а также базовое описание потоков данных и архитектуры. Этап помогает:
Зафиксировать ключевые предположения о том, из чего должен состоять продукт, и подготовить основу для MVP;
Зафиксировать минимальный состав функционала, который даст ценность и позволит проверить гипотезы. Спроектировать информационную архитектуру продукта.
Чтобы получить оценку, мы дкомпозируем фичи, определяем объём работ и ресурсов: сроки и стоимость.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13590 тендеров
проведено за восемь лет работы нашего сайта.
Наша задача в рамках предпроекта — приземлить идею клиента на реализацию.
Задаем вопросы, чтобы понять, а из чего состоит продукт. И это очень сильно касается дальнейшего развития продукта. А дальше что? А потом? А за счет чего пользователь будет возвращаться?
Клиент получает на руки документ с бизнес-функциональными требованиями и концептуальную архитектурную схему. Это не просто технический документ, в файле есть и нефункциональные требования — ожидания клиента.
Дальше – оценка.
Из отдела аналитики файл попадает в дизайн-отдел. Арт-директор изучает документ, понимает его, созванивается с клиентом. Потом уже проектирование, концепция, дизайн.
Важно, что этот файл можно отдать любому дизайнеру, он его поймет и сможет использовать в работе.
Если не делать предпроект, то можно много придумать за клиента. А он и не в курсе, что мы там напридумывали, пока оценку делали. Останавливаемся на том, что он видит сумму в смете и думает, а почему так дорого получается?
Наша задача — вместе с клиентом довести проект до точки определенности.
Какой объем проекта, из каких модулей состоит продукт и какой набор функциональных требований мы к нему выдвигаем. Одно цепляется за другое. Авторизация через почту? Значит, нужно подумать и о восстановлении пароля.
Тут про целостность продукта. Что вот этот модуль нужен для решения этой проблемы. А возможность удаления аккаунта нужна по требованию Эпл. Ничто в документе не является лишним. А если лишнее — убираем. Вместе приходим к таким выводам.
После того, как поняли скоуп проекта, мы уже на основе своего опыта можем думать о том, как это будет работать.
Например, если авторизация через соцсети — ок, описываем, как сделать. Если по номеру телефона — нужно выбрать провайдера, который шлет смс, мы вот с такими работаем. Если почта – почтовик, есть опыт работы через этот сервис. Обозначаем внешние интеграции, которые нужны, чтобы двигать проект дальше. Чем раньше задуматься, тем более плавно пойдет процесс.
Глеб Гусько, аналитик MobileUpДальше с таким документом — куда угодно.
Главное, что заказчик получил пользу и дальше уже может работать с этим файлом.