Методологии управления проектами - ищем решение на стыке p3.express, agile, scrum
Всем привет, на связи Марат Абиталиев, менеджер проектов в ВебРайз. Давно, когда я только начал погружаться в тему, мне казалось, что есть какая-то идеальная методология, которая решит за меня все проблемы в управлении проектом и расскажет, что мне нужно делать. Отчасти это и правда так, но я достаточно быстро понял, что слепое следование шагам и ритуалам не приведет к желаемому результату, а лишь помешает проекту и команде.
Одной из первой мной изученных методологий в данной теме оказался p3.express. Для читателей немного познакомлю с методологией - по сути это урезанный pmbook, но его более минималистичная версия с 37 шагами.
Познакомился с этим инструментом по рекомендации руководителя, который так же, видимо недавно узнал о p3.express. В плане применения, очень наглядно, мы с ним пошли по разным путям.
Я взял лишь общий план и те шаги, которые я сам считал ценными, обсудив каждый шаг с командой. Хотелось именно создать ситуацию, когда процессы создаются для команды, а не для процессов.
Например, мы:
- Внедрили практику ежедневных действий в середине дня —так команда не только чувствовала актуальность задачи и обсуждала текущие проблемы реализации, но и могла эффективно подготовиться к выступлению.
- Использовали двухнедельные спринты — это было уместнее, чем использовать недельный спринт, как предлагает p3.express, так как задачи за неделю просто не успевали закрываться.
- По итогам каждого спринта фиксировали результаты, и я отдельно отмечал успехи в реализации задач. Очень важно, в том числе, показывать команде, что их работа оценивается, это напрямую влияет на мораль и проактивность сотрудника.
Мой же руководитель подошел к вопросу с точностью до наоборот. Он проводил все ритуалы и шаги, предписанные методологией, ввел дополнительную бюрократию, за которой, по сути, не было реальной ценности для проекта.
Результат говорит сам за себя: мой проект был успешно завершен, и я получил положительную обратную связь, в то время как проект моего коллеги утопал в бумажной работе с демотивированной командой, так как большая часть времени уходила не на создание продукта, а на обслуживание команды.
Почему не Agile?
На мой взгляд Agile это не методология, а все-таки философия, культура и мышление. По сути, это принципы и система ценностей, по которым мы работаем в компании.
- Agile не задает конкретные шаги как, например, P3Express;
- Философия Agile задает принципы адаптивности к изменениям, а методология диктует определенный порядок, задающий конкретные шаги.
Тогда что такое Scrum, Kanban?
Scrum - это методология для создания продукта, которая подразумевает под собой декомпозицию задач на короткие и фиксированные итерации (спринты).
В своей практике, я бы выделил интересный случай в заказной разработке, когда я объединял несколько ритуалов и решал несколько целей одновременно. Я проводил планирование спринта, обзор спринта и ретроспективу вместе с заказчиком – таким образом я решал несколько задач: делал нашу работу полностью прозрачной, обсуждал с заказчиком текущие задачи и проблемы, добавлял важные задачи для заказчика в спринт, расставлял приоритетность лучшим образом.
Вовлечение заказчика так же способствует взаимопониманию и осознание для команды «зачем они разрабатывают продукт», что является не совсем очевидной мыслью, но когда разработчик имеет полное представление - он становится партнером в создании ценности.
Без понимания ценности:
Разработчик: «В ТЗ сказано сделать кнопку зеленой. Я сделал»
С пониманием ценности:
Разработчик: «Я знаю, что это кнопка является призывом к действию. Значит необходимо добавить aria-label для доступности людям с ограниченными возможностями, что соответствует целям нашего продукта»
Данная практика отлично вписывается в методологию Scrum, команда не просто следует техническому заданию и инструкциям, но еще и сама генерирует идеи и находит лучшие реализации для достижения целей, то есть самоорганизуется.
Kanban — по своей сути это один из методов управления workflow, который базируется на принципах визуализации. Неплохим его преимуществом является поэтапное, а значит менее болезненное, внедрение в работу проекта, а также отличное сочетание с Scrum.
Иногда в динамичных и нагруженных проектах, где, например создаются 50-100 задач в месяц, просто становится необходимым визуализировать работы, чтобы иметь полноценное представление о ходе работ. Помогает, в том числе, концентрироваться на закрытии задач, выявлять проблемные места в создании продукта. Но главное - этот метод помогает при планировании спринтов, анализировать метрики, которые помогают прогнозировать завершение задач, дополнительно показывая производительность команд.
Какие можно сделать выводы?
Идеальной методологии или инструмента не существует. Успех проекта всегда складывается из осмысленного применения инструмента, адаптированного под конкретные задачи, команду и контекст. Процессы должны служить команде, а не превращаться в карго-культ.
Возможно, мои рассуждения не являются чем-то новым, но я считаю, что стоит напоминать себе и другим об этой простой, но главной истине в нашей работе.
По вопросам, телеграм @webrise1