Техзадания: Как составить техническое задание и получить то, что нужно — СКБ Контур

Техническое задание на разработку сайта — инструкция, примеры, образец

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

Исполнитель или клиент пишет техзадание для всего проекта. Далее оно будет делиться на другие техзадания для разных видов работ и соисполнителей.

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

Кто составляет техзадание

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

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

Борис Качанов. Frontend-разработчик

Польза техзадания для исполнителя

• Понятно чего хочет инвестор.

• Исполнитель сразу понимает сможет ли он написать задуманное.

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

• Правильный пример ТЗ на создание сайта облегчает процесс выполнение задач.

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

• Исполнитель сможет рассчитать приблизительное время работ и стоимость.

Польза техзадания для клиента

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

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

• Есть возможность заменить рабочего с минимальными потерями для дела.

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

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

Борис Качанов. Frontend-разработчик

Так что же такое «Техническое Задание»? / Хабр

Данный текст был создан сугубо ради существования постоянной ссылки, которую бы сам автор, да и все вы — могли бы смело отправлять своим будущим заказчикам, коллегам, родственникам и знакомым в виде стандартизированного ответа на вопрос: «А надо ли мне ваше ТЗ и вообще что это?»

Как говорится — «вместо тысячи слов», поскольку каждый раз евангелистить по 4-5 часов в скайпе на данную тему становится уже утомительным, а общемировая тенденция подсовывать под определение «Технического задания» откровенную ерунду с годами все только усиливается.

Проблема

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

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

Переводим на понятный язык

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

2) Собственно из первого пункта логично вытекает и новый — сам текст ТЗ обязан начинаться с главы «Цели и задачи», четко формулирующей, какие бизнес-цели преследует вся эта очередная попытка повысить энтропию в мире. Бесцельное задание, которое не решает никаких проблем, не достигает ничего и делается «от скуки» — официально не считается Техническим Заданием, а с этого момента находится в статусе «обычная бумажка».

3) Как же вам понять, решает ли предложенная дизайн-концепция или интерактивный прототип, а то и готовый к употреблению сайт — вышеизложенную задачу бизнеса? Ничего не поделаешь, придется опять вернуться к определению: «определяет… ожидаемые результаты и сроки выполнения. То есть должны быть объективные критерии, по которым можно определить, сделан ли тот или иной пункт работ или нет». То есть ТЗ без четких измеримых показателей в рублях, секундах, тонно-километрах или градусах Цельсия — быть не может. Бриф может, или прототип, или еще любая абсурдная бумажка, но только не ТехЗадание.

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

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

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

5) Каждое внесение правок в готовое ТЗ должно стоить денег. Нельзя бесплатно и бесконечно править «Конституцию вашего проекта» только потому, что одна из сторон передумала, не выспалась, внезапно решила сэкономить и т.д. Цена каждого изменения в ТЗ должна также четко прописываться заранее в соответствующей главе.

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

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

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

Контрольные вопросы


А здесь перечислю ответы на самые часто встречающие вопросы от заказчиков:

1) Так что, на написание ТехЗадания может еще и официальный ГОСТ есть? — Да, даже несколько.

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

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

4) Вот вы и Википедия пишете, что ТЗ создается заказчиком. Но я не умею\мне некогда\просто не хочу его делать сам. Как же быть? — Отдать разработку ТЗ третьей стороне, вполне знакомой с вашим бизнесом, его задачами, целевой аудиторией и потребностями, и в то же время досконально осведомленной о всех этапах веб-разработки. Эта третья сторона станет неким «веб-нотариусом», то есть гарантом того, что исполнитель не занизит нужные вам показатели или не затянет сроки, и что заказчик установит достижимые метрики и на итоговой приемке не будет субъективно оценивать созданный продукт, на ходу изменяя зафиксированные ранее требования.

5) И что, если ТЗ является юридическим документом, то я потом могу засудить аутсорсера, не заплатить ему, заставить переделать все в десятый раз? — Если документ составлен правильно, указаны цели и методология оценки их достижения; если документ подписан сторонами и упомянут в Договоре (само ТехЗадание договором не является) — то конечно же сможете. А вот с обычным брифом, прототипами, арт-креатив-макетом, Безопасной сделкой на FL — уже нет.

6) Мне говорят, что работа будет вестись по какому то то ли скраму, то ли аджайлу; а значит архаичное ТЗ мне больше уже не нужно. Это так? — Посудите сами: вам называют непонятное слово, явно что-то маскирующее и вот уже на основании незнакомого вам термина предлагают отказаться от юридически грамотного и наполненного целями и метриками документа. Сам же agile никаких целей вроде «достичь не менее 10 000 посещений к концу года», или «достичь цифры более 25 заказов с сайта через месяц» — установить не может, это просто способ проведения совещаний и новой организации нерадивых сотрудников. Задумайтесь несколько раз: «А не пускают ли вам пыль в глаза?». На самом деле никакому новомодному скраму профессиональное ТЗ повредить не может, а вот помочь — обязательно.

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

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

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

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

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

  • Предыстория: опишите контекст, в котором будет реализован план обеспечения безопасности на воде, и почему он необходим 
  • Цель/задачи: резюмировать основные цели плана  
  • Объем работ: определение основных компонентов плана и описание целевой группы населения
  • Методология: описать структуру плана, как план будет реализован и как он будет оцениваться  
  • Управление и подотчетность: перечислите необходимые утверждения и наметьте планируемую структуру управления 
  • Квалификация: перечислить опыт, необходимый для реализации плана  
  • Результаты: перечислите результаты, которых план должен достичь, чтобы считаться успешным.
    — Включите подробную информацию о реализации любых вмешательств, любом запланированном сборе данных, запланированном выпуске отчетов и других материалов для распространения.
    — Включите сроки и вехи.
    — Включите планы встреч и консультаций.
  • Бюджет и оплата: укажите, кто за что будет платить
  • Уровень усилий: расчетное время, необходимое для разработки и реализации плана  
  • Дополнительные ссылки и ресурсы  

Преимущества

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

Недостатки

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

Контекст

ТЗ

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

 

Примеры

Шаблон ТЗ (PDF, 64 КБ)

Пример ТЗ для должности руководителя группы (PDF, 120 КБ)

Пример ТЗ для команды руководителей (PDF, 112 КБ)

Дополнительная информация

Руководство по составлению ТЗ (PDF, 505 КБ)

Базовая структура ТЗ

Руководство по ТЗ проекта

обратно наверх

ТЕХНИЧЕСКОЕ ЗАДАНИЕ определение | Кембриджский словарь английского языка

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

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

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

Из Кембриджского корпуса английского языка