Привет, Хабр! Меня зовут Татьяна Ошуркова, я разработчик и системный аналитик. Очень часто в докладах я рассказываю про выполнение смежных задач системным аналитиком. Но какие задачи входят в его обязанности сегодня?
Подписывайтесь на мой канал в Telegram, где можно найти больше полезных материалов и вебинаров.
В этой статье я разберу роль системного аналитика в команде, а также проблемы и задачи, о которых невозможно молчать которые актуальны в настоящий момент.
Начну с двух фактов:
-
Я и практически все коллеги на моем опыте выполняют множество абсолютно разных задач, которые точно выходят за пределы написания ТЗ и работы с требованиями.
-
Каждый раз, когда я упоминаю тестирование или написание кода системным аналитиком, мне задают много вопросов о том, должно ли это касаться аналитика.
Правда находится где-то в золотой середине между этим двумя фактами.
Системный аналитик – это специалист, который не только понимает работу системы с технической точки зрения. Он умеет прорабатывать логику работы системы, выстраивать сценарии её поведения, продумывать все варианты и учитывать большое количество аспектов. Это специалист, который занимается анализом и проектированием сложных систем, исходя из множества аспектов, в том числе бизнес-задач, ограничений системы, требований архитектуры, а также многого другого.
Когда я была в роли разработчика, часто у меня возникали вопросы по процессу, ограничениям, условиям или возникающим непредвиденным ошибкам. Я обращалась к аналитику, который волшебным взмахом руки прорабатывал возникающие проблемы и умел не только проанализировать бизнес-процесс, но и описать их техническим языком.
Системный аналитик, в отличие от других ролей, больше всего погружен в каждую из них. Он знает не только сами бизнес-процессы, но в то же время и их техническую реализацию. Безусловно, он может не знать, как написан код. Но он знает, что этот код выполняет. Какой результат мы должны ожидать, а какой нет после какого упадет прод.
Бизнес-анализ
Системный аналитик сейчас очень глубоко погружен в бизнес-процессы. Он знает не только сами процессы, но также и бизнес-цели своих задач и продукта в целом.
Это объясняется сложностью систем в настоящий момент. Для того чтобы четко выстроить сценарий поведения системы и проработать взаимодействие со смежными процессами, аналитику недостаточно понимать только техническую сторону. Он прорабатывает все сценарии работы реализованного функционала, исходя из выстроенных существующих, а также новых бизнес-процессов. Кроме того, он смотрит на систему не только, с точки зрения реализации функционала, а также и со стороны пользователя, что дает возможность глубоко проработать процесс.
Понимание бизнес-цели помогает избежать расхождения технической реализации с ожиданиями заказчика. Так как уровень сложности систем растет, бизнес-требования могут подразумевать под собой вариативность реализации, что может привести к расхождению с ожиданиями заказчиков.
В таком случае реализация во многом зависит от системного аналитика. Она зависит не только в качестве, непроработанные требования будут вести к переработке функционала, потере времени и ресурсов.
Разработка
Системный аналитик не пишет код. Но очень часто он погружен в техническую реализации практически на одном уровне с разработчиками. Сложность систем приводит к тому, что для проработки требований может быть недостаточно поверхностного понимания системы. Аналитик не только разговаривает с разработкой «на одном языке», но и очень часто работает с кодом.
Кроме того, большое количество микросервисов требуют грамотной проработки интеграций, а большинство интеграционных задач требуют технических навыков высокого уровня.
Есть отдельные направления, где аналитики выполняют задачи разработки. На моем опыте почти все аналитики могут написать хорошую выборку, а многие пишут скрипты для баз данных. Также работают с Python, даже применяют его для интеграционных задач.
Если перечислять хардовые навыки и инструменты, которыми пользуются аналитики уровня middle и senior, то можно говорить о том, что со сферой разработки они взаимодействуют крайне плотно, и решают задачи не только в части требований.
Тестирование
Аналитики не пишут тесты и не берут этап тестирования на себя. Но по моему опыту, они очень часто выполняют тестирование своего функционала.
Тестирование может выполнятся аналитиком параллельно с данным этапом для проверки описанной реализации. Практически всегда это не является прямой задачей аналитика, но может помочь выявить непроработанные возникающие ошибки.
В своей практике до определённого момента в роли разработчика и аналитика я считала, что моя обязанность – реализовать функционал. Его проверка являлась не моим этапом. Безусловно, я проверяла себя, но не искала множество кейсов и не тестировала все сценарии работы.
Позже я поняла, что моя ответственность есть всегда. Тестировщики или бизнес-аналитики, кто выполняет тестирование, не всегда максимально глубоко погружены в процесс, так как они видят систему не совсем с того «ракурса», с которого смотрят на нее разработчики или аналитики.
В любом случае перепроверить себя и убедиться, что сделанное твоими руками работает правильно, является хорошей практикой. Наша общая цель – это реализовать качественный продукт, а не снять с себя ответственность на определенном этапе.
Кроме этого, аналитики очень часто работают с поддержкой, выполняя задачи на второй или третьей линии. Они прорабатывают ошибки и ищут их причину. Здесь не обходится без тестирования, нахождения кейсов и воспроизведения проблематики.
Как найти подход к задачам
Если говорить про инструменты и навыки, то их можно перечислить огромное количество. Главное – это дать себе возможность расти. Задачи, которые на первый взгляд выходят за рамки обязанностей или имеющихся навыков – в первую очередь возможность роста. У меня не было ни одного навыка, который бы не пригодился мне повторно.
Очень важно развивать системное мышление. Оно помогает прорабатывать задачи на другом уровне. Чем глубже я погружаюсь в проработку процессов текущей задачи, тем выше качество проработки требований в следующей задачи.
Подведем итоги
Стать системным аналитиком – это не только уметь написать функциональные и нефункциональные требования. Это значит стать техническим специалистом высокого уровня, владеющим большим количество навыков и умением решать различные аналитические задачи при работе с со сложными системы.
Делюсь небольшой подборкой литературы, которая может быть полезна:
-
«Искусство системного мышления. Необходимые знания о системах и творческом подходе к решению проблем» Макдермотт Иан, Джозеф О’Коннор
-
«Книга решений. 50 моделей стратегического мышления» Микаэль Крогерус, Роман Чеппелер
-
«Чистая архитектура. Искусство разработки программного обеспечения» Мартин Роберт
-
«Пользовательские истории. Искусство гибкой разработки ПО» Джефф Паттон
Я желаю вам удачи в системном анализе и не только!
ссылка на оригинал статьи https://habr.com/ru/articles/853276/
Добавить комментарий