Куда развиваться системным аналитикам в 2024 году

Системный аналитик в базовом представлении — человек, который пишет ТЗ и переводит с «бизнесового» на «разработческий». Но сегодня из-за распространения гибких методологий сам системный анализ кажется не таким важным — или вовсе лишним. Так ли это в действительности? Разбираемся в теме вместе с хедами профессии системного анализа Газпромбанка Юлией Григорьевой и Марией Долгушиной.

Статья сделана по подкасту «Техно.Логично». Переходите по ссылке, чтобы послушать полную версию. Кстати, там эксперты Газпромбанка обсуждают еще много интересных тем. 

В современных командах роль системного аналитика снижается

Она появилась как типичная часть заказной разработки, когда заказчик формулировал требования, а подрядчик их выполнял. Добавить что-то после подписания контракта, где оговорены сроки, сумма, объем работ, было дорого и сложно. Этого старались избежать, поэтому и появились системные аналитики, которые очень подробно прорабатывали ТЗ.

Три года назад, когда я пришла в Газпромбанк, было что-то похожее. Отделы аналитики и разработки жили отдельно друг от друга. У нас были своя зона ответственности, свои правила взаимодействия с разработчиками — как раз через документацию. Разработчики просили, чтобы мы писали ее правильно, подробно — и они могли сразу прочитать и реализовать требования. Но это в прошлом.

Юлия ГригорьеваГазпромбанк

Но сейчас, когда компании занимаются инхаус-разработкой, потребность в системных аналитиках снижается — потому что реагировать на меняющиеся требования гораздо проще: не нужно мучиться с договорами и пересогласовывать каждый шаг.

К тому же все работают в agile-командах, где очень тесно друг с другом взаимодействуют. Разрыв между продакт-оунером и разработчиком гораздо меньше, как следствие, потребность в связующем звене ниже. И переводить «с бизнесового на технический» уже не всегда надо — в кросс-функциональных командах заказчики и разработчики неплохо понимают друг друга.

Получается, что системный аналитик остается не у дел, если вся его компетенция — работа с требованиями. Но он может помогать продакту качественно декомпозировать задачу, погрумить бэклог, оформить постановки в таск-трекере. Или написать техническую документацию, чтобы новичкам было проще разобраться в системе.

Документация — ТЗ в том числе — в привычном виде уже не так важна

Обычно ТЗ — это много-много текста, который описывает все, что должна делать система. Зачастую этот текст потом используется как техническая документация — описание того, что система фактически делает. Но мы с вами знаем, что это не всегда верно. Документация может врать, может описывать фичи, которые еще не ввели, или устаревшие версии — а не текущее состояние. Но все закрывают на это глаза и продолжают говорить, что документация в привычном виде очень-очень нужна.

Мы в команде практически отказались от такой документации. Расскажу подробнее.

Юлия ГригорьеваГазпромбанк

Года полтора назад в текущем составе сформировался стрим «Ипотека». Практически вся функциональность, связанная с основной системой, которую развивает наша команда, разрабатывалась на аутсорсе. И к сожалению, документация практически не сохранилась. Мы очень хотели восстановить ее и прежний порядок работы: проектируем решение, разрабатываем ТЗ на основании имеющейся документации (выделяя цветом изменяемый функционал), при этом восстанавливаем недостающую документацию. На основании этих требований разработчики пишут код.

После того как задачу взяли в работу, прошло несколько спринтов, но «пощупать» продукт и убедиться в его эффективности мы все еще не могли — на руках у нас было только ТЗ. И тогда мы задумались о том, а действительно ли ТЗ — необходимая часть для старта разработки.

С одной стороны, мы привыкли, что после реализации фичи у нас остается документация в виде ТЗ, в которую люди из разных команд могут зайти, почитать, разобраться в продукте/системе. Но с другой, в одной из систем есть, например, BPM-схема Camunda, которая сама по себе является документацией. Внутри нее есть сервис-таски и юзер-таски, в которых мы оставляем комментарии. Есть комментарии в коде и так далее. Почему бы не использовать?

Так, мы с ИТ-лидом стрима начали продумывать план технических задач, которые помогут отказаться от тяжеловесной документации. На текущий момент мы восстановили все спецификации AsyncAPI сервисов, сделали рефакторинг всех BPM-схем Camunda, добавив к каждому элементу схемы дополнительное описание, наполнили БД всех сервисов комментариями к атрибутам и таблицам. Процесс еще идет, но эта идея уже позволила нам отказать от полномасштабной документации.

В целом мы бы хотели в большинстве случаев видеть именно такую документацию — максимально близкое к коду или генерируемое из кода. В большинстве случаев исчерпывающие файлы в Confluence/Word может заменить генерируемая из кода документация на основе комментариев.

Еще мы сейчас тестируем PlantUML — один из инструментов Docs as Code. Делаем небинарный файл, кладем в систему контроля версий и работаем, как с кодом. Так, аналитики вносят изменения в IDE, которая поддерживает плагин, делают пуш, ставят пул реквест. И в ближайшем релизе разработчики заливают их на прод вместе со своим кодом. Все это остается лежать в репозитории, рядом с кодом сервиса. И каждый может зайти и познакомиться с описанием функционала системы.

Может показаться, что мы призываем вовсе отказаться от документов — а системный аналитик (или другой специалист, выполняющий его функции) пусть бегает по задачкам в Jira и собирает информацию о том, как все работает. На деле пойнт в другом — эти большие и сложные документы, которые мы пишем, нужны не разработчикам, а бизнесу, внешним подразделениям. И их создание, подготовка и согласование не должны тормозить написание кода.

Юлия ГригорьеваГазпромбанк

Из-за этого работа системного аналитика становится более технологичной

Расскажу, как профессия меняется у нас, в Газпромбанке

Мария ДолгушинаГазпромбанк

Еще недавно спецификации: OpenAPI, AsyncAPI и прочее — писали только разработчики (если писали), А сейчас мы в компании полным ходом в это погружаемся. Например, активно внедряем API First. Его суть в том, что мы изначально пишем спецификацию в YAML или JSON и передаем разработчикам поставщика и потребителя сервиса. Любая команда может взять ее за основу и сгенерировать код.

Да, для этого нужно, чтобы во всех системах были одни инструменты генерации кода из YAML, и сами YAML-ы писались по единому стандарту. Но мы таким образом экономим время и силы разработчиков, потому что существенная часть кода появляется сама собой.

Из-за всего этого аналитики, которые работали много лет, должны снова становиться джунами, например, в части работы с Git: делать первый коммит, пул реквест, выяснять, как это все работает. Это может быть очень страшно и некомфортно. Мне самой было сложно, но я просила помощи и получала ее.

Из-за смещения роли аналитика ближе к коду, меняются и требования к кандидатам. Растет порог входа в профессию, и мы, как наниматели, рассчитываем, что у системного аналитика будет примерное понимание того, что такое архитектура, что такое API, как формировать простые SQL-запросы. Рассчитываем, что он готов к трансформациям и интересуется смежными ролями (разработчика, архитектора и так далее). А со своей стороны предлагаем обучение нужным техническим скилам.

Аналитики боятся, что станут совершенно не нужны, и их уволят. Но будущее у профессии есть — и классное

Вряд ли профессия пропадет ближайшем будущем. До сих пор в крупных компаниях есть зоопарки систем, в которых нужно очень подробно разбираться. И системный аналитик выступает таким «проводником в темном лесу». Кроме того, она будет становиться все более и более технологичной, и аналитики продолжат погружаться в код и применять инженерные практики.

Про далекое будущее сказать сложнее. Может быть, будет некое объединение бизнес-аналитиков, системных аналитиков, UX-аналитиков, продуктовых аналитиков, и мы получим неких универсальных аналитиков, которые смогут решать большой спектр задач. А может быть, наша роль станет совсем иной. Станем писать только запросы для нейросетей: загружать задачи из бэклога и получать готовый код.

Но перспективы у профессии в любом случае есть.