В этой статье хочу суммировать свой опыт в рамках прохождения интервью на роль руководителя проекта, программы, продукта и прочие позиции для менеджера в ИТ. В течение 2017 года мне довелось поучаствовать в качестве кандидата во многих интервью (думаю около 35 точно было) и я сформировал список наиболее популярных вопросов и тем для обсуждения. При этом самый интересный момент был в том, что часто в процессе собеседования на позицию "классического проектного менеджера" (PMBOK like) и, например, Scrum мастера интервьюеры спрашивали более или менее одно и то же.
Оставлю за рамками общие вопросы, которые задают всем кандидатам, остановлюсь только на том, что специфично для роли руководителя. Итак, что чаще всего спрашивают на собеседовании у соискателя позиции ИТ менеджера (назову эту роль так для обобщения)? Разделю все пункты на «вопросы» и «кейсы». Правильного ответа или какого-то единственно верного решения у них нет, поэтому ниже только сами темы, чтобы было от чего отталкиваться и над чем подумать перед интервью:
- Вопрос: Что такое критический путь? Что будет, если одна из задач лежащая на критическом пути затянулась по срокам? Может ли быть несколько критических путей у проекта?
Почему-то для многих интервьюеров этот вопрос очень принципиальный и они делят кандидатов на тех, кто «знает про критический путь» и тех, кто нет. Получается некий индикатор для отсева хотя ничего сложного в вопросе нет и, на мой взгляд, о реальном управленческом опыте он говорит мало. Эта тема скорее из области теории и здравого смысла, разобраться с которой можно даже при помощи Википедии. - Вопрос: Расскажите про ваш самый большой провал? Каковы были причины и как выходили из ситуации?
- Вопрос: Опишите ваше наиболее значимое профессиональное достижение? Почему вы выделяете именно его?
- Вопрос: Какие бывают типы контрактов для организация проектной деятельности и с какими довелось поработать? Чем отличаются подходы Time&Materials от Fixed Price, какие у них плюсы, минусы и области применения?
- Вопрос: С чего начать работу в новой команде \ с новым проектом? Какие вопросы необходимо выяснить в первую очередь, чтобы приступить к задачам?
- Вопрос: Как оценивать успешность проекта, эффективность команды или качество продукта? Какие существуют метрики для оценки состояния дел на проекте и что доводилось использовать вам?
- Вопрос: Какие существуют модели процесса разработки ПО, с чем довелось поработать? В чем основные отличия каскадной модели (Waterfall) от итеративной (Agile), какие у них плюсы и минусы, когда следует применять ту или иную методологию?
- Вопрос: Как работать с рисками на проекте? Как выявлять и оценивать риски, какие существуют этапы работы с ними, какие решения могут быть приняты по тому или иному риску?
Это также для многих интервьюеров своего рода вопрос-маркер. Не работал с рисками – не ПМ - Вопрос: Какие вы знаете техники оценки времени и подходы для планирования бюджета?
Техник множество и выбор конечно будет зависеть от ситуации, но как обычно лучшей выбор – это сочетание нескольких подходов. Я разбирал различные методы оценки в статье Agile in IT: 7 техник оценки задач. А тут рассматривал прогнозирование бюджета: 6 методов оценки сроков и стоимости проекта. - Кейс: Возникла ситуация, при которой решено расстаться с сотрудником. Например, он не устраивает нас как специалист, этот вопрос неоднократно обсуждали, планы по исправлению ситуации отрабатывали, шансы давали. Теперь решение принято окончательно – нужно расставаться. Как можно построить процесс коммуникации для и увольнения, кого для этого можно привлечь? Как был выстроен процесс увольнения у вас?
- Кейс: Сотрудник игнорирует или не воспринимает серьезно какой-либо элемент командной работы. Например, он не ходит на ежедневные стэндапы, т.к. не видит в них смысла, считает пустой тратой времени. При этом как к специалисту к нему претензий нет, свои задачи он решает отлично. Как построить диалог с таким сотрудником, что может послужить для него аргументом в пользу участия в стэндапе? Что делать, если договориться не получилось?
- Кейс: Два разработчика из команды предлагают разные решения одной задачи и нужно выбрать более оптимальное. Естественно выбор нужно сделать максимально объективно, основываясь на достоинствах каждого решения и при этом никого не обидеть. Какие варианты тут могут быть, как лучше осуществить выбор?
- Кейс: Мы меняем культуру организации, переходим к гибким методологиям разработки и Как объяснить представителям бизнеса, заказчикам и другим не-ИТ стейкхолдерам, что такое story points, зачем они нужны и почему мы не будем делать оценку в часах?
Фактически нужно «продать» идею оценки в абстрактных единицах, подсветить ее выгоды для стейкхолдеров. - Кейс: Заказчик хочет добавить новую задачу в уже существующий зафиксированный список работ. При этом часть ранее выбранных задач команда уже начала разрабатывать, время потрачено, силы вложены. Как отрабатывать этот кейс: как решить берем или нет новую задачу в работу, как коммуницировать ситуацию на команду, что делать с текущим скоупом? Можно ли избежать подобных случаев в будущем?
- Кейс: У Заказчика есть много идей по развитию бизнеса или продукта, но нет сформулированных и хоть сколько-нибудь четких требований. Необходимо выяснить потребности Заказчика, задать правильные вопросы, понять чем можно помочь в этой ситуации. В идеале, нужно сформировать общий список задач и построить предварительную дорожную карту работ. Как это можно сделать?
Про это я тоже писал, тут может быть довольно эффективен Impact Mapping. - Кейс: Возникла конфликтная ситуация между членами команды или с заказчиком. Например, происходит эмоциональная перепалка в open-space с переходом на личности. Что делать в этом случае: какие будут первые шаги, как далее отрабатывать ситуацию? Были ли подобные кейсы в практике и как они решались?
Наверное это самые популярные вопросы и кейсы. Как минимум несколько пунктов из этого списка точно всплывали на каждом интервью.