top of page

Проектное управление. Часть 2. гибкие методологии

Обновлено: 30 дек. 2022 г.

В предыдущей части мы разобрали виды проектов по модели Киневин, в зависимости от которых выбирается стиль управления, один из которых - “Водопад”. В этой части мы поговорим о более новых, так называемых “гибких” подходах.

Проектное управление. Часть 1: введение и классические подходы

Проектное управление. Часть 3: управление рисками

Содержание:

Agile

Сейчас Agile разрекламирован, и многими позиционируется чуть ли не как панацея от всего и вся, а точнее, как универсальный ответ на VUCA-мир (мир неопределенности). Так что же такое Agile?

Это подход к реализации проектов с помощью коротких отрезков - “спринтов” - по 1-4 недели и подготовки частей общего продукта - “инкрементов”.

Неопределенность может быть связана:

  • с разрабатываемым продуктом, требованиям к нему

  • с заказчиком/потребителем, с тем, чего же он хочет и что ему надо.

Еще одна отличительная черта Agile, особенно в продуктовом управлении - создание MVP.

MVP — тестовая версия товара, услуги или сервиса с минимальным набором функций, которая несет ценность для конечного потребителя. Подробнее о том что это такое и методах создания MVP по ссылке.

Главная цель этого подхода - протестировать предположение и как можно раньше выявить ошибку. Это нужно для того, чтобы дать клиенту тот продукт, который будет ценен для него и минимизировать стоимость игры в "угадайку".

Agile целесообразен, в основном, для запутанных систем модели Киневин или как элемент гибрида в сложных системах.

Парадокс в том, что agile очень трудно работает с планированием, требователен к системе контроля и уровню команды. При слабом менеджменте это приводит к огромным перерасходам и срывам сроков на проектах.

Поэтому сейчас встречается планирование обратное от классического.

Упорядочивает все главный документ - манифест гибкой разработки программного обеспечения, который выделяет четыре основные ценности:

1. Люди и взаимодействие важнее процессов и инструментов.

Чтобы люди работали эффективнее, процессы и инструменты не должны их ограничивать. В Agile ни процесс, ни тем более инструмент не диктует, что людям делать. Они сами решают, как менять процессы/инструменты своей работы.

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

2. Работающий продукт важнее исчерпывающей документации.

Чтобы клиенты были довольны, им нужен именно работающий продукт. Поэтому разработчики продукта должны фокусироваться именно на том, чтобы продуктом можно было как можно скорее воспользоваться, а не на составлении списков, диаграмм, требований, отчетов перед заказчиком.

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

3. Сотрудничество с заказчиком важнее согласования условий контракта.

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

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

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

4. Готовность к изменениям важнее следования первоначальному плану.

Чтобы не откладывать риски проектов на последние стадии (когда будет уже поздно уменьшать содержание работы, сдвигать срок или усиливать команду), Agile предлагает не только итеративность работы, но и готовность к изменениям на всех стадиях.

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

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

Не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

Философию Agile также можно применять и при работе с персоналом:

Есть и принципы (есть хорошая статья о разнице между ценностями и принципами):

  1. Удовлетворять клиентов, заблаговременно и постоянно поставляя продукт. Клиенты довольны, когда продукт поступает к ним регулярно и через одинаковые промежутки времени.

  2. Изменять требования к конечному продукту в течение всего цикла его разработки.

  3. Поставлять продукт как можно чаще (раз в неделю, в две недели, в месяц). Поддерживать сотрудничество между командой и заказчиком в течение всего цикла разработки.

  4. Поддерживать и мотивировать всех, кто вовлечен в проект. Мотивированная команда намного лучше справляется со своими задачами, нежели команда, члены которой условиями труда недовольны.

  5. Обеспечивать непосредственное взаимодействие между разработчиками (возможность прямого контакта способствует более успешной коммуникации).

  6. Измерять прогресс только посредством рабочего продукта (клиенты должны получать только функциональное и рабочее программное обеспечение).

  7. Поддерживать непрерывный темп работы (команда должна выработать оптимальную и поддерживаемую скорость работы).

  8. Уделять внимание дизайну и техническим деталям (благодаря эффективным навыкам и хорошему дизайну команда проекта получает возможность постоянного совершенствования продукта и работы над его улучшением).

  9. Стараться сделать рабочий процесс максимально простым, а ПО – понятным.

  10. Позволять членам команды самостоятельно принимать решения (если разработчики могут сами принимать решения, самоорганизовываться и общаться с другими членами коллектива, обмениваясь с ними идеями, вероятность создания качественного продукта существенно возрастает).

  11. Постоянно адаптироваться к меняющейся среде (благодаря этому конечный продукт будет более конкурентоспособным).

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

Из принципов появились и признаки Agile-команды:

  • команда в Agile - профессионалы, с высоким уровнем экспертности в своем деле (программирование, услуги, производство и т.п.);

  • нет руководителей и старших (п.11 принципов), это полностью плоская команда. Нет даже неформальной структуры (лидеров мнений). Вместе с тем, ответственность за создание продукта делится равномерно между всеми участниками и лежит на команде в целом. В Agile не выделяют одного ответственного за результат;

  • состоит из 5-9 человек;

  • автономна и обладает достаточной смелостью, чтобы блокировать попытки вмешаться в ее работу и навязать срочные, но не приоритетные требования извне (помогает Scrum-мастер);

  • все члены взаимозаменяемы, команда кросс-функциональна. Любой участник может выполнять любую из задач, которые команда берет в работу. Но в сложных проектах это редко, и, как правило, есть «Т-компетенции»: когда участник глубоко разбирается в своей профильной деятельности (вертикальная черта в «Т») и средне в смежных областях (горизонтальная черта), может при необходимости помочь или заменить другого участника;

  • внутренне мотивирована на создание результата: она сама определяет, как выстроить работу над продуктом, все участники должны понимать цели, для которых создается продукт, каково его назначение, какие проблемы заказчика он должен решать;

  • размещается в одном помещении. Это помогает быстро общаться, быть в курсе общего состояния работы без формальных совещаний по статусу. При этом помещение для команды лучше выбирать изолированное от шума и присутствия других сотрудников: это поможет избавиться от информационного загрязнения и сфокусироваться на задаче.

Минусы и ограничения (наше мнение):

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

  • Высокая требовательность к уровню менеджмента, в том числе к работе с мотивацией, "осознанности" и компетенциями, как всей команды, так и руководителя/владельца. Во-первых тут применяется планирование, когда исполнитель сам оценивает необходимые сроки. Конечно, можно применять “покерное” планирование, но это лишние потери. А директивный подход приведет к текучке, что тоже не пойдет. В таких проектах важно учиться на исторических данных, чтобы понимать плюсы и минусы как каждого сотрудника, так и всей команды, каков на самом деле уровень производительности. Такие люди нуждаются в более "тонком управлении".

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

  • Agile не любит ограничений по срокам и финансам, а оплата почасовая... Если слабый руководитель, высокая текучка, низкий уровень команды, то вы получите "черную" дыру ваших средств и непонятную перспективу получения результата.

У нас были как удачные проекты по Agile философии, так и нет.

В качестве удачного примера можно привести исследование для Томской области. Мы с заказчиком раз в неделю общались, обсуждали результаты, наше мнение слышали, и мы немного отступили от тех. задания. Как итог - получили неплохой продукт для целевой аудитории и на 17% раньше планового срока.

В качестве неудачного - проекты в Минэнерго. В силу определенных причин сроки по всем проектам постоянно сдвигались вправо, желания что-то делать уже не было. В итоге все скатилось к постоянным подготовкам обоснований.

Полезные ссылки:

Scrum

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

Как работает скрам:

Основные роли, которые предусмотрены:

Владелец продукта

Это человек, который отвечает за успех всего продукта / результата. Он ведет бэклог продукта. Это заказчик для команды разработки, который потом отвечает за коммерческий успех и востребованность у конечных потребителей. Это предприниматель внутри компании. Он должен иметь достаточно компетенций и полномочий, чтобы принимать решения по продукту от имени заказчика.

Команда

Исполнители, те кто создает продукт. Если мы говорим про разработку программ, то она состоит из тестировщиков, архитекторов, аналитиков, программистов и т. д. Нужен как можно больший охват компетенций, и, желательно, наличие у всех более 1-й компетенции, чтобы люди могли понимать, слышать друг друга. Размер команды 5-9 человек.

Scrum-мастер

Человек, который поддерживает работу команды, помогая освоиться с фреймворком и давая необходимые инструменты для успешного преодоления всех трудностей.

Он оберегает команду от вмешательства извне, когда идет работа над текущим инкрементом. Изменения должны поступать по итогам спринта, но не вовремя работ.

Он может использовать любые подходы: как практики Agile, так и, например, Kanban (доска Scrum, это по сути доска, на которой указаны все работы на текущий спринт), Lean Startup и миксовать разные подходы.

Кроме того есть "дополнительные" роли: Пользователи и Стейкхолдеры — лица, которые инициируют проект (бизнес-заказчики) и для кого проект SCRUM будет приносить выгоду. Они вовлечены в схватку только во время обзорного совещания по спринту (Sprint Review)

Основные процессы, которые помогают организовывать работу:

Планирование спринта

Проходит перед началом каждого отрезка. Цель – определить объем работ, который команда возьмет в ближайший спринт.

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

Владелец продукта должен помнить, что он может лишь помочь команде осознать, что должно быть сделано за спринт, но не указывать и не выбирать за команду задачи, которые нужно включить в Бэклог (план работ) спринта. Команда, в свою очередь, берет на себя только тот объем работы, который действительно может выполнить. При этом нужно понимать, что решение команды – это не гарантия выполнения всех запланированных задач. Могут возникнуть непредвиденные сложности или новые внешние факторы.

Теперь мы видим, почему в Agile важна стабильность и уровень компетенций в команде.

Ежедневная летучка

Ежедневная планерка (Daily SCRUM), которая проводится в одно и то же время. Помните совещания на производствах? Этот инструмент вообще обязателен для всех. Он выстраивает точки контроля, позволяет лучше планировать день, повышает уровень дисциплины (я так полностью исключил опоздания на производстве).

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

Владелец продукта постоянно посещает эти встречи. Он может поделиться с командой результатами и планами своей работы, однако не должен ставить задачи команде или каким-либо образом вмешиваться в комментарии по задачам.

Разработка

Работа. Основное правило – запрет на изменение состава спринта. В ходе спринта нельзя добавлять к работе команды новые требования или отказываться от уже включенных в Бэклог спринта. Остановить выполнение спринта можно лишь в одном случае: если Цель спринта теряет свою актуальность. В этом случае проводится Ретроспектива для анализа причин возникшей ситуации и заново запускается Планирование спринта.

Обзор спринта

Открытая встреча для демонстрации результатов спринта. По итогам Обзора спринта должна быть получена обратная связь от пользователей по представленным результатам. При необходимости можно обновить Бэклог продукта.

Обзор спринта дает возможность команде напрямую пообщаться с пользователями и заинтересованными сторонами, услышать их требования и комментарии по выполненной работе. Стоит помнить, что задача Обзора спринта – не показать инкремент продукта во всей красе, а предоставить возможность пользователям проанализировать работу, которая действительно была проведена, и обеспечить прозрачность хода проекта.

Ретроспектива

Закрытая встреча Команды, на которой оценивается прошедший спринт с точки зрения организации процессов. На Ретроспективе формулируются ответы на вопросы:

  • Что было сделано хорошо?

  • Как можно улучшить процесс?

  • Какие улучшения будем делать в следующем спринте?

Ретроспектива поможет разрядить обстановку после Обзора спринта, на котором заказчик отказался принять инкремент продукта (результат работы за 1-4 недели). Выявив причины сложившейся ситуации, команда может сделать вывод, что ей необходимо плотнее общаться с Владельцем продукта и помогать ему в работе с Бэклогом.

Я рекомендую следующую структуру проведения встречи:

  • Новости и актуальная информация для синхронизации команды.

  • Что сделано за неделю / спринт

  • Что планируется на следующую неделю /спринт

  • Риски: снялись, реализовались, возникли.

Основные артефакты/документы/вещи, которые рождаются в процессе работы:

Бэклог продукта

Бэклог продукта (product backlog) — это упорядоченный набор элементов, очередь задач, перечень всех функций, которые заинтересованные люди хотят получить от продукта. Формируется и корректируется на всем протяжении проект