Кейсовые вопросы. Часть 2
Привет. Сегодня - последняя часть вопросов с собеседований. Будут и кейсы и просто вопросы, которые могут быть интересными в зависимости от контекста собеседования.
1️⃣ Тихая диагностика
Цель кейса - понять, как и что может узнать кандидат, не разговаривая с командой. Почему это важно? Ведь 1:1 тоже вполне себе инструмент. Мне важно понять, что из осязаемого и объективного кандидат может посмотреть. Как он может оценить текущее состояние. В ходе кейса какие-то ответы требуют большего погружения - тогда погружаемся.
Ты только что устроился в компанию. У тебя первый день в новой роли. Тебе выдали технику. На ней настроены все доступы: Jira, Confluence, почта, zoom, рабочие мессенджеры - все, что нужно. У тебя уже подписаны все документы для кадров, пройдены все обучения по охране труда (предположим, что это возможно). В этот же день была установочная встреча, на которой тебя представили команде. Все с тобой поздоровались и попривествовали. Все теперь про тебя знают, твою роль тоже знают. Все чаты командных встреч уже у тебя в календаре - если ты туда придешь, то никто не удивится.
Через месяц твои СРО/СТО ждут от тебя рекомендации и выводы о работе команды. Куда полезешь, что будешь смотреть и для чего?
Что будешь смотреть, чтобы по итогу месяца предоставить наблюдения?
Ты не можешь ни с кем разговаривать. Не можешь ставить 1:1, проводить командные встречи. Можешь только ходить на встречи (как и говорил ранее - ты уже добавлен в них, тебя представили). Срок - через 1 месяц. Ограничение по времени так же дает понять, насколько опыт кандидата позволяет оценить объем работы для диагностики. В ответе важно понять, что реально будет смотреть кандидат, а не что в целом было бы прикольно понаблюдать.
Что предлагают посмотреть кандидаты:
💬 "Посмотрю, как проходят командные мероприятия"
Важно, что именно кандидат на них смотрит.
💭"Как проводятся и проводятся ли мероприятия".
💭"Сколько длится дейли. Если больше 15 минут - все плохо"
Это тоже дает мало информации. Допустим - дейли 30 минут, но первые 15 минут говорят про бэклог Спринта, а вторые - про синхронизацию с другими командами. Плохо? Да не факт. До сих пор не могу понять, почему так цепляются за эти 15 минут без разбора причин. Можно и 15 минут провести абсолютно бесполезно.
💭"Есть ретро или нет. Если есть - в каком формате проводится"
Может быть полезно, но так же важно понять, что обсуждают, делают ли что-то с результатами ретро. Например, может быть более полезным посмотреть результаты с предыдущих ретро. Посмотреть, выполнилось ли что-то из этого"
💭"Сколько длится планирование?"
Это предлагает не так много кандидатов. Хотя, с учетом ограничения на общение, может быть важным источником информации. Здесь я спрашиваю - что именно, как и для чего будет смотреть кандидат. Например, T2M сам по себе может быть менее ценным. То, как ведется доска, бэклог, гигиена Jira (прокликиваются ли статусы) - более ценным. Если на этом этапе спрашивать больше подробностей - можно узнать, работал ли кандидат с данными или только со стандартными графиками (на них есть далеко не вся полезная информация). Например, часть кандидатов говорит, что в работе использовали только дэшборды, созданные в компании. Но в другой компании даже если они и будут - скорее всего будут настроены по другому. На мой взгляд, важно уметь выгрузить все в excel и там при необходимости построить те срезы, которые нужно.
💬 "Посмотрю стратегию и видение развития продукта, продуктовые метрики"
Полезно, но так ли это важно на первом этапе? В кейсе есть ограничение в 1 месяц. В моем опыте стратегия и видение - это точно то, что нужно обсуждать, уточнять. Если посмотреть только на слайды - будет мало понятного.
💬 "Посмотрю деплои, CI/CD, процесс код ревью, покрытия тестами" и прочие технические слова.
Из всех кандидатов, которые озвучили такие предложения, только несколько на самом деле знают, как это делать практически.
🧩 Почему я предлагаю этот кейс? И что с ним делать тебе?
Есть случаи, когда важно начать работать, но у команды прямо сейчас нет времени (пожар, релиз, что угодно лишь бы с нами не говорить). Я убежден, что много информации можно собрать из доступных источников. Гипотезы можно собрать из текущего состояния мероприятий как операционного ритма, процесса в Jira и метрик производственного процесса. Если ты опытный агент изменений - этого может быть более чем достаточно для старта. Ограничение в месяц - для того, чтобы ограничить “а еще можно вот это сделать”. Можно до бесконечности смотреть и искать, но зарплату не только за это платят). Опытный кандидат с меньшей вероятностью предложит то, что даст ему мало информации. Ну и углубляясь в ответы можно попробовать узнать, делал ли на самом деле кандидат то, что предлагает (как с предложениями по CI/CD). Можешь попробовать ответить на этот вопрос сам или предложить другому скрам-мастеру с соседнего продукта-команды сделать друг у друга такие тихие диагностики. Для команды будет минимум отвлечений, а вы сможете поделиться идеями.
2️⃣ Конфликт на ретро
Эта ситуация произошла со мной 5 лет назад. Тогда я не справился со своей задачей. Но этот опыт мне запомнился надолго, уроки я вынес). Ситуация нетиповая - тут не про правильно/неправильно. Больше - про то, как понимается ретро кандидатом.
Ретро, ты его проводишь. Ретро проходит в очном формате. В углу переговорки шушукаются и о чем-то спорят senior-fullstack разработчик и frontend-разработчик. Ты пару раз обращаешь на них внимание и возвращаешь к теме ретроспективы. Через 5 минут frontend-разработчик выбегает в слезах за дверь. Fullstack - пожимает плечами. Гробовая тишина. Вся команда сидит и смотрит на тебя.
Что будешь делать в этой ситуации? Не потом, не после ретро, а именно в моменте.
Этим кейсом просто смотрю, как кандидат относится к ретро.
Потому, что у нас конфликт 2 людей. Но по сути - это конфликт, который влияет на всю команду. Причины конфликта могут выходить за пределы этих двоих. Мне кажется, просто так тормозить ретроспективу - лишиться возможности решить важную проблему. Другой вопрос - что сразу на лету перестроить фасилитацию дело непростое.
💬"Попрошу вернуться frontend-разработчика, у нас ретро и люди сидят ждут.”
Звучит как: ”это проблема frontend-разработчика. Пусть разберется со своими эмоциями.” В таком контексте - исключает влияние проблемы на весь процесс команды. Не скрамненько.
💬"Попрошу fullstack-разработчика тоже выйти и решить конфликт"
Звучит как: ”это проблема этих двоих. Пусть сначала разберутся, а потом уже к нам приходят”. В таком контексте - тоже не очень про цель ретроспективы.
💬"Продолжу ретро по намеченному сценарию"
Это говорит о том, что кандидат либо видит больше ценности в том, что он сделал и принес. Либо пока не готов так быстро перестраиваться
💬"Спрошу у команды, что делаем дальше"
Тут кандидат делает фокус на том, что это командная проблема. Что ретроспектива - это не “собственность” скрам-мастера, а общий инструмент.
🧩 Почему я предлагаю этот кейс? И что с ним делать тебе?
Это конечно не самое жесткое, что бывало, но в начале работы скрам-мастером было сложно в этой ситуации. Я 5 лет назад этого не осознавал и остановил ретроспективу. Вышел поговорить с frontend-разработчиком. После этого вернулся к команде и предложил разойтись. И решал конфликт уже в рамках 1:1. Конфликт был не только на уровне персоналий, но и на уровне процессов внутри и инструментов. Мог бы тогда на ретро затронуть важные вещи и возможно часть из них порешать. Как бы ты поступил? Может после этого вопросы ты переосмыслишь свое отношение к ретро.
3️⃣ Другие вопросы
Тут просто перечислю вопросы, которые иногда задаю на отвлечься, настроиться.
❓Если представить скрам-мастера как животное, вымышленного персонажа, героя Marvel и так далее - то кто это/что это на твой взгляд?
Вопрос не мой, подслушал у напарников по собеседованиям. Было несколько случаем, когда кандитаты отказывались отвечать, так как вопрос “не очень понятный и сложно вот так в метафоры”.
❓Показать пример кумулятивной диаграммы потока - какие наблюдения и выводы ты можешь сделать исходя из этого графика.
Если это график команды, в которой есть проблемы в работе с задачами, простои и так далее - это скорее всего можно увидеть.
❓Команда приходит с предложением перейти на канбан. Твои действия.
Вопрос больше про позицию скрам-мастера и про вопросы/аргументы, которые он будет использовать.
❓Что на твой взгляд самое сложное/неприятное в работе скрам-мастера?
Может кандидат больше всего не любит ковыряться в Jira, а команде сейчас нужно перестроить процесс и сделать аналитику. Или кандидат на самом деле не любит общаться с менеджментом, а текущая позиция предполагает много такого взаимодействия.
❓Расскажи определение продукта.
Задаю для того, чтобы выровняться. В некоторых продуктах неправильное понимание может очень негативно сказаться на взаимодействие с PO. На текущей работе например так обстоят дела с понятием “платформа”.
❓Кто получает больше всего пользы от работы скрам-мастера? почему?
Этим вопросом хочу понять, на каких уровнях мыслит канидидат. Говорит ли про уровень продукта и компании? говорит ли про уровень каждого из команды?
❓Может ли знание и применение коучинга мешать(!) в работе?
Один из моих любимых вопросов. Я сертифицированный коуч, но не разделяю позицию применения на работе этих навыков просто по умолчанию. Более того - работа скрам-мастера/agile-коуча в некоторой степени противоречит позиции коуча. В индивидуальном коучинге ты в первую очередь преследуешь цель своего клиента. Но что делать, если цель скажем PO явно противоречит целям компании? Этим вопросом пробую выловить “ярых адептов” коучинга везде и всем.
❓Как ты понимаешь слово “токсичность”? Что такое “токсичная команда” на твой взгляд? Что будешь делать, если увидел такие признаки в команде? Может ли токсичная команда быть эффективной?
Я часто работал с командами, которые по общим параметрам попадают под понятие “токсичность”. Плохо ли они работали? Не всегда. Сказывалось ли это на достижении их целей негативно? Не всегда. Вызывало ли это конфликты внутри команды? тоже не всегда. В команде просто может быть такой стиль общения. Мне обычно не составляет труда подстроиться и общаться в том формате, в котором комфортно в команде. Но есть скрам-мастера, кто уходит из команды потому, что там ругаются матом, говорят друг другу претензии и прочее. Этим вопросом и пытаюсь такое отловить.
