В чем проблема? Составить техническое задание – это половина успеха проекта при условии, что документ сделан по всем правилам. Нередко возникает ситуация, когда ТЗ есть, но сделано так, что каждый из участников по-своему понимает его положения.
Какое решение? Многое зависит от сферы, для которой составляется техзадание. Однако есть универсальные правила, которых необходимо придерживаться. Они касаются как оформления документа, так и его содержания.
В статье рассказывается:
- Суть и задачи технического задания
- Что сделать до составления технического задания
- Стандарты составления технического задания
- Кто составляет техническое задание
- Структура технического задания
- Этапы составления технического задания
- Роль технического задания в IT-методологиях
- Конкретизация задач в техническом задании
- Пример технического задания
- Ошибки при составлении ТЗ
-
Пройди тест и узнай, какая сфера тебе подходит:
айти, дизайн или маркетинг.Бесплатно от Geekbrains
Суть и задачи технического задания
Техническое задание (ТЗ) – это четкий и подробный список требований к итоговому продукту, составленный заказчиком для исполнителя. Объём технического задания может быть довольно внушительным (до нескольких десятков страниц), если, например, речь идет о масштабном проекте либо о создании сложнотехнологического оборудования.
Технические задания (как форма документа, так и его содержание) тесно связаны со спецификой итогового продукта, что является основной их особенностью. Особенно важным является создание ТЗ для различных программных продуктов, таких как веб-сайты, онлайн-сервисы, интернет-магазины и приложения.
Составление технического задания является неотъемлемой частью процесса реализации проектов, поскольку этот документ одновременно решает несколько задач:
- Подробно изложить причины необходимости реализации проекта.
- Четко определить требования к конечному продукту.
- Оценить компетенцию исполнителя.
- Определить характеристики, свойства, составляющие и прочие требования к конечному продукту в зависимости от его специфики.
- Подробно обозначить обязанности заказчика и исполнителя.
- Определить ключевые этапы и сроки реализации проекта как в целом, так и в отдельности по каждой задаче.
- Установить критерии, по которым будет оцениваться соответствие характеристик конечного продукта требованиям, определенным в задании.
Техническое задание также имеет важную функцию предотвращения или сокращения вероятных разногласий между сторонами, касающихся как отдельных характеристик/качеств товара или услуги, так и способов достижения намеченных целей. Следовательно, наличие качественного ТЗ является основополагающим параметром успешного взаимодействия между заказчиком и исполнителем, исключающим возможные конфликты. Но как правильно составить техническое задание? Будем разбираться.
Что сделать до составления технического задания
Для создания качественного ТЗ на IT-продукт необходимо сформировать функциональные и бизнес-требования. Это и есть основа технического задания.
Поговорим об этом детальнее.
Бизнес-требования представляют собой набор задач, которые будут решаться с помощью создаваемого программного продукта. Они должны указывать на основную цель его разработки, а также на то, как он будет способствовать достижению бизнес-показателей. Эта часть ТЗ должна быть написана простым языком, понятным людям, не владеющим техническими знаниями.
входят в ТОП-30 с доходом
от 210 000 ₽/мес
Скачивайте и используйте уже сегодня:
Топ-30 самых востребованных и высокооплачиваемых профессий 2023
Поможет разобраться в актуальной ситуации на рынке труда
Подборка 50+ бесплатных нейросетей для упрощения работы и увеличения заработка
Только проверенные нейросети с доступом из России и свободным использованием
ТОП-100 площадок для поиска работы от GeekBrains
Список проверенных ресурсов реальных вакансий с доходом от 210 000 ₽
Вот пример бизнес-требований:
- Выполнить настройку фильтрации каталога товаров, которая позволит пользователям осуществлять поиск по ключевым запросам, таким как тип товара, бренд, производитель, цвет и т.д.
Под функциональными требованиями (ФТ) стоит понимать совокупность условий, исполнение которых необходимо для реализации функционала системы без детального описания. Таким образом, ФТ определяют функциональность, которой должна обладать система. В дальнейшем, набор ФТ становится основой для разработки технического задания.
Вот пример ФТ:
- Необходимо установить порядок результатов поиска в зависимости от их релевантности. В первую очередь следует показывать товары, в названии которых содержатся все слова из поискового запроса. Затем идут товары, где слова запроса встречаются в различных свойствах, учитывая вес каждого из них. Наконец, товары, в которых меньше слов из поискового запроса, показываются в последнюю очередь.
- Необходимо реализовать возможность поиска товаров по свойствам, таким как бренд, суббренд, тип товара, производитель и страна производства.
- Результаты поиска должны быть отсортированы в соответствии с весом каждого упомянутого свойства.
Стандарты составления технического задания
Ниже в таблице приведены стандарты, позволяющие понять, как составить техническое задание хорошего качества.
Стандарты | Описание |
ГОСТ 19 | В соответствии с данным ГОСТом, ТЗ обязательно должно включать:
|
IEEE STD 830-1998 | Данный стандарт подразумевает присутствие в ТЗ для разработки ПО таких критериев, как:
|
ISO/IEC/ IEEE 29148-2011 | Данный стандарт нужен для единой интерпретации каждого процесса, используемого при разработке IT-продукта. Согласно ему, ТЗ для реализации таких проектов должно включать:
|
Кто составляет техническое задание
Не существует жестко установленных рамок в вопросе, кто будет заниматься разработкой ТЗ. Это зависит от соглашения между заказчиком и подрядчиком.
Варианты могут быть следующими:
Заказчик может составить ТЗ самостоятельно
Некоторые руководители предпочитают, чтобы заказчик предоставил подробное техническое задание и запросил оценку работ.
В данной ситуации мы имеем четкое представление о том, как, что, когда необходимо снимать. Это позволяет произвести быстрый расчет стоимости и сроков реализации проекта. Однако зачастую у заказчиков нет точного технического задания, поскольку они до конца не понимают, чего хотят от подрядчика. Тогда можно предоставить им форму, в которую они впишут ответы на наводящие вопросы.
Совместное составление ТЗ
Это может выглядеть следующим образом: клиент конкретизирует требования к будущему продукту, заполняет предоставленный бриф, после чего организовывается интервью, на котором будут согласованы детали.
Техническое задание разрабатывает подрядчик
В данном случае перед исполнителем ставится основная цель, а функционал и требования к будущему продукту он подбирает из различных источников (анализ конкурентов и потенциальных потребителей, интервьюирование персонала заказчика и т.д.).
Скачать файлРазработка ТЗ подрядчиком и совместное составление техзадания имеют отличие в подходе. К примеру, вам нужен интернет-магазин:
- Коллаборация. Подрядчик получает установку от клиента на предмет формата сайта (он должен красиво отображаться на десктопе и на любых других устройствах, клиенты могут открыть в нем ЛК и накапливать баллы). Исполнитель собирает дополнительную информацию, например, о том, как долго должны сберегаться баллы, каким образом они будут использоваться. Затем он фиксирует полученные данные в документ – ТЗ.
- Разработка подрядчиком. Клиент дает установку – создать интернет-магазин. Исполнитель с помощью бизнес-аналитика осуществляет сбор и структурирование требований к будущему проекту, проводит изучение ЦА и конкурентов, предлагает включить в техзадание требование по отображению веб-сайта на экранах телевизоров, так как потенциальные покупатели предпочитают делать заказы именно таким образом.
Не существует универсального решения, однако большинство склоняется к тому, чтобы разработкой ТЗ занимались подрядчики. Узкопрофильный специалист точно знает, как должен функционировать продукт. Однако заказчику не нужно полностью «выходить из игры» – его задача донести до исполнителя, чего конкретно он хочет от проекта, каким образом он будет использоваться, кто его целевая аудитория. Было бы неплохо, если бы клиент предоставил примеры качественных ТЗ конкурентов.
Структура технического задания
Строгие правила к разработке техзадания не предъявляются. Различные заказчики оформляют его по-разному, в зависимости от поставленных целей.
на курсы от GeekBrains до 01 декабря
Одни в 2-3 предложениях могут выразить основную идею и ожидают, что подрядчик придумает все остальные детали. Например:
- Необходим маленький текст на тему «Заработок на криптовалюте». В тексте не должно быть грамматических и пунктуационных ошибок. Пишем без спама, для людей.
Некоторые же подробно описывают каждый пункт, тщательно работая над структурой:
- Нужен качественный SEO текст по тематике «Пассивный заработок на криптовалюте» объемом 9000 – 10000 символов без пробелов. Уникальность – 100 %, заспамленность – 45 %, вода – до 20%. Употребить слово «криптовалюта» не менее 10 раз. Все представленные ключевые запросы равномерно распределить по тексту. Работу сдать в Word.
Читайте также!
Ниже мы детально остановимся на пунктах, составляющих базовый шаблон техзадания.
Технические аспекты
Сюда входят обязательные требования, интерпретировать которые нельзя двусмысленно.
При составлении ТЗ для написания текстов сюда относятся такие параметры:
- число символов в одном абзаце;
- количество вхождений ключевых запросов;
- шрифт – вид и размер;
- требования к структуре – заголовки, подзаголовки;
- требуемые форматы – цитаты, нумерованные и маркированные списки, таблицы и так далее.
В техзадание для IT-продуктов входят следующие характеристики:
- выбор системы управления информацией – Joomla, WordPress и другие;
- число всплывающих окон;
- выбор типа framework – Angular, React;
- ширина конкретных частей страниц;
- место расположения формы обратной связи;
- другие сопутствующие функции.
В зависимости от требований заказчика и задач, которые нужно достичь, структура может меняться. Так, например, пункт, касающийся ширины страницы, можно убрать, если этот параметр не столь важен. Если, например, в заголовках нужно использовать синий цвет, то это также должно быть отражено в техническом задании.
Маркетинговые стратегии
Задать показатели, способствующие продвижению IT-продукта, гораздо труднее, чем технические.
Данный вопрос возвращает нас к этапу «текст создаётся для человека, а не для поисковых машин», который мы часто встречаем в ТЗ для копирайтеров. Этим заказчик выражает свое требование к созданию органичного, легко читаемого текста, не изобилующего ключевыми фразами для SEO-оптимизации. При этом совершенно неважно, каким образом писатель будет достигать данной задачи.
Планирование разработки продукта
Клиент предоставляет информацию о своей ЦА и её особенностях. Подрядчик должен использовать эти данные для того, чтобы создать итоговый продукт, который будет максимально полезен конкретной целевой аудитории.
Этапы работы
В ТЗ можно обозначить все этапы работ, в том числе промежуточные дедлайны. В частности, это относится к большим проектам. К примеру, в web-разработке подобный план может быть представлен так:
- Разработка идей, плюс дополнение имеющегося плана действий.
- Презентация начального прототипа.
- Одобрение первой экспериментальной версии продукта.
- Проверка корректности работы продукта.
- Работа по созданию дизайна.
- A/B-тестирование элементов CTA и визуальных компонентов.
При наличии четких сроков реализации задачи можно менять данную примерную схему.
Прочие аспекты
ТЗ должно содержать пункты, которые будут помогать заказчику и исполнителю оценивать эффективность выполненных шагов. Клиент должен указать результаты, которые он хочет видеть, максимально детально и четко, используя объективные характеристики и критерии, подсчет которых можно будет произвести в конце.
Кроме того, рекомендуется включить систему штрафных санкций за корректировки техзадания. Это поможет избежать участникам договора постоянного редактирования конечного продукта и изменения дедлайна.
Общий бюджет проекта, равно как и срок реализации, прописываются заранее.
Этапы составления технического задания
Качественное техзадание составляется по универсальному шаблону, который представлен в таблице ниже:
Этапы подготовки ТЗ | Описание каждого этапа |
Предоставление подрядчику общих данных | Исполнитель должен иметь четкое представление о сфере деятельности компании заказчика и о его ЦА. Это поможет ему лучше вникнуть в задачу, которую перед ним ставит клиент, и не допустить элементарных ошибок. Озвучивая идею, следует остановиться на особенностях и конкурентных преимуществах будущего продукта. |
Предоставление списка основных конкурентов | Техническое задание должно включать ссылки на аналогичные проекты, а также дополнительное описание. Так подрядчику будет легче дать оценку хорошим примерам похожих разработок и исключить вероятные сложности при реализации. Более того, анализ особенностей чужих похожих продуктов помогает создать свое оригинальное решение. |
Указание вероятных сценариев использования итогового продукта | Наличие сценария облегчает понимание особенностей работы будущего продукта. К примеру, если сфера использования затрагивает IT, то сценарий должен отвечать на вопрос: «Каким образом будет вести себя пользователь?» и давать представление об основном функционале приложения/вебсайта. |
Ведение журнала правок | В самом начале ТЗ создайте табличку с графами «автор», «дата», «описание». Вносите в неё соответствующие изменения. Это поможет следить за статистикой возникновения тех или иных противоречий, требований, дополнений. |
Составление перечня сокращений и терминов | Это является основным правилом грамотного составления техзадания. Вначале основного текста размещается словарь, включающий специализированные необщеупотребимые термины. Отдельное внимание стоит уделить словам и аббревиатурам, используемым только в рамках данного проекта. |
Конкретизация деталей | Понятие вебсайта включает не только код, но и мощности, составляющие основу его работы. Первым делом стоит определиться с сервером для размещения продукта, предварительно проанализировав его параметры (оперативная память, емкость и т.д.).
Должен быть указан порядок и периодичность оплаты услуг сервера – будет ли эта обязанность возложена на плечи бухгалтерии либо подрядчику будет выделяться ежемесячная абонплата, из которой он сможет распределять средства на конкретные нужды. Также не стоит забывать и о пользователях. Нужно проанализировать, какие устройства и браузеры они используют чаще всего и адаптировать вебсайт под разные характеристики девайсов. |
Тщательное продумывание деталей | ТЗ не должно содержать никаких «пробелов». Продумайте все до мелочей, например, поведение рисунка при наведении на него: становится ли он прозрачным и с какой скоростью, как снова появляется, не уезжает ли вправо, скрывается ли и так далее. Стоит понимать, что любая непродуманная деталь может ввести разработчика в стопор. |
Указание четких требований к приемке готового проекта | При работе над составлением ТЗ необходимо составить детальный чек-лист, который поможет клиенту оценить успешность реализованного проекта, а также работы, проделанной подрядчиком. |
Роль технического задания в IT-методологиях
Водопадная модель разработки ПО
Водопадная модель – методика разработки программного обеспечения, основанная на последовательном выполнении определенных этапов, начиная со сбора и анализа требований и заканчивая интеграцией готового продукта. Каждый этап проходит строго по очереди, что позволяет следить за процессом разработки и обеспечивать более точное планирование.
В данной модели техническое задание играет важную роль, поскольку является основным документом для заказчиков, менеджеров, разработчиков. В нём должны быть учтены все детали, включая самые мелкие, чтобы обеспечить более точное планирование и успешную реализацию проекта.
Также целесообразно провести прототипирование интерфейсов. Чтобы продемонстрировать будущий продукт, рекомендуется создать прототипы всех экранов и связать их с соответствующими разделами технического задания. Важно отметить, что не требуется создавать окончательный дизайн экранов. Достаточно реализовать warframe с отображением основных элементов интерфейса, чтобы получить представление о конечном результате.
Если в IT-продукте будут задействованы сложные алгоритмы и сценарии взаимодействия программного обеспечения с пользователями, то рекомендуется заранее представить их в форме наглядных диаграмм последовательности и вариантов использования.
Читайте также!
Желательно (не обязательно) использовать основные языки системного моделирования при создании диаграмм для техзадания. Главное, чтобы пользователь мог четко различить, что они изображают.
Если водопадный подход к разработке программного продукта подвергается изменениям в начальных требованиях, это может привести к негативным последствиям для всех, кто участвует в процессе его создания. Поэтому часто до начала работы составляются сценарии возможных непредвиденных ситуаций и планы их решения. В таких случаях ТЗ имеет ключевое значение.
Также, в процессе продолжительной разработки, требования, которые были установлены в техническом задании, могут перестать быть актуальными. Эта проблема связана с различными внешними факторами, такими как изменения в обществе или устаревание технологий разработки, так как IT-сфера непрерывно и стремительно развивается.
Методология Agile
Современные студии разработки программного обеспечения применяют гибкую Agile-методологию, которая была создана в начале 2000-х годов. Её главная идея состоит в готовности быстро адаптироваться к изменениям в проекте на любой стадии его создания.
Требования к проекту больше не фиксируются четко, а в техническом задании, если оно вообще имеется, указываются исключительно основные пункты. Сейчас более важным является функциональность готового продукта, чем точное следование рекомендациям.
Agile-методология позволяет значительно ускорить процесс составления технического задания. Необходимо только разработать общую спецификацию и указать ключевые модули будущего продукта. В процессе разработки программного обеспечения можно организовывать демонстрационные встречи для клиента (этим, как правило, занимается проектный менеджер), чтобы он мог убедиться в соответствии результата целям проекта.
В Agile-методологии любые изменения в первоначальных требованиях не являются критическими. Обе стороны изначально готовы к возможному внесению изменений в проект.
Agile-методология также использует различные инструменты проектирования, как и Waterfall (водопадная модель), но уже не на этапе составления техзадания, а в процессе разработки продукта.
Agile-методология не требует жесткого фиксирования пользовательского интерфейса, сценариев и алгоритмов взаимодействия с пользователем. А техническое задание представляет собой общее описание итогового IT-продукта, помогающее сформировать общее представление о том, что в итоге будет достигнуто.
Гибкая методология разработки не требует точной предварительной оценки стоимости работ. Обычно окончательная цена IT-продукта зависит от фактических часов, потраченных специалистами на работу.
Конкретизация задач в техническом задании
- Заголовок задачи должен давать ответ на вопрос «Что нужно сделать?»
Примеры хороших заголовков:
- Создать дизайн анимированных баннеров для Facebook/Instagram и Google для {CLIENTNAME}.
- Исправить отображение страницы/pricing в мобильной версии.
Примеры плохой постановки задач:
- Баннеры для {CLIENTNAME}
- Верстка на странице цен
Смысл заключается в том, что ответ на вопрос «Что нужно сделать?» предполагает действие и мотивирует его выполнить. Правильно сформулированная задача должна показать видимый результат.
При понимании итогового результата исполнитель меньше прокрастинирует и решительно настроен как можно быстрее к ней приступить и выполнить.
- Формулировка задачи должна указывать на примерный объём предстоящих работ
Удачные примеры:
- Создать ХХ ресайзов дизайна для площадок {CLIENTNAME}.
- Сделать адаптивную вёрстку ЛК для {CLIENTNAME}.
Неудачные примеры:
- Дизайн для {CLIENTNAME}
- Сайт для {CLIENTNAME}
Вышеуказанные рекомендации применимы также для небольших задач, которые не требуют более подробного описания или понимания их решения. Кроме того, на эти правила следует опираться не только при работе с коллегами, но и при выполнении личных задач.
Пример технического задания
Давайте рассмотрим реальный пример техзадания, которое предназначено для веб-разработчика и касается доработки полей в CMS. В данном ТЗ содержатся следующие пункты с конкретными требованиями:
- Основная задача проекта – доработка полей в CMS.
- Исходные данные: неразбериха с тем, какие поля отвечают за тот или иной функционал, в каком шаблоне они находятся. В результате возникли проблемы с оптимизацией данных элементов.
Давайте рассмотрим подробнее.
Существует два вида страниц: записи и конкретно страницы.
- Пример записей – https://
- Пример страниц – https://
Вот пример того, как разные типы могут иметь различные поля:
- Для записей существует такой вариант поля.
- Для страниц подобного поля не существует.
Что необходимо выводить, какие поля нужны:
- Заголовок окна браузера (Title).
- Описание страницы (Description).
- Основной заголовок страницы (H1).
- Название страницы в breadcrumbs (хлебных крошках).
- Короткое название, отображающееся в верхнем меню на веб-сайте.
- Название страницы в админке.
Следующие элементы требуют создания отдельных полей:
- Title.
- Description.
- H1.
- Название страницы в breadcrumbs.
- Создание понятных названий для понимания предназначения конкретного поля.
- Группировка полей на странице для редактирования.
Наименование полей:
- Заголовок окна браузера (Title).
- Описание страницы (Description).
- Основной заголовок страницы (H1).
- Название страницы в breadcrumbs (хлебных крошках).
- Выяснить, откуда взято название в меню сайта.
- Выяснить, откуда взято название страницы в админке.
Требуется вышеуказанные поля на странице редактирования:
- Назвать.
- Расположить рядом друг с дружкой.
- Соблюсти вышеуказанную последовательность.
На скринах показана область места расположения полей.
Для работы 1 специалиста требуется … рабочих дней.
Бюджет проекта: … руб.
Ошибки при составлении ТЗ
Недостаток конкретики
Это критически важный дефект, который может привести к значительным издержкам. Например, в техническом задании указано, что исполнитель должен создать текст длиной в 2000 символов. Однако исполнитель и заказчик интерпретируют символы по-разному: первый считает знаки с пробелами, а заказчик – без учёта пробелов. Техзадание неопределенное, оно не содержит инструкций относительно пробелов.
Правильная формулировка задачи должна выглядеть следующим образом: «Исполнитель должен учитывать пробелы при подсчете объема текста». Иными словами, исполнитель должен написать текст, который будет состоять из 2000 знаков, включая пробелы.
Вот еще один пример. В ТЗ указано: «Текст должен быть уникальным на 80 %». Хотя на первый взгляд все выглядит благополучно, тем не менее возникает вопрос: какая система используется для определения уникальности? Заказчик использует одну систему, исполнитель – другую, что приводит к различным результатам. Это может спровоцировать конфликтную ситуацию.
Конкретное значение вместо интервала
Итак, вы думали, что учли все нюансы, когда написали «2000 символов с учетом пробелов», однако это оказалось не так. Когда вы сдали работу, выяснилось, что в нем всего 1996 символов, что не соответствует требованиям технического задания. Клиент не был удовлетворен результатом, и его претензии оправданы. Теперь вам придется приложить дополнительные усилия, чтобы достичь точного объема текста. Важно отметить, что если текст окажется длиннее на один символ, то это также будет являться нарушением ТЗ.
Чтобы избежать такой неопределенности, лучше использовать следующую формулировку: «Исполнитель должен написать текст, объем которого находится в диапазоне от 1800 до 2000 символов с учетом пробелов». Таким образом, это поможет сделать требования более ясными и понятными для всех сторон.
Интервал вместо конкретного значения
Это тоже может оказаться ошибкой. К примеру, заказчик указывает в техзадании: «Мне нужно, чтобы веб-сайт конкретно открывался в любом современном браузере». Но, что он вложил в понятие «современный браузер»?
К примеру, IE 6 может тоже показаться клиенту вполне современным браузером. Он же установлен на компьютере. И не важно, что ПК стоит на даче и крайне редко используется. Хоть браузер и работает, его версия сильно устарела и не поддерживает многие современные функции и технологии.
В данном случае стоит добавить в техническое задание закрытый список не только браузеров, но и версий, гарантирующих правильную работу веб-сайта.
Обещание сделать невозможное
Данный аспект крайне важен для специалистов, занятых в отраслях, где невозможно предоставить абсолютные гарантии результата. Например, при продвижении веб-сайтов невозможно гарантировать, что он займет определенные позиции в поисковых системах, так как эти позиции могут меняться в зависимости от компьютера, с которого пользователь вводит запрос, и нет однозначного определения, какие из позиций являются наиболее релевантными.
Неопределенность терминологии
Для избежания недопонимания между вами и клиентом, особенно в случаях, когда используются термины, не имеющие общепринятого значения, следует включать в техническое задание список таких терминов с их определениями. Это позволит избежать ситуации, когда исполнитель и клиент понимают одно и то же по-разному.
К примеру, если вы работаете на SEO-агентство, необходимо уточнить, как компания интерпретирует понятие «вхождение ключевого запроса в текст», так как в ТЗ это не указано. Важно узнать, можно ли менять порядок слов в запросе, использовать предлоги и изменять склонения и число слов. Если эти моменты не учтены, то возможно клиент будет требовать постоянных правок, что может затянуть работу и негативно повлиять на отношения с заказчиком.
Читайте также!
Присутствие субъективных требований
Заказчики любят прибегать к субъективным требованиям, что крайне не рекомендовано для подрядчиков. В особенности, если направление, в котором работает исполнитель, очень зависит от субъективных факторов. К примеру, не нужно указывать в техзадании, что текст должен быть креативным и позитивным. Исполнитель устанет создавать такой текст и убеждать клиента, что его текст после 500 правок уже «достаточно креативный».
Для обеспечения ясного понимания чего хочет клиент и что должен для этого сделать исполнитель, рекомендуется включить в техническое задание тезисный план текста. В случае, если исполнитель является дизайнером, к ТЗ рекомендуется приложить эскиз дизайна для уточнения требований. Таким образом, в зависимости от профессии, можно добавлять соответствующие элементы в техзадание для более точной постановки задачи и выполнения ее в соответствии с требованиями клиента.
Нельзя забывать о законе Мерфи, который гласит: «Если что-то может пойти не так, то оно обязательно пойдет не так». Это применимо и к разработке веб-сайтов, и к написанию текстов, и к созданию дизайнов. Если не угадать желания заказчика, то можно потратить много времени и ресурсов впустую. Поэтому так важно правильно и конкретно формулировать задачи в техническом задании, чтобы избежать недоразумений и достигнуть желаемого результата.