А вдруг я не системный аналитик? Советы начинающим специалистам

Привет Хабр! Меня зовут Татьяна Ошуркова, я разработчик, аналитик и автор телеграм-канала IT Talks. В своем опыте я успела попробовать себя в разных ролях, поработать с различными системами и продуктами. Когда менялись мои задачи, круг обязанностей, технологический стек, если такие изменения были впервые, то в начале я всегда ловила себя на одних и тех же мыслях: «Что делать? Как лучше? А что если…?».

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

С чего начать

В работу пришла объемная задача. Предположим, я еще плохо понимаю бизнес-процессы, а также не сталкивалась ранее с некоторыми техническими аспектами функционала, с которым предстоит работать.

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

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

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

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

Как правильно сформулировать требования

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

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

2 декабря я проведу бесплатный вебинар: «Построение диаграмм. Цели и задачи визуализации данных», где подробно разберу, как эффективно использовать различные виды диаграмм для описания требований. Запись на вебинар доступна по ссылке.

Конкретика. Я нередко ловила себя на мысли: «Дальше понятно». Возможно, это деформация совмещения ролей системного аналитика и разработчика, когда кажется, что если дальнейшие технические шаги реализации построены в моей голове, то и остальным это будет понятно. Это крайне неверно. Даже описание простого функционала при неправильной формулировке требований может быть прочитано по-разному. Недопонимание, двусмысленность, неопределенность – это то, что ведет к ошибкам и потере времени. Требования должны быть четкими, однозначными и учитывать все варианты поведения системы, а также возможные ошибки.

Как найти общий язык

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

Аналитику крайне важно уметь общаться, обсуждать и задавать вопросы. Вопросы нужно грамотно сформулировать. После встреч я нередко ловила себя на том, что заданный вопрос не охватывал всю проблему, и его можно было дополнить чем-то вроде: «А что если…? Что делать в случае…?».

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

Как разобраться в сложной системе

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

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

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

Это не только может помочь в понимании системы. Использование новых навыков и инструментов будет плюсом в развитии и точно пригодится в работе.

Как освоить бизнес-процессы

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

Но кроме этого, мне помогает тестирование реализованного функционала. Необязательно описанного вами. Это может быть поиск подходящих кейсов и воспроизведение описанных сценариев. Также можно воспроизвести альтернативные сценарии, которые могут быть не описаны, но затронуты пользователем. Кроме этого можно на практике проверить взаимосвязь и влияние на сторонние процессы.

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

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

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

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

Удачи в системном анализе и решении задач!