Во время реализации 9-месячного проекта ключевой пользователь просит сделать доработку, которая сэкономит ему 4 часа работы каждую неделю. Пользователь говорит вам, что это главная причина, по которой он хочет изменить свое программное обеспечение. К сожалению, эта функция не является стандартной и, по оценкам, потребует 2 недели дополнительной разработки.

Что вы будете делать?

1. Если заказчик готов платить, то вы возьметесь за доработку.

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

3. Добавите эту функцию в бэклог разработки, которую нужно выполнить после запуска Go-Live.

Ответ: 3. Поскольку пользователь не использует такую функцию в своем текущем программном обеспечении, он может прожить без нее несколько дополнительных месяцев. Избегайте дополнительной задержки проекта: лишние 2 недели не кажутся чем-то большим, но вы никогда не знаете, сколько решений, подобных этому, вам придется принимать в ходе проекта.

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

Что вы будете делать?

1. Добавите новые шаги проверки, чтобы они соответствовали требованиям заказчика.

2. Добавите новые правила для сотрудников (спрашивать руководителя и финансового директора о расходах 500 евро) и попросите сотрудников оповестить обе стороны.

3. Откажитесь рассматривать это как необходимость.

Ответ 2: Небольшие компании часто меняют методы работы. Поэтому обычно лучше определить политику, а не разрабатывать пользовательскую функцию. Все, что вам нужно сделать, – это разослать новую процедуру согласования по электронной почте сотрудникам: оповестите менеджера и финансового директора, отправив им письма. В отличие от жесткой разработки, политику можно легко скорректировать, при этом здравый смысл все равно будет преобладать (например, если ваш менеджер в отпуске, достаточно будет подтверждения только у финансового директора).

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

Как вы выйдете из этой ситуации?

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

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

3. Вы извиняетесь, соглашаетесь с CFO и обещаете исправить ситуацию.

4. Вы напоминаете им о базовых принципах, ссылаясь на анализ ROI.

Ответ 4: Вы напоминаете об анализе рентабильности инвестиций ROI, делитесь им на экране. Вы подчеркиваете, что успех проекта определяется ответственным ключевым пользователем для этой области, как это было четко согласовано со всеми заинтересованными сторонами в начале проекта. Вы готовы вместе с CFO и ключевым пользователем провести отдельную сессию, чтобы устранить его опасения, отметив, что если будет действительно необходимо, запрос на разработку будет помещен в «бэклог», и реализован в будущем после запуска проекта.

На совещание по планированию проекта заказчик пригласил заинтересованных лиц из каждого из 7 отделов. На совещании будут присутствовать 10 представителей.

Сколько руководителей со стороны Odoo должны присутствовать на этой встрече?

1. 1 или 2, большее количество будет пустой тратой времени.

2. 4, чтобы чувствовать себя более «серьезным» на фоне 10 представителей заказчика.

3. 7, по одному для каждого отдела.

4. 10, столько же, сколько и у заказчика.

Ответ 1: Мы должны быть максимально эффективными. Если у вас есть опытные менеджеры проектов, достаточно одного человека. Однако неплохо пригласить на встречу новых бизнес-аналитиков, чтобы они могли поучиться. Также, если руководитель проекта не уверен в теме, он может пригласить эксперта.

Представьте себе следующую ситуацию: Перед Go-Live у вас встреча с генеральным директором. У вас возникало много проблем в ходе проекта, они больше не уверены в вашем решении и боятся Go-Live. Генеральный директор подумывает о том, чтобы отложить Go-Live еще на 6 месяцев. Он встречается с вами и говорит: «Моя компания не может позволить себе больше проблем. Чтобы принять Go-Live, мне нужно, чтобы вы сказали мне, что все пройдет гладко».

Что вы ответите:

1. Перенос сроков - хорошая идея для снижения рисков.

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

3. Ввод в эксплуатацию всегда труден, но мы быстро устраним все проблемы.

Ответ 3: Ввод в эксплуатацию всегда труден: всякое может случиться, даже если мы сдвинем сроки на 6 месяцев. Это нормально. И мне нужно, чтобы вы поддерживали проект, когда команда жалуется. С нашей стороны, мы будем устранять проблемы быстро, по мере их возникновения. Перенос сроков на 6 месяцев увеличит стоимость проекта и поставит под угрозу его успех (за 6 месяцев может измениться очень многое). Всегда будьте честными и открыто говорите о предстоящих проблемах. Если генеральный директор увидит, что вы знаете, что делаете, и прозрачны в своем подходе, он будет вам доверять.