Уже два года я работаю системным аналитиком в крупной телеком-компании, которая развивает 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 раза.
Системный анализ — это не лишний этап и не формальность, а важный элемент успешной разработки. Он помогает сэкономить время, нервы и ресурсы, избежать ошибок и хаоса, а главное — создавать качественные продукты.
Комментарии (17)
RodionGork
30.10.2024 08:21Прошу прощения, но был бы уместен "конкретный кейс" который показал бы что именно было плохо (кроме отсутствия аналитика) и как это удалось улучшить (кроме привлечения аналитика). А так текст выглядит будто его написал бессистемный аналитик который хотел стать системным но из инструментов имел только тазик с водой. Для того чтобы научиться пользоваться джирой аналитик не обязателен. И что кроме аналитика никто задачи сформулировать не мог - это звучит как диагноз :)
CloseToAlgotrading
30.10.2024 08:21Нахожу Ваше замечание по поводу "конкретного кейса" вполне обосновано, но все же как то уж много критики, статья вроде более менее понятна.
Ведь если задуматься то скорее всего из "разработчики, тестировщики, скрам-мастер" действительно врядли кто то сможет написать внятные требования заказчика и требования к системе.
Я сам немного в другой области работаю, но так понимаю что системный аналитик плотно общается с заказчиками и составляет хорошо проработанные юз кейсы, и на базе этого формулирует понятные и структурированные требования звказчика (не системные и не софтверные).
Однако в данной схеме мне кажется отсутсвует как минимум архитектор (объеденим системного и софтверного в одну роль и наделим его властью писать реквайрементсы).
Ну и скрам мастер тут конечно лишний %)
RestTiger
30.10.2024 08:21Я бы ещё добавил, что роль "Аналитик" в команде должна быть, но совершенно не обязательно, что это будет отдельный человек :-)
Вообще странно выглядит команда, где выделили скрам-мастера, но не упомянули ПМ или тимлида, которые действительно must have в команде. В небольшом проекте они же могут выполнять роль аналитика...
Viklim Автор
30.10.2024 08:21Про архитектора валидно, но я писал только о внутрикомандном взаимодействии, а тенденция на найм и внедрение скрамов растет, на нашем рынке)
Viklim Автор
30.10.2024 08:21К сожалению(или счастью) диагноз уместен. Разработчики пишут код, ПМы и бизнес заказчики строят карту проекта и приоритеты, тестировщики тестируют. В условиях когда бизнес хочет быстро, качественно и не зависимо от конкретного человека в команде - аналитик думает за всех. Целью статьи было донести до общества что делает аналитик для того чтобы команде было комфортно работать с продуктом, который состоит из множества элементов, и так как сообщество Хабра не только жесткие технари пересобирабщие линукс ядро на встрече, был выбран такой язык и подход к написанию
Конкретных кейсов достаточно, ведь многие разработчики игнорируют и половину того что описано в статье)
wolodik
30.10.2024 08:21Разработчики начинают работу, но у них возникает куча вопросов → Они идут с вопросами к тестировщикам, те обращаются к бизнесу
Извините, а что это за сумасшедший дом? Тестировщики общающиеся с бизнесом и разъясняющие задачи программистам?
Нельзя по хотелкам бизнеса начинать программировать, без предварительного проектирования, это будут бесконечные переделки даже у программ уровня "hello world"! А тут целый коллектив разработчиков, причём судя по уровню оплаты не бог весть какой квалификации.Viklim Автор
30.10.2024 08:21К сожалению есть и такие кейсы на рынке) Не могу назвать компанию т.к дискредитация не очень хорошая практика, но это реальный кейс когда нарушается коммуникация в команде. Во многом сказывается наш рынок
wolodik
30.10.2024 08:21Понятно что бывает по-разному, но по-моему в такой ситуации речь идёт не о том что не хватает аналитика на проекте, а вообще об отсутствии организации процессов, когда все заняты не своим делом. Тут просто чудесный рыцарь-аналитик в сверкающих доспехах не спасёт, он ещё и должен роли перераспределить, и много чего.
meirinkun
30.10.2024 08:21Статья из разряда - как с помощью воды потушить пожар.
Вот команда, она горит. В команде никто не пользуется водой, команда выгорает. Приходится нанимать новых, сроки не выдержаны.
Второй кейс - вот команда, они пьют воду и работают(+50 руб./бутылка). Издержки сокращены и команда не выгорела. Нанимаем в штат водовоза.
В ваших кейсах проблема в отсутствии профессионализма в организации работы команды и отсутствии подобия мыслительного процесса у самих участников команды, а не потому что у них в команде нет СА.
Почему разработчики начинают работу когда им сказали "Сделай приложение"? В такой ситуации любой вменяемый человек, который хоть немного думает (и даже какой-нибудь chatgpt), не говоря уже о профессиональном разработчике, начнет задавать вопросы ЗАКАЗЧИКУ или его представителям, чтобы хотя бы выявить требования. Я понимаю что это реальный кейс, когда они ходили к тестировщикам, но это какой-то нерелевантный мрак.
Тестировщик (он же QA - специалист по контролю качества разработки) должен тестировать работу разработчика, а не общаться с заказчиком и формулировать требования. Но опять же, даже если в такой команде тестировщик занимается требованиями, он, будучи, вменяемым человеком, как минимум должен их куда-то записать, чтобы потом передать разработчику (doc-first, так сказать).
И мои любимые скрам-мастера. Вся фасилитация команды лежит на них. Организация процесса взаимодействия лежит на них. Тем более, если его продали вместе с командой заказчику. И если вот эта схема "разработчик к тестировщику, а тестировщик к заказчику" его рук дело, тогда в неразработанном в срок приложении и увеличении бюджета виноват он. Ну и сам заказчик. У него, видимо, неограниченные бюджеты и довольно низкий уровень зрелости.
Если добавить в такую команду СА соответствующего уровня (непрофессионал с отсутствием способности думать), то он раздует бюджет, будет писать косноязычные требования с непонятными схемами, постоянно их менять и, по традиции этой команды, передавать их скрам-мастеру через директора, чтобы тот передал их тестировщикам, чтобы разработчики чувствовали себя комфортно.
Системный анализ - это не doc-first, это не miro-jira, не управление задачами, не назначение разработчиков и не поддержка команды от выгорания (what?). Это все административная работа, которую вы почему-то поручили СА.
Системный анализ - это мыслительный процесс анализа и синтеза систем, определение состава компонентов, их связей, границ, результата работы и прочего. Системный анализ - навык не только системного аналитика - им должен обладать любой участник команды, занимающийся разработкой ПО.
Иногда, в сложных системах подобной работы с системами необходимо довольно много, поэтому нанимают системного аналитика. Но в подавляющем большинстве случаев отдельный сотрудник для этого не нужен, достаточно профессионального разработчика/ПМ, который сможет задать вопросы заказчику.
Наличие системного аналитика в команде - не панацея от проблем и не всегда экономия ресурсов.
Тема с издержками ресурсов до появления СА и после не раскрыта совсем. На проектах/заказах любого ли масштаба расходы на СА (или нескольких СА) оправданы? Всегда ли наличие СА сокращает сроки и бюджеты? Может ли быть такое, что СА, выполняя свою работу, накопает нечто, что существенно увеличит стоимость проекта/заказа, а без СА такого бы не произошло?
Решения по ресурсам принимает не СА, соответственно не ему их экономить. Я как СА могу спроектировать систему, а человек с ресурсами на разработку не найдет их для моей системы. Поэтому в будущем придется потратить в два раза больше ресурсов. Системный анализ произошел, а экономии ресурсов нет.
Подытожу: системный анализ - must-have для любого человека.
Чем больше людей с таким навыком будут иметь отношение к разработке ПО, тем быстрее и за меньшие деньги это ПО будут разрабатывать (но это не точно).ps: Я сам СА. После прочтения вашей статьи, у меня такое чувство, что либо вы, либо у вас в компании не понимают что такое системный анализ и чем должен заниматься СА, либо в профессии произошел какой-то раскол. И снова придется объяснять команде, что я проектирую системы, а не занимаюсь поддержкой от выгорания...
JohnTR
30.10.2024 08:21Системный аналитик, к тому же, берёт на себя функции, о которых обычно забывают:
фильтрует поток сознания заказчика, задавая неудобные вопросы (как это будет выглядеть? из чего это считается? откуда будут данные и в каком формате? как нам это принять, разобрать и разложить? кто за что будет отвечать и где исходная документация очередной интегрируемой системы, Билли?)
придумывает невероятные ситуации и определяет места отказа нового функционала (слабые точки, в которые можно ткнуть хитроизогнутой палкой и всё сломать);
ограждает разработчиков от словесного поноса бизнеса (находит в море созвонов, переписок и намаханых руками абстракций суть, переводя в итоге с "бизнесового" на "программистский", формализируя требования бабуинов от маркетинга в читабельное человеками разумными ТЗ);
рассказывает бизнесу о том, что честно-честно были серьезные технические ограничения сделать именно так, как сделано (упоминая мимоходом, что у розового цвета на салатовом фоне есть тенденция уменьшать производительность труда на 37,6%);
держит в голове взаимосвязь всех прошлых, имеющихся и будущих компонентов своей системы и всяких смежных с ней, но рассказывает об этом только когда явно спросят (либо когда хотелка бизнеса ну совсем уже врастопырку вставляется во всё и так еле-еле пыхтящее).
Иначе говоря, системный аналитик - это человек-модем (матюгатор-дематюгатор), который может замкнуть на себя бизнес, разработчиков и тестировщиков, оградив первых от вторых и третьих (TODO: вписать здесь красивый пассаж о флуктуациях уровней "технического интеллекта"), но позволив им при этом коммуницировать.
СА умеет думать "как бизнес", "как разработчик" и "как тестировщик" одновременно. И доносить одну и ту же мысль, зная свою систему с фронта, бэка и вокруг, по разному в каждую из этих сторон, почти всегда имея ответ на любой спонтанный ВТФ-вопрос, откуда бы тот не прозвучал. А если нет ответа - пойдёт и задолбает тех, у кого он должен быть. Он знает людей, которые знают людей..
meirinkun
30.10.2024 08:21То что вы перечисляете - это не функции СА, которые он почему-то берет на себя - я не могу эти функции перечислить, например, в своем резюме.
У вас это набор ситуаций, с которыми СА столкнулся в своей работе.
"Фильтрация потока сознания заказчика" - это сбор и составление требований к системе. Это одна из базовых обязанностей СА, почему о ней забывают?
"Поиск невероятных ситуаций и мест отказов" - это вменямое моделирование процессов, которые будет обслуживать проектируемая система. Это также базовая обязанность СА, о ней нельзя забыть. Если забудешь, тебе напомнит QA, когда найдет будет составлять тест-кейсы.
"Ограждать от словесного поноса" - это не обязанность СА (представляю такую строчку в своем резюме), это обязанность ПМ выстроить коммуникации с клиентом правильным образом и не допускать подобных ситуаций. Т.е. не очень понятно, в чем провинился СА и почему выслушивание словесного потока должно быть его обязанностью.
"Рассказывать клиенту о честно-честно о принятых решениях" - так это тоже базовая обязанность, о ней нельзя забыть. СА должен спроектировать несколько вариантов решений, у них может быть разный состав, характеристики и трудоемкость, цена и пр.
"Держит в голове взаимосвязь всех прошлых решений" - это да, это нужно. Но лучше не в голове, лучше документацию писать:) И это тоже базовая обязанность СА, о которой просто нельзя забыть.
Думать "как бизнес" должна уметь вся команда. QA тестирует "как бизнес", разработчик переносит бизнес-объекты и процессы в код. Нет такого, что разработчики или QA говорят на своем "разработческом" или "куашном" и не понимают человеческий/бизнесовый язык. Они же тоже люди в конце концов.
Если на СА замыкается коммуникация всей команды, это не нормально, это никакого отношения к системному анализу не имеет. Я не видел ни одной книги, ни одного стандарта где было бы написано, что системный аналитик (или где сотрудник с навыком системного анализа) - это центр команды. Почему в центре не тимлид разработки или фронтэндер Петя? И главное почему это не ПМ, в чьи прямые обязанности менеджера входит управление проектом, для чего было бы неплохо свести коммуникации на себя, чтобы контролировать ход проекта?
Asterris
30.10.2024 08:21Ну ладно вам, друзья, не обижайте человека.
Он работает в казахском государственном телеком-операторе. А в таких компаниях бизнес-заказчик - это не равный тебе горизонтальный функционер, а живущий на небесах господин, которому перечить нельзя и вопросы задавать нельзя. А сам он слишком покрыт золотом, чтобы объяснять всякой черни детали своих гениальных хотелок.
Тут не аналитик нужен, а смена управленческой парадигмы. Но Алтел уже десять лет пытается свой кривой менеджмент поправить, да всё никак не выходит.
AlxndrPakhomov
30.10.2024 08:21Я не знаком с практикой ведения дел в Казахстане, но точно понимаю что заказчики в РФ грешат тем что не понимают до конца зачем они стартуют ту или иную активность, это даже не про требования а на шаг выше. Думаю тут тоже присутствует эта болезнь
mtekaef
30.10.2024 08:21Спасибо,Виктор,за статью.Вме четко ,понятно и по существу.Я сам педагог+ методист и я в очередной раз понял ,что правильно поданное знание всегда выходит за рамки какой определенной сферы и всегда "учит" всех .
AlxndrPakhomov
Очень интересно и наглядно показано, как системный анализ помогает оптимизировать работу команды и сэкономить ресурсы компании. Примеры и инструменты действительно полезны!
RestTiger
Надеюсь, это сарказм... :-)
AlxndrPakhomov
Верно(= я еще сформировал убеждение, что при старте любой задачи более-менее крупной обязательно задавать простой вопрос "Зачем?" или формировать финансово-экономическую модель. Часто видел как этот вопрос и ФЭМ не делается, это тоже приводит к тому, что на выходе результат не "очевиден")