Еще одна задача проджект-раннера – быть инициатором проекта. Ключевое различие между раннером и менеджером продукта в том, что раннер нацелен на создание нового продукта, а менеджер – на развитие существующего. Раннера интересует принципиальная схема решения, а менеджера – метрики для оценки эффективности продукта.
Когда продукт уже существует и команда работает над его развитием, многие вопросы не стоят так остро. Но если мы говорим о создании новых продуктов, к тому же инновационных, то чаще всего нет даже команды. Поэтому у менеджера в распоряжении уже готовая проектная инфраструктура, а раннер должен все создать с нуля. Это похоже на предпринимательский подход, требует самостоятельности, полномочий, ответственности и разных компетенций.
Логично, что первая необходимая компетенция проджект-раннера – умение «собирать» проект целиком, формируя команду и необходимую проектную инфраструктуру. Выполнить это можно только опираясь на технологию. В «Методе параноика» это технология продуктовой разработки.
Процесс похож на производство автомобилей: сначала строится конвейер, обучается персонал, а затем детали постепенно превращаются в готовую продукцию. Так и идеи по устройству будущего цифрового продукта проходят разные стадии, трансформируются из гипотез в проверенные решения, чтобы в конечном счете собраться в виде действующего сайта, сервиса или мобильного приложения.
В технологии продуктовой разработки функцию конвейера выполняет воронка неопределенности – базовый фреймворк, задающий общие принципы работы и стадии проекта. Следующий аспект технологии – модель продукта, в которую складываются все продуктовые решения, включая структуру проектной документации, форматы артефактов и инструменты проектирования. Дальше необходимо разобраться с требованиями к участникам проектной команды, их функциями и с подходами к управлению. Последняя часть – методика оценки и планирования работ. Технология нацелена на работу в условиях высокой неопределенности, обычные методы тут неприменимы.
Получается четыре обязательных компонента технологии, без которых невозможно выстроить работу проектного офиса или отдельного проекта, получая на выходе цифровые продукты с предсказуемым качеством и в границах доступных сроков и бюджета:
• воронка неопределенности и стадии проекта;
• модель продукта и проектирование;
• проектная команда и управление;
• оценка и планирование работ.
Полное описание технологии продуктовой разработки по «Методу параноика» – это тема отдельной книги. Здесь я дам вводные по каждому компоненту, чтобы у вас было общее представление как происходит переход от методологии к ее практическому использованию. Каждому компоненту посвящен отдельный раздел, но я начну с высокоуровневого вопроса: «Для каких задач требуется такая технология?»
Области применения технологии
Цифровые продукты не имеют самостоятельной ценности. Их смысл и значение проявляются только в рамках задач, для которых они создаются. Задачи могут быть разными, но с точки зрения бизнеса есть два варианта: зарабатывать на разработке или на использовании продукта в другой деятельности.
Заказная разработка
Первый вариант – заказная или аутсорсинговая разработка. Ваш бизнес строится на решении тех задач, с которыми ваш клиент не может справиться самостоятельно. Прежде всего это управление проектной работой, проектирование, дизайн, программирование, тестирование, развертывание и поддержка продукта. Все это может выполняться комплексно либо от вас потребуется только часть из общего списка. Ваша ключевая метрика эффективности – какую добавочную стоимость удается получить с каждого специалиста.
Знание предметной области заказчика важно, но ваша истинная цель – удовлетворить ожидания клиента. Как ни странно, иногда реальная полезность продукта не так важна, ведь даже заказчик может не знать, что ему нужно. Зато люди, которые с его стороны отвечают за проект, имеют свои критерии успеха. Например, им должен нравиться дизайн, бюджет и сроки должны остаться в оговоренных рамках, или с вами просто должно быть удобно и приятно работать.
Чем больше размер компании, тем меньше можно увидеть связь функциональных качеств продукта и коммерческих результатов от его использования. Для малого и среднего бизнеса это имеет значение, они нацелены на развитие, и каждая «фича» рассматривается как возможный конкурентный рычаг. В корпорациях все несколько иначе. Там акцент на удержании своего рынка, а значит важна предсказуемость. Ваши услуги могут быть дороже, но если вы гарантируете надежность продукта, выберут вас.
Внутреннее использование продуктов
Второй вариант – создание цифровых продуктов для внутреннего использования, чтобы усилить или изменить бизнес-модель. Неважно, будут использовать конкретный продукт сотрудники или клиенты компании. Его ценность определяется экономическим или другим эффектом, например, маркетинговым, который он приносит на вложенные в его разработку средства.
Ключевая компетенция бизнеса – найти принципиальную схему решения и сформулировать требования к продукту. Управление проектом по его созданию может быть как внутри собственной команды, так и на стороне подрядчиков. Если продукт критически важен для бизнеса, большинство продуктовых и проектных компетенций должно быть внутри. Часто достаточно небольшой команды во главе с проджект-раннером, который привлекает внешние команды и координирует их работу.
Здесь лучше всего проявляется разница между проектным и продуктовым подходом. Первый характерен для задач с ясным конечным результатом, когда нужно, например, получить первую версию цифрового продукта. В этом случае хорошо себя проявляют внешние аутсорсинговые компании, ориентированные на проектный формат работы. Но для дальнейшего развития продукта с учетом регулярных изменений в бизнесе нужна постоянная вовлеченность команды. Она должна накапливать знания, понимать внутреннюю специфику бизнеса и измерять свой успех через эффективность продукта. Такое можно ожидать только от собственных специалистов, работающих в рамках продуктового подхода.
Тиражируемые продукты
Помимо создания цифровых продуктов на заказ и для внутреннего использования, существует третий вариант – разработка тиражируемых продуктов. Они могут поставляться как онлайн-сервисы, мобильные приложения или ПО для установки у клиента. Может показаться, что между тиражируемыми и продуктами, разработанными на заказ, есть сходство. Но это не так. Заказной продукт всегда создается под индивидуальные требования клиента, а тиражируемый воплощает в себе обобщенные представления о решении пользовательской или бизнес-задачи. Добиться такой универсальности крайне сложно.
Бюджет на создание тиражируемого продукта значительно выше стоимости обычной заказной разработки. И это не учитывая затрат на маркетинг и продвижение, часто многократно превышающих расходы на создание самого продукта. Очевидно, что преуспеть в таком бизнесе можно только за счет масштабирования продаж – либо доминируя в рыночной нише, когда ваш продукт считается отраслевым стандартом, либо адаптируя одно и то же решение под задачи в разных отраслях.
Давайте зададимся вопросом, в чем ценность тиражируемого цифрового продукта для конечных потребителей, особенно бизнес-систем? Прежде всего, их можно использовать сразу, и не тратить драгоценное время на самостоятельную разработку. Клиент фактически покупает себе время. Но дело не только в этом. Самый сложный вопрос в проектной работе: «Каким продукт должен быть?» С четко поставленной задачей выполнить разработку не так сложно, как сформулировать, ответив на тысячи разных вопросов при проектировании. Интересно, что ответы часто лежат вне области технических решений и связаны с прикладной сферой применения продукта. Таким образом, компания, покупающая тиражируемый цифровой продукт, приобретает отраслевой опыт, который «зашит» в продукт. Если его внедрение сопровождается консалтингом по оптимизации бизнес-процессов компании, то истинная ценность продукта еще больше проявляется в этом. Правильный подход к бизнес-консалтингу может приносить гораздо больше прибыли, к тому же подкрепленный комплементарным продуктом, чем просто продажа технического решения.
Индивидуальная настройка технологии
В каждом описанном варианте создаются цифровые продукты, но технология их разработки будет отличаться во всех четырех компонентах: стадиях проекта в рамках воронки неопределенности, подходах к проектированию модели продукта, требованиях к участникам команды, способах оценки и планирования работ. Требуется индивидуальная настройка технологии продуктовой разработки в зависимости от области ее применения.
Это связано с разными целями. Заказная разработка ориентирована на максимальную эффективность команды, которая должна выдать результат в ограниченные сроки. Создание продуктов для внутреннего использования направлено на отдачу в самом бизнесе и часто имеет длинный «хвост» доработок и обновлений. Тиражируемые цифровые продукты должны удовлетворять потребностям широкой аудитории, что требует особого подхода к поиску и тестированию новых функций.
Отдельно хочу сказать про технологические стартапы. Они могут относиться к каждой из перечисленных категорий, но от обычных компаний их отличает нацеленность на поиск новой бизнес-модели и связанный с этим уровень неопределенности. Поэтому контроль неопределенности, который встроен в технологию продуктовой разработки по «Методу параноика», требует в стартапах еще большей «паранойи».
При использовании технологии для создания цифровых продуктов нужно понимать, что ее базовая версия «из коробки» будет выдавать усредненный результат. Чтобы получить максимум, потребуется тонкая настройка всех компонентов. Дальше я расскажу о каждом из них и покажу, на что необходимо обратить внимание. При этом хочу напомнить, что подробному описанию технологии посвящена отдельная книга – «Черная».