Кристина Ширкунова
Ведущий аналитик в «Ренессанс жизнь»
Хабр привет! Меня зовут Кристина Ширкунова, я ведущий аналитик в «Ренессанс жизнь», а до этого 5 лет работала в заказной разработке. Я участвовала в большом количестве проектов: начиная от обычных сайтов и заканчивая цифровой трансформацией достаточно крупных компаний. Почти в каждом проекте требовалось верхнеуровневое описание, потому что проекты были разные, объем большой и команды часто обновлялись. Именно об этом я и написала: как сделать верхнеуровневое описание функциональности максимально эффективно для команды.
Верхнеуровневое описание: как создать единый источник правды для вашей команды
Как бизнес-аналитику, так и системному аналитику знакома проблема долгого погружения в проект: новички тратят недели на изучение контекста. Другая частая ситуация — проектирование доработок функционала, который уже существует. Знание о нём часто уходит вместе с уволившимися «хранителями» информации.
Эти проблемы — симптомы отсутствия качественного верхнеуровневого описания проекта, продукта или функциональности. Такой артефакт не только ускоряет онбординг, но и служит профилактикой «легаси», обеспечивает единое видение целей и экономит огромное количество ресурсов команды.
Проблемы, которые решает верхнеуровневое описание
Прежде чем создавать описание, важно понять, какие боли оно закрывает:
Разрозненность контекстов: Разработчики, аналитики, продукт-менеджеры и заказчик могут по-разному понимать бизнес-задачи проекта. Это приводит к конфликтам и неэффективной работе.
Долгое погружение новых сотрудников: Новички теряются в объеме информации, не понимают сути происходящего и могут даже уволиться, не вписавшись в контекст.
Наследие (Legacy): Проект идет давно, никто не помнит все детали. Изменение одной части системы неожиданно «ломает» другую.
Функциональные пересечения: Команда проектирует или разрабатывает то, что уже есть, дублируя функционал и данные (например, две таблицы товаров в разных сервисах).
Что описывать
Описание должно отвечать на два основных блока вопросов, которые возникают у любого нового участника: бизнесовые («Зачем?») и технические («Как?»).
Бизнес-уровень (Концепция)
Это основа, с которой начинается погружение. Цель — дать понимание: что мы делаем, для кого и зачем.
Что включать в концепцию (продукта/проекта/фичи):
Цель: Зачем мы делаем этот продукт/проект? Какие боли и потребности бизнеса или пользователей он закрывает?
Сфера деятельности: Работаем в медицине, ритейле, B2B? Это определяет контекст и терминологию.
Бизнес-заказчики и стейкхолдеры: Кто вовлечен со стороны заказчика? (Этот раздел динамичен и должен обновляться).
Термины и сокращения: Единый глоссарий, которым пользуются и команда, и заказчик.
Критерии успеха: Как мы поймем, что продукт/фича/доработка оказалась успешной?
Ограничения: Бизнес-ограничения, работа с другими подрядчиками, сроки.
Задачи проекта: Верхнеуровневый перечень бизнес-требований (например, в виде реестра).
Важно: описывать нужно не только весь продукт, но и каждую фичу или крупную доработку. Зачем нам личный кабинет? Зачем эта кнопка? Это помогает расставлять приоритеты и понимать, стоит ли задача ресурсов.
Технический уровень (Архитектура и данные)
После понимания «зачем» возникает вопрос «как». Цель — показать, как система устроена изнутри.
Что описывать:
-
Архитектура решения: Как система взаимодействует с внешним миром?
Схемы интеграций: Отобразите на одном экране критические потоки данных (например, «заказы» и «товары» для интернет-магазина). Покажите, какие системы участвуют в обмене, через какие шины проходят данные.
-
Внутреннее устройство системы:
Модули/сервисы: Из каких крупных блоков состоит система?
Сущности модулей: Какие ключевые объекты (данные) живут в каждом модуле?
Взаимосвязи: Как модули и сущности взаимодействуют друг с другом? Это критически важно для понимания последствий изменений.
Инструменты для визуализации
Текстовой концепции часто недостаточно, да и вычитывать большой объем текстовой информации может быть долго и нудно.. Используйте схемы — они нагляднее и легче воспринимаются.
BPMN / UML: Для описания бизнес-процессов и моделей данных.
Блок-схемы: Для описания алгоритмов и процессов.
Cхемы взаимодействия (Venn, ArchiMate): Для визуализации архитектуры и интеграций.
Mind maps (Интеллект-карты): Для структурирования целей, фич или требований.
Ниже примеры схем для описания функциональности.
На данной схеме знакомая всем нотация BPMN2.0. Не буду углубляться в ее плюсы и минусы - об этом уже много написано - лучше рассмотрим пример.
В данном случае на схеме отображен процесс работы с конкретным модулем (работа с документами в цикле жизни клиента). Цветами обозначены кусочки схемы, отвечающие за конкретный документ. Таким образом, на одной схеме мы видим:
весь процесс работы модуля с “бизнесовой” точки зрения;
общий принцип взаимодействия с каждым документом (детально можно посмотреть на отдельных схемах);
связь документов между собой.
Речь пойдет не о UML диаграмме состояний, а о том, как на одной схеме описать статусы и кейсы, которые на них допустимы. Довольно частая ситуация, когда в зависимости от текущего статуса документа, у пользователей есть разный набор доступных действий.
На схеме выше визуализирована статусная модель в виде тайм-лайна / канбана, где под каждым статусом описаны UC, которые доступны пользователям на них. Так мы видим, что на финальных статусах мы не можем совершать никаких действий, на остальных - набор функциональностей разный.
Зачем статусы в середине выделены ярко-зеленым? Действия на них производятся на основании внешней системы, автоматически. А пользователям доступно буквально пара функциональностей (например, просмотр).
Эта схема может напоминать DFD, но это не совсем она. Изначально, ее цель была в том, чтобы показать заказчику все задействованные системы и для каких данных нам нужна интеграция с ними. Но потом она оказалась полезным артефактом для всей команды, которая понимала, что и из какой системы мы забираем и что отдаем.
Эта диаграмма тоже не принадлежит какой-то конкретной нотации. При этом, она позволяет отследить все потоки данных, которые есть в системах компании. Как это работает? Отрисовываем все системы в виде прямоугольников, а дальше - потоки данных между ними, которые обозначаем цифрами на них (не забывайте про легенду, какой номер за какой поток отвечает). В случае, если систем и потоков много (как на примере), можно добавить потокам цветовое различие.
Чем-то напоминает ERD, но тут у команды стояла другая цель: нам нужно было посмотреть зависимости сущностей и справочников в легаси-системе, чтобы убрать из нее несколько модулей. Схема помогла понять, что мы можем затронуть рефакторингом и насколько это будет критично, а в ходе построения нашлись неожиданные связи, которые при менее подробной проработке могли привести к фатальным последствиям для критически важных функциональностей для компании.
Ключевой принцип всех этих схем: Инструмент должен быть понятен вашей команде. Договоритесь о единых стандартах внутри проекта. Если разработчики не понимают UML, но понимают простые блок-схемы — используйте их.
Процесс сопровождения и онбординга
Сам по себе документ — не панацея.
Не бросайте новичка в документацию: Лидер проекта (тимлид, ведущий аналитик) должен сопровождать процесс погружения, используя документы как основу для объяснения.
Единые стандарты: Старайтесь, чтобы формат документации был одинаковым для всех проектов в компании. Используйте шаблоны — это упростит переход сотрудников между командами.
Актуальность: Концепция — живой документ. Обновляйте термины, список стейкхолдеров и целей по мере развития продукта.
Напоминайте команде о цели: Регулярно возвращайтесь к концепции на планировании и обсуждениях, чтобы сохранять единый контекст.
Когда этим стоит заниматься? Тревожные звоночки
Верхнеуровневое описание не нужно для маленького одноразового проекта. Но есть признаки, что оно необходимо вашей команде прямо сейчас:
Разное видение цели: Участники команды по-разному объясняют, зачем нужен продукт.
Долгий онбординг: Новые сотрудники не могут вникнуть в суть проекта.
Появление легаси: Изменения в одном месте ломают функционал в другом, о связи которых никто не знал.
Функциональные пересечения: Обнаруживается дублирование функционала или данных.
Ключевые выводы и рекомендации
Верхнеуровневое описание — это единственный источник правды. Оно разрешает спорные ситуации, ускоряет принятие решений и предотвращает дублирование работы.
Это инструмент для онбординга. Он помогает быстро погружать как новых сотрудников, так и существующую команду, которую переключили на новый продукт.
Сочетайте текст и визуализацию. Концепция отвечает на вопрос «зачем», схемы архитектуры и процессов — на вопрос «как».
Задумывайтесь о «зачем» с самого начала. Не бросайтесь в детальные требования. Первый вопрос аналитика: «Как эта задача соотносится с целями проекта? Какие проблемы пользователя она решает?».
Избегайте мышления «сделаем и забудем». Практика показывает, что зачастую даже самая маленькая задача будет постоянно дорабатываться и изменяться. Без понимания изначальной цели эти доработки могут пойти по неверному пути.
Заключение
Инвестиция времени в создание и поддержание качественного верхнеуровневого описания — это инвестиция в будущее вашего проекта / продукта. Это не просто документация, это фундамент для единого понимания, быстрой разработки и эффективной работы команды. Начните с малого — сформулируйте цель и нарисуйте первую схему. Это уже станет большим шагом к порядку.
Больше полезного по системному анализу — в нашем ИТ-сообществе. Мы делимся экспертизой через бесплатные вебинары, организуем конференции, проводим опросы и создаем среду для профессионального общения. Подписывайтесь, чтобы быть в курсе всех событий и не упустить ничего важного. До встречи внутри!