По мотивам недавней переписки с одним из читателей.
Читатель:
Полгода назад я искал работу, и часто на собеседовании мне описывали одну и туже ситуацию и предлагали найти решение. Я всегда высказывал свою точку зрения, но, поскольку, эту ситуацию мне предлагали разрешить в нескольких компаниях, то у меня появилось подозрение, что здесь требуется некий стандартный ответ. Может его знаете?
Ниже ситуация и вопрос:
Вы руководитель некоего проекта. Проект на стадии тестирования разработки, и вдруг Заказчик утверждает, что вы учли не все его требования, хотя они и не были отмечены в Функциональных требованиях. Например, требования были макроуровня и поэтому допускают вольное толкование. Или просто Заказчик такой самодур. Ваши действия как руководителя проекта?
Как вам? Мне прямо понравился вопрос. Лично мне такой задачки на собеседованиях не попадалось, “правильного” ответа не знаю, однако как человек, который сам регулярно нанимает РМов – я уверена, что его и нет, и работодателю интересно посмотреть, как человек будет размышлять.
Я бы отвечала примерно так:
- Ну вообще я пишу четкие документы, критерии приемки, делаю промежуточные демо, поэтому вероятность такой ситуации не очень велика, я веду работу с рисками.
- Но если это случилось – предполагаю, что как профессиональный РМ – я знаю, насколько я могу “подвинуться”, есть ли у меня часы, бюджет и прочие возможности, чтобы эти хотелки закрыть.
- Оцениваю важность хороших отношений с Заказчиком. Одно дело, если мы с ним 10 лет работаем, и он нас стабильно “кормит”, другое – если это разовый товарищ, который весь проект создает проблемы, и постоянным клиентом точно не станет. Если в компании так принято – дополнительно согласую стратегию дальнейшей работы с этим клиентом со своим руководителем
- В итоге – если “подвинуться” я могу – садимся за стол переговоров, ищем компромисс. При этом компромисс может быть самым разным – например, делаем все изменения по требования Заказчика бесплатно, если знаем, что система все равно будет у нас на поддержке и запросами на изменение мы эти деньги все равно отобьем.
А если нет – то и такой вариант никто не отменял.
А вы бы как ответили? Какие вам интересные вопросы на собеседованиях попадались? Расскажите!
Получив ответ по пункту 1 я бы засомневался в искренности говорящего 🙂
Действительно есть куча факторов, которая определяет ответ.
Кратко опишу наш недавний опыт:
Работаем с крупным госзаказчиком. Он много лет наш монозаказчик (уже печаль). Подрядчик выбирается по результатам конкурса, повлиять на конкурсную документацию мы не можем. То есть на момент когда производится оценка затрат на потенциальный проект можно опираться только на документы, которые есть в конкурсе – единственный вариант это задать уточняющие вопросы. С учетом сроков конкурса (обычно есть 2-4 недели) и обтекаемых ответов ситуация проясняется лишь частично.
И вот обсудив очень расплывчатое задание на разработку и заложив риски, мы подали оценку на разработку суперхранилища и выиграли. Но не учли того, что главным контрагентом со стороны ИТ-заказчика является новый для нас человек. Далее начинается история боли..
В первом этапе при написании Техзадания заказчик занимает активную позицию в вопросе разработки и вникает во все технические моменты, начинает навязывать свои техрешения, не имея внятного опыта, меняет знакомый нам продукт на совсем незнакомый. Спустя несколько месяцев после старта работ в нас выдаются внутрение стандарты заказчика и требование им соответствовать, иначе работы не примут. В итоге переделываются все структуры БД и весь код, завязанный на это. Возникает куча “хотелок”, не оговоренных в конкурсной документации, часть из которых приходится реализовывать. Когда обьем данных возрастает становится понятным что незнакомый до проекта продукт, который был навязан, не вывозит эти объемы, это нужно доказывать, т.к. позиция вендора все хорошо, вы просто криворукие. Было много еще всякого…
В итоге проект сделан в минус с двухкратным превышением сроков. Руководству заказчика представлено так, что срыв сроков это наши косяки.
По п.1 – учту:) а за историю спасибо, вы меня еще раз мотивировали с госами не работать:) технически такое с любым заказчиком при фикс прайсе возможно, конечно, но тут прямо в гротескной форме
А, ну и правильный ответ с точки зрения PMI:
1) Выяснить какой конкретно скоуп заказчик имеет ввиду
2) Открыть заранее написанный Change Management Plan и сделать как там написано)
Красиво и маловероятно=)) как и весь идеальный проджект-менеджмент по PMBOK=))
Специально не читал ответов, пока сам не написал) Приятно видеть, что мысли сходятся (что, в общем, не удивительно)
Чтобы я ответил:
Ну, для начала неплохо бы прояснить в какой вселенной это происходит.
Потому что
– если у нас 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 рублей, може)
ну и, самое главное, делаем работу над ошибками. пересматриваем контрак, скоуп, проясняем с клиентом, где надо – переподписываем и т.д.
чтобы больше такого быть не могло.
Как представитель “того самого Заказчика”, скажу что агрессивная теория решения кейса со стороны Исполнителя, предложенная автором комментария, еще более более вредна для бизнеса разработчика и репутации PMа, чем голый PMBoK. И вот почему. Обычно и ТЗ и контракт на конкурс, особенно на большие деньги – у Заказчика делают профессионалы, не один десяток лет работавшие на стороне Исполнителя в ИТ, и прекрасно понимающие ситуацию, как внутри своей корпорации, так и со стороны производства исполнителя. И это всегда будет fixprice. Поэтому все эти волшебные рецепты “как побороть” и “как сделать так чтобы больше такого не было” – всегда лежат за рамками и кругозора и возможностей РМа. Ни о чем он не сможет договориться. Не его уровень. Все что может извлечь РМ из этого кейса – видеть такой проект на входе и заранее договориться со своим работодателем “на берегу” о схеме премирования себя и команды в таком высокорисковом проекте.
Я сейчас тоже на стороне Заказчика работаю и, к сожалению, то, что “ТЗ и контракт на конкурс, особенно на большие деньги – у Заказчика делают профессионалы” – это реальность прям в небольшом счастливом проценте случаев=))
OMG=)) I miss you, really=))
А вообще это так прекрасно, что даже сейчас апдейт к посту сделаю
Работа на стороне подрядчика привнесла в мою жизнь много незабываемых моментов;)
Напомню, что на сайте есть гостевые публикации=)) если вдруг захочется поделиться чем-нибудь ну совсем уж незабываемым=))
Вопрос с большой неопределенностью внешних условий, поэтому очевидно, что правильного ответа нет)
Между тем ситуация жизненная, встречается регулярно, видимо поэтому и попадает в топ на собеседованиях
Согласен с шагами Юлии 2-4, не согласен с первым
Даже при детальной постановке после реализации может быть понятно, что нужно что-то еще
Я на первом шаге обычно оцениваю, нужны ли новые требования для целей проекта. Критерий: без этих требований заказчик решит те проблемы, для которых стартовал проект? Если да, то это уже повод не идти дальше, а “вспомнить зачем мы все тут собрались”
Если фича не ключевая, но нужная, то как описала Юлия – оценка и договориться как сделаем
Единственное я бы дополнил, что обычно все такие доработки лучше ставить куда-то ближе к концу. Сначала исполняем обязательную программу, потом хотелки. Отчасти потому что вероятно это не последняя хотелка, будут еще и а) лучше их делать скопом б) не впадать в ситуацию когда всовывают по одной хотелке и мы уже так увязли в этом, что еще одна новая уже не сильно настораживает ни нас ни заказчика
Понятно, что даже при супердетальных требованиях такое возможно, но как же себя не похвалить-то лишний раз на собеседовании=))