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

На собеседованиях спрашивают примерно одно и то же. В 2-х случаях из 3-х вас вначале попросят рассказать о себе. Меня настолько задолбал этот момент, что я сделал письменную версию этого рассказа и засылаю его рекрутеру перед собеседованием с пометкой, что если он это прочтёт, это сильно сократит время собеседования.

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

Кроме того, вот вам хороший совет.

Пожалуйста, не называйте пиэмбок пиэмбуком, скорее всего, с вами тут же мысленно попрощаются. Нет никакого PMBOOK, есть PMBoK, Project Management Body of Knowledge.

Почему ушли с прошлого места работы?

Всех задолбавший вопрос, задаваемый на 100 % собеседований, честным ответом на который в 50 % случаев будет: «Зажали повышение зарплаты на сто долларов», и ещё в 50 % «Начальник — чудак». Однако есть нормы этикета, так отвечать нельзя, как и нельзя откровенно хаять предыдущее место работы, даже если оно было той ещё галерой. Если не можете придумать ничего корректного, скажите: «На этом месте работы я достиг своего потолка, дальнейшего развития не предвидится, а я хочу двигаться дальше»

Что такое проект?

Это ограниченное по времени, бюджету и содержанию предприятие, направленное на получение уникального результата. В айти результатом проекта обычно (но не всегда) является продукт.

Чем проект отличается от процесса?

Процессом называются повторяющиеся операции, результат которых стандартизован. У проекта выше неопределённость и выше риски, зачастую не до конца определён результат.

Результатом проекта может быть новый автомобиль. От проектирования до получения опытного образца.

Результатом процесса может быть конвейерная сборка автомобиля с предыдущего шага.

Какие есть основные артефакты для управления проектом?

Универсального набора артефактов нет. Можно выделить такие:

• Устав или паспорт проекта.
• Договор и допсоглашение.
• Техническое задание.
• Коммерческое предложение.
• План управления проектом.
• Реестр рисков.
• Реестр заинтересованных сторон.
• План коммуникаций.
• Роадмапы и планы-графики.
• Всевозможные отчёты по статусам.
• Протоколы встреч.
• Акт приёмки выполненных работ.
• Программа и методика испытаний.
• Руководство пользователя и администратора.

Совершенно не значит, что на вашем проекте обязательно должны быть они все.

Как работает треугольник ограничений?

Стороны треугольника — сроки, бюджет, содержание. Они связаны и их сочетание важно для успеха проекта. Площадью этого треугольника является качество. При расползании треугольника, качество страдает в первую очередь.

Что входит в отчётную документацию по проекту, для чего она используется?

Набор отчётов на каждом проекте разный. Отчёт предназначен для повышения прозрачности работы команды и того, что происходит в проекте.

• Дейли репорты.
• Еженедельные и ежемесячные отчёты.
• Отчёты по рискам.
• Отчёты по прогнозу и соблюдению бюджетов.

Обязательно нужно уточнять, какие отчёты нужны заказчику и какой набор сведений должен быть в каждом из них. Всё это обсуждается на стадии инициации или планирования.

Как можно узнать, что проект пошёл не по плану?

У вас должен быть гант с расписанием, по нему чётко видно, успеваем мы или нет.

Можно применить метод освоенного объёма. К сожалению, метод работает, когда уже выполнено не менее 15 % задач из бэклога. Чем больше, тем стата точнее. Также у вас должен быть бэклог и он должен быть очень качественно декомпозирован. Также вы должны чётко понимать свои косты.

Есть канбановская практика, называется Cycle Time, это когда мы замеряем время выполнения каждого этапа работ, от взятия задачи в работу, до завершения. Так можно увидеть зависшие задачи. Применяется далеко не на каждом проекте.

Есть также такая штука как накопительная диаграмма потока. По ней тоже можно диагностировать.

Если работаем по скраму, есть диаграмма сгорания задачи и велосити.

Какое ПО вы реально используете в работе, что в нём делаете?

Читайте мою статью про софт пиэма.

• Для коммуникаций — любые мессенджеры.
• Для распределения задач — трекинговые системы. Джира, Редмайн, Кликап, Трелло, Яндекс Трекер.
• Для отчётов — эксель и гуглотаблицы. Майкрософт прожект часто применяется.
• Для ретроспектив — очень хорош Миро.

Как оценить риски на проекте?

• Прежде, чем их оценивать, их надо выявить (заказчика нужно обязательно привлекать к этому этапу).
• Потом нужно провести качественный и количественный анализ рисков.
• Потом надо продумать мероприятия по митигации рисков.
• Потом надо мониторить и контролить риски.

Качественный анализ нужен для приоритизации рисков. Применяется матрица рисков, по одной оси степень воздействия, по второй вероятность. Так определяются четыре категории рисков по влиянию.

Количественный анализ на практике применяется сильно реже.

Реестр рисков тоже на каждом проекте свой, но проектный офис может сформировать перечень типовых для проектов данной компании рисков.

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

Триггер — как понять, что риск стал проблемой.

План Б — что делать, чтобы снизить воздействие, если он сработал.

Очень плохо, когда ответственный за все риски ПМ. Ответственными могут быть также члены команды или заказчик.

Какие ваши действия при заходе на новый проект?

Читайте статью про шаги пиэма на новом месте работы.

Сначала желательно узнать, почему пиэм меняется. Нужно сформулировать цель, с которой вы заходите на проект. Узнать стек технологий, что за команда, кто заказчик, кто спонсор, кто стейхолдеры.

Пообщаться с пиэмом, который вёл проект до вас. Понять, какие немедленные действия нужно произвести.

После того, как вас представили команде, очень важно поговорить с каждым сотрудником, понять, что в команде происходит, какие боли.

Какие есть способы оценить проект?

Читайте статью про методы оценки.

Что будете делать, если поймёте, что не укладываетесь в сроки?

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

Ещё на эту тему можно рассказать:

• Распараллелить всё, что можно, в частности, фронтенд и бэкенд можно делать одновременно. Легальный способ сжатия расписания, но вам лично придётся больше коммуницировать и координировать, плюс повышаются риски. Этот метод называется Fast Tracking.
• Провести переоценку. Часто оценка делается до того, как детально проработаны все требования и её можно уменьшить с учётом новых знаний. Иногда подключение эксперта позволяет выявить участки, на которых менее опытный сотрудник решил перезаложиться.
• Урезать работы. Выкинуть ненужное, перенести его за пределы данного релиза.
• Урезать качество. Отказаться от некоторых видов тестирования. Не самый хороший путь, но это тоже метод.
• Привлечь в команду дополнительных специалистов того же уровня, что и имеющиеся или вообще, привлечь эксперта. Это увеличит стоимость проекта, но поможет сжать расписание. Однако нельзя забывать про закон убывающей предельной полезности. Метод называется Crashing.
• Сделать расписание с переработками. Запланировать больше часов в неделю, заставить сотрудников работать на выходных. Ведёт к выгоранию сотрудников и увольнениям. С переработками можно работать 3-4 недели, потом производительность упадёт. Если причина просрочки в изменениях, пришедших в середине проекта, можно отказаться от этих изменений.

Что будете делать, если за пару дней до релиза заказчик выкатил вам десяток новых фич, которые нужно сделать срочно и ВНЕЗАПНО?

В реальной ситуации заказчика нужно очень корректно и грамотно послать, но у HR-а записан в голове правильный ответ, который и нужно озвучить, а именно:

• Поговорить с заказчиком, выбрать самые важные, которые можно успеть.
• Подключить людей с другого проекта.
• Делегировать часть работы фрилансерам.

Разработчики оценили проект в 300 часов, а заказчик хочет, чтобы было 150.

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

Социально приемлемый ответ: «Надо посмотреть, что запланировали разработчики. Возможно, они хотят сделать сложную архитектуру, которая в данном случае абсолютно не нужна, а время съест много»

Что будете делать, если выяснится, что не успеваете протестировать?

В этой ситуации правдивый ответ совпадает с приемлемым для HR-а. «Посажу программистов тестировать вместе с тестировщиками, чтобы проверяли модули друг друга».

Чем хотите заниматься, какая работа вам интересна?

Ответ зависит от вакансии. Можно сказать: «Хочу делать качественные и востребованные потребителями продукты».

Вы сегодня уезжаете в отпуск, а на проекте проблема. Что будете делать?

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

Какими метриками вы можете измерять производительность команды?

Команда девопсов гугл под названием DORA, выделяет следующие метрики:

• Deployment Frequency — частота поставки;
• Lead Time for Changes — время от коммита до релиза;
• Change Failure Rate — количество багов на релиз;
• Time to Restore Service — время на фикс бага в проде.

В целом, этих метрик достаточно, чтобы оценить производительность команды. Ещё можно назвать канбан-метрики:

• Незавершенную работу (WIP): количество рабочих элементов, работа над которыми начата, но ещё не завершена. Команда может использовать метрику WIP, чтобы обеспечить прозрачность своего прогресса в сокращении WIP и улучшении своего потока. Обратите внимание, что существует разница между метрикой WIP и правилами, которые Scrum Team использует для ограничения WIP.
• Время цикла: время, прошедшее между началом и завершением работы над рабочим элементом.
• Возраст рабочего элемента: время между моментом, когда рабочий элемент попал в систему, и текущим временем. Это относится только к тем элементам, которые еще не завершены.
• Пропускную способность: количество рабочих элементов, завершенных за единицу времени. 

Когда были введены основные фреймворки и методологии управления проектами?

• Водопад. Был описан Уинстоном Райсом 1970 г. 
• Аджайл манифест появился в феврале 2001 г.
• Скрам Гайд появился в 2009 г. Кен Швабер.
• Канбан в айти появился в 2007, Андерсен.

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

Перескажите эту статью.

Как правильно ставить задачи?

От вас ждут две аббревиатуры, SMART и TOTE. Про SMART читайте статью по ссылке.

TOTE – это альтернативная методология постановки задач. Модель ориентирована на постановку задач программистам, так как работает по принципам алгоритма, но и для взаимодействия с сотрудниками и подрядчиками других специальностей тоже подойдет. Особенно полезна для работы с новичками, так как раскладывает задачу и процесс работы над ней по полочкам.

В отличие от метода SMART, здесь буквы аббревиатуры обозначают не критерии, а главы ТЗ и отчасти этапы работы над задачей:

• Test1 – какой результат нужно получить или что конкретно сделать;
• Operation – какие действия нужно выполнить, чтобы получить результат;
• Test2 – как мы поймем, что двигаемся к результату;
• Exit – как мы поймем, что достигли результата.

Какие существуют основные документы аналитики?

План аналитики — док для формирования общего видения процесса аналитики на проекте. Соглашение о том, как аналитик будет строить свою работу. Готовится перед стартом каждого проекта. Согласуется с командой и заказчиком. 

• Описание проекта. Цель, бизнес цель, модули. 
• Участники этапа аналитики. Наши и заказчика. С ФИО, контактами и часами доступа. 
• Задачи, которые будут решать эти люди. 
• Порядок аналитики. Как фиксируем инфу, частота встреч, временные слоты. Этапность. 
• Перечень артефактов. Митинг репорты, реестр рисков, матрица трассировки, все документы, которые будем реализовывать в рамках проекта. 

Реестр требований — док для фиксации собранных требований. Содержит иерархию требований и их взаимосвязи: бизнес → пользовательское → функциональное. В целом, пишется не так часто. Только на больших проектах. Если делается, то в конфлюшной таблице. 

ТЗ — общий док, в котором мы пишем всё, что связанное с проектом. 

Частное ТЗ — это когда мы по ватерфолу работаем и требуется расширение границ проекта (в основном, на госухе). На практике встречается редко. 

Тендерное ТЗ — верхнеуровневое ТЗ, чтобы участвовать в тендере. Цели проекта, характеристики проекта автоматизации, верхнеуровневые функциональные и нефункциональные требования. С ТТЗ в разработку пойти нельзя, оно недостаточно детализированное. 

Проектное решение — тоже пишется на госушном проекте и крайне редко. По сути, то же самое ТЗ, только с госовским уклоном, по 34 ГОСТу. 

Матрица трассировки — тоже инструмент для управления требований. В нём указываются все взаимосвязи требований с внешними артефактами. Обычно это связи между требованиями и кусками макета, который делают дизы заказчика. Шаблона у него нет. Пользовательское → Функциональное → Элемент дизайна → Указание, что должно быть, что есть по факту. 

Что знаете о маржинальности?

Маржа = Выручка – Переменные расходы

Маржинальность = Маржа/Выручка × 100 %

Наценка = Маржа / Переменные расходы × 100 %

Маржинальность показывает, сколько прибыли содержится в каждом заработанном рубле — то есть насколько эффективно бизнес продаёт свой товар или услугу.

Какие виды тестирования знаете?

• Модульные тесты
• Интеграционное тестирование
• Функциональные тесты
• Сквозные тесты
• Приемочное тестирование
• Тестирование производительности
• Smoke-тестирование

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

Вот вам ещё англоязычный документ на эту же тему: