«Идеальное» техническое задание

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

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

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

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

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

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

Композиционно наши спецификации состоят из трёх частей: База знаний, Элементы системы и их особенности, User flow (пользовательские сценарии). База знаний включает общее описание и цель разработки программного обеспечения, глоссарий с определениями терминов, используемых в тексте спецификаций. Также в этой части указываются ограничения, параметры устройств, на которых будет использоваться ПО, и полезные ссылки на ресурсы, которые потребуются при разработке: дизайн, внешние API и сервисы, с которыми планируется интеграция.

Часть "Элементы системы и их особенности" состоит из отдельных разделов, каждый из которых посвящён сущности или элементу системы, которые могут иметь набор параметров, статусы/состояния, а также список действий, которые можно осуществлять с ними. Описывая функциональности в третьей части спецификаций, мы обнаруживаем новые статусы для сущностей, дополнительные параметры, необходимые для корректной работы ПО, и возвращаемся к ранее описанным разделам, дополняя их и собирая по кусочкам каждую сущность системы. В качестве простого примера можно привести сущность "Сообщение" с параметрами: адресат, заголовок, текст сообщения, дата создания, дата отправки. Статусы этой сущности могут включать: создано, черновик, отправлено, доставлено. Список действий может включать: создание сообщения, сохранение сообщения в черновики, просмотр сообщения в черновиках, отправка сообщения. Уверен, что при подробном описании User flow для этой сущности мы обязательно дополним и список действий, и количество статусов, а также расширим список параметров в соответствии с потребностями ПО.

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

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

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

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