День системного аналитика: от дейли до «теперь питание компьютера можно отключить»

Иногда работа системного аналитика — это как езда на велосипеде, который горит, и ты горишь, и все в огне.

Но у меня другой стиль.

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

Меня зовут Ольга, и я работаю системным аналитиком в Газпромбанке.

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

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

Зачем вообще нужен системный аналитик?

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

Что я делаю? В мои функции входит и анализ процессов, их автоматизация, разработка решений и их развитие. И многое другое. Я и разработчик, и тестировщик, и Шерлок Холмс.

Мой рабочий день

Утро — самое продуктивное для меня время.

У команды плавающий график, а ещё мы почти все работаем удалённо. Коллеги могут начинать свой рабочий день позже часа на 2–3. Я этим активно пользуюсь. Нет никаких звонков. Встречаю новый день крепким кофе, отвожу детей в школу — и за работу. С 08:00 до 10:30 можно многое сделать, пока остальные только подключаются. Если постараться, то за эти пару часов можно успеть закрыть 80% дел, а творческие задачи тем более требуют погружения и уединения.

Чаще всего я успеваю.

Запускаю своё рабочее окружение, которое понадобится в течение дня. Быстренько пролистываю письма, чтобы понять нет ли там чего-либо срочного. Открываю Jira: не свалились ли туда внешние запросы? Первым делом хорошо заняться какой-то из крупных задач, которые у меня в спринте. Здесь нужно как следует подумать. Изучаю белые пятна, потихоньку начинаю понимать, что там и где, зарисовываю «точки помощи». Потом по этим рисункам будет проще сделать описание.

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

И вот утро заканчивается. Ну что. Привет, моя рутина. Синхронизация, переписка, созвоны и всё прочее.

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

А также у каждого есть возможность выступить с двухминутным мини-отчётом. Что сделали и что собираются делать дальше. Если, например, Product Owner осознаёт, что его представление задачи как-то отличается от услышанного, то даёт моментальный фидбэк. «Стоп, стоп, — говорит он. — Сегодня мы в эту сторону не едем. Там ремонт дороги! Все поворачиваем направо». Ну ладно. Меняем маршрут, значит. Всё проговариваем. Синхронизируемся, приходим к единому пониманию.

Основные задачи дня

Днём большую часть рабочего дня у меня занимает общение с командой — это около 60% времени. Остальное — это, собственно, аналитическая работа. То есть разработка документов, схем, рисунков.

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

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

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

Все мы сидим по разным городам. Я расшариваю свои рисунки (ранее созданные, помним, да?) и прямо во время разговора вожу по ним стрелочкой. Так, смотрим внимательно! Вот это сюда, это — туда, а это так и так. Ясно? Смотрите задачу, этот рисунок уже приложен к ней! Хм, ну и что. Тестировщик всё равно хочет уточнить, правильно ли он всё понял. Ещё раз, на всякий случай. Ему это нужно для психологической уверенности. Ладно, давайте. Мне нравится разжёвывать то, в чём сама уже разобралась.

Работа с бизнес-аналитиком

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

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

Тестирование — это моё или не моё?

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

Почему же я считаю, что аналитик должен самостоятельно уметь тестировать? Очень просто. Я отвечаю за свою задачу, за её постановку. Как я могу сказать, каким образом это работает, если я этого не вижу? До тестирования я обязательно проверю пару положительных сценариев в задаче, чтобы убедиться в работоспособности основы. А вот негативные тесты и всё остальное пусть запускают тестировщики.

И зачем мне это, если я даже не всегда оставляю комментарии об этом в задаче? А вот зачем. Это нужно для моего же спокойствия. Если, например, после разработки нового метода, ко мне придут «соседи» и скажут: «Мы хотим взять у вас метод. Это работает?», я не буду сомневаться. Я сразу скажу, что это работает вот так, как, собственно, и записано в документе.

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

Аналитик как структурированный писатель

На подготовку документов у меня остаётся примерно 40% времени. Хотя и для этого необходимо общение, чтобы получить поддержку или больше информации. Поэтому эти 40% достаточно условные, часть из них я трачу на переписку и разговоры.

Результатом такой деятельности становится красиво оформленная, понятная, структурированная информация.

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

Лучше всего в виде блок-схем, чтобы разработчику было легко реализовать задачу. Все микросервисы надо выстроить в красивый ряд и показать, что и с чем работает. У нас, кстати, только внутренних микросервисов около 90.

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

У меня сейчас в работе задача, непохожая ни на одну из прежних. Это написание нового микросервиса по принципу API First. Мне пришлось прямо заставить себя ею заняться. Для меня это выход из «уютного» состояния, в котором я давно освоилась, шаг на неизведанную почву.

Здесь мы сначала описываем весь API в YML-документе. Я создаю все компоненты будущих API, URL. Там же внутри него делаю комментарии с отсылкой к новой структуре базы. Описываю, какой компонент к какой группе принадлежит и от какой получает информацию. Потом передаю разработчику этот YML-файл. Он заряжает его в Generated Data и сразу получает часть кода. До этого мы много писали структуру в формате JSON, описывали словами или табличкой. Теперь, наоборот, описания нет, но есть сам API.

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

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

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

Завершение рабочего дня

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

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

Например, когда я писала API First, мне не нравилось одно место: параметр, который ломал всю структуру. А я привыкла, чтобы было красиво. Но не переделывать же всё. Я закончила работу, отложила проблему на завтра, но она продолжила вертеться в голове. Я пошла мыть посуду, и внезапно пришло решение. Я решила вынести компонент в другую структуру или на два шага выше. На следующий день проверила — ничего не мешает и не конфликтует. Цепочка JSON-ответа стала прямой и изящной, прямо как я люблю.

Казалось бы, где задача и где посуда.

Если видишь результат, когда долго мучаешься с чем-то, а потом-таки решаешь проблему — это и есть хороший рабочий день.

Возможности для аналитика в банке

Для меня сейчас самое главное — укрепиться в системной аналитике. Научиться новым фишкам. Т.е. въехать во все тонкости моей специальности.

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

У нас в банке есть все возможности для повышения своего уровня. Постоянно приходят приглашения на митапы и семинары. Есть опция ездить на Analyst Days (это большая международная конференция аналитиков).

В банке мы проводим еженедельные «Аналитические чтения». Это мероприятие для узкого круга, когда собираются аналитики управления рисками — пять-шесть человек, глубоко погружённых в тему. Что-то типа брейнсторма. Мы откладываем свои дела и решаем проблему одного человека. И так помогаем каждому по очереди. При этом у нас есть лидер, если мы все вместе заиграемся, он может сказать: «Ну всё, хватит, вас занесло. Давайте думать в другую сторону».

Но бывают и другие заносы.

У нас была очень большая задача: описание процесса нужно было скроллить пять минут. Решили его упростить, вынести куски в подпроцессы, чтобы карта процесса стала компактнее. Я приступила к задаче, но на меня посыпалась критика. Классическое «раньше было лучше, верните как было», потому что под новый контекст нужно перестраиваться и редко кто от такого в восторге. В общем, я старалась, ничего не получалось, и уже была готова сдаться. С тем и пришла в наш клуб анонимных аналитиков (в смысле на «Аналитические чтения»). Но техлид тогда сказал: «Было задание. Ты его делаешь. Просто закончи, чтобы было красиво и без ошибок. Всех, кто достаёт вопросами, отправляй ко мне, я по-другому объясню цель задачи». Успокоилась и доделала. Сейчас я из одного процесса сделала восемь и всё работает чётко. Всем удобно, и ни один человек ко мне с вопросами больше не пришёл.

И здесь слова техлида «Нет, делай» оказались весомее мнения остальных коллег. Его психологическая поддержка помогла мне не сдаться.

Перекрёстные связи

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

Например, когда я научилась делать API First, показала YML-документ, перерисовав его в кубики и со стрелочками. И за свои пять минут показала, как это можно применять, заманила в свою банду визуалов, но при этом не перегрузила информацией.

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

Всю эту информацию можно найти в системе по ключевым словам. Там же есть фамилия человека, который её разместил, а ещё зафиксированы процессы.

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

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

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

Читать истории других сотрудников:

— Бухгалтерия, трубы и стартапы: как я стал экспертом по Data Science в банке

— Рабочий день тимлида разработки в Газпромбанке

— Из археологии в IT: как я не стал археологом, зато стал работать с большими данными

— Как я начала заниматься Data Science, потом не перестала и сделала на этом карьеру

— С завода в IT: почему менять карьерный трек никогда не поздно

— Из архитекторов в IT: как архитектурное образование помогает строить карьеру в IT

— Pascal, экономика, крафтовое пиво и ML-модели. Как я выбрал карьеру экономиста, но в итоге оказался в IT

— Путь из разработчика в менеджеры, или как я не стал инженером холодильных установок

— Я ушёл из IT в фэшн-фото, вернулся обратно и вырос из мидл-разработчика в CTO