Что такое тз в программировании

Как составить ТЗ программисту

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

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

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

Получи грант, покрывающий 50% стоимости обучения
И обучайся новой профессии онлайн из любой точки мира
Получить грант

Как составить грамотное ТЗ

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

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

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

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

Какие советы предлагают эксперты на тему “Как составить тз для программиста”:

• Чем более сложный и требующий основательного подхода и времени проект, тем более детально следует прописать его элементы и составляющие. К примеру, ТЗ по разработке интерфейса главных страниц требует, чтобы расписали все элементы и способы их выполнения. А для создания сайта-визитки можно расписать основы, составляющие интернет-страницу.
• ТЗ для специалиста по программированию должно включать в себя задачи только для этого профиля. Не следует добавлять туда задачи, адресованные дизайнеру или другому специалисту.
• Сделайте описание отдельных задач граничными. То есть, точно обозначьте окончание пунктов одного задания и начало другого.
• Не используйте в ТЗ обобщенные и абстрактные фразы. Это вводит в заблуждение исполнителя и может быть воспринято неправильно. К примеру, фраза “удобный список функций на сайте”. Слово удобный для каждого воспринимается по-разному, конкретизируйте, что вы хотите видеть в своем проекте.
• Добавляйте в ТЗ примеры и макеты того, что должно быть в проекте. По возможности покажите исполнителю, что конкретно должно быть на сайте (платформе). Размеры, шрифты, цвета, изображения и т.д.

Правильная структура ТЗ

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

• Определитесь с целью (целями) проекта. Если у вас нет понимания, для чего разрабатывается проект и какие функции он должен выполнять, то крайне сложно будет заниматься его разработкой. Когда исполнитель видит цели работы, он лучше понимает всю суть задач и видение финального результата.
• Опишите бюджет проекта. Исполнитель, видя прописанный бюджет, может сверить все задачи и необходимые расходы. Иногда изначально запланированный бюджет может не укладываться в рамки требуемых расходов, и тогда его необходимо пересмотреть и изменить.
• Список необходимых задач. В виде пунктов и подпунктов распишите все задачи, которые необходимо выполнить в ходе работы над проектом. Разработчик таким образом видит, какую технологию лучше использовать в работе над заданием, применение какого программного кода будет актуальным. Четкое расписание по пунктам в какой-то степени дает гарантию, что все запросы заказчика будут выполнены. А если после сдачи проекта у последнего возникнут вопросы, исполнитель всегда может проверить, включены ли были эти правки изначально в ТЗ.
• Основательное описание готового продукта. Чем точнее вы опишите конечный продукт, тем большее понимание и уверенность в выполнении работ получает разработчик.
• Оценка результата проекта. Можно оценивать ход работы поэтапно, а можно это сделать после окончания работы над проектом полностью. Как происходит оценка: для этого существуют специальные программы тестирования. Финальный результат от исполнителя необходимо соотнести с теми требованиями, которые были предписаны в техническом задании. Таким образом, исполнитель может сравнить свою работу и процесс выполнения задач с требованиями, и убедиться в правильности своих действий. Заказчик сможет принять работу, оценивая ее по всем параметрам, и понять, насколько вложенные средства окупили себя.
• Сроки выполнения работ. Необходимо установить четкие сроки и дедлайны для выполнения всех задач и сдачи финального проекта. Когда заранее установлены сроки, исполнители сразу могут более точно оценить собственные возможности, необходимое количество времени и сил на работу над тем или иным пунктом. Заказчик таким образом может лучше ориентироваться в сроках выполнения работ, и это помогает составлять план всех других проектов. Зачастую работа над определенным ТЗ – это только часть одного крупного проекта или рабочего плана. И точные дедлайны выполнения позволяют установить сроки и планировать выполнение следующих задач.
• Включите в свой ТЗ возможные форс-мажоры и пути действия в таких ситуациях. Определите заранее сложности и слабые стороны вашего проекта и условий, в которых он будет создаваться.
• В пункте “Как написать ТЗ для приложения” необходимо вписать будущую работу над обслуживанием проекта. Если заказчик планирует привлекать исполнителя в дальнейшей поддержке сайта, это нужно оговорить и прописать в ТЗ.

Получите профильные знания из сферы информационных технологий на курсах DevEducation.

Техническое задание: как и зачем его писать, и почему без него не обойтись

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

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

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

Зачем писать техническое задание?

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

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

Техническое задание на проектирование устройства или написание ПО позволяет получить предварительную оценку стоимости разработки продукта

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

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

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

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

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

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

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

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

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

А можно без ТЗ?

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

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

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

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

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

Кто готовит спецификацию?

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

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

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

Что должно быть в ТЗ?

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

Термины, сокращения и определения

Использующиеся в тексте термины приводятся в начале документа. Это могут быть как IT-понятия – названия элементов, сред и языков программирования, технические определения, – так и слова и обозначения из той сферы, для которой предназначается IT-решение. Чем тщательнее будет продуман список профессиональных слов, тем лучше поймут друг друга исполнитель и заказчик.

Назначение продукта

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

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

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

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

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

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

Общие требования определяют последовательность процесса разработки.

Например, так выглядят общие требования к проекту в ТЗ на разработку ПАК для управления оборудованием.

• Разработка контроллера для управления устройствами заказчика.Контроллер должен быть установлен на каждом устройстве.
• Создание пульта управления устройствами, используя одноплатный компьютер на базе Linux.
• Разработка приложения для удаленного управления.
• Интегрирование пульта управления и контроллера в единую систему управления.
• Тестирование.
• Возможные доработки и модификации системы.

Функциональные требования касаются функций и поведения IT-решения. Пример:

1. Система должна посылать уведомления о сбое в работе оборудования.
2. Система должна контролировать датчики.
3. Система должна передавать данные по радиоканалу.
4. Система должна иметь аварийную сигнализацию.
5. Система должна управлять всеми функциями устройства.

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

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

Например, в ТЗ на разработку программно-аппаратного комплекса может быть пункт, описывающий требования к разработке устройства, протоколов связи (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-системы – предваряет написание технического задания. Это может быть краткая спецификация или большое серьезное ТЗ – все зависит от масштабности и сложности проекта. ТЗ дает представление о назначении и функциях продукта, требованиях к разработке, ходе работ и порядке приемки готового решения.

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

• подготовка технической документации
• техническое задание
• разработка электроники

• Производство и разработка электроники
• Подготовка технической документации

Как грамотно составить ТЗ программисту на доработку сайта?

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

Почему важно зафиксировать весь процесс работы в виде технической документации?

1. В ТЗ прописаны договоренности между исполнителем и заказчиком, которые сложно выразить в договоре из-за использования специфической IT-терминологии.
2. Это сэкономит время на коммуникациях: зафиксированные технические решения избавят от многочисленных пересказов, подтверждений, путаницы в показаниях.
3. Документ позволит четко разделить зоны ответственности между сторонами проекта.
4. ТЗ дает возможность проанализировать будущий проект и выявить проблемы на стадии планирования.
5. Правильно составленное задание сделает поведение всех участников работы предсказуемым и избавит от возникновения многочисленных недоразумений.
6. С юридической точки зрения, наличие этого документа облегчит сторонам разрешение спорных моментов.
7. Техзадание делает возможным финансовое планирование, что является залогом успешного бизнеса. Заказчику будет заранее видно, на что расходуются его средства.

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

Если одна из сторон хочет сотрудничать без техзадания

Это может означать следующее:

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

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

Участники проекта

Заказчик	Менеджер проекта	Разработчики
Ставит задачу	Ставит задачу разработчикам	Выполняют задание в соответствии с ТЗ
Согласовывает ТЗ	Контролирует ход работы и расставляет приоритеты
Принимает работу	Осуществляет взаимодействие с заказчиком и разработчиком
	Тестирует выполненную работу (если нет тестировщиков)

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

• Product Manager
• Руководитель проекта
• Спонсор проекта
• Тестировщики
• Технические писатели
• Кураторы
• Пользователи/потребители (например, для финального тестирования)
• И др.

Если проект маленький, то заказчик и исполнитель, как правило, работают напрямую. В этом случае тестирование берёт на себя заказчик, а разработчик сам контролирует сроки и ставит приоритеты.

Что дает сторонам каждый раздел ТЗ:

Раздел ТЗ

+ Для Заказчика

+ Для Разработчика

Осознание задач, которые решает проект или его доработка

Понимание сути задачи

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

Уверенность в правильном понимании конечного результата

Ориентирование в сроках работ и получения планируемых результатов

Оценка трудозатрат и потребности в ресурсах

Определение более-менее точной суммы затрат и планирование бюджета

Согласованный учет всех работ проекта

Подробное описание работ и каждого этапа реализации проекта

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

Оценка результата работ

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

Возможность удостовериться в бесперебойной работе проекта и в его соответствии требованиям ТЗ

Планирование затрат на обслуживание и представление о дальнейшей поддержке проекта

Выполнение работ с учетом обслуживания проекта в перспективе

Планируемые доработки проекта

Доработка в соответствии с новыми потребностями

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

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

Обычно разработке качественного ТЗ мешают следующие моменты:

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

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

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

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

Техзадание должно отвечать на вопросы:

1. Что? (какие работы, содержание элементов)
2. Где? (расположение элементов)
3. Когда? (последовательность выполнения и установленные сроки работ)
4. Как? (технология реализации, оформление, принцип работы.) Как правило, у любого объекта должны быть функции: добавления, отображения, редактирования, удаления. А также описаны зависимости и взаимодействия с другими объектами. Иногда добавляются функции модерации, валидации, автообновления, архивации и т.п.
5. Откуда? / Куда? (при переносе и т. п.)
6. Зачем? (обоснование работ, если задание будет согласовываться с 3-м лицом)
7. Особенности.

Основные рекомендации и пояснения по написанию ТЗ

1. Чем больше масштаб проекта, тем более объемным должно быть техническое задание.
2. Необходимо указывать реально осуществимые сроки выполнения работ с учетом времени на согласование проектной документации и приемо-сдаточных мероприятий. Стоит обратить внимание на ответственность заказчика за бездействие с его стороны или на форс-мажоры, тормозящие выполнение работ.
3. Программисту нужны четкие условия. Формулировки “как вариант”, “примерно”, “около”, “где-то рядом”, “там, где лучше по вашему мнению”, — неприемлемы. Требования и характеристики, которые носят субъективный характер, бессмысленны с практической и ошибочны с юридической точек зрения.
4. Чтобы сделать задачу по созданию какого-либо функционального модуля понятной для программиста, в техзадании размещают гиперссылки на те страницы, где есть нужные элементы интерфейса и функции, и дают к ним подробные пояснения. Также прилагают скриншоты с выделением интересующего фрагмента.
5. Если дизайна для страниц нет или он не так важен для заказчика, программист может использовать прототипы, о чем после согласования указывается в задании.
6. ТЗ должно быть удобным и понятным для всех сторон проекта, подробно описывать все этапы и подпункты даже по самым незначительным работам. Программист и менеджер не всегда имеют представление о том, что необходимо заказчику, поэтому важно своевременно обнаружить и согласовать все несогласованные детали.

7 типовых ошибок

1. Нечеткие цели и задачи.
2. Мало деталей в технической информации.
3. Размытые или неустановленные сроки.
4. Нет согласованности по всем вопросам между сторонами.
5. Нет регламента взаимодействия.
6. Нет ответственных лиц.
7. Нет критериев оценки результата.

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

Задача:
Разместить на сайт www.site.name.ru новую страницу, где будут размещены контакты и фотографии продавцов-консультантов, а также онлайн чат.

Описание:

1. ГДЕ? Добавить в главное верхнее меню сайта новый раздел «Ваш консультант» между разделами «Блог» и «Наши клиенты».
2. КУДА? URL новой страницы сделать: /vash_konsultant.htm
3. КАК? Макет новой страницы взять со страницы “Наши врачи”. Только вместо врачей будут консультанты.
4. ЧТО? Структура страницы следующая:
   • заголовок: Ваш консультант — по центру (в стиле других заголовков страниц сайта);
   • 3 блока в ряд, имеющие поля:
     • с фотографиями продавцов размером 400*600 (выравнивание по центру);
     • Ф.И.О. продавцов под фотографиями (текстовый формат с возможностью правки);
     • телефон общий у всех: 555-555-55 под Ф.И.О. (текстовый формат с возможностью правки);
     • электронный адрес под телефоном (e-mail: site2@mail.ru );
     • кнопка «Получить консультацию» ниже всех полей, размер кнопки, цвет и форма в стиле кнопок на сайте (см. кнопка «Сделать заказ» на url: /katalog.ru ).
5. ОТКУДА? Данные консультантов должны правиться в редакторе сайта. Также должны редактироваться теги TITLE, DESCRIPTION, H1.

Если работы выполняются для целей SEO – не забывайте закладывать все необходимые элементы на странице.

Также внизу разместить форму заказа.

1. ГДЕ? Под списком консультантов, над футером.
2. ЧТО? Три поля:
   • Имя
   • Номер телефона
   • Содержание заявки
3. КАК? Обязательные для заполнения поля: Имя и Номер телефона. Оформление сделать по образцу формы обратной связи. Если обязательное поле не заполнено, то должно выводиться сообщение, как в форме обратной связи.
4. КУДА? Заявку отправлять на email заказчика: info@common.com
5. КАК? Оформление письма в свободной форме.
6. ОСОБЕННОСТИ Защиту от ботов поставить, как на форме обратной связи.
   При отправке заявки, если все заполнено правильно, в Яндекс-метрику должно отсылаться событие “Отправка заявки”.
7. НЕ ЗАБЫТЬ О ПРАВИЛАХ ПРИЁМКИ
   Проверить:
   • На странице не должно быть незакрытых HTML-тегов.
   • Проверить адаптив на мобильных устройствах Android с разрешением ***x**** и ****x****, и планшетах с разрешением 1280×1024.
   • Проверить работу в браузерах Safari, Chrome, Mozilla.

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

Читать дальше подобные статьи

• Что такое внутренние ошибки сервера 500 Internal server error и как их исправить?
• Проверка сайта на ошибки 404. Как исправить ссылки на страницу?
• Проверить ошибки HTML кода с помощью валидатора Labrika
• Требования к CMS для SEO сайта интернет-магазина или форума

Как составить техническое задание и сэкономить 20% на стоимости проекта

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

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

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

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

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

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

• Клиент может использовать ТЗ для того, чтобы понять, за что он платит деньги, какой сайт получит в итоге. Еще до начала разработки можно увидеть структуру, понять, как элементы будут взаимосвязаны между собой. И если что-то не устраивает, изменения можно внести в ТЗ до начала разработки.
• Убедиться в том, что исполнитель имеет нужный опыт и навыки. Техзадание пишет технический писатель, проектный менеджер или тимлид, и если оно понятное, четкое, не содержит воды или двусмысленности, то это значит, что данная выбранная команда — настоящий специалист своего дела. Если же в техзадании каша из терминов и непонятных набросков, значит нужно бежать от таких исполнителей без оглядки.
• Сверить готовую работу с ТЗ. Если в переданном сайте (CRM-системе, мобильном приложении) есть очевидные несоответствия документу, разработчики обязаны внести правки бесплатно, а если они отказываются, техзадание — 100%-й вариант выигрыша дела в суде.
  Пояснение: при подписании документов о сотрудничестве к основному договору обязательно прикрепляется техническое задание, которое подписывают обе стороны. Такой документ имеет юридическую силу и может помочь вам доказать правоту при возникновении каких-либо разногласий
• Узнать реальную стоимость разработки сложного функционала. Невозможно оценить стоимость разработки сайта или приложения с большим функционалом, не видя картину целиком. ТЗ же позволяет разложить проект на отдельные модули, таким образом давая возможность оценить каждый из них отдельно. Обычно после написания проектной документации составляется бэклог — смета проекта. В этом документе указывается время на каждую из задач (отдельно оценивается клиентская часть, отдельно — серверная), которое умножается на стоимость одного часа работы программиста. Таким образом по итогу работ Заказчику предоставляется не только сам документ с техзаданием, то и детальная оценка проекта.

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

Зачем техническое задание исполнителю?

• Необходимо для того, чтобы понять, что хочет увидеть заказчик. Перед составлением ТЗ на разработку сайта специалист задает клиенту множество вопросов, показывает готовые примеры, предлагает решения. Каждый выбор, описание каждой функции и элемента записывают в единый документ, который структурируется по разделам. Если этот документ проходит согласование у клиента – значит и заказчик, и исполнитель верно поняли друг друга, и техническое задание содержит все необходимые требования.
• Застраховаться от внезапных изменений. За несколько лет работы мы сталкивались с ситуациями, когда клиент посередине процесса разработки решал внести значительные изменения в проект. Как правило, все начиналось с “а можно добавить еще одну маленькую фичу”, а заканчивалось на “а давайте из лендинга сделаем второй Amazon”. Именно в таких случаях очень выручает ТЗ, ведь все работы производятся только в соответствии с ним.
• Не менее важное назначение ТЗ — доказать экспертность. Грамотно составленное техническое задание может переубедить даже сильно сомневающегося заказчика. Часто именно на этапе составления ТЗ наши потенциальные клиенты превращались в реальных – когда заказали лишь составление технического задания для проекта, а в по итогу увидели, что мы полностью понимаем их потребности.
• Упростить и ускорить работу над проектом. Вся команда, которая работает над сайтом или приложением, опирается на ТЗ, как на основной свод законов. В качественном техзадании проработана структура будущего продукта, детально описан каждый из функциональных элементов, учтены условия интеграции со сторонними сервисами, при необходимости добавлены UML-диаграммы на основе user-stories, а также Mind Map, согласно карте сайта. Таким образом, после подготовки данного документа, команда не тратит время на выяснение нужд и требований, а достаточно быстро проектирует прототип и рисует дизайн-макет, без препятствий продвигается в написании программной части проекта. Без ТЗ же обе стороны ожидают бесконечные переговоры друг с другом, выяснения нужд и требований уже по ходу работы, что ведет к перелимитам по стоимости и срокам разработки, а также отрицательно влияет на качество написанного кода.

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

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

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

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

• используете ли Вы систему учета (например, 1С)
• какие пользовательские роли планируете добавить на сайте (клиент, менеджер, логист)
• каково Ваше УТП
• какая у вас целевая аудитория.

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

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

1. Информативность — ТЗ должно быть максимально информативным, не оставляющим места для двусмысленности
2. Понятность — каждая задача, описанная в ТЗ, выделена и визуально разграничена- то есть понятно, где закончился и где начался следующий пункт
3. Точность — в документе не должны использоваться абстрактные фразы, например, “удобная навигацию” или «красивое превью пользователя».
4. Наглядность — для достижения понимания, как будут выглядеть сложные интерфейсы, или же для наглядного пояснения сложных взаимосвязанных функций, к техзаданию могут быть прикреплены изображения, добавлены схемы, таблицы, графики и диаграммы.
5. Качество — во время написания ТЗ мы анализируем сайты с похожим функционалом, обращаемся к уже выполненным нами подобные проекты, чтобы сделать будущий продукт качественнее, нежели у конкурентов

От теории к практике: как составить ТЗ на разработку сайта

Полноценное техническое задание должно грамотно раскрывать следующие темы:

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

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

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

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

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

Для высоконагруженных сайтов и сложных систем с множеством взаимосвязей создание технического задания обычно занимает не менее одного месяца (приблизительно 160 часов рабочего времени). Объем такого ТЗ может быть 80-120 страниц, в нем очень подробно описывается весь функционал проекта, пользовательские сценарии, требования к верстке и поддержке браузерами, перечень сторонних сервисов и описание методов интеграций с ними.

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

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

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

Тип проекта	Ориентировочная стоимость проекта до ТЗ	Стоимость ТЗ (10%)
Корпоративные сайты	от $3 000	от $300
Интернет магазины	от $7 000	от $700
Системы автоматизации	от $15 000	от $1 500
Маркетплейсы	от $20 000	от $2 000

К чему приводит отсутствие ТЗ

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

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

Case Study

Мы разрабатывали CRM-систему для компании, где более 4000 клиентов, а менеджеров по работе с клиентами всего 6. Нам нужно было оптимизировать работу сотрудников так, чтобы формирование базы данных клиентов и обработке их заявок происходила в пару кликов, а в конце дня/месяца/года формировались отчеты по количествам продаж.

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

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

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

В поисках идеального ТЗ

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

Грамотное и полное ТЗ — первая ступенька к успешному проекту. Это фундамент, на котором все держится. Если вы хотите, чтобы ваш проект полностью соответствовал всем вашим ожиданиям, то можете оставить свои данные, и наш технический писатель свяжется с вами для написания ТЗ для вашего проекта.

Что такое ТЗ в IT сфере?

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

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

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

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

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

Автор: Ilya Smyrnov

Должность: CEO, Business analyst

Биография: Более 8 лет занимаюсь анализом бизнесов клиентов и повышаю их эффективность с помощью внедрения IT-решений.

Ваc может заинтересовать

Диджитализация

Фокус на бизнес-целях

Зачастую, IT подрядчик выполняет исключительно технические задачи: “скажите, что нужно сделать и мы сделаем”, совсем не понимая проблему, которую нужно решить. За 8 лет работы, мы пришли к выводу, что разработка сайта или приложения, не является конечной целью. Это лишь инструмент, помогающий решить проблему заказчика. В центре нашего подхода — цели клиента. Мы разбираемся в […]

Веб-разработка

Какие существуют виды сайтов ?

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

Веб-разработка

Этапы создания сайта

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

ОБСУДИТЬ ПРОЕКТ

Расскажите о своих бизнес-целях и наш опыт поможет их достичь!