• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Продуктсорсинг - меняем аутсорсинг или как вместе с заказчиком создавать классные продукты
 

Продуктсорсинг - меняем аутсорсинг или как вместе с заказчиком создавать классные продукты

on

  • 388 views

Презентация Дмитрия Лобасева. Конференция Software Project Management Conference-3.

Презентация Дмитрия Лобасева. Конференция Software Project Management Conference-3.
6 декабря 2013, Казань.
http://www.spmconf.ru

Statistics

Views

Total Views
388
Views on SlideShare
365
Embed Views
23

Actions

Likes
1
Downloads
3
Comments
0

2 Embeds 23

http://spmconf.ru 20
http://www.spmconf.ru 3

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Продуктсорсинг - меняем аутсорсинг или как вместе с заказчиком создавать классные продукты Продуктсорсинг - меняем аутсорсинг или как вместе с заказчиком создавать классные продукты Presentation Transcript

    • Продуктсорсинг - как вместе с заказчиком создавать классные продукты Дмитрий Лобасев Enterprise Agile Coach ScrumTrek
    • Дмитрий Лобасев • Enterprise Agile Coach, ScrumTrek • Background – – – – Разработчик Тимлид Менеджер Архитектор процессов
    • Развитие моделей аутсорсинга (с точки зрения выполнения проектов)
    • 199x - Водопад
    • Цикл боли заказчика Сделайте мне так, чтобы.. Обрабатываем запросы на изменения Анализируем, Мы выкатываем.. как есть Заказчик подписывается Заказчик принимает.. как есть Проектируем Мы делаем
    • Пример из жизни • Очень известный банк и очень крупная компания-аутсорсер. Лето 2013 • «Проблема обновления статусов .. дефектом, с точки зрения разработчиков, не является, поскольку нет противоречий требованиям» • «Разработчик не считает проблемы при использовании cmd+V в Safari дефектом, поскольку не было прописано требований к работе cmd+V»
    • Почему так происходит?
    • Почему так происходит? IKIWISI I Know It When I See It ..пока мы фокусируемся на выполнении проекта в срок..
    • Корень зла • Мы полностью проектируем и описываем будущий продукт в самом начале.. – Хотя бизнес никогда не знает в самом начале, какой именно продукт он хочет получить • Заказчики отлично понимают свой бизнес – Но они не умеют проектировать программное обеспечение • Мы фокусируемся на выполнении проекта, а не на разработке продукта
    • КАК ЭТО ИСПРАВИТЬ?
    • 200х - Agile!!!!111
    • Пример фейла true agile команды • Выбрали минимальный срез продукта для первого релиза – Работает настоящая agile-команда • Получаем хороший фидбек на еженедельных демо – Действительно важные вещи, заказчик говорит брать в работу • Заказчик руководит приоритетами и скоупом, очень доволен! • Запланированные сроки релиза прошли.. – Но мы же не делаем ничего лишнего, все фичи необходимы! • И тут конец финансового года, ревью бюджета.. – Заказчик оказывается и не получил никакого результата с точки зрения ROI..
    • Еще один пример – что здесь не так?
    • Как насчет пользователей? IKIWIEI I Know It When I Experience It ..пока мы фокусируемся на обратной связи от заказчика..
    • Корень зла • Мы опять спроектировали продукт заранее – Хоть и реализуем его итеративноинкрементально • Мы фокусируемся на разработке продукта на основе обратной связи от заказчика, а не от будущих конечных пользователей
    • ДОЛЖНО ЖЕ БЫТЬ ЧТО-ТО ЕЩЕ?
    • 201x - Lean Startup
    • А в чем разница? Agile Lean Startup • Мы считаем, что нам неизвестно решение • .. Мы даже не знаем исходной проблемы • Инкремент – недели • Инкремент – часы • Фидбек заказчика на демо • Поведение пользователей в продакшн • Цель – готовый к поставке продукт • Цель – провалидировать гипотезу и научиться • Фокус на обратной связи от заказчика • Фокус на бизнес-метриках
    • CO-CREATION – СОВМЕСТНЫЙ ПРОЦЕСС ПРОЕКТИРОВАНИЯ ПРОДУКТА
    • Формирование гипотез • Берем всю команду и на неделю к заказчику • Проектируем бизнес-модель продукта с учетом мнений и идей каждого • Получаем гипотезы, нужно провалидировать • Цель – проверить наши предположения на реальных пользователях, не написав ни строчки кода
    • Валидация через общение • Интервьюирование будущих пользователей • Подтверждение или опровержение гипотез • Формирование новых • Цель – проверить как можно больше наших предположений в единицу времени
    • Валидация через деливери • На словах ок, пора переходить к делу • True Agile – Scrum – Kanban – WHAT EVER YOU WANT • Непрерывная поставка конечным пользователям – Начинаем с инноваторов, потом остальные – Все время собираем обратную связь (общение + продуктовые метрики)
    • Бизнес-метрики как подтверждение создания правильного продукта!
    • Модель продуктсорсинга • Заказной продукт – наш стартап – Команда на фултайм – Проектируем продукт совместно с заказчиком – Ориентируемся на результат через бизнес-метрики • Пользователи • Деньги • И т.п. в зависимости от продукта • Заказчик – наш инвестор – Который ждет окупаемости
    • ПРИМЕР РАЗВОРОТА КОНЦЕПЦИИ
    • Минимальная версия продукта
    • Первый change request через три недели :)
    • СПАСИБО!