Кейс №4 от Пользователя. Задача из вакансии Менеджер проекта в Mail.ru

Кейс №4 от Пользователя. Задача из вакансии Менеджер проекта в Mail.ruПривет! Откопал в почте еще одно интересное письмо.  И еще один очередной Кейс от пользователя. Задачу прислал Роман К. Задача из тестового задания в компанию mail.ru. Свое решение задачи приложу чуть позже. Ждем ваших решений и комментариев.
Привет! Нужна помощь в решении управленческой задачи на должность Менеджера проектов. Задачи в открытом доступе нет, мне ее прислал HR.

Тестовое задание

Допустим, вы запланировали разработку крупной фичи, оценили сроки в 2 месяца, идет разработка. Через 6 недель Вы понимаете, что фичу надо запускать через 2 недели, а функционал совершенно не готов. Разработчики говорят, они не виноваты, просто всплыли непредвиденные сложности. Ваши действия в данной ситуации? Как надо поступать, чтобы предотвратить появление такой ситуации?

Ссылка на сайт компании здесь.

Буду  благодарен за любую помощь.

Запись опубликована в рубрике Кейсы от Пользователей. Добавьте в закладки постоянную ссылку.

2 комментария на «Кейс №4 от Пользователя. Задача из вакансии Менеджер проекта в Mail.ru»

  1. Мое решение:
    Ваши действия в данной ситуации?
    1. Сроки. «Просто всплыли непредвиденные сложности » — это еще не значит, что мы не успеваем в установленные сроки. Понять, успеваем ли мы сделать фичу в срок. Если не успеваем, то выяснить к какой дате успеем разработать?
    2. Сроки. Если не успеваем, поставить Владельца продукта в известность. Поинтересоваться, можем ли мы изменить дату релиза.
    3. Бюджет. Если дату двигать нельзя, пробуем выяснить, можно ли доработать нужный функционал путем увеличения ресурсов (разработчиков)- Этот способ обычно не работает, так как новому разработчику понадобится время на разбор и исследование. НО забывать про данный вариант тоже не стоит, возможно, есть специалист, который в этом хорошо разбирается и сможет помочь. — Если такой разработчик существует, и может помочь — необходимо договориться с руководителем о возможности выделения соответствующего разработчика на проект и согласовать увеличение бюджета с Владельцем продукта.
    4. Бюджет. Как вариант, договориться с разработчиками о переработках и согласовать переработки с Владельцем продукта.
    5. Содержание. Как вариант, сделать, чтобы хоть как-то работала фича (хаки, костыли), в ущерб красоте и скорости/производительность. Если этот вариант возможен, его нужно согласовывать с Владельцем продукта. В следующей версии продукта устранить баги и провести рефакторинг.
    6. Содержание. Если увеличение ресурсов не помогает, сроки не двигаются, а релиз сделать надо, то придется резать функционал. Смотрим, от каких запланированных работ и еще не реализованного функционала стоит отказаться и потратить время на доработку основной функциональности и исправлению багов.

    Как надо поступать, чтобы предотвратить появление такой ситуации?
    1. Заинтересовать, замотивировать разработчиков в проекте.
    2. Особое внимание нужно уделить этапу проектирования. Выявление рисков. Ошибки на данном этапе, намного проще и дешевле исправить, чем на последующих этапах разработки.
    3. Ежедневные, еженедельные статус митинги/собрания проектной команды. Менеджеру чаще навещать разработчиков, интересоваться состоянием дел. Своевременно выявлять баги.
    4. Правильно ставить задачи. Более сложные задачи, разбивать на мелкие подзадачи. Трудозатраты оценивает вся проектная команда.
    5. Применять agile-методологии (SCRUM). Важно знать производительность своей команды. И даже, несмотря на то, что это очень примерная величина, поможет нам спрогнозировать дату завершения проекта.
    6. Оценивать задачи всей проектной командой (planning poker)

    Роман, дайте знать если мое решение пригодилось Вам.

  2. Рома говорит:

    Владимир, спасибо!!!
    Если честно даже не ожидал, что вы мне ответите.
    Очень проработанный ответ, еще раз спасибо!

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *