«Никто не забивает гвозди айфоном. Просто Scrum не всем нужен и не всегда помогает»
2026-02-21 10:24 Diff
https://skillbox.ru/media/code/interview-viktoria-pisarenko/

#Интервью

  • 6 май 2021
  • 0

Интервью со скрам-мастером Викторией Писаренко. Говорим о проблемах и необоснованной критике гибких методологий.

Автор статей о программировании. Изучает Python, разбирает сложные термины и объясняет их на пальцах новичкам. Если что-то непонятно — возможно, вы ещё не прочли его следующую публикацию.

Виктория Писаренко — сертифицированный скрам-мастер, тренер и Agile Project Manager в компании Luxoft (Мюнхен). Работает с командами разработчиков: помогает участникам самоорганизоваться и наладить выпуск программного обеспечения. Проводит персональные консультации и учит сотрудников разных компаний использовать гибкие методологии для решения рабочих задач.

С 2016 года Виктория ведёт тренинги по Scrum, Agile и проектному менеджменту. В 2020 году она разработала авторский курс и организовала занятия в своей академии — студенты с нуля получают профессию скрам-мастера.

В интервью мы обсудили:

— Критики часто называют Scrum и Agile мёртвыми методологиями, которые не работают в реальных проектах. Что скажешь?

— С критиками ситуация интересная. Иногда они делают полезные замечания: например, человеку что-то не понравилось и он предлагает улучшения. Это отлично: есть повод прислушаться, обсудить и попробовать усовершенствовать что-то.

Но, к сожалению, большинство людей критикуют и не предлагают встречных решений. Они противятся любым изменениям, которые заставят их что-то делать, — поставь на место Scrum и Agile другую методологию, и будет так же. У таких людей срабатывает принцип «Баба-яга против» — с этим ничего не поделаешь.

Я неоднократно общалась с критиками и пыталась понять, что им не нравится в гибких методологиях. За всё время никто ничего внятного не ответил:

Спрашиваешь: что тебе не нравится?

Получаешь ответ: зачем мне эта гибкость — хочу нормально работать.

Уточняешь: что значит нормально работать?

Ответ: просто берёшь, распределяешь задачи и делаешь.

Спрашиваешь: как распределяешь?

Ответ: ну, есть начальник, и он раздаёт задачи…

Уточняешь: так тебе нужен начальник? Без него не получается распределять задачи и работать?

Обычно на этом диалог заканчивается. Человек обижается и говорит, как он в девяностые работал на американский рынок, сделал два миллиона проектов и всё планировал в бумажном блокноте без гибких методологий. Как говорится: «А раньше бабы в поле рожали — и ничего!» Вот вам и суть всей критики.

Я хочу объяснить, что Scrum и Agile бесполезно критиковать. Это просто инструменты, эффективность которых зависит от людей. Представьте семью, которой в наследство досталась старая бабушкина квартира. Семья бедная, весь день работает и не может сделать ремонт.

Проходит месяц после заселения. Старая квартира обрастает грязью, и семье становится неуютно. Все бросают дела и занимаются генеральной уборкой: отмыли окна, стены — везде блеск и красота. Проходит неделя, и снова грязно.

Семья меняет стратегию: теперь все будут убирать не только раз в месяц, но и каждый день по чуть-чуть. Ежедневно семья встречается, делит обязанности и по 15 минут убирает. Результат: в квартире постоянно порядок и чистота.

А теперь вообразите, что эта же семья начала советоваться и узнала, что ежедневные уборки не работают, — кто-то попробовал и почему-то так решил. Если она согласится с чужим мнением, то так и останется жить в бардаке.

Scrum и Agile не существуют в вакууме, и критика часто бывает абсурдной.

Успешность гибких методологий зависит от исполнителей. Если неправильно применять Scrum и Agile, то результата не будет — методологии здесь ни при чём

— То есть гибкие методологии работают, но ими нужно грамотно пользоваться?

— Не совсем так. Есть разные типы компаний: одним гибкие методологии не подходят, а другие не умеют ими пользоваться. Важно понять, что Scrum и Agile — это не серебряные пули на все случаи жизни. Это инструменты со своими правилами и ограничениями, которые нужно учитывать.

До появления гибких методологий многие компании использовали Waterfall — каскадную систему управления проектами, где задачи не пересекаются и идут друг за другом: задача №1, задача №2 и так далее. Все участники знают последовательность и не переходят к задаче №2, пока не выполнят задачу №1.

Waterfall появился из-за строгого производственного цикла, который нельзя нарушать. Например, если компания выпускает атомные подлодки, то ей не до экспериментов: для каждого этапа разрабатывают подробную документацию и список требований по контролю качества. Всё нужно выполнять последовательно, и любое отклонение от нормы приведёт к браку или аварии.

Я понимаю специфику Waterfall — эта методология и в 2021 году подходит для определённых задач. Поэтому меня удивляет, когда кто-то категорично настаивает на преимуществах Scrum и Agile. Не нужны производителю атомных подлодок и другим подобным компаниям гибкие методологии. Здесь иная цель: соблюдать стандарты, следить за безопасностью и делать ещё много всего.

Другое дело, когда компания экспериментирует с новыми сложными продуктами. В этом случае игнорировать Scrum или Agile — значит нести убытки. Например, директор компании — адепт Waterfall. Он планирует выпустить революционную титановую запчасть для самолётов или поездов. У директора есть гипотеза, что эта запчасть будет пользоваться спросом и привлечёт крупных клиентов.

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

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

Конечно, в примере с титановыми запчастями я утрировала ситуацию — в жизни никто так не поступает. Но это не отменяет основной принцип: методологии управления проектами отличаются и предназначены для разных ситуаций. В одном случае нужен Waterfall, а в других — только Scrum или Agile.

Ещё есть третья ситуация, когда удобно комбинировать гибкие и классические методологии. Например, компания пользуется Waterfall для контроля сборки автомобилей, а с помощью Scrum тестирует и обновляет программный софт.

Это добавляет к предыдущей мысли ещё один вывод: для разных ситуаций подходят свои методологии, и каждая компания должна выбирать то, что приносит прибыль, а не просто красиво выглядит на бумаге.

У каждой компании свои цели и задачи, для которых нужен специальный инструмент управления. Не бывает универсальных инструментов, которые подходят под всё. Поэтому Scrum или Agile не всем нужны и не всегда работают. Это нормально.

— Расскажи про компании, которые неправильно используют Scrum и Agile. С чем это связано?

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

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

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

  • Если команда боится руководителя, то не будет открыто заявлять о проблемах проекта. На общих собраниях все отчитаются об успешных плановых работах, а к дедлайну найдут способ уйти от ответственности.
  • Если в коллективе токсичная атмосфера, то мало кто будет делиться информацией и думать о командной ответственности за плохую работу. Все сконцентрируются на том, чтобы не подставить себя.
  • Если заказчик не заинтересован в сотрудничестве и не смотрит промежуточные версии продукта, то команде придётся работать вслепую. Например, релизить продукт и надеяться, что заказчику всё понравится и он не изменит планы после финальной презентации.
  • Если скрам-команда зависит от медленных подразделений, то пользы компания не получит. Первые быстро выполнят работу и затем будут просто ждать, пока вторые обработают запрос и дадут обратную связь.
  • Если у компании низкие зарплаты, то сотрудникам будет неинтересно концентрироваться на обязанностях и беспокоиться о дедлайнах. Они будут думать о себе: как меньше сделать и найти новую работу.

Список можно продолжать до бесконечности. Смысл в том, что гибкие методологии не будут работать без общих усилий команды, заказчиков и руководителей компании. Если хоть одна из сторон будет саботировать или не понимать ценности подхода, то ничего не получится.

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

— Получается, скрам-команды не всем по карману?

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

Но одной высокой зарплаты недостаточно. Нужно сделать так, чтобы сотрудники не хотели увольняться и разделяли культуру компании: стремились стать частью скрам-коллектива и до конца карьеры не переходить к конкурентам. Это сложный момент, который переплетается с проблемой найма универсальных специалистов. Сейчас всё объясню, но понадобится небольшая предыстория.

Концепция Scrum существует давно: в период мировых войн ею пользовались японские авиаконструкторы, в 1986 году появилось первое описание, а в 2009-м — официальное руководство. Scrum набрал популярность и перекочевал в IT.

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

Идея универсальных скрам-команд провалилась. Крупные компании быстро поняли, что технологий слишком много и сотрудники не смогут освоить все даже поверхностно. Возьмите язык JavaScript со всем его обвесом библиотек, фреймворков и обновлений. Кажется нереальным, что человек способен всё это выучить. А теперь представьте, что одних знаний JavaScript недостаточно: нужны другие языки программирования и технологии. Универсальность стала утопией, и это будет актуально до тех пор, пока у человека есть биологические ограничения — то есть пока всех не чипируют и не встроят в мозг флешку.

Теперь — самое интересное. Рассмотрим упрощённую схему, по которой многие крупные компании собирают универсальных специалистов для скрам-команд:

  1. Компания нанимает перспективного сотрудника, инвестирует в его обучение и через время получает «своего» специалиста.
  2. «Свои» специалисты объединяются в команды, и компания получает сотрудников, воспитанных на её целях и ценностях.
  3. Когда есть штат «домашних» специалистов, ими можно жонглировать. Например, если в одной скрам-команде заболел тестировщик и проект горит, компания временно переводит его коллегу из другой своей скрам-команды.

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

Если что-то из перечисленного отсутствует, а компания пытается внедрить Scrum, могут возникнуть проблемы. Если нет ничего из необходимых условий — Scrum точно не будет работать. Бесполезно возводить стены, если нет фундамента.

Scrum и Agile сложно реализовать в компаниях, которые могут предложить только среднерыночную зарплату. Посредственные условия спровоцируют кадровую текучку — придётся постоянно переучивать новых сотрудников и делать так, чтобы до увольнения они принесли какую-то пользу компании.

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

— Что, по твоему мнению, самое сложное в Scrum?

— Сложнее всего изменить мышление человека. Объяснить, что Scrum — это про коллективную ответственность и взаимопомощь. Научить говорить о проблемах, высказывать альтернативную точку зрения, конструктивно критиковать сомнительные решения и уважать всех участников команды.

Многие не готовы к Scrum, поскольку привыкли работать во главе с хозяйственником — авторитарным начальником, перед которым нужно отчитываться за каждый шаг, всё согласовывать. Если разработчика долго контролировали, в его картине мира доминируют две модели: найти ответственного и продолжить отчитываться за результат или устроить анархию — делать работу кое-как и не напрягаться, поскольку за результатом всё равно никто не следит.

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

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

Как говорил один известный медведь из советского мультфильма: «Это неправильные пчёлы, и они, наверное, делают неправильный мёд». А я добавлю: «Только мотивированные и довольные пчёлы способны хорошо работать». Лишь счастливые люди могут делать крутой продукт и приносить пользу компании. Если человек недоволен и всё делает из-под палки, то результат всегда получается отвратительным. Этого нужно избегать.

Теперь пример. Представьте разработчика, который впервые попал в скрам-команду и всё воспринимает в штыки. Ежедневные митинги ему кажутся детским садом, а совместные мастер-классы — пустой тратой времени. Человек не понимает, почему все открыто общаются и не уходят от острых вопросов. Он в шоке, потому что некому постоянно отчитываться.

Изменим нашему разработчику мышление и посмотрим, что получилось:

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

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

Scrum — это не про совещания, доску со стикерами и прочую мишуру. Это особый образ мышления, который приводит к продуктивной командной работе

— Хорошо, а что делать с лентяями. Как изменить мышление человека, который ничего не хочет?

— Сначала нужно разобраться в причине. Часто за ленью скрывается проблема, и если в ней не разобраться, можно потерять хорошего специалиста. Например, у человека что-то произошло в семье и поэтому ему не до работы. Правильное решение — дать такому сотруднику отпуск и предложить помощь.

Случиться может что угодно, и поэтому никогда не стоит спешить с выводами. Если никакой реальной причины нет и человек просто лентяйничает, достаточно дисциплинарных мер: предупредить его и объяснить последствия. Если не помогло и сотрудник продолжает мешать коллективу, остаётся увольнение.

И ещё нюанс. Под ленью я понимаю ситуацию, когда человек не выполняет свои обязанности: срывает сроки разработки и не делает то полезное, ради чего его наняли. Например, приходит и большую часть дня просиживает в соцсетях.

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

Коллектив всегда важнее лени и невежества одного разработчика, даже если этот человек считает себя суперзвездой и незаменимым сотрудником. Scrum держится на командном духе, и никому нельзя нарушать это правило.

— Представь ситуацию: команда давно практикует Scrum, но в один момент неправильно оценила сроки и сорвала дедлайн. Такое возможно? И что делать в этой ситуации?

— Конечно, возможно. Scrum не идеален, и не нужно наделять его сакральным смыслом. Проекты бывают непредсказуемыми, и поэтому ошибки неизбежны.

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

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

Вернёмся к вопросу. Если команда провалит дедлайн, то после ретроспективы появится план для исправления ситуации. Как будут развиваться события, зависит от обстоятельств: заказчик может сдвинуть сроки, закрыть проект или выбрать что-то ещё. В любом случае команда обязана сделать выводы и постараться в следующий раз не допустить проблем со сроками.

В древней Японии мастерство самураев определяли по числу шрамов на теле. В скрам-командах крутость специалистов измеряется количеством ошибок, из которых получилось извлечь урок. Они дарят опыт, и их не стоит бояться.

Опасность возникает тогда, когда ошибки маскируют нарочно. Мы уже говорили, что до Scrum компании пользовались водопадной моделью — Waterfall. До появления компьютеров план по Waterfall часто оформляли в виде огромного стенда — так сотрудники узнавали, какие задачи и в какой срок нужно выполнить.

Проблема заключалась в том, что из-за неточностей в планировании стенд приходилось постоянно переделывать. Был специальный человек, который незаметно для большинства менял таблички с задачами и сроком их выполнения. Это ничем хорошим не заканчивалось: сотрудники замечали подвох и переставали ориентироваться на план. Они понимали, что если не успеют или сделают неправильно, то специальный человек полезет на стенд и просто заменит таблички. Обман породил недоверие, а в современных компаниях такого быть не должно.

Scrum не выдаёт себя за идеальную методику управления проектами. Всё предусмотреть невозможно. Вы будете постоянно ошибаться, исправлять недочёты и становиться лучше. Это непрерывный процесс — кайдзен

— Как убедить людей перестать критиковать Scrum и Agile. Можешь в завершение что-нибудь посоветовать?

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

Рентгеновский аппарат отвечает только за снимок. От него не зависит, придёт человек в поликлинику или нет, правильно врач выпишет заключение или ошибётся, будет человек лечиться в случае болезни или оставит всё как есть.

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

Никто не обвиняет рентгеновский аппарат в воспалении лёгких. Всем понятно, что человек заболел по какой-то причине. Так же и Scrum: система управления проектами не может быть виновата в сорванных дедлайнах и других проблемах компании. Всегда виноваты люди, которые её неправильно внедрили или не так используют. Мне кажется, критики эту мысль никогда не усвоят.

Они напоминают противников медицины. Это люди, которые отказываются идти в больницу и делать флюорографию, потому что чувствуют себя хорошо и считают, что проблемы нет. Никакой рентгеновский аппарат им не нужен. Плюс он вредный, дорогой и мотает электричество. Лучше вместо него йод купить.

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

— Спасибо за интервью!

— Желаю читателям Skillbox Media прокачивать критическое мышление и принять кайдзен. Всем удачи!

Научитесь: Профессия Менеджер проектов + ИИ Узнать больше