Привет, меня зовут Инга. Я работаю в digital-агентстве Alente. В отделении разработки мы ведём проекты по созданию сайтов с нуля. И на первом этапе мы очень тщательно готовимся.
Проведение аналитического этапа перед разработкой уже стало мейнстримом, и это понятно: задуматься о целевой аудитории веб-продукта — здравая идея, позволяющая сделать продукт востребованным и полезным, включить в него только нужные фичи, сделать приятный дизайн, позаботиться о доступности… Мы все стали осознанными творцами, и это радует.
Но что насчёт заказчика?
Мы делаем сайты для малого и среднего бизнеса, иногда — для государственных структур. Под заказчиками я подразумеваю именно их — будущих обладателей вашего веб-шедевра, с которым компании предстоит жить и зарабатывать деньги.
Говорят, что причиной многих ошибок является банальное незнание ограничений. Забыли спросить, не учли, «вообще в голову не пришло». Мы за 12 лет работы обожглись не раз, и большинство причин, по которым случались ошибки, — это недостаточное знание внутренних бизнес-процессов заказчика, которые:
а) накладывают ограничения на проектируемую вами систему — а ограничения лучше знать заранее;
б) открывают возможности для адаптации системы под конкретного заказчика, что, в свою очередь, делает использование продукта компанией проще и приятнее.
Дальше приведу конкретные примеры, не переключайтесь.
Как правильно вникать в бизнес-процессы, чтобы ничего не упустить?
Спросить у заказчика. Но не просто задать абстрактный вопрос «расскажите о ваших бизнес-процессах» — а попросить смоделировать на словах тот бизнес-процесс, который вы хотите оптимизировать и/или перевести в онлайн посредством разрабатываемого продукта.
Например, перед разработкой интернет-магазина полезно задать такие вопросы:
— Опишите, как сейчас происходит обработка заказов?
– Оператор принимает заказ по телефону, регистрирует его в 1С, потом собирает...
— Можно подробнее, как происходит регистрация в 1С? Какие поля заполняет оператор? Удобен ли процесс сейчас?
…
Проведя такой диалог, мы выяснили, что у клиента есть 1С и заказы в нём регистрируются вручную, — можно автоматизировать этот процесс.
Это лишь маленький пример того, сколько пользы можно найти в простом линейном описании процесса. Для клиента он уже стал рутинным, и зачастую он сам не видит точек оптимизации, так что мы можем ему в этом помочь.
Изучить документацию. Если речь идёт о разработке портала, сервиса или просто большого сайта для уже функционирующей крупной компании, нужно изучить документы: регламенты, правила проведения, внутренние инструкции — всё, где описаны бизнес-процессы, а главное, ограничение в их работе.
Недавно я участвовала в хакатоне, который проводил Информационный департамент города Москвы. Мы с командой писали telegram-бот для портала закупок. Я вычитала все регламенты по работе на портале — и выяснила много интересного, например то, что для участия в торгах надо обязательно поставить галочку, которая сигналит о согласии пользователя с правилами проведения торгов. Соответственно, прежде чем выводить функциональность аукциона в бот, нужно дать пользователям возможность согласиться с правилами: иначе итоги такого аукциона будут нелегитимными. Мы сделали этот простой нюанс и несколько других, что вызвало большой отклик у членов жюри, которые сами работают с этим порталом. Они с благодарностью слушали нашу защиту — а потом отдали нам победу.
Изучить законодательство. Многие процессы лежат в зоне действия нормативных актов. Кстати, тут ещё нужно учитывать страну: в английской версии сайта может быть другой текст в пользовательском соглашении, нежели в русскоязычной, так как и законодательство отличается. Учесть требования законодательства = уберечь заказчика от штрафов, которые могут доходить до полутора миллионов рублей.
Об этом написана отдельная статья на нашем сайте
Спросить про связи. Правильное устройство базы данных сайта убережёт вас от нескончаемого рефакторинга, который часто нужен из-за обнаружения новых ограничений в бизнес-логике. Поэтому проясняйте всё, что касается БД.
Пример из практики: год назад мы делали простой корпоративный сайт для крупного автомобильного холдинга. Снаружи сайт ничем не примечателен, но вот админка… Когда мы «залезли» вглубь бизнес-процесса, а именно — размещения информации на сайте, мы нашли огромное поле для создания удобной панели администрирования сайта. Представьте: у холдинга больше 10 автобрендов в трёх разных городах. Есть бренды, у которых несколько дилерских центров в городе. И всем этим царством со стороны сайта управляют маркетологи, которые, к нашему сожалению, связаны то с дилерскими центрами, то с автобрендами, то с автобрендом в конкретном городе… И все они сидят в админке одного сайта, видят только свою вотчину и, кстати, ещё ничего не сломали. Продумать эту систему помогли вопросы: может ли один бренд быть представленным в двух дилерских центрах, может ли один маркетолог работать на два города? Если переводить на язык БД, то так мы проясняли связи: m2m, o2o, m2o — это помогло нам спроектировать гибкую базу для сайта. А если бы не спросили, то переделывали бы много раз.
Уже хорошо — а как сделать лучше?
Помните, в начале статьи я говорила о том, что все уважающие себя веб-разработчики без подготовки не идут писать код? Так вот, добавьте аналитику бизнеса в первый этап — так вы получите концентрат пользы. Польза выражается в обоснованном составе MVP, окупаемости и востребованности продукта.
У нас в компании первый этап называется ППО (предпроектное обследование), название нагло позаимствовано у наших партнёров (Agima, привет!). Состав ППО у нас следующий:
Аналитика на трёх китах: Бизнес, Целевая аудитория и Конкуренты.
Прототипы уникальных страниц сайта.
Визуальная концепция – мудборды, видео, подборки референсов. Тут мы ещё экспериментируем. Главная задача визуальной концепции – передать атмосферу, дизайнерскую задумку, нарисовать картинку у заказчика в голове.
Семантическое ядро.
Техническое задание на разработку сайта.
Смета с почасовой оценкой каждой фичи.
Честно сказать, мы 12 лет выводили идеальный рецепт предпроектного этапа. И вот так вот просто сейчас делимся с вами. :)