Всем привет!
Меня зовут Коля, и я периодически собеседую кандидатов на позицию системного аналитика. За последние два месяца провёл порядка 20 собеседований. В основном были кандидаты с опытом 1.5-3 года, на пути к уровню Middle и с зарплатными ожиданиями 150-200 тысяч рублей в месяц.
В данной статье хочу побрюзжать про несколько расстроивших меня особенностей, которыми обладало большинство кандидатов данного уровня.
Дисклеймер
Под "системным аналитиком" подразумевается объединенная роль - бизнес-аналитик + системный аналитик (от заказчика до разработчика). Разделения данных ролей в компании нет.
Учитывая "зарплатную вилку", откликались в основном кандидаты среднего уровня и ниже. При поиске ведущего аналитика с другой "вилкой" ситуация значимо отличалась.
Статья основана на ограниченной выборке, не имеющей статистической значимости, и отражает личное мнение автора.
Отсутствие рефлексии относительно используемых инструментов
Если я вижу в разделе «Ключевые навыки» в резюме названия двух инструментов А и В, которые можно использовать для решения одной и той же задачи, то задаю вопрос «Чем отличается А от В? В каких ситуациях лучше применять А, а в каких В?»
Это могут быть REST и SOAP, XML и JSON, PostgreSQL и Oracle, UML и BPMN, Axure и Figma, Postman и SoapUI, или любая другая пара смежных технологий или инструментов. Пример вопроса:
Смотрите, у вас в опыте указаны PostgreSQL и Oracle. И то, и другое – системы управления реляционными базами данных, используются для решения схожих задач. Но PostgreSQL бесплатный, а Oracle стоит миллионы рублей. При этом всё равно находятся люди, которые покупают Oracle. Почему они это делают?
Ни разу не прозвучал достаточно полный и точный ответ. Какие были варианты?
Ступор. Кандидат не может сказать вообще ничего, так как никогда не задумывался про это.
Озвучивание предыдущего опыта без каких-либо обобщений: «технологию А я использовал на прошлом месте работы с такой-то целью, а технологию В на позапрошлой с такой-то целью».
Озвучивание одной отличительной характеристики – например, «REST проще (быстрее, надежнее, эффективнее) чем SOAP». При этом на уточняющие вопросы – «а чем конкретно проще (быстрее, надежнее, эффективнее)?» – ответа, как правило, не было.
Почему это меня расстраивает? Стандарты, технологии и продукты – это просто инструменты, которыми владеет системный аналитик. Мне нравится метафора ящика для инструментов – где лежат молоток, отвертки, стамеска, клещи, пассатижи и многое другое. Иметь много инструментов в ящике – это хорошо. Уметь пользовать каждым из них – прекрасно. Но не менее важно понимать границы применимости и в каждой конкретной ситуации использовать наиболее подходящий инструмент – чтобы не забивать молотком шурупы.
Неумение формулировать определения
Еще один приём – попросить кандидата дать определение термина, который считается самоочевидным и значение которого он точно понимает. Например, термина «требование к ПО», или «микросервис», или «архитектура ПО». В одно-два предложения и чтобы было всем понятно.
То, что никто не знает классических определений – это нормально. Но почему системный аналитик с опытом работы не может четко объяснить, что такое «требование к ПО»? Ведь результат работы системного аналитика – именно требования.
Часто кандидаты сбивались и давали определение не того термина:
Например, в ответ на предложение дать определение термину «архитектура ПО» рассказывали про трехзвенную архитектуру.
Или на предложение дать определение микросервису говорили что «микросервисная архитектура – это способ построения приложения в виде набора микросервисов, которые общаются между собой».
Почему это меня расстраивает? Системный аналитик не должен быть собакой, которая всё понимает, а сказать не может. Основные инструменты системного аналитика – мозг и русский язык (или английский, или любой другой). Умение облекать свои мысли в слова таким образом, чтобы это было понятно всем – один из ключевых навыков, определяющих профпригодность. Навык формулировать четкие и ёмкие определения - хороший тест на уровень владения языком.
Отсутствие мотивации к самостоятельному изучению профессии
На вопрос о том, какую профессиональную литературу вы читали, самый частый ответ – «статьи на Хабре». При этом просьба назвать какую-либо из последних прочитанных статей и пояснить почему она кандидату запомнилась, остаётся без ответа.
Про Вигерса, Коберна, BABOK, Леффингуэлла, Фаулера, Купера и прочих классиков половина кандидатов даже и не слышала, вторая половина – что-то слышала, но не читала.
Почему меня это расстраивает? ИТ-специалист (и системный аналитик в том числе) должен твердо стоять на двух ногах – теории и практике. Обе ноги важны, они взаимно дополняют друг друга и обеспечивают устойчивость – способность решать разные задачи в разных условиях. В данном случае «теоретическая» нога представлена лишь смутными воспоминаниями из вуза и практически атрофировалась. Прыгать на одной ноге можно, но неудобно и легко упасть.
Конечно, из любого правила есть исключения – например, Нона Гаприндашвили по её собственным словам стала чемпионкой мира по шахматам практически не зная дебютов. Но эти исключения лишь подтверждают правило – для этого надо быть гением.
Неумение смотреть на ситуацию «сверху»
В кейсах на взаимодействие кандидаты часто отождествляли себя с персонажем кейса и решали ситуацию «изнутри», вместо того чтобы посмотреть на ситуацию сверху, понять контекст и цели. То есть действовали в духе старого анекдота «Что тут думать, прыгать надо!». Пример кейса:
Начинается новый проект, нужно автоматизировать бизнес-процесс, который сейчас выполняется «на бумаге». Вы идете к заказчику собирать требования.
Сперва идете к большому боссу – директору департамента. Большой босс говорит: «мой vision было в том, что …» и начинает рассказывать про космические корабли – искусственный интеллект, нейросети, блокчейн, роботов и т.д.
Потом идете к начальнику отдела, который непосредственно руководит людьми, которые сейчас работают. Он вам говорит: «вот есть регламент, вот правила, вот «нормативка», работать нужно именно так и никак иначе».
Потом идете к специалисту, он вам говорит: «Работать можно только вот так, мир таков, это объективная реальность».
Вы понимаете, что у всех разные картины мира, которые не стыкуются между собой. Что будете делать?
Как правило, в ответе кандидаты начинают как-то сближать позиции сторон, чтобы прийти к общему решению, которое устроит всех. Кто-то хочет собрать всех на совещание, кто-то сводит стороны попарно, кто-то занимается «челночной дипломатией».
Разные кандидаты отдают приоритет разным уровням – кто-то большому боссу (т.к. он платит деньги и ему виднее), кто-то рядовому специалисту (т.к. он лучше знает как надо).
Почему меня это расстраивает? Перед тем как начать что-то делать, полезно оглядеться вокруг и понять - где я нахожусь, что вообще происходит и зачем мне это делать. Это полезное правило, которое позволяет избежать бессмысленной работы и сэкономить время.
Bonus. Применительно к ответу на кейс выше часто бывают такие проблемы:
Кандидаты часто пытаются сами определять, кто из представителей заказчика прав, а кто не прав. Даже не знаю, чем они руководствуются при этом – вероятно, предыдущим опытом. В кейсе никакой информации для этого нет.
В предлагаемых кандидатами решениях полностью игнорируется целеполагание. Зачем мы автоматизируем этот бизнес-процесс? Каких целей хотим достичь, сформулированы ли бизнес-требования и критерии их достижения? А ведь это именно те «весы», на которых можно взвешивать слова представителей заказчика – способствуют ли они достижению бизнес-целей или нет.
Помимо того чтобы самому понять что нужно сделать, требуется еще убедить заинтересованных лиц – что это именно то, что им нужно. Данный аспект игнорировался всеми кандидатами без исключения.
Короткая память
На вопросы о том, что было пару лет назад, кандидаты часто отвечают «это было давно, не помню уже». Так отвечали про свой прошлый проект – в чем была его суть и ценность, про нотацию диаграмм которую использовали на прошлом месте работы, или про структуру спецификации требований.
Если же кандидат что-то изучал только в вузе, но не применял на практике, то как правило ничего кроме названия в голове не осталось. Хотя там, скорее всего, была какая-то практика.
Почему меня это расстраивает? Это обесценивает опыт. Полученный опыт переходит в устойчивые умения и навыки, повышающие ценность сотрудника, только после фазы осознания и рефлексии. Ответ «не помню» позволяет предположить, что полученный опыт был выкинут из головы сразу же после завершения работы, и никак не закрепился. При таком подходе полезность и ценность сотрудника растёт медленно (если вообще растёт).
Не подтверждаются "ключевые навыки", заявленные в резюме
Заявленный Keycloak означал что кандидат несколько раз заводил в UI пользователей, но понятия не имеет зачем нужен этот продукт и какие у него возможности. Аббревиатуры IdM (IAM), JWT кандидату незнакомы.
Заявленный IDEF означал что в институте рассказывали про IDEF0, но кандидат уже всё забыл – помнит только что это «устаревшая и неудобная нотация». Что так именно "неудобно" - не может сказать.
Заявленный SOAP означал что кандидат работал над системой, в которой до него были реализованы «какие-то» веб-сервисы. Но что такое WSDL и XSD – кандидату неизвестно.
Особенно порадовал случай, когда у кандидата в ключевых навыках был указан «математический анализ». Предвкушая интересную и содержательную беседу, я начал с вопроса о значимости первой теоремы Вейерштрасса (о достижении максимального и минимального значения непрерывной функции на отрезке) – почему ей придаётся такое значение. Но не получил никакого ответа...
Почему меня это расстраивает? Если что-то заявлено в «ключевых навыках», то я ожидаю от кандидата возможности вести содержательный диалог на эту тему. А по факту объем заявленных в резюме навыков нужно делить на 2, а то и на 3.
Отсутствие понимания что такое «анализ»
Если у кандидата в ключевых навыках заявлены одновременно «аналитическое мышление» и «системное мышление», то я обязательно задаю вопрос, что они имеют в виду и чем эти понятия отличаются. Достаточно точный ответ я получил всего однажды, хотя задавал этот вопрос 7 или 8 раз.
Как выяснилось, мало кто понимает что такое «анализ» (и уж тем более не может дать ему определение), чем он отличается от синтеза и какие вообще виды мыслительных операций существуют. Хотя и регулярно применяют их на практике, в том числе и непосредственно в процессе собеседования.
Почему меня это расстраивает? Чтобы закрепиться в квадранте неосознанной компетентности, нужно сперва пройти через квадрант осознанной компетентности. Системный аналитик (или бизнес-аналитик) занимается соответственно системным анализом или бизнес-анализом, но при этом не осознаёт, что такое «анализ». Чем же он тогда занимается?
Отсутствие реакции на обратную связь от собеседника
Частая проблема кандидатов – длинная и неструктурированная речь с большим количеством деталей, незначимых для ответа на поставленный вопрос.
Услышав первый затянутый ответ, я переспрашиваю «Правильно ли я вас понял, что…» и повторяю ключевые мысли из ответа кандидата, но раз в десять короче и более структурированно – например, в формате нумерованного списка (во-первых, во-вторых, в третьих).
Кажется, что это предельно толстый намёк на то, что надо говорить короче и чётче. Но большинство кандидатов его не воспринимают и никак не меняют свой способ выражения мыслей.
Почему меня это расстраивает? Здесь две причины:
Умение чётко и кратко выражать свои мысли – это один из важных навыков системного аналитика. Если его нет даже на собеседовании, то откуда он возьмется в работе?
Отсутствие реакции на сигналы собеседника. Я и на невербальном уровне подаю сигналы что меня раздражает столь затянутый и путанный ответ, и сразу же даю образец – как мне было бы понятнее и лучше. Но кандидат не реагирует и продолжает дуть в свою дуду...
Если же кандидат реагирует и перед следующими ответами начинает задумываться и формулировать свои мысли, это жирный плюс.
Нет планирования своего профессионального развития
На вопрос "что бы вы еще хотели изучить в системном анализе, каких знаний-умений-навыков вам не хватает чтобы выйти на следующий уровень?" обычно дают два ответа - либо "не знаю", либо "интеграцию". Интеграция вообще представляется каким-то "священным Граалем" системного анализа - если уж я освоил ДАЖЕ интеграцию, то круче меня только горы.
Большинство кандидатов даже не задумывается, что включает в себя системный анализ, из каких этапов состоит процесс анализа, какие техники существуют.
Почему меня это расстраивает? Это делает практически невозможным модный нынче "Lifelong Learning" в профессиональной сфере. Если я не знаю, чего именно я не знаю, то как я смогу это узнать? Формировать и непрерывно пополнять список того, что еще хочется изучить, освоить и применить на практике - полезная привычка для профессионала.
Заключение
К чему я всё это написал? Здесь опять же несколько причин:
Cтатья может быть полезна для кандидатов. Выделенные выше проблемы характерны именно для группы кандидатов уровнем «чуть ниже middle», аналитики более высокого уровня редко испытывают подобные проблемы. Это возможные точки роста.
Cтатья может быть полезна тем кто проводит собеседования – натолкнет на какие-то мысли или предоставит новые вопросы в арсенал.
Статья может быть полезна тем кто, занимается профессиональным развитием аналитиков - куда их можно еще "поразвивать".
Ну и просто по-стариковски побрюзжать о том какая пошла молодежь, не без этого :)
А какие у вас вопросы к системным аналитикам с небольшим опытом? Чего им чаще всего не хватает, какие вопросы вы задаёте? Поделитесь в комментариях!