Uploaded byAlexander Byndyu
Как перейти от проектного мышления к продуктовому. Опыт из заказной разработки
Документ представляет собой обзор перехода от проектного мышления к продуктовому подходу в области IT и заказной разработки, выделяя важность гибкой культуры и кросс-функциональных команд. Основное внимание уделяется инструментам и методам, необходимым для успешного внедрения продуктового подхода, включая взаимодействие с клиентами и использование метрик для оценки результата. Также поднимаются проблемы и препятствия, которые могут возникнуть в процессе перехода, такие как необходимость изменения структуры компании и подхода к работе.
More Related Content
Similar to Как перейти от проектного мышления к продуктовому. Опыт из заказной разработки
Как перейти от проектного мышления к продуктовому. Опыт из заказной разработки
- 1. Как перейти отпроектного мышления к продуктовому Опыт заказной разработки Александр Бындю CEO IT-архитектор Byndyusoft
- 2. Александр Бындю Эксперт вAgile и Lean · IT-архитектор CEO в http://byndyusoft.com Преподаю в университете Веду блог http://blog.byndyu.ru В прошлом: • Тренер в ScrumTrek • Вожатый на AgileCamp • IT-директор • Программист
- 3.
- 4. Конкуренты тоже научились покупатьдешевле и продавать дороже.
- 5.
- 6. ПРОЕКТНАЯ КУЛЬТУРА Сделать продуктправильно ПРОДУКТОВАЯ КУЛЬТУРА Сделать правильный продукт
- 7.
- 8. Как сохранить гибкостьбизнеса - Асхат Уразбаев https://www.youtube.com/watch?v=wAH92qJqvQQ Мы работаем на первых двух стадиях
- 9. Agile Everywhere! -Henrik Kniberg https://www.youtube.com/watch?v=moKG0RQNiqM Работаем в самом красном углу
- 10.
- 11. Компания заказчика Нашакоманда CEO CTO C Внутренниекоманды Устоявшиеся процессы Инфраструктура Знания о бизнесе Мыучаствуемкак: ·Product Owner ·IT-Архитектор ·Team lead
- 12. 1. Бежать вавангарде интересно и романтично 2. Прибыльно 3. Рост компетенций
- 13. 1. Высокая неопределенность задач 2.Участие в перестроении заказчика, иначе нет результата 3. Бороться с негативом во время перестройки
- 14. 1. Высокая неопределенность задач 2.Участие в перестроении заказчика, иначе нет результата 3. Бороться с негативом во время перестройки
- 15.
- 16. 1. Подходы иинструменты
- 17. Приходят с решениями Кнопочноемышление против целостного IT- продукта
- 18. Зачем? Кто? Корневая проблема илипотребность Решение1 Решение2 Решение3 Решение4 Решение5? Решение6 Решение7 … РешениеN Приходите с проблемами
- 19. Идите в поле! Почемуне идут: 1. Долго и дорого 2. Раньше брали в работу всё, что в голову придёт 3. Раньше галлюцинировали, теперь надо идти и общаться 4. Теряется самоуверенность, всё стало гипотезой 5. Нет навыков общения с клиентами
- 20.
- 21.
- 22.
- 23. Карта пользовательских историй Пятьсамых важных составляющих процесса выпуска успешных проектов Я как корпоративный клиент Не понимаю в каком состоянии счет и из-за этого ухожу в минус Хочу останавливать работу, если баланс стал критично низким Чтобы не терять деньги
- 24. Почему с картамисложно Приходится больше общаться Требуется глубокое вовлечение, не получится прочитать в конце Идеи и план прозрачны, не получится бездельничать Карты постоянно меняются Аналитика IT-продукта https://byndyusoft.com/productanalysis
- 25. Metrics-Driven Development Проблемы привнедрении: 1. Измеряем, что проще измерить 2. Метрики не связаны с бизнесом 3. Посчитать — значит сделать прозрачным 4. Оказывается, что крутые идеи не всегда изменяют
- 26. 1. Найти данныеи получить к ним доступ • Данные разбросаны по базам данных, сторонним сервисам, файлам и головам сотрудников • Данных нет и в прошлое за ними не вернуться • Проблема получать доступ к ком. тайне и персональным данным 2. Систематизировать, удалить мусор • Данные неполные • Одни и те же данные в разных местах представлены по-разному • Разные погрешности в разных системах 3. Извлекать информацию • Неожиданно самая простая часть работы, менее 10% времени • Простой анализ • Machine learning для более сложных задач 4. Наладить постоянную подкачку новых данных • Создать хранилища • Установить новые процессы и регламенты • Проблема с назначением ответственных Непрерывная добыча данных
- 27.
- 28. 2. Люди и«гибкая» культура
- 29. Проблемы взаимодействия междуотделами: 1. Накладные расходы на постановку и приемку задач 2. Сложно согласовывать «ресурсы» между иерархиями 3. Реализация не лучшая для продукта, а описанная при постановке 4. Исполнитель ошибается, принимая решения, потому что не видит всей картины 5. Медленная обратная связь Проект логистики Спец. по логистике PHP-программист Отдел логистики Отдел веб- разработки Сис. админ Отдел сопровождения Маркетолог Отдел маркетинга
- 30. Единая команда продукта: 1.Единыезнания о продукте, рынке и истории развития 2.Сделает продукт от начала до конца 3.Нет накладных расходов по передаче задач или знаний DevOps Маркетолог Спец. по логистике PHP-программист Кросс-функциональная команда продукта Продукт для логистики Product Owner ?? ?
- 31. Agile Product Ownershipin a Nutshell https://www.youtube.com/watch?v=502ILHjX9EE Проблемы с PO: 1. Его нет 2. Огромная проблема его найти 3. Часто из операционного руководителя делают PO, а это ошибка Product Owner Выбор метрик Исследование рынка Вдохновляет Походы в поле Видение продукта Измеритель ценности
- 32. Теперь можно резать• FFF Чтобы выбрать следующий шаг для создания правильного продукта: 1. Балансируем приоритет, риски и ценность 2. Решение принимает продуктовая команда
- 33. Как внедрить «гибкую»культуру? 1. Изменяем структуру 2. Изменяем процессы 3. Культура начинает медленно меняться
- 34. ПРОЕКТНАЯ КУЛЬТУРА Сделать продуктправильно ПРОДУКТОВАЯ КУЛЬТУРА Сделать правильный продукт
- 35. ВАША КОМПАНИЯ ВАШИКОНКУРЕНТЫvs ПРОЕКТНАЯ КУЛЬТУРА Сделать продукт правильно ПРОДУКТОВАЯ КУЛЬТУРА Сделать правильный продукт
- 36. Качественная реализация поставленных задач в сроки бюджет Поставка ценности потребителю продукта Цель
- 37. Временно, пока идет проект Навсё время жизни продукта Граница работы
- 38.
- 39.
- 40.
- 41.
- 42.
- 43. Обсуждается и изучается науровень выше Обсуждается и изучается командой продукта Ценность для потребителя
- 44. Отслеживание плана и факта Например,диаграмма Ганта Анализ данных, эксперименты, карты и общение с клиентами Инструменты управления
- 45. После сдачи проекта После каждого эксперимента, интервьюи замера метрики Обратная связь по результатам
- 46. Редко, в основном всё идетпо плану Постоянно, нет ничего неизменного Частота изменений в направлении работы
- 47. Компания заказчика Нашакоманда CEO CTO C Новаяструктура Новая архитектура Новые процессы «Гибкая»культура Внутренние сотрудники: ·Product Owner ·IT-Архитектор ·Team lead
- 48. С чего начать? Создайтекросс-функциональную команду под продукт Рисуйте карты и пишите истории вместо «плоских» текстов Идите в поле, узнайте жизнь Посчитайте бизнес Будьте готовы к изменениям
- 49. Дополнительные ссылки 1. https://www.scrum.org/resources/blo g/project-mindset-or-product-mindset 2.https://martinfowler.com/articles/prod ucts-over-projects.html
- 50.