Как составить технические требования к программе

Что такое ТЗ?

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

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

Для чего требуется ТЗ?

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

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

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

Кто должен составлять ТЗ?

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

Заказчик

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

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

Исполнитель

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

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

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

Совместно

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

Стоимость ТЗ

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

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

Как составить ТЗ?

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

Что потребуется?

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

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

Пошаговый план

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

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

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

1. Однозначные формулировки. Содержание ТЗ не должно включать описаний или характеристик, допускающих неоднозначные трактовки. В тексте документа не допускается присутствие качественных прилагательных и крайне приветствуются конкретные цифры.
2. Определение используемых терминов. Заказчик и исполнитель должны разговаривать на одном языке. Поэтому ключевые понятия нуждаются в расшифровке.
3. Соблюдение установленных стандартов. Перечень нормативных документов, которые можно использовать при составлении технического задания, приводится ниже. Здесь же необходимо отметить, что ссылки на ГОСТы или ISO всегда полезны, так как сводят к минимуму возможные разночтения.
4. Предоставление исполнителю максимально возможной информации о заказчике. Такие сведения помогают сориентироваться в том, что является важным для заказчика, его целевой аудитории и других важных параметрах.
5. Перечисление конкурентов. Достаточно часто существенную помощь в реализации проекта оказывает изучение и анализ аналогов, уже представленных на рынке или запланированных к запуску конкурирующими компаниями. Такой подход к решению задачи заслуживает внимания, так как позволяет минимизировать сопутствующие расходы и не заниматься «изобретением велосипеда», а сосредоточиться на улучшении уже имеющихся разработок.
6. Внесение корректировок при необходимости. Если речь идет о сотрудничестве двух коммерческих структур, целесообразно наладить постоянное общение. В том числе –с целью уточнения ТЗ, если это потребуется. Хотя намного правильнее заранее прописать все возможные нюансы и сценарии развития событий, так как любые корректировки технического задания можно и нужно считать форс-мажором.

Скачать шаблон и пример ТЗ на оказание услуг – источник s-vfu.ru.

О стандартах

Порядок разработки технических заданий регламентируется множеством стандартов – как международных, так и отечественных. Причем в отношении разных проектов и продуктов действуют различные нормы. Наиболее часто упоминается международный стандарт ISO/IEC/IEEE 29148-2018. Он устанавливает требования к ТЗ на разработку информационных систем и программного обеспечения.

Если говорить об отечественных стандартах, необходимо обязательно отметить два из них. Первый – это ГОСТ 34.602-89, который устанавливает основные технические и другие требования к ТЗ на автоматизированные системы. Второй – это ГОСТ 19.201-78, определяющий порядок разработки ТЗ в рамках единой системы программной документации.

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

Существуют и другие стандарты, в большинстве своем международные – IEEE STD 830-1998, RUP, BABOK, SWEBOK и т.д. Их использования в отечественных условиях сильно ограничено из-за отсутствия учета местной специфики и широкого распространения.

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

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

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

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

В каком случае ТЗ не нужно?

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

Шаблоны для скачивания и примеры

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

FAQ

Что такое ТЗ?

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

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

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

Что следует включить в ТЗ?

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

Кто занимается составлением ТЗ?

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

Какие типичные ошибки допускаются при разработке технического задания?

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

Подведем итоги

1. Техническое задание – это перечень требований к конечному продукту или результатам реализации проекта.
2. Разработка ТЗ – важный подготовительный этап, от успешного выполнения которого зависит эффективность дальнейшего сотрудничества между заказчиком и исполнителем, а также качество полученного на выходе продукта.
3. Составлением ТЗ занимается заказчик, исполнитель или одновременно оба. Последний вариант нередко оказывается самым плодотворным при условии взаимного доверия между сторонами.
4. Стоимость технического задания определяется индивидуально и зависит от специфики конечного продукта, его сложности и предъявляемых заказчиком требований.

1. Введение –

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

1.1. Цель

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

Этот раздел должен быть коротким: достаточно 1-2 абзацев.

1.2. Целевая аудитория

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

1.3. Использование по назначению

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

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

1.4. Объем

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

В этом разделе должны быть описаны:

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

1.5 Определения и сокращения

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

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

2. Общее описание

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

2.1 Потребности пользователей

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

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

2.2 Допущения и зависимости

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

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

3. Особенности системы и требования

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

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

указываются в списке функций, которые будут выполняться в системе. Эти критерии касаются вопроса «что будет создано?» а не “как” и “когда”.

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

3.2 Требования к внешнему интерфейсу

Функциональные требования составляют значительную часть спецификации системных требований. Чтобы охватить все необходимые функции системы, вам понадобится 4-5 страниц информации. Некоторые команды разбивают их по темам, чтобы документ было легче читать.

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

В зависимости от проекта требования к внешнему интерфейсу могут состоять из четырех типов:

• Интерфейс пользователя
• Программный интерфейс
• Аппаратный интерфейс
• Интерфейс связи

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

3.3 Системные требования

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

Создание системных требований перед началом создания продукта может показаться сложным, но это необходимо. Разработчики должны придерживаться требований к оборудованию, чтобы им не пришлось перезапускать проект позже. Мобильные приложения (с множеством переменных, которые необходимо учитывать) и приложения, требующие высокой реактивности (игры, любой продукт с VR/AR или IoT), особенно уязвимы.

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

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

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

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

Целью нашей разработки было создание с нуля учетной системы для одной из крупных российских компаний. Система была призвана заменить текущую, написанную в конце 90-х. В результате были реализованы платформа и один из бизнес-модулей. В реализованной части было порядка 120 объектов, 180 таблиц, около 30 печатных форм.

Хочу оговориться, что подход, описанный ниже, не универсален для написания любого ПО. Он подходит для систем уровня предприятия, которые строятся на основе объектно-ориентированного подхода: учетных, CRM-, ERP-систем, систем документооборота и т.п.

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

• Общая часть
  • Список терминов и определений
  • Описание бизнес-ролей
• Требования
  • Бизнес-требования
  • Общие сценарии
  • Сценарии использования
  • Алгоритмы и проверки

  • Системные требования
  • Нефункциональные требования
  • Требования к интеграции
  • Требования к пользовательскому интерфейсу

• Реализация
• Тестирование
• Руководства
• Управление

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

Бизнес-требования описывали то, что необходимо бизнес-пользователям. Например, им вовсе не нужен объект системы Пользователь, но зато им нужно иметь возможность поменять стоимость товара в счете и распечатать его. Бизнес-требования состояли из общих сценариев, сценариев использования (use cases) и описания алгоритмов обработки данных. Подробно о разработке подобного рода требований можно узнать из книги Карла И. Вигерса и Джоя Битти Разработка требований к программному обеспечению.

Системные требования описывали свойства и методы всех объектов системы.

Нефункциональных требований в данной статье мы касаться не будем. Могу лишь отослать вас к отличной книге Architecting Enterprise Solutions авторов Paul Dyson, Andrew Longshaw.

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

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

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

Давайте рассмотрим подробнее, что такое список терминов и зачем он нужен.

Список терминов и определений

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

Поясню это на примере термина Пользователь. Википедия дает такое определение:

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

Но нас оно не устраивало по нескольким причинам. Во-первых, в систему может зайти только человек, но не организация. Во-вторых, для нашей системы некорректно настоящее время глагола «использует» — система хранит данные о неактивных или удаленных пользователях, т.е. о тех, которые использовали систему ранее, но не могут в настоящее время. И наконец, у нас есть данные о потенциальных пользователях. Например, мы регистрируем сотрудника компании-клиента, который в дальнейшем может получить (а может и не получить) доступ в систему. Наше определение:

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

Термины связаны друг с другом. В термине Пользователь используется «операция», поэтому приведу и ее определение:

Операция — совокупность действий, составляющих содержание одного акта бизнес-деятельности. Операция должна соответствовать требованиям ACID (Atomicity, Consistency, Isolation, Durability). Совокупность операций одного модуля представляет интерфейс взаимодействия клиент-сервер этого модуля.

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

Работа над списком терминов происходила постоянно. Мы поддерживали его полноту, т.е. старались, чтобы в документации не было термина, который бы не был определен в этом списке. Кроме того, были случаи, когда мы меняли термины. Например, по прошествии нескольких месяцев с начала написания требований мы решили заменить Контрагент на Компания. Причина была проста: оказалось, что никто не в состоянии в речи, при разговоре, использовать слово «контрагент». А если так, то он должен был быть заменен на что-то более благозвучное.

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

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

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

Описание бизнес-ролей

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

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

Пара примеров:

Уровни требований

Одной из важных концепций, которую мы применяли при разработке требований, было разделение их на уровни. Алистер Коберн в книге Современные методы описания функциональных требований к системам выделяет 5 уровней. Мы использовали 4 – три уровня бизнес-требований плюс системные требования:

Бизнес-требования

1. Общие сценарии (соответствует уровню очень белого у Коберна)
2. Сценарии использования (соответствует голубому)
3. Алгоритмы и проверки (скорее черный)

4. Системные требования (нет прямого аналога, скорее черный)

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

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

На картинке ниже представлена часть нашей иерархии (о содержании речь пойдет дальше).

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

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

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

Бизнес-требования

Общие сценарии

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

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

Некоторые другие цели общих сценариев:

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

Вот пример одного из общих сценариев:

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

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

Наши сценарии использования имели следующий формат:

• Заголовок со следующими полями:
  • статус (В работе | Готов к рецензированию | Согласован)
  • пользователи (по описанию бизнес-ролей)
  • цель
  • предусловия
  • гарантированный исход
  • успешный исход
  • ссылка на описание пользовательского интерфейса (разработанного проектировщиком интерфейсов)
  • ссылка на сценарий тестирования (заполнялось тестировщиками)
• Основной сценарий
• Расширения сценария

Сценарии использования

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

Приведу сценарий использования, на который ссылается общий сценарий выше.

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

Алгоритмы и проверки

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

Например, рассмотрим простой алгоритм ниже.

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

Системные требования

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

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

Описание каждого объекта располагалось на одной wiki-странице и состояло из следующих частей:

• Определение объекта (копия из списка терминов)
• Описание свойств объекта
• Описание операций и прав
• Данные
• Дополнительная информация

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

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

Название
Названием свойства оперирует как пользователь (например, «я изменил номер счета», Номер – свойство объекта Счет), так и проектная команда. Повсеместно в документации использовались ссылки на свойства в виде простой нотации Объект.Свойство, очевидной для любого участника проекта.

Тип
Мы использовали Datetime, Date, Time, GUID, String, Enum, Int, Money, BLOB, Array(), Float, Timezone, TimeSpan. Тип имел отражение на всех уровнях приложения: на уровне БД, сервера приложения, в пользовательском интерфейсе в виде кода и графического представления. Каждому типу было дано определение, чтобы их реализация не вызывала вопросов у программистов. Например, было дано такое определение типу Money: содержит вещественное число с точностью до 4-го знака после запятой, число может быть отрицательным и положительным; одновременно со значением система хранит валюту; валюта по умолчанию — российский рубль.

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

Признак наличия нуля
Да или Нет в зависимости от того, может ли поле не содержать значения. Например, поле типа Bool должно содержать одно из возможных значений, а поле типа String обычно может быть пустым (NULL). Это ограничение реализовывалось на уровне БД и на сервере приложения.

Признак уникальности
Да или Нет в зависимости от того, является ли это поле уникальным. Часто уникальность определяется на группе полей, в этом случае у всех полей в группе стояло Да+. Это ограничение реализовывалось на уровне БД (индекс) и на сервере приложения.

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

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

• Название свойства объекта в программном интерфейсе.
• Название поля в БД.

Оба этих поля не обязательные, поскольку, например, свойство объекта может не храниться в БД, а быть вычисляемым, как сумма счета.

Хочу еще раз обратить внимание, что в написании требований принимали участие программисты. Это важно по многим причинам. Во-первых, таким образом программисты лучше осознавали требования, более того, требования становились «ближе к телу», а не просто неким куском бумаги, написанным каким-то аналитиком. Во-вторых, автоматически формировалась документация для API. В-третьих, поддерживалась трассируемость (traceability) требований, т.е. всегда было понятно, реализовано ли то или иное свойство, что особенно становилось важным при модификации требований. Безусловно, такая методология требовала большей дисциплины от программистов, что на самом деле являлось положительным фактором.

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

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

Вот типичное описание свойств нашего объекта.

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

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

В этом разделе были также таблицы, описывающие переход по статусам.

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

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

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

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

Многие скажут, что такая детализация требований отнимает много времени и не нужна. На что я возражу – а как программист догадается, что конкретно необходимо реализовать? Разве фразы «Необходимо реализовать объект Пользователь» достаточно, чтобы через некоторое время получить работающий код? Сколько надо выпить чая с аналитиком, чтобы вытащить из него данные по 40 (столько было у нас) свойствам пользователя? Кто, как не аналитик или проектировщик, должен приложить усилия и описать все объекты?

Постановка задач программистам

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

Типовая задача 1
Заголовок: Реализовать такой-то объект.
Текст задачи — ссылка на страницу с системными требованиями к объекту.
В такой задаче программисту необходимо:

• создать структуры в БД (таблица, ключи, индексы, триггеры и т.д.);
• реализовать доменный объект;
• реализовать создание начальных данных.

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

Типовая задача 2
Заголовок: Реализовать такую-то операцию такого-то объекта и права на нее
Текст задачи — ссылка на страницу с системными требованиями к объекту.
Программист находит на странице название операции и права, а по ссылке в колонке Комментарий – алгоритмы, проверки, сценарий использования.

Типовая задача 3
Заголовок: Скорректировать объект и/или операцию.
Данная задача необходима в случае изменений требований. Текст задачи содержит описание изменений или ссылку на страницу сравнения версий требований.

Инструмент для написания и управления требованиями

Как, возможно, многие догадались, для работы с требованиями мы использовали Atlassian Confluence. Хочу кратко перечислить достоинства этого продукта.

• Удаленная работа. Собственно, как и у любой wiki.
• Ссылки. Как вы видели выше, ссылки для нас – один из основных инструментов для связывания отдельных частей требований.
• Возможность дробить требования на части (каждая часть – на своей странице).
• Оповещения при изменении. Это одно из важнейших средств совместной работы. Например, получив такое оповещение по одному из сценариев, руководитель разработки может ставить задачи разработчикам, а тестировщики знает, что надо скорректировать сценарии тестирования.
• Комментарии. Многие страницы требований у нас обрастали развесистыми иерархиями комментариев. В Confluence работать с ними достаточно удобно, поскольку иерархия не плоская, а в виде дерева. Кроме того есть возможность использовать полноценный редактор, а не просто текст.
• Наличие мощного текстового редактора. Не буду здесь подробно останавливаться, отмечу лишь, что на всем протяжении нашей работы Atlassian совершенствовал редактор, и если вначале было достаточно много глюков, то затем подавляющее большинство из них было исправлено.
• Хранение истории, сравнение разных версий страниц, возможность отката на старую версию.
• Просмотр иерархии страниц в виде дерева.

Однако было и несколько проблем:

• Поскольку все требования используют одни и те же названия объектов и их свойств, то было бы очень удобно иметь инструмент, который при изменении названия менял его во всей документации. А при удалении – находил все, уже недействительные, ссылки на него.
• Не было возможности сбора статистики. Например, каждое требование имело статус, но мы не могли автоматически собирать статусы всех требований и иметь динамическую картину процесса разработки требований. Но, кажется, на данный момент что-то подобное в Confluence уже появилось.
• Диаграммы приходилось рисовать в другой системе, сохранять в PNG и уже картинку помещать на страницу Confluence. При этом еще надо было приложить исходник, чтобы через пару месяцев его можно было найти и поправить.
• Я не нашел способа экспортировать иерархию страниц в MS Word. Экспорт в XML и PDF очень часто глючил (возможно, дело в размере иерархии).

В конце хочу выразить благодарность Вадиму Лободе и Артему Каратееву за ценные советы и тщательное рецензирование данной статьи.

Антон Стасевич

В данной статье я попытался подробно рассмотреть проблему разработки Технических заданий. Тема стара, как и проблема. Но она до сих пор часто решается “как получится”. Как сказал Генри Шоу “Мелочи тревожат нас больше всего: легче увернуться от слона, чем от мухи”.

О чем эта статья?

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

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

• Вторая часть «Разработка Технического задания. Как формулировать требования?» будет полностью посвящена выявлению и формулировке требований к информационной системе.

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

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

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

• Госструктура решила затеять IT-проект. Тут все настолько мутно, куча формальностей, откатов, распилов и пр. Я не буду рассматривать такой вариант в данной статье.

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

  • Клиент имеет своих специалистов со своими взглядами, и они предъявляют конкретные требования к Техническому заданию;

  • Техническое задание разрабатывается для собственных разработчиков (клиенту все равно);

  • Техническое задание разрабатывается для передачи подрядчику (т.е. группе программистов, находящихся за штатом компании, или отдельному специалисту);

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

  • Возможны и другие, реже встречающиеся варианты;

Думаю, сейчас у читателя должны возникнуть вопросы:

• А почему нельзя разрабатывать Техническое задание всегда одинаково?

• Существуют ли какие-то стандарты, методики, рекомендации? Где их взять?

• Кто должен разрабатывать Техническое задание? Должен ли этот человек обладать какими-то специальными знаниями?

• Как понять, хорошо составлено Техническое задание или нет?

• За чей счет должно оно разрабатываться, да и нужно ли оно вообще?

Этот список может быть бесконечным. Говорю так уверенно от того, что уже 15 лет в профессиональной разработке программного обеспечения, а вопрос о Технических заданиях всплывает в любом коллективе разработчиков, с кем приходиться работать. Причины тому разные. Поднимая тему разработки Технического задания, я прекрасно отдаю себе отчет в том, что не смогу изложить ее на 100% для всех интересующихся темой. Но, попробую, как говорится «разложить все по полочкам». Те, кто уже знаком с моими статьями знают, что я не пользуюсь «копи-пастом» труда других людей, не перепечатываю чужие книги, не цитирую многостраничные стандарты и прочие документы, которые Вы и сами сможете найти в интернете, выдавая их за свои гениальные мысли.  Достаточно набрать в поисковике «Как разработать Техническое задание» и Вы сможете прочитать много интересного, но, к сожалению, многократно повторяющегося. Как правило, те, кто любит умничать на форумах (попробуйте все-таки поискать!), сами никогда не делали толкового Технического задания, и непрерывно цитируют рекомендации ГОСТов по данному вопросу. А тем, кто действительно серьезно занимается вопросом, обычно некогда сидеть на форумах.  Про ГОСТЫ, кстати, мы тоже поговорим. В разные годы своей работы мне приходилось видеть множество вариантов технической документации, составленной как отдельными специалистами, так и именитыми командами и консалтинговыми компаниями. Иногда еще я занимаюсь такой деятельностью: выделяю себе время и занимаюсь поиском информации на интересующую тему по необычным источникам (такой небольшой разведкой). В результате приходилось видеть документацию и по таким монстрам, как ГазПром, РЖД и много других интересных компаний. Конечно же, я соблюдаю политику конфиденциальности, несмотря на то, что эти документы попадают ко мне из общедоступных источников или безответственности консультантов (разбрасывают информацию по интернету). Поэтому сразу говорю: конфиденциальной информацией, которая принадлежит другим компаниям не делюсь, независимо от источников возникновения (профессиональная этика).

 Как ни странно, проблемы у всех одинаковые! У всех бывают как успешные документы (и проекты), так и совсем бестолковые  (исключение, пожалуй, составляют Технические задания, разработанные еще во времена, когда не было персональных компьютеров, но там были совсем другие условия).  Почему так получается? Именно потому, что цели у проектов бывают разные, как и пользователи этих документов. И, конечно, компетенции непосредственных специалистов не на последнем месте.  В этих двух статьях я попытаюсь  поделиться своим личным  опытом, накопленном  за многие годы. Конечно, получится в сжатом виде, т.к. вопрос достоин целой книги (кстати, идея, а может написать?)…  

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

Первое, что мы сейчас сделаем, так это разберемся с тем, что за зверь такой, «Техническое задание».

Да, действительно существуют ГОСТы и стандарты, в которых предприняты попытки регламентировать эту часть деятельности (разработки программного обеспечения). Когда-то все эти ГОСТы были актуальны и активно применялись.  Сейчас существуют разные мнения по поводу актуальности данных документов. Одни утверждают, что ГОСТы были разработаны очень дальновидными людьми и до сих пор актуальны. Другие говорят, что они безнадежно устарели.  Возможно, кто-то сейчас подумал, что правда где-то по серединеJ. Я бы ответил словами Гете: «Говорят, что между двумя противоположными мнениями находится истина. Ни в коем случае! Между ними лежит проблема». Так вот, между этими мнениями истины нет. Потому как ГОСТы не раскрывают практических проблем современной разработки, а те, кто их критикует, альтернативы (конкретной и системной) не предлагают.

Заметим, что  в ГОСТе явно не дано даже определения, сказано лишь: «ТЗ на АС является основным документом, определяющим требования и порядок создания (развития или модернизации – далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие».

Если кому-то интересно, о каких ГОСТах я говорю, то вот они:

• ГОСТ 2.114-95 Единая система конструкторской документации. Технические условия;

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

• ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.

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

Отличное определение, полностью раскрывающее суть. Впрочем, требования ГОСТа направлены как раз на раскрытие этого определения. Я ни в коем случае не критикую требования ГОСТа, я просто утверждаю, что их там явно недостаточно, чтобы разработать эффективное Техническое задание. И это нормально, ведь есть ГОСТ, например, на изготовление хлеба, и это вовсе не значит, что любой человек может выпечь хлеб по ГОСТу. Кроме ГОСТа требуется знание методик и практик, как в любом деле. Именно этот факт лежит в корне проблемы, которая лежит посерединеJ.  А многие специалисты почему-то при необходимости разработать Техническое задание, обращаются только к требованиям ГОСТа. Ну, давайте начнем жить по ГОСТу, посмотрим, что получится! Но ведь не может такого быть, что в столь распространенном занятии, как разработка и внедрение автоматизированных систем  не проводилось исследований, не изучались практики, не писалось книг об этих самых практиках! И это так. Конечно, есть много отличных (!) трудов, посвященных тематике формулирования требований и в конце статьи я приведу такие примеры. Многое в своей практике я использовал именно оттуда, а когда работал над этой статьей, то тоже нашел много интересных мыслей, которыми рад буду поделиться. Так что, велосипеда изобретать не нужно, но есть потребность систематизировать эти знания. Кстати, любопытный факт, ни одного отечественного автора в этих трудах нет. Вся литература в переводе с западных авторов, но зато каких! Среди них есть просто виртуозы своего дела, у которых есть чему поучиться и нужно это делать. Иначе, споры о том, «Как разработать техническое задание» будут продолжаться бесконечно. Однако, я увлекся лирикой…

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

Именно основное, но единственное. Настало время взяться за главное: разложить все «по полочкам», как и обещал.

Что необходимо знать о требованиях? Необходимо четко понимать, что все требования нужно разделять по видам и по свойствам. Сейчас мы научимся это делать. Для разделения требований по видам нам как раз поможет ГОСТ. Тот перечень видов требований, который там представлен, является хорошим образцом того, требования каких видов следует рассматривать. Например:

• Требования в функциональности;

• Требования к безопасности и правам доступа;

• Требования к квалификации персонала;

• …. И т.д. Вы можете  прочитаете о них в упомянутом ГОСТе (а ниже я их тоже рассмотрю немного подробнее).

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

Про виды требований я сказал, а что же со свойствами? Если виды требований могут быть различными (зависит от целей проекта), то со свойствами все проще, их 3:

1. Требование должно быть понятным;

2. Требование должно быть конкретным;

3. Требование должно быть тестируемым;

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

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

• на каком языке (в смысле сложности понимания) должно быть написано техническое задание? 

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

• А что такое техническое  проектирование, о котором, кстати, сказано и в ГОСТах, и как оно связано с Техническим заданием?

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

Так вот:

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

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

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

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

Еще небольшой, но важный момент. Иногда Техническим заданием называют небольшой кусочек требований, простой и понятный. Например, доработать поиск объекта по каким-либо условиям, добавить колонку в отчет и пр. Такой подход вполне себе оправдан, зачем усложнять жизнь. Но применяется не на больших проектах, а на мелких доработках. Я бы сказал это ближе к сопровождению программного продукта. В этом случае в Техническом задании может быть описано и конкретное техническое решение реализации требования. Например, «В алгоритм такой-то внести такое-то изменение», с указанием конкретной процедуры и конкретного изменения для программиста. Это тот случай, когда граница между Техническим заданием и Техническим проектам полностью стирается, т.к. нет никакой экономической целесообразности раздувать бумаготворчество там, где это не нужно, а полезный документ создается. И это правильно.

Управленческий учет: с нуля до настройки в 1С, Excel и Google-таблицах

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

А нужно ли вообще техническое задание? А Технический проект?

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

А что же с Техническим проектом? Данный документ весьма полезный и не утратил свою актуальность. Более того, часто без него просто не обойтись. Особенно, если речь идет о передаче работ по разработке на сторону, т.е. по принципу аутсорсинга. Если этого не сделать, есть риск узнать много нового о том, как должна выглядеть система, которую Вы задумалиJ.  Должен ли с ним знакомиться  Заказчик? Если хочет, почему нет, но настаивать  и утверждать данный документ нет никакой необходимости, он будет только сдерживать и  мешать работать. Спроектировать систему до мелочей практически невозможно. В этом случае придется непрерывно вносить изменения в Технический проект, что занимает немало времени. А если организация сильно забюрократизирована, то вообще все нервы там оставите. Как раз о сокращении такого рода проектирования и идет речь в современных методологиях быстрой разработки, о которых я упоминал выше. Кстати, все они базируются на классическом XP (экстремальном программировании)- подходе, которому уже порядка 20 лет. Так что сделайте качественное Техническое задание, понятно Заказчику, а Технический проект используйте как внутренний документ, для взаимоотношений между архитектором системы  и программистами.

Интересная деталь по поводу технического проектирования: некоторые средства разработки, устроенные по принципу предметной ориентированности (типа 1С и аналогичных) предполагают, что проектирование (имеется ввиду процесс документирования) требуется только на действительно сложных участках, где требуется взаимодействие между собой целых подсистем. В простейшем случае, например создать справочник, документ, достаточно лишь правильно сформулированных бизнес-требований. Об этом говорит и стратегия бизнеса этой платформы в части подготовки специалистов. Если посмотреть на экзаменационный билет специалиста (именно так он называется, а не «программиста»), то Вы увидите, что там присутствуют лишь бизнес-требования, а как их реализовать на программном языке это и есть задача специалиста. Т.е. ту часть задачи, которую призван решать Технический проект, специалист должен решить «в голове» (речь идет о задачах средней сложности), причем здесь и сейчас, следуя определенным стандартам разработки и проектирования, которые формирует опять же компания 1С для своей платформы. Таким образом, из двух специалистов, результат работы которых внешне выглядит одинаково, один может экзамен сдать, а второй нет, т.к. грубо нарушил стандарты разработки. Т.е заведомо предполагается, что специалисты должны обладать такой квалификацией, чтобы типичные задачи проектировать самостоятельно, без привлечения архитекторов системы. И такой подход работает.

Продолжим исследование вопроса: «Какие требования включать в Техническое задание?»

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

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

Как и любую деятельность, формулирование требований можно (и нужно) разделить на этапы. Всему свое время. Это тяжелый интеллектуальный труд. И, если относится к нему с недостаточным вниманием, то результат будет соответствующий.  По экспертным оценкам, стоимость затрат на разработку Технического задания может составлять 30-50%. Я придерживаюсь такого же мнения. Хотя 50 – пожалуй, перебор. Ведь Техническое задание – это еще не последний документ, который должен быть разработан. Ведь еще должно быть и техническое проектирование. Такой разброс обусловлен различными платформами автоматизации, подходами и технологиями, применяемыми проектными командами при разработке. Например, если речь идет о разработке на классическом языке типа С++, то без детального технического проектирования тут не обойтись. Если речь идет о внедрении системы на платформе 1С, то тут с проектированием ситуация несколько иная, как мы видели выше (хотя, при разработке системы «с нуля», она проектируется по классической схеме).

Несмотря на то, что формулировка требований является основной частью Технического задания, а некоторых случая она становиться единственным разделом ТЗ, следует обратить внимание на то, что это важный документ, и оформлять его следует соответственно. С чего начать? В первую очередь начать надо с содержания. Составьте содержание, а затем начните его разворачивать. Лично я делаю так: сначала набрасываю содержание, описываю цели, всю вводную информацию, а затем принимаюсь за основную часть – формулировку требований. Почему не наоборот? Не знаю, мне так удобнее. Во-первых, это гораздо меньшая часть времени (по сравнению с требованиями), во-вторых, пока описываешь всю вводную информацию, настраиваешься на главное. Ну это кому как нравится. Со временем у Вас выработается свой шаблон Технического задания. Для начала рекомендую в качестве содержания взять именно тот, что описан в ГОСТ. Для содержания он подходит отлично!  Затем берем и начинаем описывать каждый раздел, не забывая про рекомендации следования трем свойствам: понятности, конкретности и тестируемости. Почему я на этом так настаиваю?  Об этом в следующем разделе. А сейчас предлагаю все-такт пройтись по тем пунктам ТЗ, которые рекомендуются в ГОСТе.

И так, ГОСТ рекомендует следующие разделы:

1. общие сведения;

2. назначение и цели создания (развития) системы;

3. характеристика объектов автоматизации;

4. требования к системе;

5. состав и содержание работ по созданию системы;

6. порядок контроля и приемки системы;

7. требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;

8. требования к документированию;

9. источники разработки.

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

Раздел 1. общие сведения.

Раздел 2. назначение и цели создания (развития) системы.

Раздел 3. Характеристика объектов автоматизации.

Раздел 4. Требования к системе

Раздел 5. Состав и содержание работ по созданию системы

Раздел 6. Порядок контроля и приемки системы

Раздел 7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

Раздел 8. Требования к документированию

Раздел 9. Источники разработки

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

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

Во второй статье  будем говорить только о разделе 4 «Требования к системе», а конкретно мы будет формулировать требования из соображений понятности, конкретности и тестируемости.

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

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

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

Чтобы в Техническом задании было больше конкретики, существует немало рекомендаций. Даже есть перечень слов, которые употреблять в Техническом задании не рекомендуется. Интересно об этом пишет К.Вигерс, в своей книге «Разработка требований к программному обеспечению». Приведу самые интересные и простые, на мой взгляд, рекомендации:

• Не следует использовать слов, имеющих множество синонимов. Если это необходимо, то лучше дать четкое определение термину в разделе «Термины и определения» к Техническому заданию.

• Следует стараться не использовать длинных предложений;

• Если какое-то требование Вам кажется слишком общим, его необходимо детализировать до более мелких, но конкретных требований;

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

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

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

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

Мы с 2000 года интегрируем умные решения в разные бизнесы: занимаемся сложной веб-разработкой и развитием продуктов, внедряем CRM и ERP-системы, разрабатываем личные кабинеты. Создали более 530 сайтов и веб-сервисов. Имеем опыт заказной разработки для стартапов, а также запуска собственного продукта — MVP экспертной платформы «Консалт-Коллегия». 

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

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

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

Какие тренды проявились в онлайне

• Мобильный трафик безоговорочно преобладает

По данным SlickJump, в 2020 году он достиг 80% в рунете. Это окончательно оторвало пользователей от привычных десктопов и заменило традиционные приложения на их веб-аналоги.

• Упростилось и ускорилось изменение IT-продуктов

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

• Упростился выход на рынок

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

• Изменились бизнес-модели целых отраслей

Компании запускают онлайн-каналы продвижения или полностью переходят в интернет.

• Онлайн увеличил конкуренцию в бизнесе

Причем как количественно — за счет появления новых игроков, так и качественно — за счет расширения клиентской базы.

Итого: конкуренция усиливается, а цикл обновления и жизни продукта сокращается.

И что это меняет?

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

1) Подход с первоначальным проектированием всего продукта не обеспечивает необходимых скорости и гибкости. 

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

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

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

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

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

Шаг 1. Видение продукта 

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

В результате получится концепция, которая состоит из трех разделов:

1. Product Vision — развернутое описание продукта.
2. Product Roadmap — дорожная карта по разработке.
3. Market Requirements Document — рыночные требования: как продукт будет выглядеть и работать.

Пример

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

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

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

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

Шаг 2. Аналитика

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

Результаты этапа: 

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

Пример

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

Мы привлекли к реализации проекта нашего партнера бизнес-сообщество «Конгресс-коллегия». В основу концепции легли две составляющие:

1. Технология шеринга знаний позволяет сделать услугу консалтинга простой и доступной. Платформа организует коммуникации между участниками процесса. Можно привлечь одного или нескольких экспертов для решения задачи, а также найти консультантов для проектной команды. Информация и кейсы фиксируются в базе знаний, к которой можно обращаться в дальнейшем.
2. Методики построения деловых связей. На первом этапе бизнес-сообщество помогает привлечь на платформу надежных консультантов из числа своих членов. Если на сайте нет нужного эксперта для решения вопроса, «Конгресс-коллегия» подберет консультанта в своей закрытой базе, которая включает в себя более 6000 предпринимателей и топ-менеджеров.

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

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

Шаг 3. Генерация идей 

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

Результатами будут: 

• список идей, отсортированный по значимости и данным Market Requirements Document. При отборе часто приходится опираться на интуицию; 
• при необходимости — изменения в Vision и Roadmap.

Пример

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

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

Шаг 4. Проверка гипотез 

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

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

• Customer Development — тестирование идеи или прототипа будущего продукта на потенциальных потребителях; 
• Jobs to Be Done, или «работы, которые надо сделать» — изучение потребностей пользователей и определение задачи, которую решает продукт;
• опросы в чатах, где общается ЦА; 
• создание тестовой версии продукта. 

Если отработать процесс один-два раза, потом на этот этап будет уходить минимум времени.

Пример

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

Шаг 5. Формализация требований 

На этом этапе составляют список функциональных требований к продукту — Product Requirements Document. Получится подробное описание функционала с кучей разных фич. 

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

Пример

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

Шаг 6. Выделение MVP 

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

На этом этапе выделяют: 

• описание рамок MVP (сценарии использования продукта, user stories — краткие требования к системе, написанные языком пользователя, а также функционал для первой итерации);
• список метрик для оценки результатов.

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

Пример

Мы разработали MVP экспертной платформы с минимальным функционалом:

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

Лендинг и каталог экспертов собраны на «Тильде». Бэкенд реализован на «Битрикс24». Механика следующая: 

1. Клиент заполняет форму записи на консультацию.
2. Заявка попадает в Б24 к администратору платформы. 
3. Он уточняет запрос и при необходимости помогает выбрать эксперта.
4. Согласует стоимость и время консультации с обеими сторонами. 
5. Генерирует и отправляет клиенту ссылку на оплату. 
6. После завершения консультации сумма за вычетом комиссии платформы перечисляется эксперту. 

Наши факапы: что мы не учли и к чему это привело  

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

• Выделить время и собрать проектную команду

Я сам как владелец продукта разрабатывал концепцию платформы в свободное от других задач время. Мы привлекали сотрудников, занятых на других проектах. Разработка MVP затянулась более чем на полгода. Если бы работала выделенная команда, проект реализовали бы быстрее и проще. 

• Проверить все гипотезы на старте

Мы выявили и подробно описали боли ЦА — предпринимателей и экспертов. Но не убедились в том, что формат экспертной платформы наиболее востребован целевой аудиторией. Тестовая версия могла бы быть проще — не отдельный сайт, а группа на Facebook со списком услуг и конверсионной кнопкой или канал в Telegram с чат-ботом для записи на консультации.  

• Выбрать другие технологии

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

• Тратить меньше ресурсов на работу с экспертами 

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

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

Как оптимизировать затраты и получить максимум 

1. Перед составлением ТЗ проделайте подготовительную работу и определите, какой минимальный функционал можно реализовать для запуска продукта.
2. Не тратьте много времени на теорию и концепцию — сосредоточьтесь на том, что можно быстро реализовать, чтобы протестировать спрос.
3. Проверяйте на старте гипотезы о болях и предпочтениях клиентов. Но не запускайте масштабное исследование рынка — в большинстве случаев можно уложиться в 7–10 дней. 
4. Стремитесь получить результат с минимальными затратами. Продумывайте каждый шаг: для чего мы это делаем? как упростить процесс? Можно использовать метод анализа «Пять почему». Он заключается в том, что первопричину проблемы определяют с помощью пяти последовательных ответов на вопрос «почему?». 
5. Не делайте лишнюю работу: лучше отказаться от сложных и трудозатратных решений в пользу простых и функциональных.

Фото на обложке: mojo cp/shutterstock.com