Адаптивные рамки проекта (APF) и как их внедрить?
29.08.2018
Для многих современных проектов не подходят модели традиционного проектного менеджмента (ТПМ) . Они не справляются с вызовами, которые возникают сегодня при запуске проектов: постоянные изменения, нечеткие бизнес-цели и действия конкурентов. Установить полные требования на первом этапе стало нереальным, их приходится корректировать на протяжении всего цикла.
Поэтому циклические и рекурсивные модели — это актуальные инструменты для проектных менеджеров. Возможность пересмотреть прошлый этап работ, усовершенствовать нынешнюю итерацию или постоянно сверяться и актуализировать данные дорогого стоит.
Цель метода Адаптивные рамки проекта (APF) — гармонизировать процессы и постоянные изменения в проекте, бизнес-климате и на рынках.
⁂28. Свойство background-size. масштабирует фоновое изображение. Уроки. Обучение. CSS3
Он не предполагает шаблонов и списка подготовленных заранее решений. Изменения в подходе являются нестандартным ответом на изменения в проекте или в окружающей среде
Автор метода Роберт Высоцки настаивает, что проектный менеджер (ПМ) должен вести себя не как повар, а как шеф-повар. Не надо следовать рецептам, когда отсутствие ингредиента приведет к задержке — нужно придумывать их самому, и не оглядываться на наличие требуемых компонентов. По наблюдениям Высоцки, линейные модели ТПМ не подходят для 70% проектов.
Он выделяет семь независимых факторов, которые влияют на проект:
Характеристики среды, в которой будет реализовываться проект Характеристики самого проекта Жизненный цикл бизнес-процесса Жизненный цикл проектного менеджмента Компетенция проектной команды Видение клиентов Качество оборудования или программного обеспеченияAPF зародился в ходе двух проектов. Один был направлен на улучшение работы компании, занимающейся разработкой программного обеспечения. Второй проект ставил целью создать информационные киоски для сети магазинов. Поэтому, подчеркивает Высоцки, отличие APF от других Agile методов — он не заточен для применения в IT-сфере, а является универсальным для бизнеса.
Принципы APF
Сфокусированность на клиенте. Заказчик несет ответственность за выбор инструментов и подходов для проекта, но получат поддержку со стороны проектной команды (ПК) . Зависимость от клиента. Адаптивные рамки проекта предполагают большую вовлеченность заказчика, чем привыкли большинство проектных менеджеров. Они должны быть готовы к роли консультантов, которые поддерживают клиента на протяжении проекта. Заказчик же решает, продолжать или завершать проект. Быстрая и частая демонстрация результатов. Циклы в APF являются короткими. Благодаря этому клиент быстро узнает о текущих результатах и надежнее вовлекается в процессы. Готовность постоянно задавать вопросы и анализировать. Многие фазы APF основаны на вопросах, на которые должны ответить ПК и клиент. Изменения — путь к лучшему решению. Частота изменений для проекта APF — хороший индикатор, как стороны идут к нужному решению. Идеально, когда перемены случаются часто на ранних циклах и замедляются в дальнейшем. В отличие от ТПМ, Adaptive Project Framework рассматривает изменения не как нечто плохое, а как признаки здорового проекта. Не спекулировать на будущем. Если мы не знаем будущего, зачем планировать? Прогнозирование будущего считается процессом, который не добавляет стоимости.Алгоритмы APF
Алгоритмы APF
Adaptive Project Framework состоит из 5 фаз.
1. Определение рамок
Это начальная фаза. Устанавливаются цели проекта, которые должны четко понимать как ПК, так и заказчик. Критерий успешности фиксируется как тот результат, который принес очевидную бизнес-ценность.
Определение рамок выполняется в 5 этапов:
Поиск условий соответствия. Проходит встреча между ПК и представителями заказчика. Это может быть общение и один на один, между ПМ и клиентом. По итогам встречи клиент должен убедиться, что его желания поняты, а исполнитель — что он донес клиенту, как будет выполнять проект. Все противоречия должны быть устранены уже на этом этапе.
Во время успешного поиска условия соответствия достигаются 2 важных результата. Формируется словарь — язык общения между ПК и клиентом, и утверждается соглашение по итогам переговоров. Оно станет отправной точкой для реализации проекта.
Составление заявления с обзором проекта. Соглашение по итогам переговоров превращается в документ, в котором освещаются:
Проблемы и возможности, которые стали причиной для инициации проекта Цели проекта Рамки для целей проекта Критерии успешности Риски.Определение параметров цикла. Устанавливаются продолжительность и количество циклов. Циклы могут не иметь одинаковую длительность, но в сумме должны соответствовать дате окончания проекта.
Циклы Adaptive Project Framework обычно длятся от 2 до 6 недель. Ранние циклы должны занимать меньше времени, чем поздние, чтобы сразу завлечь клиента в проект.
Установление неполной иерархической структуры работ, или расписания проекта. При планировании проекта в APF известна цель, но не известны инструменты для ее выполнения. Структура дополняется во время выполнения проекта, когда вскрываются важные детали.
Приоритизация алгоритмов. Хотя будущее в APF остается туманным, на этом этапе определяются приоритетные инструменты и подходы, которые могут быть применены в дальнейшем.
2. Планирование цикла
Адаптивные рамки проекта предполагают планирование в соответствии с концепцией «точно в срок». Учитываются только те процессы, для которых уже подобраны решения.
Планирование цикла предполагает вовлечение клиентов. Им легко управлять, оно не требует технологических решений.
Планирование разбито на 4 этапа:
Определение целей цикла. Обсуждается совместно с клиентом с учетом отведенного для цикла времени и имеющихся ресурсов. Распределение задач для подкоманд. Это первый шаг к формированию расписания проекта с указанием исполнителей. Процессы, которые имеют зависимости, разбиваются на группы, которые уже будут менее зависимы друг от друга. Участников ПК распределяют по подкомандам, которые займутся планированием и выполнением задач. Составление расписания для процессов с зависимостями. Подкоманды формируют первые списки задач для каждого процесса. Все, что требуется для данного этапа — стикеры, маркеры и доска. То есть применяется практика канбана . Работа подкоманд. Составляется итоговое расписание для каждой подкоманды. Его можно выполнить в виде матрицы, в строках которой будут указаны участники подкоманды, а в столбцах — количество дней в цикле. На клетке матрицы располагается стикер с описанием задачи. Когда в ходе проекта происходят изменения, достаточно убрать стикеры с ненужными задачами. При этом не будут нарушены зависимости между процессами, а участники одной подкоманды не будут переброшены в другую.3. Построение цикла
В отличие от ТПМ, в APF время выполнения цикла никогда не меняется. Оно остается таким, каким было установлено в ходе первой фазы «Определение рамок». Еще одна важная особенность — изменения не проводятся в ходе цикла. Внедрение новых подходов происходит между циклами.
Чтобы построить цикл, используются такие инструменты:
Расписание для микроуровней. Участники подкоманд составляют рабочий план для подзадач, из которых состоит задача в их расписании. Рабочие пакеты. Описывают, как исполнитель намерен выполнить подзадачи. Если с ним что-либо случится, то его может заменить другой участник подкоманды. Он будет руководствоваться рабочим пакетом выбывшего исполнителя. Чтобы не создавать работу с нулевой ценностью, ПМ не должен запрашивать рабочие пакеты для некритических задач. К важным задачам относят такие, которые имеют высокий риск или требуют исполнителей, которых тяжело подменить. Хранилище для запросов на изменения. Предложения, возникающие во время выполнения цикла, рассматриваются после его завершения. Они вносятся в специальное место на канбан-доске. Информация о проблемах. Еще одно место на канбан-доске отводится для описания проблем, рисков и ситуаций, которые нужно прояснить. Собрание ПК. Проводится ежедневно в начале рабочего дня и длится менее получаса. Ответственный за выполнение задачи отчитывается, успевает ли он за расписанием, и сообщает, имеется ли у него план изменений. Также он рассказывает, что выполнила его подкоманда вчера и что готова сделать сегодня.Если какой-то подкоманде нужна помощь, чтобы выполнить задачу в срок, то она просит ее у других участников ПК после окончания собрания. Во время встречи не обсуждаются проблемы, решения и конфликты — краткие дискуссии могут касаться лишь прояснения целей проекта или его процессов.
Отчеты о работе. Регулируемые рамки проектов не предполагают письменных отчетов, доклады происходят в устной форме. Во время рабочего собрания ПМ кратко прояснит команде, как решаются проблемы, влияющие на проект.
4. Согласование с клиентом
Уникальная фаза, которой нет в ТПМ. ПК и клиент приступают к решающим переговорам, в ходе которых они анализируют проект:
какие процессы были выполнены вовремя, особенно при последнем завершенном цикле. совместно решить, должен ли проект перейти к следующему циклу. изучить запросы на изменения, которые хранились на канбан-доске; инструменты и ресурсы, не задействованные в последнем завершенном цикле; а также инструменты и ресурсы, подготовленные для следующего цикла; и составить новые приоритеты. определить цели для следующего цикла.После проведенного анализа клиенту и ПК предстоит ответить на 4 вопроса:
Соответствуют ли общие показатели проекта ожиданиям?
Существуют 2 характеристики, которые помогают определить успешность проекта. Первая — это темп. На протяжении предыдущих циклов ПК и заказчик плотно сотрудничали, поэтому могут чувствовать, набрал ли проект достаточную скорость к финальному этапу.
Если достигаются заложенные в план показатели, а клиент активно участвовал в обсуждении процессов, то настроения в команде будут хорошие. Если же заказчик равнодушно относится к судьбе проекта, отношения в коллективе не складываются, что отражается на продуктивности — то будущее такого проекта под вопросом.
Вторая характеристика — взаимодействие. Если сотрудничество ПК с клиентом складывалось плодотворно, то обе стороны смогут совместно решить, какие инструменты и подходы осталось применить в дальнейшем. Это будет знаком, что проект является здоровым и должен продолжаться.
Должен ли проект перейти к следующему циклу?
Если обе стороны серьезно подошли к анализу проекта на данной стадии, то они легко примут решение о его дальнейшей судьбе. Если существует неуверенность, что идея не будет реализована, то самое время ее отложить. Из пепла может возродиться новый проект, в котором будут учтены ошибки.
Какие инструменты и подходы получат приоритет?
На протяжении прошлых циклов на доске накапливались предложения участников ПК для изменений в проекте. Ранее были выбраны инструменты и подходы, которые еще не получили приоритет для предыдущих циклов. Теперь предстоит новая сортировка. Она пройдет легче благодаря опыту как ПК, так и заказчика.
Что мы должны построить в следующем цикле?
Список с новыми инструментами и подходами, получившими приоритет, подготовлен. Продолжительность следующего цикла известна. Цели можно ставить амбициознее, чем для предыдущих циклов. Но не обещайте клиенту невыполнимое, чтобы не утратить утвердившееся доверие.
5. Обзор проекта
Как и в ходе предыдущей фазы, вам предстоит ответить на вопросы:
Нашла ли команда приемлемое решение?
Этот вопрос можно разбить еще на два. Регулируемые рамки проектов изначально не прояснили решение при известной цели проекта, поэтому нужно сперва ответить, нашли ли мы его. Если да, то соответствует ли это решение критериям успешности, которые были установлены во время первой фазы.
Ответственность за успешное выполнение проекта несут как ПК, так и клиент.
Подошли ли алгоритмы APF для проекта?
Этот вопрос нужно задавать для каждого проекта, как удачного, так и нет. Разработчик метода Высоцки призывает делиться информацией о слабых сторонах APF, так как следит за его развитием и готов вносить правки.
Насколько хорошо команда использовала алгоритмы APF?
Высоцки настаивает, что во время фазы согласования с клиентом обе стороны должны максимально открыто обсудить будущее проекта. Что получилось хорошо и почему? Что закончилось провалом и почему? Что команда не сделала вопреки ожиданиям? Ответы на эти вопросы дадут информацию как для следующих циклов проекта, так и для других команд, использующих регулируемые рамки проектов.
Внедрение APF
Как упоминалось в начале, APF как метод зародился в ходе двух проектов. Один из них заказал ритейлер Snacks Fifth Avenue, который торговал элитными снэками со всего мира в 10 магазинах в Нью-Йорке. Второй — компания Kamikazi Softwarre Systems, разрабатывавшая приложения для Интернета и локальных сетей.
Рассмотрим один их из этих проектов под микроскопом. В 2008 году сеть Snacks Fifth Avenue приближалась к 50-летнему юбилею. Поводов для радости было немного: показатели продаж падали вместе с потоком клиентов.
Директор сети Пэтти Форз хотела привлечь новых покупателей и заразилась идеей, которую увидела в одном из торговых центров поблизости. Там установили киоски с программными приложениями, содержащими информацию о локальных ресторанах и кинотеатрах. Форз захотела поставить аналогичные киоски и в своих магазинах, однако даже не знала, как должны они выглядеть и какие услуги оказывать.
Вот так выглядело заявление с обзором проекта для Snacks Fifth Avenue:
|
Заявление с обзором проекта |
Название проекта « Дизайн киоска» |
Номер проекта 08-01 |
Проектный менеджер Т. Кофи |
|
Проблемы/Возможности Посещение магазинов Snacks Fifth Avenue падает, в этом квартале продажи уменьшились на 10% в сравнении с предыдущим кварталом. Нужно сделать что-то, чтобы изменить такой тренд. |
|||
|
Цель Вернуть продажи к прошлому уровню, увеличить поток посетителей. Создать что-то примечательное и интересное для покупателей в магазине. |
|||
|
Рамки для целей проекта: Разработать концепцию киоска с несколькими услугами для покупателей. Создать карту, как заинтересовать посетителей определенными продуктами. Создать оригинальные наборы для продуктов, которые берут для вечеринок или праздников Создать каталог для заказа товаров. Создать меню товаров для особых случаев. Предложить услуги по планированию торжеств. |
|||
|
Критерии успешности Восстановить уровень продаж предыдущего квартала на протяжении двух кварталов с момента запуска киоска. Предложить как минимум 4 сервиса, которые можно получить в киоске. Каждый из них должен принести доход, равный как минимум 5% от продаж. Провести опрос покупателей. Идея киоска должна понравиться 50% из них. Опросить посетителей, какие 3 новых сервиса они хотели бы получить. Реализовать минимум 1 идею, которая принесет прибыль, равную как минимум 5% от продаж, к концу второго отчетного квартала. |
|||
|
Риски Покупателям не понравится идея с киоском. |
|||
|
Подготовлено Т.Кофи |
Дата 01.01.08 |
Одобрено Пэтти Форз |
Дата 03.01.08 |
Большинство процессов в проекте было направлено на разработку дизайна киоска. За 6 месяцев были созданы несколько пробных прототипов, сделанные за один цикл длиной 4 недели.
В начале проекта возникали такие вопросы:
должен ли информационный киоск управляться при помощи клавиш или тачскрина? смогут ли выдаваться печатные чеки? должен ли из киоска выдаваться продукт? можно ли размещать заказы? можно ли запустить службу поддержки?В фазе согласования с клиентом участвовала фокус-группа из потребителей. Им предложили выразить мнение о виде киосков и сервисах, которые они предложат.
После этого были созданы 6 прототипов с учетом опроса потребителей. Система обеспечения была разработана за следующие 3 месяца. После того, как фокус-группа протестировала продукт, были сделаны небольшие правки в пользовательском интерфейсе. Проект был закончен в следующем месяце. В магазинах сети запустили более 200 киосков.
В них выдавались продукты, принимались заказы. Покупатели узнавали новую информацию при помощи карт и других услуг. Интерес к Snacks Fifth Avenue начал постепенно расти благодаря новым технологиям. Цели проекта по показателям продаж и посещения были выполнены.