Автор статьи
Дисклеймер. Эта информация может сильно удивить «олдскульные» студии веб-разработки. ТЗ на разработку сайта в его привычном виде не нужно — такой подход морально устарел. Здесь я имею в виду многостраничный документ, который досконально описывает архитектуру будущего сайта или его обновленной версии. Конечно, разработка по ТЗ лучше, чем «из головы» и без договоренностей, но у такого подхода тоже есть серьезные недостатки.
И еще: так называемый «продуктовый» подход в разработке, который упоминается в заголовке — это не какая-то альтернативная, еретическая школа разработки. Так можно назвать методологию, присущую продакт-менеджерам — специалистам, которые повышают бизнес-метрики популярных приложений и продуктов, исходя из гипотез, основанных на изучении пользовательского опыта. По наблюдениям последних лет, такой подход сильно повышает вероятность успешного запуска проекта. Это не что-то революционное — в интернете есть масса информации про JTBD-сценарии и важность UX-исследований, просто у таких статей другие заголовки.
И напоследок: если вам все-таки нужно составить ТЗ на разработку, в конце статьи я даю четыре рекомендации, которые вам помогут. Но прежде чем листать в самый низ, рекомендую полностью прочесть эту статью, чтобы у вас сложилось правильное представление о роли технических заданий для разработки сайтов.
А теперь расскажу, почему классические ТЗ — это плохо и поделюсь методологией эффективного составления ТЗ на разработку.
Какие проблемы есть у многостраничных техзаданий на разработку:
- Исчерпывающее ТЗ на этапе разработки заключает работу над проектом в лишние рамки.
Бывает, что в ходе разработки первоначальный концепт проекта перестает быть лучшим решением. Скажем, в ходе погружения в проект команда пришла к выводу, что сайту нужно реализовать другой функционал — он будет лучше соответствовать потребностям целевой аудитории. В лучшем случае работу над проектом придется пересогласовывать и переделывать. В худшем случае безынициативные подрядчики могут промолчать и доделать сайт по изначальному проекту.
Из этого следует другая проблема.
- Исчерпывающее ТЗ на этапе разработки пишется при слабом уровне погружения в проект.
Брифование клиента и предварительный маркетинговый анализ не будут полноценно отражать действительность. Чтобы хорошо понять потребности целевой аудитории, специфику ниши и эффективность продукта, нужно не просто погрузиться в работу над проектом, а выкатить MVP — минимально жизнеспособный продукт. Только работа над проектом и его «обкатка» со сбором обратной связи укажут на его проблемы и точки роста.
- Исчерпывающее ТЗ на этапе разработки может быть избыточным.
Здесь обратная ситуация: при разработке шаблонного интернет-магазина или лендинга можно обойтись и без подробного технического задания. Достаточно просто собрать требования заказчика и прислать прототип на согласование, не тратя время на лишнюю бюрократию и не изобретая велосипед. Так вы сэкономите время заказчика и его бюджет, выделенный на создание ТЗ для проекта.
Разработка сайта по многостраничному ТЗ полностью противоречит Agile — гибкой методологии разработки, которая является более современным и эффективным подходом к работе над продуктом. В манифесте Agile как-раз таки говорится, что готовность к изменениям важнее следования первоначальному плану, а сотрудничество с заказчиком важнее согласования условий контракта.
Если посмотреть на ТЗ с точки зрения клиентского сервиса, становится ясно, зачем оно действительно нужно — чтобы избежать лишних коммуникаций с клиентом и изменений в ходе действий. Потребность в ТЗ возникает из-за недоверия к заказчику — а что, если мы сдадим ему проект, а он захочет чего-нибудь другого, начнет нас мучить лишними правками и мы поработаем больше?
От этого можно обезопаситься: просто нужно согласовать стоимость рабочего часа и донести мысль, что гибкий продуктовый подход к разработке будет более эффективным, чем работа по заранее оговоренному плану. Тем более, что бюджет на разработку проекта можно спрогнозировать по показателям предварительно выполненных проектов. Нужно не занимать защитную позицию в переговорах с заказчиком, а работать с ним заодно.
При продуктовом подходе работу над сайтом глобально можно поделить на четыре этапа:
1. Клиент обращается к подрядчику с запросом на разработку продукта — это будет общее задание. Это документ, который редко бывает больше листа A4 — в нем описывается концепт продукта и фиксируются его ключевые метрики. При необходимости подрядчик помогает клиенту в формировании такого запроса.
2. Подрядчик формирует базу знаний о проекте, изучая информацию о рынке и проводя собственные исследования клиентской аудитории. Эта информация позволяет создать именно тот продукт, который поможет целевой аудитории решить ее задачи или «джобы», если вспомнить методологию JTBD (Jobs To Be Done).
3. По данным из базы знаний, информации о продукте, исследований аудитории и и первичного задания разрабатываются дизайн-проекты сайта в разной степени проработки и составляется функциональное задание. Примером дизайн-проекта может быть черно-белый прототип или макет сайта в Figma, а функциональным заданием — документ, написанный на языке, понятном для заказчика. Функциональное задание можно назвать более емкой и гибкой вариацией ТЗ, которая не описывает досконально архитектуру продукта, но раскрывает его основные модули и функции. Его же и используют для фиксирования договоренностей между исполнителем и заказчиком, а еще на него ориентируется команда разработки.
4. Отдельные технические задания, в которых детально описываются требования к решению конкретных задач. Например, техническим заданием может быть описание сущностей базы данных. Заказчикам эту информацию давать незачем — там будут использоваться сложные профессиональные термины.
Иногда такой подход к работе над сайтом может стоить дороже, чем разработка по предписанному ТЗ. При этом, бизнес получает продукт, который точно будет соответствовать требованиям пользователей и выполнять свои задачи более эффективно. В свою очередь, продукт по ТЗ может быть менее эффективным, за счет чего бизнес может ежемесячно упускать прибыль в миллионы и десятки миллионов рублей — зависит от его величины.
Читайте также: Как в разы поднять конверсию сайтов и приложений
В деталях продуктовый подход у разных студий веб-разработки может отличаться — скажем, у кого-то может быть не четыре этапа работы над продуктом, а шесть. Какой-то устоявшейся терминологии тоже нет — управление IT-проектами находится в постоянном развитии. Поэтому такая классификация этапов работы над продуктом является скорее методологией агентства Awake, нежели общепринятой практикой. Но одно ясно точно: гибкий подход к разработке с глубоким погружением в пользовательские сценарии дает более эффективный результат, чем работа по исчерпывающему ТЗ.
Далее подробно опишу все этапы разработки сайта и расскажу, какие технические задания могут понадобиться на каждом из этапов.
1 этап. Общее задание на разработку сайта
Общее задание — это запрос, с которым заказчик приходит в студию веб-разработки. Задача запроса: направить вектор для работы над проектом. Описывать его подробно не имеет смысла, потому что детализацией работ и стратегическим планированием должны заниматься профессионалы.
Если заказчик распишет свое виденье работы над проектом в большом ТЗ, оно будет неэффективным. Заказчик с большей вероятностью не будет разбираться ни в маркетинге, ни в разработке, а еще он вряд-ли проводил пользовательские исследования. Разработка сайта по готовому ТЗ от заказчика скорее всего обернется провалом, потому что на данном этапе никто не знает, каким именно должен быть продукт.
Что прописывается в общем задании:
- Цели ресурса. Например, повышение продаж, повышение лояльности клиентов, или повышение узнаваемости бренда.
- Какая метрика является ключевой. Оптимально в качестве ключевой метрики использовать так называемую «метрику Полярной звезды». В качестве этой метрики может использоваться любой показатель, который будет наиболее важным для продукта и на который можно будет ориентироваться при принятии стратегических решений. Например, у онлайн-кинотеатра «метрикой Полярной звезды» может быть LTV – срок жизни клиента.
- Какой основной функционал будет у сайта. Исходя из цели и выбора ключевой метрики будет ясно, что должен делать сайт и отразить это в общих чертах. Например, сайт может быть интернет-магазином, корпоративным порталом или онлайн-сервисом с определенной идеей.
Читайте также: Как измерять лояльность клиентов – самую жирную точку роста
Общие задания по разработке сайта можно разделить на два вида — они будут зависеть от назначения и функционала сайта:
- Сайт для торговли продуктами бизнеса и их продвижения. Сюда относятся интернет-магазины, сайты для заказа услуг компании, сайты-визитки и так далее. Их основными целями будет повышение коммерческого трафика и увеличение числа конверсий. Вокруг этих целей будет строиться общее задание: например, нужно сделать сайт, чтобы торговать бытовой техникой онлайн.
основатель агентства Awake
Довольно интересный пример среди наших проектов: сайт Zemexx. Это ресурс компании «Земельный Экспресс», которая продает земельные участки в Московской области. Ключевые цели, которые стоят перед сайтом — это увеличение конверсий и коммерческого трафика. Вот и все общее задание: сайт спроектирован таким образом, чтобы эффективно решать эти цели, исходя из специфики бизнеса и потребностей целевой аудитории.
- Сайт как самостоятельный продукт. В этом случае общее задание будет сфокусировано на идее сервиса и принципе его работы. Например: создать стриминговый сервис, чтобы люди покупали платную подписку для прослушивания музыки или соцсеть, в которой бы люди развлекались. Здесь ключевая метрика будет исходить от модели монетизации сервиса. Например, если это абонентская плата, ключевая метрика – срок жизни клиентов, ее нужно сделать высокой и повышать в дальнейшем.
основатель агентства Awake
Пример сайта-продукта: Isina. У этого проекта уже более объемное общее задание.
Ключевая метрика сервиса: количество платящих за премиум артистов.
Идея сервиса: помочь артистам стать заметней и получить шанс быть замеченным продюсером, лейблом или ментором. Стать заметнее = набрать больше рейтинга на Isina.
Цель проекта: чтобы карточка на Isina была важной частью для жизни артиста, который пользуется сервисом.
Для чего сервис нужен артисту:
- чтобы найти себе продюсера (стать заметным на Isina, чтобы заключить контракт с продюсером или лейблом, которые присутствуют на площадке);
- организовать единую платформу с продуктами деятельности артиста: музыкой, видео, мерчем, ссылками на сторонними площадками, ссылками на продажу билетов и так далее.
Сущности ролей в проекте:
- Артист (ключевой базовый);
- Премиум-артист (ключевой важный);
- Слушатель;
- Слушатель-эксперт;
- Ментор;
- A&R-менеджер, который представляет музыкальный лейбл и занимается подбором новых артистов.
Основная мотивация для артистов — так называемая история успеха «Золушки». Большое количество популярных артистов добились славы большим трудом, несмотря на невзгоды — эти истории транслирует сервис Isina, чтобы привлекать целевую аудиторию.
После того, как команде поступило общее задание, начинается сбор базы знаний о проекте.
2 этап. Сбор базы знаний о проекте
Сбор базы знаний — самый важный этап в работе над проектом. Именно этим сильно пренебрегают при разработке сайта по большому ТЗ.
Если продукт сложный, для достижения ключевой цели проекта придется глубоко изучить бизнес клиента, его рынок, а также целевую аудиторию и ее взаимодействие с прототипами и обновлениями сайта.
Важно: база знаний о проекте формируется непрерывно, на всех этапах работы над сайтом. Она будет обновляться даже после релиза сайта, если у него будут выкатывать регулярные обновления.
В большинстве случаев, существующей информации о продукте и рынке недостаточно: с этими знаниями не получится ответить точно, что именно нужно клиенту. Для этой цели проводят пользовательские исследования: проводят интервью и тесты вместе с целевой аудиторией, чтобы подтвердить или опровергнуть гипотезы касаемо содержания будущего сайта.
продуктовый дизайнер
Часто заказчики говорят, мол, нам не нужны исследования, сделайте сразу сайт, — не спешите. У заказчика зачастую может быть искаженное восприятие и ощущение что он знает о своих клиентах всё, но он может принимать желаемое за действительное.
Как минимум, всегда нужно проводить интервью с представителями заказчика.
Для некоторых проектов интервью с заказчиком, изучение отрасли и конкурентной среды может закрыть всю потребность в информации для сайта. Чаще всего так происходит в сфере B2B. Например, я работала с клиентом, который производит солнечные батареи для других компаний. Задача сайта в таком случае — просто рассказать о компании, последовательно передать информацию, а дальнейшую работу над сделками ведут менеджеры по продажам. Здесь не требовалось глубокого погружения в исследование потребностей клиентов для создания сайта.
Часто исследование бизнеса помогает увидеть новые аспекты, которые не замечались самим заказчиком.
К примеру, я работала над проектом для стоматологической клиники. Клиент утверждал, что ключевая аудитория — люди старше 50 лет, у них все очень запущено, потому что они боятся врачей, им требуется длительное и серьезное лечение. Однако в процессе интервью с сотрудниками клиник мы выяснили, что есть другой сегмент — клиенты от 35 лет, кто следит за здоровьем, не запускает лечение и регулярно посещает стоматолога. Это было открытием и для бизнеса. В итоге мы провели исследования двух групп, чтобы понять, какой функционал должен быть у сайта и как правильно подать услуги бизнеса для двух сегментов, а не одного, как планировалось изначально.
Но в B2C-сервисах и продуктах исследования скорее желательны и необходимы. Здесь хорошо сотрудничать с заказчиком в том, что он может знать сегменты своей целевой аудитории и выделить наиболее перспективные — а мы можем с ними общаться. Зачастую клиент знает свою аудиторию, но не знает ее глубоко — нужно брать у них интервью.
Например, мы делали сайт для курорта и организовывали глубинные интервью с клиентами, которые ездили на курорты: как они отдыхали, как выбирали отель, как доехали, что было после. Курорт предлагает огромное количество услуг (отели, горнолыжные склоны, рестораны, развлечения) и направлен на разные сегменты (семьи с детьми, спортсмены, пары). Из-за этого на выбор клиентов может влиять огромное количество факторов. С ними нужно общаться, чтобы исследовать их мотивы, потребности и предпочтения — никакой заказчик не может так глубоко и подробно знать свою аудиторию.
Исключения, при которых исследованиями аудитории можно пренебречь:
- Нужно сделать несложный продукт. Например, если нужно разработать лендинг для презентации товара, будет достаточно брифования заказчика, если он давно в бизнесе. Он расскажет о роли товара на рынке и поможет правильно расставить акценты для передачи смыслов на лендинге.
- Нужно сделать типовой продукт как у успешных конкурентов. Если задача – сделать привычный продукт для пользователей, как интернет-магазин, можно украсть юзабилити у конкурентов. Правда нужно быть уверенными, что они потратили достаточно времени на анализ рынка и продукта, чтобы не повторить их провал (о котором они могут и не догадываться).
Вся работа с информацией, предназначенная для разработки или улучшения сайта, относится к UX-исследованиям, которые никак не вписываются в рамки классического многостраничного ТЗ на разработку.
ведущий специалист UX-исследований Validata, департамент качественных исследований
Разработка, переработка или развитие сайта — один из самых частых запросов сейчас в исследованиях. UX-исследования — это большая дисциплина, в которой используются десятки разных инструментов и подходов. Постараюсь кратко передать суть этих работ.
Прежде чем идти исследовать запросы клиентов, мы всегда начинаем с внутреннего мозгового штурма. Так мы проясним, какой отдачи мы сами ожидаем от сайта и поймем — как выстроить исследование максимально продуктивно. Поймем, кого опрашивать и какие вопросы задавать. Также всегда полезны гипотезы о возможном поведении клиентов, а еще идеи по функционалу и интерфейсу сайта, которые мы уже можем им предложить.
Для внутреннего брейнсторминга мы используем схему «3+2». В нее входят:
- Триада главных вопросов: «Цели"-"Функционал"-"Контекст».
- Два вопроса реализации сайта: «Контент"-"Дизайн».
Цель.
Для определения цели нужно ответить на вопросы:
- Почему вообще возникла мысль что-то сделать с сайтом?
- А можно ли обойтись без него?
- Если уже есть работающий сайт — чем он нас самих, как компанию не устраивает?
Если разобраться, бизнесу может быть достаточно паблика в соцсетях или других каналов для взаимодействия с клиентами. Может, зацепил и вдохновил какой-то сайт конкурентов или любой другой компании? Не беда, главное — помнить, что мы от эмоций переходим постепенно к вопросу: для кого и как должен работать сайт?
Функционал.
После целеполагания определяемся с функционалом сайта — как по нашему мнению он должен работать. Например, если цель сайта — повышение продаж, нам нужен интернет-магазин или сайт с услугами, где клиента можно сразу вывести на онлайн/офлайн покупку.
После определения функционала мы выявляем все сегменты целевой аудитории и определяем: какие сегменты ЦА для нас наиболее интересны, какие сегменты еще не охвачены нашими коммуникациями и кого мы бы хотели привести в компанию.
Контекст.
Сайт всегда нужно рассматривать в контексте общего круга действий клиента: как один из элементов его информационного поля, а также один из инструментов коммуникаций и сервиса компании. Если смотреть сайт в отрыве от всей системы — это плохо, не будет понятна его истинная роль в продажах и построении доверия аудитории к бренду.
Чтобы решить эту проблему, мы должны ответить на эти вопросы:
- как клиент попадает на сайт;
- как он реагирует на сайт, к какому дизайну и интерфейсу он привык и насколько внешний вид нашего сайта будет совпадать с его представлением в картине мира клиента;
- куда клиент уходит после контакта с сайтом, захочет ли он здесь остаться или перейдет в более комфортную для себя среду — в соцсети, общение оффлайн или еще куда-то.
Далее мы делим целевую аудиторию сайта на сегменты и описываем гипотезы по каждому из этих сегментов. На основе гипотез мы создаем потребительские исследования.
Как мы описываем гипотезы: рисуем CJM, как мы его видим и отмечаем точки, где в пути клиента мог бы появиться наш сайт. Там же мы отмечаем другие каналы, с которыми клиент взаимодействует до, во время и после контакта с сайтом. Такими каналами могут быть контакт-центры, соцсети, чат-боты в мессенджерах и так далее.
Читайте также: Как создать CJM — карту путешествий клиента
Когда мы смотрим на путь клиента, мы отвечаем на вопрос: какую работу для клиента выполняет сайт? Понятно, что сайт дает некую информацию о нашем продукте и сервисе, но, на самом деле информация на сайте выполняет ряд различных задач. Например, сайт может помочь развеять сомнения в отношении качества продукта, и сформировать доверие к компании или бренду.
Контент и дизайн.
Работа с гипотезами по поводу контента и дизайна ведется параллельно. Мы формируем отдельные гипотезы относительно содержания сайта, представляя:
- какую информацию и в каком объеме ожидает получить клиент на сайте;
- какой интерфейс и стиль оформления близок и удобен для клиента.
Здесь нас могут поджидать сложности: например, если аудитория компании широкая и у нее различаются предпочтения по интерфейсу и дизайну. Но на данном этапе мы просто фиксируем это как потенциальную тему для размышлений.
После формирования гипотез, мы занимаемся анализом сайтов конкурентов и исследованиями клиентов. Эти два этапа можно делать последовательно или параллельно — все зависит от ваших ресурсов и срочности задачи.
Конкурентное исследование.
Чтобы изучить сайты конкурентов, мы используем чек-лист, в который входят волнующие нас параметры сайта. Он может быть как коротким, из 5−7 пунктов, так и обширным, с включением детального анализа интерфейса и функциональности сайта, а также его контента.
Исследование потребителей.
Чтобы лучше узнать клиентов будущего сайта, в зависимости от специфики проекта мы используем различные методы: от экспресс-чатов с 3−5 вопросами, до глубинных интервью и исследований, которые могут идти по часу, а иногда и проходить в несколько сессий.
С этими данными можно заняться разработкой нового сайта или обновлением существующего, понимая, что он будет эффективно закрывать потребности посетителей.
3 этап. Разработка дизайна и составление функционального задания
После того, как собрано достаточно данных для создания или обновления сайта, ведутся работы над дизайном будущего сайта и составлением функционального задания. В ФЗ отражаются возможности будущего сайта, а отрисовка дизайна позволяет оценить его внешний вид на наглядном примере. Работа над ФЗ и дизайном ведется параллельно — так гораздо удобнее достичь синергии между интерфейсом сайта и его функционалом.
Дизайн-макеты можно назвать техническими заданиями — по ним фронтенд-разработчик будет верстать сайт. Но разница в том, что они ведутся гораздо позже первичных переговоров с заказчиком и формируются из клиентских потребностей, а не идей, предложенных заказчиком и студией веб-разработки.
Работа над дизайном будущего сайта
Предварительная отрисовка будущего сайта в дизайн-макете тоже выполняет функции технического задания. По нему сайт будут проектировать фронтенд-разработчики. Также макет будущего сайта можно согласовать с заказчиком.
Существует три этапа разработки дизайна будущего сайта:
1. Набросок.
Изначально сайт изображают в виде черно-белой схемы, на которой изображены элементы интерфейса будущего сайта и его блоки с контентом. Так можно быстро изобразить структуру и расположение будущего сайта. За счет этого можно быстро представить общую картину и что-то подправить, не тратя на это много ресурсов.
2. Прототип.
Прототип — это интерактивная симуляция будущего сайта, которая позволяет протестировать пользовательский опыт. У прототипа будет менее детализированный дизайн, нежели у макета, зато с его интерфейсом можно будет взаимодействовать.
3. Макет.
Макет — это статичная иллюстрация будущего дизайна сайта. С макетом нельзя взаимодействовать, чтобы протестировать пользовательский сценарий, но можно оценить качество визуала. Несмотря на это, макеты можно использовать для исследований — пользователям можно показать несколько вариантов макетов и попросить выбрать лучший. В отличие от прототипов, макеты отражают окончательные версии дизайна будущего сайта.
Составление функционального задания
Функциональное задание (оно же функциональное описание или функциональные требования) — это документ, в котором перечислены возможности будущего сайта. Его можно сравнить с ТЗ, но в функциональном задании требования к сайту будут написаны простым языком, без профессиональных терминов. Оно может быть маленьким и частным, для какой-нибудь доработки, либо большим, общим и структурированным — для описания работы всего сайта.
Главная фишка качественного функционального задания в том, что оно состоит из пользовательских сценариев (user story), подкрепленных UX-исследованиями на этапе сбора базы знаний. То есть, функциональное задание — это описание простым языком, как должен работать сайт с точки зрения его будущих клиентов.
Приведу пример пользовательского сценария: так бы выглядел один из пунктов функционального задания для разработки какой-нибудь программы для управления проектами, скажем, как в «Trello». Допустим, нужно описать процесс: как проджект-менеджер, который пользуется этой программой, будет ставить одному из подчиненных новую задачу.
Создание новой задачи для существующего проекта:
- Проджект-менеджер открывает программу, выбирает нужный проект и переходит в него.
- Там он создает новую задачу, указывая ее название, описание и сроки выполнения.
- Он назначает ответственных за выполнение задачи и прикрепляет файлы, необходимые для выполнения задачи.
- Он сохраняет задачу и получает уведомление о ее успешном создании.
Так будет выглядеть пользовательский сценарий в упрощенной форме. Скорее всего, сценарий будет более детализированным. Например, в нем может быть прописана реакция приложения на нестандартное поведение пользователя. Скажем, если пользователь не даст название задаче, приложение само сгенерирует название по порядковому номеру номеру задачи или не даст пользователю сохранить задачу, чтобы он дал ей название. Но думаю суть ясна.
В чем преимущества описания функционала сайта через пользовательские сценарии:
- Их легко создавать на основе выводов из UX-исследований, CJM и JTBD-сценариев. Благодаря этому пользовательские сценарии – прямое отражение потребностей клиентов и их типичного поведения.
- Они отражают суть работы приложения. Это еще один камень в огород классического большого технического задания на разработку, которое описывает не «содержание», а «форму» будущего сайта – его технические требования.
- Их понимает заказчик. Функциональное задание в паре с дизайном сайта лучше вписываются в картину мира заказчика, нежели классическое техническое задание на разработку.
- По ним удобно тестировать сайт. Когда тестировщики проверяют сайт на работоспособность, они проходят разные пользовательские сценарии. Очевидно, что готовить чек-листы для проверки сайта гораздо проще по готовому пользовательскому сценарию.
- Не нужно быть разработчиком, чтобы ставить функциональное задание. Чтобы поставить техническое задание на разработку архитектуры сайта, нужно в большей или меньшей степени разбираться в веб-разработке. Чтобы дать функциональное задание, нужно знать, какие «джобы» должен выполнять сайт. Поэтому функциональные задания могут ставить продакт-менеджеры или интернет-маркетологи – как раз они смотрят на сайт как на продукт для решения потребностей пользователей.
Ко всему прочему, функциональные задания тоже можно использовать для фиксирования договоренностей с заказчиком и расчета стоимости проекта.
А теперь, внезапно, расскажу о технических заданиях.
4 этап. Техническое задание
Техническое задание в продуктовом подходе — это документ, который описывает архитектуру той или иной сущности в приложении. Если над сайтом работает один фулстек-разработчик, технические задания можно даже не ставить — он сможет работать по функциональному заданию. Все равно никто не опишет ему какое-нибудь API, да и незачем — он опишет его сам, если будет передавать проект. Техническое задание пишет технический специалист для другого технического специалиста, если в этом есть необходимость.
Глобально технические задания по разработке сайта можно поделить на два вида:
- Для фронтенд-разработки. «Фронт» – это видимая часть сайта, пользовательский интерфейс, контент, а также HTML-, CSS- и JavaScript-код. Фронтенд-разработчики «собирают» дизайн сайта и программируют вычисления сайта, которые работают на пользовательской стороне – в браузере. Технические задания для фронтенд-разработки делаются, когда есть готовые дизайн-макеты сайта или хотя бы их часть.
- Для бэкенд-разработки. «Бэк» – это бизнес-логика сайта, его вычисления на серверной стороне, которые происходят «под капотом». Бэкенд-разработка нужна для сайтов, которые взаимодействуют с данными. Например, если сайт: это статичный лендинг, который не собирает никакие данные, бэкенд ему не нужен. Если у лендинга будет форма обратной связи, из нее будут собираться пользовательские данные – можно сказать, что он с бэкендом
Как видите, чтобы составить грамотное техническое задание на разработку сайта, нужно самому разбираться в веб-программировании и точно знать, что именно требуется. Но если у вас есть острая потребность в составлении ТЗ, читайте рекомендации.
Как написать хорошее техническое задание: 4 рекомендации
- Составляйте ТЗ, исходя из бизнес-цели.
Например, вы решили интегрировать онлайн-чат на существующий сайт. Фактически, ваша цель — повысить количество обращений пользователей. Составьте и проанализируйте другие гипотезы: может, проблема низкого количества обращений в том, что пользователи плохо понимают ценность вашего продукта?
Попробуйте изучить системы веб-аналитики и спросить ваших клиентов, что они думают о вашем сайте с точки зрения удобства для пользователя. Если у вас есть обращения в техподдержку — обязательно их изучите. Возможно, будет больше толку, если вы проработаете контент на конверсионных страницах.
- Детализируйте ТЗ до того момента, при котором не останется разночтений.
Если вы передаете задание техническому специалисту, нужно конкретизировать ТЗ, чтобы он точно сделал то, что вам нужно.
Плохо: «добавить на главную страницу карусель, в которую можно будет загрузить популярные товары».
Лучше: «добавить на главную страницу карусель для товаров, которая будет выводить на экран 4 товара, вмещать в себя до 20 товаров и поддерживать скроллинг пальцем на смартфонах».
Хорошо: макеты дизайна для экранов с различными разрешениями и полноценное функциональное описание.
Это утрированный пример, но он отражает суть.
- Приводите иллюстрации и примеры.
Эта рекомендация особенно касается доработок со стороны дизайна — лучше показать, чем пытаться объяснить. Если вы не можете найти подходящего примера — нарисуйте схематичную иллюстрацию того, как вы представляете конечный вариант.
- Не используйте абстрактные формулировки требований.
Избегайте таких слов, как «яркий», «модный» — делайте ваши формулировки конкретными, а если они выражаются в численных показателях — измеримыми. Плохо: «нужно, чтобы сайт был быстрым». Хорошо: «нужно, чтобы сайт загружался со смартфонов не дольше трех секунд при интернет-соединении 4G».
Читайте также: Как запустить разработку сайта: разбираем каждый шаг
Надеемся, что эта статья помогла вам убедиться в том, что многостраничные технические задания — это плохой инструмент для создания сайта, который будет соответствовать потребностям клиентов. Если остались вопросы — пишите их в комментарии. Также подписывайтесь на новые статьи нашего журнала — у нас регулярно выходят экспертные статьи про маркетинг и работу над цифровыми продуктами 👇
на журнал
