Давайте я еще накину конкретики, чтоб понятно было нафига я

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

В проектном аутсорсинговом IT-бизнесе - вы продаете скрам себе :), простите. Ваша цель сделать проект в срок и качественно :)

Если надо в срок качественно запилить скоуп, то зачем тут скрам?

В твоих условиях продавай лучше Метод, давай я тебя обучу его применению. (это +50% нагрузки к Скраму в части планирования и контроля) Вот в аустсорсе слишком проекты по фикс цене, жесткий контроль потраченных часов и важно чтобы время и бюджет сошлись. Там должна быть высокая стандартизация задач и их оценок. А вот если компания продала аутстаф, то тогда там будет Скрам, потому что Клиент не понимает что хочет. и нужно экпериментировать, и он сам берет на себя риски.

Леша, красавчик. Я б тоже попробовал продать. Я кстати про тебя говорил ребятам, но они пока жестко привязаны к своим экранам и джире. Так что попозже))

:) если вы не нашли ответ на этот вопрос - то вам он и не нужен. Работать без гибких технологий вполне возможно. Это просто уровень подхода к контролю за внутренним производством. Делать его или нет - Ваш выбор.

Я тут редко бываю. И в дискуссии обычно не лезу. Но свои пять копеек вставлю. Фреймворк скрам это неплохой (и достаточно надежный) инструмент для создания ПРОДУКТОВ (даже если в 2020м его создатели захотели расширить контекст). Он имеет ряд ограничений. Он хорошо(и надежно) работает только в строго определенных условиях на определенной стадии жизненного цикла продукта. Применить фреймворк скрам целиком в проектном ИТ-аутсорсе скорее всего не выйдет. Отдельные компоненты вполне применимы. Кажется все

Продавать не нужно ничего. А вот объяснать область применимости инструментов (фреймворков) важно уметь. Люди долждны принимать решение на основе понимания, а не за счёт маркетинга. Я для себя придумал свою авторскую модель для понимания применимости Scrum и объясняю через модель типизации продукта, модель управления знаниями и переход потом уже к Cynefin. Дополняя разумеется модели, примерами из жизни.

Экраны не важно. Цифры можно хоть в экселе считать (есть запись вебинара и экселька ) . тут важно сменить парадигму планирования и управления. Если проект уже продалбываются (а запрос на это видимо есть) , то нужно включать управление Буфером проекта. Вначале это буфет в формате Надежного скрама, а потом и Цепь начнётся.

Продать в моем понимании это значит объяснить в чем ценность, польза. Все остальное я называю словом "впарить". Я не про впарить, а именно про продать.

Ого, тут уже обучение предлагают)

В личку к тебе попозже приду. А то оффтоп

У нас личные связи ;)

Ээх, Лёш)

В аутсорсе-то? По Скраму мы можете продавать Time and Materials. Для проектной работы особо смысла нет.

Гибкие технологии - это только скрам разве? Я спрашиваю конкретно про скрам-фреймворк, а не про аджайл в целом.

Scrum - это самый популярный фреймворк Agile и лидирует с большим отрывом. Его авторы подписанты манифеста Agile. Если выбор не между Agile и Waterfall, а уже в конкретных фреймворках Agile стоит, то надо знать и изучить очень детально бизнес-контекст, чтобы принять решение о рекомендации Scrum, XP, Nexus, LESS, SAFE, etc. Каждый фреймворк несёт свои особенности и подходит под разный орг. дизайн. Чаще всего выбирают Scrum, когда не знают как выбирать между фреймворками, часто это будет хороший выбор, но не всегда. 😊

Опять же выбор за конкретной методологией за Вами.. Что именно вам нужно и как у вас строится работа. Если у вас "конвеер" - то канбан будет уместнее, чем скрам. А если не очень большое проекты с небольшими полноценными командами - то скрам, возможно, подойдет лучше, чем другие. Если у вас большой коробочный продукт - то может нужно вообще смотреть в сторону других решений и даже не очень гибких. Вы спрашиваете как продать джип, но не говорите что, возможно, живете в центре города и дальше магазина не выбираетесь :)

Каждый раз очень грустно видеть, как аутсорсинговый бизнес пытается продать себе скрам. Когда спринты заводятся для более лучшего планирования и координации (целей спринтов в них нет), когда на ретроспективах обсуждаются проблемы коммуникации с заказчиком без собственно самого заказчика (ессно, ему ж не продали это всё). Плакать хочется, когда спрашиваешь команду "как вы измеряете бизнес-ценность?", а они, включая аналитика и проектного менеджера (который корчит из себя product ownerа) несут какую-то откровенную пургу. Простите, но скрам нафиг не нужен, если там нет собственно работы с бизнес-ценностью.

Я ж даже рассказал про свой кейс. Спрашивал про ваши кейсы. Может быть у вас есть кейсы продажи скрам-фреймворка? Советы мне не нужны, потому что я сегодня ничего нового в этом чате не прочитал. Особенно повеселили переводы англоязычных текстов про киневин и скрам.

Если вы не можете стать бизнесом для команды - то да, есть такие проблемы. Но если подойти чуть гибче ? Может не вытаскивать программистов на встречу заказчиком? Если все понимание продукта уже есть у продаката ИТ-отусорсера?

Вот это уже теплее. Когда заказчик купил не разработку, а решение своей вполне себе бизнесовой проблемы. Можете примерчик?

Есть два продакта (или чаще всего один) - заказчик (редко) и исполнитель (чаще) (ну или проджекты если проекты небольшие) Цель получить полное видение продукта от заказчика во внутренний контур к своему продакту (дальше это видение, просто поддерживается собственными изысканиями + постоянным диалогом с клиентом) А работа внутри уже идет на своего заказчика: у него есть видение и бюджет. При этом иногда внешнему заказчику даже не нужно знать как именно ведется разработки -он просто будет получать результат: макет, МВП, 1 версия продукта и т.д. Но: как выше уже говорили - это очень хорошо применяется именно к части собственно создания продукта. Если у вас решения в которых подготовка и поствнедрение занимает больше времени чем собственно разработки то, опять же, все движение в сторону скарама под вопросом.

То что они одни из подписантов, не значит что это истинный ASD. Рекомендую прочитать про всех остальных, там много интересного.

Я вспомнил! Клиент просил Agile, а жаловался на "нифига не делают и сайт тормозит" Но! Это продуктовая компания, зарабатывают на сервисе где ИТ-только часть доставки сервиса. Там мы поправили КПЭ , и запустили Скрам-цикл. Дополнив требованиями по обеспечению качества. (модульные тесты). Плана развития не было - поэтому провели стратсессию, и определили направления генерации идей. итог: за 5 лет компания удвоила доход.

Безвластный proxy product owner detected. Его решения уважают ровно до той степени, пока они укладываются в то, что ему сверху спустили. Простите, это не то.

А в чем власть, простите? У всех кто-то есть сверху.

В том, чтобы менять видение, очевидно.

А, так то не власть а ответственность за продукт :) Вы не хотите брать ее на свою компанию, но зато ответственность за ненужный заказчику метод готовы возложить на него :) Собственно, да в этом и кроется вся суть проблемы :) Нет, таких примеров вы не найдете :) и когда сами сможете впарить будете скрывать :) чтобы у вас все было и вам за это ничего не было

Я тоже часто делаю такую ошибку - делаю неверные выводы за других людей.

Круто! Вы где его взяли? Как он вас нашел? А самое главное, с чем он вас сравнивал и по каким критериям?

Микроскопом можно забивать гвозди вместо молотка. Он может плохо для этого подходить. Может быть даже сломаться. Проблема не в фреймворках, а в понимании контекста их применимости. Остерегайтесь истины... Хотя она очень востребована, истина может быть опасной для искателя. Мифы и успокаивающие лжи гораздо проще найти... (с)