Небольшой пример из ненастоящей жизни:

Я тороплюсь в Домодедово. Звоню в такси, заказываю машину. Мне говорят, что в Домодедово будет стоить 1000 рублей, довезут за 40 минут, приедут через 10. Ок.

А теперь два сценария происходящего. Давайте договоримся так:

• Я буду заказчиком (ну по сути я и так заказываю услугу)
• Таксист будет подрядчиком — исполнителем, который работает по Скраму.

Сценарий 1: «Классический SCRUM»

Такси приезжает не через 10 минут, как мне сказали в службе заказа, а через 15. Ок, сажусь, едем. Тут таксист обнаруживает, что в городе пробки. И за 40 минут мы вряд ли доберемся — потому что придется ехать в объезд. За дополнительный километраж нужно будет доплачивать, в службе меня сразу предупредили. Ок, что делать, едем дальше. Но тут (внезапно!) у таксиста заканчивается бензин. Он смотрит на меня честными глазами и предлагает прогуляться до ближайшей заправки с канистрой. Нет, он ничего оплачивать не будет. Я сами должен его заправить.

Дальше — плевок в пол, метро, Павелецкий, Аэроэкспресс. По расписанию, за 320р. «Все web-разработчики таксисты — п%$^сы».

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

С удивлением обнаружил, что многие западные разработчики пытаются работать по этому сценарию. Аргументируя тем, что невозможно все предугадать и изменения всё равно будут — по инициативе заказчика или ввиду «объективных» факторов. Когда-то я тоже так думал. Но — фигня всё это.

Несмотря на то, что гибкость — хорошая штука, в большинстве случаев заказчик хочет слышать фиксированную сумму. А в скраме бюджет — тоже гибкий (может менять как в меньшую, так и в большую сторону).

Итак, как поступаем мы с этой самой «гибкостью бюджета» в Скраме. А очень просто — мы делаем бюджет и время на каждый этап строго фиксированными.

Главная задача руководителя проектов — в условиях недостатка информации сделать наилучшее предположение о том, как пойдет проект, и приложить все силы для того, чтобы это предположение сбылось.

Следовательно, на каждый этап гибкой разработки у нас есть вполне жесткая оценка по координатам «деньги/сроки/объем работы». Если мы не укладываемся в бюджет — это наша проблема, оплачиваем ее тоже мы.

А теперь ко второму сценарию, там всё закончится хорошо :)

Сценарий 2: «Правильный SCRUM»

Я еду в Домодедово, но внезапно мне звонит оператор авиакомпании и говорит, что рейс перенесен в Шереметьево. Я сообщаю об этом таксисту. Естественно, я жду от него, что:

• Он не будет пилить до Домодедово, а потом разворачиваться.
• Он свернет на ближайшем перекрестке и выберет самый короткий маршрут.
• Мы договоримся с ним о новой цене поездки.

Он оказывается адекватным и с хорошей реакцией. Всё проходит гладко, я оставляю таксисту на чай и успеваю на самолет.

Здесь происходит следующее: у заказчика (то есть у меня) возникают новые требования. Я озвучиваю их. Исполнитель использует гибкость методологии SCRUM для того, чтобы внедрить их максимально быстро и дешево для меня.

И это отлично: с одной стороны у меня фиксированный бюджет, больше которого я не заплачу, даже если на офис разработчиков упадет метеорит. С другой стороны — Scrum сохранил свою гибкость там, где надо, и я могу быстро и дешево внедрять изменения в проект.

Не можете спланировать весь путь? Верю. Планируйте этапами. На то он и SCRUM. Но на каждом из них — цена и сроки должны быть озвучены заранее и должны оставаться фиксированными. Если этого хочет клиент. А по умолчанию — он хочет.