Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

ЛАФ7 Гибкий бизнес и принципы постановки задачи v1 1

448 Aufrufe

Veröffentlicht am

Доклад с Летнего Аналитического Фестивали.
Предпосылки и ключевые преимущества трансформации к продуктовым командам.
Новые единицы структурирования и развития бизнеса

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

ЛАФ7 Гибкий бизнес и принципы постановки задачи v1 1

  1. 1. Гибкий бизнес и принципы постановки задачи для ПО Безуглый Дмитрий All you need is… 7 conf.uml2.ru
  2. 2. ЛАФ 7, 2016 г. ООО «Системный Подход» Делать правильные продукты: Помогаем начинающим компаниям и продуктам стать лучше, а хорошим — ЛУЧШИМИ ! Стратегия Бизнес и системный анализ Создание продуктов
  3. 3. @cornerless
  4. 4. ЛАФ 7, 2016 г. RUN - Организация • Еще недавно правила управления казались незыблемыми: • Нарисуй оргструктуру, четко раздели ответственность, отмерь полномочия, разработай стратегию, внедри системы, • Перестань трогать рычаги управления своими охочими порулить руками, • Сядь спокойно на вершине иерархии и наблюдай, как отстроенная организационная машина планомерно движется к обозначенной стратегической цели. Марк Розин, Как внедрять инновации и при этом не разрушить бизнес
  5. 5. ЛАФ 7, 2016 г. Бизнес (Operations) Страт. Консалтинг Люди ( HR) Бизнес процессы Программы Технологии Инновации
  6. 6. ЛАФ 7, 2016 г. Что мешает работать по старому ? (VUCA) 6AnalystDays 2016 Дмитрий Безуглый twitter.com/cornerless
  7. 7. ЛАФ 7, 2016 г. Change-организация • Герман Оскарович сказал: • иерархическая четко структурированная организация не способна к инновациям – она проиграет; • чтобы держаться на гребне волны и развиваться, организация должна быть текучей, гибкой, изменчивой. Марк Розин, Как внедрять инновации и при этом не разрушить бизнес Отладив машину – построив - организацию, вы теперь должны все сломать: превратить ее в change-организацию.
  8. 8. ЛАФ 7, 2016 г. Как реализуются изменения в RUN бизнесе Бизнес Бизнес Бизнес Стратегическое Планирование Бизнес и Системный анализ Исполне ние Внедре ние Крупная организация насчитывает 500-700 систем Крупная организация насчитывает 15-100 Команд Изменение занимает от 6 до 18 месяцев
  9. 9. ЛАФ 7, 2016 г. Тимофей Евграшин Agile в головах и компаниях (v2)
  10. 10. Volatility (Быстрые изменения) + Agility = Галопирующие изменения Complexity (Больше факторов при принятии решений) + Agility = Сначала делаем, Потом Думаем Ambiguity (Неоднозначность последствий событий) + Agility = Прозрачность Результата. Без прозрачности Последствий. Uncertainty (Неопределенность Настоящего) + Agility = Полная Определенность Действий @cornerless
  11. 11. @cornerless Volatility (внезапные изменения) + Гибкая стратегия = Vision ( Ожидаемые изменения) Complexity (Больше факторов при принятии решений) + Гибкий Бизнес Анализ = Understanding Понимание Ambiguity (Неоднозначность последствий событий) + Проектирован ие = Clarity Ясность Uncertainty (Неопределенность Настоящего) + Agile For Teams = Полная Определенность Действий
  12. 12. ЛАФ 7, 2016 г. Масштабирование Agile (Основные направления) 1. Scrum of Scrums 2. LeSS - Large Scale Scrum (Larman/Vodde) 3. Rules of LeSS 4. SAFe - Scaled Agile Framework (Leffingwell) 5. DAD - Disciplined Agile Delivery (Ambler/Lines) 6. Method used at Spotify (Kniberg) 7. ​Enterprise Scrum (Mike Beedle) http://www.agilescaling.com/ • Scaled Professional Scrum / Nexus (scrum.org) • Scrum Inc - Scrum at Scale • Enterprise Transition Framework (agile42) • ​DSDM • ​MAXOS (Andy Singleton) • ScALeD Agile Lean Development • Descaling as an Alternative to Scaling Agile • Descaling Organizations, Part 1​ • scaledprinciples.org • Xscale • RAGE (Cprime)
  13. 13. ЛАФ 7, 2016 г. SAFe Роли ответственные за ответ на вопрос «Что делаем?» (ч. 1) • Уровень команды Team Level • Product Owner - Локальные решения по реализации изменений. • Уровень программы (Program Level) • Менеджер продукта (Product Management) несет ответственность за создание видения развития и дорожную карту программы. • Системный Архитектор (System Architect/Engineer) играет важную роль в оказании помощи командам в общем техническом направлении к выполнению миссии, видения и дорожной карты. • Владельцы бизнеса разделяют ответственность за ценность создаваемого решения
  14. 14. ЛАФ 7, 2016 г. SAFe Роли ответственные за ответ на вопрос «Что делаем?» (ч. 2) • Уровень потока создания ценности (Value Stream level) • Управление решением (Solution Management) имеет обязанности, аналогичные управлению продуктами • Архитектор Решения (Solution Architect/Engineer ) несет ответственность, аналогичную системный архитектор / инженер • Уровень портфеля (Portfolio Level) • Архитектор предприятия (Enterprise Architect) работает на стыке Потоков создания ценности и Потока реализации изменений для обеспечения стратегического технического руководства в таких областях, как рекомендации стека технологий, взаимодействие решений и т.д. • Владелец Эпика (Epic Owner) роль, а не должность. Этот человек берет на себя ответственность за бизнес-результат и реализацию инициатив руководства, называемого Эпиком в SAFe
  15. 15. ЛАФ 7, 2016 г. Зона Понимания Вовлечение источника изменений в процесс проектирования Зона Управле ния Изменения перестают быть внезапными
  16. 16. ЛАФ 7, 2016 г. Масштаб изменений и инноваций Уровень компании Уровень потока создания бизнеса Уровень программы/продукта Уровень Команды • Источник изменений – Стратегия компании • Источник изменений - Рынок • Источник изменений – Владелец бизнес процесса • Источник изменений Пользователь
  17. 17. ЛАФ 7, 2016 г. Почему необходимы отдельные люди для поиска решения ?
  18. 18. ЛАФ 7, 2016 г. Анализ требует времени Анализ бизнес- потребности Определение бизнес- потребности Формирование требований · Выявление изменения · Определение бизнес-заказчика · Приоритезация потребности · Категоризация потребности · Оценка соответствия потребности бизнес- целям · Определение взаимосвязей и взаимовлияния потребностей · Экспресс-оценка стоимости реализации потребности: определение порядка цены · Определение заинтересованных лиц · Формирование перечня требований в рамках потребности · Верификация требований · Оценка соответствия требований бизнес- целям · Оценка соответствия требований целевой архитектуре блока · Определение взаимосвязей и взаимовлияния требований Экспертиза и контроль реализации требований · Предоставление экспертных заключений по реализации · Экспертиза тест- кейсов · Контроль реализации требований · Валидация требований Оценка удовлетворения бизнес- потребности · Post Implementation Review · Оценка эффективности и работоспособности решений · Выявление недостатков/ проблем/ направлений дальнейшего развития в масштабе реализованной целевой архитектуры · Пересмотр требований в связи с изменением бизнес- целей и прочих элементов контекста Формирование решений · Аллокация требований по объектам архитектуры · Экспресс-оценка стоимости реализации требований, · в т.ч. расчет экономической эффективности их реализации (NPV, EMV) · Определение состава решений, требуемых для реализации целевой архитектуры в периметре потребности (целевых решений) ОПИСАНИЕ ПОТРЕБНОСТИ ЭТАПЫ ЖЦ КЛЮЧЕВЫЕ ЗАДАЧИ ОСНОВНЫЕ РЕЗУЛЬТАТЫ ОПИСАНИЕ ПРЕ-БИЗНЕС- КЕЙСА БИЗНЕС-ТРЕБОВАНИЯ БИЗНЕС-РЕШЕНИЕ БИЗНЕС-КЕЙС ЭКСПЕРТНЫЕ ЗАКЛЮЧЕНИЯ ОТЧЕТЫ ПО УДОВЛЕТВОРЕННОСТИ БИЗНЕСА
  19. 19. ЛАФ 7, 2016 г. Цена переключения между проектами (Waste) 1. Формирование карты ЗС 2. Этнография – изучение пользователей 3. Установление доверия с ЗС 4. Исследование и изучение контекста. Процессы, Системы, Инфраструктура (Погружение в предметную область) 5. Документирование и извлечение промежуточных результатов 6. Изучение технологических и возможностей команды 7. Установление контакта и взаимоотношений с командой
  20. 20. Выживает наиболее приспособленный Survival of the Fittest Приспособлен к существующей среде (1) Имеет лучшие возможности по адаптации (2)
  21. 21. ЛАФ 7, 2016 г. Компромисс развития Чем выше приспособленность к текущим условиям, тем ниже готовность к адаптации
  22. 22. ЛАФ 7, 2016 г. Продуктовый подход (Адаптированность) Разрабатывать решение Приспособленностьрешения Решение Продукт Создавать продукт
  23. 23. ЛАФ 7, 2016 г. Продуктовый подход (Социо-техническая система) Решение Продукт IT Команда Бизнес Пользователи
  24. 24. ЛАФ 7, 2016 г. Ценность и инновации создает «Digital» единица
  25. 25. ЛАФ 7, 2016 г. Иногда в ней не будет бизнес пользователей
  26. 26. ЛАФ 7, 2016 г. Иногда в ней не будет ИТ 
  27. 27. ЛАФ 7, 2016 г. Изменения в Change бизнесе Digital Поддержка Digital Производство Digital Маркетинг
  28. 28. Вопросы?
  29. 29. ЛАФ 7, 2016 г. Спасибо за внимание ! 33 • Дмитрий Безуглый • https://www.facebook.com/ dmitry.bezuglyy • bdl@system-approach.ru • ООО «Системный Подход» • https://www.facebook.com/ SystemApproach • www.system-approach.ru AnalystDays 2016 Дмитрий Безуглый twitter.com/cornerless
  30. 30. ЛАФ 7, 2016 г. Источники 1. Марк Розин, Как внедрять инновации и при этом не разрушить бизнес 2. http://www.agilescaling.com/ 3. Тимофей Евграшин Agile в головах и компаниях (v2)
  31. 31. ЛАФ 7, 2016 г. The-Сynefin-framework Делаем и не думаем  Сначала делаем потом думаем. Делаем, Проверяем, Думаем Дважды думаем, потом делаем Просто делаем AnalystDays 2016 Дмитрий Безуглый twitter.com/cornerless
  32. 32. ЛАФ 7, 2016 г. Теория систем Гибкость в реализации = Овеществление границ Границы системы AnalystDays 2016 Дмитрий Безуглый twitter.com/cornerless

×