В этой статье мы расскажем об изменениях нашего подхода к управлению проектами в связи с увеличением степени неопределенности и изменчивости внешних факторов в современных условиях. Для начала рассмотрим, как выглядит классическая модель управления.
Классическая модель управления проектами
В классической модели управления проект делился на несколько этапов. На каждом этапе требуются специалисты для выполнение определенных действий. Например, бизнес-аналитики изучают бизнес-процессы заказчика на этапе обследования, а на этапе моделирования в разработке участвуют программисты.
Освобождающиеся специалисты переключаются на другой проект, но на следующих этапах могут возвращаться. К примеру, после завершения первых этапов бизнес-аналитик может быть задействован на других проектах, пока идет разработка, и к моменту обучения вернуться.
В результате между руководителями проектов происходит борьба за ресурсы. Специалистам приходится постоянно переключаться между проектами, что приводит к увеличению затрат. Кроме того, возникает необходимость максимального документирования всех шагов.
В среднем проект длится не менее года. На старте важно собрать и зафиксировать максимальное количество требований.
Критерии успешности проекта следующие:
-
срок,
-
бюджет,
-
функциональность.
Они образуют треугольник управления проектами.
Успешным считается проект, когда стартовые требования были выполнены ровно в срок и не превысив бюджет. Любые изменения считаются негативным фактором, который подрывает как минимум один из критериев успешности.
Эволюция проектного подхода
Пандемия и увеличение степени неопределенности внешних факторов создали новую хаотичную и изменчивую бизнес-среду, которую можно охарактеризовать термином VUCA. Он расшифровывается как:
-
V — volatility, нестабильность.
-
U — uncertainty, неопределенность.
-
C — complexity, сложность.
-
A — ambiguity, неоднозначность.
Термин характеризует изменчивую и сложную среду современного мира, где не существует гарантированной стабильности. VUCA-мир – это наша реальность: нужно быть гибким, готовым отбросить прошлые убеждения, принять изменения и подстроиться под них.
Матрица Стейси — инструмент для выбора оптимального решения с учетом степени определенности:
-
Красный – принципиально рискованные решения
-
Синий – хорошо работают адаптивные методы
-
Серый – хорошо работает линейный подход
С другой стороны, согласно Матрице Стейси, ERP проекты во многом требуют классического подхода, особенно в части регламентированного учета и финансов. Здесь уровень неопределённости минимален, а требования жестко регламентированы.
Поэтому мы всегда находимся в балансе между проектным и продуктовым подходом. Ниже в таблице представлены основные отличия между ними.
В целом, проектный подход — это про фиксированные бюджет, сроки и функциональность, которые определяются на старте. Команда состоит из специалистов разных квалификаций, изменения не приветствуются, а результат Заказчик получает в конце проекта.
Продуктовый подход отличает гибкость в принятии решения. Бюджет, сроки и функциональность могут изменяться на протяжении проекта. Работа ведётся итерационно, и в конце каждой итерации Заказчик получает рабочее решение. Команды кросс-функциональны.
Гибкое управление проектами в группе компаний "СофтБаланс"
В проектах мы используем гибкие методологии, но от классического подхода полностью не уходим.
Одна из методологий, которой мы используем, основана на манифесте Agile. Этот документ содержит описание ценностей и принципов гибкой разработки. Ценности методологии Agile сформулированы в четырех строках:
- Люди и взаимодействия важнее процессов и инструментов
-
Работающий продукт важнее исчерпывающей документации
-
Сотрудничество с заказчиком важнее согласования условий контракта
-
Готовность к изменениям важнее следования первоначальному плану
Объединяет их идея: "не отрицая важности того, что справа, всё-таки нужно больше ценить то, что слева".
«Agile software development» (в переводе "Гибкая методология разработки") — это подходы на основе манифеста Agile, или фреймворки. Самыми яркими являются скрам (Scrum) и канбан (Kanban).
Скрам — это подход, который помогает командам вести совместную работу. Согласно этой методике, команда должна извлекать уроки из полученного опыта, осваивать принципы самоорганизации, анализировать свои успехи и провалы и постоянно совершенствоваться.
Канбан — подход, реализующий принцип «точно в срок». Он способствует равномерному распределению нагрузки между специалистами: по мере поступления задачи заносятся в список, и каждый специалист может выбрать нужную, создавая непрерывный поток задач.
В нашей компании для работы лучше всего подошел скрам, но с оговорками.
В скраме выделяют три группы элементов:
-
Артефакты,
-
Активности,
-
Роли.
Артефакты в скрам
Бэклог – это общий список задач. Бэклог может быть по всему проекту или по одному спринту — отрезку времени, длительность которого определяется командой в начале проекта. В течение проекта длительность обычно не меняется, позволяя команде выработать удобный для неё рабочий темп.
В наших проектах, если в бэклоге спринта заканчиваются задачи, то мы берём следующие из общего списка, не дожидаясь окончания спринта. Эта практика не характерна для скрама, но является обязательной в непрерывном процессе поставки по методологии канбан.
Инкремент воплощает реализацию задач бэклога. Каждый спринт должен включать минимум один инкремент, чтобы считаться завершенным успешно. Например, это может быть отчет, или печатная форма, или всё вместе.
Роли в скрам
В первую очередь, команда разработки — кросс-функциональная команда, ответственная за создание продукта. Внутри нет иерархии.
Кросс-функциональные команды характеризуют динамичный рынок труда: специалисты мигрируют как между командами внутри одной компании, так и между заказчиком и исполнителем. При этом важно не потерять информацию и знания при уходе специалиста.
Кросс-функциональные команды состоят из так называемых T-shaped специалистов – людей, которые являются экспертами как минимум в одной области и разбираются в других на базовом уровне. T-shaped специалисты взаимодействуют более эффективно, чем люди с узкой специализацией, потому что лучше понимают влияние своей работы на другие нюансы. Таким образом, на проекте можно сохранить стабильную команду.
Скрам-мастер выстраивает коммуникации и следит за процессом. В нашей компании роль скрам-мастера обычно берёт на себя руководитель проекта.
Владелец продукта – человек, который точно знает, что нужно сделать. Он несёт ответственность за поддержание бэклога в актуальном состоянии. Обычно это руководитель проекта со стороны заказчика.
Роль, важная во всех проектах, вне зависимости от методологии – это стейкхолдеры или заинтересованные лица — их проект как-то затрагивает, или они могут как-то повлиять. Роль стейкхолдеров часто недооценивают.
Наглядный пример: на тренинге нам нужно было реализовать проект — построить дом, используя детали ЛЕГО и методологию скрам.
Несколько часовых спринтов мы собирали определённые элементы, согласно имеющимся у нас требованиям. Когда почти всё было готово, мы обнаружили рядом с рабочим столом игрушку, которой раньше не было. Тренер объяснил, что это стейкхолдер со своими требованиями к проекту. Одно из них — изменить цвет деталей дома, который мы строили. Реализовать его за оставшиеся 5 минут было невозможно.
Тренинг показал, как важно на протяжении проекта искать стейкхолдеров и учитывать их требования, чтобы к концу проекта не оказаться в такой катастрофичной ситуации. Конечно, непросто найти всех стейкхолдеров, особенно если они никак не проявляются. Хорошей практикой является запись демонстрации результатов одного или нескольких спринтов. Ее можно разослать как у себя в компании, так и передать заказчику.
Активности в скрам
Активности являются важной частью жизни команды. На схеме представлена схема работы по методологии скрам.
В начале спринта проходят две главные встречи: рефайнмент и планирование.
Рефайнмент – это встреча, на которой команда обсуждает бэклог продукта, ставит задачи и расставляет приоритеты. В нашей практике практике, команда выполняет все действия в течении спринта, а встреча по рефайнменту совмещена с планированием спринта, где команда определяет наиболее важные задачи.
Внутри спринта проходит стендап – ежедневная встреча, где каждый участник команды отвечает на три простых вопроса:
-
что он сделал вчера;
-
что он будет делать сегодня;
-
есть ли какие-то сложности, тормозящие его работу.
Встреча длится не более 5-15 минут, в зависимости от размера команды. Если она затягивается, то нужно прервать дискуссии, но обязательно назначить дополнительную встречу, чтобы обсудить волнующую тему.
К концу спринта проводится демо. Здесь команда показывает результаты работы заказчику и заинтересованным лицам.
Завершающей встречей является ретроспектива или ретро. В идеале ретро проводится в конце каждого спринта. Цель — обсудить сложности, чтобы добиться оптимизации деятельности и комфорта в работе. Результатом ретроспективы становится список улучшений, к которым команда стремится в следующем спринте. Чтобы не было скучно на каждом ретро следует менять фокус, способ проведения или место. Например, хороший вариант провести ретро вне офиса: в кафе или в парке.
В команде мы чаще проводим ретро удалённо, используя Миро. Ниже представлен скриншот одной из наших встреч.
Первое, что нужно сделать — создать атмосферу и «включить» всех участников в работу. Для этого мы использовали статусы с картинками, чтобы рассказать друг другу о своих эмоциях. Если на старте у всех плохое настроение и не получается включиться — встречу лучше либо перенести, либо изменить фокус, иначе это потерянное время.
Далее нужно собрать данные о прошедшем спринте: проговорить цель спринта, вспомнить, что было хорошего и плохого, обсудить скорость решения задач.
После этого переходим к генерации идей: пишем на стикерах, что поможет стать лучше, быстрее и эффективнее, и переходим к выбору конкретных решений. В тот раз мы проголосовали точками за самые удачные идеи, зафиксировали ответственных и сроки реализации.
Последний шаг – закрытие. Мы ещё раз проговорили план дальнейших действий. Альтернативой могут быть слова благодарности друг другу.
Помимо основных активностей на проекте происходят и другие встречи. Одной из них является оценка задач.
Существует несколько принципов, которых принято придерживаться при оценке:
-
Высокая скорость оценки. Сама по себе оценка не несет бизнес-ценности, поэтому логично сделать ее с наименьшими трудозатратами, дешевле и оперативнее.
-
Командная работа позволяет каждому члену команды высказывать своё мнение по сложности задачи. Командная оценка даёт возможность посмотреть на задачу с разных сторон и воспользоваться опытом всей команды.
-
Относительные единицы измерения, которые могут быть выражены в баллах.
Наиболее популярный метод оценки – это покерное планирование. Его преимущество — интерактивность техники и способность сплотить команду. Все, кто участвовал в оценке ощущают личную ответственность за результат и сроки его получения.
Как проходит покерное планирование? Нужно подготовить набор карт с бальными оценками и раздать участникам. Ведущий озвучивает задачу и проясняет все возможные вопросы с командой. Каждый участник дает свою оценку и выкладывает её в закрытую, чтобы другие участники ориентировались только на своё мнение при оценке. Когда все оценки будут на столе, карты вскрываются, и команда обсуждает результаты. Если оценки сильно отличаются, то команда после обсуждения приступает к повторной оценке задачи, пока все участники не согласятся.
Цель покерного планирования — не установить срок выполнения задачи, а убедиться, что все участники процесса понимают задачу и алгоритм ее выполнения одинаково правильно.
Инструменты для организации работы команды
В первую очередь, это таск-трекер. Мы фиксируем все задачи по проекту в RedMine, формируя Бэклог продукта.
Задачам присваивается соответствующий номер спринта, назначается ответственный, сроки и указывается плановая оценка временных затрат. Команда в течение спринта меняет статусы и ответственных, переводя задачи в работу, на тестирование и в завершенные.
Если в процессе тестирования или разработки появляются новые требования или ошибки, то они оформляются новыми задачами. На статус-встрече команда решает, добавить их в текущий спринт или оставить в бэклоге до следующего планирования.
Задачи текущего спринта по всем проектам выведены из RedMine на Канбан-доску. Наша доска разделена 5 столбцов:
-
План (бэклог спринта),
-
В работе,
-
Тестирование,
-
Готово,
-
Принято Заказчиком.
При изменении статуса в RedMine задачи автоматически меняют колонку на доске.
Кроме статусных колонок, на доске есть график сгорания задач — диаграмма, показывающая количество сделанной и оставшейся работы.
Синяя линяя – это план, красная – факт. На фотографии красная линия выше плановой – значит, мы отстаём в решении задач и есть риск, что мы не успеем сделать все запланированные задачи к концу спринта. Зная эту информацию, мы точно не будем брать новые задачи в этот спринт, а на стендапе обсудим с командой, какие есть тормозящие факторы и что мы можем сделать, чтобы ускорить темп работы.
Ранее в статье была иллюстрация ретро с командой в Miro — это еще один инструмент, который мы используем. Он удобен для совместной работы команды.
Резюме
В начале этой статьи мы противопоставляли проектный и продуктовый подходы. Но на самом деле они сочетаются вместе, и нам удаётся гармонично их комбинировать.
Главное в работе сегодня — сохранение гибкости, ситуативности и возможности максимально быстро откликаться на сигналы, поступающие от рынка. Именно поэтому несмотря на всю многофакторность работы на IT-проектах мы продолжаем гарантировать результаты, а благодаря гибким методология доставляем их быстро и регулярно.