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

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

Хорошая передача не обязана быть тяжёлой спецификацией. Её задача проще: убрать те пробелы, которые потом обходятся дороже всего. Чем раньше названы границы, материалы и проверка результата, тем меньше проект зависит от чужих догадок.

1. Сначала результат, потом граница

Самая важная строка в передаче — это простое предложение о результате. Что именно человек сможет сделать после завершения работы, чего не может сделать сейчас. Формулировка должна быть понятна не только команде, но и тому, кто оплачивает задачу. Если после запуска гость сможет заказать ужин в конкретных районах, это и есть результат. Если менеджер сможет менять цену без участия разработчика, это тоже результат.

Рядом стоит сразу написать, чего эта работа не включает. Например: оплаты пока нет, второй язык не входит, старый блог не переносим. Такой список не делает задачу жёсткой без причины. Он просто не даёт проекту расширяться во время каждого нового просмотра.

Ещё полезно заранее назвать одного человека, который принимает окончательное решение, если внутри команды возник спор. Не группу и не общий чат, а конкретное имя. Когда такого человека нет, разработчик рано или поздно начнёт выбирать сам, потому что срок не исчезает только из-за внутреннего обсуждения.

2. Материалы должны быть рабочими, а не примерными

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

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

Отдельно передайте адреса и доступы. Какая страница уже работает, что именно заменяем, какие URL нельзя потерять, потому что на них уже идёт реклама или поисковый трафик. Кто управляет доменом и хостингом. Как исполнитель получит доступ без пароля в общем чате. Именное приглашение или менеджер паролей здесь надёжнее обычной переписки.

3. Бизнес-правила нужно проговаривать явно

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

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

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

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

4. Приёмка должна повторяться по шагам

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

Такие проверки нужно выполнять не на живом сайте, а на отдельной копии. Иначе каждая ошибка становится публичной, а каждое исправление приходится делать под давлением. Если тестовой среды ещё нет, её создание стоит считать частью задачи, а не лишним дополнением. Почему это важно, объясняет материал почему не стоит править боевой сайт без отдельной проверки.

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

5. Язык, дата и записка для следующего человека

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

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

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

Когда звать помощь

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

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