Как применить Scrum в вашем бизнесе?

Вопрос, вынесенный в анонс, команда Executive.ru решила задать тренеру компании ScrumTrek Алексею Пименову. Алексей прошел путь от разработчика до руководителя разработки. Руководил проектами с числом участников более 100 человек. Руководил департаментом разработки с числом сотрудников более 100 человек. Работал в компаниях «ФИНАМ», R-Style, Infowatch, Positive Technologies, Vocord Telecom. Реализовал проекты с компаниями «Мегафон», «Сбербанк», «Сбербанк Технологии», «Сбербанк Страхование», «Альфа Банк», «Альфа Страхование», «Ростелеком», «Газфонд», «Инвитро», «РусФинансБанк».

Executive.ru: Алексей, поделитесь, пожалуйста, вашем видением: что такое Scrum?

Алексей Пименов: Scrum – не методология, это организационный фреймворк. Scrum не имеет никакого отношения к проектной деятельности, он создан исключительно для того, чтобы создавать инновационные продукты. Он нужен тогда, когда заказчик не имеет представления о том, как должен выглядеть продукт. Простыми словами, мы постоянно выдвигаем гипотезы о том, каким должен быть продукт, как можно быстрее эти гипотезы реализуем и получаем обратную связь. Повторяя эти циклы, мы пытаемся «нащупать» продукт. Практика Scrum ориентирована на идеологию fail fast, то есть мы должны как можно чаще и быстрее ошибаться, из каждой ошибки делать выводы и таким образом развиваться и развивать продукт.

Executive.ru: Речь идет в первую очередь о создании программного обеспечения?

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

Executive.ru: Можно ли сравнивать Scrum с какими-то другими организационными фреймворками?

А.П.: Scrum часто противопоставляют классическому каскадному подходу, где производство продукта представлено в виде последовательности определенных этапов работ. Но этот подход не работает в случае создания продукта, который невозможно детально спроектировать, и, соответственно, требования к которому детально описать тоже нельзя. Соответственно, чтобы решить эту проблему, наборы маленьких каскадов сделали повторяющимися. Так появился итерационный процесс. Он позволяет «нащупать» продукт, но длительность одной итерации получения продукта достаточно велика.

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

Если привести пример со строительством, мы не ставим фундамент, не строим этаж за этажом, а каждый раз полностью разрушаем дом и возводим заново в новой конфигурации.

Семейство подходов к организации производства Agile базируется на четырех основных идеях:

  1. люди и их взаимодействие важнее процессов и инструментов;
  2. рабочий продукт важнее исчерпывающей документации;
  3. работа с заказчиком важнее, чем согласование контракта;
  4. реакция на изменения важнее, чем следование плану.

Если какой-либо инструмент соответствует этим четырем ценностям, его причисляют к семейству Agile. Два наиболее популярных сейчас инструмента – это Scrum и Канбан. Канбан пришел в IT-отрасль в середине 2000-х годов, и является более универсальным инструментом. Его можно использовать не только для создания инновационных продуктов, но и для эволюционного развития и оптимизации любого производственного процесса.

Executive.ru: Везде ли можно применять Scrum?

А.П.: Нет, не везде. В любой деятельности мы выделяем две части: активность Change, когда мы что-то придумываем, и активность Run, когда мы воплощаем придуманное. И бывает так, что Scrum невозможно наложить на активность Run. Например, в строительстве можно применять Scrum на этапе активности Change, то есть проектирования и создания конструкторской документации, но пока невозможно применять на этапе активности Run, то есть возведения здания. Существуют очень агрессивные, очень быстро меняющиеся среды, в которых нельзя использовать Scrum. Пример – поддержка программного продукта, большие потоковые процессы.

Executive.ru: А в каких сферах целесообразно применять Scrum?

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

Executive.ru: Приходится ли вам разъяснять клиентам принципы работы Scrum? Или к вам чаще приходят осведомленные заказчики?

А.П.: Иногда бывает, что к нам приходят люди, обладающие знаниями, но неточными или искаженными. Клиенты из IT-отрасли обычно обладают базовыми знаниями и обращаются к нам, когда возникают сложные задачи. Например, координация работы 50 команд в рамках глобального проекта. За пределами IT-отрасли часто приходится начинать разъяснения практически с нуля, когда клиенты приходят, потому что сейчас модно быть Agile и Scrum. Но все же чаще всего к нам обращаются, когда уже есть понимание и желание использовать Scrum. Бывает, что люди сами поэкспериментировали и поняли, что у них что-то не получается. Сам рынок толкает нас вперед. Например, когда молодые виртуальные банки быстро делают какие-то инновационные вещи, это влияет на крупные банки, у которых тоже появляется желание быстро внедрять инновации.

Executive.ru: Когда вы разъясняете принципы работы Scrum, потенциальные заказчики часто пугаются?

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

Executive.ru: Требуются ли для Scrum какие-то специфические условия? Например, чтобы руководитель имел верное представление о Scrum, или что-то еще?

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

Участники команды должны иметь желание и возможность постоянно взаимодействовать друг с другом. Это должны быть Т-люди. Ножка буквы – это профессиональные навыки, а крылышки – понимание того, как работают люди, которые до и после меня что-то делают с продуктом. И пограничные проблемы решаются участниками команды в зависимости от ситуации, а не перебрасываются друг на друга. Каждый участник команды должен в ней «раствориться». Если он не стал «раствором», он станет «осадком». Если говорить об IT-отрасли, то важна инженерная культура организации. Например, компании требуется две-три недели на проверку качества продукта, потому что они делают это вручную, а нам надо каждые две недели выпускать новую версию. Поэтому настоящие Scrum-команды на старте проекта много инвестируют в автоматизацию инфраструктуры проверки, инфраструктуры сборки, инфраструктуры публикации. Бывает, что внутренние нормативные правила компании обязывают вести сложную документацию, которая не имеет ценности для проекта, но отбирает у него ресурсы. Бывает, что невозможно заключить контракт по модели Time & Material, компания заключает контракты только с фиксированной ценой. А мы не можем назвать фиксированную цену, потому что не знаем, в какой момент мы подтвердим гипотезу о продукте, если мы делаем инновационный продукт.

Executive.ru: Существует ли некий стандартный набор опасений, который возникает у потенциальных заказчиков Scrum?

А.П.: Конечно, он есть. В первую очередь, беспокоит, будут ли реальные улучшения, не получится ли так, что придется вложить очень много усилий и не получить никакого ценного результата. Любые изменения с точки зрения продуктивности соответствуют букве J – провал, потом ступенька вверх. И все очень боятся вот этого провала. Кроме того, пугает неопределенность. Непонятно, как бюджетировать подобные проекты. Мы идем навстречу, предлагаем решения, даем новые инструменты.

Executive.ru: Насколько процессы Scrum прозрачны и понятны для заказчика?

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

Некоторые компании заставляют сотрудников в конце недели заполнять табели учета рабочего времени, распределять свои 40 часов на какие-то задачи. Мало кто вписывает реальное время, поэтому проектный график может не соответствовать реальности. Люди не рассказывают о рисках и проблемах, потому что боятся, что им за это влетит. Классическая система управления не поощряет неудачи, она пытается их обходить. А мы поощряем неудачи – нужно как можно быстрее наделать ошибок, исправить их и вынести соответствующие уроки. Мы устраняем страх неудачи. Если возникла проблема, мы не ищем виноватого, мы выясняем, что нужно сделать для того, чтобы в будущем это не повторилось.

Executive.ru: В октябре 2016 года на Executive.ru стартует ваш онлайн-тренинг «Внедрение и использование Scrum». На кого он расчитан? На руководителей или исполнителей?

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

Executive.ru: Насколько это будет понятно и полезно людям, не имеющим технического бэкграунда?

А.П.: Я постараюсь говорить максимально просто, без злоупотребления специальной терминологией, буду приводить примеры, так что людям без технического бэкграунда все должно быть понятно. И мы будем играть в игру Iterative Incremental Big Bang, где житейскую проблему (например, как организовать свадьбу или построить дом) нужно будет решить тремя способами – каскадным, итеративным и инкрементальным.

Executive.ru: Чему научатся слушатели вашего онлайн-тренинга? Что получат в итоге?

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

Расскажите коллегам:
Комментарии
IT-консультант, Москва

Двоякое впечатление от статьи. С одной стороны, много интересных мыслей. С другой стороны...

Слишком много английских слов. А добавить немного "импортозамещениея" нельзя?

При всем уважении, не могу согласиться с тем, что "Scrum не имеет никакого отношения к проектной деятельности, он создан исключительно для того, чтобы создавать инновационные продукты". А, простите, создание продукта - не проект? Тогда дайте определение того, что такое "проект". Автор сам пишет об "активности Change". а это и есть проектный подход, т.к. любое изменение по сути - проект. Определений термина "проект", кстати, много.

Вообще-то Scrum самими авторами позиционируется как методика управления проектами. И была она разработана именно для того, чтобы управлять проектами по разработке продуктов методами Agile в отличие от "водопадного" или "каскадного". Иначе сама разработка становилась неконтролируемой. Это желательно знать, а не "предполагать", особенно если кого-то этому обучаешь. Может, стоит выйти за рамки жизни "разработчика" и посмотреть на эту деятельность "сверху вниз" с точки зрения управленца? Мы, например, используем тот же Канбан для управления подразделениями наравне и совместно с другими управленческими процессно - ориентированными инструментами. И используем принципы Scrum и Канбан для поддержки, чего, по заявлению автора, делать нельзя. Т.е. мы используем принципы Agile и при активностях "Run".

Жизнь, как правило, всегда несколько сложнее, чем нам кажется, поэтому не стоит излучать излишнюю уверенность в собственной правоте. Это, зачастую, - источник ошибок. Если браться кого-то обучать, то, как мне кажется, надо доносить до учеников мысль о том, что учебный материал - не догма, а средство, "стартовый пинок" для запуска процесса познания и последующего самообучения. Adopt and Adapt, please.

Вице-президент, зам. гендиректора, Москва

«Если в качестве инструмента у вас имеется лишь молоток, каждая проблема начинает напоминать гвоздь» (Абрахам Маслоу)


Алексей Пименов:
Он нужен тогда, когда заказчик не имеет представления о том, как должен выглядеть продукт.

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

Игорь Сапрыкин Игорь Сапрыкин Руководитель, Москва

Полезный инструмент для исследователей, который можно использовать не только в инновационной бизнес-деятельности, но и в бизнес-образовании.

С удовольствием возьмем на вооружение, спасибо за актуальную статью!

Руководитель управления, Москва
Сергей Новиков пишет:
«Если в качестве инструмента у вас имеется лишь молоток, каждая проблема начинает напоминать гвоздь» (Абрахам Маслоу)

Алексей Пименов:
Он нужен тогда, когда заказчик не имеет представления о том, как должен выглядеть продукт.
На подобном проекте можно сразу ставить крест с точки зрения результата для клиента.. хотя если клиент платит за количество проведенных совещаний и сразу оплачивает все переделки, то можно и заработать )

Ну да, вот это и есть позиция, являющаяся самым существенным ограничением в распространении гибких методологий. Видимо, Сергей прочно живёт в мире, где решения готовы и однозначны. Не спорю, этот мир ещё очень обширен, и позиция эта правомерна. В этой реальности живут и поборники подходов, описываемых ФЗ-44 и ФЗ-223, где любая итерация будет мучительна. Но автор, вроде бы подчеркнул, что есть и другой мир, мир инноваций, где решения неочевидны, а итерации неизбежны. Здесь, порой, без SCRUM и T&M обойтись невозможно, иначе всё выливается в убийственную бюрократию. И то, что заказчик плохо представляет себе, как должен выглядеть результат, это в новых технологиях - общее место.

Researcher, Москва

Я практик! и мы уже около 3(три) лет используем Agile как идеологию и НЕ ИСПЛЬЗУЕМ Scrum как технологию.

Расскажу ка мы это делаем в своих терминах.

1. Шаг. Получаем от заказчика "хотелку". Это либо текст либо интервью с заказчиком. Выясняем(переводим на наш язык) что заказчик имел ввиду и что он понимает под "тем" что написал/сказал. Все протоколируем.

2. Шаг 2. Пишем (сами) как бы от имени заказчика Техническое Задание (ТЗ). В "нашем" ТЗ мы определяем конечный продукт для заказчика.

3. Шаг 3. Согласовываем ТЗ (иногда долго) так как после прочтения ТЗ у заказчика часто возникают серьезные корректировки своей первоначальной "хотелки". Вносим правки в ТЗ. УТВЕРЖДАЕМ (подписываем).

4. Шаг 4. Разбиваем ТЗ на этапы (спринты), планируем.

5. Шаг 5. Изготовляем первый этап, тестируем и демонстрируем заказчику.

6. Шаг 6. Обсуждаем этап с заказчиком и (часто) корректируем ТЗ и этапы. Утверждаем, подписываем

7. Шаг 7. Исполняем шаг 5, 6 по этапам до завершения.

8. Шаг 8. Финальная демонстрация готового продукта. Внедрение и запуск в пром эксплуатацию.

Нач. отдела, зам. руководителя, Москва
Татьяна Орлова пишет: При всем уважении, не могу согласиться с тем, что "Scrum не имеет никакого отношения к проектной деятельности

Многое о чём говорит в интервью Автор отличается от множества описаний Скрум. Попытался найти наиболее близкое среди множества методов, которые относя к AGILE: то ли кусочек можно найти в связи OpenUP, RUP, но и что-то отличается. Наибольшее отличие в этой статье и предыдущей - это отсутствие упоминания о заключительном этапе поставки полностью работоспособной системы -> при использовании описываемого им фреймворка.

Такое впечатление, в связи с отличиями с наиболее распространёнными взглядами на Скрум, возможно, Автору стоило придумать новое название для описываемого им фреймворка. ...

В статье Agile is Dead упоминается Dave Thomas, который говорит, что контроль над использованием термина Agile уже потерян. Возможно со Скрум произойдёт тоже самое - статья тому пример.

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

А кто будет клиентом, с которым будете работать при обучении? И если это слушатели, то как часто надо менять программу обучения?


Владимир Зонзов +10253 Владимир Зонзов Директор по производству, Украина

Валерий Иванович, мне непонятно, почему Вы (в сообщении от 14 сентября 2016, 19:35) обычные шаги разработки новой продукции называете «применением Agile как идеологии».

Да, разработка новой продукции чаще происходит в условиях заведомой недостаточности «исходных данных от заказчика» (далее, ИД). Да, создание новой продукции относится, скорее, именно к проектной деятельности. Что убедительно показано в книге Дж.Джонса «Теория проектирования».

Шаги 1-3 (а, в целом, и шаги 1-8) – обязательные в проектной деятельности. Они предусмотрены нормативными документами. Например, ЕСКД, ГОСТ-ами по организации процесса разработки строительных проектов.

В крупных проектных организациях, я всегда видел многостраничные вопросники, которыми «выпытывались» ИД. Потому что, ИД требуется много. И какие ИД нужны лучше знают разработчики проектов. Ведь, к примеру, количество разделов строительного проекта (для разработки которых «выпытываются» ИД) – два десятка (их шифры: АР, АС, ВК, ОВ, ...). И, тем не менее, даже «выпытанный» заказчик часто нуждается в корректировке ИД, по текущим результатам проектирования. Особенно это имеет место быть в многосторонних работах. Где продукция отдельных подрядчиков является частями конечного изделия. Что часто вызывает необходимость итерационного согласования смежных частей, на каждом этапе разработки изделия.

Часто темп разработки изделия диктует необходимость применения «заглушек». Ими компенсируется временная недостаточность ИД. Применение «заглушек» приводит к разбивке этапов создания продукции на, так называемые сейчас, «спринты». Еще недостаточность ИД, бывает, обусловлена недостаточностью научных представлений о продукции. Поэтому, проектный цикл, в рамках ЕСКД, дробится на этапы (НИР, ОКР, этапы подготовки к серийному производству).

Надёжным средством контроля правильности ИД, ТЗ и результатов этапов разработки являются макеты. В этом нетрудно убедится, полистав соответствующие нормативные документы.

Так что, причем здесь «скрам», «спринт» и «Agile»? – А при том, что последние – это средства «глобально» организованного процесса воровства прошлых знаний (путём их «перелицовки» новыми терминами). В результате такого процесса, разрушается единство знаний. Они фрагментируются. Что позволяет «консультантам» «зарабатывать»; а «глобальным» организаторам процесса – «зомбировать» нынешних «специалистов».

Из-за значительного и непреодолённого «разрыва поколений», нынешние «профи» податливы зомбированию. Но, нам-то зачем поддаваться?

.====================================.

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


Researcher, Москва
Владимир Зонзов пишет:
Да, разработка новой продукции чаще происходит в условиях заведомой недостаточности «исходных данных от заказчика» (далее, ИД). Да, создание новой продукции относится, скорее, именно к проектной деятельности. Что убедительно показано в книге Дж.Джонса «Теория проектирования».

Владимир Иванович! Я с Вами согласен на 95% !!

Применение Agile в наших разработках проявляется только в шагах 5 и 6. Это вовлеченность заказчика в разработку.

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

Но... Рынок изменился. Уже "у всех все есть"!!! И нужно находить способы, методы, приемы работа на "сытом" рынке.

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


Редактор, Москва

Дискуссия отредактирована и заблокирована. Комментарии оф-топик удалены.

Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
3
Евгений Равич
Конечно. Иначе просто не могло быть. После появления книгопечатания очень многое изменилось. Но ...
Все дискуссии
HR-новости
Cпрос на сотрудников в гостинично-ресторанном бизнесе вырос на 60%

Зарплатные предложения для новых кадров выросли на 23% по сравнению с зимой прошлого года.

«Вкусвилл» запустил роботов для перевозки товаров в распределительных центрах

До конца 2024 года компания планирует роботизировать 30% операций, связанных с перемещением грузов из зоны приемки в зону хранения.

«Яндекс Еда» начала работать в Бишкеке

Киргизия стала шестой страной СНГ, где доступен сервис — после России, Казахстана, Беларуси, Армении и Узбекистана.

Более 40% наемных сотрудников не могут позволить себе больничный на работе

Свыше трети опрошенных отметили, что из-за проблем со здоровьем им отказывали в повышении.