Embed Size (px)
Citation preview
Гибкий бизнес и принципы постановки задачи для ПО
Безуглый Дмитрий
All you need is… 7
conf.uml2.ru
ЛАФ 7, 2016 г.
ООО «Системный Подход»Делать правильные продукты:
Помогаем начинающим компаниям и продуктам стать лучше,
а хорошим — ЛУЧШИМИ !
Стратегия Бизнес и системный анализ
Создание продуктов
@cornerless
ЛАФ 7, 2016 г.
RUN - Организация• Еще недавно правила управления казались
незыблемыми:• Нарисуй оргструктуру, четко раздели ответственность,
отмерь полномочия, разработай стратегию, внедри системы,
• Перестань трогать рычаги управления своими охочими порулить руками,
• Сядь спокойно на вершине иерархии и наблюдай, как отстроенная организационная машина планомерно движется к обозначенной стратегической цели.
Марк Розин, Как внедрять инновации и при этом не разрушить бизнес
ЛАФ 7, 2016 г.
Бизнес (Operations)
Страт. Консалтинг
Люди ( HR)
Бизнес процессы
Программы
Технологии
Инновации
ЛАФ 7, 2016 г. 6
Что мешает работать по старому ? (VUCA)
AnalystDays 2016 Дмитрий Безуглый twitter.com/cornerless
ЛАФ 7, 2016 г.
Change-организация• Герман Оскарович сказал:
• иерархическая четко структурированная организация не способна к инновациям – она проиграет;
• чтобы держаться на гребне волны и развиваться, организация должна быть текучей, гибкой, изменчивой.
Марк Розин, Как внедрять инновации и при этом не разрушить бизнес
Отладив машину – построив - организацию, вы теперь должны все сломать:
превратить ее в change-организацию.
ЛАФ 7, 2016 г.
Как реализуются изменения в RUN бизнесе
Бизнес Бизнес Бизнес
Стратегическое Планирование
Бизнес и Системный
анализ
Исполнение
Внедрение
Крупная организация насчитывает
500-700 систем
Крупная организация насчитывает
15-100 Команд
Изменение занимает от 6 до
18 месяцев
ЛАФ 7, 2016 г.
Тимофей Евграшин Agile в головах и компаниях (v2)
@cornerless
Volatility(Быстрые
изменения) + Agility = Галопирующие
изменения
Complexity(Больше факторов
при принятии решений)
+ Agility =Сначала делаем,Потом Думаем
Ambiguity (Неоднозначность
последствий событий)
+ Agility =ПрозрачностьРезультата.Без прозрачности Последствий.
Uncertainty(Неопределенность
Настоящего) + Agility =
Полная ОпределенностьДействий
@cornerless
Volatility(внезапные изменения)
+ Гибкая стратегия = Vision
( Ожидаемые изменения)
Complexity(Больше факторов
при принятии решений)
+ Гибкий Бизнес Анализ = Understanding
Понимание
Ambiguity (Неоднозначность
последствий событий)
+ Проектирование = Clarity
Ясность
Uncertainty(Неопределенность
Настоящего) + Agile For Teams =
Полная Определенность
Действий
ЛАФ 7, 2016 г.
Масштабирование Agile (Основные направления)
1. Scrum of Scrums2. LeSS - Large Scale Scrum (Larman/Vodde)3. Rules of LeSS4. SAFe - Scaled Agile Framework (Leffingwell)5. DAD - Disciplined Agile Delivery (Ambler/Lin
es)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 Scal
ing Agile
• Descaling Organizations, Part 1 • scaledprinciples.org
• Xscale• RAGE (Cprime)
ЛАФ 7, 2016 г.
SAFe Роли ответственные за ответ на вопрос «Что делаем?» (ч. 1)
• Уровень команды Team Level• Product Owner - Локальные решения по реализации изменений.
• Уровень программы (Program Level)• Менеджер продукта (Product Management) несет ответственность
за создание видения развития и дорожную карту программы. • Системный Архитектор (System Architect/Engineer) играет важную
роль в оказании помощи командам в общем техническом направлении к выполнению миссии, видения и дорожной карты.
• Владельцы бизнеса разделяют ответственность за ценность создаваемого решения
ЛАФ 7, 2016 г.
SAFe Роли ответственные за ответ на вопрос «Что делаем?» (ч. 2)
• Уровень потока создания ценности (Value Stream level) • Управление решением (Solution Management) имеет обязанности,
аналогичные управлению продуктами• Архитектор Решения (Solution Architect/Engineer ) несет ответственность,
аналогичную системный архитектор / инженер• Уровень портфеля (Portfolio Level)
• Архитектор предприятия (Enterprise Architect) работает на стыке Потоков создания ценности и Потока реализации изменений для обеспечения стратегического технического руководства в таких областях, как рекомендации стека технологий, взаимодействие решений и т.д.
• Владелец Эпика (Epic Owner) роль, а не должность. Этот человек берет на себя ответственность за бизнес-результат и реализацию инициатив руководства, называемого Эпиком в SAFe
ЛАФ 7, 2016 г.
Зона Понимания
Вовлечение источника изменений в процесс проектирования
Зона Управле
ния
Изменения перестают быть внезапными
ЛАФ 7, 2016 г.
Масштаб изменений и инноваций
Уровень компании
Уровень потока создания бизнеса
Уровень программы/продукта
Уровень Команды
• Источник изменений – Стратегия компании
• Источник изменений - Рынок
• Источник изменений – Владелец бизнес процесса
• Источник изменений Пользователь
ЛАФ 7, 2016 г.
Почему необходимы отдельные люди для поиска решения ?
ЛАФ 7, 2016 г.
Анализ требует времениАнализ бизнес-потребности
Определение бизнес-потребности
Формирование требований
· Выявление изменения
· Определение бизнес-заказчика
· Приоритезация потребности
· Категоризация потребности
· Оценка соответствия потребности бизнес-целям
· Определение взаимосвязей и взаимовлияния потребностей
· Экспресс-оценка стоимости реализации потребности: определение порядка цены
· Определение заинтересованных лиц
· Формирование перечня требований в рамках потребности
· Верификация требований
· Оценка соответствия требований бизнес-целям
· Оценка соответствия требований целевой архитектуре блока
· Определение взаимосвязей и взаимовлияния требований
Экспертиза и контроль реализации требований
· Предоставление экспертных заключений по реализации
· Экспертиза тест-кейсов
· Контроль реализации требований
· Валидация требований
Оценка удовлетворения бизнес-потребности
· Post Implementation Review
· Оценка эффективности и работоспособности решений
· Выявление недостатков/проблем/ направлений дальнейшего развития в масштабе реализованной целевой архитектуры
· Пересмотр требований в связи с изменением бизнес-целей и прочих элементов контекста
Формирование решений
· Аллокация требований по объектам архитектуры
· Экспресс-оценка стоимости реализации требований,
· в т.ч. расчет экономической эффективности их реализации (NPV, EMV)
· Определение состава решений, требуемых для реализации целевой архитектуры в периметре потребности (целевых решений)
ОПИСАНИЕ ПОТРЕБНОСТИ
ЭТА
ПЫ
Ж
ЦК
ЛЮ
ЧЕВ
ЫЕ
ЗАД
АЧ
ИО
СН
ОВ
НЫ
Е Р
ЕЗУ
ЛЬ
ТАТЫ
ОПИСАНИЕ ПРЕ-БИЗНЕС-КЕЙСА БИЗНЕС-ТРЕБОВАНИЯ БИЗНЕС-РЕШЕНИЕ
БИЗНЕС-КЕЙСЭКСПЕРТНЫЕ ЗАКЛЮЧЕНИЯ
ОТЧЕТЫ ПО УДОВЛЕТВОРЕННОСТИ
БИЗНЕСА
ЛАФ 7, 2016 г.
Цена переключения между проектами (Waste)
1. Формирование карты ЗС2. Этнография – изучение пользователей3. Установление доверия с ЗС4. Исследование и изучение контекста. Процессы, Системы,
Инфраструктура (Погружение в предметную область)5. Документирование и извлечение промежуточных
результатов6. Изучение технологических и возможностей команды7. Установление контакта и взаимоотношений с командой
Выживает наиболее приспособленный
Survival of the Fittest
Приспособлен к существующей
среде (1)
Имеет лучшие
возможности по
адаптации (2)
ЛАФ 7, 2016 г.
Компромисс развития
Чем выше приспособленность к текущим условиям, тем ниже готовность к адаптации
ЛАФ 7, 2016 г.
Продуктовый подход (Адаптированность)
Разрабатывать решение При
спос
обле
ннос
ть р
ешен
ия
Решение Продукт
Создавать продукт
ЛАФ 7, 2016 г.
Продуктовый подход (Социо-техническая система)
Решение Продукт
IT Команда
Бизнес Пользователи
ЛАФ 7, 2016 г.
Ценность и инновации создает «Digital» единица
ЛАФ 7, 2016 г.
Иногда в ней не будет бизнес пользователей
ЛАФ 7, 2016 г.
Иногда в ней не будет ИТ
ЛАФ 7, 2016 г.
Изменения в Change бизнесе
Digital Поддержка
Digital Производство
Digital Маркетинг
Вопросы?
ЛАФ 7, 2016 г. 33
Спасибо за внимание !
• Дмитрий Безуглый• https://www.facebook.com/
dmitry.bezuglyy • [email protected] • ООО «Системный Подход»
• https://www.facebook.com/SystemApproach
• www.system-approach.ru
AnalystDays 2016 Дмитрий Безуглый twitter.com/cornerless
ЛАФ 7, 2016 г.
Источники1. Марк Розин, Как внедрять инновации и
при этом не разрушить бизнес 2. http://www.agilescaling.com/3. Тимофей Евграшин Agile
в головах и компаниях (v2)
ЛАФ 7, 2016 г.
The-Сynefin-framework
ChaoticДелаем и
не думаем
ComplexСначала
делаем потом думаем. Делаем,
Проверяем, Думаем
Complicated
Дважды думаем, потом
делаем
Simple
Просто делаем
AnalystDays 2016 Дмитрий Безуглый twitter.com/cornerless
ЛАФ 7, 2016 г.
Simple
Теория системComplex -> Complicated -> Simple
Гибкость в реализации
= Овеществление границ
Границы системы
Simple
Complicated
Complex
AnalystDays 2016 Дмитрий Безуглый twitter.com/cornerless
