Scrum: кому подходит гибкая методология

Разбор по мотивам вебинара РШУ «Как внедрить гибкую методологию Scrum: возможности и ограничения».

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

Где Scrum действительно полезен

1. Результат проекта можно корректировать по ходу работы. Если вы строите дом, переделать его на середине стройки почти невозможно — значит, классическое проектное управление подходит больше. А вот цифровой продукт, макет, сценарий, дизайн можно менять после каждой итерации без катастрофических потерь.
2. Высокая неопределённость конечного результата. Особенно это касается инновационных проектов — по словам Цымбала, специализирующегося именно на них, там часто заранее непонятно, каким должен быть сервис или продукт, и приходится буквально усилием воли останавливаться на каком-то образе результата, чтобы вообще начать работу.
3. Высокий уровень творчества. Разработка песни, книги, клипа — по сути тот же Agile: несколько итераций, постоянные доработки, черновик за черновиком.
4. Гибкая корпоративная культура. Не обязательно в компании должны быть модные офисы и пуфики — важна готовность меняться, а не внешний антураж.

Маск, Роскосмос и один и тот же метод с разным результатом

Илон Маск в интервью прямо говорил про SpaceX — соберём ракету, если девять взорвутся, десятая полетит. Это Agile в чистом виде: быстрые итерации, допустимость ошибки, обучение на провалах. Противоположный подход — годы разработки одной ракеты в расчёте, что она точно взлетит, а если нет, значит, во всём виноваты исполнители. Дело не в том, что один подход правильный, а другой нет, — просто там, где решения завязаны на государственные деньги и жёсткую отчётность, менять план на ходу физически сложнее.

https://qarocks.ru/agile-methodology/

В противоположность этому Сбербанк, во многом стал тем, чем стал, именно благодаря раннему и полноценному переходу на Agile: сначала внедрили Scrum, потом адаптировали его под себя, но принцип гибкости остался в основе.

Scrum — это не только для IT

Хотя порядка 90% Scrum-проектов приходится на IT-сферу — просто потому, что цифровой продукт легче переделать, чем физический. Андрей Цымбал привёл пример из своей практики: инжиниринговая компания «Х-Энерго», занимающаяся сложными техническими решениями для производственных объектов, внедряла Scrum не для основной деятельности, а для проекта по настройке внутренней CRM-системы. Метод точно так же сработал на непрофильной, но чётко ограниченной задаче.

Ещё один живой пример — небольшой бизнес по производству кожаных изделий (кошельки, сумки, чемоданы), 20–30 человек, продажи через маркетплейсы и одну офлайн-точку. Собственник самостоятельно изучил Scrum, внедрил его в компании — и, по его собственным словам, теперь может жить и работать удалённо по полгода, потому что процессы выстроены как часы. Это тот самый случай гибкой корпоративной культуры без каких-либо внешних атрибутов «модного» digital-бизнеса.

Где Scrum, скорее всего, не сработает

1. Жёстко зафиксированные бюджет и сроки по контракту. Если по договору нельзя менять объём и стоимость работ на ходу, смысл итеративной разработки теряется.
2. Незрелая или несамоорганизующаяся команда. Даже отлично обученный Scrum-мастер не вытянет метод в одиночку, если остальная команда относится к процессу со скепсисом.
3. Распределённые или частично занятые команды. Scrum задаёт организационные рамки, но не решает инженерные проблемы распределённой разработки сам по себе.
4. Очень маленькие или простые проекты. Здесь полный набор ролей, встреч и документов Scrum может оказаться избыточным.

Будьте внимательны: команда способна незаметно «заиграться» в бесконечные доработки — «а давайте ещё немного улучшим», «а давайте ещё раз пересмотрим». Без здравого ограничения по времени Scrum рискует превратиться в бесконечный процесс без финала.

Частичное внедрение убивает метод

Андрей Цымбыл

Бизнес-консультант, Master of Business Administration (MBA), сертифицированный руководитель проектов (PMI PMBOK, PRINCE2, Agile - Scrum, ПМ СТАНДАРТ). Проводил корпоративное обучение для представителей Роснефть, Уралкалий, РКК Энергия, Самара Электрощит, МТС, Лукойл, Ростелеком, Норникель, ВТБ, VK, Объединённая двигателестроительная корпорация и др.

  Отдельная и, пожалуй, самая частая ошибка — выборочное внедрение: убрать одну встречу, сократить роли, не назначить Scrum-мастера. В результате от Scrum остаются только доска и слово «спринт», а вся его логика — постоянная рефлексия и улучшение процесса, а не только результата, — исчезает. 

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

Вывод простой: формальности вокруг Scrum нужно подбирать под контекст, а не бездумно копировать чужой шаблон.

Что не заменит даже ИИ

Автоматизировать можно рутину: анализ скорости команды по истории спринтов, уточнение оценок задач, обработку обратной связи, суммаризацию встреч, черновую приоритизацию бэклога. А вот распределение задач по бизнес-ценности в реальном времени, по словам Цымбала, всё ещё держится на человеческой коммуникации внутри команды — формализовать этот процесс полностью пока не получается.

Как внедрять, если решили, что метод подходит

1. Пройти обучение стандарту, а не собирать знания по отдельным статьям.
2. Найти внутри компании человека, который искренне «горит» этой идеей, — сопротивление первое время будет в любом случае.
3. Начинать с пилота на одном подразделении или одном проекте, а не внедрять сразу на всю компанию.
4. Не выбрасывать элементы метода ради упрощения — именно из-за таких «сокращений» эффективность Scrum падает быстрее всего.

В сухом остатке

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

Scrum подходит не каждому проекту. Управление проектами — всем.

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

На программах проектного трека Русской Школы Управления вы научитесь выбирать между гибкими и классическими подходами, управлять рисками, ресурсами и ожиданиями участников проекта — и выстраивать систему, в которой Scrum становится рабочим инструментом, а не набором формальных ритуалов.