Если вы заказываете у сторонних подрядчиков проект, в котором нет жестких стандартов качества, попробуйте работать по техническому заданию. Оно поможет в разработке сайта, дизайна, написании статей в блог или оказании других маркетинговых и IT-услуг. ТЗ конкретизирует пожелания.
Рассказываем, как составить ТЗ так, чтобы вас поняли, что в него стоит добавить, кто должен оформлять этот документ и какие есть нюансы и особенности.
- Что такое техническое задание
- Когда стоит составлять техническое задание
- Кто должен составлять техническое задание
- Сколько стоит заказать ТЗ
- Как написать техническое задание
- Шаблоны и примеры ТЗ
- Когда ТЗ не нужно
- Кратко — универсальные советы по составлению ТЗ
Что такое техническое задание
Техническое задание, или ТЗ — это документ, в котором фиксируются требования к проекту. Условно ТЗ можно назвать любое поручение исполнителю, главное, чтобы в нем были ясно прописаны характеристики итогового продукта.
| Это не ТЗ, а поручение | Сходи, купи хлеба |
| Вот это ТЗ | Мне нужен хлеб:
Другой хлеб мне не нужен. |
В первом примере мы даем поручение, которое исполнитель должен выполнить по своему усмотрению. Во втором явно указываем, что именно нам нужно. Идеальным решением во втором случае еще будет составление договора, чтобы техническое задание стало приложением к нему.
Когда стоит составлять техническое задание
Всё зависит от проекта и вашей бизнес-модели. Если проект маленький, вы доверяете исполнителю, и риск получить не то, что вы хотели, мал, можно обойтись устным поручением.
Если проект требует значительных для вас вложений, он связан со сложной IT-сферой, где много нюансов из-за особенностей технологий, или с творческой сферой, стоит зафиксировать требования в ТЗ.
- Вы проверяете отношение исполнителя к делу. Например, приходите к подрядчику без ТЗ, а он не пытается узнать подробности задачи и выяснить, что конкретно вам нужно. Это грозит потенциальными проблемами с результатом.
- Вы страхуетесь от недобросовестных подрядчиков. Если есть техническое задание, качество заказанного продукта можно проверить на соответствие требованиям — это аргумент для спорных ситуаций.
- Проще менять исполнителей. Разработка большого проекта, например, сайта или приложения, может длиться несколько лет. Если на старте вы поняли, что подрядчик не справляется, при наличии ТЗ проще отказаться от его услуг и найти нового. Экономя время на уточнение требований.
Кто должен составлять техническое задание
Устоявшейся практики нет — как договоритесь с подрядчиком.
Заказчик делает сам
Например, гендиректор студии архитектурной фотографии «АрхФото» Анатолий Шостак называет идеальным заказом ситуацию, когда заказчик сразу присылает подробное ТЗ и просит оценить работы.
В таких случаях мы точно знаем, что, как и когда нужно снимать. Соответственно, можем сразу рассчитать стоимость и сроки работ. Но в большинстве случаев заказчики не имеют точного ТЗ, потому что у них нет конкретного понимания, что именно нужно требовать от исполнителя. В таких случаях мы предлагаем им заполнить форму с наводящими вопросами.
Анатолий Шостак
Гендиректор «АрхФото»
Совместная работа
Процесс может выглядеть так: заказчик формулирует все требования к будущему продукту, заполняет бриф подрядчика по образцу, а затем на интервью согласовываются нюансы.
Техзадание полностью делает исполнитель
В таких ситуациях подрядчику ставится общая задача, а требования и обязательные функции к продукту он собирает с помощью разных источников — проводит интервью сотрудников заказчика, изучает потенциальных потребителей и конкурентов.
Совместная работа по составлению ТЗ и заказ задания исполнителю отличается в первую очередь подходом. Например, вы хотите заказать интернет-магазин:
- Совместная работа. Вы говорите исполнителю, что хотите сайт с аккуратным отображением на любых устройствах, с возможностью регистрации личного кабинета и сбора баллов. Подрядчик уточняет, долго ли хранятся баллы, как их будут использовать. И оформляет ТЗ в документ.
- Делает исполнитель. Вы ставите задачу — сделать интернет-магазин. Исполнитель с помощью бизнес-аналитика собирает и структурирует ваши требования к магазину, а также изучает конкурентов и целевую аудиторию, предлагает добавить в ТЗ требование отображать сайт на телевизорах — потому что ваши покупатели часто заказывают товары именно так.
Универсального решения нет, но лучше доверять составление ТЗ представителю подрядчика — специалист лучше знает, как должен работать его проект. Но при этом не стоит отстраняться от работы — объясните подрядчику, зачем вам продукт, как вы планируете его использовать, кто и зачем им будет пользоваться, покажите примеры решений конкурентов, которые вы считаете хорошими.
Сколько стоит заказать ТЗ
Если проект сложный, с большим списком функций и требований, техническое задание можно заказать за деньги. Это практикуется при создании сайтов и мобильных приложений. С готовым ТЗ можно не искать исполнителя самостоятельно, а открыть тендер.
Основатель компании по разработке информационных систем Work Solutions Максим Мул при заказе ТЗ рекомендует ориентироваться на 10-20 % от общей стоимости разработки продукта.
Не рассчитывайте получить качественное ТЗ бесплатно. Для его составления привлекают аналитиков, которые должны сформировать функциональные требования исходя из задач бизнеса и описать их так, чтобы не было пространства для двусмысленных толкований.
При этом ТЗ — это отчуждаемый документ, с которым может работать любой исполнитель. То есть вы можете заказать ТЗ у одних разработчиков, а затем обратится к другим. Главное, чтобы в ТЗ были описаны бизнес-логика и правила работы.Максим Мул
Основатель Work Solutions
Если речь про IT-задачи, например, интеграцию между информационными системами, внедрение CRM, разработку дополнительного функционала ПО или приложения по API, то не стоит рассчитывать на ТЗ стоимостью меньше 50 000 руб., считает гендиректор компании «Информатика и Сервис» Владимир Севрук.
Чтобы составить минимально ценное для клиента и понятное разработчикам ТЗ, аналитику нужно потратить минимум одну неделю на опрос всех сотрудников клиента, уточнить возможность реализации требований с разработчиками и в итоге свести всё в один документ.
Такие затраты микро- и малый бизнес в основном не могут себе позволить — заказ ТЗ актуален для верхнего малого и среднего бизнеса, когда IT-продукт в итоге существенно сократит расходы бизнеса и это будет выгодно.Владимир Севрук
Гендиректор компании «Информатика и Сервис»
Платные подробные ТЗ применяют и в других сферах. Например, в архитектурной фотографии.
У нас есть более сложная форма ТЗ — мы называем ее «сценарий». Для сценария мы проводим предварительные съемки, прописываем и согласовываем все ракурсы с заказчиком, прорабатываем целевую аудиторию и рассчитываем тайминг каждого кадра с учетом движения солнца. И все это ещё до начала чистовой работы.
Анатолий Шостак
Гендиректор «АрхФото»
За составление такого подробного сценария в «АрхФото» берут деньги. В зависимости от сложности проекта и требований заказчика сценарий иногда стоит дороже самой съемки. Зато благодаря ТЗ заказчик еще до начала работ понимает, что получит в итоге, говорит Анатолий Шостак.
Как написать техническое задание
Что конкретно стоит добавить в техзадание, зависит от продукта. Например, если вы заказываете партию одежды, нужно прописать особенности покроя, виды материалов и их качество, вплоть до примерной матовости поверхности пуговиц.
Если заключаете договор на разработку сайта, нужны сценарии его использования.
Пишите однозначно
Составляя ТЗ или описывая продукт подрядчику, старайтесь избегать качественных прилагательных. «Красивый» пиджак для одного человека будет приталенным, а для другого, наоборот, широкого покроя. Так и с любыми проектами: чем больше конкретики, тем лучше.
Хороший подрядчик будет конкретизировать и уточнять неоднозначные строчки в ТЗ, но это потребует дополнительного времени на переделку. Поэтому лучше стараться минимизировать недопонимание. И постараться определить для себя конкретные требования к продукту еще до разговора с исполнителем.
Бывает, что заказчик не знает, что конкретно хочет получить, причем часто сам того не осознавая. Из-за этого в ТЗ появляются расплывчатые и многословные формулировки. В итоге заказчик с исполнителем потратят значительное время на их уточнение. Эффективнее сделать ТЗ с конкретными и точными требованиями, без многословности.
Алексей Орлов
Руководитель проектов компании «Рексофт»
Стоит попробовать любые пожелания сводить к количественным требованиям.
| Не подходит | Подходит |
| Выводить на главной странице сайта популярные товары | Взять самые покупаемые товары за неделю и показывать их на первом экране сайта в блоке популярных товаров. С возможностью добавить товар в корзину за один клик. |
Дайте подрядчику общую информацию
Расскажите подрядчику, чем занимается компания, кто ее целевая аудитория, поделитесь нюансами работы — это поможет исполнителю лучше вникнуть в проект и избежать ошибок.
Гендиректор INOSTUDIO Максим Болотов рекомендует как минимум озвучить подрядчику идею проекта, который вы заказываете, уточнить, в чем его конкурентные преимущества и уникальность.
Расскажите подрядчику, какие задачи будет решать IT-решение. Это может быть увеличение прибыли, повышение узнаваемости бренда, лояльности пользователей. Уточните, кто будет пользователями продукта, их социальные и поведенческие характеристики, например, пол, возраст, интересы, семейное положение, потребности — это нужно, чтобы корректно и эффективно сформулировать функциональные требования к продукту.
Максим Болотов
Гендиректор INOSTUDIO
Помогите разобраться в терминах и нюансах
Подрядчик, как правило, специалист в своей отрасли, в вашей сфере он по умолчанию разбирается хуже. Поэтому помогите ему понять специфические термины или нюансы в техзадании.
Можно ввести отдельный раздел в виде словаря с расшифровкой или пояснять по ходу документа.
Покажите конкурентов
В ТЗ стоит добавить ссылки на аналогичные проекты и дополнить их описаниями: что конкретно нравится в аналогах, что стоит повторить, а чего точно стоит избегать.
Если заказчик планирует создать продукт, идея которого уже есть на рынке, то имеет смысл изучить конкурентов. Выявить отличительные особенности их IT-решений, чтобы разработать собственное с уникальными преимуществами.
К документу с видением продукта рекомендуем прикладывать ссылки на аналогичные решения. С описанием функциональных блоков, которые вам понравились. Это упростит дальнейшее общение с подрядчиком.Максим Болотов
Гендиректор INOSTUDIO
Уточните важные технические требования
Если вы делаете IT-продукт, стоит сразу согласовать все технические требования с вашим IT-специалистом и подрядчиками. Это необходимо, чтобы новое решение могло быть интегрировано в ваши имеющиеся платформы и бизнес-процессы.
Например, если вы заказываете интернет-магазин, важно, чтобы его движок мог принимать данные из всех ваших систем — не только обмениваться актуальными ценами с 1С, но и получать информацию из CRM и самописных сервисов.
О нюансах нужно предупреждать подрядчика еще во время обсуждения общего видения проекта и до составления ТЗ. Важно, чтобы исполнитель умел работать со всеми вашими технологиями.
Распишите сценарии использования продукта
Если вы делаете что-то стандартное, то так сильно погружаться в особенности продукта не стоит, это лишь запутает и добавит ТЗ многословности. Но в случае чего-то необычного попробуйте в техзадании отвечать не на вопрос «Что?», а на вопрос «Как будет делать пользователь?».
- Плохо — «Требование 1. На сайте есть корзина, пользователь по дополнительному запросу может получить список дополнительных товаров». В этом случае непонятно, что и как должно работать.
- Хорошо — «Когда пользователь заходит в корзину, сайт показывает ему всплывающий баннер. На этом баннере должны быть товары, которые могут пригодиться покупателю. Он может одним кликом добавить любой товар к заказу. Или закрыть окно». В этом случае понятно, как работает сценарий использования корзины и блока с кросс-товарами.
Если речь про IT-продукты, можно прописывать сценарии по такому шаблону:
- действие пользователя;
- ответ сайта;
- если пользователь делает так, то сайт делает так;
- если пользователь делает по-другому, то сайт отвечает так.
Опишите требования к проверке проекта
При составлении ТЗ отталкивайтесь не от абстрактных требований к продукту, в таком случае получится многословный и неструктурированный список желаний. Попробуйте вместо этого придумать условный чек-лист, по которому вы будете проверять успешность проекта.
Например, для интернет-магазина это может быть:
- Буду проверять корректное отображение в браузерах Chrome, Firefox, Mozilla трех последних версий.
- Отображение на экранах мобильника с разрешением 320 px на 480 px, монитора с разрешением 1024 px на 802 px, большого монитора с разрешением…
- Скорость разгрузки по сервису такому-то не больше 1 секунды.
Чем подробнее и длиннее чек-лист, тем лучше.
Двигайтесь от общего к частному
Старайтесь собирать требования к продукту от общего к частному. Если вы заказываете дизайн сайта, то сначала стоит рассказать про общую концепцию и пожелания по цветовой гамме. Затем рассказать, какие страницы должны быть на ресурсе. После перейти к описанию требований к каждому блоку на каждой странице. И в конце определиться с элементами в блоках: какой вид и размер шрифта должен быть у текста, как оформляются иллюстрации.
Шаблоны и примеры ТЗ
Универсального шаблона технического задания нет — требования будут отличаться в зависимости от отрасли и типа проекта.
Если вы решили составлять ТЗ самостоятельно, эффективнее попросить шаблон или пример у подрядчика. Или поискать брифы, которые предлагают заполнить исполнители у себя на сайтах — вопросы из таких форм можно использовать как разделы ТЗ.
Если планируете заказать IT-продукт, можно использовать за основу госстандарты. Например:
- ГОСТ 34. Это еще советская разработка сбора требований для создания автоматизированных систем. Не готовый шаблон, но много вопросов к заказчику, которые помогут структурировать пожелания.
- IEEE 29148-2011 — стандарт разработки сложных систем, в которых есть вопросы о требовании к функциям, а также рекомендация описать условия программного окружения, то есть платформ, которые будут работать вместе с вашим продуктом.
- Rational Unified Process — продвинутая спецификация для разработки требований к IT-продуктам. Много внимания отводится вариантам использования.
Эффективнее будет составлять ТЗ вместе с выбранным подрядчиком. Он будет задавать вопросы, уточнять нюансы и структурировать информацию. А вы объяснять, что же вам в итоге нужно от продукта.
Когда ТЗ не нужно
Не стоит самостоятельно составлять техническое задание для любого продукта — зачастую это излишняя работа, которая только запутает и станет бесполезной бумагой для подрядчика.
Эффективнее будет начать с общего понимания задачи — подумайте, что вам нужно от продукта, как его будут использовать, что в нем должно быть, а что, наоборот, точно стоит исключить. Опишите это с использованием не качественных, а количественных характеристик.
С этим пониманием обратитесь к подрядчику. Возможно, он предложит использовать не ТЗ, а гибкие методологии создания продукта — когда сначала делают небольшой прототип, выпускают его, а затем собирают обратную связь от первых клиентов и постоянно дополняют требования на основе этой аналитики. С таким подходом проект реализуется с учетом потребности клиента.
Вместо ТЗ выгоднее сначала сделать предпроектное обследование, изучить реальные потребности клиентов, вместе с аналитиком подрядчика. А затем решать, нужно ли ТЗ вообще.
Может быть, выгоднее и эффективнее выполнять бизнес-задачу, например, с помощью SCRUM. Действуя небольшими итерациями в 1-2 недели, анализируя результат и постепенно дополняя требования.Владимир Севрук
Гендиректор компании «Информатика и Сервис»
Кратко — универсальные советы по составлению ТЗ
Составляя ТЗ самостоятельно или с подрядчиком, придерживайтесь следующих правил:
- Если у вас большой и нестандартный проект, стоит изучить цены на составление ТЗ. Возможно, выгоднее один раз заплатить аналитику за создание подробного документа и открыть тендер среди подрядчиков, чем самому искать исполнителей и делать несколько ТЗ по их шаблонам.
- Прописывайте требования однозначно, используйте количественные, а не качественные характеристики.
- Поделитесь с подрядчиком общей информацией о компании и проекте — это поможет исполнителю лучше понять целевую аудиторию продукта и не допустить ошибок.
- Составьте для исполнителя словарь терминов из вашей отрасли, которые используются в ТЗ.
- Посоветуйтесь с IT-специалистами из сторонних отделов. Добавьте в ТЗ информацию о технологиях, системах и бизнес-процессах, в которые будет интегрирован новый продукт.
- Распишите сценарии использовании — сначала действие пользователя, затем результат, который должен выдать ваш продукт.
- Опишите требования с помощью чек-листа проверки — подумайте, как бы вы стали проверять готовый продукт.
Как писать ТЗ: инструкция по составлению грамотного техзадания
Содержание
Что такое техническое задание
Техническое задание — это то, с чего начинается качественный функциональный продукт. По крайней мере, если таковым является само ТЗ. Если документ будет составлен непрофессионально и без должного внимания, результат окажется соответствующим.
Учитывая характер целевой аудитории блога и общие тренды, скорее всего, имеет смысл описывать технические задания конкретно на цифровые продукты. Во многом так и будет, но нельзя забывать, что и самые обычные, «аналоговые», продукты тоже требуют документации. Они требовали её ещё до появления самого интернета. Поэтому для расширения кругозора и для пользы представителей нецифровых отраслей, стоит приводить отсылки и к оффлайн-проектам.
Для чего нужно техническое задание?
Техническое задание не менее значимо, чем юридический акт, в деле закрепления прав и обязанностей сторон — заказчика и исполнителя.
Фактически это инструкция для разработчиков, конструкторов и других непосредственных создателей конечного продукта. Но по сути техническое задание, определяя жёсткие требования к каждой детали, делает сотрудничество заказчика и исполнителя безопаснее и комфортнее.
Когда каждая мелочь регламентирована, всё на своих местах, все при своих полномочиях и обязанностях, остаётся мало пространства для нечестного манёвра и недопонимания. Идеально, когда его вообще не остаётся.
Более того, конкретное и целостное техническое задание — это первый шаг к качественному результату. Чтобы продукт работал чётко, без сбоев, да и просто безопасно — это тоже периодически стоит на повестке — все его элементы должны быть продуманы. Тщательно и скрупулезно.
Техническое задание — основа как простых односложных продуктов, так и высоконагруженных систем. В каждом случае сценарии функционирования должны быть предусмотрены. Любое действие пользователя должно быть предугадано, и ответом на него должен быть полезный результат.
Именно для того, чтобы работа с конечным продуктом вызывала положительный отклик пользователя и решала его задачи, необходимо проработать идею и детали проекта на самой ранней стадии.
Кто должен составлять техническое задание
Чтобы понять, как составить техзадание, важно определиться с тем, кто именно это будет делать. На этот вопрос нет однозначного ответа — ТЗ для задачи может составить заказчик или исполнитель, в отдельных случаях — это совместная работа.
Заказчик
В этом случае исполнитель будет четко понимать, что и когда ему потребуется делать. В результате получится точно рассчитать стоимость работ и срок, отведенный на их выполнение. Однако иногда составитель ТЗ не понимает того, что именно должен предоставить им исполнитель, из-за чего с составлением ТЗ возникают проблемы.
Исполнитель
Исполнитель, занимающийся составлением ТЗ, присылает заказчику бриф с вопросами по задаче. Так специалист выясняет цель работы и свою пользу для клиента. После этого проходит интервью, и в режиме диалога стороны уточняют рабочие нюансы. Исполнитель изучает конкурентов и целевую аудиторию, чтобы добавить эту информацию в техническое задание.
Такой способ составления ТЗ удобен, когда заказчик полностью доверяет исполнителю, а исполнитель достаточно компетентен, чтобы разобраться в задаче самостоятельно.
Совместно
Совместное формулирование ТЗ начинается с того, что заказчик озвучивает исполнителю требования относительно будущего задания. Подрядчик, в свою очередь, предлагает, как улучшить проект, и только после этого составляется техническое задание. Этот способ, как и предыдущий, работает на доверии, этичности и профессионализме сторон.
Как составить техническое задание
Главные требования к техническому заданию — это продуманность и полнота. Так как составители не всегда способны им следовать, были разработаны общие стандарты разработки ТЗ.
В вакансиях на должность системного аналитика или технического писателя можно встретить требование: знание ГОСТ 19 и ГОСТ 34. Из названия легко понять, что это общегосударственные стандарты, образцы разработки технических заданий на территории России.
Эти два ГОСТа имеют отношение только к программным комплексам — к сайтам, приложениям и системам автоматизации. Другие ТЗ придется писать по совершенно другим правилам.
ГОСТ
ГОСТ 19 был введён в 1980 году. Учитывая, что основные принципы программного обеспечения почти не поменялись, документ еще не утратил своей актуальности. Это можно сравнить со строительством зданий: меняются материалы и конструкции, но общие понятия — фундамент, стены, перекрытия — сохраняются.
Согласно тексту Постановления, согласно которому принят данный стандарт, назначение его следующее: «Устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения».
Само техническое задание должно содержать следующие пункты:
- Введение;
- Основания для разработки;
- Назначение разработки;
- Требования к программе или программному изделию;
- Требования к программной документации;
- Технико-экономические показатели;
- Стадии и этапы разработки;
- Порядок контроля и приемки;
- Приложения.
Более новый стандарт — ГОСТ 34, но он новее всего на 10 лет. То есть, введён с 1 января 1990 года.
Формулировка назначения выглядит так: «Распространяется на автоматизированные системы (АС) для автоматизации различных видов деятельности (управление, проектирование, исследование и т. п.), включая их сочетания…».
Текст технического задания строится по структуре:
- Общие сведения;
- Назначение и цели создания (развития) системы;
- Характеристика объектов автоматизации;
- Требования к системе;
- Состав и содержание работ по созданию системы;
- Порядок контроля и приемки системы;
- Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
- Требования к документированию;
- Источники разработки.
Разумеется, за прошедшее время подходы были пересмотрены. Введены новые правила и рекомендации. Сами ГОСТы перешли в разряд базовой опорной точки, а конечный результат остаётся на усмотрение составителей. Тем не менее, при работе с госзаказчиками необходимо брать за основу именно ГОСТ.
ISO/IEC/IEEE 29148
Разработанный Международной организацией по стандартизации ISO, данный современный стандарт пригоден для использования помимо всего прочего в международных проектах.
Последняя редакция — ISO/IEC/IEEE 29148:2018, но, к сожалению, она отсутствует в открытом доступе, поэтому возьмём за основу предыдущую, от 2011 года.
По аналогии с ГОСТами, стандарт содержит два раздела. Один из них, SyRS — System Requirements Specification — определяет общие требования к построению систем, их принципам и характеру взаимодействия пользователя с ними. По похожей схеме составлен ГОСТ 34.
SRS — Software Requirements Specifitaion — по аналогии с ГОСТ 19, содержит требования к конечному программному продукту.
Общая схема строится следующим образом:
- Введение. Информация о компании, которая пригодится при работе над проектом, назначение продукта или системы, содержание, обзор функций и пользователей.
- Ссылки на референсы. Примеры продуктов конкурентов, которые можно использовать для анализа слабых и сильных сторон, интересных решений.
- Системные требования. Требования к юзабилити и производительности системы, состоянию, физическим характеристикам, окружению и безопасности, правилам. Для приложений — требования к внешним интерфейсам, к производительности, структуре БД, функциям и юзабилити.
- Тестирование и проверка. Процедуры тестирование по каждому из пунктов предыдущего раздела.
- Приложения. Термины, схемы, история правок.
Порядок документирования требований
Выйдем немного за пределы тематики и скажем несколько слов о том, из чего состоит весь процесс документального сопровождения продукта. Ведь он не ограничивается техническим заданием. Сложность сопроводительной документации растёт вместе со сложностью и масштабом продукта.
Разработка лендинга на Тильде или запуск таргетированной рекламы Вконтакте радикально отличаются от создания высоконагруженной биллинговой системы банка. Если первые два продукта способен создать один человек, то последний может потребовать команды из нескольких десятков специалистов из многих областей.
Бриф
В основном, уместен в контексте продуктов низкой и средней сложности. Например, небольшой сайт, воронка продаж или даже копирайтинг.
Бриф обращён к заказчику и не предполагает жёстких финальных требований или детального описания результата. Выверенной должна быть только структура опросника. В него могут входить такие пункты, как:
- Цель и назначение продукта;
- Предполагаемый бюджет;
- Целевая аудитория.
Вопросов на которые отвечает заказчик, может быть до 20–30, но не более, иначе это становится большой нагрузкой. Задача брифа в том, чтобы получить общее направление для обсуждения.
Такой опрос удобно разместить на сайте, если он не сложный. Его можно запрограммировать или дать ссылку на Google формы. Либо просто разместите кнопку обратного звонка, чтобы задать вопросы и проконсультировать клиента прямо в режиме реального времени по телефону.
Виджет обратного звонка, как инструмент, подходит не только для созвонов с партнерами, но и для клиентского сервиса. Это всплывающее окно предлагает указать контактный номер,по которому перезвонит сотрудник поддержки. С виджетом обратного звонка от Calltouch вы можете собирать заявки даже в нерабочее время, а также записывать и тегировать звонки.
Виджет обратного звонка для сайта
- Повысьте конверсию сайта на 30%
- Новым клиентам 50 минут в подарок
Узнать подробнее
Технико-коммерческое предложение
Здесь речь заходит о действительно крупных проектах. В противном случае нецелесообразно прилагать излишние усилия к созданию подобных документов.
ТКП разрабатывается в рамках маркетинговых мероприятий, когда продукт предлагается потенциальным заказчиком. Если у вас есть собственная концепция, готовая к внедрению или масштабированию, на её основе можно сделать предложение.
Документ содержит не просто идею и общее описание, но некоторые технические подробности. На их основе заказчику удобнее принимать решение, так как он сразу может увидеть, насколько характеристики продукта согласуются с той инфраструктурой, которая есть в наличии.
Бесполезно предлагать промышленные системы вентиляции маленьким кофейням. В других случаях помещение может отвечать требованиям, но электроснабжение окажется несовместимым с требованиями оборудования по питанию.
Технические требования
Если в ТКП требования приводятся самые основные, для ознакомления, то при заинтересованности заказчика с ним составляются уже более детализированные перечни требований.
Техническое задание
Собственно, предмет статьи. Предварительные сведения даны в предыдущих пунктах, а ценные советы ждут вас в следующем разделе.
Технический проект
Этап «живого» проектирования продукта. Здесь начинаются активные действия по разработке решений согласно ТЗ. В ходе работы уточняются и проясняются отдельные нюансы, требования, доработки.
В соответствии с практическими наработками, составляются новые задания и требования — частные технические задания по отдельным подсистемам (ЧТЗ).
Эксплуатация
Важно помнить, что после сдачи проекта стороны распределяют между собой обязанности по поддержанию работоспособности системы. Это тоже должно быть прописано — например, в техническом задании, если не предусмотрено другого порядка.
Перед эксплуатацией и во время неё создаются различные регламенты, описания сервисов, инструкции. Актуализируются текущие версии документов.
Когда условия работы или технологии модифицируются, приходится вносить правки в документы и внедрять изменения в продукт.
Рекомендации по составлению ТЗ
Правильное ТЗ составляют по универсальному шаблону. Мы упаковали его в виде таблицы:
| Этапы составления технического задания | Описание этапов разработки технического задания |
| Дайте подрядчику общую информацию | Подрядчик должен понимать, чем занимается компания и кто ваша целевая аудитория. Так исполнитель сможет глубже вникнуть в поставленную задачу и избежать элементарных ошибок. При озвучивании идеи важно отметить конкурентные преимущества и особенности проекта. |
| Покажите конкурентов | ТЗ должно содержать ссылки на похожие проекты с дополнительным описанием. Это поможет исполнителю оценить удачные примеры чужих разработок и избежать характерных проблем при реализации. Кроме того, выявление чужих особенностей позволяет создать собственное уникальное решение. |
| Распишите сценарии использования продукта | Сценарий нужен для понимания принципа работы продукта. Например, если область работы касается IT, сценарий отвечает на вопрос «Как будет вести себя пользователь?» и дает понимание главных функций сайта. |
| Ведите историю правок | В начале документа создайте таблицу со столбцами “дата”, “описание”, “автор”. В ней записывается история изменений документа, благодаря которой легко понять, на каком этапе возникло то или иное требование, дополнение, противоречие. |
| Составляйте список терминов и сокращений | Это правило грамотного подхода к формированию документа. Основной текст предваряется словарём, в котором записаны специальные термины, не являющиеся общеупотребимыми. Особенно уделите внимание тем аббревиатурам и словам, которые применяются только в данному проекту. |
| Прописывайте каждую деталь | Сайт — это не только код, но и мощности, на которых он работает. В первую очередь, определите, на каком сервере будет размещен сайт, какие у него параметры: ёмкость, оперативная память и другие. Пропишите периодичность и порядок оплаты сервера — передаст ли заказчик обязанность бухгалтерии или же вы будете получать ежемесячную абонентскую плату, из которой сами должны распределять средства на те или иные нужды. Позаботьтесь о пользователях. Продумайте, какими браузерами и устройствами они пользуются, какое у них разрешение. Адаптируйте сайт, если речь идёт о нём, под различные технические характеристики устройств. |
| Продумывайте детали | Не оставляйте белых пятен. При наведении на рисунок, он скрывается? Хорошо, но уточните — он уезжает влево? Становится прозрачным? С какой скоростью? Как он появляется опять? Малейшая деталь без чёткой логики ставит разработчиков и весь процесс в тупик. |
| Опишите требования к проверке проекта | На этапе составления техзадания продумайте чек-лист, по которому заказчику будет понятна степень успешности реализованного проекта. Так можно быстро оценить проделанную работу и не забыть о значимых нюансах. Бывают случаи, когда исполнитель работает за фиксированную плату и некий процент от продаж. Например, вы заказали на таких условиях настройку таргетированной рекламы у фрилансера. Чтобы честно оценить его работу, вам поможет сервис сквозной аналитики от Calltouch. Он формирует отчет о результатах рекламных кампаний: сколько было звонков и заявок, и сколько из них привели к оформлению заказа. Вам не придется высчитывать KPI — итоги работы наглядно отражены в личном кабинете. |
Бывают случаи, когда исполнитель работает за фиксированную плату и некий процент от продаж. Например, вы заказали на таких условиях настройку таргетированной рекламы у фрилансера. Чтобы честно оценить его работу, вам поможет сервис сквозной аналитики от Calltouch. Он формирует отчет о результатах рекламных кампаний: сколько было звонков и заявок, и сколько из них привели к оформлению заказа. Вам не придется высчитывать KPI — итоги работы наглядно отражены в личном кабинете.
Сквозная аналитика Calltouch
- Анализируйте воронку продаж от показов до денег в кассе
- Автоматический сбор данных, удобные отчеты и бесплатные интеграции
Узнать подробнее
Когда ТЗ не нужно
Техническое задание требуется не каждому продукту. Иногда достаточно предпроектного исследования, чтобы изучить потребности клиентов вместе с аналитиком. После этого следует решать, есть ли необходимость в ТЗ.
Зачастую более гибкие методологии, работающие на создание продукта, позволяют успешно и оперативно использовать ресурсы компании. Например, сначала формируется маленький прототип, который тестируют, и на основании обратной связи от клиентов корректируют до полноценного продукта.
Выводы
Техническое задание — важный этап подготовки к работе над проектами. Его составление помогает заказчику сформулировать суть задачи, а исполнителю дает понять, как ее выполнить. Составить ТЗ может заказчик, исполнитель или заказчик вместе с исполнителем. Выбор варианта сотрудничества зависит от сложности работ и навыков специалиста.
Техническое задание (сокращенно – ТЗ или техзадание) представляет собой документ, детально описывающий цели и задачи, которые поставлены заказчиком перед исполнителем. Его оформление позволяет упростить как производство работ, так и контроль над их выполнением. Грамотно составленное ТЗ – это первый и очень важный шаг на пути к взаимовыгодному сотрудничеству между заказчиком и подрядчиком, позволяющий исключить или минимизировать спорные ситуации в ходе дальнейшей работы. Учитывая актуальность технического задания для успешной деятельности обеих заинтересованных сторон, имеет смысл рассмотреть основные вопросы, связанные с оформлением и исполнением документа более внимательно.
Кто должен составлять ТЗ?
Порядок документирования требований
В каком случае ТЗ не нужно?
Шаблоны для скачивания и примеры
Что такое ТЗ?
Под техническим заданием понимается четко сформулированный и детальный перечень требований к конечному продукту, заявленный заказчиком и направляемый исполнителю. Несмотря на краткость приведенной формулировки, объем ТЗ может быть очень значительным и достигать нескольких десятков страниц. Например, если речь идет о реализации масштабного проекта или разработке и изготовлении сложного технологического оборудования.
Характерной особенностью технических заданий выступает сильная зависимость – как содержимого, так и оформления документа – от специфики конечного продукта. Отдельного упоминания заслуживают ТЗ на различное программное обеспечение, включая веб-сайты, онлайн-сервисы, интернет-магазины и различные приложения. Их актуальность особенно велика, что легко и вполне логично объясняется важностью и стремительным развитием IT-индустрии.
Для чего требуется ТЗ?
Необходимость составления технического задания не вызывает сомнений. Наличие документа позволяет решить сразу несколько принципиально важных задач:
- озвучить основные причины реализации объекта;
- сформулировать четкие требования к итоговому продукту;
- проверить, насколько компетентен исполнитель;
- перечислить его необходимые характеристики, свойства, составные элементы и т.д. (перечень качеств зависит от специфики товара или услуги);
- детально описать обязанности каждой из заинтересованных сторон – исполнителя и заказчика;
- установить основные этапы и сроки выполнения поставленных задач – как по отдельности, так и для проекта в целом;
- определить критерии оценки характеристик конечного продукта и установления соответствия заданным параметрам.
Не менее важной задачей технического задания становится исключение или минимизация возможных разногласий между заказчиком и исполнителем. Они могут касаться как отдельных свойств или качеств товара/услуги, так и путей достижения поставленных целей. В результате наличие ТЗ становится ключевым фактором успешного сотрудничества заинтересованных сторон – без конфликтов и спорных ситуаций.
Кто должен составлять ТЗ?
Несмотря на кажущуюся простоту вынесенного в подзаголовок вопроса, ответ на него не так очевиден, каким видится на первый взгляд. Рассмотрим три возможных варианта.
Заказчик
Данный ответ кажется наиболее логичным. Но он является таковым только в том случае, если предметом задания выступает проект, непосредственно связанный с основным видом деятельности заказчика. Например, если IT-компании требуется программа для обслуживания локальной сети. В этом случае квалификации штатных сотрудников фирмы вполне достаточно, чтобы составить грамотное ТЗ.
На практике такая ситуация складывается далеко не всегда. Например, крупному предприятию требуется построить новый производственный цех. Но в его штате попросту может не оказаться специалистов в проектировании и строительстве нужной квалификации. В этом случае имеет смысл привлечь к составлению ТЗ сторонних профессионалов, включая сотрудников потенциального исполнителя.
Исполнитель
Выше приводится пример, когда имеет смысл доверить разработку и оформление технического задания работникам компании-исполнителя. Схема работы в этом случае обычно выглядит так:
- сначала заказчик ставит общую задачу;
- затем исполнитель направляет в его адрес бриф с уточняющими вопросами;
- на основании полученных ответов происходит разработка ТЗ;
- после этого документ отправляется заказчику на утверждение.
Обязательным условием эффективного применения описанной схемы выступает доверие исполнителю со стороны заказчика. В противном случае намного правильнее последнему привлечь к работе сторонних специалистов.
Совместно
Самый оптимальный вариант взаимодействия. Напоминает описанную выше схему разработки ТЗ исполнителем, но предусматривает намного более многоступенчатую процедуру с активным участием сотрудников заказчика. При грамотной реализации позволяет добиться лучших результатов как в части точности, так и полноты технического задания.
Стоимость ТЗ
Невозможно дать однозначного ответа на вопрос о том, сколько стоит техническое задание. В этом нет ничего удивительного, если учесть разнообразие вариаций этого документа, отличающихся как объемом, так и содержанием. Важно понимать, что рассчитывать на бесплатное составление ТЗ не стоит. Тем более – в случае приглашения сторонних специалистов.
Единственным вариантом реально сэкономить становится ситуация, когда исполнитель заинтересован в получении заказа. В этом случае вполне реально добиться от него оформления технического задания на бесплатной основе при гарантиях со стороны заказчика заключить договор на выполнение работ в будущем.
Как составить ТЗ?
Разработка и оформление технического задания – сложная задача. Ее успешное решение предусматривает комплексный подход и доскональное изучение вопроса.
Что потребуется?
Грамотно составленное ТЗ предусматривает наличие нескольких обязательных составных частей, включая:
- Подробное описание целей реализации проекта.
- Основные требования и ожидания от конечного продукта.
- Ключевые этапы выполнения работ.
- Календарный график или сроки исполнения.
- Процедура контроля в процессе реализации проекта и итоговой приемки конечного продукта.
- Приложения к ТЗ. Их перечень зависит от специфики проекта и обычно включает расчет стоимости, ссылки на нормативно-правовые документы и технические регламенты, другую справочную информацию, которая может оказаться полезной исполнителю.
Пошаговый план
Фактически, процедура составления технического задания представляет собой наполнение каждого из перечисленных выше разделов итогового документа. Последовательность предпринимаемых при этом действий зависит от специфики проекта и характеристик конечного продукта. Главное – четко выполнить требования к содержимому и оформлению ТЗ, что позволит успешно решить стоящие перед документом задачи.
Рекомендации по составлению
Не менее важно не допустить типичных ошибок, характерных для недостаточно квалифицированных разработчиков и составителей ТЗ. Чтобы добиться этого, имеет смысл следовать нескольких достаточно простым рекомендациям, включая:
- Однозначные формулировки. Содержание ТЗ не должно включать описаний или характеристик, допускающих неоднозначные трактовки. В тексте документа не допускается присутствие качественных прилагательных и крайне приветствуются конкретные цифры.
- Определение используемых терминов. Заказчик и исполнитель должны разговаривать на одном языке. Поэтому ключевые понятия нуждаются в расшифровке.
- Соблюдение установленных стандартов. Перечень нормативных документов, которые можно использовать при составлении технического задания, приводится ниже. Здесь же необходимо отметить, что ссылки на ГОСТы или ISO всегда полезны, так как сводят к минимуму возможные разночтения.
- Предоставление исполнителю максимально возможной информации о заказчике. Такие сведения помогают сориентироваться в том, что является важным для заказчика, его целевой аудитории и других важных параметрах.
- Перечисление конкурентов. Достаточно часто существенную помощь в реализации проекта оказывает изучение и анализ аналогов, уже представленных на рынке или запланированных к запуску конкурирующими компаниями. Такой подход к решению задачи заслуживает внимания, так как позволяет минимизировать сопутствующие расходы и не заниматься «изобретением велосипеда», а сосредоточиться на улучшении уже имеющихся разработок.
- Внесение корректировок при необходимости. Если речь идет о сотрудничестве двух коммерческих структур, целесообразно наладить постоянное общение. В том числе –с целью уточнения ТЗ, если это потребуется. Хотя намного правильнее заранее прописать все возможные нюансы и сценарии развития событий, так как любые корректировки технического задания можно и нужно считать форс-мажором.
Скачать шаблон и пример ТЗ на оказание услуг – источник s-vfu.ru.
О стандартах
Порядок разработки технических заданий регламентируется множеством стандартов – как международных, так и отечественных. Причем в отношении разных проектов и продуктов действуют различные нормы. Наиболее часто упоминается международный стандарт ISO/IEC/IEEE 29148-2018. Он устанавливает требования к ТЗ на разработку информационных систем и программного обеспечения.
Если говорить об отечественных стандартах, необходимо обязательно отметить два из них. Первый – это ГОСТ 34.602-89, который устанавливает основные технические и другие требования к ТЗ на автоматизированные системы. Второй – это ГОСТ 19.201-78, определяющий порядок разработки ТЗ в рамках единой системы программной документации.
Оба стандарта впервые появились еще в Советском Союзе, а потому их актуальность остается под вопросом. Отсутствие более новых документов показывает слабое законодательное и нормативное сопровождение вопроса составления и разработки технических заданий в России.
Существуют и другие стандарты, в большинстве своем международные – IEEE STD 830-1998, RUP, BABOK, SWEBOK и т.д. Их использования в отечественных условиях сильно ограничено из-за отсутствия учета местной специфики и широкого распространения.
Порядок документирования требований
Грамотное составление ТЗ предусматривает обмен документами между заказчиком и исполнителем. Первым из них выступает бриф. Он представляет собой перечень вопросов, которые исполнитель адресует заказчику с целью уточнения поставленных задач.
Далее формируется коммерческое и техническое предложение. Такой документ обычно составляется при реализации масштабных проектов. Он содержит детальное описание финансовых показателей и технических требований к результатам.
На основании обоих документов (второй может быть заменен на перечень требуемых технических характеристик) составляется ТЗ. Его в обязательном порядке утверждает заказчик и согласовывает исполнитель. В подавляющем большинстве случаев техническое задание является обязательным приложением к договору.
В каком случае ТЗ не нужно?
Техническое задание требуется далеко не всегда. Например, если уже разработана детальная проектная документация, или проведены детальные предпроектные исследования/инженерные изыскания. Также не имеет особого смысла составлять ТЗ для небольших проектов, требования и характеристики которых можно перечислить непосредственно в договоре.
Шаблоны для скачивания и примеры
Найти образец технического задания на выполнение работ несложно. В сети размещено множество подобных шаблонов и реальных примеров из практики. Важно понимать, что ТЗ для разных проектов и продуктов очень сильно отличаются друг от друга. Поэтому следует крайне внимательно относиться к имеющимся образцам и подбирать подходящий.
FAQ
Что такое ТЗ?
Под техническим заданием понимается перечень требований к разрабатываемому продукту или реализуемому проекту. Он включает технические характеристики, сроки выполнения, нередко – стоимость производимых работ и другие подобные параметры.
Для чего необходимо техническое задание?
Составление ТЗ позволяет четко сформулировать поставленные перед исполнителем задачи и исключить возможность возникновения спорных ситуаций в процессе их решения.
Что следует включить в ТЗ?
Содержание ТЗ определяется с учетом специфики конкретного продукта и может включать обширный набор сведений – от перечня требуемых характеристик до описания процедуры контроля качества.
Кто занимается составлением ТЗ?
На практике встречаются три варианта ответа на этот вопрос: заказчик, исполнитель, одновременно оба. Эффективность применения каждого зависит от статуса заинтересованных сторон и характера их взаимоотношений.
Какие типичные ошибки допускаются при разработке технического задания?
Самыми частыми ошибками при составлении ТЗ выступают: неоднозначные формулировки, отсутствие четких требований, недостаток информации о заказчике, продукте и конкурентах.
Подведем итоги
- Техническое задание – это перечень требований к конечному продукту или результатам реализации проекта.
- Разработка ТЗ – важный подготовительный этап, от успешного выполнения которого зависит эффективность дальнейшего сотрудничества между заказчиком и исполнителем, а также качество полученного на выходе продукта.
- Составлением ТЗ занимается заказчик, исполнитель или одновременно оба. Последний вариант нередко оказывается самым плодотворным при условии взаимного доверия между сторонами.
- Стоимость технического задания определяется индивидуально и зависит от специфики конечного продукта, его сложности и предъявляемых заказчиком требований.
Ликбез по техническому заданию
Время на прочтение
7 мин
Количество просмотров 58K
Польза: получите знания о том, что такое ТЗ и как его составить. Обогатите словарный запас словами: концептуальная модель, data flow, mind card, user flow. use cases, wireframes, ER-model, client-server, API.
Для кого: начинающим разработчикам и желающим чтобы их поняли (заказчикам, стартапам и менеджерам).
Время чтения: 7 минут.
Отправная точка — требования
Хочу пирожное, потом морожное!
Вовка в тридевятом царстве
Существует распространенное заблуждение, что достаточно сказать: “Нужно приложение для музея/кошки/завода” и сразу станет понятно, что вам необходимо.
К сожалению, все не так просто. Представьте, что вам нужно построить дом. Вы идете к строителю, и он приступает к работе. Вы не предоставили ему ни чертежей, ни участка, даже не сказали какого цвета должен быть забор. Но дали на все про все полгода и значительную сумму денег.
Спойлер
Через полгода вас ожидает нечто в поле и вообще с забором серобуромалинового цвета.
Жутко правда? Бюджет уже потрачен и срок истек.
Чтобы такого не произошло все требования к продукту фиксируют, это и есть то, с чего начинается любая разработка.
Удобный вид требований — ТЗ
Замесить и нарубить!
Вовка в тридевятом царстве
Хорошо. Будут требования. Теперь вас точно поймут разработчики. Но тут возникает подводный камень №1: человечество пока не научилось читать мысли. Поэтому нужно в каком-то виде передать информацию и лучший для этого способ — Техническое задание.
Его также называют ТЗ, SRS, PRD — все это названия документа, в котором в правильной форме зафиксированы требования к продукту.
Подводный камень №2: память человека не безгранична, всегда лучше иметь одно место, где все ваши пожелания и требования зафиксированы (не переписка в telegram или звонок по телефону). Поэтому ТЗ это печатный текстовый документ с приложением схем и инфографики, не написанный от руки или сфотографированный. Лучше всего в формате .PDF или Google Docs.
Рецепт грамотного ТЗ
Техническое задание для разработчиков это своеобразный рецепт приготовления успешного продукта. Успешный продукт — тот, который легко поддерживать, можно развивать и менять, он не развалиться при смене разработчика и приносит прибыль в любом ее виде. Вы хотите, чтобы ваш проект был полноценным? Отлично. Напишите для этого хороший рецепт. Классическими ингредиентами (по международному стандарту IEEE-830) служат:
- Концептуальная модель
- Функциональная карта
- Путь пользователя
- Пользовательский интерфейс
- Программные интерфейсы
- Нефункциональные требования
Последние 2 пункта специфичны, советую на них обратить внимание читателям близким к разработке.
Ниже я разберу подробно каждый из пунктов. Для тех, кому не хочется подробно разобраться, оставляю ссылку на международный стандарт c шаблоном технического задания: ссылка на документ.
Концептуальная модель
В этот пункт входит краткое описание продукта, в нем отражается цель проекта и его отличительные черты.
Например: “Приложение для знакомств, в котором можно смотреть короткие видео в профилях пользователей и общаться в чате”.Также не помешает сказать пару слов об аудитории продукта, так команда проекта сможет понять его особенности и дать вам несколько полезных советов. Расскажите о ее возрасте, характере и территориальном расположении, каких-то особенностях, которые должны отразиться на проекте.
Например: “Это молодые люди, выезжающие за рубеж для отдыха и интересующиеся общением за пределами языкового барьера, которые любят снимать фото и видео”.
Стоит рассказать о типах пользователей и их ключевых отличиях.
Например: “В приложении должны быть обычные пользователи и модераторы, которые получают жалобы от пользователей на контент или профили. Модераторы могут просматривать чат обычных пользователей после жалобы и заблокировать в сервисе нарушающий правила аккаунт”.
И в завершении расскажите о компонентах вашего продукта.
Например: панель администратора, которую используют модераторы; мобильное приложение, которое использует пользователь, чтобы зарегистрироваться, добавить контент, поучаствовать в чате и т.д.
Высшим пилотажем будет сделать так называемый data flow или контекстную диаграмму, в которой будет отражено как пользователи взаимодействуют с продуктом, его компонентами и между собой.
Функциональная карта
Функциональная карта отображает общую концепцию проекта с уровнем детализации необходимым для того, чтобы оценить объем работ, расставить приоритеты.В традиционном формате такая карта напоминает карту сайта. Но удобнее всего ее отобразить в виде mind card (майнд карт, интеллект карт). Часто менеджеры рисуют на совещании на доске или листе бумаги слова и между ними связи, так вот, это и есть майнд карта. Это можно сделать удобно в бесплатных сервисах (coggle, draw.io и mindmeister) или просто в Office Word.
Очень важно отразить в функциональной карте все пользовательские особенности. В первом приближении это просто набор функций продукта.
Например: “В приложении должна быть регистрация по почте, создание и заполнение данных профиля,, возможность загрузить и отредактировать фото и видео, список аккаунтов других пользователей с различными типами фильтров, текстовый чат, обращение к службе поддержки.
Путь пользователя
Так называемый user flow или путь пользователя, это последовательный список действий или экранов, по которым может переходить пользователь в процессе взаимодействия с продуктом. Опишите, как в вашем представлении будет взаимодействовать с продуктом пользователь. Очень удобно это можно сделать также майнд картой или просто списком действий.
Например: “Пользователь заходит в приложение, чтобы познакомиться с сверстниками. Он заполняет свой профиль данными и загружает фото и видео. Затем пользователь заходит в ленту и фильтрует ее по каким-либо критериям. В качестве результата он получает список релевантных профилей, может посмотреть их и написать другому пользователю в чате.
Путь пользователя — это общий алгоритм работы с продуктом. Также существует еще use cases (варианты использования) — это детализация user flow. В случае мобильного приложения для знакомств вы создали путь пользователя по экранам, а затем описываете, что пользователь может сделать на каждом экране.
Например: на экране регистрации пользователь может:
перейти на экран авторизациизарегистрироваться через соцсети (Facebook, Twitter)может ввести почту, пароль, затем его повторить и подтвердить регистрацию в письме, пришедшем на почту.
Пользовательский интерфейс
Продукт должен мало того что работать, так еще и приятно выглядеть. Немного отойдем от тематики приложений, чтобы не заставлять вас их скачивать для ознакомления. Лучше посмотрим на симпатичные сайты:
- ukraine.craigslist.org
- www.theworldsworstwebsiteever.com (предупреждение, если вы страдаете приступами эпилепсии то не переходите по ссылке
- www.art.yale.edu
Посмотрели на пример плохого дизайна, теперь вытрите кровь с глаз и перейдем к обсуждению интерфейса. В этой части технического задания стоит приложить реферы — примеры того, каким вы хотите видеть свой продукт. Это могут быть аналоги похожих разработок или просто примеры, дизайн которых вам понравился.
Опишите в общем виде, каким вы хотите видеть свой продукт, какие у него должны быть цвета, какие элементы использоваться, какую вы хотите анимацию и т.д. Если у вас есть фирменный стиль или брендбук, отлично, сошлитесь на них.
Дизайнеры скажут вам большое спасибо, если вы укажите стиль дизайна интерфейса, например flat design или material design.
Высшим пилотажем будет добавить wireframes (вайрфреймы) — прототипы интерфейса продукта в виде приближенных схем.
Программные интерфейсы
Этот раздел для специалистов. Если вы уверены в своих силах, то продолжайте чтение.В лучшем техническом задании также описывается архитектура продукта, то есть то, из каких программных компонентов он состоит. В случае клиент-серверного приложения для знакомств сервис разбивается на часть сервера, которая хранит данные и обрабатывает их, производит какие-то логические операции и часть клиента, который отображает данные.
Сервер декомпозируется на модули: базы данных, аутентификации, чата и т.д.Клиент связывается с сервером через API (интерфейсы передачи данных), стоит указать его тип (REST, WEB, RPC и т.д.) и описать методы, ответы и обработку ошибок.
Данные обычно хранятся в базе данных в виде специальных структур, чаще всего таблиц (для реляционных БД) и json структур (для нереляционных). Разработчики скажут вам огромное спасибо, если в техническом задании вы укажите сущности базы данных (ER-модели) и опишите хранимые поля, с указанием их типов данных (string, int и т.д), ключей (primary, foreign), обязательности (required) и пустого значения (nullable).
Нефункциональные требования
Это общие требования к продукту. Их можно разделить на требования к техническому обеспечению, требования безопасности и требования к производительности.В требованиях к техническому обеспечению указывают пожелания к устройствам и операционной среде, например для приложения знакомств это Android 7.0+ и JDK 8+, iOS 11.0+ и Swift 4.2.
В требованиях к безопасности можно указать, что передача данных в чате должна осуществлять с помощью шифрования SHA-1 и что при регистрации сложность пароля должна быть не менее 8 бит.В требованиях к производительности говорится о связи компонентов и отказоустойчивости, например стоит указать, что таймаут на чтение сообщения в чате не более 1 с и что приложении частично хранит кеш и может ограниченное время работать в автономном режиме.
Советы
- Создавайте текстовый документ в онлайн офисе или PDF, который легко будет прочесть. Это гораздо лучше переписки в чате или голосового сообщения, его всегда можно будет посмотреть с любого устройства.
- Соблюдайте последовательность, переходите от общих требований к частным, приведенная выше структура не идеальна, но может служить хорошей основой.
- Все требования должны быть в одном документе или вики-структуре, не храните их отдельно, они должны быть всегда доступны из одного источника.
- Давайте четкие и разумные указания, избегайте неточностей, пишите максимально простым языком.
- Описывайте ваши требования максимально подробно. Лучше один раз все продумать, чем постоянно уточнять различные детали и нюансы.
- Приготовьтесь потратить больше нескольких дней или обратитесь к профессионалу для составления документа. Грамотное техническое задание спасет вас от долгих обсуждений деталей с разработчиками и обозначит четкие критерии сдачи проекта. Например, полноценное ТЗ по стандарту IEEE-830, приложенное к договору на разработку, является аргументов в суде в случае невыполнения требований.
Статья обновлена 23.06.2022
Сегодня разберёмся с таким термином, как техническое задание. Что это такое? Как его правильно разработать? На что стоит обязательно обратить внимание? Ответ на эти вопросы важен, ведь именно от того, как составлено техзадание, во многом зависит результат работы.
Если задачи сформулированы не точно, то и выполнены они будут соответствующим образом. Видение исполнителя далеко не всегда соответствует видению заказчика, поэтому в статье мы расскажем о том, как правильно формулировать свои требования и пожелания.
Почему разработка технического задания так важна
Нельзя недооценивать важность ТЗ. На самом деле этот документ по значимости можно сравнить с договором, в котором прописаны обязанности всех участников сделки.
Техническое задание на разработку того или иного проекта можно назвать инструкцией по выполнению работы. Поскольку структура ТЗ подразумевает перечисление всех условий процесса и деталей результата, то сотрудничество становится более понятным, комфортным и безопасным как для заказчика, так и для исполнителя.
Происходит это потому, что в ТЗ детально описывается каждый нюанс, подробно разъясняется каждая мелочь. Как итог – пространства для ошибки, неверного действия или обмана практически не остается, ведь любое нерегламентированное действие будет считаться нарушением инструкции.
Но даже не это является главным преимуществом полноценного ТЗ, а то, что профессиональный подход гарантирует качественный итог. Чтобы в результате получить продукт, который будет отличаться бесперебойной работой и отвечать всем нормам и требованиям, важно остановиться на деталях, всё тщательно просчитать и продумать. А основные требования к техническому заданию как раз подразумевают скрупулезное отношение ко всем рабочим моментам.
Ошибочно считать, что подобный подход применяется исключительно при выполнении сложных процессов. Даже самые простые задания требуют чётких инструкций, а все ходы должны быть просчитаны на три шага вперед. Именно поэтому написание ТЗ является обязательным этапом любой работы.
О стандартах написания технических заданий
Как писать ТЗ часто не знают даже те, кому по роду своей деятельности регулярно приходится ставить определенные задачи перед исполнителями. Главными требованиями здесь являются продуманность, чёткость и полная передача нужной информации. Но, не имея должного опыта, сложно реализовать задуманное, опираясь исключительно на заявленные требования. Для написания полноценного задания, необходимо знать стандарты разработки ТЗ, которые считаются общепринятыми и применяются во всех сферах деятельности.
В некоторых профессиях от кандидатов при трудоустройстве даже требуют знания ГОСТ 34 и/или ГОСТ 19. Например, это относится к таким профессиям как технический автор или системный аналитик. Речь идет о государственных стандартах, которые успешно применяются как образец оформления и составления ТЗ.
Важно отметить, что указанные выше ГОСТы относятся непосредственно к программным комплексам, поэтому применять их можно как шаблон технического задания на разработку ПО и тому подобных продуктов.
Для многих станет настоящей неожиданностью то, что ГОСТ 19 действует с 1980 года. Но, поскольку модель программного обеспечения не подвергалась значительным изменениям, актуальность этого стандарта не теряется и сегодня.
В этой сфере деятельности, как и в большинстве других, есть свои азы и основы, которые остаются неизменными даже с течением времени и развитием новых технологий.
ТЗ на разработку ПО обязательно должно включать в себя такие пункты:
- Вступление
- Основа для разработки ПО
- Сфера применения
- Ключевые требования к ПО
- Обязательные требования к документации и к программе
- Технико-экономические показатели
- Этапы работы и их очередность
- Сроки и особенности приемки и контроля готового ПО
- Приложения
ГОСТ 34 принят на 10 лет позднее описанного выше стандарта. Нельзя сказать, что он сильно отличается от предшественника, но свои особенности у него точно есть. Пример оформления ТЗ согласно этому документу выглядит следующим образом:
- Общая информация о системе
- Назначение системы
- Информация об объектах, для которых создается система
- Ключевые требования к готовому продукту
- Этапы выполнения работы и особенности каждого этапа
- Порядок приемки готового продукта
- Этапы подготовки системы к вводу в действие
- Требования к программной документации
- Источники разработки
Нельзя сказать, что современные ТЗ пишутся исключительно по этим образцам – время внесло свои корректировки и появилось множество новых правил и рекомендаций. Но эти документы точно можно использовать как базу на проектирование ГОСТ-совместимого технического задания. Полностью следовать перечисленным требованиям необходимо исключительно в случае взаимодействия с государственными структурами.
Что касается составления заданий для международных проектов, то здесь применяется стандарт ISO/IEC/IEEE 29148:2018, разработка которого принадлежит Международной организации по стандартизации ISO. Как и в случае с ГОСТами, тут есть опорные пункты по составлению полного и качественного технического задания. Задание международного образца включает:
- Описание системы или продукта. Для кого предназначен объект и что пользователь может в нём делать.
- Технические характеристики: производительность программы, интерфейс, безопасность и так далее.
- Описание этапов тестирования.
- Приложения и история изменений проекта.
Общие рекомендации для составления понятного ТЗ
Даже зная ГОСТы, разбираясь в требованиях и понимая, что такое инструкция по написанию хорошего ТЗ и как её использовать, без практического опыта сложно сделать все с первого раза именно так, как запланировано. Если составление технического задания требуется не для государственной системы и не для официальной иностранной организации, совсем не обязательно следовать ГОСТам. Можно дополнить ТЗ элементами, которые сделают жизнь заказчика и исполнителя гораздо проще.
Во многом советы от специалистов в сфере разработки ТЗ дублируют пункты ГОСТов, однако тут есть и дополнительные детали, которые точно помогут приблизить реальный результат к желаемому.
1. История правок – обязательно сделайте таблицу, в которой будут прописаны все изменения в документе и причины правок. Указывайте дату и автора идеи. Это поможет увидеть слабые места и сформировать устойчивый алгоритм действий на будущее.
2. Словарь – все термины, сокращения и аббревиатуры должны быть внесены в отдельный список. Неважно, будут ли эти слова применяться в дальнейших проектах или же используются только в этом ТЗ.
3. Уделяйте внимание мелочам – в результате выполнения работ по составленному техническому заданию должен получиться идеальный продукт, готовый для работы.
Последний пункт особенно важен и требует внимания. Ряд деталей может ускользнуть из вида из-за того, что какие-то из моментов покажутся заказчику очевидными и включенными в работу по умолчанию. Данное мнение может быть субъективным и исполнитель не всегда обладает таким же видением. При написании технического задания стоит абстрагироваться от оценочных суждений, расписав каждый пункт максимально подробно. К примеру, если составляется ТЗ для разработки сайта, то оно должно содержать не только технические моменты, но и такие нюансы, как оплата сервера, адаптация юзабилити под пользователя, для мобильных устройств и тому подобное.
Что может помочь при составлении технического задания
Теперь, когда мы разобрались с обязательными пунктами, которые должно содержать техническое задание, поговорим о других документах, призванных помочь в его составлении. В небольших компаниях и на ряде проектов эти элементы даже могут заменить ТЗ, так как представляют собой пошаговые инструкции с исчерпывающей информацией.
Бриф
Главный опросник, который заполняет заказчик перед началом работы. Если создать список вопросов грамотно, то можно и вовсе избежать подписания дополнительных инструкций. Так как бриф в данном случае будет являться полноценным планом работ. Во многом сложность заполнения инструкции зависит от специфики заказа. Так, составление задачи на разработку полноценного интернет-магазина будет содержать куда больше пунктов, чем бриф на создание рекламного баннера.
Приведем для примера бриф на разработку сайта. Он поможет стать отличным фундаментом для начала работы.
Бриф на разработку сайта
| Наименование организации | _________________ |
| Контактное лицо | _________________ |
| Телефон, email контактного лица | _________________ |
| Сфера услуг, оказываемых компанией | _________________ |
| Геолокация оказываемых услуг / доставки товаров | _________________ |
| Сайт компании | _________________ |
| Целевая аудитория | _________________ |
| Главные конкуренты на рынке | _________________ |
| Цели и задачи сайта (визитка, презентация, каталог) | _________________ |
| Разделы сайта (контакты, магазин, блог и пр.) | _________________ |
| Как часто планируются обновления контента сайта | _________________ |
| Мультиязычность сайта (в случае необходимости укажите языки) | _________________ |
| Характеристика дизайна сайта (лаконичный / серьёзный / яркий и т.д.) | _________________ |
| Впечатление, которое должен произвести ресурс на пользователя | _________________ |
| Есть ли у компании фирменный стиль и логотип (приложите ссылки на файлы) | _________________ |
| Нужны ли на сайте анимированные элементы | _________________ |
| Интеграция систем онлайн-оплаты | _________________ |
| Магазин | _________________ |
| Архив | _________________ |
| Email рассылка | _________________ |
| Форма обратной связи | _________________ |
| Новости | _________________ |
| Отзывы | _________________ |
| Другое (укажите необходимые дополнительные функции сайта) | _________________ |
| Требуется ли регистрация домена | _________________ |
| Требуется ли регистрация сайта на хостинге | _________________ |
| Необходимо ли место на сайте для рекламных баннеров | _________________ |
| Необходима ли раскрутка сайта ресурсами исполнителя | _________________ |
| Сроки выполнения | _________________ |
| Бюджет | _________________ |
| Сроки проверки заказа | _________________ |
| По мере готовности передать готовую работу (контакты) | _________________ |
Коммерческое предложение
Описание услуг или продукта в данном случае оформляется наиболее подробным образом. Презентация содержит не только описание товара, но и технические характеристики, стоимость и прочие условия взаимодействия с клиентом.
Прочитав такое коммерческое предложение, потенциальный заказчик сразу же видит все условия сделки и выгоду сотрудничества. На основе имеющихся данных ему проще принять решение о работе или сравнить компанию с другими исполнителями.
Какую информацию обязательно стоит включить в коммерческое предложение?
- Информацию о компании: название, сфера деятельности, направления работы. С какого года вы работаете на рынке? Какие услуги предоставляете?
- Выгода для клиента. Как продукт отличается от прочих аналогичных? Сколько довольных клиентов у компании? Какие условия доставки? В данном пункте эффектно будут выглядеть чёткие цифры, которые дадут понять клиенту, почему нужно выбрать именно вас.
- Цена. Обязательный блок с ценами стоит оформить наиболее прозрачным и удобным к восприятию образом. Учтите все вариации комплектации продукта, чтобы максимально подробно донести информацию до заказчика.
- Технические характеристики продукта. Срок эксплуатации, комплектация и так далее.
- Условия взаимодействия. Гарантия, доставка, возврат товара, контакты.
И бриф, и коммерческое предложение станут отличными помощниками для старта взаимодействия по тому или иному проекту. В ряде случаев вполне уместно разместить данные документы на сайт. Так заинтересованный заказчик сразу сможет сделать выводы о рациональности сотрудничества.
Грамотное ТЗ – залог хорошего результата. Помните об этом и присматривайтесь к мелочам!
Составить техническое задание так, чтобы человек понял, что от него требуется и у него появилась внутренняя мотивация решить твою задачу, — это не особое искусство или магия, а конкретный скилл, который можно и нужно вырабатывать.
У меня 8-летний опыт в проектном менеджменте, работе с дизайнерами, программистами и в постановке задач для них. А последние 3 года я руковожу собственной digital-студией «Пекло». Поэтому с уверенностью говорю, что неважно, работаешь ты с придирчивым разработчиком-перфекционистом или супер-творческим десигнером, подход к формированию задачи одинаковый, за исключением нескольких мелочей.
В этой статье я поделюсь советами и приемами, которые я использую в работе сам: как составить ТЗ так, чтобы вашим коллегам, подрядчикам, партнерам было приятно и комфортно принимать и осуществлять ваши задачи. А это залог эффективной командной работы, выполненных планов, заработанных денег. Поехали!
Заголовок/название задачи должен отвечать на вопрос «Что Сделать?»
Хорошие примеры:
- Разработать дизайн анимированных баннеров для FB/Insta & Google для {CLIENTNAME}
- Исправить отображение страницы /pricing на мобильных устройствах
Плохие примеры:
- Баннеры для {CLIENTNAME}
- Верстка на странице цен
В чем соль:
- Ответ на вопрос «что сделать?» уже подразумевает действие и побуждает к нему
- В хорошо сформулированной задаче должен быть видимый/ощутимый результат
- Когда ты понимаешь желаемый результат — в итоге меньше прокрастинации и больше готовности приступить к задаче и сделать ее
Заголовок задачи должен давать понимание приблизительного объема работы
Хорошие примеры:
- Сделать ХХ ресайзов готового дизайна под площадки для {CLIENTNAME}
- Сделать адаптивную верстку личного кабинета для {CLIENTNAME}
Плохие примеры:
- Дизайн для {CLIENTNAME}
- Сайт для {CLIENTNAME}
В чем соль:
- Если задача слишком объемная и «необъятная», то в итоге непонятно, с какой стороны к ней приступить, с чего конкретно начать и поэтому возникает стресс и прокрастинация
- Надо постараться передать конкретный объем работы + если задача крупная, то обязательно должна содержать подзадачи, с которых нужно начать делать большую задачу
Рекомендации выше подходят как для мелких задач, не требующих дальнейших описаний, видения решения и так далее. Также я рекомендую использовать эти правила даже для ведения личных задач, а не только для постановки коллегам.
Сроки выполнения задачи
Задача, «подкрепленная» дедлайном более приоритетная и важная к исполнению. Задача без дедлайна получает статус «ну, когда-нибудь хорошо было бы ее сделать».
Если вы ставите задачу партнерам и вы не рулите приоритетами их задач, то обязательно уточняйте, когда ее смогут выполнить.
Описание задачи и его структура
Описание задачи необходимо для крупных и объемных задач, где нужно передать весь контекст проекта и понимание ситуации. Обычно описание задачи состоит из нескольких логичных последовательных блоков (это важно!):
- Краткое описание проблемы и ее масштаба
- Видение ее решения (или описание конкретных действий)
- Профит и польза проекту/команде/всем от выполненной задачи
Но помните, что не нужно писать летописи-лонгриды из ваших user story при описании багов. Краткость — сестра таланта. Плюс текст отформатированный, с расставленными акцентами, логично распределенный на абзацы.
IT-шный пример
Заголовок: Задать подготовленные мета-данные для страниц сайта
Мы обнаружили, что на сайте не сформулированы titles & meta descriptions. У части страниц они не заполнены, половина страниц — дубли, а оставшаяся часть сформулирована без использования ключевых слов и некликабельно. Это критическая ошибка, так как без корректных мета-данных сайт не может расти в поисковой выдаче.
Мы составили таблицу в Google Docs с прописанными мета-данными для каждой статической страницы сайта, а также с шаблонами для динамически генерируемых страниц. Ссылка на документ: {link}. Так как у проекта нет админки, где мы могли бы все настроить своими руками, просьба вставить метаданные из документа на страницы сайта:
- Для статических страниц данные вносятся копипастом
- Для динамических страниц используются переменные. Например:%НазваниеТовара% за %price% от интернет-магазина BRANDNAME.COM. То есть, для каждой конкретной страницы сайта должно подставляться ее содержимое. Весь список переменных также находится в таблице.
Просьба это сделать ASAP, так как от этого зависит вся дальнейшая работа по оптимизации. После реализации задачи, мы отправим сайт на переиндексацию и сразу получим увеличение показов и кликов в выдаче! Если в ходе работы возникнут вопросы — без проблем спрашивайте!
Пояснение: кратко описываем проблему, подготавливаем всю необходимую информацию для разработчика (таблица), далее описываем решение задачи, объясняем подводные камни с «переменными». В конце обозначаем важность задачи, желаемые сроки и профит, который будет от решенной задачи. Также мы добавляем, что мы если что рядом и готовы оперативно ответить и помочь (снижает стресс при получении незнакомой задачи).
Самое важное: если решенная задача имеет конкретный результат и пользу, то у исполнителя есть мотивация ее выполнить. Если важность задачи не раскрыта и понимание того, что она даст, то и желания сделать задачу, быть причастным к ее решению тоже особого нет.
Дизайнерский пример
Заголовок: Разработать landing page для {clientname}
К нам обратились ребята из ХХХ. Они организуют ивенты и тусовки для крупных компаний, и за два года стали лидерами. Текущий лендинг — унылое говно и не соответствует их компании.
Мы узнали собрали всю инфу и контент у клиента:
- {ссылка на гуглдок} — это ссылка на ТЗ с примерной последовательностью блоков и черновиками текстов. В случае, если появятся идеи и предложения — можно отойти от ТЗ и предложить свое решение.
- {ссылка на гуглдиск} — собрали в папку все необходимое для проекта: исходники лого, фотографии с тусовок и командные фото
- Вот подборка ссылок на хорошие сайты, которые можно изучить перед работой:
Помни: рисуем mobile-first, так как 90% трафика — мобильные устройства!
Предлагаю перед стартом работ встретиться и обсудить детали работ, я детальнее расскажу про компанию и структуру лендинга, которую мы продумали. По срокам — нужно показать макет до ХХХ, так что время на подумать есть. Контент дали хороший, заказчик адекватный — так что уверен, сможем сделать круто!
Пояснение: рассказываем о сильных сторонах клиента и о проблеме, даем всю необходимую информацию для старта работ и показываем важные технические нюансы. Из моего опыта, дезигнеры, как правило, не любят много букв, текст читают и копипастят невнимательно, поэтому с ними чаще всего нужно обсуждать задачу голосом. В конце, опять же, говорим о положительных нюансах и намерении сделать круто. Однако, жизнь, тяжелая и непредсказуемая штука: может прилететь говняный проект, и вы понимаете, что уже не отвертеться, его нужно сдать и забыть как страшный сон. В таком случае не обманывать коллегу и говорить честно: «Брат, мы должны сделать эту грязную работу!».
Контекст задачи
Некоторые из советов (вроде написания заголовков задач) вообще не требуют дополнительного времени на постановку, а вот насколько развернутые и детально описанные должны быть ТЗ — определяет контекст задачи. Перед постановкой задачи обязательно:
- Поймите, насколько исполнитель знаком с проектом, для которого делается задача?
- Учитывайте, делал ли он раньше аналогичные задачи с вами или вообще с кем-то
- И если есть сомнения, что вы хорошо друг друга поймете — созвонитесь и синхронизируйтесь
В результате вы сэкономите всем время, нервы, быстрее и круче решите задачу, получите каеф от гладкого процесса.
Взаимоотношения с ответственным за выполнение задачи
С каждым человеком у нас складываются определенные взаимоотношения и стиль общения. И чтобы задача лучше читалась и воспринималась исполнителем, можно этот нюанс учитывать и отходить от официоза, канцеляризмов и написать текст на «вашем» языке, что тоже будет комфортнее для восприятия информации
Cover-letter для оформленной задачи — задачу нужно ПРОДАТЬ
Еще небольшая фишка: когда задача уже сформулирована по феншую. Ее нужно ПРОДАТЬ исполнителю:
- Привлечь внимание
- Вызвать интерес
- Вызвать желание
- СДЕЛАТЬ ЕЕ
Прямо по канонам AIDA получается, да? 
Хороший пример:
Вася, привет! В процессе аудита сайта мы обнаружили серьезную ошибку — которая мешает росту сайта. Нужна твоя помощь. Посмотри, пожалуйста, ее сегодня — {ссылка на тикет}!
Плохой пример:
Всем привет! Завели новую задачу: {ссылка на тикет}
И еще мудрые советы в копилку:
- Я прочитал книгу Getting Things Done Дэвида Аллена, и внедрил (и продолжаю это делать) методологию GTD на N% в свою жизнь и стал работать эффективнее и с меньшим стрессом. Очень ее рекомендую.
- Используйте Главред для написания текста
- Не ставьте задачи голосовыми сообщениями! %)
Главное, сформировать у себя привычку писать задачи по феншую — это перестанет быть для вас стрессом, нагрузкой и перестанет занимать дополнительное время. Зато будет порядок в процессах и в эффективности работы!
Рассказываем, как составить техническое задание. Какая информация должна в нем быть и как правильно структурировать данные в ТЗ.
Что такое техническое задание?
ТЗ – это постановка задачи, план действий и обсуждение грядущей работы в одном документе. Техническое задание необходимо в любой сфере деятельности. Строите дом? Нужен четкий план и требования. Делаете веб-сайт? Тот же сценарий. Любая деятельность сопровождается хотелками заказчика и нормативами, которые обязуется соблюдать исполнитель. Они и заносятся в ТЗ.
Комьюнити теперь в Телеграм
Подпишитесь и будьте в курсе последних IT-новостей
Подписаться
Зачем нужно ТЗ
Благодаря техническому заданию устанавливается первичный контакт между исполнителем и заказчиком. Грубо говоря, с помощью него производится проверка, стоит ли вообще этим людям сотрудничать. Проверка на то, насколько реалистичны требования заказчика и сможет ли им соответствовать исполнитель.
К тому же ТЗ устанавливает регламент, помогающий вести работу в заданном направлении без самодеятельности с обеих сторон. Четко составленный план действий нивелирует разночтения бизнес-решений и помогает избежать нелепых ошибок на полпути.
Также ТЗ формирует ожидаемый результат и дает возможность оценить результат проделанной работы.
Каким должно быть ТЗ
На самом деле, соблюдение четких правил при составлении ТЗ не требуется. Разные компании и предприниматели оформляют задания по-разному. Вопрос в преследуемых целях.
Кто-то за пару предложений излагает ключевую мысль и надеется, что работник сам додумает остальное:
Нужно написать небольшой текст на тему «Душевые кабины». Текст должен быть для людей. Без переспама.
А кто-то описывает все в деталях и структурирует каждый аспект:
Нужно написать текст на тему «Душевые кабины» объемом 3500 знаков. Уровень спама – до 55%, уровень воды не более 18%, уникальность – от 90%. Слово «душевые» использовать не более 15 раз. Избегать стоп-слов (и, или, но, а).
Далее мы рассмотрим пункты, которые входят в базовый шаблон ТЗ.
Технические характеристики
Технические аспекты включают в себя четкие требования к оформлению задачи, которые не получится двояко интерпретировать.
В случае с текстами сюда можно отнести:
-
количество знаков на абзац,
-
тип и размер шрифта,
-
количество используемых ключевых слов,
-
правила структурирования текста с помощью подзаголовков,
-
необходимые форматы данных (таблицы, списки, цитаты и т.п.).
В техническое задание для программистов можно включить:
-
выбор системы управления данными (WordPress, Joomla и т.п.),
-
выбор фреймворков (React, Angular и т.п.),
-
количество всплывающих окон,
-
ширину контентной части страницы,
-
расположение форм обратной связи в приложении,
-
дополнительные функции.
Структура может варьироваться в зависимости от пожеланий заказчика и поставленных задач. Если ширина страницы не имеет значения, то этот пункт можно убрать. Если, к примеру, необходимо использовать синий цвет в заголовках, то это тоже стоит заранее прописать в ТЗ.
Маркетинговые характеристики
Характеристики, помогающие продвижению сайта, сложнее задать так же четко, как технические.
Этот аспект возвращает нас к фразе «текст пишется для людей, а не для роботов», который часто можно увидеть в копирайтерских ТЗ. Тем самым заказчик дает понять, что нужно написать органичный и легко читающийся текст без обилия ключей для оптимизации под поисковые машины. Но как именно автор этого достигнет – не имеет значения.
Заказчик рассказывает о целевой аудитории и ее особенностях. Задача исполнителя – воспользоваться этой информацией и сделать итоговый проект/текст наиболее привлекательным для указанной ЦА.
Этапы работы
Также в техническом задании можно указать все этапы работы, включая промежуточные дедлайны. Это касается больших проектов. Например, в веб-разработке такой план может выглядеть следующим образом:
-
Этап разработки идей и дополнение существующего плана действий.
-
Демонстрация первого прототипа.
-
Приемка первой тестовой версии продукта.
-
Тестирование функциональности.
-
Разработки дизайна.
-
А/Б-тестирование визуальных компонентов и CTA-элементов.
Это примерная схема, которую можно менять на свое усмотрение, если есть четкие сроки выполнения задачи.
Другие аспекты
Важно, чтобы в ТЗ были пункты, помогающие обеим сторонам оценить эффективность проделанной работы. Задача заказчика – заранее прописать ожидаемые результаты как можно подробнее и четче, используя объективные критерии и характеристики, которые в конце можно будет посчитать.
Также стоит внести систему штрафов за корректировки ТЗ, чтобы ни у одной из сторон сделки не было соблазна постоянно редактировать итоговый продукт и менять сроки.
Срок выполнения работы тоже приписывается заранее, как и общий бюджет проекта.
Примеры ТЗ
Рассмотрим два абстрактных примера технического задания в том виде, в котором они часто встречаются.
Для разработчиков
Это сокращенный вариант технического задания, потому что обычно они гораздо больше.
Сайт должен быть выполнен в соответствии с указанным макетом. Цветовая палитра, расположение объектов, шрифты, текст и прочие элементы из Figma должны быть перенесены на итоговый проект.
Текст ТЗ может содержать более конкретную информацию об имеющихся функциях:
-
На сайте должна быть форма для загрузки файлов (только в форматах JPG, PNG).
-
При скролле должно появляться сообщение с предложением зарегистрироваться.
-
Если пользователь долго бездействует (более 20 секунд), должен появляться робот-помощник (его функциональность описана ниже).
-
Под каждым материалом на сайте должна быть секциями с комментариями.
Также в ТЗ можно внести требования к дизайну и оформлению кода:
-
Цвет подзаголовков берем из макета (#CD6326).
-
Списки должны быть оформлены в формате ul > li > a.
-
Блочные структуры должны быть реализованы с помощью свойства селекторов flex.
Отдельно можно указать технические средства, используемые в работе:
-
Работа должна быть доступна в репозитории my-new-project.
-
Каждое изменение должно сопровождаться отдельным коммитом.
-
В качестве базы данных используется технология MongoDB.
Для копирайтеров
Текст на тему «Стоит ли использовать WordPress в 2020 году?».
Общие требования к тексту:
-
Статья должна быть поделена на части. Каждый подзаголовок отделяет один логический блок.
-
В тексте необходимо использовать одну таблицу и минимум один список.
-
Между списками, таблицами, цитатами и подзаголовками должно быть расстояние минимум в 400 знаков.
-
В тексте должны быть подзаголовки второго уровня, минимальный промежуток между подзаголовками – 750 символов, максимальный – 900 символов.
-
Ключевые фразы должны быть использованы столько раз, сколько указано в скобках рядом со словом.
-
Ключевые фразы должны быть равномерно распределены по тексту. Расстояние между ключевыми фразами не менее 1000 знаков. Первое ключевое слово должно использоваться в первом абзаце.
Объем текста: от 10 000 знаков.
Примерная структура текста:
- Что такое WordPress.
- Основные преимущества WordPress.
- Сравнение WordPress с другими CMS.
Ключевые фразы:
- WordPress (8)
- Темы для ВордПресс (1)
- CMS WordPress (2)
- Для разработчиков (1)
- Для новичков (2)
- Как установить на сайт WordPress (1)
- Joomla (2)
- Drupal (1)
Вместо заключения
На этом все. Заносите в ТЗ все важные для бизнеса или проекта данные. Ставьте четкие требования и не допускайте разночтений, чтобы не возникало недопониманий и необходимости вносить срочные правки при приближении к сроку сдачи работы.