Техническое задание: как и зачем его писать, и почему без него не обойтись
Все удачные IT-продукты были когда-то просто идеями. И очень часто (почти всегда) идеи принадлежат людям, далеким от разработки программного и аппаратного обеспечения.
Они хотят что-то улучшить в своем бизнесе, в том направлении деятельности, которое знают досконально. Идеи, мысли, мечты — это прекрасно, но важно, чтобы специалист верно их понял и воплотил в работающее устройство или программу.
Правильно довести идею до разработки поможет техническое задание. Зачем готовить ТЗ, кто и как должен это делать, можно ли обойтись без ТЗ и как минимизировать расходы — обо всем этом вы узнаете из данной статьи.
Зачем писать техническое задание?
Техническое задание на разработку прибора или программного обеспечения — это документ, определяющий требования к IT-продукту, включая его назначение, функции, поведение, используемые компоненты, технологии, инструменты разработки, а также порядок выполнения работ. ТЗ служит руководством для бизнес- и технических групп, занимающихся созданием IT-решения.
Техническое задание в равной степени нужно и заказчику, и разработчику. Спецификация является трудом специалистов из разных областей и используется клиентом и исполнителем на протяжении всего периода разработки и после окончания проекта.
Техническое задание на проектирование устройства или написание ПО позволяет получить предварительную оценку стоимости разработки продукта
Стоимость сложного устройства или приложения невозможно оценить навскидку. Необходимо учесть множество моментов — затраты труда специалистов, стоимость компонентов и логистики, работы, связанные с сертификацией и т.д. Грамотно составленный документ позволяет и исполнителю, и заказчику видеть и оценивать как процесс разработки целиком, так и отдельные его ступени. Таким образом, заказчик получит представление о предварительной стоимости каждого этапа работ. Более точные данные будут даны в смете проекта.
В ТЗ очерчиваются примерные сроки исполнения заказа. У клиента и аутсорсинговой компании не будет разногласий по поводу тайминга, если с самого начала в документе обозначены временные отрезки для каждого этапа проекта.
Сроки выполнения работ по проектированию электроники и созданию программного обеспечения могут сдвигаться по разным причинам. Некоторые из них — например, время ожидания компонентов и сроки доставки — можно предусмотреть уже на этапе написания ТЗ.
Заказчику будет проще оценить готовое решение — электронное устройство, программное обеспечение или программно-аппаратную систему, — сверив его с описанием в техническом задании. Именно поэтому ТЗ должно быть составлено грамотно и максимально подробно.
Качественно написанное техническое задание на разработку прибора или ПО может свидетельствовать о компетенции и опыте специалистов. Вдумчивый подход разработчиков к подготовке проекта, понятная и исчерпывающая информация в ТЗ говорят об общем уровне сервиса компании.
Совместная работа может быть прервана или заморожена по тем или иным обстоятельствам — из-за финансовых и правовых сложностей, геополитической обстановки, разногласий сторон, серьезных логистических проблем и т.п.
С хорошо составленным техническим заданием на разработку IT-продукта заказчику проще вернуться к сотрудничеству с аутсорсинговой компанией либо найти нового подрядчика.
В ТЗ описывается сам продукт, его назначение и функциональность, а также этапы разработки, основные элементы электроники и инструменты для создания ПО. Таким образом, и заказчик, и разработчик имеют полное представление о проектируемом IT-решении, что служит страховкой от разногласий, недопониманий, внесений незапланированных изменений в концепцию продукта.
Работа над проектом идет быстрее и проще, когда команда разработчиков опирается на ТЗ. Нет необходимости согласовывать каждый шаг, теряя время.
А можно без ТЗ?
Написание ТЗ — процесс непростой, требующий высокой квалификации и, конечно, стоящий денег. Стремясь сократить стоимость проекта, заказчик может решить написать ТЗ своими силами или вовсе отказаться от написания документа. Можно ли обойтись без ТЗ — объяснить на словах, показать образец устройства, платы или приложения, попросить сделать по шаблону?
Любой, даже совсем небольшой типовой проект требует оформления спецификации — документа, где будут зафиксированы требования к разрабатываемому решению, порядок работ, используемые компоненты и т.д. Это не будет ТЗ в классическом виде, но совсем без спецификации не обойтись.
Клиент может предоставить документ, в котором в произвольной форме изложены его идеи, пожелания, видение продукта. Компетентность клиента в вопросах проектирования и программирования будет большим плюсом, но главное — четко и понятно сформулировать свои пожелания к продукту. На основе такого объяснения компания-разработчик создаст полноценное качественное ТЗ, которое будет служить ориентиром в последующей разработке.
Как написать техническое задание
Техническая спецификация содержит много предметных данных и детальное описание процесса разработки. Чем сложнее задача, тем больше специалистов будет вовлечено в написание ТЗ и тем больше информации будет в готовом документе.
Кто готовит спецификацию?
Невозможно создать хорошее ТЗ по шаблонам и советам из Интернета.
Разработкой технического задания на проектирование устройства или создание программного обеспечения занимаются специалисты, знающие все нюансы разработки и того, как будет выполнен проект — этапы работ, сроки, компоненты и конечный продукт. Это ПМы, разработчики, тестировщики. Каждый из них вносит в ТЗ свою информацию, выстраивая общую картину проекта.
Можно доверить написание технического задания специалистам из штата своей компании, которые знают, какой продукт им нужен, и могут подробно указать в документе желаемые функции и характеристики устройства или программы. Но зачастую такая экономия оборачивается двойной работой, потерей времени и денег.
Техническое задание, созданное компанией-разработчиком, будет учитывать не только все пожелания клиента, но и возможности подрядчика (экспертизу в разработке, опыт работы с компонентами, используемые инструменты и языки программирования и т.д.). Все пункты ТЗ будут оговорены сторонами и одобрены заказчиком, чтобы по итогу сотрудничества клиент получил удовлетворяющий всем требованиям продукт.
Что должно быть в ТЗ?
Технические задания разрабатываются под конкретный проект и, как правило, уникальны. Тем не менее есть пункты, которые в том или ином виде присутствуют во всех технических заданиях на разработку ПО, электроники и программно-аппаратных систем.
Термины, сокращения и определения
Использующиеся в тексте термины приводятся в начале документа. Это могут быть как IT-понятия — названия элементов, сред и языков программирования, технические определения, — так и слова и обозначения из той сферы, для которой предназначается IT-решение. Чем тщательнее будет продуман список профессиональных слов, тем лучше поймут друг друга исполнитель и заказчик.
Пример таблицы терминов в техническом задании.
Назначение продукта
В этом блоке расписываются назначение IT-решения, цели его создания и целевая аудитория.
К основным целям могут относиться увеличение клиентской базы, положительный имидж компании, увеличение производительности труда, уменьшение ручных операций и т.д.
Пункт также содержит информацию о задачах проекта — это может быть разработка с нуля и под ключ, участие в отдельном этапе создания (например, работа над программным обеспечением для готовой аппаратной части) или усовершенствование существующего продукта.
Цели должны быть конкретными и понятными, чтобы конечный продукт максимально соответствовал требованиям и был полезен заказчику.
Требования к проекту
Требования к проекту — основа спецификации, его самая весомая и развернутая часть. Как правило, блок требований содержит следующие подразделы:
Общие требования определяют последовательность процесса разработки.
Например, так выглядят общие требования к проекту в ТЗ на разработку ПАК для управления оборудованием.
Этапы проекта:
Разработка контроллера для управления устройствами заказчика.Контроллер должен быть установлен на каждом устройстве.
Создание пульта управления устройствами, используя одноплатный компьютер на базе Linux.
Разработка приложения для удаленного управления.
Интегрирование пульта управления и контроллера в единую систему управления.
Тестирование.
Возможные доработки и модификации системы.
Функциональные требования касаются функций и поведения IT-решения. Пример:
Система должна посылать уведомления о сбое в работе оборудования.
Система должна контролировать датчики.
Система должна передавать данные по радиоканалу.
Система должна иметь аварийную сигнализацию.
Система должна управлять всеми функциями устройства.
Нефункциональные требования определяют такие критерии, как производительность, масштабируемость, ремонтопригодность, безопасность продукта и многое другое.
Требования к разработке могут быть представлены несколькими пунктами, где подробно описываются этапы работ и используемые компоненты и инструменты.
Например, в ТЗ на разработку программно-аппаратного комплекса может быть пункт, описывающий требования к разработке устройства, протоколов связи (MQTT, TCP и т.п.), пользовательского приложения для управления устройством.
Требования к организации и качеству работ определяют то, как будет организована работа над проектом, коммуникация между заказчиком и исполнителем, а также основные моменты, касающиеся качества системы, устройства или программного продукта — время непрерывной работы, поведение системы в аварийной ситуации и пр.
Требования к безопасности могут содержать требования о защите кода, разграничении доступа, прав и т.д.
Помимо основных пунктов, ТЗ содержит индивидуальные для конкретного проекта блоки, например, описание ролей для разграничения доступа, требования к интерфейсу, требования к размеру и внешнему виду устройства.
Что такое хорошее ТЗ?
Каким должно быть качественное техническое задание на разработку устройства и ПО: на одну страницу или на пятьдесят, написанное шаблонными фразами или с использованием технического сленга, с картинками или без?
Прежде всего, ТЗ должно быть написано простым и понятным языком, ведь его будут изучать не только технические специалисты, но и менеджеры отдела продаж, и команда заказчика. Конечно, без технических терминов не обойтись, но не стоит перегружать ими текст. Схемы, рисунки, таблицы не обязательны, но очень желательны. Графические элементы доносят информацию в наглядной и понятной форме.
Размер ТЗ зависит от масштаба и сложности проекта. Чем больше проект, тем больше подготовительных документов. Техническое задание на разработку системы управления аккумуляторами, работа над которой продлится не один год, не может быть одностраничным документом. Но и для масштабных проектов в написании ТЗ нужно стремиться к балансу краткости, понятности и информативности.
Чем может обернуться несерьезный подход к составлению и изучению спецификации? Как минимум — дополнительными затратами времени, как максимум — разногласиями сторон и получением продукта, который не отвечает требованиям заказчика. Чтобы избежать таких моментов, заказчик также должен уделить ТЗ время — принять участие в обсуждении спецификации и вникнуть в готовый документ.
Работу по написанию технического задания лучше доверить профессионалам — тем, кто будет разрабатывать IT-решение. К ним можно прийти с идеей, даже не имея представления, как ее воплотить. Хорошее ТЗ сбережет время, деньги и нервы как клиенту, так и разработчику.
Ошибки при составлении спецификации
При составлении технического задания важно избегать распространенных ошибок. Приведем некоторые из них.
Отсутствие словаря терминов
В спецификации от заказчика: Виртуальный помощник обеспечивает голосовое взаимодействие, воспроизведение Mx player, Spotify, TuneIn, Audible, Pandora, Hungama, Ganna, предоставляет информацию о EPL, MLB, NBA, NHL и т.д.
Как должно быть: Виртуальный помощник обеспечивает голосовое взаимодействие, воспроизведение музыки (Mx player, Spotify, TuneIn, Audible, Pandora, Hungama, Ganna), предоставляет информацию о спортивных событиях (EPL, MLB, NBA, NHL и т.д).
Музыкальные сервисы: Mx player, Spotify, TuneIn, Audible, Pandora, Hungama, Ganna.
Аббревиатуры спортивных объединений:
EPL — English Premier League
MLB — Major League Baseball
NBA — National Basketball Association
NHL — National Hockey League
Расплывчатые и непонятные формулировки
В спецификации от заказчика: Представленный в 1983 году, MIDI является стандартом для многих существующих продуктов и приложений. MIDI определяет не только протокол для обмена музыкальными данными, но и аппаратное соединение, используемое для физического обмена данными. Передача MIDI-данных через другое соединение, такое как USB, будет называться USB-MIDI.
Как должно быть: Формат MIDI (Music Instrument Digital Interface) позволяет стандартизировать музыкальное оборудование различных производителей.
Протокол обеспечивает передачу данных в цифровом формате между устройствами, позволяет воспроизводить музыку и управлять работой вспомогательного оборудования (пиротехнического, осветительного и т.д.).
Перегруженное деталями описание
В спецификации от заказчика: Формат GS — это набор рекомендаций, созданных Roland для стандартизации характеристик звуковоспроизводящего оборудования. Он поддерживает все функции, перечисленные в General MIDI System. Кроме того, хорошо совместимый формат GS обеспечивает большее разнообразие звуков, позволяет редактировать звук и задает многочисленные особенности для широкого спектра дополнительных функций, таких как эффекты хоруса и реверберации.
Формат GS был создан с расчетом на будущее, что упрощает добавление дополнительных звуков и поддержку новых аппаратных функций по мере их появления. Его можно модифицировать для работы с системой General MIDI. В результате формат GS компании Roland может достоверно воспроизводить партитуры General MIDI так же, как и музыкальные данные GS (музыкальные данные, записанные в формате GS).
Как должно быть: Формат Roland GS является расширением стандарта General MIDI для унификации характеристик звукового оборудования.
Поддерживая все функции, перечисленные в General MIDI System, стандарт дополнен новыми инструментами, эффектами и функциями.
Путаница в функциональных и нефункциональных требованиях
В спецификации от заказчика: Система должна поддерживать температуру воды в нагревательной емкости не выше 50°С.
Как должно быть: Функциональные требования: Система должна поддерживать устанавливаемую пользователем температуру воды. Нефункциональные требования: Температура воды в нагревательном оборудовании не должна превышать 50°С.
Заключение
Разработку IT-решения — электронного прибора, приложения, встроенного программного обеспечения или IoT-системы — предваряет написание технического задания. Это может быть краткая спецификация или большое серьезное ТЗ — все зависит от масштабности и сложности проекта. ТЗ дает представление о назначении и функциях продукта, требованиях к разработке, ходе работ и порядке приемки готового решения.
Техническая спецификация — результат коллективного труда менеджера проекта, разработчиков, тестировщиков и, конечно, заказчика. Написание ТЗ — сложный процесс, который требует от разработчиков иметь знания и экспертизу в разработке программных и аппаратных решений, разбираться в рынке электронных компонентов, оценивать логистические маршруты, а также понятно излагать информацию. Лучше, если ТЗ напишет компания-разработчик, учтя все требования заказчика и свою экспертизу. Тогда разработка продукта будет идти быстрее и комфортнее и для исполнителя, и для заказчика.
