Мы рассмотрим процесс перехода от заказной разработки к продуктовой модели, преимущества и возникающие при этом сложности. * Основной экономический фактор перехода – сокращение издержек за счет тиражируемого продукта. Изменение бизнес-модели, необходимость инвестиций, рыночные риски. * Создание тиражируемого продукта на базе существующих разработок для корпоративных заказчиков – наиболее естественный путь. Часто сложный процесс внедрения сдерживает полный переход к продуктовой модели. * Рыночное позиционирование продукта и управление требованиями. Две модели работы с рынком: pragmatic marketing и market development. * Перестройка корпоративной культуры. Ответственность владельца продукта. Почему внутренний заказчик продукта – плохая схема. Коммуникации с каналом продаж, маркетингом и поддержкой. Политическая воля менеджера продукта. * Необходимость автоматизации процессов разработки и поддержки. * Введение элементов платформенной функциональности в продукте и развитие партнерской экосистемы – перспективные направления рыночной экспансии.

1. Разработка тиражируемого продукта: преимущества бизнес-модели Георгий Баркан Руководитель направления технического развития пользовательских продуктов «Лаборатория Касперского» Минск, 19—20 мая 2011 года

2. Об авторе С 1995 года прошел путь от программиста и архитектора до руководителя проектов Заказные проекты для DEC, Compaq, Hewlett-Packard В QuestSoftwareреализация спец. проектов для PricewaterhouseCoopers,MerrillLynch,FidelityInvestments, MSN.com, CIBC, HSBC,Volkswagenи др. C 2010 года руководит разработкой технологической стратегии развития пользовательских продуктов «Лаборатории Касперского» NB!Доклад является отражением исключительно личного опыта и выражает точку зрения автора

3. Бизнес-модели Экономика заказной и тиражируемой разработки

4. Экономика:заказная разработка Суммарный функционал З2 З1 Общий функционал З3 Числозаказчиков Заказчик хочет решить все свои проблемы Затраты~ число заказчиков Выручка~ число заказчиков Прибыльность~ Const

5. Экономика:тиражируемая разработка V3 V2 V1 Затраты~ o(число клиентов) — растет, но медленно Выручка~ число клиентов Прибыльность — растет!

6. «Заказная разработка — это продажа мозгов в розницу по себестоимости,а тиражируемая — бизнес» Из заседанияАссоциации разработчиков программных продуктов«Отечественный софт»

7. Бизнес-модель Принципы: Нужен рынок Общность потребностей у клиентов Продажи двигает маркетинг Рост числа клиентов Продукты не живут вечно Риски: Рынок маленький Рынок слишком большой Конкуренция Скорость выхода на рынок

8. Трудности перехода От заказной к тиражируемой модели

11. Технологическая экспертиза?Учиться или искать извне Переход отзаказной разработки

12. Проблемы перехода Внедрение Продукт + заказнаяразработка Система уклиента Внедрение «съедает» ресурсы

13. В чем разница? Рекомендации по построению успешной тиражируемой разработки

15. Максимально детальная проработка, уточнение

16. Нужно застраховаться от изменений

18. Обобщать и пробовать (риск выше)

19. Нужен «портрет» клиента

20. Нельзя работать с командой в режиме заказчик—исполнитель

21. Миссия компании: ответ на вопрос «зачем?»Davis, 2005 Баркан, 2011

23. Индустриальный стандарт

24. Практические методологии

26. Итеративный подход

27. Проверка гипотез

28. Подгонка продукта и рынка друг другуNIHITO:Nothing Important Happens In The Office новый Функционал: существующий Wiki // Product management Pragmatic Marketing Wiki // Steven Gary Blank SlideShare // Pathfinder Software новые старые Клиенты:

31. Доверие команды

33. Правила игры Все решения принимает менеджер продукта (слово «стейкхолдер» запретить) С командой разработки общается только менеджер продукта (и эскалация поддержки) Продажи – ничего не обещать клиенту, продавать продукт «V.сегодня» Никогда не делаем заказных редакций продукта Внедрение договаривается с клиентом самостоятельно

34. Рекомендации Разработка Все технологические предложение обсуждаем Изучаем клиентов вместе Продажи Управлять ожиданиями клиентов Поддержка через службу поддержки Поддержка Все предложения обсуждаем (статистика) Внедрение Управлять ожиданиями клиентов Технологические предложения собираем, обобщаем и только потом обсуждаем

35. Менять: автоматизацияпроцессов разработки Requirements Management Source Control Build Automation Testing Automation Issue Tracking(Bugs + Change requests) Knowledge Base Зачем?Эффективность! Интегрировать Гусаров, 2011

36. Менять: поддержка Support Case Создает Issue Клиент Использует Solution Статистика Линия 1 Разработка Линия 2, …Эскалация …

38. API

40. Канал продаж1С-Битрикс

41. Итоги Трудности перехода Из-за «полутиражируемой» модели Новое Управление продуктом Менять Корпоративная культура Управление требованиями Процессы разработки (автоматизация) Процессы поддержки (эскалация) Рыночная экспансия Партнеры Платформа

42. Alan M. Davis. Just Enough Requirements Management: Where Software Development Meets Marketing. Dorset House, 2004. Георгий Баркан. Практика и чуть-чуть философии управления требованиями.Software People 2011.http://softwarepeople.ru/2011/programhttp://www.slideshare.net/gbarkan/ss-7559856 http://wikipedia.org/wiki/Product_management http://www.pragmaticmarketing.com http://wikipedia.org/wiki/Steven_Gary_Blank http://www.slideshare.net/pathf/product-management-throwdown-pragmatic-marketing-vs-customer-development Владимир Гусаров. Организация разработки коробочного продукта — от релиза до патча.Software People 2011.http://softwarepeople.ru/2011/program http://www.1c-bitrix.ru/partners http://ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html

43. How great leadersinspire action TED // Simon Sinek

44. Георгий Баркан Руководитель направления технического развития пользовательских продуктов «Лаборатория Касперского» http://twitter.com/gbarkan http://linkedin.com/in/gbarkan george_barkan@hotmail.com http://slideshare.net/gbarkan