Без ТЗ результат ХЗ: как мы верстали без аналитики и уворачивались от недовольства клиентов

Сталкивались ли вы с ситуацией, когда клиент отказался от ТЗ проекта, а потом предъявил ряд требований? Мы в Webit работали с таким заказчиком и решили поделиться своим антикейсом, который может послужить уроком для других агентств. В этических целях мы не будем упоминать название компании.

Прежде чем погрузить вас в кейс, покажем, какие уроки вы сможете из него вынести:

1. Всегда и при любых обстоятельствах составляйте ТЗ. В случае недовольства клиента вы сможете показать документ, подписанный его же рукой. Так вы защитите себя как юридически, так и морально.
2. Не делайте скидки на маленькие проекты и если вы видите, что клиент всеми силами хочет сэкономить. Иначе вы рискуете уйти в минус.
3. Будьте готовы к манипуляциям. Они не должны вас сломить, тем более если вы можете подтвердить свою правоту документом.

Если спойлер вас не напугал, перейдем к главному.

Задача, которую перед нами поставил клиент

Летом 2023 года к нам обратился один из ведущих интернет-магазинов косметики с задачей сверстать дизайн, который подготовила другая студия. Изначально клиент не захотел обращаться к нам за полным комплексом услуг, так как ему не подошли расценки. Дизайн от другой студии получился действительно хорошим, но было видно, что заказчик хочет сэкономить на верстке.

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

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

Когда коллеги ознакомились с каждой деталью продукта и задали все интересующие вопросы, мы формируем ТЗ. Бывает, что клиент не хочет получать ТЗ, тогда по итогам аналитики готовим простенькое внутреннее техническое задание, на которое будут ориентироваться программисты и верстальщики.

Мы посчитали стоимость аналитики и верстки проекта. Когда начали согласовывать оценку с клиентом, он настоял, что от аналитики компания отказывается со словами:

«Чего там анализировать? На макеты смотришь и делаешь».

Так мы остались без ТЗ, но с макетами от дизайнеров.

В среднем аналитика составляет 15-20% бюджета проекта, которые клиент захотел сэкономить. Она создана для того, чтобы синхронизировать ожидания заказчика и представления исполнителя, каким должен получиться результат работ. Это позволяет избежать дополнительных временных и финансовых затрат на переделку работ от неверно сформулированных целей.

Было требование, чтобы мы сверстали дизайн за два месяца. Тогда мы сразу предупредили, что не сможем закончить работы в этот срок, но постараемся. Не успели бы мы из-за двух факторов:

1) Очень много разделов с непонятным неописанным функционалом, которые нужно отрисовывать.

2) Не было аналитики. Поняли, что придется постоянно обращаться с миллионом вопросов к заказчику или к дизайнерам. Работа из-за этого будет идти медленнее обычного.

Вместо составления ТЗ клиент предложил устраивать утренние созвоны и по 15 минут обсуждать каждую страницу. Это предложение мы посчитали неразумным и сначала отказались, так как созвоны — всегда дополнительные затраты по времени и дополнительные часы, которые не заложены для работы над проектом. Позже мы все-таки согласились на это предложение, но клиент не заплатил за дополнительные часы.

С какими проблемами мы столкнулись

1. Верстка макетов вслепую. Верстальщику передали макеты и он верстал их исходя из своего опыта, так как аналитики не было и мы не смогли прояснить все детали по каждой странице. У некоторых экранов была непонятная для команды логика работы.

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

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

Для того, чтобы хоть как-то выйти из недоброжелательного настроя, мы все-таки начали созваниваться ежедневно на 15 минут и выполнять «аналитику» без аналитики. ТЗ все равно не появилось. Мы пошли на уступки, так как очень хотели пополнить свое портфолио работой с этим заказчиком. Клиент сэкономил 15% на аналитике, но мы все равно использовали эти сэкономленные проценты, потому что иначе не получилось бы закрыть проект.

2. Сломанный телефон. Все свои вопросы по логике работы экранов мы отправляли лицу, принимающему решение (ЛПР) со стороны заказчика, а он перенаправлял нас в студию, которая занималась дизайном.

Когда мы доделали все страницы, то обнаружили около 300 правок, детали по которым не описывались до этого ни на созвонах, ни в проекте в Figma. Из-за этого у нас очень сильно сдвинулись сроки. Вместо начала октября мы сдали проект в середине ноября.

3. Требование работать по Bootstrap. На этапе продаж перед нами поставили условие использовать фреймворк Bootstrap. Особенность этого фреймворка в том, что в нем есть специальная сетка, которая вносит корректировки в размеры отступов и текста. Мы предупредили о том, что подготовленный дизайн может не соответствовать требованиям Bootstrap и скорее всего из-за фреймворка мы не сможем повторить дизайн точь-в-точь по сетке. Объяснили, что подготовленные макеты лучше верстать без использования фреймворка. Да, это будет дольше, но зато “пиксель в пиксель” как в Figma. Заказчик все равно настоял на своем требовании, так как он хотел все сделать максимально быстро. Плюс он озвучил, что если будут какие-то вопросы по дизайну, просто присылать ему.

Когда мы стали работать и закрывать страницы по Bootstrap, то ЛПР, увидев их, указал, что там большие отступы, не те размеры, спрашивал почему идем не по макету. Мы же при каждой сдаче страниц обращали внимание заказчика на ошибки и отмечали, что работать все будет не так как в макете из-за сетки фреймворка. Некоторые страницы дизайна просто не были готовы к верстке по Bootstrap.

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

У нас получилась не Pixel Perfect верстка, из-за чего клиент сильно возмутился, несмотря на то, что она не обсуждалась во время оценки и не была заложена в смете. Тогда мы поставили условие: либо нужно подправить макеты, либо работаем дальше и делаем с ограничениями Bootstrap. Сроки были крайне сжатыми и все переделать “пиксель в пиксель” заняло бы очень много времени.

Мы сошлись на том, что главную страницу, карточку товара, контакты доделаем в Pixel Perfect на HTML5 без фреймворка, но детальные и типовые страницы будем верстать, как позволяет Bootstrap.

4. Не стали заниматься SEO-оптимизацией. Недавно от клиента пришел пул вопросов о SEO требованиях и рекомендациях. SEO-специалист заказчика решил узнать, почему многие страницы сделаны не по SEO требованиям: дискрипшины, метатэги, h1, h2. Пришлось снова напомнить, что у нас нет ТЗ проекта и заказчик отказался от услуги SEO-сопровождения разработки, чтобы оптимизировать стоимость. На что клиент ответил: «Возможно, но я думал, что вы обладаете экспертизой в этом. У вас SEO — одно из ключевых направлений бизнеса судя по всем остальным кейсам и по продвижению». Мы действительно обладаем экспертизой в SEO-оптимизации и закладываем часы SEO-специалиста в каждый комплексный проект по разработке. Но если нашу команду привлекают именно на верстку и выделяют бюджет только под эту услугу, то мы работаем без привлечения специалистов из других направлений.

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

Что стоило сделать иначе нашей команде

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

ЛПР, который с нами работал — маркетолог. Он знал на что надавить, так как хорошо разбирался в e-com. На этапе пресейла он очень хорошо сторговался, и менеджер сделал ему скидку 5%, снизив ставку специалистов. В конечном счете, по проекту получилась большая переработка, мы вышли в минус.

Наша команда усвоила много уроков:

1. Проджект-менеджер понял, что с такими клиентами нужно быть более принципиальным и решительным. Стоит указывать на то, о чем договаривались на этапе оценки.
2. Для сейл-менеджеров — это урок не делать никакой скидки, если в процессе работы над проектом не составили ТЗ.
3. Формат ежедневных 15-минутных созвонов тоже должен быть учтен в оценке, даже если клиент до этого отказался от этапа аналитики. За все отработанное время заказчик обязан заплатить. В нашем случае этот момент был упущен, а дополнительное время проекту команда все равно посвятила. Кстати, его бы как раз хватило на написание ТЗ.
4. Теперь мы спрашиваем, принципиально ли клиенту использовать какой-либо фреймворк или требуется ли ему Pixel Perfect верстка. Обычно требование сделать дизайн «точь-в-точь» очень редкое.

Плюсы, которые команда вынесла из работы над проектом

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

Клиент, как и мы сами, вынес для себя из работы много важных вещей. Сейчас мы обсуждаем этап программирования. Теперь точно будем составлять четкое ТЗ и не пропустим этап аналитики. В этом убедился и сам ЛПР.

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