Владимир Завертайлов

SCRUM должен быть по фиксированной цене

спешалли фор CMSmagazine

Помните, мы проводили тот самый опрос и обещали статью на CMSmagazine? Выполняем обещания, вот она.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


 

Что еще почитать по этой теме

Scrumban разрулит: обновление для техподдержки
Сибирикс
26 Мая 2016
Scrumban разрулит: обновление для техподдержки
Если где-то в коммуникациях с клиентами есть слабые места — мы их устраняем. С этой целью появился Helpdesk и новое обновление для Доски задач.
Обновление: Scrumban теперь в 20 быстрее
Сибирикс
20 Апреля 2016
Обновление: Scrumban теперь в 20 быстрее
Хорошая новость для тех, кто любит задачи, да побольше. И желательно чтобы все на одной доске.
Опасности SEO-продвижения: как выйти в топ и не сломать сайт
Сибирикс
13 Апреля 2016
Опасности SEO-продвижения: как выйти в топ и не сломать сайт
Продвижение и оптимизация сайта — не так просто, как могут уверять SEO-компании. Мы решили морально подготовить вас ко всем форс-мажорам

У вас есть проект?

Давайте обсудим его. Продумаем. И сделаем!

Заказать клёвый проект
Заявка отправлена
Спасибо, ваша заявка отправлена. Эксперт студии Сибирикс свяжется с вами в ближайшее время для уточнения подробностей.