ТЗ, начало!

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

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

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

Нам необходимо связать нашу идею, дерево целей и бизнес архитектуру таким образом, чтобы получился документ типа ТЗ (мы не претендуем на оформление ТЗ по ГОСТ, нам необходимо иметь документ, который будет понятен всем участникам проекта/продукта)

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

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

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

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

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

Шаг 1 Связать дерево целей и ТЗ

За пример возьмем нашу идею из статьи Оформление идеи ИТ-проекта (для единомышленников) Технология оценки состояния здоровья сотрудника для допуска к работе/учебе/процедурам/…. У нас описаны цели 1 и 2 уровней, можно описать ещё глубже, но это не является предметом статьи. Приведем лишь пример

Пример 1:

Цель 2 уровня — Интеграция с популярными моделями оборудования для снятия медицинских показаний.

Компонент – Интеграция с оборудованием.

Требования:

Шаг 2 Выделить компоненты

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

Цель 2 уровня – обеспечение возможности сохранности данных в защищённом хранилище

Компонент – Файловое хранилище

Пример:

Файловое хранилище решает 2 задачи:

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

Шаг 3 Оценить необходимые ресурсы

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

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

Шаг 4 Оценить выгоды

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

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

Для построения ТЗ мы должны

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

Для статьи использовались материалы habr. com по микросервисной архитектуре и secrets. tinkoff. ru по юнит экономике