1. Стажировка (от 1 недели до месяца) – решение вне проектных задач, обычно из пула технического долга;
2. Испытательный срок (классически всего 3 месяца, включая стажировку) – работа уже в команде в "боевых" условиях, но на связи с наставником.

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

Обычно у нас получается такой цикл:

Стажировка или тестовая неделя/задача 📅

На этом этапе главная задача – показать, что ты умеешь давать результат в том виде, в котором он требуется. Для этого лучше идти по такой лестнице:

В рамках этого периода мы обращаем внимание на поинты ниже.

1. Умение решать поставленную задачу.

Есть задача, есть примеры решения подобных задач, есть инструкции/регламенты/шаблоны для того, чтобы описать ТЗ. Это всё, что необходимо на этом этапе.

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

Здесь следует набраться терпения и показать результат.

2. Умение адаптироваться.

Да, компания новая, да, процессы часто - другие, или тем не менее не «один-в-один». Когда в компании есть 20+ аналитиков и они работают по существующему процессу (и им ОК), то вероятность, что до тебя все заблуждались, стремится к нулю, но она есть.

См. пункт 1, но сразу не критикуй, еще рано.

3. Внимательность.

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

Умение декомпозировать большую задачу на мелкие - в этом случае также будет кстати. Мелкие неточности и пропуск некоторых моментов допустимы, но не 3-4 раза подряд. Здесь ожидается, что через 1 итерацию ревью ТЗ будет принято.

4. Умение признавать ошибки.

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

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

5. Умение оценить свои силы адекватно.

Велик соблазн с первых дней показать себя с лучшей стороны и занижать оценки.

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

Декомпозиция задачи здесь выходит на первое место. Умеешь разделять и объективно оценивать свою эффективность — проблемы с верной оценкой задачи у тебя не возникнет.

6. Наличие запросов на консультацию.

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

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

Тем более, повторюсь, что подвигов на этом этапе никто не ожидает.

7. Обратная связь от наставника.

В рамках стажировки новичок взаимодействует с наставником почти каждый день. Также может работать с отдельными разработчиками и тестировщиками.

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

Испытательный срок 🕒

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

8. Обратная связь от команды.

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

Если в общем обратная связь положительная, то работаем дальше.

9. Наличие вопросов и предложений.

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

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

10. Стабильность

Далее закрепляем еще 1-2 месяца. И, вуаля, перед нами - новый системный аналитик.

Как тебе материал? Понравился? Ставь 👍

Всем отличной 🍁 среды и продуктивной недели!

Больше пользы здесь 👉: @pro_system_analysis

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

Этап 5. Оценка примера технического задания

Чаще всего мы говорим про описание будущего состояния, подразумевая под ним технические задание.

Как мы проговаривали в предыдущей части (здесь), в конце пройденного технического собеседования будет правильным запросить пример технического задания в том виде, в котором его привык описывать кандидат на предыдущем или текущем месте работы.

Из практики:

Рекомендации:

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

Этап 6. Финальное собеседование

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

Обычно в финальном собеседовании принимают участие:

1. будущий непосредственный руководитель
2. будущий руководитель проекта/продукта, а иногда и в компании с владельцем продукта
3. будущий руководитель направления/департамента/управления
4. коллеги из HR

и такое разнообразие участников приводит к тому, что каждый может задать свой список вопросов.

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

Из практики:

Рекомендация:

Заключение

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

От себя хочу отметить, что очень хотел бы проводить меньше собеседований и быстрее закрывать наши потребности в системных аналитиках, поэтому описал процесс максимально подробно.

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

Успешных собеседований!

Предыдущие части:

1. Часть 1. Введение
2. Часть 2. Оценка резюме
3. Часть 3. Телефонное интервью
4. Часть 4. Техническое интервью

Как тебе материал? Понравился? Ставь 👍

Всем отличной 🍁 среды и продуктивной недели!

Больше пользы здесь 👉: @pro_system_analysis

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

Этап 4. Оценка результатов технического собеседования

Техническое собеседование состоит из следующих этапов:

1. Знакомство с кандидатом;
2. Обсуждение нашей потребности;
3. Вопросы на понимание роли системного аналитика;
4. Проектирование простого web-приложения;
5. Ответы на вопросы кандидата.

Шаг 4.1. Знакомство

На этом этапе наши задачи следующие:

1. Представиться;
2. Договориться о форме общения (в 100% случаев это переход на "ТЫ");
3. Рассказать о сценарии собеседования;
4. Рассказать о том, что потребуется от кандидата (напомнить про демонстрацию экрана, необходимость взять бумагу и ручку, если это нужно, стакан воды);
5. Напомнить про нашу компанию.

Во-первых, всё что кандидат хотел бы рассказать о себе, должно быть в резюме, и мы его уже несколько раз изучили (Часть 2. Оценка резюме и Часть 3. Технический скрининг).

Во-вторых, обычно такой рассказ занимает минут 10-15, а мы еще не успели напомнить о нашей потребности кандидату.

Из практики:

Лайвхак:

Шаг 4.2. Напоминание о потребности

На этом этапе наши задачи следующие:

1. Напомнить кандидату кого мы ищем, т.е. кого называют "системный аналитик" в нашей компании и какие навыки требуются обязательно, а какие - опционально.
2. Рассказать про проект или проекты, куда сейчас выполняется подбор системных аналитиков.
3. Рассказать немного прo flow, адаптацию, методологию, шаблоны и т.п.

Лайвхак:

Шаг 4.3. Инструктаж

На этом этапе наши задачи следующие:

1. Напомнить, как будут проходить следующие две части;
2. Попросить не гуглить и не вспоминать точные определения, а рассказывать всё своими словами, т.к. мы не на теоретическом экзамене;
3. Напомнить, что будет проектирование, а, значит, правильного решения может и не быть и достаточно уметь обосновать своё;
4. Напомнить, что если требуется взять ручку и блокнот или налить чаю, то лучше это сделать прямо сейчас.

Лайвхак:

Шаг 4.4. Вопросы на понимание роли системного аналитика

Здесь мы задаём вопросы по типу:

1. Кто такой "системный аналитик"?
2. На сколько сейчас ты работаешь близко к должности системного аналитика?
3. Какими инструментами и зачем ты пользуешься?
4. Как выглядит flow поставки ценности на текущем месте?

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

Из практики:

Шаг 4.5. Проектирование приложения

Всё начинается с демонстрации экрана кандидатом и проговаривания задачи.

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

Из практики:

Например задачи:

Цель: написать техническое задание для разработчиков.

Инструмент: на выбор кандидата.

Далее мы проходим по всем тем требованиям, которые были заявлены в вакансии, но не в форме вопросов-ответов, а в процессе проектирования.

4.5. 1. Работа с требованиями и архитектура решения

На что смотрим:

1. Будет ли этап работы с требованиями (их соберут, опишут, переспросят - всё ли учли?);
2. Будет ли этап проектирования архитектуры (прежде, чем начинать проектировать базу данных или api, появится ли схема решения?)

Из практики:

Рекомендации:

4.5. 2. Проектирование базы данных

Далее мы действительно начинаем проектировать одну или несколько баз данных, в зависимости от выбранной архитектуры.

Здесь мы смотрим за тем:

1. Есть ли понимание того, как проектировать базы данных (определение сущностей, связей между ними, кратности связей);
2. Есть ли понимание нормализации и денормализации данных;
3. Есть ли понимание ключей и их назначения.

По ходу можем задавать теоретические вопросы.

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

Из практики:

4.5. 3. Синхронное взаимодействие

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

Здесь мы даём кандидату свободу предложить решение. Однако в подавляющем большинстве случаев мы начинаем проектироваться GET метод в стиле REST.

Как только мы получили первый вариант сигнатуры метода, мы начинаем процесс мутации первоначального варианта с добавлением новых вводных:

1. "А теперь представим, что есть фильтры. Что изменится?",
2. "А теперь давай представим, что записей в базе 1 млрд. Что изменится?",
3. "А еще представим ..." и т.д.

Метод мутирует, параллельно мы накидываем теоретические вопросы, которые адекватно вплетаются в процесс проектирования и являются логичными.

Из практики:

4.5. 4. Асинхронное взаимодействие

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

Параллельно обсуждаем то, как будет выглядеть постановка на такое решение, какие есть подводные камни.

Из практики:

4.5. 5. Дополнительные (необязательные разделы)

Здесь мы коротко пробегаемся по дополнительным компетенциям:

1. Работа с 1С-системами;
2. Работа с bpmn-движками;
3. и т.п.

Шаг 4.6. Вопросы от кандидата

Чтобы дойти до этого этапа, необходимо внимательно следить за таймингом и сделать так, чтобы у нас осталось 10 минут на ответы на вопросы кандидата.

Из практики:

Поэтому в наших собеседованиях отсутствуют:

1. Вопрос "Расскажи о себе";
2. Нет никаких логических задачек и заданий на внимание;
3. Минимум теоретических вопросов, значение которых само по себе не гарантирует наличие навыков;
4. Задача ставится таким образом, чтобы при наличии практических навыков на каждый из этапов уходило 10-15 минут.

Мы всегда просим кандидата предоставить пример своего "лучшего технического задания". Очень часто возможности предоставить что-то с текущего места работы нет из-за NDA, поэтому у нас был этап проектирования, когда есть возможность задокументировать и составить ТЗ на решение, которое только что обсудили.
Из практики:

Предыдущие части:

1. Часть 1. Введение
2. Часть 2. Оценка резюме
3. Часть 3. Телефонное интервью

Как тебе материал? Понравился? Ставь 👍

Всем отличной 🍁 среды и продуктивной недели!

Больше пользы здесь 👉: @pro_system_analysis

В рамках этой части рассмотрим 3 этап собеседования системного аналитика, связанный с оценкой результатов телефонного интервью (технический скрининг).

Этап 3. Оценка результатов телефонного интервью

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

Список групп вопросов выглядит так:

1. Общие вопросы про текущий опыт;
2. Опыт работы с требованиями;
3. Опыт работы с базами данных;
4. Опыт работы с интеграциями (синхронные и асинхронные);
5. Опыт работы с 1С;
6. Собственное позиционирование и планы по развитию.

Вопросы сформулированы так, чтобы понять владеет ли кандидат ключевыми понятиями, и сгруппированы по тем навыкам, которые были заявлены в вакансии (кроме группы 1 и 6 - они имеют общих характер). Интервьюер задаёт вопросы и фиксирует ответы без комментариев.

Группа 1. Общие вопросы про текущий опыт

Группа 2. Опыт работы с требованиями

Группа 3. Опыт работы с базами данных

Группа 4. Опыт работы с интеграциями

Группа 5. Опыт работы с 1С системами

Группа 6. Собственное позиционирование и планы по развитию

Вопросы представляют собой скрипт с ветвлениями в зависимости от ответов на вопросы. Т.е. интервьюер задаёт не все вопросы всегда, а только если кандидат заявляет, что в соответствующей теме разбирается.

Из практики

К нам на вход по результатам телефонного интервью приходят:

1. Заполненная анкета технического скрининга;
2. Общее впечатление коллег от общения с кандидатом.

Оценка скрининга проводится по просмотру ключевых вопросов. Решение о переводе кандидата на этап технического собеседования (об этом поговорим завтра) принимается при наличии нескольких положительных решений от лидов системной аналитики.

Предыдущие части:

1. Часть 1. Введение
2. Часть 2. Оценка резюме

Как тебе материал? Понравился? Ставь 👍

Всем отличной 🍁 среды и продуктивной недели!

Больше пользы здесь 👉: @pro_system_analysis

В рамках этой части рассмотрим 1 и 2 этапы собеседования системного аналитика, связанные с оценкой резюме.

Этап 1. Предварительная оценка резюме

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

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

Этап 2. Оценка резюме

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

Шаг 2.1. Проверка читабельности

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

Из практики:

Рекомендации:

Шаг 2.2. Оценка возраста

Если возраст до 22, то уже есть еще одна "засечка", иначе идём дальше.

Из практики:

Рекомендации:

Шаг 2.3. Оценка общего стажа

Если общий стаж меньше 2 лет, то рассмотрение резюме на этом заканчивается.

Рекомендации:

Шаг 2.4. Сверка хронологии образования

Если выходит так, что период работы и период обучения пересекаются, то делаю еще одну "засечку".

Например, кандидату 21 год, дата окончания вуза 2025 год, но уже 3 года стажа работы СА - это еще один звонок о том, что к резюме нужно присмотреться внимательнее.

Из практики:

Рекомендации:

Шаг 2.5. Анализ последнего места работы

На что обращаю внимание:

1. Должность: если последнее место работы не "системный аналитик" любого грейда, то появляется необходимость присмотреться. Если долгое время работал не по специальности, то велика вероятность того, что навыки были забыты.
2. Продолжительность работы: если продолжительность работы менее 2 лет, то появляется необходимость присмотреться. Быстрый выход на рынок вызывает сомнения в том, что удастся построить долгосрочное взаимодействие.
3. Название компании: если видишь название компании, чьи собеседования знаешь и понимаешь (что это действительно системные аналитики), то становится просто спокойнее, но это не даёт никаких преимуществ.
4. Навыки: если действительно есть пересечение с тем, что заявлено в вакансии, то проверяю их на техническом собеседовании (о котором речь пойдёт в следующем части), иначе делаем еще одну "засечку" о сомнении в соответствии должности.

Из практики:

Рекомендации:

Шаг 2.6. Анализ предыдущих мест работы

Здесь схема примерно такая же, как на предыдущем шаге. Разве что смотрится всё еще менее внимательно.

Из практики:

программист -> бизнес-аналитик -> системный аналитик 

Шаг 2.7. Анализ продолжительности работы на каждом месте

Обращаю внимание на то, как долго задерживался на рабочем месте и как часто менял работодателей.

Если на всех местах продолжительность работы была порядка 1 года, то рассмотрение резюме джоб-хоппера на этом заканчивается.

Рекомендации:

На чём хочется заострить внимание:

1. Сначала просмотр одного резюме занимал сильно больше времени (до 10 мин), те самые "засечки" фиксировались и были обоснованием для перехода на следующий этап или отказа от дальнейшего рассмотрения;
2. Сейчас весь процесс анализа одного резюме происходит за 1-2 минуты, а итогом рассмотрения резюме является проставленный "+" или "-" в моей таблице;
3. Чем больше резюме отсматриваешь (чем выше насмотренность), тем быстрее принимается решение;
4. Безусловно есть риск неверно оценить и отказать перспективному кандидату, который просто некачественно оформил резюме или был неверно оценен (человеческий фактор никуда не делся, ошибки могут быть). Этот риск просто принимается и стараюсь нивелировать;
5. При наличии сомнений выбор делается в пользу "пропустить на следующий этап", что частично нивелирует упомянутый выше риск.

Главная рекомендация:

Ссылка на вводную часть: [Часть 1]

Понравился материал? Ставь 👍

Всем хорошего 🍁 вторника и продуктивной недели!

Больше пользы здесь 👉: @pro_system_analysis

Больше четырёх лет назад я вышел на рынок труда в СПб. Я прошёл (точнее НЕ прошёл🙃) порядка 15 собеседований на должность "системный аналитик", которые были местами совершенно разные.

Тогда ещё все собеседования были очными и:

• где-то решающим был вопрос про знание методологии "kanban";
• где-то - навык решения квадратных уравнений;
• где-то был нужен бизнес-аналитик;
• и только местами всё было честно и искали того, кто займётся проектированием и формированием технических заданий для разработки.

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

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

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

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

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

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

Понравился материал? Ставь 👍 Если есть замечания или запрос - напишите.

Всем хорошего 🍁 вторника и продуктивной недели!

Больше пользы здесь 👉: @pro_system_analysis

Если сейчас внедряете у себя такой шаблон, то рекомендую основывать его на спецификации OpenAPI. И вот почему:

Как лучше всего организовать шаблон? 📑

1. Описание метода – краткое пояснение, что делает этот метод.
2. URL и HTTP метод – указание на путь и тип запроса (GET, POST, PUT, DELETE и т.д.), иная информация, принятая для фиксирования в компании.

Указать в табличном виде для каждого входного параметра:

1. наименование,
2. тип параметра запроса (path, query и т.п.),
3. тип данных (boolean, string, object и т.п.),
4. ограничения (pattern, MaxIndex, MinLength и т.п.),
5. обязательность,
6. возможность принимать значение null
7. произвольный комментарий.

1. Указать в какой форме возвращается ответ;
2. Перечислить в табличном виде структуру ответа.

1. Пример запроса – привести пример реального запроса с параметрами и телом;
2. Примеры ответов – пример успешного ответа с примером структуры ответа и примеры негативных ответов с кодами 4хх/5хх (опционально).

1. порядок авторизации, в результате выполнения которого могут быть возвращены коды ответов 401 и 403,
2. валидации входных параметров (с учетом ограничений из раздела 2 и иные прочие проверки (например, условные), в результате которых может быть возвращён код ответа 400,
3. непосредственно саму логику работу метода: обращения к базам данных, выполнение вычислений, вызов методов других сервисов.

1. блок-схемы,
2. sequence-диаграммы
3. другие принятые в компании графические артефакты.

В результате при обнаружении новых аспектов работы REST-методов, которые укладываются в спецификацию OpenAPI, которые не принимались во внимание на ранних стадиях документирования могут быть легко встроены в такой шаблон, например, учет Content-Type.

А что ты ещё бы добавил в такой шаблон? Какие элементы помогают твоей команде быстрее разобраться в API?

Поделись своим опытом в комментариях. 👇

Всем хорошего 🍁 понедельника и продуктивной недели!

Пойдёмте поработаем 👨🏻‍💻

made in: @pro_system_analysis