Как писать тз: инструкция по составлению грамотного техзадания

Бизнес vs Функциональные требования

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

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

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

Пример бизнес-требования:

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

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

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

Методы обеспечения качества

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

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

Чем раньше найдем ошибку, тем дешевле она нам обойдется. Самый простой способ исправлять ошибки — это вообще их не делать.

Я часто езжу на поездах в разные города. Прекрасный сервис, не надо платить за проживание, но там есть одна проблема — некоторые граждане храпят. А я довольно чутко сплю, и это всегда было проблемой. Я придумывал всякие способы, как от этого избавиться (есть баг — человек храпит, как это исправить). Иногда я просто стучал в стенку — дыщ-дыщ…. Человек просыпался, на какое-то время это помогало.

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

Голос из зала: Есть еще один способ! Вот такой — еще пива.

Еще пива — способ, да, я его тоже пробовал, но это полумера.

И вот я, по дороге сюда, все-таки исправил этот баг. Я сделал так, чтобы он вообще не появлялся. Я купил себе беруши. Знаете такие штуки? В уши вкручиваешь, и ни хрена не слышно, великолепно спишь. Кстати, появляются другие проблемы, можно проспать свою остановку.

Итак, как мы сделаем так, чтобы проблем не было вообще?

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

Некоторая «полумера» — ревью кода. Оно должно происходить до коммита, тогда имеет смысл его делать.

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

Если уж сделали ошибку, ее лучше исправить как можно раньше. Как это можно сделать? Ну вот:

• Непрерывная интеграция
• Юнит-тесты
• Разработка через тестирование (TDD)
• Автоматизированное приемочное тестирование

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

Требования поменяются, код будет деградировать, и вы рано или поздно столкнетесь с проблемой поддержки — когда у вас 50% времени занимает поддержка, исправление кода из-за того, что он не очень качественный. Код вообще, и в особенности в эджайле, надо поддерживать в великолепном качестве.

А что тогда такое «Ручное тестирование»? Если вы делаете все то, что написано на двух предыдущих слайдах, (это, кстати, бывает не всегда), то что остается на долю ручного тестирования?

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

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

Вот и все тестирование

Я тут с Лешей Кривицким разговаривал, говорю «Я поеду на конференцию, буду про тестирование в эджайле говорить», а он говорит «Я не понимаю, о чем вы там рассказываете. Просто автоматизируйте все тесты, и всё».

Леша рулит в agile, но он программист. У программистов всегда всё так — взять всё и поделить автоматизировать!

Основные принципы

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

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

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

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

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

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

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

Как составляется ТЗ на тендер

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

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

• государственные стандарты;
• рекламу и каталоги;
• публичные оферты;
• исполненные контракты;
• официальные информационные источники уполномоченных органов и др.

Как правило, документ с ТЗ содержит таблицу с характеристиками. Указывая характеристики, необходимо учитывать нормирование. Предельные характеристики обозначены в специальном перечне товаров, работ и услуг (Постановление Правительства Российской Федерации от 2 сентября 2015 года № 927). На его основе заказчики формируют свои списки и устанавливают требования к количеству и наивысшей цене товаров, а также к их свойствам. Перечень характеристик зависит от категории товара.

Обычно мы включаем

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

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

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

Роль: Администратор

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

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

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

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

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

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

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

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

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

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

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

Техническое задание по ГОСТу 19 должно содержать следующие разделы:

1. введение;
2. основания для разработки;
3. назначение разработки;
4. требования к программе или программному изделию;
5. требования к программной документации;
6. технико-экономические показатели;
7. стадии и этапы разработки;
8. порядок контроля и приёмки.

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

В разделе 1 «Введение» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.

В разделе 2 «Основания для разработки» должны быть указаны:

• документ (документы), на основании которых ведётся разработка;
• организация, утвердившая этот документ, и дата его утверждения;
• наименование и (или) условное обозначение темы разработки.

В разделе 3 «Назначение разработки» должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.

Раздел 4 «Требования к программе или программному изделию» должен содержать следующие подразделы:

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

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

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

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

В подразделе 4.4 «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их основных технических характеристик.

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

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

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

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

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

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

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

В разделе 8 «Порядок контроля и приёмки» должны быть указаны виды испытаний и общие требования к приёмке работы.

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

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

Насколько детальным должно быть техническое задание?

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

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

Вместо введения

Доклад был представлен на конференции SQA Days’2009 24 апреля. Его можно было послушать в виде слайдкаста (слайды, снабженные звуком), но слайдкаст утерян.

Текст совсем чуть-чуть поправлен и снабжен (не всеми) картинками в нужных местах.

Руководство по тестированию в Agile

Кто-нибудь работает по эджайлу? Пожалуйста, поднимите руки. Уау… А из тех, кто не поднял, кто-нибудь собирается это сделать? Хорошо. Давайте я сначала представлюсь — меня зовут Асхат Уразбаев, меня уже представили, поэтому я коротко… Он сказал всю правду обо мне, немножко преувеличил местами… Работаю в компании ScrumTrek, мы занимаемся внедрением гибких методологий, помогаем компаниям и организациям всем этим заниматься.

Разработка технического задания: ключевые этапы

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

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

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

Как составить техническое задание: советы из личного опыта

Техническое задание должно быть детальное.

Не бойтесь описывать каждый элемент, каждый пункт, каждую кнопку. Все-все-все максимально детально пишите.

Не бойтесь показаться дотошным.

Уж лучше что-то несколько раз повторить и разжевать, нежели потом доделывать, доплачивать, дорабатывать.

Последнее техническое задание, которое я писал, касалось разработки сайта. Это был большой информационный проект. Сначала разработали дизайн, а потом на его основе описывал функциональное задание для программистов. Так вот, все ТЗ получилось на 54 страницы А4 11 шрифтом.

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

Техническое задание должно быть четкое.

Не нужно никакой воды. Все по делу. Если пишите о срока, то конкретную цифру, если о функционале, то перечень нужных вам функциональных решений и т.д.

Ваше техническое задание – это не догма

А лишь один из возможных вариантов исполнения задач.

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

Они могут что-то увидеть, высказать свое мнение, подсказать оптимальное решение исполнение.

Что такое метод «5 почему»

Суть метода пяти почему: сформулировать проблему и последовательно задавать вопрос «Почему это случилось?», отталкиваясь от предыдущего ответа. Задав вопрос пять раз, вы найдете источник проблемы, ее первопричину.

`pc`

{{/pc}}

`mobile`

{{/mobile}}

Создается цепочка причин, причинно-следственная связь, которая должна работать и в обратном направлении.

`cta_banner`

Приведем пример выявления первопричины проблемы.

Проблема: клиент отказался от сделки.

1 Вопрос: почему клиент отказался от сделки?

Ответ: потому что посчитал, что услуга стоит дорого.

2 Вопрос: почему клиент посчитал, что услуга стоит дорого?

Ответ: потому что менеджер не смог обосновать ему стоимость услуги.

3 Вопрос: почему менеджер не смог обосновать ему стоимость услуги?

Ответ: потому что менеджер плохо знает продукт.

4 Вопрос: почему менеджер плохо знает продукт?

Ответ: потому что сотрудник работает месяц и не успел ознакомиться с продуктом.

5 Вопрос: почему за месяц менеджер не успел ознакомиться с продуктом?

Ответ: потому что в компании отсутствует система адаптации новых сотрудников.

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

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

`pc`

{{/pc}}

`mobile`

{{/mobile}}

Разработал метод «5 почему» изобретатель и основатель компании «Toyota» Сакити Тоёда. Впоследствии методика стала одним из инструментов производственной системы Toyota, которая получила название «Концепция бережливого производства» или «Lean production».

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

С чего начать составление грамотного технического задания

Итак, давайте же перейдем к главной теме этой статьи

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

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

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

Рекомендуем прочитать: «Что такое вендинговый бизнес и как его начать?»

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

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

Для чего?

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

Приведу пример.

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

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

Функциональные требования

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

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

Рекомендуем прочитать: «Как составить правильный бизнес план: пошаговые рекомендации»

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

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

Сроки

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

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

Отчетность

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

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

Ответственность

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

Какую? Во-первых, в соответствии с законодательством, но также вы можете установить какие-то свои штрафы и санкции.

Рекомендуем прочитать: «На что обратить внимание при составлении бизнес плана для игровой комнаты»

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

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

• цели, результаты и видение: что, как и в каком объеме должно быть достигнуто;
• стороны, которые принимают участие, их обязанности, полномочия и ответственность. Например, если к проекту привлекаются маркетолог, дизайнер, программист, верстальщик и контент-менеджер – для каждого есть отдельный план;
• ресурсы и финансы, за счет которых будет достигнут необходимый результат;
• график выполнения и структуру работы.

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

Пример структуры страницы для техзадания

Залог успешного проекта: своевременная корректировка ТЗ

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

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

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

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

Из чего состоит техническое задание

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

1. Описание проекта/задачи. Кратко пишем, что за проект или задача, которую нужно выполнить.
2. Назначение и цели. Какие цели стоят перед проектом.
3. Требования. Дизайн, функции, технологии, которые необходимы.
4. Описание работ. Что, когда и как будет выполнено.
5. Порядок контроля и приемки. Как будут приниматься работы, что можно считать выполненным.
6. Приложения. Эскизы, наброски, прототипы.

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

–

–