«Хочу свой маркетплейс!» или «Сделайте мне сайт, как у Эппл конкурента» — требование, вроде бы, понятное и емкое. Ну правда же: сразу можно оценить масштаб проекта! Но увы, это только на первый взгляд.

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

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

Мы советуем второй путь и ниже рассказываем, как вообще в Сибирикс строится работа заказчиками с момента первого знакомства до сметы. А ещё — какие «хотелки» и важные параметры проекта вам стоит озвучить аккаунт-менеджеру студии разработки для более точной оценки проекта.

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

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

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

Забавный факт: часто уже на этом этапе заказчик осознает, что шел в студию с простой задачей «обновить дизайн», а в итоге оказывается, что для решения задач его бизнеса нужно делать проект с нуля с полностью иной логикой.

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

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

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

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

• агрегации требований и CJM (сейчас мы объединили аналитику и путь пользователя в удобный гибридный формат CJM);
• примеры прототипов для корпоративных проектов, интернет-магазинов и личных кабинетов;
• ТЗ и бэклоги — показываем, как мы работаем с ТЗ и что вообще такое бэклог и в чем его соль;
• мудборды и скетчи;
• дизайны главных и внутренних страниц на проектах разного типа: от корпоративных сайтов до маркетплейсов;
• дизайн-системы — если проект заказчика нуждается в таком инструменте;
• верстка разных проектов — как правило, сложных технически и визуально классных (например, сайт легенды геймдева Alawar или сайт для производителя халяльных молочных продуктов «Чабан»); 
• интеграции — тут можем показать технологические схемы или подробно рассказать о конкретных кейсах с непростыми интеграциями;
• дашборды и доски управления.

Если стоит вопрос о выборе технологий, можем подробно рассказать о том стеке, который рекомендуем для проекта, показать примеры админ-панелей Laravel, обсудить плюсы и минусы при выборе между Flutter и React Native для мобильной разработки и не только.

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

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

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

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

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

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

1. Проект нам интересен именно с точки зрения креатива — есть ощущение, что можно сделать «Вау!» и клиент будет готов к смелым решениям. 
2. Заказчик сам говорит, что нужен вау-эффект, но непонятно, что под этим подразумевается. В этом случае мудборд позволяет дать более точную оценку на дизайн — мы смотрим с заказчиком разнообразные варианты решений, чтобы понять — в какую сторону идти и заранее понять объем работ.

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

Чтобы уже на первом звонке-знакомстве разговор получился продуктивным, заказчику важно подготовиться заранее.

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

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

Если у вас уже есть проект, важно сформулировать:

• что хотите переделать или улучшить;
• чего не хватает и нужно добавить: это могут быть конкретные страницы, личные кабинеты, интеграции;
• что необходимо сохранить — например, SEO-трафик.

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

Хорошо, если заказчик сразу расскажет о том, зачем ему новый сайт и какие задачи с его помощью он хочет решить. Одни из самых частых запросов клиентов:

• обновить дизайн, сделав его современным;
• сделать удобными структуру, навигацию или интерфейсы;
• рассказать о компании или конкретном бренде;
• поработать над позиционированием и «зацепить» пользователей с первого скролла;
• снизить нагрузку на сотрудников компании за счет автоматизации процесса оформления заказа или бронирования;
• упростить работу контент-менеджеров.

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

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

• ERP-системы и базы данных — важно указать, что это за базы данных, какую информацию мы должны забирать оттуда на сайт, есть ли API;
• CRM-системы — также важно указать, что за система, какую информацию нужно забирать на сайт;
• Для e-commerce-проектов также важно обсудить системы оплаты и доставки — какие должны быть на сайте и сколько, нужен ли эквайринг;
• Программы лояльности и бонусные системы — если это сторонняя система, также важно понять, есть ли API и какие данные планируется забирать на сайт.

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

Если на проекте требуется личный кабинет — это важно обсудить отдельно. Потому что функционал такого раздела на сайте бывает ну очень разным: на одном проекте достаточно хранения ФИО, контактов пользователя и возможности отслеживать заказ, а на другом требуется настоящая панель управления от космического корабля. И конечно, это означает совсем разные бюджеты на разработку.

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

Чем больше подробностей о проекте и требованиях к нему вы расскажете на старте — тем больше очевидных плюсов получите:

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