Введение
В прошлой статье мы разобрали как можно оформить идею, подготовили презентацию, провели несколько встреч и трудных переговоров. И вот, настал тот день, когда нашим проектом/продуктом заинтересовались, у нас есть команда и мы готовы засучив рукава действовать.
Теперь необходимо составить ТЗ и провести предварительную оценку: что делать, как делать, на нашем языке сформировать функциональные и не функциональные требования.
Требования должны быть понятны, и в случае изменений (управление изменениями – это отдельный большой вопрос при управлении проектами, но оставим его специалистам), должна быть возможность их корректировки, без переделывания всего ТЗ
Постановка задачи
Нам необходимо связать нашу идею, дерево целей и бизнес архитектуру таким образом, чтобы получился документ типа ТЗ (мы не претендуем на оформление ТЗ по ГОСТ, нам необходимо иметь документ, который будет понятен всем участникам проекта/продукта)
Суть
Для решения задачи нам необходимо обратиться к двум современным подходам: микро-сервисной архитектуре и юнит экономике.
Микро-сервисная архитектура - то подход к созданию приложения, подразумевающий отказ от единой, монолитной структуры. То есть вместо того чтобы исполнять все ограниченные контексты приложения на сервере с помощью внутрипроцессных взаимодействий, мы используем несколько небольших приложений, каждое из которых соответствует какому-то ограниченному контексту.
Юнит экономика – оценка прибыльности одной единицы, или юнита. В качестве юнита может быть продукт, пользователь или клиент.
Мы возьмем в них общее (оба определения приведены для обозначения их взаимосвязи, т.е. каждое небольшое приложение, по факту выполняет конкретную, измеримую бизнес функцию и приносит пользу) сервис услуга. Для нас важна возможность описания требований и формирования оценки как с точки зрения реализации, так и с точки зрения получения выгод.
Описывать мы будем требования, через компоненты, так как они позволяют быть более гибким при реализации.
Шаг 1 Связать дерево целей и ТЗ
За пример возьмем нашу идею из статьи Оформление идеи ИТ-проекта (для единомышленников) Технология оценки состояния здоровья сотрудника для допуска к работе/учебе/процедурам/…. У нас описаны цели 1 и 2 уровней, можно описать ещё глубже, но это не является предметом статьи. Приведем лишь пример
Пример 1:
Цель 2 уровня - Интеграция с популярными моделями оборудования для снятия медицинских показаний.
Компонент – Интеграция с оборудованием.
Требования:
- Компонент должен обеспечивать интеграцию со следующим оборудованием … (список оборудования)
- Компонент должен уметь передавать и получать данные по протоколу … (название протокола или протоколов)
- Компонент должен иметь возможность получать … количество сообщений от оборудования
- …
Шаг 2 Выделить компоненты
Компоненты мы выделяем как бы с двух сторон, со стороны бизнеса и со стороны технологий. Таким образом мы снизим вероятность ошибки при формировании требований и не опишем компонент, который будет собирать в себе 2 разных цели.
Цель 2 уровня – обеспечение возможности сохранности данных в защищённом хранилище
Компонент – Файловое хранилище
Пример:
Файловое хранилище решает 2 задачи:
- Сохранение данных
- Получение данных
Но также решает задачу источника данных для аналитики. Мы можем выделить компонент по аналитике отдельно, что более предпочтительно. А можем и сделать единый компонент, что может в последствии привести к дополнительным рискам (перегрузка инфраструктуры, так как хранилище будет использоваться и для аналитики, что в рамках одного компонента будет сложно учесть).
Шаг 3 Оценить необходимые ресурсы
Оценка, при подобном подходе, будет, наверное, самым простым шагом. Так как мы выделили отдельные компоненты (конечно выделять их стоит совместно с архитектором, он позволит избежать массы ошибок), конкретизировали их функции, примерно оценили нагрузку на компонент.
Данную оценку лучше проводить в человеко днях (это единица измерения рабочего времени), финансовую оценку можно сделать путем умножения (тарифы все используют разные).
Шаг 4 Оценить выгоды
Данный шаг иногда упускается, но на мой взгляд он не менее важен чем остальные. При фиксации выгод от компонента, мы сможем качественно выделить приоритеты.
При прохождении этого шага у нас всегда будет аргументация на подтверждение бюджета, а возможно и на его увеличение. Согласитесь, если инвестор понимает, какую выгоду принесет тот или иной компонент, для проекта/продукт сразу становиться менее рискованным
Выводы
Для построения ТЗ мы должны
- Качественно проработать идею
- Описать компоненты с целевыми показателями
- Описать выгоды, которые несет каждый компонент
- Сделать предварительную оценку в человеко днях
При таком подходе, вы всегда подготовите ТЗ, с которым сможет работать любой психически здоровый участник проекта/продукта
Для статьи использовались материалы habr. com по микросервисной архитектуре и secrets. tinkoff. ru по юнит экономике