Scrum. Как не споткнуться в погоне за продуктивностью?

Уинстон Черчилль говорил, что «демократия - наихудшая форма правления, если не считать всех остальных». И речь здесь не о том, что это плохой политический строй, просто не существует однозначно совершенных систем, но стремиться к ним - наша обязанность. Демократия лишь задает направление. С работой по Scrum похожая ситуация. В интеграции этой методологии в свои бизнес-процессы определенно есть сложности, но она лучше остальных подходит под определенные задачи.

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

Изначально эта методология разрабатывалась для управления емкими проектами в сфере IT, однако ее принципы помогут повысить эффективность работы команд, занятых и в других областях: услуги, производство, продажи, HR. Scrum будет полезен даже в бытовых делах.

Для РокетБиз Scrum оказался оптимальным вариантом работы, так как наша команда решает бизнес-задачи клиентов комплексно: оптимизирует работу с персоналом, увеличивает эффективность отдела продаж, повышает результативность интернет-маркетинга.

В этом материале директор по персоналу РокетБиз Ксения Лысенко, опираясь на личный опыт, разъяснит, какие бонусы несет работа по Scrum и покажет с чего следует начать.

Чем заманчив Scrum

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

  • Планомерное ведение журнала работ, необходимых для полной готовности разрабатываемого продукта (backlog), позволило исключить выпадение целей при краткосрочном и долгосрочном планировании;
  • Четкие роли в Scrum помогли членам команды, занятым в одном процессе, без споров разграничить полномочия и фронт работ;
  • Ежедневные летучки и еженедельный разбор проделанной работы (разбор спринта) избавили от нехватки времени для обсуждения свежих идей внутри команды;
  • Ежемесячный разбор проделанной работы наглядно показал скрам-команде, что она не топчется на месте - результат виден всем.

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

Первые шаги: от стикеров на стене до удобного онлайн интерфейса

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

Второе - организовать площадку для отслеживания выполнения целей и задач в реальном времени. Вначале мы выбрали самый что ни на есть физический носитель - стену в нашем офисе. Мы разделили ее на отсеки «Сделать», «В работе» и «Готово». Затем добавили раздел «ПОЖАР», куда включали всякие незапланированные задачи, возникающие вследствие какого-то форс-мажора - скажем, из-за блокировки важного онлайн сервиса великим и ужасным Роскомнадзором.

С течением времени мы поняли, что заклеивать стикерами стену вручную - контрпродуктивно, и ушли за решением в интернет. Там мы набрели на замечательный сервис для управления проектами небольших групп - Trello. Он идеально подошел в качестве альтернативы офисной стене.

Следует оговориться, что работа в Trello подойдет не всем. Наш друг из агентства «Аутмаркетинг» Антон Шаяхов в своем материале «Scrum-маркетинг в камерном агентстве: почему нам не понравился Trello и чем мы его заменили» подробно рассказал про альтернативные #инструменты. А их немало: Jira, Wrike, StarTrek, Taiga, Basecamp. У всех есть свои плюсы и минусы. За подробностями - по ссылке выше. Осторожно: присутствует ненормативная лексика из сферы IT.

Оценка и анализ эффективности команды

Всякая работа должна оцениваться. Каждая задача «весит» определенное количество баллов, состоящих из суммы потраченного времени, задействованных членов скрам-команды и их трудозатрат. Например, сложная задача для одного человека может «стоить» существенно больше 1 балла. Для оценки Scrum использует числа Фибоначчи. Это порядок, когда каждое следующее число равно сумме двух предыдущих - 1, 2, 3, 5, 8, 13, 21 и так далее. Придумана такая методика для того, чтобы внутри команды не было споров о трудозатратности задач - проще определить стоимость работы, если выбор стоит между 5 и 8 баллами.

В самом начале сложно точно определить «вес» задачи. Если бы вы меня тогда спросили, во сколько баллов можно оценить, к примеру, задачу по размещению вакансии - я бы точно не ответила сходу. Первое время мы ставили балл навскидку, по ощущениям. И вот спустя примерно три месяца, мы начали понимать, как сложность задачи влияет на ее оценку - задача по размещению вакансий может стоить и 1 балл, и 5. Все зависит от обстоятельств. Дело в том, что в одном случае мы ее выполняем уже зная площадку для размещения и содержание вакансии, а в другом надо промониторить аналогичные вакансии конкурентов, узнать у руководителя искомого сотрудника, какими качествами должен обладать соискатель, сформулировать требования по вакансии и все в этом духе.

Ксения Лысенко

Среди прочего баллы помогут оценить адекватный уровень загрузки команды. К примеру, ваша команда способна за недельный спринт выполнить задач на, скажем, 200 баллов. Это значит, что, если вы в начале недели запланировали работ на 300 баллов, то с большой долей вероятности ваша скрам-команда ничего не успеет, сильно устанет и «перегорит».

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

Век живи - век учись

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

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

0
70 комментариев
Написать комментарий...
Yuri Mediakov

Ну так себе у вас контентный маркетинг. Опоздали со статьей лет на 5 минимум. :)

Ответить
Развернуть ветку
Ярослав Град

Мы тут недавно поняли, что топ10 верхнего списка профессионалов конечно многое знают и применяют, причем давно. Например по скраму в силиконке работают оооочень давно. Но тут какая штука, большинство (оставшиеся 90%) все еще не слышали, а если даже слышали - то не применяют. А если и применяют, то не факт что верно. А бывает, что слышали, но не видят для себя практической пользы. Короче весь смысл всего этого дать еще один взгляд, практический опыт, и показать, что блин этим стоит пользоваться. У нас получилось и дало результат

Ответить
Развернуть ветку
Вася Пражкин

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

Ответить
Развернуть ветку
Ярослав Град

Что вы имеете ввиду?

Ответить
Развернуть ветку
Вася Пражкин

Времена уже не те, многие в скрам и аджайл наигрались еще несколько лет назад, хайп прошел давно, простым словом Scrum уже никого не заинтересуешь. Люди битые стали, опытные, а Вы им еще раз то же самое, под тем же соусом.

Ответить
Развернуть ветку
Yaroslav Grad

Это конечно так, но тут же есть и другая сторона медали. О скраме мы знали давно, но не применяли, и так же считали - все понятно и ничего нового. А потом внедрили и охренели от того, как выросла производительность.
Тут же как в crm. Все знают, а используют не больше 5% бизнесов. Мы работаем с крупным бизнесом и даже там crm не везде. Хотя тема была понятная еще 15 лет назад)

Ответить
Развернуть ветку
Вася Пражкин

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

Ответить
Развернуть ветку
Yaroslav Grad

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

Ответить
Развернуть ветку
67 комментариев
Раскрывать всегда