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

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

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

Зачем нужно техническое задание?

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

Получите 267 видеоуроков по 1С бесплатно:

Что должно содержать в себе техническое задание?

Тех. задание обязательно должно содержать в себе:

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

Также существуют государственные стандарты к написанию ТЗ — ГОСТы. На практике мало где применяются, но бывает, заказчик настаивает на этом.

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

Примеры и образцы ТЗ для 1С

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

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

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

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

Кроме того, есть ряд ГОСТов, например, 19.201-78, в которых прописано, что и в каком виде должно содержаться в подобном документе.

Однако, как показывает практика, под заветной аббревиатурой «ТЗ» понимаются совершенно разные по сути, содержанию, оформлению и детализации документы. К сожалению, многие заказчики уверены, что, написав пару страниц требований к будущей системе, они получат от нас точную (максимум с дельтой в 10-20%) оценку с календарным планом работ. Получая в очередной раз на почту «ТЗ, по которому к завтрашнему дню надо дать оценку и выслать КП», я всегда морально готовлюсь увидеть очередное творение в стиле «система должна обмениваться с сайтом всей необходимой информацией».

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

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

Так как же составить ТЗ, по которому в итоге получится именно то, что было заложено его автором(-ами), а не то, что «умеет типовой функционал конфигурации»?

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

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

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

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

3. Usability. Из двух предыдущих пунктов есть простое следствие – понятная логика работы и максимальная визуализация будущей системы помогут в итоге заложить в ТЗ нужное количество примечаний\пунктов, касающихся удобства использования системы. Для систем, с которыми работают низкоквалифицированные сотрудники, это может стать решающим фактором успешности проекта (впрочем, этот параметр также крайне важен и для топ-менеджмента, не желающего иметь дела с «этими бухгалтерскими программами»). Например, в ТЗ на систему для розничных продаж не указали, что поиск артикула должен занимать не более трех секунд. Если бы систему реализовали через типовой поиск конфигурации, то это могло привести к критическим ситуациям в реальной эксплуатации, т.к. с учетом количества номенклатуры этот поиск занимал до 30 секунд, что недопустимо при работе с розничными покупателями, где каждая секунда на счету.

4. Ссылки на популярные решения . Зачастую, для всех, к примеру, менеджеров по продажам компании, фраза «функционал ведения сделок» означает примерно одно и то же, но для сотрудников подрядчика эта фраза не значит ровным счетом ничего. Но добавьте пару слов в эту фразу, и из варианта «карточка сделки, аналогичная таковой в Битрикс24(или 1С:CRM)» уже понятно, чего примерно ожидает от этой самой карточки Заказчик.

5. Первичная обратная связь . Еще раз повторюсь - для успешной реализации ТЗ его не обязательно писать по ГОСТу. Не нужно писать документ, предназначенный только техническим специалистам. Техническое задание в первую очередь должно быть понятно коллегам его составителя, а потом и тем, кто будет его реализовывать. Крайне важно получить положительную обратную связь от коллег бизнес-пользователей, прежде чем направлять документ потенциальным подрядчикам или внутреннему отделу разработки. Документ, предельно ясный одному человеку, но не понятный даже ближайшему окружению не имеет шансов на успешную реализацию.

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

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

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

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

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

Его применяют в своей работе строители, мастера, выполняющие ремонтные работы, программисты, дизайнеры и многие другие специалисты.

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

Особенности техзадания

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

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

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

Эта задание, выполняет важную функцию: она помогает разрешить возможные спорные ситуации. Будучи изложенными в письменном виде, требования к проекту или объему работ становятся ориентиром для обеих сторон. Исполнитель имеет право не выполнять ту работу, которая не указана в техническом задании. Для дополнительных действий необходима новая инструкция.

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

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

Состав ТЗ: требования к функциональности

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

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

• К функциональной составляющей.
• Для параметров безопасности (для автоматических систем и программного обеспечения).
• К квалификационному уровню специалистов.
• К внешнему виду.
• К используемым материалам.

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

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

Характеристика требований

В отличие от многочисленных видов требований, свойств для их характеристики намного меньше:

• Понятность.
• Конкретность.
• Тестируемость.

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

Техническое задание - это не технический проект

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

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

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

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

Структура технического задания

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

Как правило, вначале, в вводной части, излагают цель и назначение проекта. Далее следует перечисление разделов, требований и их расшифровка. Чтобы понять, как выглядит ТЗ для автоматизированной системы, можно рассмотреть структуру, рекомендуемую ГОСТом 34.602-89:

• Указание общих сведений.
• Описание назначения и цели, ради достижения которой планируется создание или развитие системы.
• Характеристики объектов, подлежащих автоматизации.
• Изложение требований к системе.
• Состав и содержание мероприятий и работ, применяемых для создания системы.
• Описание того, как должен проходить контроль создания и процедура приемки готовой системы.
• Перечень требований к работам, которые будут проводиться с объектом автоматизации для его подготовки.
• Порядок ведения документации.
• Указание источников разработки.

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

Зачем составлять ТЗ для ремонта комнаты

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

По этой причине техническое задание на ремонт становится одним из важнейших этапов, так как позволяет:

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

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

Какие пункты включает техзадание для ремонта комнаты

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

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

2. Характеристика пола: объем работ, которые нужно выполнить на этом участке. Здесь можно подробно указать, что именно необходимо выполнить мастерам:

• Демонтировать пришедшее в негодность покрытие, плинтуса и черновые полы (тип и квадратура).
• Нанести выравнивающую, разделительную стяжку и термоизоляцию (площадь и высота материалов).
• При необходимости установить систему «теплый пол» (тип и высота конструкции).
• Нанести стяжку над нагревательными кабелями (около 30-50 мм).
• Подготовить поверхность к укладке плитки, ламината, ковролина или другого материала (характер расположения элементов).
• Установить плинтус (указывают количество погонных метров, а также все внутренние и внешние уголки).

3. Работы с потолком:

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

4. Что требуется проделать со стенами:

• Очистить от предыдущего слоя обоев или другого покрытия (площадь).
• Отбить штукатурку.
• Заштукатурить стены (с армированием или без него). Здесь необходимо указать не только общую квадратуру стен, но и толщину слоя. Длину используемых откосов приводят в погонных метрах.
• Зашпаклевать стены.
• Указать, сколько в комнате наружных углов, чтобы можно было подсчитать длину перфорированного уголка.

5. Параметры окна:

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

6. Характеристики двери:

• Описать параметры двери, производителя, используемые материалы (в том числе и фурнитуру), тип коробки, наличников и петель.
• Отдельно прописать необходимость изменения размеров дверного проема (увеличение, уменьшение, перемещение) с размерами и перечнем работ.

7. Работы с электрическими сетями:

• Перечень работ (установка, замена,
• Необходимость прокладки телефонных или интернет-кабелей.
• Приложить схему.

8. Мероприятия по монтажу отопительных систем и кондиционеров:

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

Нужно ли обследование помещения перед составлением технического задания на ремонт

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

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

При обследовании комнаты обращают внимание на главные параметры и выполняют следующие действия:

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

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

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

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

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

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

Технический облик изделия

Теория решения изобретательских задач — это советская методика сильного мышления, получившая широкое как в России, так и в мире. Она позволяет глубоко проанализировать проблему и найти эффективное решение.
Работа над ТРИЗ была начата Генрихом Сауловичем Альшуллером и его соратниками в 1946 году.

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

В 1956 году вышла первая публикация про то, что техника развивается по определенным законам. Чтобы эффективно изобретать, нужно эти законы выявить и эффективно применять
Со временем ТРИЗ развился в большой набор инструментов, помогающие решать ряд актуальных задать:
— создавать новые прорывные продукты,
— повышать потребительские свойства имеющихся решений,
— снижать себестоимость,
— обходить патенты конкурентов.
Ведущие мировые компании, такие как Samsung, Intel, Procter&Gambel, General Electric и другие используют ТРИЗ в своих R&D центрах.

Термины

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

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

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

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

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

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

Состав типового технического задания

Давайте рассмотрим, что же включает в себя типовое ТЗ.

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

Итак, техническое задание, вне зависимости от выбранного ГОСТа, всегда включает следующие основные сведения по разрабатываемому ПО:

1) наименование – полное и краткое названия, условное обозначение разрабатываемого ПО;
2) назначение – то, для чего, в какой области и с какой целью разрабатывается ПО;
3) основание для разработки – документы, на основании которых производится разработка ПО;
4) функции – перечень и описание функций разрабатываемого ПО;
5) структура – описание архитектуры и компонентов разрабатываемого ПО;
6) пользовательский интерфейс – в современном мире обязателен;
7) надежность, безопасность, условия эксплуатации и проч. важные требования;
8) документация – какая документация, в каком объеме и в соответствии с какими требованиями ГОСТов будет также разработана;
9) стадии и этапы разработки – что и в какой последовательности разрабатывается;
10) порядок контроля и приемка – как именно будет происходить сдача разработанного ПО Заказчику.

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

Существует несколько ГОСТов, регламентирующих разработку ТЗ в нашей области: это ГОСТ 34.602 (автоматизированные системы) и ГОСТ 19.201 (программное обеспечение). Документы, выполненные по этим стандартам, значительно отличаются как по наполнению, так и по содержанию. Оба стандарта представлены на нашем корпоративном портале в разделе Библиотека, вы можете самостоятельно ознакомиться с ними более подробно.

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

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

Возможно, вас также заинтересует:

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

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

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

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

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

Структура технического задания

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

Class="fs-13">

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

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

class="fs-13">

7. Система размещения баннеров
8.

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

class="fs-13">

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

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

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

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

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

class="fs-13">

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Опыт в предметной области

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

Поиск Лекций

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

При проектировании технического объекта важное место занимает разработка технической и технологической документации: техническое задание (ТЗ) и технические условия (ТУ).

Техническое задание — это основной исходный документ для разработки продукции, содержащий технико-экономические требования к продукции, определяющие ее потребительские свойства и эффективность применения, перечень документов требующих совместного рассмотрения, порядок сдачи и приемки результатов разработки. Техническое задание на проектирование разрабатывается на основании ГОСТ 15.001-88 и оформляют в соответствии с общими требованиями к текстовым конструкторским документам по ГОСТ 2.105-68.

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

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

При разработке технического задания следует:

· установить общую цель создания технической системы;

· установить общие требования к проектируемой системе;

· определить этапы создания системы и сроки их выполнения;

· провести предварительный расчет затрат на создание системы.

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

1) наименование и область применения;

2) код изделия;

3) основания для разработки;

4) цель и технико-экономическое обоснование;

5) источники для разработки;

6) этапы разработки и запуска производства;

7) технические требования.

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

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

Основанием для разработки является маркетинговые исследования и выход нового стандарта.

В разделе «Цель и технико-экономическое обоснование разработки» указывают:

1. Конкретное функциональное назначение объекта – для снижения токсичности автомобиля.

Техническое задание на разработку программы

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

3. Предполагаемую потребность в данных объектах у потребителей – данный объект необходим потребителю для соблюдения норм стандарта и сохранения здоровья людей и окружающей среды.

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

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

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

Основные этапы разработки: маркетинговые исследование; разработка ТЗ; — проектирование объекта; испытание; подготовка производства; запуск в производство.

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

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

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

1.Технические требования

2. Требования безопасности

3. Требования охраны окружающей среды

4. Правила приемки

5. Методы контроля

6. Транспортирование и хранение

7. Указание по эксплуатации

8. Гарантии изготовителя

9. Утилизация

На основе разработанных документов можно приступать к непосредственному проектированию объекта.

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

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

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

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

Структура

Задание делится на несколько составных частей:

1. Глоссарий. В этом разделе даются определения основных понятий, которые будут использоваться в документе. Например, требуют пояснения такие термины, как шаблон раздела, HTML-теги, контент и другие;
2. Общие положения. Сторонам следует определить статус технического задания, порядок внесения в него правок и согласования отдельных положений;

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

Сайты используются для различных целей: в качестве интернет-магазина, в рекламных целях, для предоставления информации о компании и так далее. Цели, для которых создаётся сайт, также влияют на его структуру и содержание.

1. Требования к программному обеспечению. Они включают в себя серверную часть (программные условия, за которые отвечает владелец сайта) и клиентскую (браузеры, через которые заходят на электронный ресурс клиенты);
2. Технические требования. Сайт разрабатывается под конкретные аппаратные возможности вычислительной техники. Неоптимизированные страницы будут проблемно открываться на устаревших устройствах, что существенно снизит аудиторию. В задании указываются требования к процессору, оперативной памяти и так далее;
3. Типы пользователей. Сайт посещают пользователи с различными статусами: администраторы, авторизованные пользователи, неавторизованные и так далее. Для каждой из этих групп должен быть разработан собственный функционал;
4. Требования к графическому дизайну. Заказчик и исполнитель согласовывают цветовую гамму, размеры баннеров и кнопок, расположение блоков на страницах и так далее. Отдельно указываются элементы, которые не должны быть использованы в ходе создания графической составляющей (например, мелькающие баннеры);

Обратите внимание! Обязательно следует прописать порядок утверждения концепции дизайна сайта. Любые изменения в уже принятую концепцию могут вноситься только за дополнительную плату.

1. Требования к структуре сайта. Это самый объёмный раздел. В нём описывается, какие именно элементы нужны на электронном ресурсе: главная страница, личный кабинет, раздел «О компании», страницы с описаниями товаров и так далее;

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

1. Система управления сайтом. Отдельно стоит остановиться на структуре инструментов, предназначенных для добавления новых страниц, удаления и добавления новостей на сайт, внесения иных изменений. После создания сайта он будет управляться силами компании-заказчика, и интерфейс должен быть понятен её работникам;
2. Требования к контенту. Нередко заказчики желают получить полностью наполненный сайт. На страницах должны быть тематические статьи, новости по теме, информация о новинках продукции фирмы и так далее. Кроме этого, должны присутствовать графические материалы, видеоролики, баннеры;
3. Этапы выполнения работ, порядок сдачи-приёмки каждого из этапов. Весь процесс создания сайта должен быть разделён на несколько частей. Работа над каждой частью должна быть выполнена за определённый период времени и принята заказчиком.

Переделка уже принятого этапа неизбежно повлечёт за собой внесение изменений в последующие, что увеличит время работы над проектом и затраты исполнителя;

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

Как составить и образец

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

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

Использовать объективные критерии оценки

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

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

Подробно описывать все элементы сайта

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

Согласования

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

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

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

Главная » Понятия » Сделать техзадание. Структура технического задания