[Agile, Управление продуктом, Управление проектами, Управление разработкой] Scrum и Fixed Price в аутсорсинге: совместить нельзя разделить
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Мало кто находит выход, некоторые не видят его, даже если найдут, а многие даже не ищут.
Из “Алиса в стране чудес”
В статье поднимаются следующие вопросы.
- О противоречивости компонентов аутсорсинговой формулы ‘Scrum + Fixed Price’.
- Об одной, из возможных, ошибке (корневой причине), предшествующей неверному выбору инструмента Scrum.
- Об одной ситуации, когда действительно стоит вопрос о совмещении 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? Чтобы управлять изменениями, которые, например, возникают в результате неверно проведенной фазы 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 – наиболее подходящий инструмент.
Однако, для аутсорсинга данная ситуация значительно осложняется пожеланием клиента использовать схему Fixed Price при заключении контракта и предстает в невыгодном свете для обоих сторон. В какой-то мере с некоторыми допущениями можно достичь компромисса при заключении контракта и при управлении таким проектом. Важно сформировать правильное понимание и верные ожидания клиента (инвестора), оценить риски, рассмотреть по возможности иные схемы финансового взаимодействия, а в процессе реализации проекта постоянно работать с лояльностью клиента и т.д. Углубляться в вопрос не буду, так как он выходит за рамки статьи.
В аутсорсинге чаще всего вопрос в первую очередь заключается в грамотном проведении фазы Discovery (Pre-sale, диагностики) в отношении Product Scope и выборе верного ЖЦ. И если выбирается Agile и Scrum в ситуации, когда Product Scope зафиксировать можно (и тем более, когда этого не было сделано по каким-то причинам вовремя, с ожиданием/предположением его проработки в будущем), и при этом в контракте – Fixed Price, на мой взгляд, совершается ошибка, которая ставит под сомнение положительный исход проекта.
Спасибо за внимание!
===========
Источник:
habr.com
===========
Похожие новости:
- [IT-компании, Карьера в IT-индустрии, Управление продуктом, Управление проектами, Учебный процесс в IT] Эх, айти, куда ж ты котишься?
- [Веб-дизайн, Развитие стартапа, Разработка веб-сайтов, Управление продуктом] Как определить функционал MVP и влюбить клиента в пилотную версию продукта
- [Agile, Управление проектами, Управление разработкой] Игровая механика для скрам-команды, которая любит настолки
- [Управление продуктом] Метод Jobs To Be Done — как решать задачи пользователей с помощью продуктов?
- [Управление продуктом] Что такое Lean Canvas?
- [Agile] От «станков» к «растениям» или мой опыт перехода на agile
- [DevOps, Python, Машинное обучение, Управление разработкой] MLOps — Cook book, chapter 1
- [Развитие стартапа, Управление продуктом] Уроки от начинающего основателя и генерального директора GawkBox (перевод)
- [DevOps, Управление проектами] От Junior до Team Lead за 3 года
- [Управление продуктом, Управление проектами, Управление разработкой] Что делать, если в вашей команде появился «эффективный» менеджер?
Теги для поиска: #_agile, #_upravlenie_produktom (Управление продуктом), #_upravlenie_proektami (Управление проектами), #_upravlenie_razrabotkoj (Управление разработкой), #_agile, #_scrum, #_waterfall, #_upravlenie_razrabotkoj (управление разработкой), #_upravlenie_proektami (управление проектами), #_upravlenie_produktom (управление продуктом), #_agile, #_upravlenie_produktom (
Управление продуктом
), #_upravlenie_proektami (
Управление проектами
), #_upravlenie_razrabotkoj (
Управление разработкой
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 15:11
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Мало кто находит выход, некоторые не видят его, даже если найдут, а многие даже не ищут.
Из “Алиса в стране чудес” В статье поднимаются следующие вопросы.
В статье затронут весьма спорный момент, не имеющий однозначной точки зрения и являющийся предметом нескончаемых дискуссий. Поэтому читая, имейте, пожалуйста, ввиду, что ваше мнение может не совпадать с представленным, но это совершенно не значит, что кто-то из нас абсолютно прав в равной степени, как и то, что кто-то – абсолютно неправ. Как говорилось в статье “С чего начинается псевдо-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? Чтобы управлять изменениями, которые, например, возникают в результате неверно проведенной фазы 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 – наиболее подходящий инструмент. Однако, для аутсорсинга данная ситуация значительно осложняется пожеланием клиента использовать схему Fixed Price при заключении контракта и предстает в невыгодном свете для обоих сторон. В какой-то мере с некоторыми допущениями можно достичь компромисса при заключении контракта и при управлении таким проектом. Важно сформировать правильное понимание и верные ожидания клиента (инвестора), оценить риски, рассмотреть по возможности иные схемы финансового взаимодействия, а в процессе реализации проекта постоянно работать с лояльностью клиента и т.д. Углубляться в вопрос не буду, так как он выходит за рамки статьи. В аутсорсинге чаще всего вопрос в первую очередь заключается в грамотном проведении фазы Discovery (Pre-sale, диагностики) в отношении Product Scope и выборе верного ЖЦ. И если выбирается Agile и Scrum в ситуации, когда Product Scope зафиксировать можно (и тем более, когда этого не было сделано по каким-то причинам вовремя, с ожиданием/предположением его проработки в будущем), и при этом в контракте – Fixed Price, на мой взгляд, совершается ошибка, которая ставит под сомнение положительный исход проекта. Спасибо за внимание! =========== Источник: habr.com =========== Похожие новости:
Управление продуктом ), #_upravlenie_proektami ( Управление проектами ), #_upravlenie_razrabotkoj ( Управление разработкой ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 15:11
Часовой пояс: UTC + 5