Brief 
Тендеры и лиды
Информация
Если спросить десять IT-директоров, как у них со скрамом, то семь скажут: «Вроде вводили, вроде писали правила, но толку мало», два — «Он работает у нас… иногда», а один уверяет, что никакого скрама у них и не было (это уже отдельная история). Скрам стал почти обязательным в описании вакансий, презентаций и «агильных» стратегий, но на практике он далеко не всегда даёт обещанные чудеса.
В России, где и команды, и контексты весьма разнообразны, эта проблема проявляется особенно ярко. Давайте разбираться — без занудства, но с реальными причинами и выводами.
Первое, что важно понять: скрам — это фреймворк, а не «готовая методология успеха». Он задаёт структуру, роли, церемонии, но он не отвечает за содержание работы, мотивацию людей или бизнес-цели. Многие ожидают, что как только в заголовке команды появится слово Scrum, продукт начнёт расти, багов станет меньше, а эффективность — выше. Это заблуждение.
Скрам подразумевает, что есть Product Owner (с понятным приоритетом беклога), Development Team (с готовностью выполнять задачи) и Scrum Master (люди, которые следят за процессом).
Но на практике:
Результат: скрам существует на бумаге, но в голосе команды его нет. Это не скрам не работает — это его искажают.
Это классический аргумент, особенно популярный в российских аутсорс-компаниях и у проектов с нестабильными требованиями. Дескать, заказчики меняют требования, дедлайны плавают, а команде надо реагировать на всё это мгновенно. Скрам здесь воспринимается как тяжеловес, мешающий «быстро реагировать». Но проблема не в скраме, а в путанице между гибкостью с реактивностью.
Скрам предполагает инкрементальность и частую обратную связь — это не про негибкость, а про структуру реакции. Если команда просто копирует церемонии, но не привносит в них смысл (например, ретроспектива не приводит к реальным улучшениям), то скрам превращается в ритуал, а не в инструмент.
Скрам часто внедряют сверху: HR говорит, что он нужен, PM-ы говорят, что это модно, а руководители хотят видеть KPI-таблицы. Но никто не объясняет команде зачем скрам, какие проблемы он помогает решать и какие ожидания от него у бизнеса.
В результате:
Скрам тут — как вывеска, но не как мышление.
В российских IT-командах часто наблюдается ситуация, когда роли скрама формально распределены, но ответственность реально размыта. Вот что это означает:
Вместо работы в одном поле команда живёт в трёх мирах: legacy-система, долгосрочный проект и «срочные баги от маркетинга».
Скрам поощряет оценку через скорость поставки ценности, а не через количество строчек кода или закрытых тикетов. Многие российские компании всё ещё измеряют эффективность через:
Это создаёт неприятный эффект: команда делает много «видимых» дел, но клиенту не становится лучше. Скрам требует измерений в терминах ценности: рабочий фичерелиз, уменьшение времени на обнаружение ошибок, рост удовлетворённости пользователей. Без этой переориентации скрам остаётся красивым словом.
На российских IT-форумax и в HR-опросах (VC.ru, Habr Career, LinkedIn HR группы) наблюдается явная дискуссия:
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13260 тендеров
проведено за восемь лет работы нашего сайта.
«Скрам в у нас внедрили, но его никто не уважает» — частая формулировка.
Например, в опросах резюмируется, что команды либо:
Этот феномен не уникален для России, но проявляется из-за сочетания культурной модели управления, высокой нагрузки и часто неполных бизнес-требований.
Скрам действительно работает там, где:
Если этого нет — скрам будет работать так же хорошо, как «инструкция по йоге» у человека, который ни разу не делал растяжку.
Забудь на минуту мысли типа «надо поменять процесс». Сначала стоит:
1. Пересмотреть ожидания от скрама. Спросить: «Что именно вы хотите получить?» Ответ вроде «скорость» мало что скажет. Надо точные цели.
2. Оценить зрелость процессов. Если ветка релиза — это спагетти, а backlog живёт в Google Docs — скрам бессилен.
3. Настроить правильные метрики. Пара примеров:
Эти метрики действительно отражают работу, а не только занятость.
4. Прокачать роли, а не названия. Не «есть Scrum Master», а чтобы он реально помогал убирать барьеры.
Скрам не работает не потому, что он плох, а потому, что его не понимают правильно и применяют как волшебную формулу. В России это особенно заметно из-за сочетания культурных моделей управления, сложных продуктов и гибридных требований.
Скрам может быть очень мощным инструментом, но он не заменяет ясной стратегии, зрелых процессов и ответственного менеджмента. Он усиливает зрелость, но не создаёт её с нуля.
Короче говоря: Scrum работает только там, где команды говорят честно — не про «галочки», а про результат.
