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

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

• Результат проекта можно корректировать по ходу работы. Если вы строите дом, переделать его на середине стройки почти невозможно — значит, классическое проектное управление подходит больше. А вот цифровой продукт, макет, сценарий, дизайн можно менять после каждой итерации без катастрофических потерь.

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

• Высокий уровень творчества. Разработка песни, книги, клипа — по сути тот же Agile: несколько итераций, постоянные доработки, черновик за черновиком.

• Гибкая корпоративная культура. Не обязательно в компании должны быть модные офисы и пуфики — важна готовность меняться, а не внешний антураж.

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

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

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

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

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

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

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

• Жёстко зафиксированные бюджет и сроки по контракту. Если по договору нельзя менять объём и стоимость работ на ходу, смысл итеративной разработки теряется.

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

• Распределённые или частично занятые команды. Scrum задаёт организационные рамки, но не решает инженерные проблемы распределённой разработки сам по себе.

• Очень маленькие или простые проекты. Здесь полный набор ролей, встреч и документов Scrum может оказаться избыточным.

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

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

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

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

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

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

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

• Пройти обучение стандарту, а не собирать знания по отдельным статьям.

• Найти внутри компании человека, который искренне «горит» этой идеей, — сопротивление первое время будет в любом случае.

• Начинать с пилота на одном подразделении или одном проекте, а не внедрять сразу на всю компанию.

• Не выбрасывать элементы метода ради упрощения — именно из-за таких «сокращений» эффективность Scrum падает быстрее всего.

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

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