MOC Interview for position IT Project Manager

Коротко о видео

Это мок-интервью на позицию IT Project Manager уровня примерно middle. Кандидат рассказывает о переходе из разработки через поддержку и внедрение в управление проектами и продуктом, а затем отвечает на вопросы о ролях PM и Product Owner, Scrum, Kanban, качестве, рисках, экономике и управлении командой. Интервьюер уточняет и корректирует ряд ответов, в частности различия между продуктовой и проектной работой, смысл Scrum, WIP-лимитов, технического долга и обеспечения качества.

Затронутые темы

Что взять на заметку

• Кандидат описывает свой опыт как смесь внедрения, интеграционных продуктов и проектного управления; с конечными пользователями он взаимодействовал мало, преимущественно общаясь с представителями заказчика и коллегами из других продуктов.
• В прежней продуктовой роли команда улучшала надёжность интеграционного продукта: отслеживала тайминги повторяющихся операций, локализовала медленные этапы, внедряла изменения и проверяла результат. Интервьюер отмечает, что в описании больше признаков работы PM, чем Product Manager.
• По объяснению интервьюера, Scrum полезен там, где ценность и потребности пользователей нельзя заранее полностью определить: команда выпускает инкременты, получает обратную связь и корректирует направление, а не только исполняет фиксированное ТЗ.
• В Kanban WIP-лимиты нужны для вытягивающей системы и выявления узких мест: задача не должна переходить на следующий этап, если там нет свободной ёмкости. Интервьюер приводит стартовую рекомендацию выбирать лимит около размера команды плюс один и затем корректировать его по данным команды.
• Для контроля проекта обсуждаются earned value, время ожидания или блокировки задач, flow efficiency, трудозатраты на гарантийное исправление дефектов и доля дефектов, найденных после выхода в production.
• Среди способов снизить escaped defects названы разделение окружений, code review, демонстрации, согласование и дополнение тест-кейсов с заказчиком, а также автоматизация тестов. Интервьюер отдельно подчёркивает: тестирование проверяет качество, но не создаёт его само по себе; качество начинается с ясных, тестируемых и недвусмысленных требований.
• В кейсах о рисках и дедлайне кандидат предлагает заранее эскалировать проблему, обсудить перенос сроков либо сократить и приоритизировать scope; интервьюер напоминает, что позднее добавление людей может замедлить проект из-за затрат на погружение и коммуникацию.