Привет, Хабр! Меня зовут Татьяна Ошуркова, я разработчик и системный аналитик. Очень часто в докладах я рассказываю про выполнение смежных задач системным аналитиком. Но какие задачи входят в его обязанности сегодня?

Подписывайтесь на мой канал в Telegram, где можно найти больше полезных материалов и вебинаров.

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

Начну с двух фактов:

1. Я и практически все коллеги на моем опыте выполняют множество абсолютно разных задач, которые точно выходят за пределы написания ТЗ и работы с требованиями.

2. Каждый раз, когда я упоминаю тестирование или написание кода системным аналитиком, мне задают много вопросов о том, должно ли это касаться аналитика.

Правда находится где-то в золотой середине между этим двумя фактами.

Системный аналитик – это специалист, который не только понимает работу системы с технической точки зрения. Он умеет прорабатывать логику работы системы, выстраивать сценарии её поведения, продумывать все варианты и учитывать большое количество аспектов. Это специалист, который занимается анализом и проектированием сложных систем, исходя из множества аспектов, в том числе бизнес-задач, ограничений системы, требований архитектуры, а также многого другого.

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

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

Бизнес-анализ

Системный аналитик сейчас очень глубоко погружен в бизнес-процессы. Он знает не только сами процессы, но также и бизнес-цели своих задач и продукта в целом.

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

Понимание бизнес-цели помогает избежать расхождения технической реализации с ожиданиями заказчика. Так как уровень сложности систем растет, бизнес-требования могут подразумевать под собой вариативность реализации, что может привести к расхождению с ожиданиями заказчиков.

В таком случае реализация во многом зависит от системного аналитика. Она зависит не только в качестве, непроработанные требования будут вести к переработке функционала, потере времени и ресурсов.

Разработка

Системный аналитик не пишет код. Но очень часто он погружен в техническую реализации практически на одном уровне с разработчиками. Сложность систем приводит к тому, что для проработки требований может быть недостаточно поверхностного понимания системы. Аналитик не только разговаривает с разработкой «на одном языке», но и очень часто работает с кодом.

Кроме того, большое количество микросервисов требуют грамотной проработки интеграций, а большинство интеграционных задач требуют технических навыков высокого уровня.

Есть отдельные направления, где аналитики выполняют задачи разработки. На моем опыте почти все аналитики могут написать хорошую выборку, а многие пишут скрипты для баз данных. Также работают с Python, даже применяют его для интеграционных задач.

Если перечислять хардовые навыки и инструменты, которыми пользуются аналитики уровня middle и senior, то можно говорить о том, что со сферой разработки они взаимодействуют крайне плотно, и решают задачи не только в части требований.

Тестирование

Аналитики не пишут тесты и не берут этап тестирования на себя. Но по моему опыту, они очень часто выполняют тестирование своего функционала.

Тестирование может выполнятся аналитиком параллельно с данным этапом для проверки описанной реализации. Практически всегда это не является прямой задачей аналитика, но может помочь выявить непроработанные возникающие ошибки.

В своей практике до определённого момента в роли разработчика и аналитика я считала, что моя обязанность – реализовать функционал. Его проверка являлась не моим этапом. Безусловно, я проверяла себя, но не искала множество кейсов и не тестировала все сценарии работы.

Позже я поняла, что моя ответственность есть всегда. Тестировщики или бизнес-аналитики, кто выполняет тестирование, не всегда максимально глубоко погружены в процесс, так как они видят систему не совсем с того «ракурса», с которого смотрят на нее разработчики или аналитики.

В любом случае перепроверить себя и убедиться, что сделанное твоими руками работает правильно, является хорошей практикой. Наша общая цель – это реализовать качественный продукт, а не снять с себя ответственность на определенном этапе.

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

Как найти подход к задачам

Если говорить про инструменты и навыки, то их можно перечислить огромное количество. Главное – это дать себе возможность расти. Задачи, которые на первый взгляд выходят за рамки обязанностей или имеющихся навыков – в первую очередь возможность роста. У меня не было ни одного навыка, который бы не пригодился мне повторно.

Очень важно развивать системное мышление. Оно помогает прорабатывать задачи на другом уровне. Чем глубже я погружаюсь в проработку процессов текущей задачи, тем выше качество проработки требований в следующей задачи.

Подведем итоги

Стать системным аналитиком – это не только уметь написать функциональные и нефункциональные требования. Это значит стать техническим специалистом высокого уровня, владеющим большим количество навыков и умением решать различные аналитические задачи при работе с со сложными системы.

Делюсь небольшой подборкой литературы, которая может быть полезна:

• «Искусство системного мышления. Необходимые знания о системах и творческом подходе к решению проблем» Макдермотт Иан, Джозеф О'Коннор

• «Книга решений. 50 моделей стратегического мышления» Микаэль Крогерус, Роман Чеппелер

• «Чистая архитектура. Искусство разработки программного обеспечения» Мартин Роберт

• «Пользовательские истории. Искусство гибкой разработки ПО» Джефф Паттон

Я желаю вам удачи в системном анализе и не только!