Как я стала системным аналитиком

Меня зовут Соня, и в 20 лет я стала самым молодым системным аналитиком в отделении крупного российского банка.

Я живу в Саратове, войти в ИТ хотела еще со школы. В 2018 году поступила в СГУ имени Чернышевского на факультет системного анализа и управления. Но не могу сказать, что вуз как-то помог в карьере. Совершенно бесполезные академические знания, никак не связанные с рыночным представлением о профессии системного аналитика, и шуточки преподавателей, что на работу возьмут только официанткой, оставили не самое приятное впечатление.

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

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

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

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

Один из абзацев был посвящен системным аналитикам. Это ИТ-специалисты, которые отвечают за сбор и анализ требований к сервису, приложению или сайту, проектируют технические решения и ставят задачи команде разработки.

Для меня это стало любовью с первого взгляда: я нашла что-то на стыке технаря и гуманитария! Еще и с приятной средней зарплатой 180 тысяч рублей. При взгляде на цифры оставшиеся сомнения исчезли.

В 2018 году я подала документы в СГУ имени Чернышевского, выбрав на бакалавриате специальность «системный анализ и управление». Параллельно получала в этом же университете второе высшее образование и училась на переводчика — правда, скорее для того, чтобы не забывать английский.

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

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

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

На втором курсе начала искать работу. Разумеется, хотела в ИТ, вот только нужно было найти что-то на неполный рабочий день. Друг рассказал о наборе в поддержку «Яндекса», и я решила попробовать: привлекала возможность начать свою карьеру с крупной корпорации.

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

Зарплата рассчитывалась по числу закрытых задач. Ее начисляли на специальный счет в «Яндекс-валюте», а каждые две недели переводили в рубли по курсу, который устанавливала компания. В месяц выходило 20—30 тысяч рублей, и для студентки из Саратова этого было более чем достаточно.

Конечно, не все было так радужно. С приходом ковида зарплату начали урезать. Впоследствии ребят на аналогичные должности нанимали за 7 тысяч рублей в месяц. Да и в целом поддержка, как и любая сфера услуг, — это постоянная работа с негативом.

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

Летом 2021 года, перед последним, четвертым курсом, я взяла отпуск в «Яндексе» и принялась искать стажировку на позицию системного аналитика. Поиск был хаотичным: я искала объявления на порталах с вакансиями и откликалась на все подходящие предложения. Большая часть компаний не отвечала или отказывала.

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

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

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

Из этого списка я не знала ни одного пункта, так что пришлось в срочном порядке изучать весь материал самостоятельно. Никаких масштабных курсов я бы не успела пройти, поэтому начала штудировать просторы интернета. У меня не было понимания, где хорошая информация, а где — нет. Я просто открывала «Ютуб» и первые попавшиеся статьи, а затем составляла конспект на каждый пункт списка и заучивала его наизусть.

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

Собеседование немного напомнило игру: предлагали представить, что ты сделаешь в той или иной ситуации. Еще давали задачи на логику из серии: «Все арбузы — это коровы, а все коровы красные. Значит ли это, что все арбузы красные?»

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

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

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

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

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

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

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

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

Любой продукт проходит через шесть фаз:

1. Сбор и анализ требований.
2. Документирование требований.
3. Дизайн.
4. Разработку.
5. Тестирование.
6. Внедрение и поддержку.

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

Наш герой-следователь заводит дело и выезжает на место преступления. А я завожу задачи в трекере YouTrack для описания техзадания.

Затем начинается активная работа на месте преступления: поиск улик, а в моем случае — процессов и похожих кейсов; опросы свидетелей — заказчика, других аналитиков, тестировщиков, разработчиков и коллег из смежных систем.

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

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

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

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

Финал — внедрение и поддержка продукта, то есть эксплуатация. Тут тоже без системного аналитика не обойтись! Бывает такое, что во время пользовательской эксплуатации возникают ошибки. Именно системный аналитик должен передать информацию команде поддержки и при необходимости привлечь разработчиков к решению бага.

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

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

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

В 10:15 у нас обязательное ежедневное совещание с коллегами-аналитиками. Обсуждаем, кто что делал вчера и какие у кого планы на сегодня. Иногда на них весело.

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

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

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

Я не обедаю, вместо этого 15 минут хожу вокруг офиса в качестве перезагрузки. Завершать день стараюсь нудной, но необходимой работой: например, рисую схемы бизнес-процессов или заношу данные в отчет.

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

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

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

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

Методология разработки определяет порядок выполнения задач, методы оценки и контроля. Бывают разные виды: waterfall, спиральная, итеративная, инкрементная, V-образная, RAD и, конечно же, одна из самых популярных, актуальных и удобных — Agile. Между собой они различаются подходом к постановке задач, контролю результата и тем, насколько четко сформулированы требования к продукту.

Не буду подробно описывать различия между ними — кажется, для этого потребуется отдельная статья. На работе я использую Scrum — это методология разработки, которая основана на философии Аgile. По моему мнению, она наиболее комфортна для работы с программным обеспечением.

Советую:

• книгу «Руководство по Scrum» Кена Швабера и Джеффа Сазерленда;
• книгу «Канбан. Альтернативный путь в Agile» Дэвида Андерсона;
• книгу «Impact Mapping. Как повысить эффективность программных продуктов и проектов по их разработке» Гойко Аджича;
• курс «Постановка задачи на разработку ПО»;
• мультик, который за пять минут расскажет о самом популярном фреймворке разработки ПО, — для самых ленивых.

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

Рекомендую книги:

• «Разработка требований к программному обеспечению» Карла Вигерса и Джоя Битти;
• «Пользовательские истории. Искусство гибкой разработки ПО» Джеффа Паттона;
• «Современные методы описания функциональных требований к системам» Алистера Коберна.

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

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

Рекомендую:

• книгу «Введение в UML. Краткое и информативное пособие по основам UML-моделирования» Мартина Фаулера — это наиболее популярный труд по моделированию бизнес-процессов, читается максимально легко и просто;
• курс лекций «Введение в программную инженерию» Дмитрия Кознова;
• графический редактор draw.io для отработки навыков на практике. Он создавался для построения диаграмм бизнес-процессов, и в него изначально загружены самые популярные фреймворки, чтобы моделирование процессов занимало минимум времени.

Базы данных и умение составлять SQL-запросы. Это нужно для систематизации информации и мгновенного поиска. К примеру, относительно недавно мне нужно было найти все актуальные документы, хранящиеся в базе, — один запрос, и готово!

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

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

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

• «От монолита к микросервисам» Сэма Ньюмена;
• «Шаблоны интеграции корпоративных приложений» Грегора Хопа и Бобби Вульфа;
• «BABOK. Руководство к своду знаний по бизнес-анализу. Версия 3.0» — это гайд, который разработал Международный институт бизнес-анализа.

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

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

Разумеется, я не могу не думать о дальнейшем развитии, поэтому регулярно читаю книги и статьи по своему профилю. Например, есть интересные телеграм-каналы «Бизнес-анализ & ИТ», «Physics. Math. Code» и «Business Analysis Magazine chat». Иногда хожу на вебинары, чтобы послушать коллег из других компаний. Советую новичкам в профессии доклады с конференции по системному и бизнес-анализу Analyst Days.

В моей компании есть такая штука, как ИПР — индивидуальный план развития, который ты обсуждаешь с тимлидом и руководителем. Довольно распространенная история в ИТ: приходишь на встречу, говоришь, чего бы тебе хотелось, получаешь обратную связь и вместе с более опытными коллегами составляешь план.

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