Система планирования продуктовых проектов

Тимофей Скрыльник, MBA, PME, руководитель проектов Отдела развития продуктовых решений «Адванта Консалтинг»

При создании нового продукта разработчики горячо спорят, какую методологию применять – проектное управление или гибкие методологии? Случается, что создатели мобильных приложений приходят в судостроение и бьют себя в грудь, выкрикивая:

– Гибкие методологии – лучший подход!

Бывает наоборот: те, кто работал с космической отраслью, переходят в ИТ и пытаются спланировать каждую задачу заранее, просчитав все на этапе инициации. В итоге продукт проваливается, потому что та модель, по которой делался запуск, не соответствует ни скорости изменений рыночной ситуации, ни возможностям и культуре организации.

Планирование запуска продукта и рыночные провалы

Вопрос ставится более широко: существует множество подходов к управлению и планированию проектов, сочетающих в себе недостатки и лучшие стороны традиционного планирования и современные разработки, к которым относится гибкое управление и много чего еще. Например, есть методологии, направленные на постоянное создание ценности (стандарт P2M). Есть методологии, нацеленные на оптимальное управление временным риском (метод критической цепи и его разновидности). Если ошибиться в выборе методологии и начать создание космической ракеты по Scrum, провал гарантирован. Правильный же выбор обеспечит рыночное преимущество, потому что результат будет быстрее, дешевле и создаст ценность для потребителя.

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

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

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

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

• лидерство и издержках
• лидерство в продукте
• стратегия фокусирования

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

Планирование неопределенности в развитии продукта

Продуктовые проекты, в отличие от проектов в общем смысле, нацелены не на получение результата, а на «создание ценности», даже если результат, обеспечивающий ценность, постоянно меняется. В конечном счете, заказчика интересует возврат инвестиций:в начале проекта определяется рыночная возможность, в конце ожидается прибыль. В ходе самого проекта задачей является определить характеристики продукта, создать его, продать, вернуть вложения.

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

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

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

Для проектов, в которых планируется множество изменений, есть два основных подхода:

1. Упорядочивать изменения, применяя при этом классическое планирование проектов. Планировать проекты глубоко, но только те этапы и работы, которые известны. То, что не известно, оценивать с применением методов оценки таких, как бенчмаркинг.
2. Считать, что изменения являются основной частью работы, не планировать ничего, кроме изменений (это есть гибкие методологии).

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

Источник: Cooper 2001

Проект состоит из этапов, которые реализуются по планам в рамках проектной модели. После каждого этапа проводятся процедуры по:

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

Например, в строительной отрасли после изыскательских работ проводится ревизия проекта, для чего уточняются планы, ожидаемая прибыль, собирается инженерный комитет. По итогам проект может даже потерять привлекательность (если обнаружены грунтовые воды) – его надо срочно остановить! Возможно, проект следует изменить, чтобы вернуть прибыль: вместо элитного жилья в башнях от 55 этажей создать детский парк. Детский парк не вернет стоимость земельного участка, но минимизирует убытки.

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

Это подобно тому, как мы едем по переполненному пробками городу на машине:

1. Мы проложили маршрут, распечатали, едем только по нему. Навигатор посчитал, что ехать час, но пробки выросли, мы едем два.
2. Мы проложили маршрут, навигатор предложил объезд на середине пути. Мы поехали по другому маршруту. Ехали лишь полтора часа, но бензин расходовался быстрее.
3. Мы не пользуемся навигатором! Мы видим пробку и сразу сворачиваем. Зато можно проехать дворами! Доехали быстро, но заплатили штраф.

Выгода при гибком подходе получается за счет того, что мы не закладываем в планы резервы, у нас нет громоздкой процедуры утверждения изменений. Также у нас очень короткие этапы, и мы постоянно мониторим реакцию рынка. Отметим, что подход StageGate подразумевает в целом то же самое, только длина спринта не 2 недели, а до двух лет.

В этой статье мы четко определяем границы применимости: дальнейшие изложения верны только для продуктов, в которых используется водопадное планирование. Стройка, фармацевтика, во многом ИТ (если создаем что-то крупное) подходят, в то же время мобильные приложения и интернет-магазины – нет. Затронуть все аспекты всех методологий невозможно.

Развитие продукта и ограничения бизнеса

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

1. По срокам
2. По стоимости
3. По требованиям к продукту: как сказал когда-то Генри Форд, «автомобиль может быть любого цвета, если он черный».

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

Построение качественного графика для продуктового проекта в ADVANTA

Выше описаны основные элементы, исходя из которых можно сформулировать требования к формированию плана-графика создания продукта: 

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

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

Для продуктовых проектов планы строятся так, чтобы обеспечивать постоянное устранение неопределенностей. Неопределенности же задаются:

• Незнанием на ранних этапах параметров рынка
• Незнанием на ранних этапах потребностей клиента
• Незнанием на ранних этапах возможностей производства / организации
• Рисками на каждом этапе

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

Мы можем выдвинуть требования к плану-графику:

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

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

Можно выделить следующие работы по устранению неопределенностей, которые можно смело включать в любой проект создания продукта:

• Подготовка данных о рынке – конкуренты, объемы рынка, тренды и т.д.
• Уточнение знаний о клиенте, формирование детально портрета клиента
• Сбор подробных данных о всех заинтересованных сторонах
• Формирование максимально точного облика продукта в форме продуктовых гипотез (мы все же не знаем продукт точно, потому на этом этапе, даже если мы говорим, какого он цвета, это лишь гипотеза)
• Тестирование продуктовых гипотез через MVP

В системе планирования ADVANTA есть все необходимое для создания плана проекта с требуемой детальностью: это, прежде всего, диаграмма Ганта, в которой есть возможность выделять этапы и вести разные мероприятия, включая закупки, риски, MVP и т.д.

Построение качественного плана управления проектами для продуктового проекта

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

Для плана проекта создания продукта, тем не менее, стоит отметить:

• План управления заинтересованными сторонами становится крайне важен: если мы говорим «Client is the King!» мы должны помнить, что он – тоже заинтересованная сторона!
• Должен быть проработан план коммуникаций – нужная информация должна доводиться до заинтересованных сторон, иначе в проекте возникнут дополнительные риски.
• В части закупок ничего необычного, но мы должны помнить, что мы закупаем не только для продукта, но для MVP. Для MVP чаще прибегают к аутсорсингу, так как MVP достаточно короткие.

Главное, что должно быть в плане управления продуктовым проектом и чего нет в типовом плане по PMI, это описание задачи по постоянному мониторингу ценности для клиента. Когда готовится MVP? Когда проводится развитие клиента? Как и на какие метрики влияют утвержденные изменения? Если это не прописать в плане или даже Уставе проекта, исполнители более поздних этапов могут забыть о связи проекта с рынком.

В этой статье мы разобрали принципы и дали рекомендации, как планировать проекты развития продуктов. Прочитав ее, мы не исключаем, что некоторые скажут: «Не, слишком сложно, внедрим Agile». Возможно, они будут по-своему правы. Тем не менее, это не отменит необходимость проводить и рыночные исследования, и тестировать MVP, и отслеживать ограничения и продуктовые метрики. ADVANTA позволяет упростить планирование за счет шаблонизации. Составьте типовые блоки проектов (например, типовой MVP), подготовьте шаблоны в ADVANTA, разворачивайте эти блоки из шаблона. Надеемся, что система управления продуктовым портфелем и хороший инструментарий планирования позволит вам выполнять ваши проекты качественно и в срок, а продукты делать более прибыльными.