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

Года три вспять я воспринимал корпоративный веб-сайт – приблизительно на 20 страничек. Приемку назначили на вечер пятницы. Дизайн мне нравился, на телефоне ничего не разъезжалось. Я заполнил форму оборотной связи придуманными данными, узрел сообщение о удачной отправке и проверил, что цель в аналитике сработала. Опосля этого подписал акт.

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

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

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

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

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

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

2-ая неудача состоит в отсутствии метрики, поэтому что «чтоб сделалось больше клиентов» нереально ни проверить, ни оспорить. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5 обычных споров с подрядчиком

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

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

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

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

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

Принимать необходимо не странички, а работающий процесс

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

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

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