Scrum и Fixed Price в аутсорсинге: совместить нельзя разделить

    Мало кто находит выход, некоторые не видят его, даже если найдут, а многие даже не ищут.
    Из “Алиса в стране чудес”

    В статье поднимаются следующие вопросы.

    1. О противоречивости компонентов аутсорсинговой формулы ‘Scrum + Fixed Price’.
    2. Об одной, из возможных, ошибке (корневой причине), предшествующей неверному выбору инструмента Scrum.
    3. Об одной ситуации, когда действительно стоит вопрос о совмещении Scrum и Fixed Price, требующей глубокого анализа и поиска компромиссов для ее разрешения.

    В статье затронут весьма спорный момент, не имеющий однозначной точки зрения и являющийся предметом нескончаемых дискуссий. Поэтому читая, имейте, пожалуйста, ввиду, что ваше мнение может не совпадать с представленным, но это совершенно не значит, что кто-то из нас абсолютно прав в равной степени, как и то, что кто-то – абсолютно неправ.

    Как говорилось в статье “С чего начинается псевдо-Scrum в аутсорсинге”, в большом количестве аутсорсинговых проектов, команды которых совмещают (или, не исключено, выдают желаемое за действительное) Scrum и Fixed Price, не верно идентифицирован жизненный цикл (ЖЦ) проекта. Т.е. совершена ошибка в выборе между итеративным инкрементным или гибким ЖЦ. И, как результат, не верно выбран управленческий инструмент – фреймворк Scrum. И уже следствием этого выбора является возникновение ряда проблем, неверных выводов об Agile, Scrum и попыток (от слова «пытка»?) совместить эти два взаимоисключающих понятия.

    Взаимоисключающих?!

    Сейчас аргументирую.

    Предполагается, что читающий далее ознакомился с материалами вышеназванной статьи.

    Scrum + Fixed Price – это то же самое, что идти одновременно вперед и назад?


    Как она ни пыталась, она не могла найти тут ни тени смысла, хотя все слова были ей совершенно понятны.
    Из “Алиса в стране чудес”
    При заключении контракта на оказание аутсорсинговых услуг клиент практически всегда настаивает на Fixed Price (схема “под ключ”). Его пожелание – зафиксировать Product Scope (или объем работ), увидеть бюджет, сроки. Он хочет видеть, что «покупает». На Time & Material клиенты соглашаются редко.

    Таким образом, ключевой момент: потребность клиента – зафиксировать в контракте, а провайдера услуг – выполнить обязательства по контракту и гарантировать, что параметры будут неизменными с прогнозируемой погрешностью (в силу некоторой степени неопределенности и рисков на этапах продаж и заключения контракта) после начала разработки. Вопрос понижения степени неопределённости и рисков – это вопросы возможности проведения и качества фазы Discovery (Pre-sale, диагностики) в отношении Product Scope.

    Совершенно очевидно, что, если мы что-то фиксируем (гарантируем клиенту по контракту), то мы обязаны спланировать и управлять этим таким образом, чтобы обеспечить выполнение своих обязательств. Т.е. управлять планом (или фиксированными характеристиками проектного треугольника).

    Fixed Price просто обязывает нас поставить в приоритет управление планом. Иначе, зачем нам что-то фиксировать, заведомо зная, что оно изменится, и мы на самом деле не планируем этим управлять? Чтобы просто заключить контракт? Критическая ошибка устоявшихся процессов продаж: фиксируем, заведомо зная, что будем менять, лишь для того, чтобы подписать контракт!

    Почему “будем менять”? Потому что Scrum – это ведь всегда про неопределённость и ее результат — изменения. Это про приоритет управления изменениями. И ведь не исключено, что они могут появиться уже после первого спринта. Почему?

    Отступление о возможных причинах изменений

    В чем может быть причина изменений? Она, например, может быть в некачественно проведенной фазе Discovery (Pre-sale, диагностики) в ситуации, когда Product Scope может быть определен в той или ной мере (для примера см. п. 3 из Case Study в статье), но по каким-то причинам этого не сделано. В таком случае, это проблема фазы и внутренних процессов, а не причина выбора Scrum для контракта с Fixed Price, гибкого ЖЦ вместо итеративного с целью компенсации допущенной ошибки.

    Хотя, справедливости ради, отмечу, что в продажах (Pre-sale-активностях бизнес-аналитиков) в аутсорсинге (одна из самых проблемных фаз с точки зрения Product Scope!) не все так просто как в магазине, когда покупается готовый товар с конкретными свойствами (функциональностью). А фаза Discovery – сложно продаваемая активность бизнес-аналитиков и команды. Но минимизация в той или иной степени неопределенности и оценка рисков – одна из главных задач грамотно выстроенного процесса продаж. Как и формирование понимания у клиента о необходимости и важности этих активностей (бывает очень сложно!). Но для этого существует достаточное количество техник и инструментов. И это сводится к вопросу качества оказываемых услуг, а не продажи “кота в мешке”.

    Другая причина может быть в невозможности определить Product Scope & Vision на текущий момент (для примера см. п. 2 из Case Study в статье). И это действительно очень непростая и невыгодная для обеих сторон ситуация, когда возникает серьезное противоречие и поднимается вопрос о совмещении Scrum и Fixed Price при оказании аутсорсинговых услуг. Она требует тщательного анализа, дополнительных действий по формированию всестороннего понимания клиента (зачастую технически и идеологически далекого от реалий процессов разработки) о возможных сложностях и рисках и поиску компромиссных решений.

    Итак, почему же выбирается Scrum при Fixed Price? Чтобы управлять изменениями, которые, например, возникают в результате неверно проведенной фазы Discovery (Pre-sale, диагностики) либо когда Product Scope не может быть определен на данной фазе? В первом случае, на мой взгляд, это ошибочно. Во втором – сложно реализуемо при Fixed Price.

    Третий возможный вариант выбора Scrum как инструмента Agile, гибкого ЖЦ вместо итеративного инкрементного в ситуации, когда Product Scope проработан и зафиксирован на фазе Discovery (Pre-sale, диагностики), а в контракте – Fixed Price, тоже на мой взгляд не рационален: зачем выбирать инструмент для управления изменениями (уводить из фокуса явно более приоритетную вещь – план), когда их вероятность минимизирована?

    Возращение к главной мысли статьи.

    Но, допустим, Scrum выбран. Повторюсь, Scrum – инструмент управления изменениями, когда степень неопределённости может быть понижена только в процессе и только при использовании соответствующих подходов. И это понижение является результатом этого процесса.

    Но контракт с Fixed Price задает приоритет в управлении планом!

    Таким образом «формула» ‘Scrum + Fixed Price’ трансформируется в ‘управление изменениями + управление планом одновременно’. Задача менеджера – управлять в разных степенях и планом, и изменениями, но в приоритете может быть только что-то одно: либо план, либо изменения.

    Либо управление планом, либо управление изменениями – это, своего рода, аксиома, заложенная в основы менеджмента и бизнес-анализа. Она отражена в базовых (и не только) руководствах для менеджеров (PMBOK) и бизнес-аналитиков (BABOK). А классификация ЖЦ (и их идентификация в отношении конкретных проектов) опирается на нее: есть ЖЦ, предназначенные для управления планом (например, Waterfall, итеративные инкрементные (IID)) и гибкие, Agile для управления изменениями. Выбор ЖЦ (а в последствии и инструментов) строится из того, чему в управлении отдается приоритет.

    Гибкий ЖЦ – это разновидность итеративного инкрементного ЖЦ для проектов с определенными доминирующими признаками/особенностями (список контрольных вопросов приведен в вышеназванной статье), позволяющими идентифицировать его как отдельный ЖЦ и «направить все силы» на управление изменениями. К этим признакам могут быть отнесены: невозможность “здесь и сейчас” достичь некоторой степени определенности Product Scope (самое важное!), поиск бизнес-решения (или его быстрая поставка бизнесу для формирования обратной связи), которое “выстрелит”, формирование списка ключевых функций продукта (Key Features), короткие итерации, изменчивость, эксперимент, постепенное наращивание функционала, ретроспективы, совершенствование не только продукта, но и процессов с целью получить лучший вариант продукта. Возможно ли в таких условиях получить адекватные оценки бюджета и сроков?

    Дьявол всего в одной детали или … все дело в Product Scope


    Во всем есть своя мораль, нужно только уметь ее найти!
    Из “Алиса в стране чудес”

    Что вы можете сказать об определенности (возможности ее установить) в отношении Product Scope & Vision на этапе продаж, фазы Discovery (диагностики) на старте проекта в аутсорсинге?

    Если Product Scope не может быть определен, оценен, зафиксирован по причинам уникальности продукта, идеи старт-апа, неизвестности в отношении эффективности принимаемых бизнес-решений (необходимости их поиска) и сложности определения ключевых функций продукта, наличия гипотез, требующих проверки и т.д. (см. еще раз п. 2 из Case Study тут), то, конечно же, фреймворк Scrum – наиболее подходящий инструмент. Его выбор возможен и в том случае, когда Product Scope может быть определен (бизнес-идея не уникальна), но пожелание клиента (инвестора) начать разработку как можно скорее (без диагностики и, соответственно, фиксаций) по схеме Time&Material, например.

    Однако, для аутсорсинга ситуация с уникальной бизнес-идеей значительно осложняется пожеланием клиента использовать схему Fixed Price при заключении контракта и предстает в невыгодном свете для обеих сторон. В какой-то мере с некоторыми допущениями можно достичь компромисса при заключении контракта и при управлении таким проектом. Важно сформировать правильное понимание и верные ожидания клиента (инвестора), оценить риски, рассмотреть по возможности иные схемы финансового взаимодействия, а в процессе реализации проекта постоянно работать с лояльностью клиента и т.д. Углубляться в вопрос не буду, так как он выходит за рамки статьи.

    В аутсорсинге чаще всего вопрос в первую очередь заключается в грамотном проведении фазы Discovery (Pre-sale, диагностики) в отношении Product Scope и выборе верного ЖЦ. И если выбирается гибкий ЖЦ и Scrum как инструмент (вместо итеративного инкрементного ЖЦ и его инструментов для управления планом и изменениями) в ситуации, когда Product Scope зафиксировать можно (и тем более, когда этого не было сделано по каким-то причинам вовремя, с ожиданием/предположением его проработки в будущем), и при этом в контракте – Fixed Price, на мой взгляд, совершается ошибка, которая ставит под сомнение положительный исход проекта.

    Спасибо за внимание!

    Комментарии 11

      0
      Способ повествования очень сложный. В итоге ничего не понял. По ссылке ниже кажется об этом же
      Ссылка
        0
        По ссылке — как совместить. В статье — о том, что невозможно совместить то, что по сути не совместимо и не должно совмещаться (в комментариях к статье по ссылке также много об этом) и как понять (на что обратить внимание), когда не стоит и пытаться.
        P.S. да, способ повествования сложный. как ни старалась проще написать о такой сложной теме — не вышло. спасибо, попробую со временем сделать материал более легко воспринимаемым.
        +1
        А я подумала, что Вы нашли способ совместить гибкую разработку и фикс прайс. Эх…
          0
          Способов совместить нет (и делать Scrum со всей его эмпирикой, и вложиться в планы), мое мнение. Но способы как управлять таким проектом и компромиссы есть. В статье по ссылке в первом комментарии, например. Может быть об этом и я напишу, пользуюсь несколько иными подходами. Но это как ложкой копать карьер — можно же, но все время надо придумывать, как сделать это эффективнее и не довести до абсурда, лучше заранее оценить ситуацию и пригнать технику. Но все же мое мнение, разумнее не допускать такой ситуации в принципе и закрыть вопрос на этапе продаж. Но мы в реальном мире, и если уж случилось иначе, то надо что-то с этим делать…
          0

          Как-то странно, что скрам противопоставляется итеративной поставке инкрементов, когда это его суть — каждую итерацию (спринт) генерировать готовый к поставке инкремент ценности. И Fixed price скрам не противоречит, по-моему. Ему противоречит Fixed scope.

            0
            Как-то странно, что скрам противопоставляется итеративной поставке инкрементов...

            Не скрам (это инструмент майндсета Agile для реализации гибкого ЖЦ для работы с неопределенностью и изменениями), а гибкий ЖЦ итеративному инкрементому. Это разные ЖЦ по классификации PMBOK (см. 5 версию, там более подробное описание) и по ситуациям реализации проектов.
            Если у вас со Scope полная определенность (каков смысл эмпирики Scrum?), кейсы я приводила для пассажироперевозок в статье по ссылке, вы просто режете его на куски и итеративно поставляете. Если определенности нет (фактор неизвестности), то вы ее достигаете короткими итерациями (выбирая Scrum, так как этот инструмент работает именно в этом направлении — управлении изменениями в результате изначальной неопределенности) и ценными поставками, по которым формируется обратная связь и дальнейшие пути разработки.
            И Fixed price скрам не противоречит, по-моему. Ему противоречит Fixed scope.

            Это Fixed Budget (как «более мягкая» разновидность FP) допускает фиксацию только бюджета. Да и то, там Scope полностью «не отпускается», заказчик расставляет приоритеты и т.д. FP — это схема «под ключ», фиксирует все параметры проектного треугольника (бюджет, сроки, содержание).

            Но дело даже не в этом. Любая фиксация противоречит неопределенности и эмпирике. Как можно дать адекватную оценку времени, сроков, бюджета экспериментов? Допустим вы зафиксировали бюджет, а scope отпущен. Вы остановите разработки на пол пути, когда закончатся деньги?
            Или тот же кейс с пассажироперевозками, что я приводила: лет 5 после выхода на рынок приложения (опущу название, но не сложно догадаться) менялись алгоритмы построения маршрутов, ценообразования, расчет коэффициентов в час пик, потом был какой-то алгоритм динамического ценообразования. Разве можно что-то зафиксировать при такой переменчивости и обратной связи от рынка?
              0
              Вы остановите разработки на пол пути, когда закончатся деньги?

              Заказчик решит, что делать дальше. Варианты навскидку:


              • в целом результатом доволен, но это ещё не MVP даже — ещё транш, а может уже конкретный скоуп доработок
              • результатом не доволён — закрываем
              • релизимся и переходим на T&M
                0
                Варианты жизнеспособные в том случае, если заказчик был подготовлен к ним на этапе продаж или в процессе (такова стратегия изначально была оговорена).
                А вот T&M действительно подходящая схема для Scrum. И только при ней начинается настоящий Scrum, мое мнение.
                  0

                  Естественно, что должен быть подготовлен, а не "ваши деньги мы потратили, но пока и половины того, что вы в целом хотели, не сделали, если хотите доделывать — давайте ещё деньги, но не факт, что всё успеем"


                  Да, чаще всего "само так получается" когда заказчик внутренний, выбивает бюджет на "отчётный период", а не на проекты с конкретными целями-результатами.


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


                  Но в целом, да, T&M самая подходящая для Scrum и идеологически, и практически :)

            0

            Спасибо, хорошая статья.

              0
              Спасибо!

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое