SCRUM должен быть по фиксированной цене
Делаем скрам дружелюбнее к заказчикам
Владимир Завертайлов
Небольшой пример из ненастоящей жизни (еще до того, как весь рынок такси заняли агрегаторы):
Я тороплюсь в Домодедово. Звоню в такси, заказываю машину. Мне говорят, что в Домодедово будет стоить 1000 рублей, довезут за 40 минут, приедут через 10. Ок.
А теперь два сценария происходящего. Давайте договоримся:
Я тороплюсь в Домодедово. Звоню в такси, заказываю машину. Мне говорят, что в Домодедово будет стоить 1000 рублей, довезут за 40 минут, приедут через 10. Ок.
А теперь два сценария происходящего. Давайте договоримся:
- Я буду заказчиком (ну по сути я и так заказываю услугу).
- Таксист будет подрядчиком — исполнителем, который работает по Скраму.
Сценарий 1: «Классический SCRUM»
Такси приезжает не через 10 минут, как мне сказали в службе заказа, а через 15. Ок, сажусь, едем. Тут таксист обнаруживает, что в городе пробки. И за 40 минут мы вряд ли доберемся — потому что придется ехать в объезд. За дополнительный километраж нужно будет доплачивать, в службе меня сразу предупредили. Ок, что делать, едем дальше. Но тут (внезапно!) у таксиста заканчивается бензин. Он смотрит на меня честными глазами и предлагает прогуляться до ближайшей заправки с канистрой. Нет, он ничего оплачивать не будет. Я сам должен его заправить.
Дальше — плевок в пол, метро, Павелецкий, Аэроэкспресс. По расписанию, за 320р. «Всеweb-разработчики таксисты — п%$^сы».
Дальше — плевок в пол, метро, Павелецкий, Аэроэкспресс. По расписанию, за 320р. «Все
Ситуация фантастическая, но в ней есть доля правды. По сути я как заказчик наблюдаю следующую картину: мне сразу выдвинули условие, что за все форс-мажоры и неправильные оценки со стороны службы такси отвечаю я. На что я в спешке согласился. Затем этот самый форс-мажор случился (причем трижды): один раз меня обманули с оценкой времени старта, потом вдруг образовались проблемы (пробки), решение которых оплачивал опять я и, наконец, таксист не рассчитал и заглох на полпути. В итоге — сроки не соблюдены, а бюджет распух, как губка.
С удивлением обнаружил, что многие западные web-разработчики пытаются работать по этому сценарию. Аргументируя тем, что невозможно все предугадать и изменения всё равно будут — по инициативе заказчика или ввиду «объективных» факторов. Когда-то я тоже так думал. Но — фигня всё это.
Несмотря на то, что гибкость — хорошая штука, в большинстве случаев заказчик хочет слышать фиксированную сумму. А в скраме бюджет — всегда гибкий (может меняться как в меньшую, так и в большую сторону).
С удивлением обнаружил, что многие западные web-разработчики пытаются работать по этому сценарию. Аргументируя тем, что невозможно все предугадать и изменения всё равно будут — по инициативе заказчика или ввиду «объективных» факторов. Когда-то я тоже так думал. Но — фигня всё это.
Несмотря на то, что гибкость — хорошая штука, в большинстве случаев заказчик хочет слышать фиксированную сумму. А в скраме бюджет — всегда гибкий (может меняться как в меньшую, так и в большую сторону).
Итак, как поступаем мы с этой самой «гибкостью бюджета» в Скраме. Очень просто — делаем бюджет и время на каждый отдельный этап строго фиксированными.
Главная задача руководителя проектов — в условиях недостатка информации сделать наилучшее предположение о том, как пойдет проект, и приложить все силы для того, чтобы это предположение сбылось.
Следовательно, на на старте каждого этапа гибкой разработки у нас есть вполне жесткая оценка для него по координатам «деньги/сроки/объем работы». Если мы не укладываемся в бюджет — это наша проблема, оплачиваем ее тоже мы.
А теперь ко второму сценарию, там всё закончится хорошо :)
Главная задача руководителя проектов — в условиях недостатка информации сделать наилучшее предположение о том, как пойдет проект, и приложить все силы для того, чтобы это предположение сбылось.
Следовательно, на на старте каждого этапа гибкой разработки у нас есть вполне жесткая оценка для него по координатам «деньги/сроки/объем работы». Если мы не укладываемся в бюджет — это наша проблема, оплачиваем ее тоже мы.
А теперь ко второму сценарию, там всё закончится хорошо :)
Сценарий 2: «Правильный SCRUM»
Я еду в Домодедово, но внезапно мне звонит оператор авиакомпании и говорит, что рейс перенесен в Шереметьево. Я сообщаю об этом таксисту. Естественно, я жду от него, что:
- Он не будет пилить до Домодедово, а потом разворачиваться.
- Он свернет на ближайшем перекрестке и выберет самый короткий маршрут.
- Мы договоримся с ним о новой цене поездки.
Таксист оказывается адекватным и с хорошей реакцией. Всё проходит гладко, я оставляю таксисту на чай и успеваю на самолет.
Здесь происходит следующее: у заказчика (то есть у меня) возникают новые требования. Я озвучиваю их. Исполнитель использует гибкость методологии SCRUM для того, чтобы внедрить их максимально быстро и дешево для меня.
И это отлично: с одной стороны у меня фиксированный бюджет, больше которого я не заплачу, даже если на офис разработчиков упадет метеорит. С другой стороны — Scrum сохранил свою гибкость там, где надо, и я могу быстро и дешево внедрять изменения в проект.
Не можете спланировать весь путь? Верю. Планируйте этапами. На то он и SCRUM. Но на каждом из них — цена и сроки должны быть озвучены заранее и должны оставаться фиксированными. Если этого хочет клиент. А по умолчанию — он хочет.
И это отлично: с одной стороны у меня фиксированный бюджет, больше которого я не заплачу, даже если на офис разработчиков упадет метеорит. С другой стороны — Scrum сохранил свою гибкость там, где надо, и я могу быстро и дешево внедрять изменения в проект.
Не можете спланировать весь путь? Верю. Планируйте этапами. На то он и SCRUM. Но на каждом из них — цена и сроки должны быть озвучены заранее и должны оставаться фиксированными. Если этого хочет клиент. А по умолчанию — он хочет.