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

В этой статье расскажу, куда может привести работа системного аналитика.
Кто такой системный аналитик
Начну с того, кто такой системный аналитик.
Что бы не говорили про границы ответственности, системный аналитик на проекте - эдакий универсальный боец, который общается со всеми, начиная от заказчиков и заканчивая тестировщиками. Это тот самый человек, который ведет требования от их возникновения до сдачи в виде фич заказчикам со стороны бизнеса.
В самом начале карьеры аналитик только описывает требования с технической стороны (сами требования ставит заказчик). А я начинала вообще с позиции консультанта. Я выросла в небольшом городе и начинала работать в достаточно крупной локальной консалтинговой компании. Там не было такого понятия, как аналитик. Консультанты же занимались всем - внедрением, технической поддержкой и даже немного продажами. Консультанты много общались с клиентами, собирали их замечания и пожелания. Кроме того, участвуя в поддержке, видели, что в продукте можно улучшить - так или иначе все это выливалось в ТЗ для разработки.
Честно говоря, мне уже тогда нравилось описывать эти новые фичи и требования к ним. Мой начальник на тот момент подсказал, что есть такая профессия, как системный аналитик, порекомендовал покопать в ту сторону. На следующее место работы я перешла уже в статусе аналитика.
Уже на этом этапе аналитику важно знать и понимать:
-
методологии разработки ПО;
-
основные принципов ООП;
-
что такое варианты использования (use cases);
-
что такое UML и уметь применять различные диаграммы на практике;
-
различать функциональные и нефункциональные требования и уметь их описывать;
-
а еще нужно быть коммуникабельным, уметь проводить встречи;
-
управлять состояниями требований.
По мере получения опыта аналитику приходится брать на себя все больше ответственности, сталкиваться с задачами от бизнеса, вроде выявления рисков, прогнозирования дальнейшего развития сервиса и т.п. А параллельно ему надо налаживать межсистемные взаимодействия, т.е. постоянно общаться с коллегами из других команд. Все это скорее управленческие задачи. Но и о технических задачах забывать нельзя - надо погружаться в архитектуру проекта, учиться ее строить и давать оценку, рассчитывать нагрузку сервисов, думать о стратегии развития API-шек.
На практике такой список компетенций означает, что с одной стороны ты рисуешь много схемок, а с другой - постоянно пропадаешь на митингах, работая как менеджер. Бывают дни, когда у тебя в календаре по 6-7 встреч, и тебе просто тяжело уже переключаться между ними. Только что обсуждал одно, а теперь надо срочно переходить к обсуждению чего-то другого.
И в этот момент ты начинаешь задумываться, что эдакий разрыв в компетенциях - технических и управленческих - не очень-то комфортен. Задач много, ответственности - тоже, везде нужно все успевать. Чтобы это стало комфортнее, надо выбрать либо одно, либо другое. Так и появляется вопрос, куда идти дальше.
Путь в управленцы
Первый логичный путь - развиваться в направлении менеджерства, примеряя на себя роль product owner и полностью погружаясь в продукт уже со стороны бизнеса. Переместившись на эту позицию, необходимо будет развивать продукт и презентовать его. Возможно, даже продавать, полностью определяя стратегию его развития.
Навыки для старта:
-
управление изменениями и рисками;
-
основы работы с бюджетом;
-
планирование;
-
решение проблем как внутри команды, так и со смежными командами.
Путь в технари
Второй возможный путь - прокачивать технические компетенции. Стать архитектором, но не системным, который строит разработчиков и указывает, как правильно писать код, а кем-то вроде solution архитектора, который рисует схемы компонентов. Это довольно молодая и востребованная профессия. Причем, кажется, что в нее надо именно вырастать на своем рабочем месте. Надо немного перерасти статус аналитика и посмотреть на проект с другого масштаба - сверху, глубже и шире.
Лично мне интереснее это направление, поскольку в управлении довольно много политики.
Мне повезло - на соседнем проекте планируется рефакторинг архитектуры, точнее старый бизнес-процесс будем перезапускать на полностью новой архитектуре, так что у меня есть шанс попрактиковаться в ее построении. Проектом мне предстоит заниматься вдвоем со старшим системным архитектором. Он будет курировать сервис со стороны технической части (кода), а я - со стороны проектирования компонентов, моделей и графиков.
Шанс самостоятельно построить архитектуру выпадает не часто - надо либо прийти на новый проект, который только разрабатывается, либо найти тот, где нужны масштабные переделки.
Навыки для старта:
-
более глубокое погружение в паттерны архитектуры;
-
управление требованиями и построение архитектуры в масштабе всей системы (а не только своей части);
-
более продвинутые навыки коммуникаций.
Путь в лиды
Третий вариант - если ты давно на проекте и тебя все устраивает, можно постепенно становиться лидом аналитиков. По мере того, как приходят новички, их нужно погружать в работу. По сути это путь наставничества - тимлида или техлида аналитики. И здесь в большей степени нужны качества HR, когда нужно с удовольствием взаимодействовать с коллегами и рассказывать им о том, как все работает.
Думаю, мне был бы интересен и этот путь. На прошлой работе у меня уже был опыт погружения новых аналитиков в проект. Мне нравится помогать, отвечать на вопросы по продукту, выстраивать процессы работы с документацией. Но конкретно на моем проекте он по некоторым причинам для меня закрыт.
Для старта надо:
-
продолжать развивать навыки общения и донесения информации;
-
развивать навыки наставничества;
-
погружаться в выстраивание и улучшение процессов аналитики;
-
развивать умение мотивировать сотрудников;
-
прокачивать делегирование и распределение ответственности.
А что еще?
Мне кажется, есть некоторое количество компетенций, которые надо прокачивать всегда - они в любом случае помогут, вне зависимости от направления развития.
Во-первых, надо стараться структурировать свою работу - раскладывать все по полочкам, расписывать все процессы. Все, с чем разбираешься, желательно описывать и рисовать диаграммы. Это всегда помогает, причем, не только тебе, но и кому-то другому, если ему придется в этом разбираться.
Во-вторых, надо стремиться просто хорошо выполнять свои обязанности. Только так можно показать, что тебе можно доверять, и рассчитывать в будущем на более серьезные проекты, в какой бы сфере они не находились.
В-третьих, надо учиться коммуницировать с людьми. Работа системного аналитика в принципе подразумевает много коммуникаций, но я здесь имею в виду прочее общение - внутри команды и со своими руководителями. Например, я озвучивала своему непосредственному руководителю, куда бы хотела расти. Это помогает достигать своих целей.
И помните, в вашей работе всегда можно что-то улучшить.
Автор статьи: Света, Максилект.
P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на нашу страницу в VK или на Telegram-канал, чтобы узнавать обо всех публикациях и других новостях компании Maxilect.
Автор: Maxilect