Как сделать тз

Добавил пользователь Алексей Ф.
Обновлено: 05.10.2024

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

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

Чтобы таких последствий избежать, Вам необходимо техническое задание на разработку сайта.

чТО ЭТО И ЗАЧЕМ НУЖНО

Неважно, кто будет исполнителем сайта – Вы сами, Ваш родственник, фрилансеры за скромную оплату, специализированная компания за огромную сумму денег…

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

Техническое задание (коротко “ТЗ”) – это документ, который максимально подробно и однозначно отражает требования к Вашему будущему сайту.

Сайт создают именно на основе ТЗ. Чем более подробным и однозначным оно будет, тем больше Ваш новый сайт будет соответствовать Вашим ожиданиям.

ТЗ на создание сайта – как закон, не должно допускать трактовок и разночтений.

Всё, что не прописано в ТЗ разработчик делает на своё усмотрение. И, как показывает практика, его усмотрение сплошь и рядом не будет совпадать с Вашим.

1. Кто пишет ТЗ

Кто должен составлять техническое задание на разработку сайта? На этот вопрос есть только два варианта ответа: заказчик или исполнитель.

И это логично, кроме одной тонкости – смысл в составлении ТЗ для Вас и для разработчика разный, а от этого разные подходы и требования к нему.

Понять, какой именно сайт Вам нужен;
Зафиксировать бюджет (иначе Вам потом выставят счёт, мама не горюй);
Контролировать разработчика (сроки, объём работ, функционал, переделки и т.д.).

Понять и с первой попытки удовлетворить заявленные Вами пожелания;
Избежать бесплатных доработок и корректировок.

Таким образом, Вы оба – и заказчик, и исполнитель сайта, заинтересованы прийти к максимальному пониманию.

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

2. Бриф на разработку сайта

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

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

ТЗ на разработку сайта можно составить только на основе Ваших пожеланий и никак иначе.

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

Бриф – это анкета с вопросами о содержании, дизайне, технических возможностях Вашего будущего сайта.

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

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

Если отдельные пункты вызывают затруднения, то не стесняйтесь задавать разработчику вопросы по типу “Что это значит?”, “Как это повлияет на работу моего сайта?”, так как не все разработчики под одним понимают то же самое, что и Вы.

Либо в графе “Дополнительная информация” обязательно укажите все Ваши пожелания, не вошедшие в ответы на вопросы. Если эта графа отсутствует, просто допишите их в конце брифа. Главное не оставлять недосказанности.

Основа технического задания

Ещё не определились, кому доверить создание Вашего сайта? Можно написать техническое задание самому, разослать его нескольким потенциальным исполнителям и сравнить их ценовые предложения.

Имейте ввиду, что у Вас получится только основа, набросок технического задания.

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

В последствии техническое задание будет неоднократно редактироваться обеими сторонами. Это нормальный рабочий процесс.

Предпроектное проектирование

Этот пункт является неотъемлемой частью технического задания на создание сайта, хотя фактически он к нему не относится.

Дело в том, что после того как Вы заполнили бриф, подписали техническое задание и разработчик изучил всё это (включая рынок и конкурентов), то он делает предпроектное проектирование.

Предпроектное проектирование – это создание прототипа Вашего сайта, его скелета, который потом будет обрастать дизайном, контентом и функционалом с фишечками.

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

А так как этот процесс занимает не один день, то логично, что компании, которые делают проектирование до договора, просто показывают Вам шаблон в формате “как у всех”.

И да, сам прототип можно сделать с помощью обычных листов бумаги и цветных фломастеров.

Каждый лист – отдельная страница сайта (или экран одностраничника). Либо можно воспользоваться простыми офисными программами вроде Microsoft World или Microsoft Excel.

Лично мы при разработке landing page используем специальные программные продукты.

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

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

Интересно. Не забудьте установить на сайт систему комментирования. Так пользователи смогут делиться своим мнением и даже подталкивать к покупкам других посетителей (а еще это положительно влияет на SEO). Кликайте и узнавайте подробнее -> Сackle

ЛАЙФХАКИ ПО СОСТАВЛЕНИЮ ТЗ

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

1. Где взять сайты-образцы

Хорошим помощником могут стать широко представленные в сети рейтинги и ТОПы Интернет-ресурсов.

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

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

Но слепо не копируйте, наш российский менталитет всё-таки отличается и это не просто слова.

2. Как определить цветовую гамму

Задача облегчается, если у Вас есть готовый бренд-бук или чёткий фирменный стиль.

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

Не лишним будет немного изучить вопрос восприятия цвета в рекламе. Или обратиться в Google за помощью.

Для этого открывайте кртинки по запросу “цветовые подборки” или вводите название цвета, который хотите взять за основу, а далее выбирайте понравившиеся и прикрепляйте к Вашему тз для дизайнера.

Цветовые подборки

Секрет. Подкрутит первые отзывы, оценки и прочие поведенческие факторы на Вашем сайте и тогда остальные пользователи будут к Вам более лояльны. Рекомендуем для накрутки TaskPay, сами им пользуемся. Кликайте -> TaskPay

3. Как подобрать шрифты для сайта

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

ОШИБКИ ПРИ НАПИСАНИИ ТЗ

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

Поэтому выделяю самые основные из списка, те, что у Вас с вероятностью в 80% будут, если это Ваша первая разработка тз.

Важно. Допиливать сайт до идеала, конечно, хорошо, но многие забывают про самое главное – систему оплаты. И наш выбор – Yookassa. Внедряется легко и есть решение для отправки чеков в налоговую. Кликайте -> Yookassa

1. Нет ограничений во времени

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

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

Особо педантичные заказчики выставляют сроки разработки по каждому разделу сайта.

2. Утрата данных доступа

Как правило, на разработчика прицепом ложится регистрация доменного имени и хостинга для сайта.

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

И в один прекрасный день сайт просто перестаёт работать, потому что вовремя не продлили хостинг или доменное имя. Адреса сайта так и вовсе можно лишиться.

Поэтому запомните, что данные доступа к хостингу и доменному имени – это Ваши личные данные.

Распечатайте их и бережно храните вместе с важными документами. А лучше после разработки поменяйте все доступы, ведь всякое бывает, в той компании тоже существует человеческий фактор.

3. Отсутствие наглядности

Принцип “лучше 1 раз увидеть, чем 100 раз услышать” работает здесь на полную. В одни и те же слова заказчик и исполнитель могут вкладывать разный смысл.

И наверное эта ошибка вообще должна стоять на первом месте нашего хит-парада, так как такая картина происходит постоянно: “Хочу абстракцию”, – пишет заказчик, подразумевая нечто подобное (пример на картинке ниже)

Абстракция – вид заказчика

“Ок, держите”, – говорит разработчик. И предлагает заказчику абстракцию следующего вида.

Абстракция – представление исполнителя

И попробуй потом докажи, что Ваша абстракция абстрактнее его. Каждый прав, никто не виноват.

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

4. Качественные прилагательные

Вспоминаем разряды прилагательных из школьной программы… Шучу 🙂 Если слово обозначает качество, которое может проявляться сильнее или слабее, то оно смертельно опасно для технического задания.

Например, красивый (кто-то может быть ещё красивее или страшнее), умный, современный и т.п. Это слова-табу. Их нельзя однозначно понять. У каждого субъективное представление о красоте и современности.

Только конкретика. Например, “На два тона светлее”, “Смещаем на 5 сантиметров” или “Острые углы у кнопки”.

Кстати. Интегрируете CRM-систему с Вашим сайтом, чтобы посетители сайта сразу попадали к Вам в базу, так Вы не потеряете ни одного клиента. К тому же там много фишек, которые помогут сделать из сайта просто бомбу продаж и еще автоматизировать бизнес-процессы. Кликайте -> Битрикс 24

5. “На усмотрение разработчика”

Об этот коварный пункт спотыкаются многие. Заполняя бриф или составляя тз на дизайн сайта, не оставляйте в нём пробелов.

Вы должны понимать, что “На усмотрение разработчика” означает “что хочу, то и ворочу” или же “Всё, что не оговорено, выполняется на усмотрение исполнителя”. И поверьте, это не просто лазейка, а целое окно в Европу для разработчика.

И конечно, так происходит не всегда. Если Вам попался грамотный специалист, то можно не волноваться за результат.

Но тут возникает другая проблема, он может сделать реально как надо, а Вам не понравится чисто субъективно. И всё будет как в известном для многих разработчиков анекдоте:

КОРОТКО О ГЛАВНОМ

Вы точно не пожалеете о времени, потраченном на составление и согласование технического задания для создания сайта или лендинга.

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

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

Кстати. Создайте собственный сайт через конструктор за один день и без программистов. В арсенале готовые шаблоны, мобильная версия, корзина, платежи и еще +10 инструментов. Кликайте и тестируйте -> InSales (по промокоду “inscale” +30 дней бесплатно).

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

Красивая картинка для обложки статьи — будет отлично смотреться при шейринге везде! Используйте этот лайфхак :) by designers from Dupers!

В этой статье я поделюсь советами и приемами, которые я использую в работе сам: как составить ТЗ так, чтобы вашим коллегам, подрядчикам, партнерам было приятно и комфортно принимать и осуществлять ваши задачи. А это залог эффективной командной работы, выполненных планов, заработанных денег. Поехали!

Баннеры для
Верстка на странице цен

Сделать ХХ ресайзов готового дизайна под площадки для
Сделать адаптивную верстку личного кабинета для

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

Если вы ставите задачу партнерам и вы не рулите приоритетами их задач, то обязательно уточняйте, когда ее смогут выполнить.

Описание задачи необходимо для крупных и объемных задач, где нужно передать весь контекст проекта и понимание ситуации. Обычно описание задачи состоит из нескольких логичных последовательных блоков (это важно!):

Краткое описание проблемы и ее масштаба
Видение ее решения (или описание конкретных действий)
Профит и польза проекту/команде/всем от выполненной задачи

Но помните, что не нужно писать летописи-лонгриды из ваших user story при описании багов. Краткость — сестра таланта. Плюс текст отформатированный, с расставленными акцентами, логично распределенный на абзацы.

IT-шный пример

Заголовок: Задать подготовленные мета-данные для страниц сайта

Мы обнаружили, что на сайте не сформулированы titles & meta descriptions. У части страниц они не заполнены, половина страниц — дубли, а оставшаяся часть сформулирована без использования ключевых слов и некликабельно. Это критическая ошибка, так как без корректных мета-данных сайт не может расти в поисковой выдаче.

Мы составили таблицу в Google Docs с прописанными мета-данными для каждой статической страницы сайта, а также с шаблонами для динамически генерируемых страниц. Ссылка на документ: . Так как у проекта нет админки, где мы могли бы все настроить своими руками, просьба вставить метаданные из документа на страницы сайта:

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

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

Дизайнерский пример

Заголовок: Разработать landing page для

К нам обратились ребята из ХХХ. Они организуют ивенты и тусовки для крупных компаний, и за два года стали лидерами. Текущий лендинг — унылое говно и не соответствует их компании.

Мы узнали собрали всю инфу и контент у клиента:

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

Помни: рисуем mobile-first, так как 90% трафика — мобильные устройства!

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

Некоторые из советов (вроде написания заголовков задач) вообще не требуют дополнительного времени на постановку, а вот насколько развернутые и детально описанные должны быть ТЗ — определяет контекст задачи. Перед постановкой задачи обязательно:

Поймите, насколько исполнитель знаком с проектом, для которого делается задача?
Учитывайте, делал ли он раньше аналогичные задачи с вами или вообще с кем-то
И если есть сомнения, что вы хорошо друг друга поймете — созвонитесь и синхронизируйтесь

В результате вы сэкономите всем время, нервы, быстрее и круче решите задачу, получите каеф от гладкого процесса.

Еще небольшая фишка: когда задача уже сформулирована по феншую. Ее нужно ПРОДАТЬ исполнителю:

Привлечь внимание
Вызвать интерес
Вызвать желание
СДЕЛАТЬ ЕЕ

Прямо по канонам AIDA получается, да? :)

Хороший пример:
Вася, привет! В процессе аудита сайта мы обнаружили серьезную ошибку — которая мешает росту сайта. Нужна твоя помощь. Посмотри, пожалуйста, ее сегодня — !

Плохой пример:
Всем привет! Завели новую задачу:

Главное, сформировать у себя привычку писать задачи по феншую — это перестанет быть для вас стрессом, нагрузкой и перестанет занимать дополнительное время. Зато будет порядок в процессах и в эффективности работы!

15 топ-менеджеров , которые вывели свои компании на лидирующие позиции в рейтинге ESG.

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

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

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

Какие тренды проявились в онлайне

Мобильный трафик безоговорочно преобладает

По данным SlickJump, в 2020 году он достиг 80% в рунете. Это окончательно оторвало пользователей от привычных десктопов и заменило традиционные приложения на их веб-аналоги.

Упростилось и ускорилось изменение IT-продуктов

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

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

Изменились бизнес-модели целых отраслей

Компании запускают онлайн-каналы продвижения или полностью переходят в интернет.

Онлайн увеличил конкуренцию в бизнесе

Причем как количественно — за счет появления новых игроков, так и качественно — за счет расширения клиентской базы.

Итого: конкуренция усиливается, а цикл обновления и жизни продукта сокращается.

И что это меняет?

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

1) Подход с первоначальным проектированием всего продукта не обеспечивает необходимых скорости и гибкости.

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

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

2) Далеко не всегда клиенты четко представляют себе бизнес-модель своего продукта либо готовы тестировать и быстро адаптировать ее в соответствии с реакцией рынка.

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

Поэтому мы включили в цикл нашей работы этапы проработки продукта. Парадокс, но выйти на рынок можно быстрее, если на старте, еще до составления ТЗ, дополнительно пройти шесть шагов. Именно так работают Agile-команды: движение короткими итерациями и конкретные результаты каждого этапа. Ниже мы проиллюстрируем эти шаги (и допущенные ошибки) на примере нашего собственного продукта.

Шаг 1. Видение продукта

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

В результате получится концепция, которая состоит из трех разделов:

Product Vision — развернутое описание продукта.
Product Roadmap — дорожная карта по разработке.
Market Requirements Document — рыночные требования: как продукт будет выглядеть и работать.

Пример

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

Внутри команды их нет. Можно нанять консультанта. Но как определить его компетенции? На виду обычно те, кто активнее себя продвигает. Однако, навыки самопрезентации не равны профессионализму: часто бизнесу учат те, кто им никогда не занимался.

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

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

Шаг 2. Аналитика

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

оцифрованные данные исследования с детально описанными портретами ЦА;
обзор конкурентов;
список дополнительных требований к продукту.

Пример

Я провел более 20 проблемных интервью со знакомыми предпринимателями. Часто это был не запланированный опрос, а спонтанный разговор о том, что их беспокоит. Я обобщал информацию, находил причинно-следственные связи. Формировалась проблематика проекта: дефицит квалифицированных кадров, кризис доверия к консультантам, сложности цифровизации бизнеса и эффективной коллаборации для решения деловых вопросов.

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

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

Шаг 3. Генерация идей

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

список идей, отсортированный по значимости и данным Market Requirements Document. При отборе часто приходится опираться на интуицию;
при необходимости — изменения в Vision и Roadmap.

Пример

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

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

Шаг 4. Проверка гипотез

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

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

Если отработать процесс один-два раза, потом на этот этап будет уходить минимум времени.

Пример

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

Шаг 5. Формализация требований

На этом этапе составляют список функциональных требований к продукту — Product Requirements Document. Получится подробное описание функционала с кучей разных фич.

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

Пример

У нас получилось развернутое описание проекта на 40 страниц. Полный список функционала включает в себя создание цифрового образа каждого эксперта, открытого рейтинга экспертов, базы знаний, личного кабинета, модуля сбора и анализа статистики.

Шаг 6. Выделение MVP

Из всего набора требований выделяют критически важные функции, без которых нельзя запустить продукт. Если функционал сложный и нетиповой, при разработке ТЗ стартаперу может быть сложно учесть все детали и визуализировать результат, что потом грозит объемными доработками и внеплановыми расходами. Именно поэтому сначала рекомендуется разработать MVP.

На этом этапе выделяют:

описание рамок MVP (сценарии использования продукта, user stories — краткие требования к системе, написанные языком пользователя, а также функционал для первой итерации);
список метрик для оценки результатов.

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

Пример

Мы разработали MVP экспертной платформы с минимальным функционалом:

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

Клиент заполняет форму записи на консультацию.
Заявка попадает в Б24 к администратору платформы.
Он уточняет запрос и при необходимости помогает выбрать эксперта.
Согласует стоимость и время консультации с обеими сторонами.
Генерирует и отправляет клиенту ссылку на оплату.
После завершения консультации сумма за вычетом комиссии платформы перечисляется эксперту.

Наши факапы: что мы не учли и к чему это привело

Мы прошли шесть шагов до ТЗ, но все-таки допустили просчеты. Что можно было сделать иначе для лучших результатов:

Выделить время и собрать проектную команду

Я сам как владелец продукта разрабатывал концепцию платформы в свободное от других задач время. Мы привлекали сотрудников, занятых на других проектах. Разработка MVP затянулась более чем на полгода. Если бы работала выделенная команда, проект реализовали бы быстрее и проще.

Мы выявили и подробно описали боли ЦА — предпринимателей и экспертов. Но не убедились в том, что формат экспертной платформы наиболее востребован целевой аудиторией. Тестовая версия могла бы быть проще — не отдельный сайт, а группа на Facebook со списком услуг и конверсионной кнопкой или канал в Telegram с чат-ботом для записи на консультации.

Тратить меньше ресурсов на работу с экспертами

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

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

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

Что такое техническое задание?

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

Зачем нужно ТЗ

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

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

Также ТЗ формирует ожидаемый результат и дает возможность оценить результат проделанной работы.

Каким должно быть ТЗ

На самом деле, соблюдение четких правил при составлении ТЗ не требуется. Разные компании и предприниматели оформляют задания по-разному. Вопрос в преследуемых целях.

Кто-то за пару предложений излагает ключевую мысль и надеется, что работник сам додумает остальное:

А кто-то описывает все в деталях и структурирует каждый аспект:

Далее мы рассмотрим пункты, которые входят в базовый шаблон ТЗ.

Технические характеристики

Технические аспекты включают в себя четкие требования к оформлению задачи, которые не получится двояко интерпретировать.

В случае с текстами сюда можно отнести:

количество знаков на абзац,

тип и размер шрифта,

количество используемых ключевых слов,

правила структурирования текста с помощью подзаголовков,

необходимые форматы данных (таблицы, списки, цитаты и т.п.).

В техническое задание для программистов можно включить:

выбор системы управления данными (WordPress, Joomla и т.п.),

выбор фреймворков (React, Angular и т.п.),

количество всплывающих окон,

ширину контентной части страницы,

расположение форм обратной связи в приложении,

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

Маркетинговые характеристики

Характеристики, помогающие продвижению сайта, сложнее задать так же четко, как технические.

Заказчик рассказывает о целевой аудитории и ее особенностях. Задача исполнителя – воспользоваться этой информацией и сделать итоговый проект/текст наиболее привлекательным для указанной ЦА.

Этапы работы

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

Этап разработки идей и дополнение существующего плана действий.

Демонстрация первого прототипа.

Приемка первой тестовой версии продукта.

А/Б-тестирование визуальных компонентов и CTA-элементов.

Это примерная схема, которую можно менять на свое усмотрение, если есть четкие сроки выполнения задачи.

Другие аспекты

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

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

Срок выполнения работы тоже приписывается заранее, как и общий бюджет проекта.

Примеры ТЗ

Рассмотрим два абстрактных примера технического задания в том виде, в котором они часто встречаются.

Для разработчиков

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

Сайт должен быть выполнен в соответствии с указанным макетом. Цветовая палитра, расположение объектов, шрифты, текст и прочие элементы из Figma должны быть перенесены на итоговый проект.

Текст ТЗ может содержать более конкретную информацию об имеющихся функциях:

На сайте должна быть форма для загрузки файлов (только в форматах JPG, PNG).

Если пользователь долго бездействует (более 20 секунд), должен появляться робот-помощник (его функциональность описана ниже).

Под каждым материалом на сайте должна быть секциями с комментариями.

Также в ТЗ можно внести требования к дизайну и оформлению кода:

Списки должны быть оформлены в формате ul > li > a.

Блочные структуры должны быть реализованы с помощью свойства селекторов flex.

Отдельно можно указать технические средства, используемые в работе:

Работа должна быть доступна в репозитории my-new-project.

Каждое изменение должно сопровождаться отдельным коммитом.

В качестве базы данных используется технология MongoDB.

Для копирайтеров

Общие требования к тексту:

Статья должна быть поделена на части. Каждый подзаголовок отделяет один логический блок.

В тексте необходимо использовать одну таблицу и минимум один список.

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

В тексте должны быть подзаголовки второго уровня, минимальный промежуток между подзаголовками – 750 символов, максимальный – 900 символов.

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

Ключевые фразы должны быть равномерно распределены по тексту. Расстояние между ключевыми фразами не менее 1000 знаков. Первое ключевое слово должно использоваться в первом абзаце.

Объем текста: от 10 000 знаков.

Примерная структура текста:

Что такое WordPress.
Основные преимущества WordPress.
Сравнение WordPress с другими CMS.

Ключевые фразы:

WordPress (8)
Темы для ВордПресс (1)
CMS WordPress (2)
Для разработчиков (1)
Для новичков (2)
Как установить на сайт WordPress (1)
Joomla (2)
Drupal (1)

Вместо заключения

На этом все. Заносите в ТЗ все важные для бизнеса или проекта данные. Ставьте четкие требования и не допускайте разночтений, чтобы не возникало недопониманий и необходимости вносить срочные правки при приближении к сроку сдачи работы.

Читайте также: