Харизма не вкачана - на собеседованиях будет тяжко.
Харизма не вкачана - на собеседованиях будет тяжко.

Всем привет!\

Сегодня я разберу 5 навыков системного аналитика, на которые пристально обращает внимание работодатель.

На собеседовании с каждым ответом на вопрос вы добавляете либо отнимаете по очку от навыков своего персонажа-кандидата на вакансию.

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

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

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

А сейчас в процессе обзора попробуем все же разобраться - как отличить хорошего
аналитика от плохого?

1. Коммуникация

P.S В начале хотелось назвать качество Коммуникабельность, но тут же вспомнились четыре всадника Апокалипсиса для рекрутеров в резюме:

Вот они слева направо
Вот они слева направо

Итак, что у нас по коммуникации. Да в целом это и есть тот самый soft skill, который довольно просто оценить, но сложно прокачать.

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

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

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

На собеседовании навык коммуникации проверяют через следующие вопросы:

  • Расскажите о себе и своем опыте.

  • Расскажите, что вы делали как аналитик.

  • Какими достижениями в своей работе вы гордитесь?

  • Расскажите о своей самой сложной/важной работе за последние полгода.

  • С какими группами заинтересованных лиц вы общались?

2. Аналитическое мышление

Что вышло, то вышло..
Что вышло, то вышло..

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

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

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

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

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

  • Вам аналитик принес список требований. Как вы их оцените?

  • Опишите, что обычно содержится в вашей постановке для разработчиков?

  • Опишите схему процесса доставки заказа в Яндекс.Еда со стороны курьера.

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

3. Техническая экспертиза

Перекосы случаются.. но это все менеджеры виноваты!
Перекосы случаются.. но это все менеджеры виноваты!

Именно то, что оценивают в процессе технического интервью.

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

Мое видение: решение практических задач > вопросы на фундаментальные темы
Почему так? Ответ напишу на своем канале в ближайшее время.

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

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

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

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

Вопросы, проверяющие базовую техническую экспертизу:

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

  • Приходилось ли вам проектировать взаимодействие информационных систем? Какие способы интеграций вы знаете?

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

  • Напишите пример rest-API для книжной библиотеки (напишите методы, эндпоинты и пример JSON).

4. Проактивность

Активность без границ
Активность без границ

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

Но даже задав вопрос когда заканчивается работа системного аналитика - уже
можно многое понять о кандидате.

Плохой пример: системный аналитик может быть пассивным и не искать способы
решения явных проблем в команде.

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

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

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

Вопросы, проверяющие навык проактивности, обычно следуют из вопросов по навыку 1. Коммуникация. Но можно спросить например:

  • Были у вас конфликтные ситуации в команде? Как вы их решали?

  • Расскажите про процесс работы на последнем вашем проекте. Какая роль была у вас на нем?

  • В каком проекте либо задаче вы проявили себя как лидер?

  • Как вы прокачиваете свои навыки аналитика?

5. Гибкость

Вы не понимаете, у нас тут Agile
Вы не понимаете, у нас тут Agile

Жизнь - штука непредсказуемая.

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

  • Проект, итоговая работа по которому отправляется в стол

  • Секвестр бюджета и последующее сокращение половины команды

  • Увольнение тимлида/продакта в самый ответственный момент проекта

  • Длительное ожидание новых задач, ибо разработчик - узкое горлышко команды

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

А какие у вас были форс-мажорные ситуации на проектах?
Поделитесь в комментариях.

Спасибо!

Комментарии (10)


  1. Vpan
    07.07.2023 07:50
    +4

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


    1. fenrrr Автор
      07.07.2023 07:50

      Привет!

      Полностью с тобой согласен. Но на собеседовании к примеру грамотную письменную речь я не особо смогу проверить. Никогда кандидатам не предлагал письма бизнесу писать. Хотя может стоит попробовать? :)

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

      Такие требования, увы. Но у всех команд они конечно же разные.


    1. Mazrigosh
      07.07.2023 07:50

      Золотые слова. На мой взгляд, современные собесы вообще превратились в викторину на вроде ЕГЭ. Зазубрил все, оттарабанил - молодец. Забыл какую-то укню - не молодец, и всем фиолетово, что в работе она тебе ни разу не пригодилась (и, возможно, не пригодится).


      1. fenrrr Автор
        07.07.2023 07:50

        Привет!

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

        И сравнение с ЕГЭ - это просто 1 к 1 что происходит на бОльшей части собеседований сейчас. Культуру проведения собеседований можно и нужно развивать. Что я и косвенно и буду продвигать через свой блог.


  1. NIKEtoS1989
    07.07.2023 07:50

    Как будто про проактивность - это прям очень показательно - если чел пришёл на работу работать работу - то зачем её особо ускорить - таски крутятся - зп мутится????


    1. fenrrr Автор
      07.07.2023 07:50

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


  1. z250227725
    07.07.2023 07:50
    +3

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

    Разве системный аналитик должен это объяснять?

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

    У вас разработчики имеют контакт с Заказчиком? Иначе как они погрузятся в бизнес-процесс, кроме как через Аналитика, который ничего объяснить не может?

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

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


    1. fenrrr Автор
      07.07.2023 07:50

      Добрый день!

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

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

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

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

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


      1. z250227725
        07.07.2023 07:50
        +1

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

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

        Вы либо доверяете аналитику либо зря держите его в своем штате.


        1. smirnov_dm
          07.07.2023 07:50

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