Comments 26
Навыки можно разделить на те, которые прокачиваются быстро и которые прокачиваются долго. На мой взгляд, смотреть нужно на те, которые прокачиваются долго. Например, кандидат может не уметь рисовать диаграммы последовательностей или не знать об их существовании. Это странно, но легко поправимо. Пример обратного: неграмотная письменная речь. Если человек пишет с ошибками да так, что каждый его документ нужно вычитывать перед отправкой заказчику, за ним годами придется все вычитывать.
Привет!
Полностью с тобой согласен. Но на собеседовании к примеру грамотную письменную речь я не особо смогу проверить. Никогда кандидатам не предлагал письма бизнесу писать. Хотя может стоит попробовать? :)
А вот попросить нарисовать сиквенс диаграмму простенькую я смогу. И это будет для меня намного важнее, ибо мне нужно чтобы аналитик пришел на проект и давал вэлью здесь и сейчас. А не когда он этому хард скиллу обучится.
Такие требования, увы. Но у всех команд они конечно же разные.
Золотые слова. На мой взгляд, современные собесы вообще превратились в викторину на вроде ЕГЭ. Зазубрил все, оттарабанил - молодец. Забыл какую-то укню - не молодец, и всем фиолетово, что в работе она тебе ни разу не пригодилась (и, возможно, не пригодится).
Привет!
Да, я вот совсем недавно как раз отвечал на вопрос почему практические задачи важнее теоретических на собеседовании.
И сравнение с ЕГЭ - это просто 1 к 1 что происходит на бОльшей части собеседований сейчас. Культуру проведения собеседований можно и нужно развивать. Что я и косвенно и буду продвигать через свой блог.
Я бы этого назвал проблемой "системы". Вы можете дать практические задачи, как бы попробовать оценить практические навыки кандидата. Кандидат может перенрвничать, может ошибиться, в конце концов никто из нас не проектирует системы на лету и не становится в ситуацию, когда надо придумать архитектуру кредитного конвейера за полчаса.
По итогу, вам покажется, что кандидат не справился, кандидат уйдет в другое место, где просто расскажет про кафку и ресты и будет нанят. А вам придется бороться с этой системой и тратить по полгода на поиски кандидата.
Добрый день!
Никто из нас не проектирует фейсбуки на лету, но я этого и не прошу сделать на собеседовании :)
Мне важно оценить, как человек размышляет и работает, а не что он зазубрил. Повторюсь, что мои методы отрабатывают и приносят вэлью командам в виде классных ребят пока на 100% (тьфу-тьфу-тьфу).
Согласен. Мягкие навыки сильно сложнее прокачивать, поэтому они должны уже быть у аналитика.
Как будто про проактивность - это прям очень показательно - если чел пришёл на работу работать работу - то зачем её особо ускорить - таски крутятся - зп мутится?
системный аналитик не может объяснить разработчику, почему он решил реализовать логику именно таким образом
Разве системный аналитик должен это объяснять?
В результате разработчик тратит время на погружение в бизнес-процесс, чтобы самому убедиться в корректности решения
У вас разработчики имеют контакт с Заказчиком? Иначе как они погрузятся в бизнес-процесс, кроме как через Аналитика, который ничего объяснить не может?
Про аналитическое мышление тоже слишком категорично. С такими критериями отбора ваши аналитики будут постоянно изобретать велосипеды. Нет ничего зазорного в том, чтобы обратиться к коллегам за информацией, т.к. со схожей проблемой кто-то уже мог сталкиваться и существует хорошее или, наоборот, плохое решение.
Не понятно как из отсутствия аналитического мышления вытекает непонимание предметной области, указанное в плохом примере. Получается, что все кто задействованы в бизнес-процессе его имеют, но это не так. Зачастую они как раз не способны объяснить чем занимаются и чего хотят и аналитику приходится "просеивать песок" в поисках чего-то ценного. Для понимания предметной области нужно уметь учиться.
Добрый день!
На моей практике в командах с хорошей культурой аналитики и разработки одно из правил приемки ТЗ - его ревью разработчиком перед стартом. Соответственно у разработчика вполне логично могут быть вопросу по бизнес-процессу. И вообще это является одним из показателей сеньорности разработчика - если он не просто кодит, а четко понимает, какую бизнес-задачу решает его код. А для этого нужна сессия общения с аналитиком, особенно если интеграция компексная.
И да, бывает такое, что с бизнес-заказчиком тоже приходится собираться на троих с разработчиком. Чем ближе к фронтальным модулям разработка - тем может быть больше такого взаимодействия.
Про то, что обращаться за помощью коллегам - это ни в коем случае не осуждается, все так. Сам так делаю, когда в новую предметную область погружаюсь. Мой пример был про плохое развитие или отсутствие навыка как такового.
Человек может заучить, кто такие неклиенты банка и методы конвертации их в клиентов. Но при обсуждении с бизнесом нового метода он может не понимать ее вот хоть убей. Даже если она хороша, просто у человека не хватает навыка анализа ее понять. И бизнесу приходится тратить больше времени, чтобы быть такому «плохому» аналитику объяснить свою идею.
Этот пример противоречив, ибо тут и от навыка заказчика тоже зависит качество объяснения его точки зрения. Но представим, что с ней все хорошо, а вот с эмпатией аналитика - не очень. Проблема тут и возникнет.
Мы тоже используем ревью разработчиками, но исключительно с точки зрения технических аспектов.
Время разработчиков слишком дорого, чтобы тратить его на встречи с Заказчиками и погружение в бизнес-процессы.
Вы либо доверяете аналитику либо зря держите его в своем штате.
Почти согласен, но зависит от масштаба и характера проекта. Как бы хорошо ни были сформированы и зучены требования, как бы детально ни были описаны процессы, в сложных системах могут быть особенности априори находящиеся за пределами технической экспертизы как заказчика, так и аналитика, при этом процесс может быть ограничен этими особенностями. Например, когда речь идёт о взаимодействии с регулярно обновляющимся сторонним API. Одно-два ёмких интервью с командой, где затрагиваются процессы, в подобных случаях может сократить количество изменений на этапах разработки.
Коллеги, мнения ваши полностью разделяю.
Более расширенное мнение об отношениях между аналитиком и разработчиком сегодня высказал отдельно.
Спасибо за полезную инфу! Учусь на СА и такие статьи помогают вливаться в контекст и мотать на ус на будущие собесы:)
Привет!
Крутяк, очень рад, что кому-то я правда полезен) приходи на мой канал, там еще больше полезностей выкладываю.
Хабр все же для каких-то более тяжеловесных статей планирую использовать для публикации.
Успехов в обучении!
Сложная ситуация. Честно говоря, аналитики все разные и на собеседовании сложно выявить
Да, легко проверить технические знания, ем более часто там проверять особо нечего.
Можно попросить нарисовать схему процесса, но ценным является не ее срисовка, а умение понять потребность заказчика и нарисовать то, чего нег, но будет работать
Можно попросить рассказать, как контролировать полноту требований, скоуп, но на реальном проекте вылезет, что аналитик не понимает проект и этого не может сделать в принципе
Самое важное:
Землеройка, аналитик не пишет кол, он склеивает заказчика и разработку и его обязанности часто формально недоопределены. Поэтому копать до побеы - обязательное условие
Коммуникабельность и умение работать с конфликтами. Птица говорун по сути бесполезна. Важно уметь слушать всех, запоминать и сводить в одну точку. И эту точку описать максимально прозрачно для всех. Но если не можешь - не все потеряно, можно работать на вторых ролях, если на проекте больше одного
Ориентированность на результат. Это основное, код, строиз, 100500 выполненных задач - по фиг, если продукт не работает так как надо. Надо понимать цель и под нее строить все, в том числе заказчик, который первый готов уйти убсуждать шрифты или цыювет фона. Все меряется продуктом - вышло хреново, аналитика на кол, как минимум главного. Не понимая цели, можно получить 100500 тасок, которые не собиратся в целое
Готовность слушать всех и прочить помощь зала. Аналиьик часто самый слабый спец во всем. Технически он слабее любрго дева, в бизнесе все равно шaрит меньше чем SME, в дизайне ... и так во всем. Агалиьик не должен брать на себя, он должен собиоать все мнения и помогать выйти на решение
КАк проверить? Не знаю. По рекомендации. Это более менее раьотает
Остальное - честно, ты либо попадешь в проблему, либо узнаешь потом.
В целом в статбе все неплохо, но из опыта есть куча примеров, что у коассного на вид спеца был скелет в шкафк, который его помножил на ноль
Корона на голове
Спорщик
Безинициативная все уточняющая овечка
Небрежность
Хитросделанная редиска, которая имеет огромный опыт эмуляции работы
Добрый день!
Очень достойно расписал то, о чем я в целом хотел коснуться и разобрать дальше. Прям спойлер словил))
Касательно собеседований, тут на самом деле чисто на неком эмоциональном интеллекте нужно пытаться кандидата проанализировать. И желательно звать на собес еще кого-нибудь для более полной оценки. Я бывает провожу для аналитиков отдельный собес-знакомство с командой, чтобы ребята пообщались-позадавали друг другу вопросы.
Ибо если аналитик в коллектив не вливается - на уровне тимлида направления приходится потом некоторые конфликты разруливать. А это время, концентрация и деньги.
Готовность слушать всех и просить помощь зала. Аналитик часто самый слабый спец во всем. Технически он слабее любого дева, в бизнесе все равно шaрит меньше чем SME, в дизайне ... и так во всем. Аналитик не должен брать на себя, он должен собирать все мнения и помогать выйти на решение
В точку!
Возникло некоторое искажение при прочтении статьи, что аналитик либо плохой, либо хороший. Я бы добавил, что всё всегда зависит от тех задач и конфигурации команды, на которую аналитик ищется.
По технике. Например, вводная:
- аналитик любит упарываться в технику, принимать архитектурные решения,
- в команде есть человек в чьей ЗО лежит выбор и принятие архитектурных решений (например, техлид, архитектор, или ведущий аналитик)
- основная потребность в команде от аналитика -- помощь в разработке требований и команде нужно более продуктовое влияние от аналитика (помощь с исследованиями, поиском решений)
В такой ситуации можно ждать беды, характер который можно предсказать в зависимости от портретов по модели Белбина (например). Высокий риск того, что продуктовое качество решений пострадает, а задачи будут застревать в дискуссиях. Особенно это важно при том, что аналитик в технике понимает гораздо меньше, чем техлид.
Из моего опыта -- знаю кейс, как однажды такое совпадение привело к тому, что команда разработки перестала пользоваться постановками от аналитика (читала общие детали, но не саму постановку).
Похожий пример могу привести про нестандартное мышление (которое попало в аналитический склад ума). Например, от джуна ждут скорее проактивности в обучении, а не поиске креативных решений. В выборе между менее креативным, но более исполнительным и мотивированным на обучение и более креативным джуном с высоким уровнем уверенности (эффект Даннинга-Крюгера никто не отменял) я зачастую выберу первого, потому что креатив и уверенность второго будет мешать принятию решений. Креативность придет с насмотренностью, а вот "хладнокровие" воспитать быстро не получится)
Общие скиллы всегда понятны, но под каждый конкретный запрос требования к скиллам довольно сильно отличаются и немного режет глаз, что кого-то из-за этого можно называть плохим)))
Сергей, привет! Рад тебя снова видеть тут)
Да, возможно я не до конца довел мысль про то, что все рассмотренные примеры «плохих» и «хороших» аналитиков - это сугубо субъективная оценка работодателя-собеседующего. Некие уайт и редфлаги, и я их попытался обобщить. Дело это конечно неблагодарное, потому что ситуаций куча разных (которую ты в общем-то и описал по тексту).
В первом твоем кейсе вопрос критично стоит в том, что аналитик твой как будто независимая единица, которая сама себе задачи ставит и живет в отрыве от команды. Это мое впечатление такое) Для этого и должно быть руководитель, который такую единицу возьмет и определит фокус на том, что делать «надо», а не то, что она «любит».
Во втором про хладнокровного - отчасти соглашусь. Если это джун. В миддлах+ бывает этой «искры» не хватает, дабы быть фасилитатором встреч тех же. Хотя при желании вполне такие хладнокровные могут на место любого уверенного поставить, вспоминаю сразу безопасников в сбере))
Добрый день!
Недавно начал ознакомление с профессией СА. Пока все очень нравится, но на различных платформах не раз наткнулся на тезис мол, до захода на позицию СА, уже должен быть какой-то опыт работы в айти. Именно работы. Насколько этот тезис правдив/уместен? Стоит ли выбирать профессию СА как стартовую? Заранее спасибо)
Добрый день!
Мне очень понравился твой вопрос, и я более подробно на него отвечу у себя в канале.
Если вкратце - да, работодатель всегда будет давать предпочтение кандидату с опытом в айти, нежели без опыта. Это вполне логично. Но дальше идут куча факторов и детальный разбор профиля кандидата, в ходе которого рекрутер принимает решение, звать ли его на собеседование или нет. Вот про них я в воскресенье пост напишу.
А насчет стоит ли выбирать СА как стартовую профессию? Мой ответ, да, стоит, главное чтобы была внутренняя искра и желание учиться и погружаться в технику. Ибо даже в анализе есть достаточно хард скиллов, которые необходимо освоить.
"Проведя глубокую аналитику текущего процесса и используя методы визуализации данных аналитик смог предложить новый подход к оптимизации бизнес-процесса, который не был ранее реализован в организации."
Вроде про системного аналитика речь, почему он должен придумывать отпимизацию бизнес-процессов?
"На проекте при проработке бизнес-требований системный аналитик смог предложить оптимальную архитектуру будущей системы, учитывая существующее legacy-решение и технические ограничения. "
То есть в процессе проработки бизнес-требований системный аналитик придумывает архитектуру. Просто кккомбо какое-то. У вас системный аналитик выполняет роль и бизнес-аналитика и архитектора?
Добрый день!
Да, такое бывает. И я считаю это нормальным.
Я в двух компаниях совмещал данные роли. Позиция называлась аналитик. Я про это много на канале рассуждал. Почитайте вот этот пост.
Как отличить хорошего аналитика от плохого?