Управление проектами по Scrum

Удивительная штука инфобиз – достаточно забросить в массы одно слово и из него составят полноценный рассказ, правда без использования этого слова. Так получилось и со scrum. Неосознанно я работаю в scrum с 2009 года. Узнала я, что это такое в 2013 и еще раз убедилась, что работаю я в scrum с 2009 года. Как специалист (консультант) по процессному и проектному управлению, я ставила эксперименты на своих клиентах. Надеюсь, они подозревали, что это эксперименты, а не стопроцентные проверенные практики. В противном случае ведь никому не было бы интересно 🙂 В чем заключались эти самые что ни на есть научные опыты? Мы внедряли принципы scrum в управление проектными командами в непроектных организациях, а также в малых командах классической системы управления. В 70% это было фиаско. Конечно, меня посетил сначала отчаянный вопрос, а потом азартно-экспериментаторский «что мне делать дальше – внедрять или не внедрять, вот в чем вопрос?». Можно было бы бросить эту затею и переключиться на другие методологии, благо их пруд пруди сегодня. Но я отчаянно пыталась найти ответ таким странным на первый взгляд результатам.
 
И вот, 2014 год дарит нам волшебную книгу Фредерика Лалу. И один большой ответ на все заданные и не заданные вопросы: «Господа, а вы вообще готовы к тому, что применять гибкие подходы? Вы вообще agile-валидны? Ваши ценности отвечают принципам гибкости в управлении?» А буквально месяца полтора назад я знакомлюсь с Максимом Цепковым и его докладом на тему ценностной теории.
 
Давайте сейчас, прежде чем мы начнем говорить о scrum как о возможностях, проверим уровень своей готовности к этому. Задайте себе вопросы и мысленно честно ответьте на них: Что для вас важнее? (для вас или вашей организации):

Процессы или люди?

Технологии или коммуникации?

Реальный работающий результат или правильно заполненные бумажки?

Выполнение пунктов контракта или сотрудничество с заказчиком?

Гибкость в принятии решения или следование первоначальному плану?

Запомните свои ответы. Они расскажут Вам о том, какие ценности управляют вами или вашей компании.
 
Что есть ценности? Это то, что движет нами при принятии решения. Если на один из вопросов вы ответили «процессы» или «бумажки» — это ваши ценности. И они прекрасны. Они идеальны для процессного управления и регламентированных бп. Однако ничего общего не имеют со scrum. К чему я веду – сколько не изучайте принципы agile, если гибкие ценности идут в разрез с вашими – вы попадете в 70% моих фиаско.

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

Итак. Семь уровней.

Уровень физических рефлексов. Тот уровень, на котором каждый индивид действует самостоятельно, на чужих и опасных территориях и пытается всячески выжить. Это не организационный уровень, поэтому даже не примеряйте на себя. Вряд ли вы к нему относитесь.

Уровень принадлежности. В ответ первому – когда несколько индивидуумов собрались вместе, но пока нет лидера и не допускается идея о том, что кто-то может кем-то управлять и что это вообще возможно. На этот уровень я тоже никого из вас не посажу.

А вот начиная с революционного начинайте фантазировать. К слову, цвета и наименования уровней в скобочках соответствуют Лалу. Тип организаций, в которых активный и неуемный лидер пытается все под себя подмять. В таких структурах нет места системе управления априори. Это приступные группировки, мафия, управление улиц. Место, где заработанное потом и кровью людей достается одному человеку. В России на этом уровне находятся не только бандиты.

Уровень регламентов и норм. Церковь, армия, ЖКХ. Какой идеальный вариант системы управления? Классический бюрократический. На этом уровне осознанно или нет, но в большинстве своем функционируют предприятия.

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

И вот плавно переходим к уровням, на которых agile-подход не панацея, но пища – уровень общности. Здесь, я надеюсь, Вы узнаете и себя, и свои команды. Часто уровень ИТ и медиа, нестроительных проектов. На сегодня это максимально известный левел организаций. Следующим предполагают господа ученые философы будет именно тот самый пресловутый бирюзовый. Духовный, как можно его еще назвать. Уровень, на котором не просто будет отрицаться иерархия и менеджмент как таковой (что мы можем наблюдать на зеленом предыдущем), но и вся деятельность компании будет направлена на улучшение мира и принесение пользы.

Для Agile есть два уровня развития. Один из них еще даже не появился.
Поэтому прежде чем приступать к внедрению scrum в управление в рамках вашего проекта или компании, или становиться пропагандистом как я – определите, насколько и вы и ваша команда и ваше руководство готово к этому.
Scrum появился как всегда случайно. В 1986 году была опубликована статья в Harvard Business Review, кто-то из японских манагеров кратко изложил ценностную суть данного фреймворка как набор принципов самоорганизующейся команды, который успешно использовался в Canon, Honda, Fuji-Xerox. И только в 1993 году Джеф Сазерленд изложил и назвал Scrum в виде рабочей методологии для разработки ПО. Что такое Scrum? Схватка в регби. То есть принцип не эстафеты, а командной работы.
 
Да, у Scrum есть ощутимые преимущества по сравнению с другими методологиями управления. По сути он-то и методологией не является, а всего лишь фреймворком, однако это больше потянет на кухонные философские беседы. Посему пока будем именовать его так, как вложили в наши умы.
Вернемся к преимуществам. Сейчас пройдемся по ним как по тезисам, а в конце вернемся к ним еще раз уже проанализировав полученную информацию и убедившись в истинности этих преимуществ.
— Scrum – это удовлетворенные заказчики
— Scrum – это повышенная окупаемость инвестиций
— Scrum – это уменьшение расходов
— Scrum – это быстрые результаты
— Scrum – это удовлетворенность и полная нирвана
 
Принципы Agile зафиксированы и прописаны в Agile Magnifesto, манифест, который был подписан представителями и носителями agile-ценностей (Scrum, xp, kanban, lean). В 2004 году совершенно случайно собрались ребята на лыжном курорте и, горячо обсуждая новые методики и инструменты, составили и подписали вот такой емкий и единственный нормативный agile документ:
— люди и взаимодействия важнее процессов и инструментов
— работающий продукт важнее исчерпывающей документации
— сотрудничество с заказчиком важнее согласования условий контракта
— готовность к изменениям важнее следованию первоначальному плану
 
Помните, мы в самом начале попытались определить свой набор ценностей по ответам на вопросы? Эти вопросы не были списаны с манифеста, а всего лишь представляют собой ценностные маркеры, однако сравнивая их мы видим определенную тождественную связь. Из чего мы в очередной раз делаем вывод, что Scrum – это набор ценностей.

Нормы практики Scrum – это вам не жесткая организационная структура и регламентированные бизнес-процессы. Это: РОЛИ, ВИДЫ ДЕЯТЕЛЬНОСТИ и АРТЕФАКТЫ

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

Упорядочение задела продукта – задел – планирование спринта – задел спринта – выполнение спринта – подведение итогов – ретроспектива. Процесс разбавляется ежедневными летучками и анализом прироста готового к поставке продукта.

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

— дедлайн

— расстановка приоритетов

— демонстрация прогресса

— исключение перфекционизма

— стимулирование завершения

— предсказуемость

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

Кто такой? Мы определили, что это единственное уполномоченное лицо по части решения вопросов, связанных с желаемым видом продукта, а также является неким связующим звеном между всеми участниками проекта и разработчиками. Чем должен обладать специалист для реализации успешной функции Владельца продукта:
— знание предметной области: он же тот, кто принимает решение о продукте, поэтому область рабочую он знать должен хорошо, плюс его опыт убережет его от перфекционизма и будет напоминать, что не все можно предусмотреть, и наоборот – подскажет, что можно ожидать в будущем – какие изменения, форсмажоры или просто дальнейшее развитие событий.
— навыки работы с людьми: без этого навыка в agile в принципе нечего делать. Но для Владельца это один из ключевых навыков. Ему необходимо быть не только открытым и общительным, но и владеть навыками переговоров, инструментами решения конфликтных ситуаций и знать на практике, как мотивировать людей к действиям.
— принятие решений: вот он, тот самый навык, который отличает функционал Владельца от коллег по цеху. Аналитический склад ума, финансовые знаний, хорошо бы понимать как просчитывается финансовая эффективность деятельности и рентабельность продукта, в конце концов готовность и решимость принимать важные решения о продолжении разработки или ее прекращении, модификации продукта и видоизменения первоначального плана.
 
Со Scrum Мастером все проще. Проще в плане специализированных навыков и знаний, но сложнее с теми soft skills, которые не приобретаются. Мастер некий наставник. Духовное лицо, если хотите. Тот, кто держит весь энергетический уровень и не дает ему упасть. Человек-клей команды. Что у него есть?
– он наставник, коуч. Он помогает раскрыть потенциал каждого члена команды для достижения синергии и повышения эффективности работы команды в целом.
— он лидер. Лидер не тот, кто всегда прав, а тот, кто управляет настроением в коллективе и мотивирует/вдохновляет специалистов. Это Мастер.
— он берет на себя ответственность. Он осознает, что все, что происходит в команде и в процессе – все на его плечах.
— он защищает каждый спринт от вмешательства в цели со стороны участников проекта. Помните/знаете, есть принцип в Scrum – никаких изменений в цели спринта быть не может, пока спринт не будет завершен.
— он инициатор изменений и устранитель препятствий – летучки, итоги, ретро – ничто не утекает из-под зоркого взгляда Мастера, который не только улавливает любые нюансы в команде и процессе, но и складывает это все в общую картину – план действий. Наладить, отладить и сделать так, чтобы в итоге всем было хорошо.
 
Для того, чтобы и Мастер и Владелец смогли выполнить свои основные обязанности и применить все свои навыки, нужна соответствующая команда. И это самое важное. Нам нужны не только офигенные спецы, но и те, кто будет разделять с нами ценности Agile и принципы Scrum.
— итак, во-первых, команда должна быть самоорганизованной, не ждать указаний и задач, эскалированных сверху
— межфункциональная неоднородность, для того, чтобы команда обладала широким спектром ЗУНов (знаний, умений, навыков). И здесь же отметим, что ЗУНы должны быть Т-образными – это значит и вширь, и в глубину
— внутренние отношения отлажены на 200% — это и отношения между ленами команды, и пропускная способность передачи информации, доверие, открытость. Этому способствует долговечность команды – чем дольше она работает вместе, тем выше все необходимые характеристики
— физические характеристики команды также важны, поскольку Scrum подразумевает работу в достаточно жестком темпе. Каждый член команды должен быть к этому готов и вынослив
— оптимальность штата – момент, который упускается. С непривычки. В команде не может быть «недогруженных» или «перегруженных» спецов. Так же как и не может быть лишних или незаменимых. По сути задача Мастера – сформировать и смотивировать таким образом, чтобы состав проектной команды был оптимальным. Кстати, по ЗУНам классно работает инструмент Карта звездного неба. Не буду сейчас на ней останавливаться, но кто не знает – отметьте, что просто необходимо о ней узнать.
 
О многом хочется рассказать и остановиться на каждом пункте подробно да с практическими заданиями. Ан нет. Выделим только самое важное. И для меня важным являются принципы планирования в Scrum. Думаю, что принципы эти после знакомства с манифестом и особенностями команды и спринта, не станут удивительным явлением. Все логично:
— предусмотреть все невозможно, никакие планы невозможно составить заранее
— предварительное планирование в первую очередь должно быть полезным, но не фанатичным – фанатичность, которая в классическом процессном планировании и жестком проектном приносит больше вреда и влечет за собой колоссальные расходы, а в итоге и убытки
— акцент на адаптации плана и перепланировании, а не на стопроцентном следовании первоначальному плану – мысленно обращаемся к манифесту
— готовность к резкой смене стратегии при необходимости – развивать понимание того, что все может пойти не по плану, да и так, что придется кардинально менять цели. Никакие изменения не являются негативными, как и причины. В данном случае нет места оценки. Это просто гибкость.
 
А теперь соберем всю картину в единое целое:
У Владельца продукта появляется мысль и образ продукта – команда формирует задел продукта и упорядочивает его – далее происходит планирование спринта, формирование его задела, выполнение – все это щедро сдабривается ежедневными летучками, а завершается подведением итогов и ретроспективы.
 
Преимущества выглядят уже более разумно и аргументированно:
— довольный заказчик от того довольный, что видит прогресс и дает обратную связь так часто, как того требует продукт
— окупаемость продуктов обусловлена тем, что каждый спринт приносит в рынок готовый продукт, который уже может идти в использование
— расходы уменьшаются благодаря гибкости и принципам планирования
— быстрые результаты благодаря команде и Мастеру
— уверенность и удовлетворенность касается всех участников проекта – Scrum помогает делать хорошие вещи хорошо, быстро, а от плохих во время отказываться
 
Я бы рассказывала еще очень долго 🙂 Пусть нас, сеятелей scrum, становится все больше и больше 😉

***************

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2024 DEVELOPER. Больше статей можно прочитать здесь.

В 2024 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2024 в Москве.

Выбрать мероприятие.