Как составить техническое задание? Кто должен составлять техническое задание?

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

  1. Введение
  • Актуальность

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

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

  • В каких случаях необходимо качественное составление технического задания?

Основные сферы применения данного документа – это:

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

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

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

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

  • Основания для разработки. Почему мы делаем эту систему?

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

  • Назначение разработки. Кто будет пользоваться результатами разработки?

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

  •  Требования к системе. Что хотим в итоге?

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

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

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

  • Требования к безопасности работы с разработкой.

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

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

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

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

Описываем программное обеспечение, которое используем для разработки, либо то с которым взаимодействуем (например, при проектировании – AutoCAD, при работе с бухгалтерией – 1C, а при создании уникального ПО – Visual Studio. Я перечислил частные примеры.). Вашей задачей является написать про то, что поможет вам добиться того результата, который требуется (имеется ввиду в техническом плане). Если в предыдущем разделе мы рассматривали аппаратный план, то здесь больше идет акцент на программный план (например, версия программы, тип лицензии, список дополнений, язык программирования и т.д.). Этот раздел дает больше ориентации специалисту на саму разработку и то какой она должна быть. Пункт совместимости ПО важен также и для заказчика. Ведь если лицензии к продуктам нужно будет приобретать, то об этом сразу стоит заявить.

  • Требования к маркировке и упаковке

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

  • Требования к транспортированию и хранению.

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

  • Специальные требования

В предыдущем разделе я коротко упомянул о легко зажигательной смеси. Но это могут быть и яды, и биоматериалы и все что угодно. Если наша программа (или разработка) работает с этим, то следует заявить об этом в разделе «Специальные требования». Это поможет специалисту лучше подготовиться к работе и позволит лучше понимать тот «объект», с которым он работает. Если есть еще какие-либо замечания касательно разработки то, в целом, они здесь могут быть указаны. В иных случаях, если такие требования не ставятся, пишем, что специальных требований к разработке не ставится.

  •  Требования к программной документации (отвечаем на вопрос что входит в состав продукта, основные моменты по продукту)

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

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

  •  Технико-экономические показатели

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

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

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

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

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

  •  Перечень принятых сокращений

Например, при написании этого технического задания часто используется слово «продукт». Что оно означает?

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

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

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

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

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

  • Основная суть технического задания.

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

  • Окончательные выводы по созданию технического задания для проекта.
  • Техническое задание – незаменимый для руководителя инструмент ведения бизнеса в 21 веке и правильный способ оценки труда специалистом, предполагающий ее денежную составляющую. К счастью современные инструменты способны уладить работу этих двух субъектов при помощи единой площадки и единого документа.
  •  Составление технической документации важно не только руководителю (заказчику) но и исполнителю (специалисту, работнику), так как позволяет предотвратить конфликты между сторонами и показывает кто из них прав.
  • Техническое задание имеет ряд составляющих, каждая из которых должна быть описана и учтена.
  • Часть заказчиков и работников относятся к техническому заданию как к «небольшой писульке», заполнение которой возможно в общих чертах. Это приводит к проблемам в бизнесе для руководителя и сложностью понимания задачи сотрудником (работником).
  • Исходя из вышесказанного необходимо правильно составлять техническое задание. Нужно понимать, что вы решаете общую задачу и попытаться найти общее решение в техническом задании.
  • Суть технического задания – нахождение точек связи между заказчиком и исполнителем.