Техническое задание

Техническое задание. Принципы написания.

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

Стоит отметить, что в повседневной аналитической работе мы стараемся избегать термина «Техническое задание». Этот термин слишком перегружен смыслами и часто неясно, что за ним стоит. Мы используем термины «Бизнес-требования» (BRD - Business requirements document), «Функциональные требования» (FRD – Functional requirements document) и Технико-архитектурные требования (TAD – Technical Architecture document). Однако здесь, чтобы не усложнять описание, мы будем использовать именно термин «Техническое задание». Документ, который мы в большинстве случаев используем для взаимодействия с заказчиками состоит на 70% - из бизнес-требований, на 20% из функциональных требований и только на 10% - из технико-архитектурных требований. Конечно, эта пропорция варьируется в зависимости от специфики и технической сложности системы.

Главным фактором успеха при разработке технического задания является правильно выстроенная коммуникация с заказчиком. Ведь задача аналитиков состоит в том чтобы фактически произвести операцию brain-dump, и результаты расположить на бумаге в структурированном виде. При этом очень важно (1) разговаривать с заказчиком на одном языке, чтобы тому не приходилось разжевывать очевидные для специалиста понятия предметной области и (2) уметь правильно слушать.

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

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

1. Оглавление 2. История изменений документа 3. Участники проекта 4. Назначение документа 5. Терминология 6. Общий контекст

Если в начале документа даётся общая, концептуальная информация о разрабатываемой системе, то во второй, основной части документа, детально прописываются бизнес-требования и существенные для оценки стоимости разработки функциональные требования к системе.

В разделе «Терминология» технического задания на баннерную систему мы определяем такие понятия как Показы, Клики, CTR, Охват, Частота контакта, Файл бронирования и т.п, а в разделе «Общий контекст» - описываем основные бизнес-процессы компании-заказчика, относящиеся к размещению баннерной рекламы, а также - системное окружение, текущие роли менеджеров компании и права доступа. Стоит отметить, что в данном конкретном случае система строилась не на пустом месте. Ранее менеджеры компании использовали другую, отличную от нашей, систему размещения баннерной рекламы. В противном случае - анализ ролей и прав доступа был бы скорее всего вынесен в отдельную главу.

7. Система размещения баннеров 8. Взаимодействие с биллингом 9. Banner Engine 10. Техническое описание компонента Banner Engine

Самый объемный раздел описываемого нами технического задания – «Система размещения баннеров»; он посвящён ядру разрабатываемой системы и содержит все требования непосредственно к системе управления рекламными местами. Учитывая специфику данного проекта, мы посвятили отдельный раздел взаимодействию баннерки с биллинговой системой. Также в отдельный раздел мы выделили требования к достаточно независимой компоненте сбора и отображения статистической информации, которая является для заказчиков рекламных кампаний и менеджеров рекламных агентств едва ли не основным компонентом системы.

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

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

Каждое техническое задание отличается по размеру, числу иллюстраций, количеству версий. Для примера, документ на баннерку представлен на 44 страницах и содержит 15 иллюстраций. Процесс подготовки этого документа занял около месяца и включал около 8 итераций с заказчиком.

В техническом задании регистрируются как бизнес-требования к системе, так и функциональные требования:

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

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

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

Пример функционального требования:

«Для решения этой задачи [какой – см. выше] предполагается использовать внешний сервис, к которому баннерные сервера будут обращаться при каждом показе баннера. Поскольку данный сервис является точкой отказа, баннерные сервера должны корректно обрабатывать ситуацию когда внешний сервис недоступен или отвечает с задержками».

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

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

Название сценария: Создание рекламного места

Пример функционального требования:

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

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

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

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

«Система баннерной рекламы связана с тремя внешними модулями, функционирующими в окружении компании: системой управления сайтом компании, системой биллинга и системой аутентификации и хранения данных пользователей». Каждый показ баннера сопровождается запросом от системы управления сайтом к баннерной системе. Эти системы, кроме того, используют общие идентификаторы площадок и рекламных мест, а также согласованные имена параметров таргетирования».

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

« Размещение (единица размещения, строка медиаплана) – это сущность, объединяющая баннер, который необходимо показывать, рекламное место, на котором будет показан баннер, а также правила показа. Правила показа определяют период размещения, параметры таргетирования, лимиты размещения, веса и т.п. Фактически, все рекламные кампании состоят из размещений».

Частота контакта – количество уникальных пользователей, посмотревших рекламный баннер определенное число раз. Например, частота контакта 5 – количество уникальных пользователей, каждый из которых посмотрел данный рекламный баннер не менее 5 раз. Частота контакта 1 = Охват.

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

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

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

По необходимости, мы используем в ТЗ прототипы избранных экранов системы (functional wireframes), которые, не являясь окончательными, демонстрируют базовый блок функциональности пользовательского интерфейса.

Вот такой прототип экрана редактирования рекламной кампании был включен в ТЗ на систему баннерной рекламы.

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

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

Большое значение при создании технического задания имеет опыт разработки похожих систем. Он помогает быстрее вникать в бизнес-процессы и потребности заказчика, делать «по аналогии» многие вещи, которые ранее казались бы нам сложными. Накопленный опыт в области управленческих бизнес-систем, крупных интернет-проектов, финансовых систем, e-commerce систем позволяет нам применять свои знания в отношении каждого последующего проекта, которым мы занимаемся. До того, как получить заказ на систему баннерной рекламы, упомянутую выше, мы уже занимались разработкой нескольких баннерных систем. Мы хорошо знали, как работают баннерки, знали характерную терминологию этой предметной области. На основании нашего опыта работы с другими баннерными системами, мы предложили заказчику довольно много упрощений, оригинальных решений, не только в сфере технологий, но и бизнеса.

Техническое задание согласно ГОСТу

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

Как правило, этапу составления технического задания предшествует проведение обследования предметной области, которое завершается созданием аналитического отчета. Именно аналитический отчет (или аналитическая записка) ложится в основу документа Техническое задание.

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

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

Руководствующими стандартами при написании технического задания являются ГОСТ 34.602.89 «Техническое задание на создание автоматизированной системы» и ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению». Первый стандарт предназначен для разработчиков автоматизированных систем, второй для программных средств (разницу между данными сериями мы обсуждали в статье «Что такое ГОСТ» ).

Итак, ниже мы представляем список и описание разделов, которые должно содержать техническое задание согласно ГОСТам.

ГОСТ 19.201-78 Техническое задание. Требования к содержанию и оформлению

ГОСТ 34.602.89 Техническое задание на создание автоматизированной системы

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

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

• Общие сведения о системе (программе);
• Назначение, цели и задачи системы (программы);
• Требования к системе (функциональные требования, пользовательские требования, требования к системе в целом и тд);
• Требования к видам обеспечения;
• Требования к документированию;
• Стадии и этапы разработки;
• Порядок контроля и приемки системы (программы).

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

«В данном документе создаваемая информационная система называется «Единое окно доступа к образовательным ресурсам», сокращенно ЕО.
Систему Единое окно доступа к образовательным ресурсам далее в настоящем документе допускается именовать Единое окно или Система.»

Также сюда следует включить подразделы сообщающие реквизиты организаций участвующих в разработке (Заказчика и Исполнителя).

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

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

Неотъемлемой частью документа Техническое задание также должен быть список терминов и сокращений. Термины и сокращения лучше представить в виде таблицы с двумя столбцами «Термин» и «Полная форма».

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

Назначение и цели создания системы

Данный раздел документа Техническое задание должен содержать назначение и цели создания системы.

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

Основной целью Системы является формирование единой информационной среды и автоматизации бизнес-процессов Образовательных учреждений Российской Федерации.

Создание информационной системы «Единое окно» должно обеспечить:

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

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

Требования к системе

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

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

«4.1 Бизнес-процесс «Предоставление информации об образовательных учреждениях Российской Федерации

В данном бизнес-процессе выделяются следующие участники:

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

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

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

4.1.1 Регистрация образовательного учреждения в Системе

Регистрация образовательного учреждения Российской Федерации осуществляется ответственным сотрудником учреждения («Постановление Правительства …»).

Процесс регистрации образовательного учреждения включает следующие шаги:

• Автор создает запись об организации;
• Автор заносит данные организации;
• Система проверяет наличие лицензии для данной организации

• Если лицензия существует в базе данных, Система отправляет Автору сообщение об успешной регистрации;
• Если лицензия не найдена в базе данных, Система отправляет сообщение Автору об отсутствии лицензии для данной организации.»

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

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

• требования к режимам функционирования системы
• показатели назначения
• требования к надежности
• требования к безопасности
• требования к численности и квалификации персонала и режиму его работы
• требования к защите информации
• требования по сохранности информации при авариях
• требования к патентной чистоте
• требования по стандартизации и унификации
• и т.д.

Требованиям к видам обеспечения

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

Требования к документированию

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

Данный раздел технического задания также важен, как и описание функциональных требований, поэтому не следует ограничиваться фразой «Заказчику должна быть предоставлена вся документация согласно ГОСТ 34». Это означает, что вы должны предоставить весь пакет документов включая «Формуляр», «Паспорт» и т.п. Большинство документов из списка, указанного в ГОСТ 34.201-89 не нужны ни вам, ни заказчику, поэтому лучше сразу согласовать список на этапе разработки документа Техническое задание.

Минимальный пакет документов обычно включает:

• Техническое задание;
• Ведомость эскизного (технического) проекта;
• Пояснительная записка к Техническому проекту;
• Описание организации информационной базы;
• Руководство пользователя;
• Руководство администратора;
• Программа и методика испытаний;
• Протокол приемочных испытаний;
• Акт выполненных работ

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

Стадии и этапы разработки

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

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

Порядок контроля и приемки системы

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

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

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

Написание технического задания для разработки сайта

Виртуальный офис

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

Продвижение сайтов

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

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

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

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

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

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

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

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

1. Описание компании-заказчика (продукция, услуги, время существования на рынке и т.д.)
2. Аудитория сайта (характеристика трафика; кого мы хотим привлечь на сайт и какие действия мы ожидаем от пользователей — просмотр информации, звонок в компанию, онлайн-покупка и пр.)
3. Задачи сайта (продажи, сервисное сопровождение клиента, информирование о продукции)
4. Тип сайта (интернет-магазин, корпоративный портал, сайт-визитка)
5. Функционал (перечень страниц, технических средств и модулей, служащих для достижения заданных целей)
6. Структура и навигация (разделы сайта, основное меню и подменю, пути перемещения пользователя по внутренним страницам)
7. Описание модулей и страниц (макеты страниц, дизайн, графика, количество и содержание полей форм обратной связи, виджеты, регистрация и проч.)
8. Техническая информация («движок сайта», хостинг, совместимость с разными браузерами и операционными системами, требования к администрированию)

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

• Хорошее техническое задание имеет последовательную логическую структуру. Каждый следующий пункт должен служить продолжением предыдущего и в то же время быть четко разграничен — это важно для контроля над ходом разработки.
• Ни в коем случае в ТЗ не должно присутствовать субъективно-оценочных условий вроде «удобный интерфейс», «привлекательный дизайн» и тому подобного.
• Задание лучше точно распределять по специалистам. Дизайнер, программист, верстальщик и другие участники разработки должны знать свой фронт работы и выполнять то, что входит в их компетенцию.
• Составлять ТЗ лучше на основе анализа сайтов конкурентов. Желательно привести 2-3 примера решений, которые нравятся заказчику, и 2-3 примера неудачных, на его взгляд, сайтов. В этом случае исполнитель будет точнее понимать рамки задачи.
• Каждый элемент страницы следует описывать именно так, как его видит заказчик. Например, виджет погоды или курсов валют нужно заказывать с пояснением, откуда следует брать информацию, в каком графическом виде ее представить, какие именно города или валюты требуется указать.

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

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

Разработчик в 99% случаев может составить ТЗ более грамотно, так чтобы не только клиент, но и программисты полностью понимали условия задачи. Как вариант, схема сотрудничества может выглядеть следующим образом:

1. Заказчик обрисовывает общие пожелания, кратко описывает свой бизнес и сообщает, для каких целей ему нужен сайт.
2. Исполнитель составляет примерный вариант техзадания, указывая в нем ключевые параметры.
3. Затем стороны совместно вносят поправки и оговаривают подробности.
4. Исполнитель пишет окончательный вариант ТЗ и после полного согласования приступает к основной работе.
5. После выполнения каждого пункта заказчик проверяет ход разработки, корректирует и направляет процесс.

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

Контакты телефон: 8 800 775-64-07 e-mail: info@clever-as.ru

Примеры технического задания на написание текстов копирайтеру

На должности SEM-специалиста на веб-студии мне постоянно приходиться делать технические задания на написания текстов. От малых на 1-5 текстов до больших на 100-200 шт. В среднем, приходиться писать до 20 ТЗ копирайтеру в месяц.

Выкладываю несколько примеров технических заданий на написание текстов копирайтеру:

1. ТЗ тексты cleanin-g август — Пример небольшого ТЗ проекта, который находиться на студийном ведении. Этот сайт есть в моем портфолио.
2. Техническое задание копирайтеру Elitdrevstroi — пример большого технического задания копирайтеру. Обычно, такое ТЗ нужно составлять в процессе внутренней оптимизации интернет магазина с большим числом категорий.
3. ТЗ тексты — Еще одно ТЗ в процессе внутренней оптимизации.
4. ТЗ тексты для клиник — Пример технического задания на написание текстов с абзацами.

Другие интересности на SeoKrem.com:

полистал пару тз. пошлятина одна. кто же так ТЗ составляет.

Свежие статьи на почту!

Краткий список услуг

Полное вовлечение бизнеса в интернет
от $300/месяц SEO:

Для вас старается Малышев Роман.

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

В своей практике я нередко сталкивался с мнением, что техническое задание не нужно, что оно будет только мешать и тормозить процесс разработки, сковывать его. Считаю это крайне неверной позицией. Это позиция людей некомпетентных, непрофессиональных. Почему таким людям (это, как правило, разработчики) выгодно отсутствие ТЗ?

1. Это скрывает отсутствие опыта, слабое представление сути дела, за которое берётся разработчик;
2. Это даёт возможность затянуть разработку и увеличить бюджет;
3. Это позволит недобросовестному исполнителю безнаказанно урезать объёмы работ, ухудшать характеристики;
4. Это позволит исполнителю “левачить” - заниматься другой разработкой в то время, пока заказчик ему платит. Разработчик может выполнять часть работ, якобы нужных для проекта, а потом сдавать их на сторону.

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

Как аргументируют отказ от оформления ТЗ?