Роль и поведенческие кейсы
Ролевые и поведенческие кейсы, которые спрашивает каждое собеседование — системный против бизнес-аналитика, junior против senior, обоснование ценности аналитика, конфликт стейкхолдеров, неотзывчивый заказчик и объяснение ограничений.
11 вопросов
JuniorДизайнОчень частоСтейкхолдер бросает в чат команды однострочный запрос — «нужен дашборд» — без контекста, аудитории и цели и просит оценку к завтрашнему дню. Что вы как аналитик делаете первым, до любого дизайна и оценки? Разберите, как вы превращаете этот размытый запрос в рабочую задачу — с кем говорите, что спрашиваете и как избегаете догадок об объёме.
Стейкхолдер бросает в чат команды однострочный запрос — «нужен дашборд» — без контекста, аудитории и цели и просит оценку к завтрашнему дню. Что вы как аналитик делаете первым, до любого дизайна и оценки? Разберите, как вы превращаете этот размытый запрос в рабочую задачу — с кем говорите, что спрашиваете и как избегаете догадок об объёме.
Не оценивайте догадку. Сначала найдите, кому и зачем это нужно — цель за словом «дашборд». Затем выявите конкретику: какие решения он поддерживает, кто пользователи, какие данные. Оформите это в несколько требований, подтвердите и только потом оценивайте.
Типичные ошибки
- ✗Оценивать запрос до того, как известны его цель и пользователи
- ✗Пересылать размытый запрос разработчикам без всякого анализа
- ✗Догадываться об объёме вместо того, чтобы выявить его у стейкхолдера
Уточняющие вопросы
- →Какие вопросы быстрее всего вскрывают реальную цель за размытым запросом?
- →Как быть со стейкхолдером, который уходит от уточняющих вопросов?
JuniorДизайнОчень частоВладелец продукта (product owner) объясняет новое требование устно в пятиминутном разговоре в коридоре и ждёт его в следующем спринте. Вы не уверены, что представляете это одинаково. До начала разработки как вы подтверждаете, что ваше понимание совпадает с его пониманием? Опишите, что делаете, чтобы закрыть разрыв между сказанным и записанным.
Владелец продукта (product owner) объясняет новое требование устно в пятиминутном разговоре в коридоре и ждёт его в следующем спринте. Вы не уверены, что представляете это одинаково. До начала разработки как вы подтверждаете, что ваше понимание совпадает с его пониманием? Опишите, что делаете, чтобы закрыть разрыв между сказанным и записанным.
Перескажите своими словами и в конкретике — пример, макет или критерии приёмки — и попросите PO подтвердить или поправить. Письменное подтверждение надёжнее кивка. Проговорите крайние случаи и допущения; если он не согласен, вы поймали разрыв до кода.
Типичные ошибки
- ✗Считать устное объяснение понятым, не подтвердив его
- ✗Фиксировать дословную цитату вместо проверяемого пересказа
- ✗Начинать разработку до подтверждения общего понимания
Уточняющие вопросы
- →Какой артефакт лучше подтверждает общее понимание — пример, макет или критерии приёмки?
- →Как подтвердить понимание, не заставляя PO чувствовать себя на допросе?
JuniorДизайнЧастоВ середине спринта вы понимаете, что внешняя зависимость почти наверняка сдвинет обещанную функцию на неделю позже срока. Заказчик пока не знает. Как и когда вы сообщаете этот риск? Опишите, что вы говорите, насколько рано поднимаете тему и как подаёте это, чтобы разговор остался управляемым, а не превратился в нарушенное обещание.
В середине спринта вы понимаете, что внешняя зависимость почти наверняка сдвинет обещанную функцию на неделю позже срока. Заказчик пока не знает. Как и когда вы сообщаете этот риск? Опишите, что вы говорите, насколько рано поднимаете тему и как подаёте это, чтобы разговор остался управляемым, а не превратился в нарушенное обещание.
Поднимайте, как только достаточно уверены, а не у дедлайна. Изложите риск прямо — что затронуто, почему, вероятное влияние — затем принесите варианты: меньший объём в срок, полный объём позже или смягчение, с чёткой рекомендацией.
Типичные ошибки
- ✗Тянуть с плохой новостью, пока срок уже не сорван
- ✗Сообщать проблему без вариантов и рекомендации
- ✗Обещать срок и скрывать сдвиг за переработками
Уточняющие вопросы
- →Как оценить влияние риска, когда задержка ещё не определена?
- →Чем сообщение о риске внутренней команде отличается от внешнего заказчика?
MiddleДизайнЧастоПросматривая уже утверждённую спецификацию, вы замечаете, что два требования противоречат друг другу — одно гласит, что заказы ниже порога одобряются автоматически, другое — что каждый заказ требует ручного одобрения менеджера. Оба подписаны. Разработка стартует на следующей неделе. Что вы делаете, когда конфликт внутри самих написанных требований, а не между людьми? Опишите, как подтверждаете, разрешаете и фиксируете это.
Просматривая уже утверждённую спецификацию, вы замечаете, что два требования противоречат друг другу — одно гласит, что заказы ниже порога одобряются автоматически, другое — что каждый заказ требует ручного одобрения менеджера. Оба подписаны. Разработка стартует на следующей неделе. Что вы делаете, когда конфликт внутри самих написанных требований, а не между людьми? Опишите, как подтверждаете, разрешаете и фиксируете это.
Убедитесь, что это реальное противоречие, а не два смешанных контекста. Проследите требование до владельца и цели, сведите владельцев решить, какое правило побеждает или как сосуществуют, и зафиксируйте решение.
Типичные ошибки
- ✗Молча удалять одно требование, не вовлекая его владельца
- ✗Оставлять оба противоречащих требования на примирение разработчикам
- ✗Откладывать конфликт до тестирования вместо решения в спеке
Уточняющие вопросы
- →Как отличить настоящее противоречие от двух требований с разными допустимыми контекстами?
- →Какая практика ревью ловит такие противоречия до подписания?
MiddleДизайнЧастоВ бэклоге один пункт — «добавить модуль отчётности» — и команду просят спланировать его в этом спринте. Кроме заголовка деталей нет. Как вы декомпозируете эту размытую функцию во что-то, что команда может оценить и строить инкрементально? Опишите, как разбиваете её, что уточняете в первую очередь и как выбираете первый поставляемый срез.
В бэклоге один пункт — «добавить модуль отчётности» — и команду просят спланировать его в этом спринте. Кроме заголовка деталей нет. Как вы декомпозируете эту размытую функцию во что-то, что команда может оценить и строить инкрементально? Опишите, как разбиваете её, что уточняете в первую очередь и как выбираете первый поставляемый срез.
Сначала восстановите цель и пользователей, затем режьте по ценности, а не по слою. Превратите каждый отчёт — его данные, фильтры, права — в тонкий сквозной срез. Первым поставьте срез с высшей ценностью; оценивайте срезы, а не глыбу.
Типичные ошибки
- ✗Резать по техническому слою, из-за чего до конца нечего использовать
- ✗Оценивать весь модуль как один неделимый пункт
- ✗Обязываться на все отчёты до поставки первого среза
Уточняющие вопросы
- →Как выбрать, какой срез приносит ценность первым?
- →Насколько тонким может стать вертикальный срез, пока он ещё поставляемый?
MiddleДизайнЧастоСоседняя команда владеет API, от которого зависит ваша функция, и она не отвечает на запрос интеграции уже три спринта. Срок под угрозой, а ваши вежливые напоминания остаются без ответа. Эскалируете ли вы, и если да, то как — не превращая это в жалобу на людей? Опишите, как решаете, что пора, кого вовлекаете и как подаёте эскалацию, чтобы она осталась про блокер, а не про вину.
Соседняя команда владеет API, от которого зависит ваша функция, и она не отвечает на запрос интеграции уже три спринта. Срок под угрозой, а ваши вежливые напоминания остаются без ответа. Эскалируете ли вы, и если да, то как — не превращая это в жалобу на людей? Опишите, как решаете, что пора, кого вовлекаете и как подаёте эскалацию, чтобы она осталась про блокер, а не про вину.
Эскалируйте, когда уже пробовали напрямую, дали чёткий запрос и срок, а блок угрожает поставке. Держите фокус на риске, а не на людях: назовите зависимость, влияние на срок и нужное решение. Идите к тому, кто может разблокировать.
Типичные ошибки
- ✗Эскалировать на первый неотвеченный ответ, подавая это как вину
- ✗Никогда не эскалировать и тихо впитывать задержку
- ✗Обходить зависимость, не подняв блокер
Уточняющие вопросы
- →Что на деле должно содержать хорошее сообщение об эскалации?
- →Как сохранить отношения с командой-ровней после эскалации через их голову?
MiddleДизайнЧастоЗаказчик две недели не отвечает на уточняющие вопросы, несколько требований всё ещё открыты, а спринт стартует в понедельник, и команда ждёт работу. Получить подпись вовремя не выйдет. Как вы решаете, что команда строит, и как страхуетесь, если ваши допущения окажутся неверны? Опишите, как приоритизируете известный объём и действуете ответственно в этой тишине.
Заказчик две недели не отвечает на уточняющие вопросы, несколько требований всё ещё открыты, а спринт стартует в понедельник, и команда ждёт работу. Получить подпись вовремя не выйдет. Как вы решаете, что команда строит, и как страхуетесь, если ваши допущения окажутся неверны? Опишите, как приоритизируете известный объём и действуете ответственно в этой тишине.
Стройте сначала то, что ясно и малорисково; отложите всё, что упирается в открытые вопросы. Задокументируйте явные допущения и отправьте их как «вот что мы построим, если не скажете иначе». Ведите письменный след и параллельно эскалируйте тишину.
Типичные ошибки
- ✗Строить самые неопределённые пункты на догадке без фиксации допущений
- ✗Останавливать весь спринт вместо работы по ясному объёму
- ✗Самому утверждать требования и скрывать молчание заказчика
Уточняющие вопросы
- →Как ранжировать известный объём, когда ценность и риск указывают в разные стороны?
- →Как сформулировать допущение, чтобы молчание безопасно считалось молчаливым согласием?
MiddleДизайнЧастоНа второй день спринта старший стейкхолдер отзывает вас в сторону и просит команду «просто сделать наоборот» — напрямую противореча поведению, зафиксированному в подписанном техническом задании (ТЗ), под которое строит вся команда. Он ждёт, что это сделают тихо и быстро. Как вы работаете со стейкхолдером и запросом, не игнорируя его, но и не давая базовой линии дрейфовать бесконтрольно? Опишите свои шаги.
На второй день спринта старший стейкхолдер отзывает вас в сторону и просит команду «просто сделать наоборот» — напрямую противореча поведению, зафиксированному в подписанном техническом задании (ТЗ), под которое строит вся команда. Он ждёт, что это сделают тихо и быстро. Как вы работаете со стейкхолдером и запросом, не игнорируя его, но и не давая базовой линии дрейфовать бесконтрольно? Опишите свои шаги.
Не подчиняйтесь молча и не отказывайте. Отнеситесь к запросу как к изменению подписанной базовой линии, а не правке в коридоре. Уточните цель, оцените влияние, проведите через управление изменениями; для срочного — нужного утверждающего.
Типичные ошибки
- ✗Тихо реализовывать запрос против базовой линии от старшего голоса
- ✗Отказывать наотрез, не раскопав цель и не предложив путь изменения
- ✗Строить обе версии, чтобы избежать разговора, оставляя спеку устаревшей
Уточняющие вопросы
- →Что должно быть в лёгком запросе на изменение для срочной правки?
- →Как сохранить хорошие отношения, настаивая на управлении изменениями?
SeniorДизайнИногдаРазработчик говорит, что заданное вами требование «технически невозможно» и его нельзя построить. Бизнес на него рассчитывает, а вы сами не глубоко технический человек. Как вы проверяете, правда ли это, и что делаете дальше в каждом случае? Опишите, как прощупываете ограничение, отличаете жёсткий предел от дорогого или незнакомого и приводите требование к рабочему исходу, не продавливая ни разработчика, ни бизнес.
Разработчик говорит, что заданное вами требование «технически невозможно» и его нельзя построить. Бизнес на него рассчитывает, а вы сами не глубоко технический человек. Как вы проверяете, правда ли это, и что делаете дальше в каждом случае? Опишите, как прощупываете ограничение, отличаете жёсткий предел от дорогого или незнакомого и приводите требование к рабочему исходу, не продавливая ни разработчика, ни бизнес.
Отнеситесь к «невозможно» как к отправной точке, а не приговору. Спросите, что конкретно мешает — жёсткий предел, стоимость, нехватка навыка — и получите конкретную причину. Отделите «нельзя» от «дорого» или «незнакомо». Если предел реален, несите варианты бизнесу.
Типичные ошибки
- ✗Принимать «невозможно» на веру без конкретной причины
- ✗Продавливать разработчика и навязывать исходное требование
- ✗Путать реальный жёсткий предел с просто дорогим или незнакомым
Уточняющие вопросы
- →Какие вопросы отделяют настоящий предел от дорогого обходного пути?
- →Как привлечь второе техническое мнение, не подрывая первого разработчика?
SeniorДизайнИногдаОпишите реальную вашу собственную аналитическую ошибку, дошедшую до продакшена — упущенное требование, неоднозначную спеку, непроверенное допущение — которая вызвала заметную проблему. Какова была цена, как её поймали и, что важнее, что вы изменили в своей работе, чтобы такой же класс ошибки не повторился? Сосредоточьтесь на системном исправлении, а не на извинении.
Опишите реальную вашу собственную аналитическую ошибку, дошедшую до продакшена — упущенное требование, неоднозначную спеку, непроверенное допущение — которая вызвала заметную проблему. Какова была цена, как её поймали и, что важнее, что вы изменили в своей работе, чтобы такой же класс ошибки не повторился? Сосредоточьтесь на системном исправлении, а не на извинении.
Признайте конкретную ошибку и влияние честно, затем сосредоточьтесь на системном исправлении, а не на вине. Причина обычно — непроверенное допущение или неоднозначное требование. Измените процесс — ревью или критерии приёмки — чтобы предотвратить весь класс ошибки.
Типичные ошибки
- ✗Отрицать любую ошибку или винить разработчиков и тестировщиков
- ✗Латать единственный случай без изменения процесса
- ✗Перегибать в тяжёлый процесс на всём подряд
Уточняющие вопросы
- →Как решить, должно ли исправление быть изменением процесса или разовым?
- →Как поделиться уроком из ошибки, не обвиняя команду?
SeniorДизайнРедкоСкептичный заказчик бросает вам вызов напрямую — «разработчики могут говорить со мной сами; докажите, что аналитик на этом проекте мне вообще нужен». У вас один разговор, чтобы обосновать. Как вы оправдываете роль в терминах, которые заказчику реально важны — стоимость, риск и поставка — а не перечислением задач, что вы выполняете? Опишите аргумент и конкретную ценность, на которую указываете.
Скептичный заказчик бросает вам вызов напрямую — «разработчики могут говорить со мной сами; докажите, что аналитик на этом проекте мне вообще нужен». У вас один разговор, чтобы обосновать. Как вы оправдываете роль в терминах, которые заказчику реально важны — стоимость, риск и поставка — а не перечислением задач, что вы выполняете? Опишите аргумент и конкретную ценность, на которую указываете.
Спорьте в терминах заказчика — деньги и риск, а не должности. Без аналитика разработчики переводят нужды урывками, поэтому неоднозначность доходит до кода и правится поздно. Аналитик срезает переделки, держит один источник требований и освобождает разработчиков строить.
Типичные ошибки
- ✗Защищать роль перечислением артефактов или ссылкой на методологию
- ✗Уступать, что роль не нужна, вместо обоснования ценности
- ✗Подавать аналитика как привратника, что блокирует прямое общение
Уточняющие вопросы
- →Как бы вы доказали ценность аналитика на одном срезе работы?
- →Какая метрика лучше показывает цену неоднозначности, дошедшей до разработки?
