1.
Продуктсорсинг - как вместе с
заказчиком создавать классные
продукты
Дмитрий Лобасев
Enterprise Agile Coach
ScrumTrek

2.
Дмитрий Лобасев
• Enterprise Agile Coach,
ScrumTrek
• Background
–
–
–
–
Разработчик
Тимлид
Менеджер
Архитектор процессов

3.
Развитие моделей аутсорсинга
(с точки зрения выполнения проектов)

4.
199x - Водопад

5.
Цикл боли заказчика
Сделайте мне
так, чтобы..
Обрабатываем
запросы на
изменения
Анализируем,
Мы выкатываем..
как есть
Заказчик
подписывается
Заказчик
принимает.. как
есть
Проектируем
Мы делаем

6.
Пример из жизни
• Очень известный банк и очень крупная
компания-аутсорсер. Лето 2013
• «Проблема обновления статусов .. дефектом, с
точки зрения разработчиков, не является,
поскольку нет противоречий требованиям»
• «Разработчик не считает проблемы при
использовании cmd+V в Safari дефектом,
поскольку не было прописано требований к
работе cmd+V»

7.
Почему так происходит?

8.
Почему так происходит?
IKIWISI
I Know It When I See It
..пока мы фокусируемся на
выполнении проекта в срок..

9.
Корень зла
• Мы полностью проектируем и описываем
будущий продукт в самом начале..
– Хотя бизнес никогда не знает в самом начале,
какой именно продукт он хочет получить
• Заказчики отлично понимают свой бизнес
– Но они не умеют проектировать программное
обеспечение
• Мы фокусируемся на выполнении проекта, а
не на разработке продукта

10.
КАК ЭТО ИСПРАВИТЬ?

11.
200х - Agile!!!!111

12.
Пример фейла true agile команды
• Выбрали минимальный срез продукта для первого релиза
– Работает настоящая agile-команда
• Получаем хороший фидбек на еженедельных демо
– Действительно важные вещи, заказчик говорит брать в работу
• Заказчик руководит приоритетами и скоупом, очень доволен!
• Запланированные сроки релиза прошли..
– Но мы же не делаем ничего лишнего, все фичи необходимы!
• И тут конец финансового года, ревью бюджета..
– Заказчик оказывается и не получил никакого результата с точки
зрения ROI..

13.
Еще один пример – что здесь не так?

14.
Как насчет пользователей?
IKIWIEI
I Know It When I
Experience It
..пока мы фокусируемся на
обратной связи от заказчика..

15.
Корень зла
• Мы опять спроектировали продукт заранее
– Хоть и реализуем его итеративноинкрементально
• Мы фокусируемся на разработке продукта
на основе обратной связи от заказчика, а
не от будущих конечных пользователей

16.
ДОЛЖНО ЖЕ БЫТЬ ЧТО-ТО ЕЩЕ?

17.
201x - Lean Startup

18.
А в чем разница?
Agile
Lean Startup
• Мы считаем, что нам
неизвестно решение
• .. Мы даже не знаем исходной
проблемы
• Инкремент – недели
• Инкремент – часы
• Фидбек заказчика на демо
• Поведение пользователей в
продакшн
• Цель – готовый к поставке
продукт
• Цель – провалидировать
гипотезу и научиться
• Фокус на обратной связи от
заказчика
• Фокус на бизнес-метриках

19.
CO-CREATION – СОВМЕСТНЫЙ
ПРОЦЕСС ПРОЕКТИРОВАНИЯ
ПРОДУКТА

20.
Формирование гипотез
• Берем всю команду и на неделю к заказчику
• Проектируем бизнес-модель продукта с
учетом мнений и идей каждого
• Получаем гипотезы, нужно провалидировать
• Цель – проверить наши предположения на
реальных пользователях, не написав ни
строчки кода

21.
Валидация через общение
• Интервьюирование будущих пользователей
• Подтверждение или опровержение гипотез
• Формирование новых
• Цель – проверить как можно больше наших
предположений в единицу времени

22.
Валидация через деливери
• На словах ок, пора переходить к делу
• True Agile – Scrum – Kanban – WHAT EVER YOU
WANT
• Непрерывная поставка конечным
пользователям
– Начинаем с инноваторов, потом остальные
– Все время собираем обратную связь (общение +
продуктовые метрики)

23.
Бизнес-метрики как подтверждение
создания правильного продукта!

24.
Модель продуктсорсинга
• Заказной продукт – наш стартап
– Команда на фултайм
– Проектируем продукт совместно с заказчиком
– Ориентируемся на результат через бизнес-метрики
• Пользователи
• Деньги
• И т.п. в зависимости от продукта
• Заказчик – наш инвестор
– Который ждет окупаемости

25.
ПРИМЕР РАЗВОРОТА КОНЦЕПЦИИ

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

27.
Первый change request через три
недели :)

28.
СПАСИБО!