«Никто не забивает гвозди айфоном. Просто Scrum не всем нужен и не всегда помогает»

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

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

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

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

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

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

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

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

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 урывками: использует выборочные практики или навязывает гибкий подход сотрудникам, клиентам и внутренним подразделениям. Это заканчивается провалом, и здесь не бывает исключений.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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