Техническое задание — документ, который описывает, что именно должен сделать исполнитель, в каком виде сдать результат и по каким признакам работа считается принятой. Это не формальность для бухгалтерии, а единственное место, где зафиксированы договорённости, которые через 2 месяца обе стороны помнят по-разному.
Почти любой спор с подрядчиком сводится к одной фразе: «я думал, это входит». Задание существует ровно для того, чтобы такой фразы не было. Оно переводит ожидания в проверяемые формулировки: не «удобный сайт», а «форма отправляется, письмо приходит на два адреса, заявка попадает в таблицу».
Зачем нужен документ, а не устная договорённость#
Устная договорённость держится, пока обе стороны помнят её одинаково. На проекте длиной в 6 недель это перестаёт работать: у заказчика меняется представление о результате, у подрядчика меняется состав команды, и условие с первой встречи уходит вместе с человеком, который его слышал.
Вторая причина — сравнение предложений. Пока объём не описан, каждый исполнитель считает своё: один закладывает 5 страниц на готовом шаблоне, другой — уникальный макет и наполнение каталога. Разница в смете вдвое говорит не о качестве, а о том, что стороны посчитали разные вещи. Из чего складывается цена, разобрано в материале про стоимость сайта.
Третья причина — приёмка. Без перечня проверяемых условий момент «работа сдана» определяется настроением сторон и настойчивостью того, кто громче. С перечнем приёмка превращается в прогон по пунктам: проверили, отметили расхождения, назначили срок на исправление, подписали.
Есть и внутренняя польза. Пока задание пишется, вскрываются вопросы, которые иначе всплыли бы в середине работ: кто готовит тексты, откуда берутся фотографии, что происходит со старым сайтом в день переключения. Полдня на документ экономят неделю переделок.
Что обязательно входит в состав задания#
Минимальный рабочий комплект — 6 блоков. Первый: зачем всё делается. Одна-две фразы про задачу бизнеса, а не про технологию. «Принимать заявки на замер и передавать их в отдел продаж» — цель. «Сделать сайт на популярной платформе» — средство, и целью его подменять нельзя.
Второй блок — границы. Что в работу не входит: наполнение каталога, написание текстов, съёмка, перенос старых заявок, обучение сотрудников. Раздел с исключениями обычно важнее списка включённого, потому что споры возникают вокруг того, о чём промолчали.
Третий — состав работ по пунктам, с уровнем детализации «страница» или «функция». Четвёртый — технические требования: платформа, где всё размещается, обмен с учётной программой, поведение на телефоне, на чьё имя оформлены доступы. Пункт про доступы пропускают чаще прочих, а он определяет, останется ли сайт у вас после ссоры с подрядчиком.
Пятый блок — материалы и ответственные: кто и в какой срок передаёт логотип, прайс, фотографии. Просрочка со стороны заказчика двигает срок сдачи, и это стоит написать прямо. Шестой — приёмка: перечень проверок, срок на замечания и порядок их исправления.
Кто пишет задание: заказчик или подрядчик#
Смысловую часть пишет заказчик. Никто, кроме владельца бизнеса, не знает, как устроен приём заявок, кто их обрабатывает и что считается ошибкой. Техническую часть пишет исполнитель: платформа, способы обмена данными, ограничения. Подписывают документ обе стороны, иначе он остаётся чьим-то пожеланием.
Отдельная разработка задания как платного этапа — нормальная практика, особенно если проект сложнее сайта-визитки. Цену этого этапа запрашивают вместе со сметой проекта и сравнивают у нескольких исполнителей: она зависит от того, насколько глубоко подрядчику придётся разбираться в вашем процессе, а не от размера будущих работ. Сразу оговаривают и второе условие — результат передаётся вам в виде, пригодном для передачи другому исполнителю. Задание, которое нельзя показать конкуренту, написано не для вас.
Признак плохого документа один: формулировки без критерия проверки. «Современный дизайн», «быстро работает», «удобная админка» проверить невозможно, и на приёмке они превращаются в спор о вкусе. Каждый пункт должен допускать ответ «да» или «нет». Если ответа нет, пункт переписывают или убирают.
Если объём работ невелик, полноценное задание избыточно: хватит описания задачи на страницу. Как сформулировать её так, чтобы исполнитель понял с первого раза, разобрано в материале про постановку задачи разработчику.
Как принимать работу и обращаться с правками#
Приёмка идёт по перечню из задания, а не по общему впечатлению. Берёте пункты подряд и отмечаете «сделано» или «нет». Впечатление тоже важно, но оно обсуждается отдельно от приёмки, иначе работа не сдаётся никогда: желание что-нибудь поправить не заканчивается.
Разбивайте проект на этапы и принимайте частями. Макет, вёрстка, работающие формы, наполнение — каждый этап закрывается отдельно по согласованным критериям. Так ошибка обнаруживается на своём шаге, когда область переделки ещё ограничена, а не перед запуском всего проекта.
Порядок правок фиксируют заранее. Рабочая формула: 2 круга правок на этап входят в цену, дальше — по часовой ставке. Отдельно оговаривается, что считать правкой, а что новой задачей: смена цвета кнопки и добавление раздела с фильтрами живут по разным правилам.
Тревожные признаки во время работ: исполнитель показывает результат только картинками, отвечает «так нельзя» без объяснения причины, а сроки сдвигаются без новой даты. Любого из них достаточно, чтобы остановиться и письменно сверить понимание объёма.
Вывод: с чего начать своё первое задание#
Начните не с формы документа, а с двух списков: что входит и что не входит. Второй список пишется дольше и приносит больше пользы — именно в нём прячутся будущие споры про наполнение, тексты и обучение сотрудников. Оба списка хватит набросать в обычной таблице.
Дальше опишите результат словами, которые можно проверить. Простая проверка формулировки: представьте, что работу сдал незнакомый человек, а вы принимаете по написанному. Если пункт допускает два толкования, его перепишут не в вашу пользу. Переписывайте, пока толкование не останется одно.
Не гонитесь за объёмом. Задание на 4 страницы, где каждый пункт проверяем, работает лучше, чем документ на 40 страниц с общими словами. Большой текст никто не перечитывает на приёмке, а значит, он не защищает. Объём соразмеряют с ценой ошибки, а не проекта.
И согласуйте порядок изменений до старта. Проект без права на правки нежизнеспособен, проект с бесконечными правками не сдаётся: рабочий вариант находится между этими крайностями и записывается в документ до первого платежа. Иначе первая же спорная правка станет поводом для торга.