вопросы на собеседовании проджект менеджера

В чём разница между Scrum и Kanban? Когда выбрать каждый?

Scrum работает фиксированными спринтами с зафиксированным объёмом, определёнными ролями и церемониями — он подходит продуктовой работе, где ритм планирования и обзора приносит пользу. Kanban это непрерывный поток с ограничением незавершённой работы и без спринтов, что подходит поддержке, сопровождению и всему, где приоритеты меняются ежедневно. Решающий вопрос — можете ли вы удержать скоуп стабильным две недели; если нет, церемонии Scrum превращаются в театр.

Как вы оцениваете? Что такое story points и planning poker?

Story points выражают относительный размер и сложность, а не часы, что избавляет от ложной точности временных оценок и учитывает разную скорость разных людей. В planning poker все оценивают одновременно, чтобы никто не якорился на самом громком мнении, и настоящая ценность — в обсуждении после расхождения. Прогнозировать по точкам можно только после нескольких спринтов, когда установилась velocity.

Что делать, если проект не успевает в дедлайн?

Поднимать вопрос сразу, как только вы это поняли, а не когда это станет неоспоримым — цена сюрприза намного выше цены плохой новости. Приходить нужно с вариантами, а не только с проблемой: урезанный скоуп, поэтапная поставка, добавление людей с учётом времени на их разгон или перенос даты, и у каждого варианта проговорены последствия. А дальше решение принимает тот, кто владеет этим компромиссом.

Как вы управляете рисками? Приведите пример.

Риски выявляют вместе с командой, заносят с вероятностью и влиянием, назначают владельца и прописывают меру снижения и триггер, говорящий, когда действовать. Конкретный пример — зависимость от стороннего API: мера это разработка против мока за интерфейсом, а триггер — отсутствие доступа к песочнице к определённой дате. Реестр рисков, который никто не пересматривает еженедельно, это документация, а не управление.

Что такое velocity и burndown chart? Как их использовать?

Velocity — это количество точек, которое команда закрывает за спринт, и полезна она как диапазон прогноза по нескольким спринтам, а не как одно число. Burndown показывает остаток работы во времени и в основном раскрывает форму: плоская линия в начале и обрыв в конце означают, что работу не интегрируют до последнего дня. Оба инструмента диагностические, для команды — использование velocity как цели по производительности гарантированно портит оценки.

Как вы решаете конфликты внутри команды?

Разбираться рано и сначала один на один, отделяя позицию каждого от стоящей за ней потребности. Большая часть технических конфликтов на самом деле про непроговорённые приоритеты — один оптимизирует срок поставки, другой поддерживаемость — и называние этого компромисса превращает ссору в решение. Если не разрешается, эскалировать тому, кто владеет компромиссом, а не давать конфликту тлеть.

Что делать, если клиент постоянно меняет требования?

Не бороться с изменениями, а сделать их стоимость видимой. Процесс change control, где каждый запрос получает оценку влияния на скоуп, сроки и бюджет, превращает спор в осознанный выбор, и клиенты обычно сами себя ограничивают, когда компромиссы явные. Частые изменения ещё и часто сигналят о недостаточном дискавери, поэтому более короткие циклы обратной связи и демо могут снять причину, а не симптом.

Как вы сообщаете клиенту плохие новости?

Рано, прямо, с посчитанным влиянием и приложенными вариантами. Начинать с сути и того, что это значит для клиента, а не с длинного захода, брать ответственность без чрезмерных извинений и быть конкретным в том, что вы сделаете и к какому сроку. Ущерб отношениям наносит почти исключительно позднее раскрытие, а не сама проблема.