Маркетинг
2 июля 2019Как вести себя с подрядчиками, чтобы получить свой веб-проект вовремя
Если вы заказываете у подрядчика сайт, веб-сервис или мобильное приложение, сроки проекта зависят не только от него. Вы можете повлиять на то, чтобы это было быстрее. Как вести себя с подрядчиками, чтобы они не срывали сроки, какие функции нужно оставить на себе, а какие можно делегировать, рассказывает Юлия Бердникова, интернет-маркетолог агентства «Атвинта».
- Со сроками веб-разработки у компаний часто возникает какая-то беда: то пообещают быстро и затянут, то говорят какие-то нереальные даты и включают непонятные работы. Я расскажу, как заказчик может влиять на скорость процесса и помочь не срывать сроки.
В команде каждого проекта со стороны агентства есть аккаунт, проджект-менеджер, аналитики, дизайнеры, программисты. И есть еще одна роль, которую часто не учитывают, - заказчик. Да, это часть команды, и его роль наиболее важная:
- Это хранитель знаний о проекте. Он должен делиться информацией, без которой проект не сможет стартовать. Например, указывать цели разработки сайта, сервиса или мобильного приложения, рассказывать о бизнес-процессах компании.
- Это конечное лицо, принимающее решение. Подрядчик может предлагать, объяснять выгоду или даже настаивать на чем-то. Однако последнее решение за заказчиком, ведь именно его бизнес-задачи решает готовый веб-продукт.
- Это поставщик контента. Даже если тексты, фото- и видеоматериалы делает агентство, источником контента будет заказчик: предоставляет список товаров или услуг, рассказывает о миссии и ценностях компании, дает добро на проведение съемок на своей территории.
Разберем на примерах разных проектов возможности заказчика ускорить релиз продукта. Мы разделили все проекты на три группы: краткосрочные, с углубленной аналитикой и те, которые разрабатываются по принципу MVP. В каждом из этих вариантов есть аналитика, непосредственно разработка и согласование.
Краткосрочные проекты
Итоговый результат такого проекта можно описать практически сразу. Этапы аналитики и разработки занимают примерно равное время. Аналитика нужна, чтобы оценить ситуацию на рынке: что делают конкуренты и что нужно пользователям. В таких проектах основное время занимают подготовка контента и согласование с заказчиком.
Пример 1. Разработка сайта с личным кабинетом для фотостудии заняла чуть меньше 2 месяцев. Текст и фотографии для сайта заказчик заготовил заранее. При работе над личным кабинетом он рассказал о специфике работы с фотографиями клиентов в интернете. Благодаря вовлеченности заказчика в проект мы сразу запрограммировали приватное скачивание фотографий и оперативно сверстали дизайн с готовым контентом.
Пример 2. Разработка информационного сайта для производителей наружной рекламы. У компании очень много услуг. Каждой услуге соответствует отдельная посадочная страница. На каждой странице - текстовое описание, иллюстрации, фото с примерами работ. На таких сайтах очень многое зависит от контента. А точнее - от того, чтобы вовремя его предоставить. Нам передали список, описание и иллюстрации всех услуг, чтобы мы сформировали структуру сайта и наполнили его информацией. Сроки не затянулись.
А вот альтернативный пример - сайт для жилищного застройщика. С момента согласования дизайн-концепции до релиза сайта прошло 4 месяца. И все это время мы ждали от заказчика верные изображения планировки квартир и текстовые описания для наполнения разделов.
Создать такой контент самостоятельно, без участия заказчика, не выйдет. Этой информацией обладает только он сам.
Как заказчику повлиять на скорость разработки:
- Делитесь информацией. Расскажите максимум о своем бизнесе и клиентах, предоставьте список услуг или товаров.
- Давайте контент. Подготовьте заранее фотографии и текст для наполнения сайта. Если контент разрабатывает исполнитель, свяжите агентство с сотрудниками, со слов которых можно описать услуги. Дайте доступ для проведения фото- и видеосъемки.
- Согласовывайте вовремя. Подрядчик присылает на согласование техзадание, прототипы, дизайн-концепцию, макеты страниц и сам итоговый продукт. Изучайте внимательно, задавайте вопросы, обсуждайте то, что не нравится.
Проекты с углубленной аналитикой
В терминах проектной разработки их называют двухэтапными или waterfall-проектами. Зачастую это проекты, которые автоматизируют бизнес-процессы. Их нельзя сделать, придумав функции с потолка. На первом этапе подрядчик будет разбираться в сфере и специфике бизнеса компании. Потом - исследовать пользовательские сценарии, создавать прототипы, по которым отрисует дизайн будущего интерфейса. В таких проектах невозможно точно спрогнозировать, сколько времени понадобится непосредственно на программирование и верстку, пока не проведен этап аналитики.
Пример 1. Сервис учета сделок для компании, которая занимается аудитом, был создан за 3 месяца. Два из них ушли на изучение и описание бизнес-процессов.
Компания активно тестировала пользовательские сценарии, объясняла все нюансы работы, иногда отвергала предложенные нами очевидные решения, «потому что у нас так не сработает». Благодаря такой включенности проект сдали вовремя.
Антипример: разработка корпоративного портала с функциями системы постановки задач, планировщиком и мессенджером. Работа растянулась почти на год.
Основная проблема - на этапе прототипирования работал один представитель компании, а к моменту согласования подтянулись руководители смежных подразделений. У них были свое видение и пожелания. Пришлось снова погружаться в бизнес-процессы, отрисовывать интерактивные прототипы, согласовывать, учитывать противоречивые замечания каждой из сторон. Количество функций будущего продукта разрасталось, а срок аналитики вырос на треть.
В итоге через полгода мы остановились на варианте, который устраивал наиболее влиятельных представителей компании. За следующие 2 месяца задизайнили и запрограммировали систему автоматизации коммуникаций. Готовый продукт оказался настолько многофункциональным, что инструкция для пользователей уложилась в книгу. Внедрить веб-сервис заказчикам оказалось проблематично.
Как заказчику повлиять на скорость разработки:
- Активно участвовать в аналитике. Посвятите аналитика и проджект-менеджера в процессы компании, покажите, как все устроено. Это поможет подрядчику разобраться, как все работает сейчас и что должно улучшиться после разработки веб-продукта.
- Сразу тестировать на пользователях. Разрешите и организуйте тестирование интерактивных прототипов на реальных будущих пользователях. Так проще и быстрее поправить неудобные функции интерфейса, чем на стадии тестирования продукта или после релиза.
- Принимать решение одному человеку. Выделите одного ответственного за общение с подрядчиком и согласование. Это человек, который видит проект в целом, собирает все пожелания коллег, отсекает лишние «хотелки», оставляет на реализацию действительно важные функции.
Разработка по принципу MVP
Ситуации с раздуванием этапа аналитики можно избежать, если разделить весь проект на блоки. Сначала надо описать и запрограммировать основные функции. Остальные - наращивать на следующих этапах. Этот подход идеален для сложных многопользовательских веб-сервисов: уже с минимальным рабочим веб-продуктом заказчик будет получать прибыль или оптимизирует работу сотрудников.
Например, для корпоративного портала из прошлого примера такой подход позволил бы поэтапно делать и внедрять продукт.
Основная цель разработки корпортала - сделать удобной совместную работу сотрудников из разных городов и регионов. На первом этапе достаточно запрограммировать систему постановки задач и новостной раздел. После этого внедрить новую систему и узнать мнение сотрудников, чего не хватает корпоративному порталу. В следующих шагах добавлять те функции, которые повысят скорость коммуникаций и улучшат работу. Например, добавить внутренний мессенджер или планировщик задач в виде календаря.
Как заказчику повлиять на скорость разработки:
- Расставьте приоритеты. На этапе аналитики четко определите главную проблему, которую решает продукт разработки. Так будет проще выбрать, что реализовать в первую очередь, а что оставить на потом.
- Сначала главное, потом - фичи. Не настаивайте на новых функциях и фишках в текущей итерации до релиза первой версии.
- Согласовывайте внимательно. Особенно техзадание, прототипы и дизайн-концепцию. Оцените, решает ли результат главную проблему желаемым образом. Протестируйте удобство и понятность интерфейса. Если согласовывать машинально, получите не то, что хотели.
Вывод
Так что это получается: клиент платит подрядчику деньги за готовый веб-продукт, и ему же придется «поработать» на проекте? И да, и нет. У заказчика есть обязанности, от которых не отойти, и те, которые может взять на себя подрядчик.
Неизбежные обязанности заказчика:
- Рассказать видение: проекта, своего бизнеса, желаемой аудитории и результата.
- Согласовывать вовремя. От этого зависит, будет ли готово в срок и как вам нужно.
- Один проект - один представитель от вас. Чем меньше участников переговоров в процессе ведения проекта, тем быстрее приходите к результату.
Обязанности заказчика, которые можно делегировать подрядчику:
- Генерировать контент. Агентство напишет тексты, проведет фотосессию и сделает видео под общую концепцию веб-продукта.
- Исследования на пользователях. Аналитик проведет опросы о желаемых функциях или тестирование результатов на фокус-группе.
- Вам нужно будет только поделиться предпочтениями на старте и вовремя согласовывать. Это добавит стоимости проекту, но может сэкономить ваше время.