Меня зовут Шпак Артем, я системный аналитик в финтехе. В статье-гайде расскажу, что скрывается за короткими формулировками в чек-листах по онбордингу и дополню еще несколькими пунктами, которых в этих документах обычно нет. Этот гайд неоднократно помогал мне и моим ученикам (особенно пункт про доступы и погружение в продукт) успешно пройти испытательный срок и сразу заявить о себя, как об опытном специалисте и «на чиле» пройти испытательный срок аналитику.
В первые дни работы новички обычно получают «чек-лист онбординга» — документ в Confluence с задачами, которые нужно выполнить в течение испытательного срока. На первый взгляд, кажется, что достаточно просто следовать этому списку, и адаптация пройдет гладко.
А нифигааа: такие чек-листы часто формальны и не содержат всей ключевой информации. Они не объясняют, что действительно важно сделать в начале испыталки и как вам показать себя с лучшей стороны. Расскажу, что действительно нужно делать, если вы только пришли на новый проект!
№1. Оформление доступов
Стандартно — это первый пункт в чек-листе.
Будьте готовы к тому, что в документе будет неполная информация или наоборот, излишняя. Часто бывает так, что некоторых систем уже нет, потому что документ в Confluence был составлен три года назад и не обновлялся.
Однажды на моём первом онбординге я получил задачу: «Просмотреть документ Х в сервисе Y». А сервиса Y у меня в доке нет... И как выполнить задачу? Здесь главное — не сидеть просто так, ждать, молчать, а пойти к наставнику грозным шагом. Я так и сделал. Через час мне выдали актуальную инструкцию. А если бы не попросил — то и не выдали бы, и задача была бы провалена.
Следовательно, у нас появляется новая переменная в этом пункте — оказывается, может существовать актуальный документ с описанием сервисов и доступов. Просто так, скорее всего, вам его не выдадут. Уточняйте требования — действуйте проактивно!
Картинка с мемом: «Ссылку я дам. Доступ я не дам».
Если вы прошли этап «Получить доступы к сервисам», указанным в чек-листе, то дальше уточните у команды, какие сервисы могут понадобиться дополнительно.
Дело в том, что есть сервисы, которых нет в документах, потому что команда может пользоваться своим списком, и, чтобы быть в контексте, вам необходимо порасспрашивать не только лидера, наставника или ментора, но и коллег. Например, после общих встреч я подходил к одному из коллег и начинал «допрос»: «А как это происходит? А в какой системе? А-а, а как доступ получить?» Так я постепенно выяснил весь актуальный список сервисов команды.
Ключевое действие на этом этапе — максимально быстро создать все заявки и получить доступ к системам. Если вы не уверены в своих силах и переживаете, то я всегда советую выложиться на этом этапе на 1000 %, чтобы выиграть время для последующих этапов. И не обязательно говорить руководителю о том, что у вас уже есть все доступы. Используйте выигранное время для чтения документации и погружения.
№2. Погружение в корпоративное ПО
Первым делом изучите базу знаний.
Сначала находим именно свой проект и читаем о нём всё. Например, на одном из онбордингов мне прислали Confluence департамента и Confluence команды. Оба документа были полезны, но первый документ мне пригодился немного позже. Я расставил приоритеты и не тратил время на «лишние» документы, а в первую очередь начал читать документы своей команды. Во время онбординга от них вам будет больше пользы.
Следующий этап — освоить трекер задач.
Рекомендую зайти в Jira и просто читать таски. Читать, читать и читать, чтобы понять: методологию ведения, статусы задач, кто задачи создаёт, как в команде их описывают — подробно или нет, изучить, какие типы задач используются. Например, до недавнего времени моя команда использовала подход с эпиками и тасками, а сейчас — с тасками и подзадачами, а сторей у нас никогда не было.
Это всё очень пригодится, когда появятся первые задачи — вы уже будете понимать, что с ней надо делать.
Основные сервисы.
Естественно, изучите сервисы переговоров, почту, корп. чаты и другие корпсервисы (сервисы для просмотра логов, создания заявок и т.д.) для ускоренного погружения в проекты.
№3. Взаимодействие с командой и культурой компании
Бывает, что этот пункт отсутствует в чек-листах. Но он важен.
Наблюдение и адаптация.
Рекомендую не спешить, особенно с предложениями, а постепенно адаптироваться к процессам. Мало ли что происходит в команде, вы можете не знать о прошлых «делах», которые накладываются на текущие процессы. И предложения просто не услышат, а вы расстроитесь, онбординг пойдёт не по плану.
На первой работе системным аналитиком мне «повезло» попасть в команду, которая в тот момент находилась в стадии «пересборки»: проект завершился, и участники растекались в другие команды. В какой-то момент нас осталось человека четыре, и мы все не понимали: а что нам делать-то теперь?
Но, благо, во время «турбулентности» я внимательно слушал и наблюдал за тем, что происходит на созвонах и рабочих встречах, что помогло мне понять подходы и процессы в команде, которую отстроили позже.
Личные встречи.
Ещё помогала настойчивость, когда я ставил индивидуальные встречи с каждым членом команды, чтобы обсудить роли, ожидания и задачи. Встречи полезны — помогают лучше понять, как эффективно взаимодействовать с коллегами. Ведь каждая компетенция видит один и тот же проект по-разному: разработчик понимает внутреннее устройство, а тестировщик чаще всего работает с паттернами тестирования и знает слабые места. Аналитик же скорее расскажет про процессы и боль, которую решает ваше ПО.
Знакомства — это важно. Рекомендую расспрашивать о проекте, технологиях, процессах во время индивидуальных знакомств. Заодно вы узнаете членов команды, а они — вас. Например, как-то мне посчастливилось поработать с тимлидом-бэкендером в банке, который до этого 10 лет отработал в шахте. Кто знает, какие удивительные люди работают с вами? Познакомитесь и узнаете, а работать будет веселее.
№4. Понимание системы и её компонентов
Здесь начинается интересное.
Изучение клиентского пути.
Совместно с аналитиком или QA поработайте с тестовой средой: выполняйте базовые сценарии использования, изучайте клиентские пути. Как понять основные процессы и точки взаимодействия пользователя с системой, допустим, когда пользователь решит оформить кредит под залог?
Для этого можно пройти путь оформления кредита на тестовой среде. А чтобы зайти в тестовую среду, сориентироваться там, создать пользователя, зайти в продукт — не обойтись без QA. Он лучше всех знает, как это сделать. А для этого нужно просто попросить :) Не пренебрегайте тем, чтобы пройти с тестировщиком клиентский путь вдоль и поперёк, посмотреть отправляемые логи, записи в БД. Поверьте, вам это пригодится.
Здесь поможет пункт №3 «Личные знакомства» данной статьи.
Изучайте продукт, фичи и их визуальное отображение. Если включите DevTool, то можете узнать, какие запросы отправляются. Если найти логи этих запросов, увидите, что это за сервис. А там можно и к разработчику или аналитику заглянуть, которые ответственны за сервис.
Для более глубокого понимания получите доступ к базам данных, логам событий и метрикам работы системы. Для качественной и глубокой проработки фичей жизненно необходимо уметь искать в БД записи, которые создаются во время процесса использования продукта, искать логи, которые сохраняет ваш продукт. Это как разобрать машину на автосервисе, чтобы понять, как она работает. В моём продукте мне очень помогла практика, когда на каждом шаге я наблюдал, какие записи создаются в БД.
Изучите API с помощью Swagger или Postman для понимания интеграций. Если Swagger есть не всегда (уточните у разработчика или аналитика), то попросите тестировщика прислать Postman-коллекции продукта и рассказать, в каком порядке их вызывать.
После этого не забудьте повесить вашу шляпу Шерлока Холмса на вешалку и пойти отдыхать)
Онбординг — самое подходящее время, чтобы всё потрогать и разобраться в сервисах.
Документация.
Найдите и изучите документацию по сервисам и бизнес-процессам, за которые отвечает ваша команда. Кто может помочь: коллеги из вашей команды, руководитель, аналитик (если вы не единственный аналитик в команде, а предыдущий аналитик занимается прохождением ИС в другом месте :D )
Вы как аналитик должны понимать, где и какая документация лежит. Добавляйте документацию в закладки, чтобы она была под рукой.
Изучите бэкенд-документацию и любую другую документацию на сервисы, чтобы получить базовое понимание их работы и интеграций. Здесь без разработчика не обойтись.
Когда мне тяжело понять, какой сервис за что отвечает, я создаю таблицу. В ней четыре столбца: «Разработчик», «Сервис», «Эндпоинт», «Назначение» На первых порах шпаргалка поможет не запутаться.
А чтобы понять, как устроен процесс с самого начала и вплоть до финала, помогает диаграмма активности процесса (флоу) пользователя с указанием взаимодействий с различными системами. Она может выглядеть как угодно, но это не так важно — главное, что она будет понятна вам.
Командные созвоны и консультации.
Если документации недостаточно, организуйте созвоны с членами команды, чтобы получить необходимые знания. Общение — ключ к успеху, повторюсь. Ведь если документации нет, то ничего не остаётся, кроме как общаться и ковыряться в продукте.
№5. Погружение в бизнес-процессы и домен
Изучение бизнес-процессов.
Чем глубже вы поймёте бизнес, тем эффективнее сможете предлагать решения, и вообще вы будете понимать, что происходит, какой продукт и для кого вы делаете. Мы делаем ПО для пользователей, а не ищем и не заставляем пользователей его использовать. Для этого я рекомендую полностью погрузиться в бизнес-процессы, за которые отвечает ваш продукт.
Сбор информации о домене.
Найдите документацию с описанием бизнес-процессов, глоссариев и метрик для вашего продукта. Вам может помочь руководитель или продукт — они обычно хорошо понимают, что происходит. На всех работах именно руководитель мне объяснял суть продукта с точки зрения бизнеса и процессов. Но не всем так везёт, поэтому можно поискать руководителя, руководителя или коллег из ваших команд. Не бойтесь, это покажет вас с лучшей стороны!
Попробуйте организовать встречи со стейкхолдерами для получения информации о домене: задать вопросы, выяснить, кто имеет отношения к вашему продукту, а если продукт внутренний — найти пользователей. Однажды я пришел на внутренний проект, на котором не было документации. Мы с моим руководителям катались в другие офисы, чтобы пообщаться с теми, кто используют ПО, а также взглянуть на них вживую. Такой опыт запоминается.
Если у вас есть возможность выехать в «поля», чтобы погрузиться в процессы, например постоять на кассе в «Бургер Кинг», как один из моих учеников, то обязательно так сделайте.
А если вы работаете над промышленным ПО или, допустим, складским, то без «гембы» не обойтись. На одной из прошлых работ я ездил на склады и в магазины ритейлера продуктов со своей цепочкой поставок. Там иногда примерял на себя роль складского сотрудника: участвовал в приемке товаров от поставщиков, выяснял, почему они привозят товар в разных коробках, работал со сканнером, собирал паллеты, игрался тестировал с промышленным принтером, водил погрузчик. А как иначе погрузиться в процессы и понять пользователя складского ПО? Только так, а не иначе. Об этом у меня есть отдельная статья.
Из выездов в «поля» можно вынести много полезного. Никогда не отказывайтесь.
Попробуйте найти опытного коллегу, который сможет объяснить ключевые аспекты домена. Обычно бывалых сразу видно: говорят мало, но по делу. Пообщайтесь с ними — вы можете узнать много нового, может, даже то, что никто не знал до вас в вашей команде.
На крайний случай, если нет совсем никого или времени для погружения мало, могут помочь нейросети. ChatGPT (или что-то подобное) быстро вам расскажет о новой области. Только не увлекайтесь.
№6. Установление целей и обратная связь
Фиксация целей на испытательный срок.
В первую неделю на новом месте ваш руководитель проведёт встречу-знакомство. Одной из тем на данной встрече будет обсуждение того, что от вас хотят в целом. Но также будет обсуждение того, что от вас хотят на испытательном сроке. Будьте крайне внимательны, потому что вы будете говорить о критериях — прошли вы испытательный срок или нет. Согласуйте с руководством чёткие цели, например: «Получить доступы, провести анализ, написать техническое задание и документацию по конкретным фичам». Разделите их на этапы: первый месяц, второй месяц, третий месяц. Обычно это не должны быть какие-то сверхсложные задачи.
Без четко поставленных целей на испыталку не будет критериев её успешного прохождения. А это значит, что эти три месяца вы будете в подвешенном состоянии. Так что ставьте цель, и, если вы вдруг поймете, что не справляетесь, то в моём телеграм-канале канале много советов по прохождению собеседований и написанию документации.
Запрос обратной связи.
Регулярно запрашивайте обратную связь от руководства и коллег.
В первый месяц — еженедельно, затем реже. Это позволит вам корректировать своё поведение и подходы к работе. Так вы будете понимать, что о вас думают как о сотруднике, и поймёте, стоит ли ещё раз открывать резюме и на обедах проходить собеседования или всё хорошо и вы можете не переживать.
Например, когда я запрашивал обратную связь, мне советовали выучить стейкхолдеров систем, с которыми взаимодействует наш продукт, чтобы знать, к кому обращаться, и оперативнее решать проблемы.
№7. Проявление инициативы и решение проблем
Инициатива и активность.
Проявляйте активное участие в рабочих процессах, инициируйте встречи и обсуждения, предлагайте идеи с аргументацией. Так вы сможете быстрее влиться в рабочие процессы. Если вы много предлагаете, то получаете ответы на эти предложения, которые также помогают понять продукт и людей вокруг. Так вы сразу найдёте менее активных коллег, которых можно «подсидеть» (шутка!).
Помните, все испытывают страх испытательного срока. Все мои ученики задают такой вопрос. Но проблем с ИС ни у кого не было.
Решение проблем.
Проблемы возникают только, если молчать о трудностях. И вот тогда возникнут проблемы с ИС, потому что самая популярная причина увольнения в это время — молчание. Знаю не одну ситуацию, когда увольняли именно за умалчивание. Обсуждайте проблемы с руководителем или лидом команды, предлагая возможные решения. Проблемы есть у всех, но если вы профи, то с помощью своих софт-скиллов обязательно найдёте способы решения проблем.
Если вы вдруг не справляетесь и у вас проблемы, ни в коем случае не молчите! Подсветите данную проблему лиду, руководителю, постарайтесь найти причину.
№8. Заключение и дальнейшие шаги
Оценка ситуации.
Если испытательный срок проходит сложно, обсудите это с руководителем. Если ситуация не улучшается, рассмотрите возможность ухода, чтобы избежать дальнейшего стресса и разочарования. Но это происходит редко, обычно больше переживаний!
Помните, что первые 3–4 месяца новый аналитик не сможет выдать полноценный результат, и это нормально.
Переход к основной работе.
Если все идет хорошо, продолжайте укреплять свои знания и взаимодействие с командой. Ваш успех на испытательном сроке заложит фундамент для дальнейшего роста в компании.
Помните, что первое мнение о вас — самое важное! Не бойтесь ошибаться или показаться глупым, ведь если вы там оказался, значит ты точно не глупый!
Желаю удачи с испытательном сроком!
Подписывайтесь на мой телеграмм, где я рассказываю про работу аналитиком, собеседования, поиск работы, а также карьеру в IT :)
Статьи, которые могут быть интересны:
Как дизайнеру с помощью макетов оптимизировать процессы и сэкономить время
Как у нас почти получилось сделать автономного робота для «Битвы Роботов»
База об организации процесса разметки: команда, онбординг, метрики
Подписывайтесь на блог и Телеграм-канал Alfa Digital — там мы постим новости, опросы, видео с митапов, краткие выжимки из статей, иногда шутим.
