Подводные камни перехода из заказной разработки в продуктовую

Дмитрий Безуглый

Константин Бредюк

О докладчикахКонстантин Бредюк

• Менеджер продуктов в NetCracker Technology

• New Product Development Professional (NPDP) тест пройден

• Certified Scrum Product Owner (CSPO)

• Со-организатор Российского сообщества менеджеров программных продуктов swpm.ru

Дмитрий Безуглый

• Более 15-лет опыта участия в проектах по созданию, развитию, внедрению и эксплуатации различных информационных систем

• Max масштаб проекта 50 инженеров, около 30 чел-лет

• Max бюджет проекта 2,5 млн. долл.

• Max ROI проекта 400%

О чем будем сегодня говорить

1. Зачем переходить в продуктовую разработку2. Как переход видится не бумаге3. Какие ожидают овраги в реальности4. Как эти овраги обходить

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

Адаптировано из Википедии

Причины перехода в продуктовую разработку

1. Потенциал финансового успеха, не доступного в заказной разработке

2. Конкурентное преимущество на рынке3. Закрепление в рыночной нише

Потенциал финансового успеха

Заказная разработка

Решение(Solution)

$

Продуктовая разработка

Продукт

$

$

$

Время

$

Заказная разработка

Продуктовая разработка

Потенциал финансового успеха

Конкурентное преимуществоРешение (solution) на основе продукта будет дешевле для

заказчика, чем полностью заказная разработка

100% custom

Полностью заказное решение

20

%cu

stom

Решение на основе продукта

80% product

Закрепление в нише

1. Фиксация наработанной экспертизы и know how(на основе реализованных проектов)

2. Хороший маркетинговый мессадж (подтверждение экспертизы и намерений готовностью разрабатывать продукт)

Как переход видится на бумаге1. Собираем N реализованных заказных проектов в

один

2. В документации меняем «Компания ABC» на «Пользователь»

3. Сокращаем лишних разработчиков, аналитиков, саппорт («проект» теперь только один)

4. Продаем M раз одну и ту же систему

Продуктовая разработка

Заказная разработка

Бизнес-модель Разработка и продажа продуктов

Оказание услуг

Методология Управлениепродуктами

Управление проектами

Ключевая роль Менеджер продукта

Менеджер проекта

Природа внешних рисков

Рынок Заказчик

Какие ожидают овраги в реальности

1. Стратегические риски (источник - рынок)

2. Процессные проблемы (внутренние)

1. Управление требованиями и исследование рынка

2. Маркетинг и продвижение

3. Технологии и разработка

4. Операционная деятельность

РискиКак правило, компания-

вендор в случае наступления рискового события несет полную

финансовую ответственность

Продуктовая

разработкаЗаказная разработка

Как правило, компания-исполнитель несет финансовую ответственность только за невыполнение своих контрактных обязательств

Стратегические риски1. Продукт не будет отвечать потребностям рынка

(не «попадет» в рынок)

2. Структурные сдвиги в отрасли

3. Некорректная оценка объема целевого рынка

4. Появятся сильные конкуренты

5. «Продукт» не получится (останется кастомной разработкой)

Три картинки при внешние риски

Источник вдохновения – доклад Jeoffrey Moore на конференции Business of Software 2009

http://swpm.ru/2010/04/geoffrey-moore-strategy/

Непопадание в рынок

Конкурент 1

Конкурент 2

Потребитель 1

Потребитель 2

Мы

Структурные изменения

Конкурент 1

Конкурент 2

Потребитель 1

Потребитель 2

Мы

Структурные изменения

Конкурент 1

Конкурент 2

Потребитель 1

Потребитель 2

Мы

Переоценка размеров рынка

Конкурент 1

Конкурент 2

Потребитель 1

Потребитель 2

Мы

Переоценка размеров рынка

Мы

Источник внутренних проблем продуктовой разработки – применение методов

управления проектами к управлению продуктами

Жизненный цикл проекта и продукта

Продажа Разработка Сдача Поддержка

Отбор идей РазработкаВывод на

рынокУправление

на рынке

Цикл проекта заказной разработки

Цикл продукта

Особенности ЖЦ продукта

1. Сначала разработка, потом продажа

2. Ищем идею, а не берем задачу заказчика

3. Принимает не заказчик, а рынок

4. «Новая жизнь» на рынке, которая значительно отличается от поддержки в заказном проекте

5. Разработка: скорее R&d, чем r&D

Проблемы в управлении требованиями

1. Нет работы с рыночными требованиями2. Требования не агрегируются3. Не построена корректная система отбора фич4. Требования придумываются5. Отсутствие долгосрочных планов (Роадмап)6. Не берутся в расчет продукты конкурентов

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

Проблемы в продвижении и маркетинге

1. Старые каналы продаж2. Нет процесс запуска продукта (Product Launch)3. Старый «сервисный» месседжинг4. Процесс продажи на заточен под продукт

1. Нет системы прохождения демонстраций2. Нет системы прохождения PoC’ов3. Нет системы маркетинговой поддержки продажи продукта

Нет специфических для продажи продукта (product), а не услуги (service) активностей

Проблемы с технологиями и разработкой

1. Конфигурабельность уровня заказного решения2. Нет процесса продуктовых релизов, апдейтов, фиксов и

их доставки3. Отсутствие платформенной стратегии4. «Сервисный» подход к выбору технологии

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

проектное решение

Проблемы в операционной деятельности

1. Нет процесс New Product Development2. Нет системы кроссфункциональных команд для

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

3. Закисание специалистов (один и тот же большой проект)4. Не налажены взаимоотношения продукт - заказной

проект

Остались процессы, заточенные под разработку заказного ПО

Как эти овраги обходить

1. Методология управления продуктами вместо методологии управления проектами

2. Введение роли менеджера продуктов3. Привлечение соответствующих специалистов (в

зависимости от размера компании)4. Обучение сотрудников (линейных менеджеров

и топов)

Переход к продуктовой разработке - это хорошая бизнесовая возможность

НО

Связанная со значительными рисками и требующая применения других подходов к

организации деятельности компании

Вопросы

Спасибо!

Контакты:

Дмитрий Безуглый: bdl@system-approach.ru

Константин Бредюк: bredyuk@gmail.com

Software Product Management Russia: http://swpm.ru