Даже MVP нельзя разработать без тщательного анализа и глубокой проработки требований. В противном случае есть риск потратить и без того ограниченный бюджет впустую.
Чтобы этого не произошло, нужно качественное ТЗ.
В этом кейсе расскажем, как нам удалось спроектировать эффективную систему, соответствующую ожиданиям инвесторов и потребностям клиентов..
Над какой системой мы работали
Мы разрабатывали систему для малого и среднего бизнеса, она позволяла авторизовываться в банках. Бизнесу нужно управлять счетами в разных банках без необходимости проводить платежи и анализировать доходы и расходы в каждом банке отдельно. Нужно одно место, где бизнес сможет полностью управлять финансовыми потоками через разные банки.
В некоторых странах законодательство обязывает банки раскрывать свои API, в других — нет. Мы работали над системой на рынке Объединенных Арабских Эмиратов, где вскоре должен был принят закон, обязывающий банки раскрывать API.
На момент разработки системы закон еще не вступил в силу. Мы не хотели интегрироваться с каждым банком напрямую, поэтому искали компании, которые уже агрегировали банковские решения и предоставляли единый API. Вместо того чтобы интегрироваться самостоятельно, мы нашли компанию, которая уже объединила решения разных банков.
К нам обратились основатели стартапа с бизнес-идеей, которую они успешно защитили и получили небольшие инвестиции для создания первой версии — proof of concept. Им требовалась аналитика, чтобы уложиться в ограниченный бюджет, тщательно проработать и запланировать, что нужно сделать, чтобы реализовать проект в рамках бюджета и сроков, одновременно решая множество дополнительных вопросов.
Аналитика: предварительные ласки
На старте у нас был pitch deck — специальная презентация для инвесторов, которая описывает продукт, рынок, его тенденции и обосновывает, почему продукт будет успешным. Это была отличная инвестиционная презентация, но в ней была только бизнесовая информация.
Презентация описывала киллер-фичи — кто такие пользователи, какие у них боли и как приложение должно их решать. Но, конечно, там не было конкретики. Например, упоминалось, что пользователи смогут управлять своими финансами. Но что означает «управлять»? Возможность просматривать платежи, статистику? Возможность совершать платежи? А какие именно платежи?
Также было указано, что пользователи смогут выстраивать отчетность по всем операциям. Но это не просто отчетность. Для бухгалтеров — ключевых пользователей приложения, — важны конкретные отчеты, которые они готовят и сдают в определенные сроки. Это не просто случайная кастомная отчетность.
Нам, как аналитикам, нужно было понять, какой минимально необходимый функционал необходим в системе, чтобы создавать эти отчеты. Иначе бухгалтеры не будут использовать приложение, так как не смогут выполнять основные задачи.
Мы тщательно изучили презентацию, а затем проанализировали рынок. Исследовали аналогичные системы, не обязательно конкурентные. Например, могли существовать такие же приложения, но для других стран с другой отчетностью.
Пообщались с конкретными бухгалтерами, работающими на этом рынке. Провели глубинные интервью, чтобы понять, как и с чем они работают, с какими трудностями сталкиваются. После детального изучения их работы представили им концепт приложения и задали вопрос: «Было бы вам удобно, если бы это выглядело так?». Мы получили обратную связь и провели небольшое тестирование гипотезы.
Таким образом, мы собирали требования для того, что должно быть реализовано в MVP, чтобы оно соответствовало обещаниям, данным инвесторам. Мы составили перечень минимально необходимого функционала, без которого теряется конкурентное преимущество, а пользователи не смогут выполнять свои основные задачи.
Мы также проработали систему монетизации. В презентации заказчиков она, конечно, была описана. Но наша задача как аналитиков заключалась в том, чтобы поставить ее под сомнение и провести валидацию. Мы задавали пользователям вопросы: «Сколько вы сейчас платите за решение? Готовы ли платить за новый функционал? А если готовы, то сколько?».
Мы проверяли модель монетизации, предложенную заказчиками, на ее восприятие реальными пользователями и вносили коррективы.
С какими трудностями мы столкнулись
Кейс был сложен тем, что мы работали в условиях неопределенности в законодательстве, исходя из прогноза, что оно изменится и что можно будет напрямую взаимодействовать с различными банками через API. Мы понимали, что если закон будет принят, наша система должна быть готова к таким интеграциям. Однако существовал риск, что закон не будет принят. Поэтому, если бы мы изначально строили систему, ориентируясь на закон, она могла бы оказаться неработоспособной. Это привело бы к перерасходу бюджета, и нам пришлось бы переделывать всю систему таким образом, чтобы она могла интегрироваться с агрегатором. Агрегатор интегрируется с банками, а мы — с агрегатором.
Поэтому было принято решение разрабатывать архитектуру так, чтобы она могла работать как напрямую с API банков, так и с агрегированными решениями. Это увеличило стоимость разработки на этапе MVP, но было оправдано, так как гарантировало оптимальную гибкость, необходимую в условиях высокой неопределенности.
Работа осложнялась спецификой местного рынка — иным законодательством, принципами управления финансами и отчетностью. Все это нужно было изучить и учитывать при выборе функционала, что накладывало дополнительные ограничения. Мы были вынуждены тщательно проводить интервью с бухгалтерами, финансовыми специалистами и целевыми пользователями, чтобы четко понять, какой функционал является критически важным, а без чего можно обойтись.
Поскольку это был стартап, бюджет и сроки были ограничены. Нам нужно было приоритизировать функционал, выбирая только тот, который приносил максимальную ценность. На каждом этапе, прежде чем взять функцию в работу, мы оценивали ее стоимость и сопоставляли с ожидаемой пользой для пользователей. Тестировали это на потенциальных пользователях и собирали обратную связь.
Например, реализация модуля для построения кастомных отчетов оказалась сложной задачей — это была дорогостоящая функция. Первоначально мы планировали отказаться от нее, предлагая стандартные решения. Однако, как выяснилось в ходе переговоров, без этого функционала система теряла бы привлекательность для пользователей, и они не были бы готовы за нее платить. Поэтому мы решили оставить эту функцию и сделать ее ключевой, хотя изначально этого не предполагали.
Из чего состоит ТЗ
Когда мы определили необходимый функционал, приступили к ТЗ. Стремились предоставить четкие инструкции разработчикам.
- Скоуп работ — это детализированный перечень задач, которые необходимо выполнить для достижения целей проекта. Скоуп работ помогает избежать недоразумений, обеспечивая ясное понимание того, что должно быть сделано, а что не входит в задачи проекта.
- Пользовательские истории — что, когда, в каких случаях и какие пользователи могут делать.
- Юзкейсы — как конкретный пользователь взаимодействует с системой в конкретной ситуации, последовательность действий, альтернативные сценарии.
- Возможные ошибки системы.
- Структуру данных— какие сущности участвуют в юзкейсах.
- Глоссарий,так как отрасль специфическая, и на рынке ОАЭ есть определенная терминология, которую необходимо описать, чтобы все участники разработки говорили на одном языке.
- Прототипы — мокапы, чтобы дизайнер мог взять описание юзкейсов и базовые мокапы и составить из этого дизайн.
На выходе мы получили набор юзкейсов и диаграмму сущностей с их взаимосвязями.
Затем мы получили обратную связь от заказчиков и техлидов, которые будут реализовывать проект. После согласования передали финальную версию в разработку.
Мы не откладывали разработку до полного завершения ТЗ. Скорость была критически важна, поэтому мы параллельно вели несколько процессов. Когда начали писать ТЗ, у нас уже был скоуп работ. Мы разбили его на блоки и приоритизировали их с точки зрения того, что нужно прояснить в первую очередь, а что уже достаточно понятно. Например, авторизация, регистрация, модуль нотификаций — разработчики могли начать работу, пока мы занимались детальным описанием более сложных частей. Например, отчетности: какая она должна быть, как должна выглядеть, какие данные для этого нужны.
Мы передавали блоки в разработку от самого сложного к самому простому, давая разработчикам возможность начать с базовых задач, не требующих детальной аналитики.
Чему мы научились
Мы сделали выводы о необходимости быть готовыми к изменениям. Гибкость любой системы критически важна для успеха. Даже при жестких сроках и ограниченном бюджете нельзя пренебрегать аналитикой и бета-тестированием, чтобы избежать серьезных последствий в будущем. Мы сформировали видение продукта, определили набор функционала, создали прототипы. Хотя мы еще не были уверены, что именно будем делать, мы сразу представили это нашим пользователям. Показывали им, обсуждали, получали обратную связь. Опираясь на нее, мы вносили изменения уже на этапе аналитики, а не разработки.
Если бы мы не взаимодействовали столь тщательно с целевой аудиторией, у нас получился бы совершенно другой продукт с другим набором функционала и приоритетами.
Правильная и жесткая приоритизация была ключевым моментом. Пользователи давали обратную связь, но они могли хотеть многого. Владелец продукта принимал строгие решения о том, что включать, а что — нет, в MVP-версию. Приоритизация была проведена очень грамотно — мы учитывали даже самые мелкие функции: какие они принесут выгоды, сколько будут стоить, как на них реагируют пользователи. Даже если какие-то функции казались необходимыми, важно было выбрать и разработать только самое ключевое, чтобы уложиться в сроки и бюджет. Лишь затем переходили к следующим этапам.
В итоге команда успешно завершила разработку MVP в срок и в рамках бюджета, несмотря на все сложности и ограничения. Мы потратили значительно больше средств на аналитическую работу, но при этом сэкономили время и деньги на разработке. Это себя оправдало — приложение оказалось востребованным. Мы получили положительные отзывы от целевой аудитории, а клиент, для которого было создано приложение, сейчас активно привлекает инвестиции для дальнейшего развития продукта.