Коллеги, всем привет!
В сегодняшней статье хотелось бы поговорить о том, каким образом методы "классического" управления проектами могут быть полезны при реализации крупных задач в scrum командах.
Идея написания статьи появилась после завершения нескольких крупных проектов и задач, когда по итогам финальных ретроспектив мы поняли, что многих ошибок мы могли бы избежать, вспомнив про классический подход. Соответственно в этой статье я и моя коллега Лена Коварская попытались собрать все то, о чем нам стоило подумать раньше, и, возможно, эти мысли помогут кому-то еще.
Сразу оговорюсь:
Цель статьи - показать, какие именно методы и идеи из классического управления проектами могут быть полезны при работе по scrum над крупными задачами и почему.
В статье мы не будем давать пошаговую инструкцию о том, как именно надо интегрировать scrum и классический подход, т.к. это все-таки зависит от конкретной ситуации (мы можем рассказать только про свой опыт в конкретной ситуации).
Если у вас зрелые команды, вы внимательно читали scrum guide и понимаете все, что написано между строк, а также уже давно адаптировали SAFe или LeSS, и запустили не один крупный проект/продукт, то, возможно, часть мыслей в этой статье будет для вас из серии «как мы изобрели велосипед» и «давайте делать хорошо и не делать плохо». Если нет – будем рады.
Для начала небольшое «лирическое отступление».
На практике часто бывает так, что когда организация или команда начинает работать по scrum, то идеи классического проектного менеджмента воспринимаются как пережитки старого "водопадного" мира, наполненного стонами страдающих разработчиков и заказчиков. Поэтому слова «план», «управление рисками» , «управление stakeholder-ами» и т.п. может быть опасно произносить в слух, если не хочешь, чтоб новообращенные последователи agile практик не сожгли тебя как злостного еретика на костре из PMBoK-ов:) шучу, но в каждой шутке только доля шутки.
Самое интересное в этом «холиваре» то, что классический проектный менеджмент вообще не противоречит agile-у – он просто определяет темы и вопросы, о которых надо подумать и всегда помнить, если хочешь успешно завершить работу над большой задачей с четкими целями и определенными сроками. И результатом этого "думания" вполне может стать то, что разработку будет решено вести по scrum. Просто после этого надо будет предусмотреть, как отслеживать прогресс, управлять scope-ом, контролировать качество и т.д. и т.п.
При этом часть ответов уже содержится в scrum-guide в явном виде, а ответы на остальные вопросы предлагается искать путем инспекции результатов работ и постоянным внедрением улучшений по итогам инспекций, т.е. просто получая опыт, «набивая шишки» и делая уроки из своих ошибок.
Собственно ниже хотим показать области знаний из классического подхода к управлению проектами и содержащиеся в них идеи, которые могут помочь сократить количество набитых шишек.
Управление ресурсами
Scrum guide и принципы Agile-манифеста говорят о том, что у нас уже есть Scrum team из мотивированных профессионалов, которая откуда-то появилась и готова к работе.
Если у вас такая команда уже есть – ок, вам об этом думать тоже не надо. Если такой команды у вас нет, то тут как раз и может помочь классический подход. В частности он говорит о том, что вам заранее надо подумать и составить план* следующих действий:
Где, кем и как будет набираться команда проекта.
На какой срок выделяется команда проекта.
Как вы будете обучать и мотивировать команду.
Как вы будете решать проблему возможной «текучки» кадров и потери знаний.
-
Как вы обеспечите нормальные взаимоотношения между людьми в рабочих командах.
И т.д. и т.п.
Если подумать об этом заранее, а не по итогам ретроспективы через N спринтов после начала работы, то можно избежать некоторых серьезных проблем.
*Примечание. Здесь и далее «план» - это не обязательно формальный документ на 100500 страниц с жестко заданной структурой. Это в первую очередь сформулированные мысли и идеи о том, как вы будете поступать в определенных ситуациях для решения определенных задач, а как именно эти мысли оформлять – уже решает каждый сам для себя.
Управление рисками
На моей практике, чаще всего именно в ответ на предложение подумать и оценить риски можно услышать «у нас не водопад/не PMBoK» и т.п.:) Но риски есть всегда независимо от подхода к разработке. При этом риски могут быть связаны не только с самим процессом поставки ценности, но и с окружением проекта, инфраструктурой, заказчиками, stakeholder-ами и т.п.
Scrum guide говорит, что если у вас прозрачный процесс поставки ценности и вы проводите его регулярную инспекцию и адаптацию, то, заметив какую-то проблему, вы сможете найти решение и немедленно его внедрить.
Классический подход говорит о том, нет смысла ждать наступления риска, когда можно заранее подумать о следующем:
Составить список всех возможных рисков проекта.
Для каждого риска оценить его вероятность и влияние, на основании которых сформировать план дальнейших действий.
Определить риск-триггеры и как часто вы будете отслеживать наступление этих триггеров.
Как часто вы будете обновлять реестр рисков и план действий.
И ведь scrum-у это не противоречит. И когда вы об этом подумаете, у вас по сути уже будет план управления рисками.
Управление stakeholder-ами
Scrum guide отталкивается о того, что stakeholder-ы уже известны команде, и команда с ними взаимодействует. При этом в жизни на вопрос «а от куда мы про stakeholder-ов узнаем» ответ будет из серии «ну Product owner как-то узнает»:)
Область знаний про управление заинтересованными лицами может помочь Product owner-у и команде тем, что заранее подтолкнет найти ответ на следующие вопросы:
Кто является ключевыми stakeholder-ами.
Как их выявлять и как с ними взаимодействовать.
Оценить влияние и вовлеченность stakeholder-ов.
Оценить, какая информация, кому и зачем может быть нужна. Подумать, как эффективнее взаимодействовать с каждым stakeholder-ом, чтоб от этого была максимальная польза для проекта.
Это особенно важно. ведь формат взаимодействия со стейкхолдерами напрямую влияет на результат проделанной работы.
Управление scope-ом
Scrum guide рассказывает о том, кто управляет backlog-ом спринта и backlog-ом продукта. При этом формирование backlog-а остается в ведении Product owner-а, который отвечает за то, чтоб каждый элемент backlog-а был понятен команде и приносил ценность.
Классический подход может помочь тем, что заранее будут продуманы следующие вопросы:
Каких целей мы хотим достигнуть, реализовав проект.
Как будем выявлять потребности заказчика и оценивать целесообразность их реализации.
По каким принципам мы сможем определить границы проекта – что несет ценность, а что нет, что должно войти в MVP, а что нет, и т.п.
Из каких этапов будет состоять проект.
Какие инструменты мы будем использовать для описания требований, какая степень подробности их описания нам нужна, чтоб соблюсти баланс между скоростью и качеством.
Ответы на эти и подобные вопросы могут помочь при определении границ проекта и постановке Product goal-а и разбивки его реализации на этапы.
Управление изменениями
Самая интересная и потенциально «холиварная» часть Scrum guide говорит о том, что команды должны уметь гибко подстраиваться под изменения, и в целом команда должна делать только то, что приносит ценность и служит целям спринта. И дальше есть много статей на тему, как поставить хорошие цели на спринт.
Если у вас работа по time and material, возможно, у вас и не будет никаких проблем – приходит заказчик, говорит, что для него важно в следующем спринте, команда это реализует, и все довольны.
Если у вас ограниченные сроки и стоят вполне конкретные задачи, вы можете столкнуться с ситуацией, когда реализация всех пожеланий заказчика будет невозможна из-за ограничений по времени и ресурсам.
Классический подход предлагает подумать о следующем:
Кто может вносить изменения в scope.
Как мы контролируем, что соблюдаются границы проекта.
Как мы будем оценивать необходимость изменений.
Как мы будем искать ресурсы на реализацию этих изменений.
Кто принимает решения в конфликтных ситуациях.
Все это не противоречит Scrum guide-у, т.к. не запрещает вносить изменения, а просто показывает, что они не должны быть хаотичными. Понятно, что в процессе работы команда наверняка найдет ответы на эти вопросы опытным путем. Просто если подумать о них заранее, возможно, получится избежать части проблем.
Интеграция и коммуникации
Здесь Scrum guide напрямую не дает рекомендаций, т.к. рассматривает работу одной кросс-функциональной команды над одним продуктом. Если команд несколько, то здесь возникают LeSS, SAFe и Nexus. Сложность в том, что начинающие команды не сразу могут «созреть» для эффективного внедрения этих форматов, а комплексные задачи могут появляться еще до достижения зрелости.
Здесь полезным будет ответить для себя на следующие вопросы и сформировать план соответствующих действий:
Определить зоны ответственности – кто из команд и за что отвечает.
Определить, кто имеет право вносить изменение в backlog и цели проекта/задачи.
Определить единые правила работы со scope-ом (backlog-ом продукта) и его оценкой (единые story point-ы, общие мероприятия по оценке и т.п).
Определить, какие работы зависят друг от друга, и постараться минимизировать эти зависимости.
Договориться о том, как участники команд смогут оперативно решать рабочие вопросы.
Вот и все – мы перечислили основные моменты, которые, на наш взгляд, лучше продумать при запуске больших задач/проектов в Scrum команде (командах), чтоб избежать лишних ошибок и потерянного времени. И как уже сказали, считаем, что, все это не противоречит базовым принципам agile и scrum. Надеемся, что статья поможет вам избежать части ошибок, которые в свое время сделали мы:)
P.S. Еще раз большое спасибо Лене Коварской за соавторство.