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

Проект временный и уникальный, а операционная деятельность непрерывна и повторяема.

• Проект представляет собой временную работу с чётким началом и концом ради конкретного результата, например запуска сайта или переезда офиса, и заканчивается, как только результат получен.
• Операционная деятельность состоит из постоянной, повторяющейся работы, которая держит бизнес на ходу, например расчёт зарплат или поддержка клиентов, без запланированного конца.
• Это различие важно, потому что проекты требуют временного планирования и поставки результата, а операционная деятельность требует стабильных, повторяемых процессов.

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

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

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

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

Объём проекта задаёт согласованные границы того, что команда поставит и что останется за рамками.

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

Расползание объёма означает неконтролируемый рост работ, а главным способом защиты служит понятный процесс изменений.

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

Обычно проект проходит инициацию и планирование, затем исполнение и контроль, после чего формально закрывается.

• Распространённый жизненный цикл включает инициацию, на которой проект определяют и одобряют, планирование, на котором уточняют объём, расписание, бюджет и риски, исполнение, на котором команда выполняет работу, и мониторинг и контроль, который идёт параллельно исполнению, чтобы отслеживать ход работ и вносить корректировки.
• Последней идёт фаза завершения, на которой передают результат, подводят итоги и фиксируют извлечённые уроки.
• Эти фазы дают проекту структуру от идеи до завершения.

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

• Устав проекта представляет собой короткий документ, который формально утверждает проект и даёт проджект-менеджеру полномочия использовать ресурсы.
• Он обычно содержит цель и задачи проекта, общие границы работ, ключевых стейкхолдеров, предварительный график и бюджет и основные риски или допущения.
• Он создаётся на старте и служит ориентиром для понимания того, чего должен достичь проект.

Описание работ достаточно подробно фиксирует работы и результаты, чтобы стороны договорились до старта.

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

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

• Поставляемый результат представляет собой конкретный итог проекта, например отчёт, дизайн или работающая функция продукта, то, что можно передать.
• Веха представляет собой значимую точку в расписании, которая часто отмечает завершение набора результатов и сама не имеет длительности.
• Иными словами, поставляемый результат создают и передают, а веха лишь отмечает момент в графике.

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

• Иерархическая структура работ разбивает весь проект на меньшие, управляемые части, от крупных поставляемых результатов до отдельных задач, необходимых для их получения.
• Она помогает, потому что гарантирует, что ничего не забыто, упрощает оценку и распределение работы и даёт ясную картину общего объёма усилий.
• Обычно это один из первых шагов планирования после определения объёма.

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

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

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

• Проект представляет собой одну временную работу ради конкретного результата.
• Программа объединяет группу связанных проектов, которыми управляют вместе ради более масштабной цели, недостижимой по отдельности, а портфель охватывает всю совокупность проектов и программ организации, которой управляют в соответствии со стратегией.
• Это возрастающие уровни масштаба: от одного проекта к группе связанных проектов и всей их совокупности.

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

• Я бы выявил ключевых стейкхолдеров и поговорил с ними, чтобы понять, что им нужно и почему, через интервью, воркшопы или изучение существующих документов.
• Я бы задавал вопросы, чтобы прояснить цель, зафиксировал требования письменно и предложил стейкхолдерам подтвердить их, чтобы убедиться, что понял верно.
• Итогом должен стать ясный, согласованный список того, какой результат должен дать проект, до планирования работы.

Функциональные требования определяют, что делает решение, а нефункциональные задают качество его работы.

• Функциональные требования описывают, что продукт или результат должен делать, конкретные функции или действия, например пользователь может сбросить пароль.
• Нефункциональные требования описывают, насколько хорошо решение должно работать, включая такие характеристики, как производительность, безопасность, надёжность и удобство.
• Важны оба, потому что фича, которая работает, но слишком медленна или небезопасна, всё равно не отвечает настоящей потребности.

Задокументированные требования дают команде единый доступный ориентир для разработки и приёмки.

• Документирование требований создаёт общий, согласованный ориентир, чтобы все исходили из единого понимания, и позволяет сверить финальный результат с тем, что просили.
• Незадокументированные требования остаются только в памяти участников, забываются и ведут к спорам о том, что было обещано.
• Я бы хранил их в общем, доступном месте вроде Confluence или документа требований, чтобы вся команда могла на них ссылаться и обновлять.

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

• Я бы не действовал на основе догадок, а задавал уточняющие вопросы, чтобы превратить размытые формулировки в конкретику и понять реальную потребность, стоящую за каждым запросом.
• Когда требования противоречат, я собираю стейкхолдеров, чтобы обсудить компромиссы и договориться о решении, а не тихо выбираю одну сторону.
• Цель состоит в том, чтобы получить ясный, согласованный набор требований, который все подтвердили.

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

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

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

• Запрос на изменение представляет собой формальное предложение поменять что-то уже согласованное, например объём, расписание или бюджет, после утверждения плана.
• Я обрабатываю его, оценивая влияние на время, стоимость и другую работу, обсуждая это со стейкхолдерами и получая ясное решение одобрить или отклонить до того, как что-то делать.
• Это позволяет принимать и документировать изменения, не допуская незаметного отклонения от плана.

Надёжное расписание объединяет оценки, зависимости, ответственных, даты, вехи и реальную доступность команды.

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

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

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