Разработка тиражируемого продукта: преимущества бизнес-модели
Георгий Баркан
Руководитель направления технического развития пользовательских продуктов
«Лаборатория Касперского»
Минск, 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. Продукты не живут вечно Риски: 1. Рынок маленький 2. Рынок слишком большой 3. Конкуренция 4. Скорость выхода на рынок
ТРУДНОСТИ ПЕРЕХОДА
От заказной к тиражируемой модели
Продукт
Заказные решения для корпоративных клиентов
• Уже есть экспертиза в предметной области
• Есть готовые решения, но нужно обобщать — в продукт попадет малая часть
Outsourcing • Фокус на предметную
область? • Технологическая экспертиза?
Проще
Сложнее
Можно создать продуктовую команду
Учиться или искать извне
Переход от заказной разработки
Продукт
Система у клиента
Внедрение
+ заказная разработка
Внедрение «съедает» ресурсы
Проблемы перехода
В ЧЕМ РАЗНИЦА?
Рекомендации по построению успешной тиражируемой разработки
Менять: управление требованиями
Заказчик • Выявить потребности • Максимально детальная
проработка, уточнение • Нужно застраховаться от
изменений • «Мы и они»
Продукт • «Придумать» потребности • Обобщать и пробовать (риск
выше) • Нужен «портрет» клиента • Нельзя работать с командой
в режиме заказчик—исполнитель
• Миссия компании: ответ на вопрос «зачем?»
1) Davis, 2005 2) Баркан, 2011
Новое: управление продуктом
Pragmatic Marketing • Для существующих
продуктов и рынков • Индустриальный стандарт • Практические методологии • «Количественный
маркетинг»
Customer Development • Для новых идей и
рыночной экспансии • Итеративный подход • Проверка гипотез • Подгонка продукта и рынка
друг другу
NIHITO: Nothing Important Happens In The Office
Фун
кци
он
ал:
новый
существующий
новые старые Клиенты:
3) Wiki // Product management 4) Pragmatic Marketing 5) Wiki // Steven Gary Blank 6) 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 leaders inspire action
9) TED // Simon Sinek
«Как?»
«Что?»
«Зачем?»
Георгий Баркан
Руководитель направления технического развития пользовательских продуктов
«Лаборатория Касперского»
http://twitter.com/gbarkan
http://linkedin.com/in/gbarkan
http://slideshare.net/gbarkan