Продуктовый подход в обучении: где его применять и зачем
Нажимая кнопку, вы соглашаетесь с условиями передачи информации.
* Пожалуйста, укажите название вашей компании — мы работаем только с юридическими лицами.
Зачем обучению продуктовый подход
«Внедрять образовательный проект несколько месяцев и в итоге его провалить — дорогая ошибка. Сейчас даже „внутренний рынок“ — сотрудники компании — перенасыщен обучающим контентом. Так что перед T&D стоит непростая задача: вовлечь сотрудников в обучение, показав им ценность программы или курса, достичь бизнес-целей и при этом эффективно потратить бюджет.
Продуктовый подход — итеративный. Он позволяет безболезненно вернуться назад на любом этапе, переработать обучение и снизить риски. А если сразу делать программы и курсы под запросы пользователей, с нужной подачей материала и каналами коммуникации, созданием поддерживающей среды и качественной упаковкой программы, а еще постоянно сверяться и корректировать продукты, такое обучение точно будет востребованным у сотрудников и принесет деньги бизнесу»
Продуктовый подход работает на задачи бизнеса — главного заказчика обучения. Продакт-менеджер определяет целевую аудиторию и текущие бизнес-потребности, формирует ценность, упаковывает эти данные в стратегию разработки продукта и контролирует выход этого продукта на рынок.
Цифры и аналитика помогают следить за выполнением задач, а в дальнейшем — оценивать прибыль, которую продукт приносит компании. Так бизнес не стреляет из пушки по воробьям, а сразу вкладывается в окупаемый проект, который отвечает двум задачам: скорости реализации и ценности для конечного пользователя.
Плюсы продуктового подхода для решения бизнес-задач:
Как применять продуктовый подход в разработке корп-обучения
Раскладываем разработку образовательного продукта на 7 шагов, используя продуктовый подход. Объясняем, как надо и как не надо действовать на каждом шаге.
Как [не] работал классический подход в обучении
На нашем опыте, когда компания планирует обучение, она собирает его из потребностей бизнеса и существующего технического решения. Например, нужно поднимать продажи, и есть какая-то LMS, которую компания купила «на всякий случай». Всё это смазывают модными трендами типа «мобайл-фёрст» и загоняют продавцов в мобильную LMS с курсом по продажам.
Это ретроградный подход, и это не работает. В компаниях клиентов мы внедряем продуктовый подход к обучению и раскладываем разработку на 7 шагов.
Вот как будут работать оба подхода.
1. Образовательный контекст пользователя
❌ Никто не разбирается, почему продажи нужно поднимать, что мешает сотрудникам это делать, какое обучение поможет им работать лучше, и в каком виде это им удобнее. Кажется, что если это рабочее обучение — можно просто поставить перед фактом.
✅ Первое, что мы делаем — аудит образовательного контекста пользователя. В стартапах это называют исследованием целевой аудитории, а у нас — персона-моделью. Вот выдуманный пример:
В левой части собираем классические соцдем-характеристики: возраст, место жительства, семейное положение, где и кем работает. Это база, на которой строится контекст пользователя.
В правой части — углублённый портрет. Чем этот человек живёт, какая у него ролевая модель и уровень технической грамотности, какой прошлый опыт обучения. Если этого не знать, наш продукт может «промахнуться» или не учесть важного бэкграунда пользователей.
2. Валидация проблемы и потребности
❌ Если у пользователей нет потребности, у них не будет мотивации учиться. Если у бизнеса нет потребности решать свои задачи с помощью обучения, он не вложит деньги и время. То же самое — если потребности бизнеса и пользователей расходятся.
Например, менеджер видит, что сотрудники не работают по эджайлу, хотя должны. Первый вариант — провести тренинг или курс по эджайлу и ещё раз объяснить людям, как это работает.
✅ Второй вариант, который использует продуктовый подход и CustDev, — выяснить, в чём проблема. Может оказаться, что проблема не в методологии, а в кросс-функциональных коммуникациях, или просто никому не понятно, как работать в «Джире». Получается, что обучать надо другим вещам.
В итоге мы находим точку пересечения: где запрос разделяют пользователи, и он выполняет цели бизнеса.
3. Проблемные точки на пути пользователя
❌ В классическом подходе обучение видится простой схемой: запустили продукт → обучили людей → получили результат. На деле всё сложнее. Внутри каждого шага у пользователя возникнут проблемы: авторизация, понимание целей обучения, цифровая грамотность, удобство платформы, затраченное время, сложность и многое другое.
Если каждую из этих проблем не отработать, пользователь отвалится и перестанет учиться. Или, если такой возможности нет, — саботирует обучение.
✅ Чтобы понять, какие характеристики нужны обучению, мы строим LJM — Learning Journey Map. Это весь путь взаимодействия пользователя с обучением, начиная от слухов и анонсов, заканчивая вручением сертификата или рефлексией. С помощью него понимаем, с какими проблемными точками работаем. Точно так же продуктовые команды разбираются с драйверами и барьерами пользователей.
Например, мы находим проблемы на первом этапе воронки — когда пользователь должен согласиться на обучение. Может оказаться, что не хватает понимания, зачем нужно обучение, что оно даст — это значит, что людям не «продали» обучение внутри компании, и никакой мотивации им заниматься нет.
4. Итерационный запуск обучения
❌ Традиционный и не очень удачный способ делать продукт — уходить и 3—5 месяцев разрабатывать его в лабораторных условиях. Если на тестах перед запуском что-то пойдёт не так, придётся переделывать большую машину.
✅ Хороший вариант — разбить разработку на итерации и тестировать каждую. Например, поменять первую точку касания с пользователем и сделать хорошую рассылку про обучение. Аналитика покажет, что цифры выросли, но слабо. Пробовать другое: сделать анонс в Вотсап-чате — и увидеть, что конверсия выросла. Решение найдено, и можно интегрировать его в продукт.
По сути, разработка обучения — это постоянный цикл постановки гипотез и их проверки. И хотя в образовании обычно меньше статистики, чем в других продуктах, всё равно есть ключевые показатели: конверсии в воронке, доходимость, вовлечённость, карта кликов.
5. Внутренний маркетинг
❌ В нашей практике на полном серьёзе бывали случаи, когда обучение просто выкладывали на корпоративный портал и удивлялись, почему никто не проходит. Недостаточно сделать хорошее обучение, про него нужно ещё рассказать.
✅ В продуктовом маркетинге это называется «доставка» контента — и в обучении всё работает так же. Важно, где пользователь видит информацию об обучении, откуда узнаёт про него, в каком виде, чем поддерживается его интерес, и где можно узнать подробности.
6. Конкуренция за внимание
❌ Кажется, что у корпоративного обучения нет конкуренции, потому что оно обязательное и делается для конкретных сотрудников. Это не совсем так.
Обязательное обучение совсем не значит, что его нельзя саботировать. Прокликивать тесты, копаться в телефоне на тренинге, делать для галочки — всё это встречается в корпоративной среде. Поэтому у корп-обучения есть большой вызов в плане увлекательности, пользы и эстетики.
✅ Наш конёк — геймифицировать корп-обучение, делать его увлекательным, красивым, игровым. Мы даже называем это «геймдизайном» обучения, и такой продукт может конкурировать за внимание с «Ютубом» и «Нетфликсом». Но геймификация нужна не всегда.
Бывает конкуренция, когда по вашей теме уже есть хороший продукт: люди могут получить этот контент в другом месте, он объективно лучше того, что вы можете сделать сами. В таком случае полезнее договориться о партнёрской программе или создать контент, специфичный для вашей компании.
Ещё конкурентом может быть уровнь аналогичных продуктов. Если люди вне работы учатся на «Мастерклассе» или в «Юдеми» — от корпоративного курса они будут ожидать такого же качества. Не дотянете до планки — и пользователи отвалятся ещё до того как дойдут до контента.
7. Как закончить пользовательский опыт в обучении
❌ Ситуация, с которой мы часто сталкиваемся — обучение ничем не заканчивается, как сериал, который закрыли на середине истории. Люди остаются в подвешенном состоянии: непонятно, что стало итогом, что делать дальше, как, кому и куда дать обратную связь.
✅ Есть несколько способов закрепить или просто закончить образовательную программу. Например, суммировать весь опыт в виде чек-листов, гайдов, возможности вернуться к новым знаниям.
Другой вариант — провести рефлексию, записать инсайты, поделиться обратной связью. Это будет полезно и для развития обучения как продукта.
Обучение — тоже продукт
Это главная мысль, которую мы хотели донести. Неверно и даже опасно считать, что корпоративное обучение существенно отличается от любого другого продукта или услуги, которые человек получает от компании, государства или покупает на свои деньги.
Продуктовый подход помогает сделать обучение полезным, своевременным и даже желанным. Сохраните схему, чтобы не забыть.
Продуктовый подход к онлайн-курсам
Эта статья была изначально опубликована в журнале «Развивейшн». Если вы хотите каждый месяц получать новую порцию интересного и полезного материала на вашу электронную почту, то оформите подписку.
В марте запустил курс «Дзен эффективности» о том, как перестать тратить время на ерунду. Сделал его так, как всегда мечтал: без воды, пустой мотивации, уловок и самообмана. Чётко и по делу. Концентрированный практический опыт, сотни ссылок на научные работы и неочевидные приёмы и советы. О самом курсе рассказывал пару месяцев назад.
За три месяца курс прошло 30 человек, большинство осталось довольны и многие хотят продолжать учиться. Конечно, можно было бы организовать университет имени себя любимого и делиться там чем-то интересным и полезным, заворачивая это во всё новые и новые курсы. Но во мне победил продуктовый подход. Сейчас расскажу, что это значит.
Относиться ко всему на свете, как к продукту меня научили Ваня Замесин, создатель Меты, блог которого я читаю почти каждый день, и Денис Пушкин из Скайэнга (советую посмотреть его доклад о том, как превратить в продукт переговорку, отношения и толстовку).
Вот так я формулирую для себя ключевые принципы продуктовой разработки:
Каждый из этих принципов я применил ко вполне традиционному инфобизнесу. В итоге у меня получился продукт, который немного отходит от классической парадигмы и ломает основные устои.
Тренеры и создатели курсов хитренькие: придумали инфопродукт и долго на нём катаются, затягивая всё глубже и глубже в свою воронку. Сначала ты подписываешься на бесплатную рассылку, потом слушаешь вебинар, приходишь на онлайн-курс, а в конце ещё и в школу какую-нибудь. И каждый раз должен платить за то, что тебе пережёвывают один и тот же контент по десять раз. В этом плане я неправильный инфоцыган.
Раз в месяц у меня происходит релиз новой версии курса, который одновременно получают студенты прошлых потоков и новички. Все они могут прийти в онлайн-эфир по воскресеньям, послушать разбор темы и задать свои вопросы. То есть через месяц обучение не заканчивается, а продолжается с новой силой. Так, например, я полностью переделал урок про энергию, где мы говорим о том, что делать, чтобы не выгорать. Судя по отзывам, получилось неплохо, но есть над чем ещё работать.
Регистрируясь на курс единожды, ученик получает обновления материалов до тех пор, пока у меня есть силы их выпускать. При этом области для переработки уроков каждый раз новые. А здесь вступает в силу второй базовый принцип — бэклог.
В большинстве курсов, которые я проходил, организаторы либо придавали обратной связи совсем мало значения, либо игнорировали её полностью. Да, были опросники в конце занятий, кто-то прислушивался к советам и что-то менял. Но скорее всего, я об этом никогда не узнаю, потому что всё это происходило уже после моего обучения. Новинки и изменения получали следующие потоки. Потому что между обратной связью и реакцией проходило очень много времени. Как вы понимаете, у меня всё устроено по-другому.
В конце митапа один из организаторов попросил поднять вверх руку с количеством пальцев, характеризующим, насколько встреча была полезной и оправдала ожидания. В зале нас было около ста человек и каждый вытянулся на стуле. Потом ведущий попросил тех, кто оценил мероприятие ниже «четвёрки», рассказать о том, что нужно поменять в следующий раз, чтобы оценка повысилась. Было интересно и очень конструктивно. Я взял эту практику на вооружение.
В конце урока я прошу учеников поставить оценку, и мы вместе разбираем обратную связь. Каждый рассказывает о том, что можно улучшить, что доработать. Все комментарии попадают в бэклог, какие-то идеи я реализую уже к следующему занятию, какие-то на следующем потоке. Одним из ключевых изменений стал трекинг выполнения заданий, помогающий отследить прогресс учеников на курсе. Я бы никогда об этом не подумал, если бы не услышал, что на курсе не хватает геймификации, помогающий не потерять фокус на главном.
Конечно, у меня есть анкета в конце потока, анализ отзывов, но наиболее полезной оказывается именно ненапряжная обратная связь на занятиях, которую ученики дают в онлайне. Цикл фидбека помогает постоянно совершенствовать и дорабатывать продукт.
Это только две метрики, которые я научился отслеживать. Впереди фокус на работе и результатах учеников, более детальная проработка материалов и оценка практических заданий. Но уже сейчас понятно, что делать, а главное, зачем.
Благодаря продуктовому подходу, курс постоянно находится в круге развития: ученики подсказывают, что ещё можно доработать (формируют бэклог), получают обновлённый материал (итерация), обсуждают его внутри сообщества (метрика) и предлагают очередные доработки (опять фидбэк). Продукт эволюционирует, и я этому несказанно рад.
Каждый следующий поток привносит что-то новое, но все эти возможности доступны ученикам прошлых наборов, потому что они приложили к ним руку
Методология продуктового подхода
Попробуйте вбить в google «продуктовый подход» и посмотреть первые несколько ссылок. Все статьи рассказывают об общих принципах, о результатах, которых Вы непременно достигнете, если начнёте его применять. Смотрите сами:
Эта ситуация напоминает хайп вокруг Agile. Было много статей на тему «Почему Agile – это круто». Потом многие компании пробовали понять, что же это такое Agile, и адаптировать идеи под себя (так, как они это понимали). Но в итоге стало появляться множество статей на тему «Почему Agile – это НЕ круто». Самое распространённое мнение про Agile, которое я слышал: «Agile – не для нас, так как Agile – это никаких документов, хаос и постоянное изменение требований, а нам так нельзя (да и в России без документов – никак)».
В последние годы то же самое происходит и с продуктовым подходом. Информации много, но она носит общий характер. В этой статье я постараюсь систематизировать эту информацию для того, чтобы начинающим продактам (и компаниям, где они работают), было проще начать применять этот подход.
P.S. Не стесняйтесь дополнять в комментариях
Итак, прежде всего, Продукт – это не товар или услуга, которую Вы продаёте. Продукт – это Ваше ценностное предложение, направленное на решение важной проблемы Вашей Целевой Аудитории (ЦА) через выбранные каналы продаж. Или проще: Продукт – это совокупность ЦА, канала и месседжа (то, как Вы доносите ценность вашей ЦА).
Целевая аудитория (ЦА) определяется двумя составляющими. Это – Клиент и Рынок. Для анализа ЦА следует изучить клиента:
Далее: Где мы можем получить нашу Целевую Аудиторию? Оцениваем типы каналов продаж и выбираем из них те, через которые наиболее вероятно можно получить нужных нам клиентов. Определившись с типами, подбираем конкретные каналы (к примеру, Facebook-группа Лаборатория Digital экспертов).
Для формирования ценностного предложения необходимо понять, по каким критериям люди выбирают тот или иной товар или услугу – определяем их Главную потребность:
Поняв Главную потребность клиента, мы можем определить, какими функциями/свойствами, направленными на удовлетворение этой потребности, обладает (или должен обладать) наш продукт. Формулируем Ценностное предложение / Месседж. Обратите внимание, что это – не те слова, которые мы будем говорить нашему клиенту, а та мысль, которую мы попытаемся ему донести.
Наше ценностное предложение будет неполным, пока мы не изучим наших конкурентов и не выявим Главного конкурента. Конкуренты бывают прямые (делают примерно то же, что и мы) и непрямые (создают ту же ценность, но другим способом). Главное: Конкурент есть всегда. Иногда конкурентом является «устоявшийся порядок». К примеру, для некоторых клиентов Uber конкурентом является привычка людей ловить проезжающие машины, подняв руку на улице. Сильные и слабые стороны конкурентов можно оценить, связавшись с ними под видом потенциальных покупателей.
Далее – важный этап. Делаем юнит-анализ. Важный – потому что здесь мы закладываем допущения (assumptions), которыми мы будем в дальнейшем управлять и отслеживать (основные метрики). Юнит-анализ – это P&L «наоборот». Если P&L отвечает на вопросы «Сколько я заработаю?», «Когда будет break even?» и «Какой у меня ROI?», то юнит-анализ зачастую делается «на коленке» и отвечает на вопрос, сколько «юнитов» мне надо продавать, чтобы выйти на безубыточность, и сколько – чтобы заработать. миллион? (подставьте сумму сами). Именно тут мы понимаем требуемую ёмкость каналов привлечения клиентов, можем быстро проверить, окупается ли продукт, и выявить точки, которые влияют на маржинальность.
Главное – все описанные исследования и расчёты делаются итерационно, то есть мы постоянно возвращаемся к ним, проверяем и уточняем. Для этого мы должны постоянно общаться с нашей ЦА, задавать им вопросы, слушать и слышать, проверять конверсии на практике, стараться получить наиболее репрезентативную (и разнообразную) выборку различных потенциальных клиентов.
Партнёрства. Какие партнёры могут дать нам новых клиентов? Какие партнёры позволят увеличить средний чек? Какие – снизить отток клиентов? Продумайте, какие партнёрства возможны и как они повлияют на ключевые метрики Вашего продукта. И что Вы можете дать в обмен Вашим партнёрам? И посчитайте, «сходится» ли экономика партнёрства.
Да, и немного про ключевые метрики. Некоторые из них Вы скорее всего уже сформулировали в ходе анализа. Настало время их дополнить, чтобы далее, при разработке, выводе на рынок и развитии продукта отслеживать их, адаптировать и, при необходимости, менять.
Если всё хорошо и экономика сходится, переходим к разработке и выводу продукта на рынок. На мой взгляд, тут есть две главные составляющие, которыми должен управлять product manager: Sales&Marketing и Development.
Оставим за рамками этой статьи вопросы разработки. Могу только сказать, что в большинстве случаев я – за Agile. И не забудьте, что расчёт большинства выбранных нами ключевых метрик необходимо сразу заложить в разрабатываемый продукт.
Остановимся подробнее на тех «артефактах», которые нам стоит подготовить для успешных продаж Вашего продукта:
В качестве итога: трудно охватить такую большую тему в короткой статье, я сознательно опустил некоторые важные темы из-за их объёма. Но надеюсь, что эти пробелы будут восполнены в комментариях.
В качестве благодарности: Благодарю школу продакт менеджеров Product University, которая дополнила мои знания и помогла понять необходимость структурирования разрозненных знаний о продукте.
Продуктовый или проектный подход – как правильно?
Мне очень нравится фраза одного статистика: «В сущности, все модели неправильны, но некоторые полезны»
Примерно лет 10-15 тому назад многие жали за процессное управление – разобрались, что не везде работает; переключились на проектное, сейчас разбираемся, что и оно не везде работает.
Любой подход имеет ограничения определённое контекстом применения. Стрёмно видеть, когда доказательства применимости подхода ссылается на сам подход, а не на контекст его применения — доказательство догмата через догмат – религиозный фанатизм.
Приходится часто сталкиваться с подобным догматизмом от проектного управления.
Метрики, используемые в проектном управлении, направлены на контроль достижения цели в определённых проектных ограничениях, а не на контроль соответствия поставляемого продукта решению задач, под который он создаётся. Интересным образом эта проблема была сформулирована в «Чёрном законе метрик».
Метрики в продуктовом менеджменте направлены на проверку того, что действительно ли, создаваемый продукт соответствует решению проблемы потребителя. Эта проверка между проблемой и решением иногда называют «соответствием продукта рынку» (product market fit). Об одном из подходов к продуктовому управлению, где используется product market fit писал тут.
Странно выглядела бы идея строить многоэтажный дом, сдавая каждый этаж отдельно, регулярно внося конструктивные изменения на основании обратной связи от будущих жильцов. И также странно выглядит идея запустить продукт, ориентированный на открытый рынок, стремясь соблюсти проектный подход.
Представите, глобальную страховую компанию, которая хочет разработать новый продукт для страхования домашних животных.
Руководитель продукта пытается продемонстрировать совету директоров цифровые инновации, ожидая, что проект будет укомплектован человеческими ресурсами с самого начала, а разработчики, технические специалисты, которые в настоящее время работают над различными другими проектами, также будут задействованы в этом проекте.
Следуя традиционному принципу проектного управления, техническое руководство составляет его план и заранее определяет бюджет и необходимые человеческие ресурсы. Ежемесячно контролирует, идёт ли работа по плану и в рамках бюджета.
Затем, после запуска год спустя, приложение явно не привлекает значительного числа новых клиентов – и по факту хуже аналогичного решения, выпущенного маленьким стартапом в области страховых технологий шестью месяцами ранее.
Традиционные принципы управления ИТ-проектами долгое время обеспечивали успех в бизнесе и помогали предприятиям реализовывать крупнейшие и наиболее важные инициативы на протяжении многих лет. Управление проектами даёт руководителям возможность собрать необходимые ресурсы и бюджеты, составить подробный план, зафиксировать выполненные задачи, похвалить себя и свою команду, когда проект завершается вовремя и в рамках бюджета. В таком случае это не удивительно, что компании составляли масштабные планы проектов по управлению и трансформации своих процессов. На мой взгляд, здесь происходит глубокая проблема на уровни психологи управления – «Куда смотрим, туда и приедем», менеджер проекта концентрируется исключительно на метриках, описывающих ограничения, и не обращает внимания на момент ценности эксплуатации продукта проекта.
И поэтому традиционные подходы в управлении проектами обычно недостаточно для обеспечения сегодняшних потребностей в поставке программных продуктов, к примеру. Неподходящая управленческая модель и метод измерения могут пустить под откос даже стратегические проекты, которые отлично обеспечены ресурсами – Отслеживание действий и бюджетов даёт ощущение безопасности, которое может проявиться только тогда, когда программный продукт выйдет на рынок. Хуже того, предварительно принятые риски и расходы могут задержать команду в получении обратной связи по мере реализации проекта.
Мишель Шаттлворт управляющий директор в Deloitte Consulting LLP’s Delivery Innovation group – «Многие команды встроили в свою ДНК определённые способы работы, часто измеряя действия: проведение встреч, выполнение задач, создание поставок. Вместо того чтобы уделять должное внимание результатам. Управление продуктам меняет окно, через которое команда смотрит на свою работу. Пришло время изменить образ мышления и принять модели поведения и показатели, определяющие успех на основе результатов, которые часто определяют конечные пользователи продукта».
Многие организации осознают преимущества перехода к методологии управления продуктами для изменения стратегии разработки программного обеспечения. Управление продуктами побуждает организации измерять успех на основании ценности, которую их продукт приносит потребителям, а не на основе этапов, достигнутых в процессе создания реализации проекта. Подходы, которые включают в себя зонтик Agile, реагируют на обратную связь пользователей, на изменения рыночных условий. Поддерживают гибкость и промежуточные корректировки, вместо жёсткой привязки бюджетного и ресурсного плана к базовому плану проекта.
В приведённым выше примере страховой стартап, использующий продуктовый подход, вероятно, начал не с создания монолитного плана проекта, а с определения желаемых бизнес-результатов, таких как: увеличение числа пользователей приложения, определение целевых конверсий в платящего клиента. Руководители собрали кросс-функциональную команду разработчиков программного обеспечения, полностью посвятившую себя разработке продукта, запланировали более частые проверки прогресса, а также корректировали курс по ходу работы – и всё это за меньшую часть затрат чем у крупной организации.
Согласно Керстену, основные различия между ИТ-проектами и управлением продуктами заключается в следующем:
Управление проектам обычно распределяет финансирование в соответствии с этапами, зафиксированными во время определения объёма проекта (где-то в процессах: Планирование управление стоимостью, Оценка стоимости, Определение бюджета), а новый бюджет требует фактически создание нового плана проекта.
Управление продуктом основывается на бизнес-результатах с выделением новых денег по мере необходимости и на достижение дополнительных результатов.
Проекты обычно измеряются способностью выпустить поставку в срок и в рамках проектных ограничений, поэтому бизнес-заказчики вводят заранее свои требования, что обычно приводит к укрупнению проекта и увеличение его бюджета.
Продуктовый подход ориентирован на способность команды создать дополнительную ценность и достигнуть бизнес-целей, таких как создание программного продукта, приносящего ожидаемую прибыль.
В проектном подходе риск поставки продукта плохо соответствующему рынку наиболее вероятен, потому что спецификация продукта и стратегические решения формируются на старте (фиксируется базовым планом, а дальше отслеживаются метрики, как правила отклонения от базового плана. см «чёрный закон метрик»).
В продуктовом подходе риск распределяется на более длительный период и на несколько итераций, создавая возможность внести изменения в спецификацию продукта, если первоначальные предположения (о свойствах продукта) окажутся неверными или возникнут стратегические возможности.
Проектный подход распределяет ресурсы на раннем этапе, и люди часто работают над несколькими проектами одновременно с частым оттоком и переназначениями.
Продуктовый подход предполагает назначение кросс-функциональной команды на один продукт, это позволяет достичь большей стабильности и даёт возможность постепенно корректировать штатное расписание.
Проектный подход ориентирован на поставку по заранее согласованным требованиям (реализация плана).
Продуктовый подход основывается на дорожной карте, проверки гипотез с упором на функциональность ценность для бизнеса (реализация ценности).
Офис управления проектами навсегда может точно определить сложность решения с точки зрения бизнеса (нехватка бизнес-компетенций). В этом случае прогресс проекта становится чёрным ящиком уже для бизнеса (нехватка компетенций в ИТ).
Продуктовый подход помогает руководителям сопоставить выполненную работу с бизнес-результатом, что обеспечивает большую прозрачность (за счёт быстрых поставок работающих модулей и получения обратной связи от бизнеса).График
В проектном подходе есть зафиксированная дата окончания проекта. Уделяется мало внимания работоспособности продукта после завершения проекта.
Продуктовый подход делает упор на многолетний жизненный цикл продукта, включая текущее обслуживание и работу по улучшению. Т.е. эксплуатацию продукта, что полностью исключено в проектном подходе.
В сущности, все модели неправильны, но некоторые полезны. Выбирая подход, нужно учитывать контекст применения. Если контекст таков, что нужно отдать итог работы в строгом соответствии с документацией – проектный подход. Если итог работы ориентирован на открытый рынок – продуктовый подход. Выбор подхода, который позволяет вам приобрести больше, чем потерять, – есть вектор антихрупкости 🙂
Отслеживание действий, бюджетов, сроков даёт ощущение безопасности. Реагирование на обратную связь пользователей и на изменения в рыночных условиях даёт управляемость.
Керстен рекомендует предприятиям использовать более быстрые циклы обратной связи и структурировать свои подразделения в потоки создания ценности продуктов. «Поток создания ценности — это непрерывный поток информации, необходимый для предоставления ценности клиенту, и чем больше ценности передаётся клиенту, тем успешнее организация», — Керстен отмечая это, рекомендует направлять сотрудников только к одному потоку создания ценности зараз.
Организации могут измерить элементы потока на уровне бизнеса и соответствующим образом оптимизировать», — говорит Керстен. «Используя этот подход, команды могут перейти от мира, в котором в предварительном плане проекта всё указано, к бюджету разработки продукта, который позволяет перераспределять между потоками создания ценности и адаптироваться к тому, где лидеры видят бизнес-результаты».
Закончить хочу словами соотечественника. Андрей Губанов, «Спасибо от Сбербанка», Начальник отдела целевого маркетинга — «Мы не делаем готовый продукт, мы делаем управляемый продукт»