Зачин
Очень много статей на тему найма программистов и проблем с наймом, как со стороны нанимателя, так и со стороны кандидатов.
Но мне мало попадалось статей про найм смежных вакансий, возможно просто плохо смотрел.
Поэтому решил написать о проблемах связанных с поиском аналитиков, как системных, так и бизнес аналитиков. Скажу сразу, что для меня это разделение условное.
О сути
Аналитик для меня это человек способный понять суть задачи/проблемы и трансформировать эту суть в техническую постановку/задание для технической команды(программисты, тестеры, админы, саппорт и т.д.).
И вот когда встал вопрос о поиске такого кандидата возникли первые трудности, формализировать критерии, если для поиска программиста надо указать ожидаемый стек технологий и знаний, например язык программирования(C#, Go, PHP, Python и т.д.).
То что указать для поиска аналитика?
Критерии
Конечно все началось с гугления таких критериев, просмотра wiki, вакансий от других компаний и т.п.
Итогом стал такой список:
сбор и анализ требований, коммуникация со всеми участниками процесса
умение разбирать сложные процессы
трансформация исходных данных в четкое и лаконичное ТЗ
умение прогнозировать/ставить оценку по времени своим задачам, управление своим временем или Time Managment.
технические навыки: SQL, работа с API(Postman, SoapUI, etc), UML/BPMN и т.п.
Вроде бы ничего сложного, как по мне точно не rocket science.
Поиск
Создали вакансию, опубликовали ее и стали работать с кандидатами.
Также мы давали небольшое ТЗ, для предварительного отбора, в нем описывали текущий бизнес процесс с указанием на оптимизацию. И просили ответить на ряд вопросов:
Какие узкие места и риски есть в ТЗ?
Какие вопросы спросите у менеджера?
Опишите поэтапно как планируете решать задачу?
Оцените по времени каждый этап, сколько времени он займет приблизительно (созвоны, консультации и т.п. можно опустить)?
Какие артефакты и дополнительные инструменты потребуются?
В дальнейшем, ТЗ и наработки по нему использовались на интервью с кандидатом. Задавая подготовленные к собеседованию вопросы мы постоянно ссылались на ТЗ и ответы кандидата по нему.
Это удобный формат общения, когда не придумываешь очень абстрактные задачи на ходу, а апеллируешь к конкретному ТЗ с которым (что очень важно) кандидат знаком.
Результаты
На момент написания статьи конверсия ниже 1%, т.е. из условных 105 кандидатов 1-му мы сделали офер.
Возможно это нормальная конверсия и отбраковка кандидатов очень высокая. В поиске и найме аналитиков мы не считаем себя спецами.
Проблемы кандидатов:
Сложное ТЗ
На начальном этапе поиска мы сталкивались с тем, что некоторые кандидаты не хотели рассматривать ТЗ и что-то по нему делать, ссылаясь на то, что оно большое и потребует много времени.
Действительно, первая версия ТЗ была больше, но не намного, проведя внутренний аудит ТЗ на своих сотрудниках мы убрали спорные вопросы, которые могли интерпретировать как сложные и трудоемкие.
Ну например, там был такой вопрос/просьба "Нарисуйте схему процесса as is и to be.", для автора статьи это не кажется сложным, но действующие сотрудники убедили, что качественная прорисовка схемы это трудоемкий процесс и мы убрали это из ТЗ.
Неумение сформулировать вопрос
Многие кандидаты писали довольно много вопросов к менеджеру решая ТЗ.
Но на интервью сформулировать 3 ключевых вопроса и объяснить как это им поможет решить задачу не могли. Часто это были даже не вопросы, а сразу предложения, например «Давайте/Можно сделаем интеграцию между системами?». Не то чтобы сам вопрос плохой, но как это поможет решить бизнес задачу? Если ответ «нет», то тогда задачу закрываем и расходимся? Возможно мы сами не верно понимали посыл кандидата.
Также были вопросы на которые нет ответа, например «Какой бюджет?». Ответ, что никакого бюджета нет, не подходит, потому что он есть. Но сказать какой именно бюджет невозможно, задача/ТЗ выдуманное, хотя и составлено из реальных бизнес кейсов.
Автор иногда отвечал 1 млн. долларов, что вызывало улыбку у кандидата и грусть у автора.
Вода
Задаешь конкретный вопрос кандидату, например "Что такое UserStory?" и потом минут 10-15 слушаешь пространные рассуждения в которых упоминается про предмет вопроса, но ответ невозможно понять. Далее задаешь уточняющий вопрос, например "Сформулируйте в сжатой форме UserStory из ТЗ" и тут фантазия кандидата раскрывается на всю, если не прервать возможно и полчаса смогут вещать. Оговорюсь однако, что это не все кандидаты, но многие.
Отсутствие навыка прогнозирования и TM
Один из важных пунктов которые интересовали в кандидатах это умение прогнозировать свою работу.
Почему это важно для нас? Потому что любая работа имеет начало и конец. Да, иногда задачи ставятся очень абстрактно и финиш по ней не виден. Но например, просто прочитать и понять бизнес требования, сколько на это нужно времени? У каждого по разному, но уверен что это часы, кому-то хватит 1-го часа, кому-то 4 часа, важно уметь прогнозировать сколько времени займет та или иная работа.
И речь не про дедлайны, а про возможность понять что результат работы(презентация например) появится через неделю или день и можно дальше уже договариваться с бизнесом о встречи, или планировать выступление перед партнерами по бизнесу и т.д.
Time Managment, уже столько про это написано, не вижу смысла повторятся, но приведу очень яркий кейс из одного собеседования. На вопрос "Вам нужно обсудить с менеджером 3 ключевых вопроса, что вы будете делать?". Ответ поразил автора "позвоню ему и спрошу".
В целом это не плохой способ, но разве менеджер ничего не делает? Или не менеджер, а например программист, он только и ждет звонка аналитика чтобы с ним пообщаться?
Мой ответ это запланировать встречу с менеджером или программистом, выяснить свободно ли у него время на эту встречу, написать повестку к встречи, чтобы не болтать, а обсуждать то что нужно обсудить.
Очень слабые познания в SQL
Мы давали такое задание "Есть три таблицы: orders, users, partners. Необходимо написать sql запрос который выведет все заказы пользователя Иван созданные партнером Иванушки International.". Потом проговаривали, что задача из двух частей:
1-я это проектирование структуры БД.
2-я это написание SQL запроса на основе полученной структуры БД.
Многие застревали на проектировании из 3 таблиц. Написание самого SQL тоже скатывалось в либо невозможность написать, либо в кривой синтаксис, который не распознавался как SQL.
Эпилог
Статья получилась довольно объемной, думаю не каждый дочитает до конца. Поэтому решил остановится на том что получилось выше.
Здравая критика приветствуется!
Публикация не претендует на что-то больше, чем описание процесса найма аналитика и возникшие в процессе трудности.
