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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проблема

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Управление проектами
• Agile
• Управление продуктом

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

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

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

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

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

Техническое задание: для чего нужно и как составить

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

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

Возьмём к примеру работу со стартапами. Клиент приходит с идеей и не знает, как её реализовать технически. Разработка стартапа начинается с MVP (минимально жизнеспособного продукта), потому что неизвестно, «взлетит» он или нет. Ещё одна особенность стартапа — изменчивость. Цифровое решение может не раз меняться на ходу, поэтому техзадание может стать неактуальным. Таким проектам на помощь приходит Product Vision — описали видение проекта и начали разрабатывать, тестировать, получать обратную связь и поэтапно развивать продукт.

В чём польза ТЗ для заказчика

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

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

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

Определение компетентности подрядчиков. Если клиент видит понятное и структурированное техническое задание, то с подрядчиком можно продолжить сотрудничество. Если видит неразбериху и не понимает, что в документе описано, то это заставляет задуматься о надёжности компании-разработчика. Через техзадание можно «прощупать» подрядчика и оценить его компетентность.

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

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

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

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

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

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

А что если использовать готовый шаблон из Интернета

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

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

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

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

На что обратить внимание при приёме ТЗ

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

Однозначные формулировки

Формулировку «Сделать красивый сайт» исполнитель и заказчик могут понять по-разному. Чтобы не было разночтений, лучше избегать прилагательных «красивый», «хороший», «качественный», «быстрый» и абстрактных примеров «Сайт должен загружаться быстро». Быстро — это как? Такие предложения каждый человек может трактовать по-своему. Чем точнее описано техзадание, тем лучше получится результат.

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

Глоссарий

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

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

Примеры

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

Что должно быть в техзадании

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

Компания и цель создания сайта

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

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

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

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

Может показаться излишним указывать, что сайт должен быть адаптивным, то есть работать в любых браузерах (Google Chrome, Yandex, Opera и т. д.) и на разных видах устройств (компьютеры, ноутбуки, телефоны, планшеты). Но лучше перестраховаться и описать всё. Техническое задание — это документ, по которому вы будете принимать работу.

Структура сайта

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

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

Пользовательские сценарии

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

Для описания сценариев IT-продуктов используют следующий шаблон: действие пользователя — ответ сайта.

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

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

Контент

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

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

Дизайн

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

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

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

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

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

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

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

Техническое задание для тендеров

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

Закон 44-ФЗ не регламентирует, что должно содержаться в техзадании, но оно должно давать чёткое понимание о задачах заказчика. Поэтому важно описать в ТЗ следующие пункты:
• цель и задача проекта;
• показатели, которые необходимо достичь за счёт разрабатываемого продукта или услуги;
• требования к оптимизации, продвижению и наполнению продукта контентом;
• требования к техническим характеристикам продукта;
• функциональные и нефункциональные требования в зависимости от того, какая потребность стоит на повестке;
• требования или предпочтения к технологическому стеку разработки проекта;
• сроки оказания услуги;
• условия гарантийного обслуживания;
• требования к необходимой технической документации при сдаче товара/работ/услуг;
• другие необходимые требования, которые не противоречат закону 44-ФЗ.

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

Вместо заключения

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

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

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