Заявка ушла не туда: как поставить задачу на разработку сайта и принять работу

Михаил Кремнёв

Эксперт по государственным и корпоративным закупкам, основатель ТендерОпоры

На следующий день спросил руководителя проекта, на какую почту приходят заявки. Он проверил настройки, открыл свой ящик.

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

С тех пор еще до обсуждения дизайна я спрашиваю: что произойдет после нажатия кнопки «Отправить»? Куда попадет заявка, кто ее увидит и что сделает дальше? Кто сможет изменить настройки, когда работа над проектом закончится?

Ответа «ну, заявка придет» мне уже недостаточно. Нужно договориться, куда именно она придет и как мы это проверим.

Почему просьба «сделайте сайт» недостаточно

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

Вторая беда состоит в отсутствии метрики, потому что «чтобы стало больше клиентов» невозможно ни проверить, ни оспорить. 

Без исходного значения, целевого показателя и срока непонятно, как оценивать результат.

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

Что я вписываю в бриф, чтобы потом не спорить о вкусах

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

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

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

О чем я спрашиваю подрядчика до начала работы

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

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

Приемка идет по этапам, а не одним вечером перед актом

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

Финальная приемка не имеет ничего общего с просмотром и вопросом «нравится или нет». Я прогоняю результат по пунктам брифа: цель, метрика, границы, сроки и доступы. «Кнопка некрасивая» ничего не объясняет, а «не нажимается в Safari на iPhone» объясняет все. Срок на замечания мы называем заранее, ведь у каждого свое «быстро».

Что я проверяю сам, даже когда подрядчик клянется, что все работает

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

Если аналитика входит в согласованный объем работ, я проверяю ее до приемки: есть ли у нас доступ, фиксируются ли тестовые события и корректно ли передаются предусмотренные данные

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

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

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

Пять типичных споров с подрядчиком

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

Разговор о результате лечится метрикой, согласованной до старта, иначе причины ищут по ощущениям. «Мы сделали больше, доплатите» лечится границами и правилом про письменное согласование работ вне объема. На случай сбоев после сдачи заранее определяем, что входит в гарантийные обязательства, кто отвечает за поддержку и куда обращаться.

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

Чем все это окупается

Хороший подрядчик конкретики не боится, потому что ему так проще работать. У него меньше шансов через полгода объясняться, почему получилось не то. Час на бриф, полчаса на доступы и час на приемку стоят дешевле переделки сайта, и проверено это не одним проектом.

Принимать нужно не страницы, а работающий процесс

Теперь перед подписанием акта я возвращаюсь к задаче, с которой начинался проект. Если сайт нужен для оптовых заказов, недостаточно увидеть красивый каталог и сообщение «Заявка отправлена». Нужно проверить, что данные попали куда следует, ответственный сотрудник получил их, а у компании остались доступы для дальнейшей работы.

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

Такая проверка не заменяет доверия к подрядчику. Она помогает нам одинаково понимать, что значит «готово».