Как составить тз на разработку программы

11 Сен 2015

О технических заданиях, об их важности и о правильном составлении приходится слышать постоянно. Техническое задание на создание сайтов, техническое задание на дизайн-проекты, техническое задание на разработку программ, техническое задание на то, техническое задание на это… Так ли важно это самое, техническое задание, панибратски именуемое, ТЗ? А давайте разберемся!

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

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

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

Как системному аналитику ставить задачи на разработку

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

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

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

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

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

Для кого техническое задание?

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

051. Что нужно сделать, прежде чем садиться за ТЗ – Алексей Бородкин

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

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

1. Организация
2. Информация
3. Коммуникация
4. Юрисдикция.

Организация должна быть направлена на сам процесс, иначе говоря, упорядочить творчество и созидание программы, или программного комплекса. Строго, структура технического задания на разработку программ должна быть четкой и в тоже время лаконичной. Поскольку читать 120-150, а то и более, страниц неудобоваримого технического текста, творческая личность программиста попросту не сможет. А значит, краткость – сестра таланта.

Информационная составляющая ТЗ должна быть полной, но сжатой.

И опять же простое правило, «необходимо и достаточно». Его, как водится, нужно придерживаться всегда и везде, но при составлении технического задания по разработке программ, это правило становится номер один. Грамотное техническое задание – первый и последний документ, который расскажет обо всех желаниях заказчика в удобной для понимания программиста форме.

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

С коммуникациями несколько сложнее. Почему? Да потому что коммуникации, да ещё и в процессе относительно творческом, сложны всегда. Особенно, если говорить на разных языках. А языков тут может быть несколько, более точно – по числу участников проекта под кодовым названием «разработка программ».

1. Клиент, он же Заказчик
2. Менеджер проекта
3. Исполнители проекта, они или он: программист(ы)
4. Другие возможные участники, имеющие мнение: как сделать, как сделать лучше, и чем всё должно закончиться.

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

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

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

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

Об этом позаботились ещё в стародавние времена СССР, разработав целую концепцию стандартов, называемых ГОСТами. Удивительно, но разработка программ, этими стандартами также предусмотрена, что согласитесь, не может не радовать.

Разработка программ и составление технического задания по этому направлению регламентируется ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению.

Также не лишними будут ещё два руководства:

1. ГОСТ 2.114-95 Единая система конструкторской документации. Технические условия;
2. ГОСТ 34.602-89 информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы. Эту троицу, несомненно, можно считать «святая святых» при разработке и составлении технического задания практически любой предметной области. Есть, конечно, и другие стандарты, руководствоваться которыми можно и нужно, но вспомним о «необходимом и достаточном».

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

Что мы имеем в итоге?

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

1. Что нужно сделать в рамках проекта;
2. Зачем это нужно, и для каких конкретно целей;
3. Где будет использоваться результат проекта (читай, разработка программ), в какой сфере деятельности, и на каком уровне;
4. Какие требования должна удовлетворять разработка программ;
5. Что нужно сделать в процессе работы над проектом;
6. Как будет оцениваться результат со стороны Заказчика;
7. Какими документами устанавливается порядок взаимодействия по проекту;
8. На чем основана инициация работы над проектом по разработке программ.

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

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

1. к набору выполняемых программой функций;
2. по организации входных и выходных данных;
3. к быстродействию;
4. к надежности функционирования;
5. к длительности восстановления при отказах;
6. по отказам в связи с некорректными действиями пользователя;
7. к видам обслуживания;
8. к числу и квалификации персонала, взаимодействующего с программой;
9. к параметрам технических средств, на которых будет обеспечиваться нормальная работоспособность программы;
10. к исходным языкам и кодам программирования, информационным структурам и сторонним программным средствам;
11. по защите и информационной безопасности;
12. к маркировке и упаковке;
13. к условиям транспортировки и хранения.

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

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

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

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

1. Постановка задачи проекта;
2. Формирование и конкретизация требований к технической реализации;
3. Формулировка требований к разрабатываемой программе;
4. Согласование этапов, их длительности, и составление документации;
5. Указание языков и кодов программирования;
6. Составление, корректировка и утверждение у Заказчика технического задания.

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

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

Источник: it-konsultant.ru

Составляем понятное ТЗ для разработчика и заказчика

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

Изучить аудиторию

• Для кого пишется документ? Кто его целевая аудитория (ЦА)? — Чаще всего это бизнес-заказчики, разработчики и тестировщики.
• Какой уровень подготовки у читателей? Насколько хорошо они знают предметную область? Насколько технически подкован бизнес-заказчик? — Тут всё зависит от само́й аудитории.
• Что хочет получить целевая аудитория от документа? — Заказчики хотят увидеть, что их требования учтены и как планируется их реализовать. Разработчики и тестировщики — понять, что делать.
• Что оценивает ЦА при согласовании документа? — Разработчики оценивают в ТЗ, насколько требования понятны и реализуемы; тестировщики — полноту описания для создания тест-кейсов; заказчик — полноту фиксации бизнес-требований и их реализации.

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

Собрать вводные от заказчика

На встрече с клиентом аналитик собирает информацию:

• Какими заказчик видит цели и задачи у проекта? Кто его целевая аудитория (пользователи)?
• На что в бизнесе заказчика повлияет достижение этих целей и выполнение задач?
• Делал ли уже заказчик что-то для закрытия этих потребностей бизнеса?
• Какой он видит реализацию проекта?

Как провести встречу

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

«Дизайн на салфетке»

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

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

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

Как написать ТЗ для разработчика и заказчика

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

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

Если же продукта ещё нет, то он пишет для разработчика и тестировщика полное ТЗ на информационную систему, в котором описывает:

• общую информацию о ИС;
• предполагаемый технологический стек, на котором будет реализована система или ссылку на архитектурное решение, где это определяется;
• описание выполняемых бизнес-процессов;
• описание интерфейсов (пользовательских и интеграционных) и алгоритмов обработки объектов/данных, используемые справочники и формы отчётов;
• роли пользователей и доступные им функции, статусные модели объектов учёта.

Независимо от того, какое ТЗ вам нужно написать: полное или локальное, — при изложении информации нужно придерживаться трёх важных принципов. Расскажу о них в привязке к полному ТЗ на информационную систему.

Принцип 1. Структурированность информации

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

Структуру ТЗ на можно разделить на 2 части:

• организационную;
• основную (тело ТЗ).

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

В организационную часть входят:

• Титульный лист — наименование компании, кем утверждается документ (опционально), наименование документа, год создания документа.
• Оглавление — маршрутизация по документу. В Word есть удобный функционал для вставки и обновления Оглавления, используйте его.
• История изменений — нужный раздел ТЗ, который покажет разработчику и заказчику историю внесения изменений в документ. Например:

• Глоссарий — список сокращений и профессиональных терминов, которые используются в компании и документе — с пояснениями или ссылками на определения.

К основной части обычно относят:

• блок общей информации о ИС;
• детальное описание функциональных требований;
• нефункциональные требования.

Принцип 2. От общего к частному

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

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

Помните, Техническое задание не художественный роман, и начинать документ с описания маленькой экранной формы (ЭФ) — плохая попытка заинтриговать читателей.

Как работает принцип «от общего к частному» покажу на примере расширенной структуры ТЗ.

В Блоке общей информации о ИС описывается:

• общая информация (цель создания ИС, её основное назначение и процессы какой предметной области должны быть реализованы в ИС);
• предполагаемый технологический стек, на котором будет реализована система или ссылка на архитектурное решение, где это определяется;
• перечисление выполняемых в ИС процессов/крупных функций;
• перечисление функциональных модулей ИС;
• интеграция — принципы интеграции; дополнительно опционально можно перечислить ИС, с которыми требуется интеграция.

Информация в данном блоке излагается крупно, ёмко, без деталей. Разделите Блок на подразделы. Как правило, Блок общей информации занимает в ТЗ не более 1,5–2 страниц.

Детальное описание функциональных требований

Это самый объёмный раздел ТЗ. По сути, его структура уже заложена списками бизнес-процессов/крупных функций и функциональных модулей, но теперь она расширяется и детализируется:

• Справочники — здесь описываются принципы использования справочников и списков, даётся список, справочников используемых в ИС. На этом уровне их можно разделить на группы: например, внутренние (ведётся в ИС, импортируется) и внешние. Описание каждого справочника, кроме наименования включает в себя: наименования атрибутов, коды атрибутов, их связь с другими справочниками.
• Роли — описываются ролевая модель: роли, функционал, кем и как администрируется.
• Функциональные модули — описываются принципы функционирования по каждому модулю из перечисленных в разделе «Блок общей информации —> Функциональные модули».
• Принципы построения интерфейсов ИС — описываются главное меню, если оно используется в системе. Также можно описать стандартные элементы экранных форм ввода и поиска.
• Список электронных сообщений, которыми система обменивается с другими системами. Раздел опциональный, информацию удобно оформлять в таблице — с явным указанием признака «входящее сообщение/исходящее сообщение».
• Реализуемые процессы — описываются алгоритмы выполнения каждого процесса в ИС из перечисленных в разделе «Блок общей информации —> Процессы». Описание процессов лучше всего располагать в логической последовательности.

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

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

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

Минимальное описание ЭФ включает

• Наименование поля на ЭФ.
• Тип и длина данных (на ЭФ и в базе данных, если отличаются).
• Обязательность (используют три варианта: О — обязательное, Н — необязательное, УО — условно/обязательное). Для УО в обязательном порядке прописать условие, при котором поле становится обязательным.
• Способ заполнения поля:

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

Описание экранных форм (ЭФ) удобно давать в табличной форме.

Требования к печатным формам должны содержать

• шаблон печатной формы (со статической частью и динамической частью с маппингом на данные);
• алгоритм и режим формирования отчёта.

Требования к реализации ЭФ и ПФ можно оставить по тексту описания процессов. Но если таких описаний много и/или они объёмные, то лучше их вынести в отдельный раздел или приложение. А при описании давать гиперссылки на описание конкретных форм приложения.

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

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

Принцип 3. Убрать информационный шум

Информационный шум — это элементы, усложняющие понимание текста, искажающие его смысл — или вовсе препятствующие адекватному пониманию содержания.

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

• В ТЗ не должно быть несогласованных предложений, бесконечных причастных и деепричастных оборотов, лексических и орфографических ошибок. Перечитывайте написанное перед отправкой документа на согласование. Хорошо, если дополнительно это будут делать коллеги, у которых не замылен глаз.
• Единое форматирование текста в документе и его приложениях обязательно. Разные шрифты, внезапный капслок или курсив, разные отступы и выравнивание абзацев, необоснованное цветовое выделение текста, отсутствие единого оформления заголовков и таблиц — всё это создаёт сильный информационный шум.
• Технические правки в документе, визуализируемые редактором в режиме рецензирования (например, форматирование, обновление ссылок или нумерации), нужно принимать перед отправкой на согласование документа.
• Описания однотипных объектов (например, справочников, ЭФ и ПФ) должны быть одинаковыми по форме и по составу данных. Массивные описания ЭФ и ПФ могут стать информационным шумом для описания реализуемого процесса. Решение одно — группируем и выносим в отдельный раздел или приложение.

Дополнительные артефакты ТЗ

Если разрабатываемая система будет обеспечивать выполнение STP-процессов с использованием электронного документооборота с внешними контрагентами удобно приложить DocFlow обмена электронными сообщениями:

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

В некоторых ТЗ рисуют user story. Это помогает описать клиентский путь, адекватно спроектировать действия пользователя в системе и сделать user friendly интерфейс. С user story проще согласовывать ТЗ с заказчиком и делать тест-кейсы.

Полезно будет привести для разработчика в ТЗ диаграммы статусов пользователя и/или объекта учёта:

Что ещё важно

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

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

Источник: tproger.ru

Как писать ТЗ: инструкция по составлению грамотного техзадания

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

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

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

Для чего нужно техническое задание?

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

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

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

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

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

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

Заказчик

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

Исполнитель

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

Совместно

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

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

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

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

ГОСТ

ГОСТ 19 был введён в 1980 году. Учитывая, что основные принципы программного обеспечения почти не поменялись, документ еще не утратил своей актуальности. Это можно сравнить со строительством зданий: меняются материалы и конструкции, но общие понятия — фундамент, стены, перекрытия — сохраняются. Согласно тексту Постановления, согласно которому принят данный стандарт, назначение его следующее: «Устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения». Само техническое задание должно содержать следующие пункты:

• Введение;
• Основания для разработки;
• Назначение разработки;
• Требования к программе или программному изделию;
• Требования к программной документации;
• Технико-экономические показатели;
• Стадии и этапы разработки;
• Порядок контроля и приемки;
• Приложения.

Более новый стандарт — ГОСТ 34, но он новее всего на 10 лет. То есть, введён с 1 января 1990 года.

Формулировка назначения выглядит так: «Распространяется на автоматизированные системы (АС) для автоматизации различных видов деятельности (управление, проектирование, исследование и т. п.), включая их сочетания…».

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

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

ISO/IEC/IEEE 29148

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

Последняя редакция — ISO/IEC/IEEE 29148:2018, но, к сожалению, она отсутствует в открытом доступе, поэтому возьмём за основу предыдущую, от 2011 года.

По аналогии с ГОСТами, стандарт содержит два раздела. Один из них, SyRS — System Requirements Specification — определяет общие требования к построению систем, их принципам и характеру взаимодействия пользователя с ними. По похожей схеме составлен ГОСТ 34.

SRS — Software Requirements Specifitaion — по аналогии с ГОСТ 19, содержит требования к конечному программному продукту.

Общая схема строится следующим образом:

Маркетинг

Как разработать контент-стратегию

Как разработать контент-стратегию

Порядок документирования требований

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

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

Бриф

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

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

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

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

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

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

Виджет обратного звонка для сайта

• Повысьте конверсию сайта на 30%
• Новым клиентам 50 минут в подарок

Технико-коммерческое предложение

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

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

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

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

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

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

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

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

Технический проект

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

В соответствии с практическими наработками, составляются новые задания и требования — частные технические задания по отдельным подсистемам (ЧТЗ).

Бесплатно Электронная книга
23 действующих способа сделать свой маркетинг круче, быстрее, эффективнее, чем сейчас

Эксплуатация

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

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

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

Рекомендации по составлению ТЗ

Правильное ТЗ составляют по универсальному шаблону:

Дайте подрядчику общую информацию

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

Покажите конкурентов

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

Распишите сценарии использования продукта

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

Ведите историю правок

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

Составляйте список терминов и сокращений

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

Прописывайте каждую деталь

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

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

Продумывайте детали

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

Как он появляется опять? Малейшая деталь без чёткой логики ставит разработчиков и весь процесс в тупик.

Опишите требования к проверке проекта

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

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

Сквозная аналитика Calltouch

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

Источник: www.calltouch.ru