Уже два года я работаю системным аналитиком в крупной телеком-компании, которая развивает IT-направление.
В этой статье на примере двух кейсов покажу, как системный анализ помогает оптимизировать разработку и сэкономить ресурсы компании. А ещё поделюсь тем, как у нас устроены процессы.
Контекст
У нас 2 мобильных приложения, около 10 веб-приложений и 50+ микросервисов. Всем этим пользуются около 7 миллионов человек. Это сложная экосистема, где важно качественно планировать и управлять ресурсами.
Мы сталкиваемся с несколькими основными вызовами:
-
Микросервисная архитектура. Надо постоянно следить, чтобы ничего не падало. Сервисы должны быть надёжными и масштабируемыми.
-
Миллионы пользователей. Система должна выдерживать высокие нагрузки.
-
Множество приложений и сервисов. Интеграция и синхронизация между платформами требует внимания к деталям.
Любой проект начинается с определения целей бизнеса и довольно амбициозных запросов. Кто-то хочет запустить новые услуги для клиентов или улучшить существующие продукты. И тут всегда встаёт главный вопрос: а можно ли это реализовать?
Первый кейс: как потерять ресурсы
Бизнес захотел создать мобильное приложение для учёта ресурсов. Компания нанимает инхаус-команду из 9 человек, куда входят разработчики, тестировщики, скрам-мастер. Средний фонд оплаты труда такой команды составил примерно $15 000 в месяц. Планировалось реализовать проект за 8–10 месяцев.
Проблема была в том, что команда начала разработку без чётких требований. Бизнес-заказчики часто формулируют задачу абстрактно, в духе «Хочу приложение», не объясняя, как всё должно работать технически. В итоге получаем затянутый процесс, нескончаемые правки и откровенно сырой продукт.
Почему всё пошло не так:
-
Нечёткие требования. Разработчики получили задачу без подробного описания функционала.
-
Проблемы в общении. Чтобы уточнить требования, разработчик задавал вопросы тестировщику, тот — заказчику, а ясности всё равно не было.
-
Постоянные исправления и доработки. Из-за недостатка информации и отсутствия конкретики ошибки множатся, на их исправление уходит время, а конца не видно.
-
Переработки и выгорание. Команда тратила много времени и энергии на уточнение деталей и доработки. Неопределённость и постоянные изменения демотивировали людей.
Результат: вместо запланированных $140 000 компания потратила на проект больше $180 000. Сроки увеличились на 4 месяца. Готового продукта так и не появилось.
Второй кейс: как это исправить
Для того же проекта решили привлечь системного аналитика в команду. Сроки, и планы были аналогичными, к базовым затратам прибавился +1 человек ФОТа (~$18 000 в месяц). Проект завершили за полгода с нормальным рабочим MVP, который можно развивать дальше.
Вы спросите, а разница-то какая? Один человек всё наладил? Да, всего один дотошный системный аналитик смог чётко сформулировать задачи, устранить путаницу и направить команду в нужное русло.
На примере первого кейса видно, как проходит типичная разработка без системного анализа.
Бизнес говорит абстрактно: «Хочу приложение» → Разработчики начинают работу, но у них возникает куча вопросов → Они идут с вопросами к тестировщикам, те обращаются к бизнесу, но не получают полных ответов → Команда не укладывается в сроки, из-за постоянных доработок и задержек теряется мотивация, проект стопорится.
В результате компания теряет время, деньги и получает продукт низкого качества.
Во втором же кейсе активно участвует системный аналитик. Он связывает бизнес и команду разработки, обеспечивает чёткость требований и структурированный подход к проекту.
Чем занимается системный аналитик и как помогает команде
-
Формулирует чёткие требования. Аналитик переводит запросы и пожелания бизнеса в конкретные задачи для команды разработки.
-
Систематизирует работу. Требования фиксируются в удобных инструментах, таких как Miro, Notion и Confluence, чтобы упростить разработку.
-
Поддерживает актуальную документацию. Вся документация по проекту обновляется в режиме реального времени. Процесс разработки становится прозрачным и понятным для команды.
Инструменты для системного анализа
Немного расскажу об инструментах, которыми мы пользуемся в работе.
-
Miro. Это платформа для визуализации процессов и совместной работы. В Miro можно наглядно показать, как будет работать система, строя диаграммы последовательностей и взаимодействий.
Например, при проектировании нового функционала для мобильного приложения мы используем Miro, чтобы визуализировать пользовательский поток — от входа в приложение до взаимодействия с сервером.
-
Notion. Платформа для хранения документации по проекту. В Notion фиксируются бизнес-требования, критерии приёмки, гипотезы и другие ключевые элементы.
В одном из проектов мы фиксировали в Notion все гипотезы и требования, чтобы у команды был доступ к нужной информации на всех этапах работы.
-
Confluence. Инструмент для создания и ведения документации. В Confluence мы создаем sequence-диаграммы, которые помогают разработчикам лучше понимать, как будут взаимодействовать компоненты системы.
Для одного из микросервисных проектов мы как раз создавали sequence-диаграммы в Confluence. Это сильно упростило работу разработчиков и тестировщиков, так как все взаимодействия были чётко прописаны.
-
Mermaid. Инструмент для создания диаграмм с помощью кода. В Mermaid легко вносить изменения, а диаграммы можно интегрировать с Confluence.
С помощью Mermaid мы можем быстро обновлять диаграммы, когда меняются требования или функциональные детали проекта. Это помогает поддерживать документацию в актуальном состоянии и облегчает разработку.
Подход Doc First: документация вперёд
У нас в компании практикуется подход Doc First: сначала создаётся документация, потом пишется код. Это не только упрощает работу, но и экономит нервы.
Преимущества такого подхода:
-
Возникает меньше вопросов и недоразумений, так как у команды есть задокументированные требования.
-
Разработка идёт быстрее. У разработчиков есть чёткие требования, они могут сразу приступить к работе, не нужно уточнять детали на каждом этапе.
-
Легко вносить изменения. Если что-то поменялось, это сразу фиксируется в документации. Команде проще разобраться и адаптироваться.
Пример: мы разрабатывали новый API для мобильного приложения. Сначала сделали спецификацию в формате Swagger, которая описывает все возможные взаимодействия с системой. Подняли моки в Postman, что позволило разработчикам начать работу с готовыми примерами. Описали алгоритмы работы для тестировщиков, чтобы сразу приступить к работе с полным пониманием задачи.
Управление задачами и тестирование
Задачи мы ведём в Jira. Она интегрируется с Confluence и другими инструментами, так легче отслеживать процессы.
В целом управление задачами у нас выглядит так:
-
Формулируем требования. Системный аналитик фиксирует задачи в Jira и связывает их с документацией в Confluence.
-
Назначаем разработчиков. Задачи распределяются между участниками команды, каждый знает, за что отвечает.
-
Автоматизируем и интегрируем. Jira интегрируется с GitLab и Notion, так что весь процесс становится проще и прозрачнее.
Тестировщики работают с задокументированных требований. Они создают сценарии на основе критериев приёмки, описанных в Notion и Confluence. Например, при тестировании нового функционала для приложения команда использует документацию, созданную аналитиком. Это сильно снижает количество ошибок.
Давайте подытожим
Системный анализ — это must-have для бизнеса, потому что он:
-
Ускоряет разработку. Системный аналитик формулирует задачи и последовательно фиксирует требования, чтобы уменьшить количество итераций и ускорить процесс. Например, в проектах, где был вовлечен системный аналитик, среднее время разработки сократилось почти в два раза — с 8–10 месяцев до 4–6.
-
Помогает снизить затраты. Благодаря требованиям и документации становится меньше ошибок и, как следствие, переработок. Это снижает общие затраты на проект.
-
Поддерживает команду. Системный анализ помогает избежать выгорания команды. Это положительно сказывается на мотивации сотрудников, так как благодаря правильной постановке задач и фиксации требований мы сократили время разработки нового функционала для приложения в 2 раза.
Системный анализ — это не лишний этап и не формальность, а важный элемент успешной разработки. Он помогает сэкономить время, нервы и ресурсы, избежать ошибок и хаоса, а главное — создавать качественные продукты.
ссылка на оригинал статьи https://habr.com/ru/articles/854600/
Добавить комментарий