По итогам тренинга системного мышления "Как определить свою систему среди чужих"
Половина участников сегодняшнего тренинга системного мышления "Как определить свою систему среди чужих" не только читала мою книжку, но и была на каких-то предыдущих тренингах. Это очень тяжело: вести тренинг для тех, кто уже как-то знакомился с системным подходом, и одновременно для слышащих о нём впервые. Надеюсь, все остались довольны: я довольно сильно поменял материал, сдвинул акценты (вот тут я об этом подробней: http://ailev.livejournal.com/1218791.html).
Сегодня случилась необычно жаркая дискуссия на тему неэквивалентности определения и воплощения системы. Минимум полчаса, совсем не ожидал. Все варианты заблуждений на эту тему были тщательно проговорены, да по паре раз каждый. Может, нужно добавить специальных слайдов на эту тему, уж больно она для разработчиков волнительна.
Вообще, чем меньше тем я планирую пройти за день тренинга, тем трудней в это время уложиться. Как весело шутили в конце тренинга, "если не спешить, то можно дойти до деталей -- а поскольку дьявол в деталях, то тут он вылезает, и после этого его приходится долго обсуждать". Даже системную схему проекта сегодня практически не обсуждали, и едва уложились (а уложиться к плановому времени окончания было важно: приехали люди из других городов, у них конец дня поминутно расписан). Действительно, как использовать системную схему проекта, если целевая система ещё неизвестна? Какой такой проект, если непонятна его цель, непонятно что должно быть на выходе, какая система должна быть создана?
Обсудили, как восстанавливать пропущенную систему в проектах по созданию информационных систем: переводить их в проекты автоматизации деятельности, где есть организационный подпроект и софтовый подпроект. Имя у проекта не "внедрение ERP/SAP/EAM/CAD/PLM/Oracle/...", а "автоматизация таких-то работ" -- с подробным выяснением, каких именно работ, что будет с работами и выполняющими эти работы людьми после автоматизации, какой для этой автоматизации нужен софт и его настройки, формированием команды проекта автоматизации из организующих людей и организующих софт подкоманд и т.д.. Нюансов много, рецепт не универсален, но такой сборный "проект автоматизации кусочка деятельности" обычно имеет больше шансов на жизнь и встречает больше понимания, чем более-менее автономный "проект по созданию информационной системы для кусочка деятельности". Да, это про способы заштопывания того самого разрыва между деятелями и айтишниками, business-IT gap. Просто целевая система должна быть куском деятельности (практикой), а не софтом. Софт в корпоративном контексте это обычно подсистема. Софт целевая система чаще всего в айтишной фирме, но если айтишная фирма занимается корпоративными проектами -- то лучше бы ей заниматься проектами автоматизации, а не "внедрения софта", лучше бы целевой системой у фирмы был бы новый автоматизированный кусочек деятельности фирмы, нежели "внедрённый софт".
Вообще, это довольно новая идея о том, проект это работа над целевой системой плюс работа по изменению использующей системы (или влиянию на изменение использующей системы -- там другие хозяева, это только над своей целевой системой ты властен и не влияешь, но просто меняешь). Я недавно описывал в трендах инженерии требований, что необходимость активной работы со стейкхолдерами (а не просто сбор/выявление требований) только-только начинает проникать в стандарты и учебники инженеров по требованиям (http://incose-ru.livejournal.com/53170.html). Этот тренд верен и вообще для проектов: проекты работают не только с самой целевой системой самого проекта, но и влияют на изменения использующей системы (и не только систем в операционном окружении, но иногда и изменения идут с самими стейкхолдерами -- меняется их состав, исполнителей ролей стейкхолдеров доучивают и переучивают, меняется структура их ответственности за системы).
Особо обсуждался вопрос про "сбитую собственную мушку" при описании системы. Конечно, при описании целевой системы все стейкхолдеры смотрят на неё со своих позиций и имеют какие-то интересы -- это понимается легко. Но только я, гений, смотрю объективно и выбираю свою систему среди чужих объективно, то есть как системный инженер (или системный менеджер), потому что это я главный и с системным подходом. Вот такое рассуждение трудно усомнить, если не помнить, что говорящий эти слова имеет богатый жизненный опыт в каких-то вполне определённых ролях -- и он тоже имеет свои интересы, он стейкхолдер, его мушка сбита с "объективности" на деятельностную субъективность не больше, но и не меньше чем у других стейкхолдеров. Поэтому нужно внимательно анализировать свои собственные интересы и выделение целевой системы исходя из этих интересов, понимая, что достичь "объективной системности" и "нейтральности по отношению к другим стейкхолдерам" не получится. Со стороны очень легко увидеть зашоренных их профессиональными интересами других стейкхолдеров, но собственную зашоренность увидеть нелегко. Для начала нужно о ней знать, и включать себя и свои интересы в число стейкхолдеров -- чтобы иметь возможность работать не только над собой, но и над другими.
Это был тренинг системного мышления
1. Как определить свою систему среди чужих1.1. Определение системы
-- Театральная метафора: стейкхолдеры и многерица
-- Практика «Кто у вас был на последнем совещании?»
1.2. Разнообразие систем в проекте
-- Системная холархия: целевая и использующая система
-- Потребности, требования, ограничения (архитектура)
-- Системная схема проекта
1.3. Как определить целевую систему
-- Примеры определения целевой системы
1.4. Практика: определи свою систему
-- Практическое занятие на примерах систем участников
-- Лучшие современные практики менеджмента и системной инженерии
Рабочие программы для последующих тренингов системного мышления из этой серии:
2. Жизненный цикл системы или проекта? 2.1. Понятие жизненного цикла
-- понятие жизненного цикла в биологии и системном подходе 1.0
-- жизненный цикл системы, проекта, технологии
-- понятие архитектуры: компоненты, модули и размещения
-- изменения системы во времени: 4D
2.2. Разнообразие жизненных циклов
-- жизненный цикл в системном подходе 2.0
-- вид жизненного цикла
-- V-модель, спиральная модель,
-- связь с менеджментом, генератор проектов
-- выход за пределы жизненного цикла
2.3. Многомерный жизненный цикл
-- многообразие изменений в проекте;
-- синхронизация изменений воплощения системы, определения системы, возможностей, стейкхолдеров, команды, работы, технологий
2.4. Практики жизненного цикла
-- стандарты и body of knowledge (сумма знаний) как формы документирования практик
-- практики и языки паттернов
-- примеры методологий и составляющих их практик
3. Проекты, процессы или задачи?3.1. Инженерный менеджмент
-- инженерия предприятия
-- роль корпоративного софта
-- разнообразие "управлений"
3.2. Особенности управления разработкой
-- метафора потока
-- проект? процесс? кейс?
-- DEMO
3.3. Архитектура и задачи
-- метод контрольных вопросов
-- события и контрольные точки
3.4. Лучшие практики "управлений" (проектами, процессами, задачами)
-- где "запасы", которые нужно минимизировать в разработке?
-- TOC
-- lean 2.0 и kanban
-- lean startup
-- с чего начнёте у себя?
4. Развитие и совершенствование
4.1. Развитие и совершенствование
-- теория эволюции: революции и застои
-- развитие: постановка практик
-- дилемма инноватора
4.2. Моды и поветрия на практики
-- моды и поветрия (примеры)
-- остромодные практики
-- тренд в развитии практик: автоматизация, вплоть до полной
4.3. Циклы совершенствований
-- постановка практик
-- Дёминга (управление качеством)
-- POOGI (process of on-going improvement, ускорения хода работ)
-- Бойда (сражения с конкурентами)
4.4. Учёт и контроль как фундамент изменений
-- Операционный учёт: управление конфигурацией целевой системы (ALM, PLM, ERP, EAM)
-- управление конфигурацией обеспечивающей системы: архитектура предприятия
5. Архитектура предприятия5.1. О самом главном
-- понятие архитектуры целевой системы
-- архитектура предприятия
-- штабная работа: чем занят архитектор
5.2. Архимейт по-русски
-- почему Архимейт, три его уровня
-- формула "выполнитель -- что делает -- с чем"
-- свободный архитектурный моделер Archi
5.3. Как описать деятельность
-- организационные роли и оргместа
-- практики, процессы, события
-- объекты и рабочие продукты
5.4. Как описать корпоративный софт и "железо"
-- моделирование прикладного софта
-- моделирование оборудования, системного софта и компьютерных сетей
6. Стратегирование6.1. Стратегия и стратегирование
-- что такое стратегия
-- что такое стратегирование
-- тест на стратегию ("что мы немедленно прекращаем делать")
6.2. Представление стратегии в Архимейт
-- целеориентированная инженерия требований
-- стейкхолдеры, интересы, оценки, цели, принципы, контрольные точки
-- стратегия и её реализация в архитектуре предприятия
6.3. Стратегия по Голдратту
-- стратегическое дерево: от миссии к деталям
-- узел стратегического дерева: события, практики, обоснования, жертвы
-- типовые стратегии Голдратта
6.4. Экономичный стартап (Lean Startup)
-- измеримый рост, рост и рост
-- стратегирование -- это эксперименты!
-- стратегические виражи (pivots)
Более подробная информация по каждой теме доступна на сайте организатора вот тут: http://nisse.ru/actual/events/
Сегодня случилась необычно жаркая дискуссия на тему неэквивалентности определения и воплощения системы. Минимум полчаса, совсем не ожидал. Все варианты заблуждений на эту тему были тщательно проговорены, да по паре раз каждый. Может, нужно добавить специальных слайдов на эту тему, уж больно она для разработчиков волнительна.
Вообще, чем меньше тем я планирую пройти за день тренинга, тем трудней в это время уложиться. Как весело шутили в конце тренинга, "если не спешить, то можно дойти до деталей -- а поскольку дьявол в деталях, то тут он вылезает, и после этого его приходится долго обсуждать". Даже системную схему проекта сегодня практически не обсуждали, и едва уложились (а уложиться к плановому времени окончания было важно: приехали люди из других городов, у них конец дня поминутно расписан). Действительно, как использовать системную схему проекта, если целевая система ещё неизвестна? Какой такой проект, если непонятна его цель, непонятно что должно быть на выходе, какая система должна быть создана?
Обсудили, как восстанавливать пропущенную систему в проектах по созданию информационных систем: переводить их в проекты автоматизации деятельности, где есть организационный подпроект и софтовый подпроект. Имя у проекта не "внедрение ERP/SAP/EAM/CAD/PLM/Oracle/...", а "автоматизация таких-то работ" -- с подробным выяснением, каких именно работ, что будет с работами и выполняющими эти работы людьми после автоматизации, какой для этой автоматизации нужен софт и его настройки, формированием команды проекта автоматизации из организующих людей и организующих софт подкоманд и т.д.. Нюансов много, рецепт не универсален, но такой сборный "проект автоматизации кусочка деятельности" обычно имеет больше шансов на жизнь и встречает больше понимания, чем более-менее автономный "проект по созданию информационной системы для кусочка деятельности". Да, это про способы заштопывания того самого разрыва между деятелями и айтишниками, business-IT gap. Просто целевая система должна быть куском деятельности (практикой), а не софтом. Софт в корпоративном контексте это обычно подсистема. Софт целевая система чаще всего в айтишной фирме, но если айтишная фирма занимается корпоративными проектами -- то лучше бы ей заниматься проектами автоматизации, а не "внедрения софта", лучше бы целевой системой у фирмы был бы новый автоматизированный кусочек деятельности фирмы, нежели "внедрённый софт".
Вообще, это довольно новая идея о том, проект это работа над целевой системой плюс работа по изменению использующей системы (или влиянию на изменение использующей системы -- там другие хозяева, это только над своей целевой системой ты властен и не влияешь, но просто меняешь). Я недавно описывал в трендах инженерии требований, что необходимость активной работы со стейкхолдерами (а не просто сбор/выявление требований) только-только начинает проникать в стандарты и учебники инженеров по требованиям (http://incose-ru.livejournal.com/53170.html). Этот тренд верен и вообще для проектов: проекты работают не только с самой целевой системой самого проекта, но и влияют на изменения использующей системы (и не только систем в операционном окружении, но иногда и изменения идут с самими стейкхолдерами -- меняется их состав, исполнителей ролей стейкхолдеров доучивают и переучивают, меняется структура их ответственности за системы).
Особо обсуждался вопрос про "сбитую собственную мушку" при описании системы. Конечно, при описании целевой системы все стейкхолдеры смотрят на неё со своих позиций и имеют какие-то интересы -- это понимается легко. Но только я, гений, смотрю объективно и выбираю свою систему среди чужих объективно, то есть как системный инженер (или системный менеджер), потому что это я главный и с системным подходом. Вот такое рассуждение трудно усомнить, если не помнить, что говорящий эти слова имеет богатый жизненный опыт в каких-то вполне определённых ролях -- и он тоже имеет свои интересы, он стейкхолдер, его мушка сбита с "объективности" на деятельностную субъективность не больше, но и не меньше чем у других стейкхолдеров. Поэтому нужно внимательно анализировать свои собственные интересы и выделение целевой системы исходя из этих интересов, понимая, что достичь "объективной системности" и "нейтральности по отношению к другим стейкхолдерам" не получится. Со стороны очень легко увидеть зашоренных их профессиональными интересами других стейкхолдеров, но собственную зашоренность увидеть нелегко. Для начала нужно о ней знать, и включать себя и свои интересы в число стейкхолдеров -- чтобы иметь возможность работать не только над собой, но и над другими.
Это был тренинг системного мышления
1. Как определить свою систему среди чужих1.1. Определение системы
-- Театральная метафора: стейкхолдеры и многерица
-- Практика «Кто у вас был на последнем совещании?»
1.2. Разнообразие систем в проекте
-- Системная холархия: целевая и использующая система
-- Потребности, требования, ограничения (архитектура)
-- Системная схема проекта
1.3. Как определить целевую систему
-- Примеры определения целевой системы
1.4. Практика: определи свою систему
-- Практическое занятие на примерах систем участников
-- Лучшие современные практики менеджмента и системной инженерии
Рабочие программы для последующих тренингов системного мышления из этой серии:
2. Жизненный цикл системы или проекта? 2.1. Понятие жизненного цикла
-- понятие жизненного цикла в биологии и системном подходе 1.0
-- жизненный цикл системы, проекта, технологии
-- понятие архитектуры: компоненты, модули и размещения
-- изменения системы во времени: 4D
2.2. Разнообразие жизненных циклов
-- жизненный цикл в системном подходе 2.0
-- вид жизненного цикла
-- V-модель, спиральная модель,
-- связь с менеджментом, генератор проектов
-- выход за пределы жизненного цикла
2.3. Многомерный жизненный цикл
-- многообразие изменений в проекте;
-- синхронизация изменений воплощения системы, определения системы, возможностей, стейкхолдеров, команды, работы, технологий
2.4. Практики жизненного цикла
-- стандарты и body of knowledge (сумма знаний) как формы документирования практик
-- практики и языки паттернов
-- примеры методологий и составляющих их практик
3. Проекты, процессы или задачи?3.1. Инженерный менеджмент
-- инженерия предприятия
-- роль корпоративного софта
-- разнообразие "управлений"
3.2. Особенности управления разработкой
-- метафора потока
-- проект? процесс? кейс?
-- DEMO
3.3. Архитектура и задачи
-- метод контрольных вопросов
-- события и контрольные точки
3.4. Лучшие практики "управлений" (проектами, процессами, задачами)
-- где "запасы", которые нужно минимизировать в разработке?
-- TOC
-- lean 2.0 и kanban
-- lean startup
-- с чего начнёте у себя?
4. Развитие и совершенствование
4.1. Развитие и совершенствование
-- теория эволюции: революции и застои
-- развитие: постановка практик
-- дилемма инноватора
4.2. Моды и поветрия на практики
-- моды и поветрия (примеры)
-- остромодные практики
-- тренд в развитии практик: автоматизация, вплоть до полной
4.3. Циклы совершенствований
-- постановка практик
-- Дёминга (управление качеством)
-- POOGI (process of on-going improvement, ускорения хода работ)
-- Бойда (сражения с конкурентами)
4.4. Учёт и контроль как фундамент изменений
-- Операционный учёт: управление конфигурацией целевой системы (ALM, PLM, ERP, EAM)
-- управление конфигурацией обеспечивающей системы: архитектура предприятия
5. Архитектура предприятия5.1. О самом главном
-- понятие архитектуры целевой системы
-- архитектура предприятия
-- штабная работа: чем занят архитектор
5.2. Архимейт по-русски
-- почему Архимейт, три его уровня
-- формула "выполнитель -- что делает -- с чем"
-- свободный архитектурный моделер Archi
5.3. Как описать деятельность
-- организационные роли и оргместа
-- практики, процессы, события
-- объекты и рабочие продукты
5.4. Как описать корпоративный софт и "железо"
-- моделирование прикладного софта
-- моделирование оборудования, системного софта и компьютерных сетей
6. Стратегирование6.1. Стратегия и стратегирование
-- что такое стратегия
-- что такое стратегирование
-- тест на стратегию ("что мы немедленно прекращаем делать")
6.2. Представление стратегии в Архимейт
-- целеориентированная инженерия требований
-- стейкхолдеры, интересы, оценки, цели, принципы, контрольные точки
-- стратегия и её реализация в архитектуре предприятия
6.3. Стратегия по Голдратту
-- стратегическое дерево: от миссии к деталям
-- узел стратегического дерева: события, практики, обоснования, жертвы
-- типовые стратегии Голдратта
6.4. Экономичный стартап (Lean Startup)
-- измеримый рост, рост и рост
-- стратегирование -- это эксперименты!
-- стратегические виражи (pivots)
Более подробная информация по каждой теме доступна на сайте организатора вот тут: http://nisse.ru/actual/events/