что должно быть в ТЗ для разработчика

23.10.2022

Валерия Г. Мария Простова

Время чтения:

3

мин.

В этой статье:

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

Что предшествует составлению ТЗ на разработку

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

Что должно быть в ТЗ для разработки IT-продукта

Информация о разрабатываемом IT-продукте

Глоссарий

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

Спецификация на интерфейс

Пользовательские сценарии (use case)

Пользовательская и техническая документация

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

Согласование ТЗ

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

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

Эта статья будет полезна вам, если:

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

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

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

Что предшествует составлению ТЗ на разработку

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

На этом остановимся подробнее:

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

Например, бизнес-требованием можно назвать:

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

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

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

• Организовать сортировку результатов поиска по релевантности. Первыми должны идти те товары, у которых все слова поискового запроса находятся в одной строке. Далее идут товары у которых все слова встречаются в разных свойствах (при этом учитывается «вес свойства» см. ниже). Далее идут товары у которых встречается меньшее количество слов из поискового запроса
• Сделать возможность поиска по свойствам: бренд, суббренд, вид товара, название производителя, страна производитель
• Организовать сортировку результатов поиска в соответствии с «весом» свойства (название, бренд, суббренд, вид товара, состав, название производителя, страна производитель)

Обязательные составляющие тех.

задания на разработку

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

Например:

• ГОСТ 34
• IEEE 29148-2011 — стандарт разработки сложных систем
• Rational Unified Process — спецификация для разработки требований к IT-продуктам

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

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

Что должно быть в ТЗ для разработки IT-продукта

Информация о разрабатываемом IT-продукте

1. Назначение и цели создания
2. Структура IT-продукта
   • из чего состоит продукт
   • как он взаимодействует с системой в целом

Глоссарий

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

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

1. Бизнес-требования
2. Функциональные требования
3. Технические требования:
   • характеристики (нагрузка, которую должен выдержать сервис, производительность и т. д.)
   • требования к технологиям
   • требования к серверам
   • требования к скорости работы сервиса
   • обязательная интеграция со сторонними сервисами
   • требования к безопасности
   • и прочее. Таких требований может быть очень много, все зависит от того, какой продукт вы разрабатываете

Спецификация на интерфейс

Этот пункт присутствует в ТЗ на разработку IT-продукта при реализации по прототипам или макетам.

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

Пользовательские сценарии (use case)

• Use case — это ответ системы на действия пользователя. Соответственно, чем больше пользовательских сценариев и реакций системы будет описано в ТЗ, тем лучше.

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

• Определить появление возможных проблем во время разработки
• Четко определить и предсказать поведение системы
• Упрощает приемку задачи, дает совпасть ожиданию и реальности
• Дает однозначность: упрощает жизнь для разработчика, тестировщика, постановщика

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

Тут выбор за вами, главное, чтобы сценарии были понятны.

Однако, каждый сценарий должен обязательно содержать 3 блока:

• Предусловие — что привело к старту сценария
• Постусловие — что должно произойти по окончании выполнения сценария
• Основной поток событий — основной алгоритм действий
• Необязательно, но зачастую присутствует альтернативный поток событий — альтернативный алгоритм действий

Пользовательская и техническая документация

Набор документации, которая будет передана по итогу работ:

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

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

• Техническое задание — мы используем Confluence, Notion
• Спецификация на интерфейс — Confluence, Notion
• Конструкторскую документацию — Confluence, Notion
• Описание API — мы используем openAPI (swagger), postman
• Документация кода (оно же комментирование кода) мы используем PHPDoc, JsDoc

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

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

Согласование ТЗ

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

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

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

как аналитику написать техзадание на ИС

Автор Анна Вичугова

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

Agile по-разгильдяйски или зачем нам ТЗ?

Российские ГОСТы по разработке ТЗ (уже недействующий 34.602-89 и  заменивший его с 01.01.2022 ГОСТ 34.602-2020, что мы рассматриваем в новой статье, а также 19.201-78), а также зарубежные стандарты спецификации требований к ПО (ISO IEEE 29148-2018 и IEEE 830-1998), которые мы разбирали здесь – отличные шаблоны для составления технического задания, знать которые должен каждый аналитик. Однако, содержание любого предмета важнее его формы, поэтому давайте абстрагируемся от строгих рекомендаций и вспомним, зачем вообще нужно ТЗ и как его написать с максимальной пользой. Для этого ответим на 3 простых вопроса:

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

Хотя ответ на первый вопрос может с первого взгляда казаться очевидным, все не так просто. К сожалению, на практике часто бывает, что ТЗ на продукт разрабатывается уже ПОСЛЕ его реализации в каком-то виде и нужно только в качестве обязательной части комплекта проектной документации, чтобы Заказчик и Исполнитель подписали договоры и акты выполненных работ. Другой вариант этого нежелательного кейса – так называемое «ТЗ для галочки», когда структура технического задания на разработку АС/ПО/ИС полностью соответствует стандарту, например, ГОСТ 34.602-89 или 19.201-78, но содержание написано общими фразами и не содержит полного набора функциональных и нефункциональных требований к будущему продукту.

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

Разработка ТЗ на информационную систему по ГОСТ и SRS

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

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

• Заказчик – стейкхолдеры со стороны бизнеса, проблемы которого должен решить продукт с помощью его функциональных возможностей в заданных условиях его использования;
• Разработчик – к этой роли можно отнести как непосредственно программиста, пишущего программный код, так и архитектора ИТ-решения, а также тим/техлида и DevOps-инженера, т.е. всех непосредственных участников процесса реализации заявленных в ТЗ требований;
• Тестировщик – который проверяет, что результат соответствует заявленным ожиданиям, трассируя требования в набор тестов;
• Руководитель проекта – отвечая за бюджет и сроки поставки продукта, project manager должен понимать объем работы, который следует из контекста и набора требований к создаваемому продукту.

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

Можно ли написать ТЗ не по стандартам?

Как уже было отмечено, все российские и международные стандарты по разработке ТЗ и спецификации требований – это всего лишь шаблоны для создания документа «техническое задание». Поэтому, если вы не работает с госзаказчиками и нет необходимости четко следовать структуре и содержанию этих ГОСТ’ов, а ТЗ нужно для единого понимания требований к продукту у бизнеса и исполнителей, можно разработать этот документ самостоятельно. Например, я предлагаю вам следующую рабочую структуру ТЗ на основе SRS по ISO IEEE 29148-2018, исключив некоторые пункты, предписываемые стандартом. Курсивом отмечены мои комментарии по включению в данный документ иллюстраций в виде UML-диаграмм и экранных форм.

• Введение
  • Краткое описание – зачем и кому нужен продукт, какие бизнес-задачи и проблемы он решает, т.е. каковы бизнес-требования с плановыми целями и показателями их достижения
  • Термины и сокращения
  • Категории и характеристики пользователей и их потребности относительно продукта, т.е. требования стейкхолдеров, которые можно наглядно показать в виде UML-диаграммы use case
  • Ограничения, бизнес-правила и стандарты
• Функциональные требования
  • Функциональные требования – по каждому требованию:
    • Название и кодировка
    • Приоритет и трассировка с другими требованиями и/или бизнес-правилами
    • Детальное представление в виде вариантов (сценариев) использования, так называемых юз-кейсов (use case) с возможными иллюстрациями основных и альтернативных потоков, например, в виде UML-диаграммы деятельности, BPMN или EPC-схемы бизнес-процесса. Также здесь можно показать экранные формы, доступные для актора в данном варианте использования.
    • форматы и объем входных и выходных данных (результатов выполнения функции) – может входить в пункт Результат в описании вариантов использования
  • Системные (архитектурные) требования
    • Доменные сущности и связи между ними, что можно показать в виде UML-диаграммы классов или ER-схемы, описывающей таблицы базы данных
    • Среда развертывания (программное и аппаратное обеспечение, например, операционная система ПК или мобильного телефона) – можно показать с помощью UML-диаграммы развертывания и компонентов
    • Внешние компоненты (СУБД, браузер, сетевые подключения и пр.)
    • Программные интерфейсы
    • Интерфейсы оборудования
    • Интерфейсы связи и коммуникации
  • Нефункциональные требования
    • Производительность
    • Надежность и доступность
    • Информационная безопасность и сохранность данных
    • Удобство использования (пользовательские интерфейсы)
  • Прочие требования
    • К интеллектуальной собственности (патентная чистота)
    • Требования к документации

Предложенную структуру можно дополнять и изменять по своему усмотрению. Например, добавить RACI и CRUDL-матрицы или включить в состав нефункциональных требований некоторые характеристики качества ПО, регламентированные стандартом ГОСТ Р ИСО/МЭК 25010-2015 «Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов» (ISO/IEC 25010:2011). О том, что такое нефункциональные требования и чем, например, надежность отличается от доступности, а также как измерить удобство пользовательского интерфейса, мы поговорим в следующий раз, а сейчас предлагаем вам пройти открытый интерактивный тест на проверку знаний о стандартах и требованиях.

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

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

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

 

ЗАПИСАТЬСЯ НА ОБУЧЕНИЕ

— Выберите курс -INTRO: Основы бизнес-анализа: вход в профессию для начинающихMODP: Методы описания бизнес-процессов (IDEF, DFD, BPMN, EPC, UML)EXBAB: Лучшее из BABOK®Guide: ТОП-10 задач и 20+ техник для аналитикаTTIS: Разработка ТЗ на информационную систему по ГОСТ и SRSOAIS: Основы архитектуры и интеграции информационных системBUML: UML для бизнес-аналитика: основы ООП и разработка моделейBAMP: Управление бизнес-анализом — курс для руководителейPOAP: От процессов к продуктам: Product Ownership и Agile-практики для бизнес-аналитикаBSTUD: Курсы по системе Business Studio для бизнес-архитекторов и аналитиковCBAB: Штурм BABOK за 40 часов — подготовка бизнес-аналитиков к экзамену на сертификат CBAP/CCBA Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.

Как написать отличную спецификацию продукта (для начинающих)

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

Но подождите всего одну секунду …

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

Итак, как сделать так, чтобы ваше творение было успешным? Один из способов — написать четкую и краткую спецификацию продукта.

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

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

Звучит достаточно просто, правда? Ну… и да, и нет.

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

Что такое спецификация продукта?

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

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

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

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

Спецификация должна быть ориентирована на клиента, быть краткой и тщательной. Он также должен отвечать на три ключевых вопроса:

1. Что мы строим и зачем?
2. Что дает этот новый продукт или функция?
3. Как измерить успех?

Почему важны характеристики продукта?

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

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

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

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

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

Что должен включать лист спецификации проекта?

• Краткое описание продукта : опишите, что это за продукт, для чего он нужен и зачем он нужен. Уделите время и внимание этому разделу, потому что он вам снова понадобится для устава проекта.
• Список характеристик и требований : объясните, на что способен продукт, как он будет работать и какие материалы вам потребуются для его изготовления.
• График разработки и доставки : включает информацию о разработке, основных этапах и сроках доставки.
• Бюджет на разработку и поставку : укажите, сколько денег вы готовы потратить на разработку и запуск продукта.
• Список рисков и проблем : предоставить разбивку потенциальных рисков или проблем, которые могут возникнуть во время разработки или запуска продукта. Это может быть отдельный список или краткое изложение вашего более полного реестра рисков.
• Экономическое обоснование : кратко опишите преимущества продукта и прогнозируемую прибыль.
• Пользовательские истории : пользовательские истории описывают функциональность продукта с точки зрения пользователя. Вот пример пользовательской истории для веб-сайта: «Как занятой покупатель, я хочу иметь возможность быстро находить информацию о продукте».
• Персонажи пользователей : персонажи — это вымышленные профили, представляющие вашу целевую аудиторию. Примерный образ пользователя может быть таким: «Джон, 25-летний мужчина, который ищет информацию о выпечке».
• Функциональные характеристики : функциональные характеристики содержат более подробное техническое описание продукта, включая принципы его работы, необходимые материалы и поддержку.
• Нефункциональные спецификации : нефункциональные спецификации предлагают общее описание продукта, включая сведения о том, что это за продукт, что он делает и зачем он нужен.
• Дизайн спецификации продукта : важно включить некоторые элементы дизайна в спецификацию вашего продукта, чтобы у разработчиков было четкое представление о целях. Спецификации дизайна могут включать каркасы, макеты или общее описание внешнего вида продукта. Это также полезно при объяснении проекта заинтересованным сторонам, поскольку изображения легче понять, чем технические данные.

Как создать документ со спецификацией продукта

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

1. Определите проблему, которую вы решаете

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

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

2. Проведите исследование

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

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

3. Напишите четкое и краткое резюме

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

Мы создадим современный веб-сайт, простой в использовании и актуальный для пользователей в возрасте от 20 до 30 лет. Цель состоит в том, чтобы предоставить пользователю информацию, которую он ищет, как можно быстрее и интуитивно понятно.

4. Включите временную шкалу

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

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

5. Включите бюджет

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

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

6. Выберите, какие спецификации продукта включить

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

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

7. Запустите пользовательские тесты

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

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

8. Получение отзывов и запуск итерационных циклов

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

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

9. Запустите свой продукт

Если вы довольны продуктом, пришло время запустить его! Релиз — это место, где ваша тяжелая работа объединяется, и ваш продукт, наконец, доступен для общественности.

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

10. Сбор отзывов после запуска

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

Обычные способы сделать это включают в себя проведение опросов и мониторинг поведения пользователей на веб-сайте с помощью тепловой карты и A/B-тестов.

Спецификации продукта: практические советы и рекомендации

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

Backlog, наш собственный инструмент управления проектами, содержит интерактивные диаграммы Ганта, репозитории SVN и Git, перетаскиваемые файлы, потоки истории и многое другое.

Заключительные мысли

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

Как описать создание продукта

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

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

Что такое характеристики продукта?

Спецификация продукта — это план, в котором объясняется, каким будет продукт, как он будет выглядеть и какую функцию он будет выполнять.

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

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

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

Что включать в спецификацию продукта

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

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

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

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

Пользовательские истории : Напишите пользовательские истории — краткие описания пользователями своего опыта использования продукта. Опишите функции, которые хотят видеть пользователи. Вы можете написать их, используя простой шаблон: «В качестве функции я хочу [цель], чтобы [выгода]».

Например, не очень технически подкованный потребитель может сказать: «В качестве функции мне нужен простой в использовании интерфейс, чтобы я тратил меньше времени на чтение инструкций».

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

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

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

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

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

Спецификация продукта

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

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

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

Источник: TemplateLab

Как написать спецификацию продукта

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

1.

Начните с определения проблемы

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

• Что их больше всего волнует?
• Какие у них проблемы?
• Как продукт может решить эту проблему?

2. Взгляните на информацию о клиентах

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

3. Обсудить со всей организацией

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

4. Расставьте приоритеты и выберите функции

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

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

5. Отправить первоначальный лист спецификаций продукта в разработку

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

6. Проведение пользовательского тестирования

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

7. Оптимизация спецификаций продукта

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

Примеры спецификаций продуктов

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

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