ЛАФ7 Гибкий бизнес и принципы постановки задачи v1 1
•Als PPTX, PDF herunterladen•
0 gefällt mir•609 views
Доклад с Летнего Аналитического Фестивали. Предпосылки и ключевые преимущества трансформации к продуктовым командам. Новые единицы структурирования и развития бизнеса
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (19)
Andere mochten auch
Andere mochten auch (9)
Ähnlich wie ЛАФ7 Гибкий бизнес и принципы постановки задачи v1 1
Ähnlich wie ЛАФ7 Гибкий бизнес и принципы постановки задачи v1 1 (20)
Mehr von Dmitry Bezuglyy
Mehr von Dmitry Bezuglyy (20)
ЛАФ7 Гибкий бизнес и принципы постановки задачи v1 1
- 1. Гибкий бизнес и принципы постановки задачи для ПО Безуглый Дмитрий All you need is… 7 conf.uml2.ru
- 2. ЛАФ 7, 2016 г. ООО «Системный Подход» Делать правильные продукты: Помогаем начинающим компаниям и продуктам стать лучше, а хорошим — ЛУЧШИМИ ! Стратегия Бизнес и системный анализ Создание продуктов
- 3. @cornerless
- 4. ЛАФ 7, 2016 г. RUN - Организация • Еще недавно правила управления казались незыблемыми: • Нарисуй оргструктуру, четко раздели ответственность, отмерь полномочия, разработай стратегию, внедри системы, • Перестань трогать рычаги управления своими охочими порулить руками, • Сядь спокойно на вершине иерархии и наблюдай, как отстроенная организационная машина планомерно движется к обозначенной стратегической цели. Марк Розин, Как внедрять инновации и при этом не разрушить бизнес
- 5. ЛАФ 7, 2016 г. Бизнес (Operations) Страт. Консалтинг Люди ( HR) Бизнес процессы Программы Технологии Инновации
- 6. ЛАФ 7, 2016 г. Что мешает работать по старому ? (VUCA) 6AnalystDays 2016 Дмитрий Безуглый twitter.com/cornerless
- 7. ЛАФ 7, 2016 г. Change-организация • Герман Оскарович сказал: • иерархическая четко структурированная организация не способна к инновациям – она проиграет; • чтобы держаться на гребне волны и развиваться, организация должна быть текучей, гибкой, изменчивой. Марк Розин, Как внедрять инновации и при этом не разрушить бизнес Отладив машину – построив - организацию, вы теперь должны все сломать: превратить ее в change-организацию.
- 8. ЛАФ 7, 2016 г. Как реализуются изменения в RUN бизнесе Бизнес Бизнес Бизнес Стратегическое Планирование Бизнес и Системный анализ Исполне ние Внедре ние Крупная организация насчитывает 500-700 систем Крупная организация насчитывает 15-100 Команд Изменение занимает от 6 до 18 месяцев
- 9. ЛАФ 7, 2016 г. Тимофей Евграшин Agile в головах и компаниях (v2)
- 10. Volatility (Быстрые изменения) + Agility = Галопирующие изменения Complexity (Больше факторов при принятии решений) + Agility = Сначала делаем, Потом Думаем Ambiguity (Неоднозначность последствий событий) + Agility = Прозрачность Результата. Без прозрачности Последствий. Uncertainty (Неопределенность Настоящего) + Agility = Полная Определенность Действий @cornerless
- 11. @cornerless Volatility (внезапные изменения) + Гибкая стратегия = Vision ( Ожидаемые изменения) Complexity (Больше факторов при принятии решений) + Гибкий Бизнес Анализ = Understanding Понимание Ambiguity (Неоднозначность последствий событий) + Проектирован ие = Clarity Ясность Uncertainty (Неопределенность Настоящего) + Agile For Teams = Полная Определенность Действий
- 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)
- 14. ЛАФ 7, 2016 г. SAFe Роли ответственные за ответ на вопрос «Что делаем?» (ч. 1) • Уровень команды Team Level • Product Owner - Локальные решения по реализации изменений. • Уровень программы (Program Level) • Менеджер продукта (Product Management) несет ответственность за создание видения развития и дорожную карту программы. • Системный Архитектор (System Architect/Engineer) играет важную роль в оказании помощи командам в общем техническом направлении к выполнению миссии, видения и дорожной карты. • Владельцы бизнеса разделяют ответственность за ценность создаваемого решения
- 15. ЛАФ 7, 2016 г. SAFe Роли ответственные за ответ на вопрос «Что делаем?» (ч. 2) • Уровень потока создания ценности (Value Stream level) • Управление решением (Solution Management) имеет обязанности, аналогичные управлению продуктами • Архитектор Решения (Solution Architect/Engineer ) несет ответственность, аналогичную системный архитектор / инженер • Уровень портфеля (Portfolio Level) • Архитектор предприятия (Enterprise Architect) работает на стыке Потоков создания ценности и Потока реализации изменений для обеспечения стратегического технического руководства в таких областях, как рекомендации стека технологий, взаимодействие решений и т.д. • Владелец Эпика (Epic Owner) роль, а не должность. Этот человек берет на себя ответственность за бизнес-результат и реализацию инициатив руководства, называемого Эпиком в SAFe
- 16. ЛАФ 7, 2016 г. Зона Понимания Вовлечение источника изменений в процесс проектирования Зона Управле ния Изменения перестают быть внезапными
- 17. ЛАФ 7, 2016 г. Масштаб изменений и инноваций Уровень компании Уровень потока создания бизнеса Уровень программы/продукта Уровень Команды • Источник изменений – Стратегия компании • Источник изменений - Рынок • Источник изменений – Владелец бизнес процесса • Источник изменений Пользователь
- 18. ЛАФ 7, 2016 г. Почему необходимы отдельные люди для поиска решения ?
- 19. ЛАФ 7, 2016 г. Анализ требует времени Анализ бизнес- потребности Определение бизнес- потребности Формирование требований · Выявление изменения · Определение бизнес-заказчика · Приоритезация потребности · Категоризация потребности · Оценка соответствия потребности бизнес- целям · Определение взаимосвязей и взаимовлияния потребностей · Экспресс-оценка стоимости реализации потребности: определение порядка цены · Определение заинтересованных лиц · Формирование перечня требований в рамках потребности · Верификация требований · Оценка соответствия требований бизнес- целям · Оценка соответствия требований целевой архитектуре блока · Определение взаимосвязей и взаимовлияния требований Экспертиза и контроль реализации требований · Предоставление экспертных заключений по реализации · Экспертиза тест- кейсов · Контроль реализации требований · Валидация требований Оценка удовлетворения бизнес- потребности · Post Implementation Review · Оценка эффективности и работоспособности решений · Выявление недостатков/ проблем/ направлений дальнейшего развития в масштабе реализованной целевой архитектуры · Пересмотр требований в связи с изменением бизнес- целей и прочих элементов контекста Формирование решений · Аллокация требований по объектам архитектуры · Экспресс-оценка стоимости реализации требований, · в т.ч. расчет экономической эффективности их реализации (NPV, EMV) · Определение состава решений, требуемых для реализации целевой архитектуры в периметре потребности (целевых решений) ОПИСАНИЕ ПОТРЕБНОСТИ ЭТАПЫ ЖЦ КЛЮЧЕВЫЕ ЗАДАЧИ ОСНОВНЫЕ РЕЗУЛЬТАТЫ ОПИСАНИЕ ПРЕ-БИЗНЕС- КЕЙСА БИЗНЕС-ТРЕБОВАНИЯ БИЗНЕС-РЕШЕНИЕ БИЗНЕС-КЕЙС ЭКСПЕРТНЫЕ ЗАКЛЮЧЕНИЯ ОТЧЕТЫ ПО УДОВЛЕТВОРЕННОСТИ БИЗНЕСА
- 20. ЛАФ 7, 2016 г. Цена переключения между проектами (Waste) 1. Формирование карты ЗС 2. Этнография – изучение пользователей 3. Установление доверия с ЗС 4. Исследование и изучение контекста. Процессы, Системы, Инфраструктура (Погружение в предметную область) 5. Документирование и извлечение промежуточных результатов 6. Изучение технологических и возможностей команды 7. Установление контакта и взаимоотношений с командой
- 21. Выживает наиболее приспособленный Survival of the Fittest Приспособлен к существующей среде (1) Имеет лучшие возможности по адаптации (2)
- 22. ЛАФ 7, 2016 г. Компромисс развития Чем выше приспособленность к текущим условиям, тем ниже готовность к адаптации
- 23. ЛАФ 7, 2016 г. Продуктовый подход (Адаптированность) Разрабатывать решение Приспособленностьрешения Решение Продукт Создавать продукт
- 24. ЛАФ 7, 2016 г. Продуктовый подход (Социо-техническая система) Решение Продукт IT Команда Бизнес Пользователи
- 25. ЛАФ 7, 2016 г. Ценность и инновации создает «Digital» единица
- 26. ЛАФ 7, 2016 г. Иногда в ней не будет бизнес пользователей
- 27. ЛАФ 7, 2016 г. Иногда в ней не будет ИТ
- 28. ЛАФ 7, 2016 г. Изменения в Change бизнесе Digital Поддержка Digital Производство Digital Маркетинг
- 29. Вопросы?
- 30. ЛАФ 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
- 31. ЛАФ 7, 2016 г. Источники 1. Марк Розин, Как внедрять инновации и при этом не разрушить бизнес 2. http://www.agilescaling.com/ 3. Тимофей Евграшин Agile в головах и компаниях (v2)
- 32. ЛАФ 7, 2016 г. The-Сynefin-framework Делаем и не думаем Сначала делаем потом думаем. Делаем, Проверяем, Думаем Дважды думаем, потом делаем Просто делаем AnalystDays 2016 Дмитрий Безуглый twitter.com/cornerless
- 33. ЛАФ 7, 2016 г. Теория систем Гибкость в реализации = Овеществление границ Границы системы AnalystDays 2016 Дмитрий Безуглый twitter.com/cornerless
Hinweis der Redaktion
- Основной вопрос - Что такое гибкий анализ и что нужно чтобы он действительно работал ? В рамках доклада будут рассмотрены: VUKA – контекст (+) Big Agile картина Бизнес и cистемный анализ (BSA) в SAFe 4.0 Принципы реализации гибкого анализа Обзор основных инструменты и практик Гибкого Анализа
- OVERVIEW: In this slide, you can explain that, at first glance, the Framework may appear complicated. However, you can provide assurance that you will take them through it in a logical manner. SAMPLE SPEAKER NOTES: This is what is referred to as the “SAFe Big Picture”. At first, it may look complicated, but as we will see, it is actually a very straight-forward and logical representation. We will see that roles, artifacts, and activities are clearly defined based on proven principles and practices. Decomposing the SAFe Big Picture into it’s constituent parts, we’ll discover that it’s a simple, powerful and easily understood framework for managing complex software and systems development.
- Let’s now move to the Team Level Here, we have small cross-functional teams that are empowered to make localized decisions to get work done. These teams may operate under ScrumXP or Kanban on software, firmware, or hardware. Each Agile team has a Scrum Master, Product Owner, Developers, Testers, and other necessary team roles. Let’s move to the Program Level The Release Train Engineer facilitates the activities of the Agile Release Train, much like the Scrum Master facilitates the activities of the team. Product Management is responsible for the Program Vision and Roadmap. They prioritize the work in the Program Backlog, much like Product Owners do in the Team Backlog, The System Architect/Engineer plays a critical role in helping align teams in a common technical direction toward accomplishment of the mission, Vision, and Roadmap. Business Owners share responsibility for the value delivered by a specific Agile Release Train The roles at the Value Stream level are similar to those at the Program Level The Value Stream Engineer has responsibilities similar to those of the Release Train Engineer Solution Management has responsibilities similar to those of Product Management The Solution Architect/Engineer has responsibilities similar to those of the System Architect/Engineer Let’s move to the Portfolio Level We have the Program Portfolio Management team responsible for strategy and investment funding, program execution, and governance. They have the highest level fiduciary responsibility in the Framework. The Enterprise Architect works across Value Streams and Agile Release Trains to provide strategic technical guidance in such areas as technology stack recommendations, interoperability of solutions, and hosting strategies The Epic Owner is a role, not a title. This person takes responsibility for the business case and implementation guidance of initiatives, called Epics in SAFe
- Let’s now move to the Team Level Here, we have small cross-functional teams that are empowered to make localized decisions to get work done. These teams may operate under ScrumXP or Kanban on software, firmware, or hardware. Each Agile team has a Scrum Master, Product Owner, Developers, Testers, and other necessary team roles. Let’s move to the Program Level The Release Train Engineer facilitates the activities of the Agile Release Train, much like the Scrum Master facilitates the activities of the team. Product Management is responsible for the Program Vision and Roadmap. They prioritize the work in the Program Backlog, much like Product Owners do in the Team Backlog, The System Architect/Engineer plays a critical role in helping align teams in a common technical direction toward accomplishment of the mission, Vision, and Roadmap. Business Owners share responsibility for the value delivered by a specific Agile Release Train The roles at the Value Stream level are similar to those at the Program Level The Value Stream Engineer has responsibilities similar to those of the Release Train Engineer Solution Management has responsibilities similar to those of Product Management The Solution Architect/Engineer has responsibilities similar to those of the System Architect/Engineer Let’s move to the Portfolio Level We have the Program Portfolio Management team responsible for strategy and investment funding, program execution, and governance. They have the highest level fiduciary responsibility in the Framework. The Enterprise Architect works across Value Streams and Agile Release Trains to provide strategic technical guidance in such areas as technology stack recommendations, interoperability of solutions, and hosting strategies The Epic Owner is a role, not a title. This person takes responsibility for the business case and implementation guidance of initiatives, called Epics in SAFe
- Слишком много извлечения и передачи знаний
- https://baoman.wordpress.com/2010/01/07/my-riff-on-the-cynefin-framework/