Ответ руководителя лиги: «Из сказанного вами я не понял ни слова, кроме того, что подвергнусь публичному унижению. Я уже объявил всем, что сайт будет доступен 30 марта, а вы не только говорите мне, что это не случится к указанной дате, но и не можете сказать точно, когда он будет. Если бы агент Дерека Джитера
[16] попробовал такое, ему пришлось бы иметь дело с моим руководством».
Совет команды 2
Команда 2 предлагает руководителю лиги ни о чем не беспокоиться. Участники команды очень рады, что MLBTix добился такого успеха, и уверены, что рекомендованная Denture технология будет работать прекрасно, иначе компания не стала бы ее рекомендовать.
Ответ руководителя лиги: «Вы хотите меня успокоить, я понял. Но я также заметил, что вы будете готовы покинуть корабль, обвиняя Denture, если технология не сработает. Мне нужен совет, а не обходительная формулировка».
Совет команды 3
Команда 3 предлагает руководителю лиги подход, позволяющий обслужить любое количество посетителей MLBTix. Если на стадионе Yankee не будет достаточного количества открытых касс, образуются длинные очереди болельщиков. Поэтому команда реализует функцию, которая будет выводить посетителям сообщение: «Ввиду повышенного спроса на билеты просим вас подождать». Затем каждые 30 секунд будет выводиться сообщение: «Пожалуйста, оставайтесь в очереди. Ваш запрос важен, и мы хотим вам помочь». Команда считает, что при таком подходе MLBTix может обслуживать любое количество клиентов без каких-либо дополнительных затрат.
Ответ руководителя лиги: «Очень ценю, что вы нашли способ не увеличивать бюджет, но ваша бережливость загнала меня в угол, поскольку я ненавижу такие сообщения. Я ненавижу и очереди, но, находясь в реальной очереди на стадионе Yankee, по крайней мере, вижу, что происходит вокруг. Ваше предложение приемлемо, но я не очень доволен».
Совет команды 4
Команда 4 считает, что успех рекламной кампании повлек дополнительную работу для команды разработки. Выводить сайт в текущем состоянии рискованно – работать он, может, и будет, но первые несколько дней его функционирования будут плачевными. Команда подготовила несколько вариантов. Первый вариант – уже на следующей неделе позволить людям начать использовать сайт MLBTix для регистрации и посмотреть, что будет происходить. До 30 марта клиенты не смогут покупать и продавать билеты, но возможность зарегистрироваться и посетить сайт уже сейчас может снизить нагрузку в день открытия. Конечно, по-прежнему останется риск возникновения проблем, которые невозможно рассчитать количественно. Однако этот вариант не требует никаких дополнительных затрат. Второй вариант – усилить текущие аппаратные мощности системы для команд с самым высоким ожидаемым объемом обращений: Yankees, Red Sox, Mariners, Braves и Giants. Это аналогично открытию дополнительных касс по продаже билетов. Этот вариант обойдется в $3,4 млн и позволит сайту MLBTix выйти по графику с минимальным риском. Третий вариант – отложить релиз MLBTix на месяц, чтобы улучшить систему для обработки большего, чем ожидалось, объема клиентов. Стоимость этого варианта составляет $1,1 млн за дополнительный месяц работы и $425 000 в виде упущенной выгоды лиги MLB от 25 %-ной комиссии.
Ответ руководителя лиги: «Я понимаю. Вы четко изложили альтернативы, и их нетрудно сравнить, потому что вы очень понятно все объяснили. Хм. С одной стороны имеем непредсказуемый риск потерять все, с другой – можем потратить $3,4 млн, чтобы продолжить работать по плану и свести риск к минимуму, а с третьей стороны – заплатить $1,525 млн, испытать смущение и стыд за месячное опоздание, но решить проблему наверняка. Мы не оценили, сколько клиентов мы потеряем, опоздав на месяц, но это не должно стать слишком большой проблемой, поскольку мы – монополисты. Куда еще могут пойти клиенты? Значит, мне следует решить, стоит ли моя гордость около $1,9 млн. Я горд, но не глуп. Действуем по третьему варианту!»
Извлеченные уроки
Командам было очень трудно поговорить с владельцем продукта в лице руководителя лиги MLB на понятном ему языке. Скрам основан на сотрудничестве, которое требует понимания, а оно, в свою очередь, требует хорошей коммуникации. Если владелец продукта говорит только в деловых терминах, а команда – только в технических, то не будет продуктивного общения, а следовательно, и сотрудничества.
Вспомните о проекте приложения для денежных переводов MegaBank. Когда менеджер по разработке заподозрил, что проект займет больше времени, чем он пообещал своему руководству, он поручил команде сделать все необходимое, чтобы успеть к назначенной дате. Будь у него адекватные количественные данные, он мог бы сравнить затраты на повышение качества системы в течение дополнительных двух месяцев с расходами на поддержание некачественно реализованной и запутанной системы в течение ее жизненного цикла. Он решил больше тратить на дальнейшее обслуживание, хотя и не знал, насколько дорогим окажется его выбор. Как сказал мне участник команды: «Несмотря на использование нами скрама, мы работаем так же, как раньше».
Когда консультанты Denture запланировали создание аукциона MLBTix, они предоставили достаточно информации, чтобы обеспечить руководству лиги возможность идти на компромиссы. MLBTix был комплексным проектом и обязательно напоролся бы на рифы. Однако наличие финансовых данных позволило сравнить различные альтернативы и сделать рациональный выбор. Руководитель лиги оценил свою гордость и решил сохранить деньги в кошельке. Планы, содержащие достаточную информацию, облегчают принятие рациональных решений.
Из четырех описанных здесь команд только одна использовала финансовые значения из плана и предложила варианты, понятные руководителю лиги бейсбола. Другие команды либо пытались обсудить проблему на языке, не имеющем для руководителя лиги смысла, либо полностью принимали на себя риски проекта, заявляя, что все в порядке. В большинстве групп проводимых мной тренингов многие команды принимают риск и не предоставляют альтернативы заказчику. К сожалению, это довольно типичная манера поведения в индустрии разработки программного обеспечения: мы до последнего не раскрываем карты, и только в конце проекта наши клиенты узнают, насколько все на самом деле плохо. Не намеренно. Скорее это естественное влияние среды, в которой разработчики понимают состояние проекта не лучше, чем руководство.
Выводы
Скрам предоставляет множество возможностей для инспекции проекта и необходимых адаптаций. Их цель – оптимизация выгоды, которую проект приносит организации. Тем не менее, чтобы принимать наилучшие решения, ответственный за адаптацию должен обладать адекватной информацией. В случае с MegaBank у владельца продукта Джули и менеджера по разработке Эда не хватило информации, чтобы решить, придерживаться созданного всей командой семимесячного графика или более короткого пятимесячного, первоначально обещанного руководству. При отсутствии данных о затратах и выгодах они согласились исполнять взятые на старте обязательства.
