Как вести себя с подрядчиками, чтобы получить свой веб-проект вовремя

Если вы заказываете у подрядчика сайт, веб-сервис или мобильное приложение, сроки проекта зависят не только от него. Вы можете повлиять на то, чтобы это было быстрее. Как вести себя с подрядчиками, чтобы они не срывали сроки, какие функции нужно оставить на себе, а какие можно делегировать, рассказывает Юлия Бердникова, интернет-маркетолог агентства «Атвинта».

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

В команде каждого проекта со стороны агентства есть аккаунт, проджект-менеджер, аналитики, дизайнеры, программисты. И есть еще одна роль, которую часто не учитывают, — заказчик. Да, это часть команды, и его роль наиболее важная:

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

Разберем на примерах разных проектов возможности заказчика ускорить релиз продукта. Мы разделили все проекты на три группы: краткосрочные, с углубленной аналитикой и те, которые разрабатываются по принципу MVP. В каждом из этих вариантов есть аналитика, непосредственно разработка и согласование.

Краткосрочные проекты

Итоговый результат такого проекта можно описать практически сразу. Этапы аналитики и разработки занимают примерно равное время. Аналитика нужна, чтобы оценить ситуацию на рынке: что делают конкуренты и что нужно пользователям. В таких проектах основное время занимают подготовка контента и согласование с заказчиком.

Пример 1. Разработка сайта с личным кабинетом для фотостудии заняла чуть меньше 2 месяцев. Текст и фотографии для сайта заказчик заготовил заранее. При работе над личным кабинетом он рассказал о специфике работы с фотографиями клиентов в интернете. Благодаря вовлеченности заказчика в проект мы сразу запрограммировали приватное скачивание фотографий и оперативно сверстали дизайн с готовым контентом.

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

А вот альтернативный пример — сайт для жилищного застройщика. С момента согласования дизайн-концепции до релиза сайта прошло 4 месяца. И все это время мы ждали от заказчика верные изображения планировки квартир и текстовые описания для наполнения разделов.

Создать такой контент самостоятельно, без участия заказчика, не выйдет. Этой информацией обладает только он сам.

Как заказчику повлиять на скорость разработки:

• Делитесь информацией. Расскажите максимум о своем бизнесе и клиентах, предоставьте список услуг или товаров.
• Давайте контент. Подготовьте заранее фотографии и текст для наполнения сайта. Если контент разрабатывает исполнитель, свяжите агентство с сотрудниками, со слов которых можно описать услуги. Дайте доступ для проведения фото- и видеосъемки.
• Согласовывайте вовремя. Подрядчик присылает на согласование техзадание, прототипы, дизайн-концепцию, макеты страниц и сам итоговый продукт. Изучайте внимательно, задавайте вопросы, обсуждайте то, что не нравится.

Проекты с углубленной аналитикой

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

Пример 1. Сервис учета сделок для компании, которая занимается аудитом, был создан за 3 месяца. Два из них ушли на изучение и описание бизнес-процессов.

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

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

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

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

Как заказчику повлиять на скорость разработки:

• Активно участвовать в аналитике. Посвятите аналитика и проджект-менеджера в процессы компании, покажите, как все устроено. Это поможет подрядчику разобраться, как все работает сейчас и что должно улучшиться после разработки веб-продукта.
• Сразу тестировать на пользователях. Разрешите и организуйте тестирование интерактивных прототипов на реальных будущих пользователях. Так проще и быстрее поправить неудобные функции интерфейса, чем на стадии тестирования продукта или после релиза.
• Принимать решение одному человеку. Выделите одного ответственного за общение с подрядчиком и согласование. Это человек, который видит проект в целом, собирает все пожелания коллег, отсекает лишние «хотелки», оставляет на реализацию действительно важные функции.

Разработка по принципу MVP

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

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

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

Как заказчику повлиять на скорость разработки:

• Расставьте приоритеты. На этапе аналитики четко определите главную проблему, которую решает продукт разработки. Так будет проще выбрать, что реализовать в первую очередь, а что оставить на потом.
• Сначала главное, потом — фичи. Не настаивайте на новых функциях и фишках в текущей итерации до релиза первой версии.
• Согласовывайте внимательно. Особенно техзадание, прототипы и дизайн-концепцию. Оцените, решает ли результат главную проблему желаемым образом. Протестируйте удобство и понятность интерфейса. Если согласовывать машинально, получите не то, что хотели.

Вывод

Так что это получается: клиент платит подрядчику деньги за готовый веб-продукт, и ему же придется «поработать» на проекте? И да, и нет. У заказчика есть обязанности, от которых не отойти, и те, которые может взять на себя подрядчик.

Неизбежные обязанности заказчика:

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

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

• Генерировать контент. Агентство напишет тексты, проведет фотосессию и сделает видео под общую концепцию веб-продукта.
• Исследования на пользователях. Аналитик проведет опросы о желаемых функциях или тестирование результатов на фокус-группе.
• Вам нужно будет только поделиться предпочтениями на старте и вовремя согласовывать. Это добавит стоимости проекту, но может сэкономить ваше время.