Доступы
Бриф — это анкета, по которой мы оцениваем задачу и считаем смету до подписания договора. Чек-лист из этой статьи — про другое: что нужно подготовить уже после подписания, к моменту, когда команда садится за работу. Бриф отвечает на вопрос «что делать». Чек-лист — на вопрос «что дать», чтобы делать это можно было без пауз. Проект с хорошим брифом, но без доступов всё равно стоит на месте в первую неделю: оценить задачу и начать её выполнять требуют разных вещей от клиента.
Хостинг, домен, CRM, аналитика — без них команда физически не может начать: не на что поставить сайт, не с чем его связать. Обычно тут теряется не время на выдачу доступа, а время на поиск: кто регистрировал домен три года назад, у кого пароль от аналитики, остались ли доступы у человека, который уже не работает в компании.
Если домен и хостинг ещё не куплены — это тоже не проблема, но об этом нужно сказать сразу, на старте, а не когда команда впервые спросит про DNS. Хуже, когда клиент думает, что доступы есть, и выясняет обратное только по факту запроса.
Отдельная история — CRM и другие системы, куда сайт будет отдавать заявки. Если интеграция согласована на словах, а доступ к CRM появляется только на этапе тестирования лид-формы, тестирование сдвигается — и вместе с ним сдвигается всё, что шло следом по графику.
Брендовые активы
Логотип в векторе (SVG или EPS, не скриншот из презентации и не логотип, вырезанный из PDF), гайдлайн, если он есть, и фотографии — свои, не стоковые заглушки, которые потом придётся менять постранично уже после запуска. Если фирменного стиля ещё нет, это нормально: мы делаем его сами, но тогда это отдельный этап с собственным сроком, который нужно учитывать в общем графике заранее, а не обнаруживать в разгар вёрстки, когда макет уже собран под несуществующий стиль.
Логотип в растре — частый случай. Растровый файл ограничивает то, как знак ведёт себя на разных фонах, в шапке сайта и в фавиконе, и на восстановление векторной версии уходит время, которое в графике не заложено, потому что задача формально считалась закрытой.
Фотографии — отдельный пункт, который недооценивают чаще всего. Хорошо свёрстанная страница с плохими фотографиями продукта или команды выглядит хуже плохо свёрстанной страницы с хорошими: фото первым бросается в глаза, и заменить его в последний момент часто негде.
Контент
Тексты, цены, характеристики товаров — то, без чего страница остаётся макетом с плейсхолдерами. Разработку и наполнение можно вести параллельно, но у параллели есть предел: страницу нельзя сдать без контента, который на неё ложится. Если текст для страницы услуги появляется через месяц после того, как страница свёрстана, вёрстка не экономит время — она просто ждёт, пока команда уже переключилась на следующий этап.
Особенно это касается интернет-магазинов: у карточки товара десятки атрибутов — размер, цвет, материал, наличие, срок доставки, — и когда часть из них выясняется уже на этапе выгрузки каталога, приходится возвращаться к структуре данных, которая казалась закрытой ещё на этапе проектирования.
Готовность контента не значит «всё написано идеально». Значит — данные существуют в каком-то виде: в таблице, в старой CRM, в head у человека, который знает цены наизусть. Довести их до финального вида на сайте — уже наша работа. Но если данных не существует вообще нигде, эту работу нельзя сделать быстрее, просто перекладывая её ближе к дедлайну.
Контактное лицо с полномочиями
Один человек, который отвечает на вопросы команды и подтверждает решения без похода наверх. Не обязательно самый занятой руководитель — важно, чтобы у него было право сказать «да» или «нет» без паузы на внутреннее согласование. На созвонах может присутствовать больше людей для контекста, но решение должен подтверждать кто-то один — иначе один и тот же вопрос обсуждается заново с каждым новым участником.
Без такого человека каждый вопрос превращается в цепочку: команда спрашивает, контактное лицо пересылает выше, ответ возвращается через несколько дней, иногда с новыми вопросами вместо ответа. Один такой круг — это несколько дней простоя. Три круга за проект — это уже недели, и они не видны на диаграмме до тех пор, пока не сложатся в сорванный срок сдачи.
Почему это не экономит время
Логика «начнём быстрее, доготовим по ходу» кажется разумной, но работает наоборот. Задача не исчезает оттого, что её отложили — она переезжает в середину проекта, туда, где уже идёт вёрстка и настройка интеграций. И там она стоит дороже: команда переключается на неё с уже начатой работы, ждёт данные, потом переключается обратно, теряя время не только на ожидание, но и на возврат в контекст, который был потерян при переключении.
Задержка при этом не поглощается запасом — потому что запаса на согласования в смете нет. Она переносится на график один в один: неделя без ответа на вопрос про доступ к CRM — это неделя, на которую сдвигается весь проект, а не только тот этап, где команда ждала ответа.
Готовность к старту — это не бюрократия и не способ переложить работу на клиента. Это единственный способ, которым согласованный график остаётся согласованным, а не превращается в список причин, почему сроки сдвинулись.
Дальше
Как мы строим работу над проектом от подписания до запуска, описано в разделе подход. Если вопрос ещё на стадии оценки задачи, а не подготовки к старту, — это к статье про бриф.
