Разработка тиражируемого продукта: преимущества...
DESCRIPTION
Мы рассмотрим процесс перехода от заказной разработки к продуктовой модели, преимущества и возникающие при этом сложности. * Основной экономический фактор перехода – сокращение издержек за счет тиражируемого продукта. Изменение бизнес-модели, необходимость инвестиций, рыночные риски. * Создание тиражируемого продукта на базе существующих разработок для корпоративных заказчиков – наиболее естественный путь. Часто сложный процесс внедрения сдерживает полный переход к продуктовой модели. * Рыночное позиционирование продукта и управление требованиями. Две модели работы с рынком: pragmatic marketing и market development. * Перестройка корпоративной культуры. Ответственность владельца продукта. Почему внутренний заказчик продукта – плохая схема. Коммуникации с каналом продаж, маркетингом и поддержкой. Политическая воля менеджера продукта. * Необходимость автоматизации процессов разработки и поддержки. * Введение элементов платформенной функциональности в продукте и развитие партнерской экосистемы – перспективные направления рыночной экспансии.TRANSCRIPT
Разработка тиражируемого продукта: преимущества бизнес-модели
Георгий БарканРуководитель направления технического развития пользовательских продуктов«Лаборатория Касперского»
Минск, 19—20 мая 2011 года
Об авторе
• С 1995 года прошел путь от программиста и архитектора до руководителя проектов
• Заказные проекты для DEC, Compaq, Hewlett-Packard• В Quest Software реализация спец. проектов для
PricewaterhouseCoopers, Merrill Lynch, Fidelity Investments, MSN.com, CIBC, HSBC, Volkswagen и др.
• C 2010 года руководит разработкой технологической стратегии развития пользовательских продуктов «Лаборатории Касперского»
• NB! Доклад является отражением исключительно личного опыта и выражает точку зрения автора
БИЗНЕС-МОДЕЛИЭкономика заказной и тиражируемой разработки
Экономика:заказная разработка
Заказчик хочет решить все свои проблемы
Затраты ~ число заказчиковВыручка ~ число заказчиковПрибыльность ~ Const
З1
З2
З3 Числозаказчиков
Суммарный функционал
Общий функционал
Экономика:тиражируемая разработка
V1
V2
V3
Затраты ~ o(число клиентов) — растет, но медленно
Выручка ~ число клиентовПрибыльность — растет!
«Заказная разработка — это продажа мозгов в розницу по себестоимости,а тиражируемая — бизнес»
Из заседанияАссоциации разработчиков
программных продуктов«Отечественный софт»
Бизнес-модельПринципы:1. Нужен рынок2. Общность потребностей у клиентов3. Продажи двигает маркетинг4. Рост числа клиентов5. Продукты не живут вечно
Риски:6. Рынок маленький7. Рынок слишком большой8. Конкуренция9. Скорость выхода на рынок
ТРУДНОСТИ ПЕРЕХОДАОт заказной к тиражируемой модели
Продукт
Заказные решения для корпоративных клиентов
• Уже есть экспертиза в предметной области
• Есть готовые решения, но нужно обобщать —в продукт попадет малая часть
Outsourcing• Фокус на предметную
область?• Технологическая экспертиза?
Проще
Сложнее
Можно создать продуктовую команду
Учиться или искать извне
Переход отзаказной разработки
Продукт
Система уклиента
Внедрение
+ заказнаяразработка
Внедрение «съедает» ресурсы
Проблемы перехода
В ЧЕМ РАЗНИЦА?
Рекомендации по построению успешной тиражируемой разработки
Менять:управление требованиями
Заказчик• Выявить потребности• Максимально детальная
проработка, уточнение• Нужно застраховаться от
изменений• «Мы и они»
Продукт• «Придумать» потребности• Обобщать и пробовать (риск
выше)• Нужен «портрет» клиента• Нельзя работать с командой
в режиме заказчик—исполнитель
• Миссия компании: ответ на вопрос «зачем?»
1) Davis, 20052) Баркан, 2011
Новое:управление продуктом
Pragmatic Marketing• Для существующих
продуктов и рынков• Индустриальный стандарт• Практические методологии• «Количественный
маркетинг»
Customer Development• Для новых идей и
рыночной экспансии• Итеративный подход• Проверка гипотез• Подгонка продукта и рынка
друг другу
NIHITO:Nothing Important Happens In The Office
Фун
кцио
нал:
новый
существующий
новыестарыеКлиенты:
3) Wiki // Product management4) Pragmatic Marketing5) Wiki // Steven Gary Blank6) SlideShare // Pathfinder Software
Владелецпродукта
Менять:корпоративная культура
Ответственность за успех• Нужно принимать решения• Нужна политическая воля
Для разработкиБыть не заказчиком, а владельцем, менеджером:• Интересы развития продукта• Доверие команды• Эффективность разработки
Для продажСоздавать модель работы на рынке
Клиент
Продажи
Маркетинг
Менеджер продукта
Разработка
Внедре-ние
Управляет
ПомогаетСтавитзадачу
ЭскалацияИзучает
Поддержка
(Налаживает)(Контролирует)
Строитпартнерство
Обеспечивает
Взаимодействие
Правила игры
1. Все решения принимает менеджер продукта (слово «стейкхолдер» запретить)
2. С командой разработки общается только менеджер продукта (и эскалация поддержки)
3. Продажи – ничего не обещать клиенту, продавать продукт «V.сегодня»
4. Никогда не делаем заказных редакций продукта5. Внедрение договаривается с клиентом
самостоятельно
Рекомендации• Разработка– Все технологические предложение обсуждаем– Изучаем клиентов вместе
• Продажи– Управлять ожиданиями клиентов– Поддержка через службу поддержки
• Поддержка– Все предложения обсуждаем (статистика)
• Внедрение– Управлять ожиданиями клиентов– Технологические предложения собираем, обобщаем и
только потом обсуждаем
Менять: автоматизацияпроцессов разработки
• Requirements Management• Source Control• Build Automation• Testing Automation• Issue Tracking
(Bugs + Change requests)• Knowledge Base
Зачем? Эффективность!
Инте
грир
оват
ь
7) Гусаров, 2011
Статистика
Клиент
Линия 1 РазработкаЛиния 2, …Эскалация
…
IssueСоздает
Solution
Использует
Support Case
Менять: поддержка
Экосистема партнеров
Продукт
Рынок
ЭкспансияЭкспансия
Продукт
Внедрение
Продукт
ВнедрениеПлатформа
• SDK• API• Документация
• Внедрения• Канал продаж
Платформа и партнеры
8) 1С-Битрикс
Итоги• Трудности перехода– Из-за «полутиражируемой» модели
• Новое– Управление продуктом
• Менять– Корпоративная культура– Управление требованиями– Процессы разработки (автоматизация)– Процессы поддержки (эскалация)
• Рыночная экспансия– Партнеры– Платформа
1) Alan M. Davis. Just Enough Requirements Management: Where Software Development Meets Marketing. Dorset House, 2004.
2) Георгий Баркан. Практика и чуть-чуть философии управления требованиями. Software People 2011.http://softwarepeople.ru/2011/program http://www.slideshare.net/gbarkan/ss-7559856
3) http://wikipedia.org/wiki/Product_management 4) http://www.pragmaticmarketing.com 5) http://wikipedia.org/wiki/Steven_Gary_Blank 6) http://
www.slideshare.net/pathf/product-management-throwdown-pragmatic-marketing-vs-customer-development
7) Владимир Гусаров. Организация разработки коробочного продукта — от релиза до патча. Software People 2011.http://softwarepeople.ru/2011/program
8) http://www.1c-bitrix.ru/partners 9) http://ted.com/talks/simon_sinek_how_great_leaders_
inspire_action.html
How great leadersinspire action
9) TED // Simon Sinek
«Как?»
«Что?»
«Зачем?»
Георгий БарканРуководитель направления технического развития пользовательских продуктов«Лаборатория Касперского»
http://twitter.com/gbarkan http://linkedin.com/in/gbarkan [email protected] http://slideshare.net/gbarkan