Привет, друзья! Сегодня поговорим о том, как системный аналитик (то есть я, ты или тот парень из соседнего отдела) может использовать визуализацию, чтобы перестать быть "человеком, который пишет непонятные документы", и стать "тем, кто делает красивые картинки, которые все понимают". Ну, или хотя бы пытается.
Давайте признаем, что иногда объяснить разработчику, как работает процесс, — это как объяснить котику, почему нельзя есть кактус. Ты вроде всё правильно говоришь, но в итоге он всё равно делает или понимает по-своему. А всё почему?
Первое — причина в нас, и мы не умеем объяснять! (но это уже отдельная история)
Второе — потому, что слова — это скучно.
Зачем вообще это нужно?
Давайте начистоту:
Текстовые требования — это как рецепт без фотографий. Ты читаешь: "возьмите 200 г муки, добавьте яйцо, замесите тесто..." Но как оно должно выглядеть на каждом этапе? Густое или жидкое? Сколько именно мешать? А если бы были фото или видео, ты бы сразу понял, что к чему.
Например, представьте, что вы описываете взаимодействия микросервисов для разработчиков. Текстовая версия может выглядеть так:
”У нас есть сервис A, который взаимодействует с сервисом B через REST API. Сервис B, в свою очередь, отправляет данные в сервис C через очередь сообщений Kafka. Сервис C обрабатывает данные и сохраняет их в базу данных PostgreSQL. Сервис D периодически запрашивает данные из PostgreSQL и отправляет их в сервис E через gRPC."
Этот текст, конечно, информативен, но разработчику придется мысленно строить схему взаимодействия, что может привести к ошибкам или недопониманию. Вместо этого можно использовать диаграмму, где каждый сервис будет представлен в виде блока, а стрелки покажут взаимодействие между ними.
Что это дает?
1. Упрощение сложного
Вместо 5 страниц текста — одна понятная диаграмма. Как говорил Эйнштейн: "Если вы не можете объяснить это просто, вы сами не до конца это понимаете".
2. Улучшение коммуникации
Когда ты показываешь разработчику красивую и понятную диаграмму процесса, он сразу думает: "О, этот человек знает, что делает!" А если ты показываешь ему 20 страниц текста, он думает: "О, этот человек знает, как пользоваться Word..."
3. Найти скрытые проблемы
Иногда, когда ты визуализируешь данные, ты вдруг понимаешь: "Ой, а тут дыра размером с черную дыру!" И это хорошо, потому что лучше найти её сейчас, чем потом, когда всё уже запущено в production.
Как это работает на практике?
Давайте посмотрим на несколько примеров, где визуализация данных может спасти тебе жизнь (или хотя бы нервы).
1. Визуализация бизнес-процессов
Представьте, что вам нужно описать процесс оформления заказа в интернет-магазине. Тут куча условий, ветвлений, кейсов и прочих нюансов. Что делает большинство системных аналитиков (чаще всего junior)? Пишут кипу текста. И вот что у нас получается:
Клиент заходит на сайт интернет-магазина.
Клиент ищет товар через поисковую строку или каталог.
Клиент выбирает товар и нажимает кнопку "Добавить в корзину".
Клиент нажимает кнопку "Оформить заказ".
— Если клиент уже авторизован, система переходит к следующему шагу.
— Если клиент не авторизован, система предлагает войти в аккаунт или зарегистрироваться.
Клиент указывает адрес доставки.
Клиент выбирает способ оплаты (например, карта, PayPal, наложенный платёж).
Клиент проверяет данные и нажимает кнопку "Подтвердить заказ".
— Если оплата прошла успешно, система переходит к следующему шагу.
— Если оплата не прошла, система предлагает повторить попытку или выбрать другой способ оплаты.
Система формирует заказ и отправляет уведомление клиенту.
Заказ передан в службу доставки, клиент получает трек-номер для отслеживания
И далее по смыслу….
С точки зрения содержания — всё верно. Но вот с точки зрения восприятия... Ну, знаете, как читать инструкцию к китайскому роботу пылесосу, вроде всё понятно, но глаза разбегаются, и хочется закрыть и никогда больше не открывать.
И тут на помощь приходит наш хороший товарищ — BPMN (Business Process Model and Notation). Вместо текстовой простыни вы получаете наглядную схему, где каждый шаг, каждое условие и каждое решение видны как на ладони.
Выглядеть это может вот так:
2. Анализ пользовательских сценариев
Ты можешь показать, как пользователь взаимодействует с системой. Например, как он регистрируется на сайте. И тогда все поймут, что "ой, а тут у нас 15 шагов, а нужно 3!" Пример: "Вот пользователь вводит логин, потом пароль, потом подтверждает почту, потом... Ой, а он уже ушёл."
3. Сокращение времени на выполнение задач.
Когда разработчики видят чёткую визуализацию требований, они быстрее понимают, что нужно сделать, и начинают работу. Это уменьшает количество уточняющих вопросов и итераций, что ускоряет процесс разработки.
Как донести информацию до разных команд? Или "Кому что показывать"
Исходя из своего опыта, я выделил несколько подходов, которые помогают донести информацию до разных специалистов. Как говорил кто-то умный: "Если ты объясняешь всем одинаково, ты объясняешь неправильно". Главное — понять, кому что показывать.
1. Системным аналитикам (особенно новичкам на проекте)
Системные аналитики — это как исследователи, которые только что попали в новый мир. Им нужно быстро понять, какие сервисы используются, как они взаимодействуют между собой (через какие брокеры, очереди или API), и где вообще что находится. Тут на помощь приходят диаграммы в нотации C4. Это как карта метро для проекта: сразу видно, кто куда едет, где пересаживается и куда лучше не соваться.
Диаграмма была взята из статьи “Как описать большую систему в нотации С4”
2. Backend и Frontend разработчикам
Особенно когда речь идёт о разработке API, им очень помогают диаграммы последовательности. Это как инструкция для робота: кто, кому и что отправляет.
3. Data engineer
Когда нужно описать, как должен работать алгоритм, гораздо проще использовать псевдо-SQL код. Да, он может не запуститься (особенно если работаешь с ещё несуществующими таблицами), но воспринимать информацию в виде чётко структурированного языка гораздо проще.
Пример: "Вот пример запроса, который должен обрабатывать данные. Сразу видно, что мы хотим получить на выходе. Ну, или надеемся получить."
-- Предположим, у нас есть таблица "orders" (заказы) и "customers" (клиенты)
-- Нам нужно получить список заказов для каждого клиента, включая общую сумму заказов
SELECT
c.customer_id, -- ID клиента
c.customer_name, -- Имя клиента
COUNT(o.order_id) AS total_orders, -- Общее количество заказов
SUM(o.order_amount) AS total_amount -- Общая сумма заказов
FROM
customers c -- Основная таблица клиентов
LEFT JOIN
orders o -- Присоединяем таблицу заказов
ON
c.customer_id = o.customer_id -- Связь по ID клиента
GROUP BY
c.customer_id, c.customer_name -- Группируем по клиенту
HAVING
SUM(o.order_amount) > 1000 -- Фильтруем только тех, у кого сумма заказов больше 1000
ORDER BY
total_amount DESC; -- Сортируем по убыванию общей суммы
Согласитесь, что в таком формате информация воспринимается легче, чем если бы она была представлена в виде описания. Мы ведь не на собеседовании на должность разработчика SQL, верно? Верно!
Если вместе с этим добавить тестовые данные из Excel, разработчик станет вашим лучшим другом.
А вот как это могло выглядеть с большим количеством "буков".
"Нам нужно получить список всех клиентов из таблицы customers, а также информацию об их заказах из таблицы orders. Для каждого клиента мы должны посчитать общее количество заказов и общую сумму всех заказов. Затем мы должны отфильтровать результаты, оставив только тех клиентов, у которых общая сумма заказов превышает 1000. Наконец, мы должны отсортировать результаты по убыванию общей суммы заказов, чтобы клиенты с самыми большими суммами были в начале списка."
4. Бизнес-аналитикам
Бизнес-аналитики — это наши главные заказчики счастья. Они формируют бэклог задач, и именно от них зависит, что мы будем делать в ближайшие месяцы. Но есть один нюанс: зачастую они не совсем технически подкованы. И тут на помощь приходит наша любимая фраза: "Объясни, как будто мне 5".
На этом этапе у нас полный карт-бланш: рисуем квадратики, стрелочки, используем любые аналогии, лишь бы донести суть. Это как объяснить, почему небо голубое, но вместо неба у нас — сложный процесс обработки заказов, а вместо голубого цвета — куча технических нюансов.
Главная задача здесь — сделать так, чтобы бизнес-аналитики поняли, что технически выгодно, а что нет. Если на этом этапе они начинают отсеивать свои идеи, которые невозможно реализовать или которые просто не стоят усилий, значит, мы сделали свою работу хорошо.
Баланс — это как пицца: без правильных пропорций невкусно
Справедливости ради, отмечу, что не всегда можно обойтись одними только красивыми графиками и диаграммами. Да, они выглядят круто, разработчики и заказчики иногда плачут от счастья, глядя на них. Но, как и с пиццей, если переборщить с одним ингредиентом, всё может пойти не так.
Бывают ситуации, когда без хорошо проработанного текстового описания просто не обойтись. Если полагаться только на визуализацию, можно получить ситуацию, когда все смотрят на красивую картинку, но никто не понимает, что именно нужно делать. Выглядеть будет это примерно вот так:
Как и в жизни, здесь важно соблюдать баланс. Иногда нужны диаграммы, иногда — текстовые описания, а иногда — и то, и другое. Главное — понять, что лучше работает в конкретной ситуации. Что же выбрать, давайте разберемся.
Как понять, где лучше написать, а где лучше нарисовать?
Когда лучше рисовать:
1. Демонстрация структуры данных.
Если нужно показать, как данные связаны между собой (например, ER-диаграммы для базы данных), визуализация будет понятнее текстового описания.
2. Пользовательские сценарии.
Когда вы описываете, как пользователь взаимодействует с системой, user flow поможет быстро понять, где могут возникнуть проблемы.
Пример: Сценарий регистрации пользователя на сайте.
Когда лучше писать
1. Детальные требования.
Если нужно описать конкретные условия, ограничения или бизнес-правила, текст будет более подходящим. Диаграммы не всегда могут передать все нюансы.
Пример: Описание логики расчета скидок для клиентов.
Базовый тариф зависит от маршрута, класса обслуживания и времени вылета.
Спрос влияет на цену:
Если загруженность рейса выше 80%, цена увеличивается на 10% за каждые дополнительные 5% загрузки.
Если загруженность ниже 30% за 7 дней до вылета, цена снижается на 15%.
Сезонные коэффициенты:
В праздничные дни (например, с 25 декабря по 5 января) цена увеличивается на 20%.
В низкий сезон (февраль, ноябрь) цена снижается на 10%.
Персонализированные скидки:
Для участников программы лояльности предоставляется скидка 5%, но только если текущая цена выше базового тарифа.
Для новых клиентов действует скидка 7%, но не более 1000 рублей.
Дополнительные условия:
Если билет оформляется менее чем за 24 часа до вылета, применяется наценка 25%.
В случае задержки рейса более чем на 3 часа пассажир получает компенсацию 10% от стоимости билета.
В данном случае если мы рисовали диаграмму, она была бы сильно перегружена!
2. Технические спецификации.
Когда вы описываете API, форматы данных или алгоритмы, текстовое описание (возможно, с примерами кода) будет более точным.
3. Когда важна точность.
Если нужно избежать двусмысленности, текст с четкими формулировками предпочтительнее. Диаграммы могут быть интерпретированы по-разному.
Пример: Процесс отмены подписки с юридическими нюансами
Первичный запрос на отмену:
Пользователь может отменить подписку в любое время через личный кабинет.
Если подписка еще действует, пользователь получает доступ к сервису до конца оплаченного периода.
Если у пользователя есть задолженность, отмена недоступна до погашения долга.
Промежуточное удержание пользователя:
При попытке отмены предлагаются альтернативные варианты:
Скидка 30% на следующий месяц.
Пауза подписки на 60 дней.
Если пользователь соглашается на паузу, он может возобновить подписку в течение 60 дней без потери данных.
Финальная отмена и юридические аспекты:
Если подписка была оформлена через сторонний сервис (App Store, Google Play), пользователь перенаправляется в соответствующую систему.
Пользователь получает уведомление на e-mail с подтверждением отмены.
В случае подписки с годовым платежом возврат средств возможен только при отмене в течение 14 дней после оформления подписки.
Инструменты, которые спасут тебе жизнь!
Теперь поговорим о том, чем ты можешь пользоваться, чтобы сделать свои требования не только полезными, но и доступными к пониманию. Как говорила моя бабушка: "Если нельзя, но очень красиво, то можно".
1. Drawio - https://www.drawio.com/
Это как конструктор Lego для диаграмм. Хочешь — BPMN, хочешь — UML, хочешь — С4, хочешь — просто квадратики со стрелочками.
2. Miro - https://miro.com
Это онлайн-доска, где можно рисовать всё, что угодно. Mind maps, диаграммы, схемы — всё, что поможет тебе объяснить, чего ты хочешь.
3. Excel/Google Sheets
Старый добрый Excel. Если ты не хочешь заморачиваться с крутыми инструментами, просто сделай график тут. Это как приготовить ужин в микроволновке: быстро, просто, иногда даже вкусно.
4. PlantUml - https://plantuml-editor.kkeisuke.com/
Это инструмент для тех, кто любит код больше, чем графические интерфейсы. Ты пишешь текст, а PlantUML превращает его в диаграммы. Это как волшебство, только для гиков.
5. Paint
Да, тот самый Paint. Старый, добрый, немного примитивный, но иногда именно он спасает, когда нужно быстро и на пальцах набросать концептуальную схему или процесс.
6. QuickDBD - https://www.quickdatabasediagrams.com/
Этот инструмент позволяет создавать ER-диаграммы (Entity-Relationship) с помощью текстового описания. Просто пишешь, какие таблицы и связи нужны, а QuickDBD автоматически генерирует диаграмму.
Картинки — это сила, но не панацея
Итак, друзья, визуализация данных — это не просто способ сделать требования красивыми. Это твой мост, который соединяет идеи с пониманием.
Но помни: визуализация — это не волшебная таблетка. Иногда без текста просто не обойтись, особенно когда нужно объяснить что-то сложное или детальное. Главное — найти баланс. Как в музыке: слишком много инструментов — и мелодия теряется, слишком мало — и она становится скучной. Так и с требованиями: важно сочетать картинки и текст, чтобы всё звучало гармонично.