Управление проектами.РУ

Управление проектами.РУ
Сообщество тех, кто умеет или хочет научиться
хорошо управлять проектами
05 февраля 2020 Из жизни РМа
10

Вопрос руководителю проекта на собеседовании

Юлия Бажанова
Редактор проекта, РМР, ICP-PPM

По мотивам недавней переписки с одним из читателей.

Читатель:

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

Ниже ситуация и вопрос:

Вы руководитель некоего проекта. Проект на стадии тестирования разработки, и вдруг Заказчик утверждает, что вы учли не все его требования, хотя они и не были отмечены в Функциональных требованиях. Например, требования были макроуровня и поэтому допускают  вольное толкование. Или просто Заказчик такой самодур. Ваши действия как руководителя проекта?

Как вам? Мне прямо понравился вопрос. Лично мне такой задачки на собеседованиях не попадалось, “правильного” ответа не знаю, однако как человек, который сам регулярно нанимает РМов – я уверена, что его и нет, и работодателю интересно посмотреть, как человек будет размышлять.

Я бы отвечала примерно так:

  1. Ну вообще я пишу четкие документы, критерии приемки, делаю промежуточные демо, поэтому вероятность такой ситуации не очень велика, я веду работу с рисками.
  2. Но если это случилось – предполагаю, что как профессиональный РМ – я знаю, насколько я могу “подвинуться”, есть ли у меня часы, бюджет и прочие возможности, чтобы эти хотелки закрыть.
  3. Оцениваю важность хороших отношений с Заказчиком. Одно дело, если мы с ним 10 лет работаем, и он нас стабильно “кормит”, другое – если это разовый товарищ, который весь проект создает проблемы, и постоянным клиентом точно не станет. Если в компании так принято – дополнительно согласую стратегию дальнейшей работы с этим клиентом со своим руководителем
  4. В итоге – если “подвинуться” я могу – садимся за стол переговоров, ищем компромисс. При этом компромисс может быть самым разным – например, делаем все изменения по требования Заказчика бесплатно, если знаем, что система все равно будет у нас на поддержке и запросами на изменение мы эти деньги все равно отобьем.

А если нет – то и такой вариант никто не отменял.

А вы бы как ответили? Какие вам интересные вопросы на собеседованиях попадались? Расскажите!

 UPD 06.02.2020: Читайте комменты, они полезнее и подробнее, чем пост.

Рекомендую посмотреть:

Обучение
18 февраля 2020
Курс по аналитике данных от SkillFactory – обзор от upravlenie-proektami.ru
Юлия Бажанова
Редактор проекта, РМР, РМЕ, PRIME

комментарии

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

Такой e-mail уже зарегистрирован. Воспользуйтесь формой входа или введите другой.

Вы ввели некорректные логин или пароль

Sorry that something went wrong, repeat again!

10комментариев

сначала новые
по рейтингу сначала новые по хронологии
1

Получив ответ по пункту 1 я бы засомневался в искренности говорящего 🙂

Действительно есть куча факторов, которая определяет ответ.
Кратко опишу наш недавний опыт:

Работаем с крупным госзаказчиком. Он много лет наш монозаказчик (уже печаль). Подрядчик выбирается по результатам конкурса, повлиять на конкурсную документацию мы не можем. То есть на момент когда производится оценка затрат на потенциальный проект можно опираться только на документы, которые есть в конкурсе – единственный вариант это задать уточняющие вопросы. С учетом сроков конкурса (обычно есть 2-4 недели) и обтекаемых ответов ситуация проясняется лишь частично.
И вот обсудив очень расплывчатое задание на разработку и заложив риски, мы подали оценку на разработку суперхранилища и выиграли. Но не учли того, что главным контрагентом со стороны ИТ-заказчика является новый для нас человек. Далее начинается история боли..
В первом этапе при написании Техзадания заказчик занимает активную позицию в вопросе разработки и вникает во все технические моменты, начинает навязывать свои техрешения, не имея внятного опыта, меняет знакомый нам продукт на совсем незнакомый. Спустя несколько месяцев после старта работ в нас выдаются внутрение стандарты заказчика и требование им соответствовать, иначе работы не примут. В итоге переделываются все структуры БД и весь код, завязанный на это. Возникает куча “хотелок”, не оговоренных в конкурсной документации, часть из которых приходится реализовывать. Когда обьем данных возрастает становится понятным что незнакомый до проекта продукт, который был навязан, не вывозит эти объемы, это нужно доказывать, т.к. позиция вендора все хорошо, вы просто криворукие. Было много еще всякого…
В итоге проект сделан в минус с двухкратным превышением сроков. Руководству заказчика представлено так, что срыв сроков это наши косяки.

Автор2
Юлия Бажанова

По п.1 – учту:) а за историю спасибо, вы меня еще раз мотивировали с госами не работать:) технически такое с любым заказчиком при фикс прайсе возможно, конечно, но тут прямо в гротескной форме

3

А, ну и правильный ответ с точки зрения PMI:
1) Выяснить какой конкретно скоуп заказчик имеет ввиду
2) Открыть заранее написанный Change Management Plan и сделать как там написано)

Автор4
Юлия Бажанова

Красиво и маловероятно=)) как и весь идеальный проджект-менеджмент по PMBOK=))

5

Специально не читал ответов, пока сам не написал) Приятно видеть, что мысли сходятся (что, в общем, не удивительно)

Чтобы я ответил:
Ну, для начала неплохо бы прояснить в какой вселенной это происходит.
Потому что
– если у нас T&M контракт,
– мы работаем по скраму и
– мы “на стадии тестирования разработки” в рамках очередного спринта
то мы радуемся, рукоплещем и договариваемся о том, когда клиенту удобно назначить встречу с бизнес-аналитиком.

В грустном варианте – когда
– это фикс прайс,
– “стадия тестирования разработки” – это UAT на стороне клиента перед big bang внедрением по waterfall

1) Погладить заказчика по голове, подтвердить, что мы работаем строго по контракту, и, конечно, если что-то вдруг забыто – все невиновные будут наказаны. Намекнуть, что если по результатам оценки будет ясно, что это новые требования – то нам крайне хочется все сделать забесплатно, но придется все-таки сформировать CR.
2) Cпросить какие именно требования не учтены. Если сразу непонятно – назначить встречу аналитиков с заказчиком или представителями для прояснения.
3) Если, действительно, в серой зоне и в контракте не сказано что в этом случае делать – сесть и глубоко задуматься, правильную ли профессию вы выбрали. Потому что ПМ на проекте в том числе, чтобы таких вопросов не возникало.
4) Получить оценку объема печали, скорее всего умножить на 3.14, оценить влияние на внедрение (сроки, качество, и т.д.), прикинуть свою зопу (Zone Of Possible Agreement – разброс вариантов на которые можем согласиться)
5) Дальше варианты решения:
5.1) стоять насмерть, упираться рогом и слать клиента в Change Management вплоть до через суд.
5.2) согласиться все сделать за свой счет
5.3) агрессивные переговоры (клиент берет на себя определенный процент расходов от завышенной оценки и с большой вероятностью получает говнокачество) либо попытка найти winwin (“мы вам забесплатно это, а вы нам допничек на то подпишете”)

решение функция многих переменных, а именно:
– отношения с заказчиком, последствия семейной ссоры
– объем требуемых изменений
– возможность отбить эти деньги позже или параллельно (вы сейчас с тем же человеком заключаете контракт на миллион а изменение стоит 10 рублей, може)

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

Автор6
Юлия Бажанова

OMG=)) I miss you, really=))
А вообще это так прекрасно, что даже сейчас апдейт к посту сделаю

7

Работа на стороне подрядчика привнесла в мою жизнь много незабываемых моментов;)

Автор8
Юлия Бажанова

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

9

Вопрос с большой неопределенностью внешних условий, поэтому очевидно, что правильного ответа нет)
Между тем ситуация жизненная, встречается регулярно, видимо поэтому и попадает в топ на собеседованиях

Согласен с шагами Юлии 2-4, не согласен с первым
Даже при детальной постановке после реализации может быть понятно, что нужно что-то еще
Я на первом шаге обычно оцениваю, нужны ли новые требования для целей проекта. Критерий: без этих требований заказчик решит те проблемы, для которых стартовал проект? Если да, то это уже повод не идти дальше, а “вспомнить зачем мы все тут собрались”

Если фича не ключевая, но нужная, то как описала Юлия – оценка и договориться как сделаем
Единственное я бы дополнил, что обычно все такие доработки лучше ставить куда-то ближе к концу. Сначала исполняем обязательную программу, потом хотелки. Отчасти потому что вероятно это не последняя хотелка, будут еще и а) лучше их делать скопом б) не впадать в ситуацию когда всовывают по одной хотелке и мы уже так увязли в этом, что еще одна новая уже не сильно настораживает ни нас ни заказчика

Автор10
Юлия Бажанова

Понятно, что даже при супердетальных требованиях такое возможно, но как же себя не похвалить-то лишний раз на собеседовании=))

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: