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'а. Мы скорее хотели подтолкнуть вас к изучению этого инструмента. Если удалось - пишите о своих успехах и неудачах, ведь на ошибках учатся, причем как на своих, так и на чужих.
Итак статья: Scrum. Как не споткнуться в погоне за продуктивностью?
Мы сначала делали таблицу эксель, но это нудно.
Потом лепили стикеры на стенку, но они отваливались и плохо переклеивались.
В инете нашли Трелло и это оказалось норм, вот фото.
Потом мы придумали каждому заданию давать баллы сложности, но сначала было проблемно, так как ITшник Гриша ставил своим задачам стоимость 1, а грузчик Петрович считал что это 10 (и наоборот).
В общем непонятно кто у нас ставит балы (возможно мы все, собираемся и час выясняем сколько баллов стоит та или иная задача. Но это норм, потому как это официальный перерыв в работе), в статье мы не будем этого писать. Просто напишем "оцениваем баллами".
Так, читатели хотят ответ на заголовок "как не споткнуться?", ну не знаем как, напишем просто "у нас не было цели сделать из вас скрам мастера", мы просто написали про переход с экселя и табличек на веб приложение и баллы. Ну и чтобы типа запустить диалог, напишем "а как у вас со скрам?", пишите давайте, комментируйте, заинтересовывайтесь.
Спасибо за внимание, с вами был РокетБиз (вот ссылка).
Я зашел прочитать "Как не споткнуться в погоне за продуктивностью?". Так как не споткнуться?
Для того, чтобы споткнуться или же не споткнуться, надо начать движение. В статье рассказано о том, как его начали мы. А что не так?
Да, сперва надо составить перечень работ для создания готового продукта и адекватно оценить свои силы (баллы, ага). Мы указали на то, каким инструментом пользоваться удобно, а каким - нет (Scrum на стене распространенный вариант). Ну и подсказали, где получить полный объем знаний по предмету.
В дальнейшем мы расскажем об оптимальной численности скрам-команды и об позитивном воздействии Scrum на настроение и, следовательно, продуктивность коллектива. На примере конкретных кейсов расскажем, в каких проектах Scrum работает отлично, а в каких - хотелось бы лучше (и чем заменить).
Словом, лиха беда начало, Сергей)
Прям с языка снял коммент)
Комментарий удалён модератором
Интересная позиция.
С последним тезисом согласны полностью)
Комментарий недоступен
Андрей, с тезисом про счастье я полностью с Вами согласна. А так как многие из нас проводят треть своего времени на работе, я считаю, что работа должна добавлять счастья в жизни ;)
Кстати, в Scrum есть такой показатель "индекс счастья", он как раз отражает эмоциональное состояние команды.