Версия 02:59, 3 апреля 2019

В субботу был на конференции "Прикладное системное мышление", которую проводит школа Системного менеджмента Анатолия Левенчука. Репортаж не получается: wifi нет, а мой мобильный инет был медленный. Может, и хорошо, что не получился, потому что доклады были очень информационно-насыщенные, и я мог сосредоточиться на содержании. У Анатолия был большой пост с анонсом содержания.

Открывалась конференция докладом Анатолия Левенчука, в котором был анонс новой концепции их школы системного менеджмента как второго-альтернативного бакалавриата, дающего базовые дисциплины, затем было нескjлько докладов, в которых представлены онтики, созданные в школе при разработке базовых дисциплин, о постановке обучения, и доклады о конкретных проектах в разных отраслях с применением системного мышления или других мыслительных практик, и о развитии мышления, об инструментах моделирования. Кстати об инструментах стоит отметить, что в большинстве случаев пробовали использовать Enterprise Architect, и ни в одном случае он не взлетел. Реально работает связка из диаграмм на салфетках (досках, флипчартах, просто листах бумаги), которые затем переводятся в confluence.

Презентации и видео большинства докладов конференции будут опубликованы, но некоторые доклады были без записи по просьбе автора. А дальше - мой обзор докладов. А Анатолий уже написал свой отзыв о конференции со ссылками на открытые презентации и на канал, где будет видео (но я свой писал втемную, не читая отзыв Анатолия).

Анатолий Левенчук. Образовательная программа второго бакалавриата

Основной тезис доклада - в том, что концепция второй магистратуры или дополнительного образования не работает, потому что есть пробелы в базовом образовании: у людей не поставлено мышление, отсутствуют базовые модели мира. А без них нельзя быстро дать понимание смежных областей, необходимое для полноценного понимания концептов, нельзя сформировать полноценных T-людей с глубоким, а не поверхностным пониманием смежных специализаций, необходимым для совместной работы над сложными проектами. Они в школе это осознали, весь последний год строят программу второго бакалавриата со своими базовыми курсами по мышлению и другим дисциплинам. В презентации была слоевая схема дисциплин (справа), а в конце февраля у Анатолия был большой пост и доклад о содержании обучения.

Отмечу, что когда у них получится создать такой бакалавриат, то он неизбежно окажется порезанным на небольшие тренинги, а значит может доставляться не комплектом, а по требованию. А еще не исключено, что в этих условиях нынешний первый бакалавриат просто станет не нужным. А еще - Анатолий открыт к сотрудничеству, и если кто-то хотел бы взять еще неразвернутую часть его курса и развернуть в отдельный тренинг и создать онтику, или иным образом использовать и развивать материалы - можно к нему обращаться.

Ну а дальше - краткий конспект доклада из моего поста.

Заполнение договоров с гос.образованием МФТИ - договор - подпись за раздел каждого курса, и дата, помимо общего за договор, громадная детализация. Это показывает, почему нельзя работать с государством. Еще и потому, что он в системной школе ведет уже 13 курс, а там - нет.

Хотели у государства сделать онтологику - нельзя, читают логику и историю науки, которая не имеет никакого отношения к практике. Разбирают историю флогинстона - последние 100 лет. И сдвинуть это невозможно, другая кафедра.

Концепция кругозора, T-люди: глубокие прикладники с широким кругозором. Кроме своей деятельности - выцепить смежные, выцепить объекты, сделать персональное преобразование, а потом еще отдать, кому надо, не туда, откуда взял, а по цепочке. И это принципиально отличается от человека ренессанса - широкого кругозора Леонардо да Винчи, профессионал во всем. Которая в 19 веке деградировала в английского джентльмена. который дилетант во всем.

Надо не просто разговаривать с людьми, чему учат курсы и тренинги коммуникации, а содержательный разговор, а для этого надо знать смежные предметы содержательно. А это не вторая-третья магистратура, а второй-третий бакалавриат, потому что концептуальную базу по замыслу дают в бакалавриате. И они в школе занимаются именно вторым бакалавриатом. Для которого нужно еще добавить фундаментальные курсы, выделив общее, чтобы сделать людей способным осваивать концепты.

И они пересмотрели курс школы системного менеджмента, осознав это. Стейкхолдерское мастерство, стратегирование, управление изменениями. Сейчас занимается стратегическим маркетингом, который оказывается продвижением, а не маркетингом.

Антон Климант. Онтика для танца и телесного мышления

Рассказ об онтике, которая лежит в основе тренинга Антона по системному фитнесу. Это результат применения системного мышления к танцу, с выделением базовых элементов. Сам Антон - крутой танцор, танцующий директор школы чемпионов брейк-данса "Волнорез", и уже сложившимся успешным тренером пришел к освоению системного мышления и попытке совместно с Анатолием применить его к танцу. И это - получилось.

Институт физической культуры основывается на описании Берштейна. Три уровня - мышцы, суставные увязки, уровень пространства, уровень действий, уровень движения. Они чуть поменяли лексику и по-другому рассказывают. Говорят не тонус/титанус, а говорят об усилиях, правильных, паразитных и остаточных. На слайдах была уровневая структура и логика развертывания курса, очень конкретная и с обоснованием. 5 пунктов - 5 дней.

В курсе они ставят осознанное управление мышцами, чувствительность к усилию.

• объем внимания к усилию конкретной мышцы. Мышцы плеча - 5-6 мышц. А сколько вы чувствуете?
• Шкала - усилия, сверхусилия, расслабление, обмякания. Получается левый предел сдвинуть от расслабления (3) до обмякания, а правый - увеличивается до сверхусилия
• Калибруют, учат дозировать усилия.
• Дифференциация усилий в напряг и в натяг - разные мышцы, противоположны, и важно напрягаться с расслаблением противоположных и наоборот, по всему телу, осознанно.

Каков результат такого подхода? При традиционном обучения танцам на достижение хорошего уровня уходит три года на каждый танец, и нет кумулятивного эффекта, потому что разные школы (бальные, сальса, танго, брейк-данс и другие) учат совершенно по-разному. А их подход позволяет за год - получить общую основу всех танцев, потом осваивать 5-6 танцев за год на том же уровне. То есть получается ускорение многократно. А если вам не нужен профессиональный уровень - то это еще быстрее.

Следующая задача - выходить на горные лыжи, серфинг и другой спорт. И они недавно делали доклад на профессиональных конференциях, сравнивали свои подходы с теми, кто профессионально тренирует спортсменов.

Дмитрий Сизов. Системный маркетинг и построение его онтики

Еще одна онтика, которую строит школа системного менеджмента для своих курсов - маркетинг. Потому что сейчас карта маркетинговых инструментов на одном из референсных сайтов - просто мозаика из 7000 инструментов, объединенных примерно в 100 групп. У Gartner есть карта диджитал инструментов в метро-метафоре, кто-то использует метафору города, и в целом получаются разнообразные кучи, не оставляющие особых шансов системно разобраться. Поэтому и сделан заход на онтику.

У маркетинга - две целевые системы:

• Продукт, который делаем
• Мозг потребителя, в котором формируется потребность

Задача маркетинга - связать Денотат, потребность потребителя с продуктом, и делают связывание через знак.

Дальше была онтика в схемах, которые можно будет увидеть в презентации, а я пересказать не могу. Но зафиксирую тезисы.

• Мы связаны с конкурентом только через ценности конкурирующего продукта, а не через рынки.
• Не удовлетворенность клиента, а его вовлеченность
• В физическом мире корелянт - уровень дофамина.
• У Котлера клиент один. А реально есть много, например, регулятор.

Дальше будут делать курс. Не маркетинг про связывание через знак, а продвижение продукта с вовлечением клиента, как часть системного предпринимательства.

Евгений Волков. Опыт разработки и апробации базового курса онтологии для гуманитариев

Это был рассказ о попытке построить курс онтологики, разворачивающийся от базовых вопросов и выбора базовых элементов. Нулевой цикл современной грамотности, до онтологии надо учить читать и писать... Курс был апробирован на студентах, и сейчас идет попытка внедрить в существующие образовательные институты.

С места был вопрос - а не поздно ли учить этому в 30+ лет, мозги не окостенели? Ответ - нет, не поздно, есть позитивный опыт.

Прапион Медведева. В любой необычной ситуации - моделируй

У Прапион есть задача: сделать, чтобы люди выделяли из мира полезные объекты и структуры, а не что попало. Очень многие люди этого не умеют, и это вызывает печальку и недоумение. Выделять нужно то, что позволит решить задачу, а не что учили выделять папа и мама, или то, что выделяет глючный мозг со своими когнитивными искажениями.

Дальше - конспект доклада. В замысле было обсуждение, но предыдущие докладчики рассказывали дольше, и тайминг обсуждения не позволил. Жаль.

Что есть сейчас.

• Учебник по системному мышлению
• Курс по онтологике и методичка к нему
• Почти есть курс по принятию решений
• И блоги. Очень разные и много.

Этого недостаточно.

Задачи.

• Люди все равно принимают решение не на моделях, а как попало
• Проседают навыки превращать модели в текст и обратно
• Навыки согласования моделей стейкхолдеров и коллективного моделирования
• Игнорируют достижения научного мышления за 200-300 лет, пользуются тем, что было 2000 лет назад
• коллективные взаимодействия про деятельность на моделях, особенно сложную - проседают

Кто должен решать эти задачи?

• Школа и университет. Превращение текста в модель и наоборот было у нее на обществознании. Но это - исключение, сейчас не решают.
• Консалтеры. Не слишком хорошо, обычно ограничиваются постановкой конкретных практик.
• Коучи, психологи, консультанты - работают индивидуально, и тоже налаживают жизнь, а не сделать полезное. 20 лет удовольствия - а проект не сделан.

Остается доп.образование, и оно должно решить эту проблему.

Линейка курсов.

• Основы онтологики
• Коллективное принятие решений
• Функциональная грамотность
• научное мышление в жизни
• Коммуникативные стратегии или как сообразить на троих

основы онтологики

• выделение объектов из фона
• работа с классификаторами
• 4d и прочее
• разные стейкхолдерские описания
• основы байесианства

Базовый курс - говорить об онтологиках.

Коллективное принятие решений

• поиск альтернатив и их оценка, не выбирать из одного варианта
• коллективное принятие решений
• стейкхолдеры и их интересы
• коллективные создания моделей
  • и дальнейшее использование моделей для принятия решений

функциональная грамотность

• медленное чтение, способы схематизации, схемы в голове и снаружи
• делать выводы из текста с учетом автора - герменевтика и стейкхолдерство
• разворачивание схемы в текст с учетом (интересов) читающего
• как делать схему, текст и другие модели из наблюдения за миром

Курс про научное мышление. Исправляем ошибки тех, кто должен учить.

• Уберем историю науки, займемся тем, что есть сейчас.
• Ошибки и искажения в понимании причин и событий
• гипотезы и их проверка
• байесианство и измерение чего угодно
• в каких ситуациях и как использовать инструменты современной науки

Курс по стратегиям коммуникаций

• занимательная конфликтология
• как распознать ситуации, где недостаточно понимания и подобрать стратегию
• методы разрешения споров и создания общего знания

Моделирование в любом контексте - большая схема. Из 6 шагов.

• Зачем нужна модель - всегда пропускают. И сразу строят модель
• Какие штуки есть в поле моделирования - и если пропустить первый пункт, то получается список всего
• Как штуки в поле связаны с полем снаружи.
• Подписать стрелочки связей
• Что происходит во времени
• Как участники моделирования и их роли относятся к процессу.

Кстати, у Прапион будет мастер-класс по моделированию в любом контексте на предстоящей 26/04 [KnowledgeConf.ru KnowledgeConf].

В вопросах. Что делать человеку, который попал в среду, где люди не умеют моделировать. Ответ: надо начать с первого вопроса - для чего вы делаете модель. И отвечая на него - моделировать.

Кирилл Гайдамака. Системная инженерия требований на практике

Кейс. Целевая система - автоматизированная сеть метеорологических радиолокационных постов. Включая мобильные, которыми тоже надо управлять. На предпроекте группу привлекали урывками и заказчик сделал дырявое ТЗ, это обычная ситуация. А потом выиграли конкурс, и задание надо выполнять. Надо было привести ТЗ к разумному уровню.

Области

• Анализ заинтересованных сторон
• Приоритизация
• Моделирование целей
• Моделирование сценариев
• Моделирование контекста
• Анализ развилок
• Написание требований - очень всего много.

Качество требований. Традиционно тут используют перфекционмстский список по качеству, и совершенствовать можно бесконечно. Практично: улучшить требования до определенной степени, так чтобы снизить риски неверных решений.

Что сделано

• Сортировка по уровням, тррассировка, закрытие дыр
• Дополнение - по встречам и нормативке.
• use case, оттрассирвоаны на требования и взаимно дополнены
• глоссарий и словарь данных
• use case увязаны с практиками ЖЦ

Попробовали enterprise architect. Очень быстро стало жать - потому что проблема вопрос доступности для стейкхолдеров. Confluence + Yogi - взлетел, но целостность глючила. Перешли на Archi + Bitbucket. Но начинается все со схемоидов на листочках и картинах в visio, примеры тоже были.

Дальше - скрины с реестрами usecase, требований и т.п. И отчеты - не просто матрицы, а всякие области непокрытые и т.п.

Отдельно - рассказ про переход black box -> white box для use case по мере конкретизации требований. Методологическая составляющая этого перехода не проработана, они для себя сделали.

Чтобы систематизировать большое количество use case, использовали стадии жизненного цикла. На слайдах раскрыты подробности о представлении жизненного цикла, там много интересных деталей. Например, эксплуатация - это не только использование по назначению, но и разворачивание, обновление и т.п. Декомпозиция практик, потом use case. И практики - всегда про людей, а use case - не обязательно. Например, ситуация грозы для мобильного поста.

В заключении Кирилл заметил, что использовать все это на проекте и сделать проект успешно получилось еще и благодаря курсам системного менеджмента и стратегирования, которые помогли выстраивать отношения со стейкхолдерами.

Александр Лучков. Средства поддержки моделирования

Александр - из Бортовые аэронавигационные системы. Живой системный архитектор, отечественный, которые работает по норме. Проект - 3 года, настоящее железо. Пробовали много инструментов (был слайд).

Модель должна поддерживать процесс коммуникации - и как раз из этого выбирали модель. Дальше была серия слайдов с видами моделей и инструментами для каждого вида коммуникаций. При этом много моделей использовались сразу для нескольких видов коммуникации. К сожалению, такому изложению не хватает оснований для конкретно этого выбора, а так же сценариев использования выбранных моделей для обеспечения эффективности коммуникации. Осмысление списка показывает, что он структурирован по фазам жизненного цикла проекта и последовательности принятия решений и, наверное, более удачным был бы именно рассказ в этом залоге, особенно если его вести не в текстовом представлен, а на диаграмме, в которой бы было показано разворачивание моделирования по времени. Впрочем, и в этом виде информация ценная. Привожу конспект, на слайдах було подробнее.

• Необходимость функционала: сценарии взаимодействия + контекстная модель. Инструменты - EA (не взлетело), Confluence (взлетело), Салфетки (для начального этапа хорошо, а потом в congfluence для сопровождаемости)
• Принятие решений о назначении системы и компонентов. Контекстная модель, модель потоков, структурные связи компонентов, модель , а потом моделер, не сразу.
• Принятие решений о технической реализации. Контекстная, архитектурная, потоков, в виде требований. Чем проще организовано обсуждение, тем быстро приходит. Важнее наличие обоснования решения, чем наличие модели. Модель без обоснования "почему" - затягивает коммуникации.
• Решения о последовательности выполнения работ. Модель ЖЦ и модель сценариев взаимодействия (единица реализации). От досок и салфеток до формализации. Тулы - постфактум.
• Необходимость документирования. Модель ЖЦ, схема деления, развертывания ПО. И! у разных инженеров - разные представления, какой должна быть модель. А именно это надо интегрировать. Confluence - спасение человечества.

Основные проблемы - организационные сложности и мотивация. Формальные методы - должны быть нужны тем, кто использует, без этого они не взлетают. Работает неформальное моделирование: доски, салфетки, фотоаппарат. Интересно, что они попробовали в духе DDD сделать единый язык, и это тоже не взлетело. Что, с моей точки зрения, не удивительно, язык не надо делать сначала, он должен прорастать, но на нем надо держать фокус.

Вячеслав Мизгулин. Product Studio - инструмент построения системных моделей

Доклад начался с проблематизации: в продукт-менеджеры приходят молодые без опыта, но с амбициями. Поэтому в портфель попадают провальные проекты. Ситуация усугубляется лозунгом, что продукт-менеджер не должен разбираться в продукте, это дело технарей. Дальше много досок, канвасов и совещаний. А разработка в это время реализует совсем другое, чем было придумано на досках.

Но для исправления ситуации могут позвать опытного продукта, и тогда он творит магию, как Гэндальф, и ситуация исправляется. Но Гэндальфов мало, они заняты и дороги, и это - реальная проблема. Поэтому предлагается заменить Гэндальфов новым продуктом Product Studio, который будет хранить всю нужную информацию и обеспечивать ведение проекта. Продукт есть уже в виде прототипа, можно пробовать использовать.

Что я об этом скажу? Чтобы заменить Гэндальфа, надо понимать, что именно он делает. Судя по метафоре, что он творит магию, разработчики продукта этого не понимают. Но у них есть гипотеза, что Гэндальф по сути увязывает практики жизненного цикла через рабочие продукты, помогает команде видеть контекст и смысл работы, а также проверяет проверяет проектные предложения и белые пятна. И даже если реальный Гэндальф творит какую-то иную магию, этих действий достаточно, а продукт их обеспечит. Он все помнит, данные хранит в тексте, отображает в разных представлениях. Данные хитро связаны, но положены в один инструмент вместо разнородного хранения в confluence, git, archimate. Менеджер при этом пусть видит свой любимый канвас, а системный инженер - свои любимые диаграммы.

Собственно, в этой гипотезе - основной фактор рисков проекта. Если эти действия смогут существенно повысить результативность в значительном числе случаев, то Product Studio имеет шансы на успех. У меня тут определенный скепсис, потому что в качестве основы заявлен ISO 42010, а я весьма скептически отношусь к стандартам как к средству обеспечить предпринимательскую деятельность. Так что есть шанс просто получить еще один вариант урезанного Enterprise Architect. А еще явно непонятно, как туда будут положены диаграммы на салфетках - а это очень существенный этап жизни каждой диаграммы...

Но, возможно, разработчики смогут довести методологию до хорошей результативности, пусть для некоторого класса продуктов. Тогда важно, чтобы методология была адекватно реализована в продукте, и надо поддерживать использование продукта развитием методологии и обучением. Тут есть позитивный пример Business Studio: это не просто еще один движок для описания процессов, это методология и система обучения и поддержки для тех, кто взялся его использовать на своих предприятиях, и именно это, на мой взгляд, поддерживает нишу, которую он занимает. Возможно, у Product Studio тоже получится.

А возвращаясь к тому, чем на самом деле занимается Гэндальф, у меня есть идея, что это можно получить анализом телеграм-проектов. Есть такой феномен, я о нем неоднократно слышу уже несколько лет. Люди научились делать проекты с синхронизацией через телеграм, при чем многие из них являются специалистами по проектному управлению и умеют делать проекты традиционным способом. Но способ через телеграм - легче, и позволяет им сделать те проекты, которые традиционному не поддаются. Собственно, проекты, которые делаются на людях и коммуникации были и раньше, но в телеграм все ходы записаны, можно анализировать проекты с разной успешностью и сравнивать их.

Антон Меркулов. Системный подход для разработки avtomotive IoT

Кейс - реинжиниринг системы бортового автомобильного софта, с выделением общего ядра, не зависящего от конкретного автомобиля и специализированных надстроек. Сам софт - для дополнительного устройства, устанавливаемого в автомобилях для каршеринга или для других целей, и обеспечивающего дистанционный контроль. Устройство имеет широкие возможности контроля управления автомобилем, и важно, чтобы его работа не посадила аккумулятор, не испортить работу автомобиля, заглушив двигатель на скорости, а не только обеспечила нужный контроль. Исходно софт разрабатывался исторической, поэтому никакой общей части не было, были отдельные прошивки под каждый автомобиль и потому проводить оптимизацию или реализовывать требования для конкретного клиента требовалось в десятке вариантов софта.

Самым интересным в докладе был способ изменения запуска проекта. Есть медленный и правильный путь: рисуем правильную архитектурную диаграмму, обосновываем эффект изменений и запускаем проект. А есть быстрый путь, которым пошли: найти не решаемую в архитектуре проблему, драматизировать, получить карт-бланш на решение. Второй интересный момент: при реализации учитывали закон Конвея, согласно которому для выделения ядра надо разделить команду, ограничив коммуникации, иначе никакой слабой связности не получится. Поэтому поделили на 2 команды, ядро и настройки.

Успех - проверено на практике, пришел клиент со специфическими требованиями, ему успешно сделали проект на общей прошивке, без изменения специфических частей под конкретные автомобили, при этом часть функционала обобщена и пойдет в ядро.

Антон Тюков. Тренировка навыков мышления в контексте изобретательства

Антон - мастерская смыслов Стратосфера]. Он рассказывал про свой инструмент http://thnktools.com для тренировки навыков решения изобретательских задач при конструировании бизнес-процессов. Выделили три основных навыка - выделение главной функции; определение обобщенных недостатков; применение приемов устранения недостатков (30 штук, Малкин). На каждый навык - знакомство со свойствами объекта, умение его опознать в задачах, и дальше тестирование результата. Тренировка 15 минут в день, 5 минут на упражнение.Три уровня: соотнести определение с ситуацией; опознать недостатки в реальных объектах; показываем изобретение - спрашиваем, по какой причине будет совершен переход. По сути тренируется овладение онтикой, понятийным аппаратом и умение соотнести ее с описанием ситуаций. Дальше они планируют развивать, заметая новые области.

Интересно, что в докладе использованы СМД-схемы: постановку задачи выделения главной функции показывали на основе схемы акта деятельности, на которой ставят задачу обеспечения инструментами, а работу изобретателя формулировали на основе шага развития.

Виктор Николенко. Опыт создания инженерных центров на базе системной инженерии

Виктор - советник гендиректора ИЛ, автор учебника по системной инженерии, 50 лет стажа инженера - авиастроителя. Он рассказывал о своем уникальном опыте проектирования, в котором за счет процесса проектирования обеспечивали качество, по максимуму исключающее доводку опытного образца.

Авиационные двигатели - четыре кейса времен СССР.

• Двигатель для самолета вертикального взлета и посадки - режим висения. Опытный образец летал. В серию не пошел.
• Двигатель для Калибра, первое поколение. Задача - срочно очень "другой" - через год сделали на стенде, всего за 4 года.
• Вертолетный двигатель для пустыни с пылезащитой. Сделали по чертежам, запустили - заработало. Прислали запрос "что сделали не так, так не бывает"
• ГД лазер непрерывного действия 1МВт в луче. Начали разработку, когда исчезли публикации, как оно было с атомной отраслью. Сделали прототип, потом в натуральную величину и 20 лет демонстрировался образец успешно.

Перестройка, работа с иностранными фирмами. И сделали более 20 контрактов с успехом. Некоторые контракты были жесткими, при отклонении параметров опытного образца от заданных более чем на 2% снижало оплату вдвое. Работа в GE-авиационные двигатели (до 2005 работало отделение в Москве, потом прикрыли). Уникальные проекты испытания двигателей. У GE - 10 фаз ЖЦ, они работали до 6 ворот. А дальше работали в инженерном центре Airbus 2006-2008. На входе центр генерировал убытки из-за проблем культурной совместимости их системной инженерии и наших конструкторов. Это он преодолел.

И дальше был методологический фрагмент, как это обеспечивается, к сожалению короткий. Декомпозиция: проблемы, времени, продукция, действий с последующей интеграции. Управление - деление менеджер проекта и главный конструктор. Главные конструкторы подчиняются генеральному.

С использованием этих принципов был реорганизован центр Технодинамика. В 5 городах России, в Уфе 3 площадки. Удаленный доступ, совместная работа и обучение в процессе работы. Дальше - репорт об успехах. Количество сотрудников выросло на 40%, выработку на сотрудника на 60%.

Как любопытная история - заказ на оптимизацию сумок техобслуживания для вертолетов. После оптимизации из 134 единицы инструментов осталось шесть, убрали дубли. А дубли, судя по всему, получились потому, что разработчик каждой системы предусматривал свой комплект для обслуживания...

Если говорить о задачах, то в авиастроении России она - в повышении производительности труда на сотрудника. По этмоу показателю мы отстаем даже от Бразилии. А еще системная инженерия - это непрерывное обучение, освоение смежных специальностей. И здесь тоже большие трудности, за 10 лет в Росатоме обучены сотни, а надо обучать тысячи специалистов.

Елена Ерошкина. Заметки трансформатора: опыт применения системной инженерии в enterprise

Это был рассказ о процессе трансформации в крупном торговом холдинге, который в докладе назван не был. У него 1000+ магазинов в России и СНГ. Долгое время был период успешного экстенсивного развития, и это было адекватно условиям внешнего мира. А теперь надо перейти к интенсивному развитию, потому что мир меняется. Темп изменений задают небольшие мобильные компании, и большие компании должны успевать изменяться в нужном темпе, раньше этого не требовалось, крупные компании могли идти существенно медленнее.

При этом начато изменение с IT-блока, потому что 85% изменений в компании - через IT, которое работает в режиме партнерства с бизнесом. Елена - заместитель Директора по IT, основные стейкхолдеры проекта - Генеральный директор и Директор по IT. Вовлечение - внимательно слушали, совместно учились, обсуждали.

Ожидания для бизнеса: уровень клиентских сервисов выше гигиенического уровня; увеличение темпов изменений; финансируются правильные вещи, которые делаются и делаются правильно.

Ожидания по IT: кратно увеличить скорость запросов на разработку, сохранив при этом существующую стоимость, сократить долю сопровождения, сократить долю эскалации решений до руководства.

Если вам про скорость - то agile и devops. И это про них, хотя еще 2 года назад они думали, что это не про них. И им надо удерживать архитектуру и работать со сложными системами - поэтому пошли в системную инженерию. Прошла курс Левенчука, потом Мизгулина. И применяла это в проекте.

Что было отмечено.

• Разные описания для разных стейкхолдеров. Модель. И даже рассказывать адресные описания стейкхолдерам.
• Лидер со знаком минус - он не просто противник проекта, обычно у него есть своя модель, отличающаяся от предлагаемой, по которой он пытается действовать. И ее надо понять.
• Самоопределение - ты как стейкхолдер, в каких ролях участвуешь. Переключение между ролями. "Я как архитектор". или "я как менеджер". Это сложно, надо учиться, и проходить больно.
• Создали концепцию, объяснили все команде и сказали - а теперь действуйте. И пошли массовые конфликты. Раньше она бы подумала, что люди такие - а тут поняла, что люди в роли не встали. И надо помочь. Product leader, Team Lead - явное разделение деятельности по ролям.
• Как найти свой продукт в Enterprise. В принципе, бизнесу понятно, как выделяется продукт, они могут с этим работать.
• Но есть подразделение, которое работают с клиентом - и они начали строить продукты от клиента, через клиентский опыт. И оказалось, что их продукты плохо соответствуют внутренним, и изменение клиентского продукта проходит через весь ландшафт. И это - вопрос сегодняшнего дня. И придется менять архитектуру предприятия целиком. Это повестка нынешнего года, и обещан рассказ через год.
• До этого они преобразовывали только IT. Надсистему, предприятие описали, но решили, что оно не наше, не меняем. А теперь увидели, что надо менять. Но! с самого начале - изменение в самом бизнесе, он тоже меняется и очень сильно. Налаживание архитектурной точки.
• Дорога - длинная. Потоковая организация работ. Перестраивают портфельное управление по-другому, в продуктовое. Определяем место продуктового управления. Верхнеуровневая карта есть.

И в заключении Елена отметила, что еще ни один проект не проходил у нее с таким классным исполнением. И это - как раз за счет применения методов системной инженерии.

Юрий Юрченко. Опыт применения практик системного менеджмента в сложном банковском проекте

Юра прошел обучение, и начал применять практики системного менеджмента. И доклад был рефлексией, что именно помогает, на конкретном кейсе разработки проекте по разработке нового банковского продукта. Детали продукта не раскрывались, в целом он должен был преобразовывать короткие деньги в длинные, и иметь очень большой ROI. За счет изменения рыночных макроэкономических условий за время разработки (сильно изменилось соотношение длинных и коротких ставок) ROI оказался ниже ожидаемого, но 200% за полгода они получили, двухкратно отбив затраты. Он вел проект в команде-генподрядчике, над проектом кроме нее работало 8 территориально-распределенных разнокультурных команд.

Интересно, что аналогичный проект пытались создать раньше - не взлетало. И на старте провели анализ, почему те проекты оказались похоронены. Получились распространенные проблемы: попытка создать систему без работы с возможностью; делали систему для всех, без стейкхолдера-адресата.

Оценивая опыт, критично: проектирование+архитектура; стейкхолдеры, ответственность за людей, единый словарь.

Проектирование архитектуры - сработало.

• Не было глобальных провалов и переделок.
• Хотя команды не слишком хорошо понимали функциональную архитектуру. Лучше - процессы и потоки данных. Не хватало навыков работы со схемами и онтологиями.
• Однако, получилось сделать не точечное решение, а более широкое, с перспективой развития на аналогичные продукты. И если рынок изменится благоприятным образом и откроет возможности, то это окажется востребованным.

Ключевые факторы погружения в функциональную архитектуру

• Глубокое погружение в предметную область -- книги
• систематизация, схематизация, моделирование предметной области -- в книгах хаос, особенно по новой области
• верификация модели с основным стейкхолдеров, работающим на языке возможности
• не надо спрашивать пользователя "как ты работаешь" - получишь ответ "прихожу в 9 утра", адекватный вопросу
• анализ аналогичных решений от конкурентов - там много интересного.

Архитектура должна быть предметом коммуникации, а не красивой бумажкой.

Работа со стейкхолдерами.

• Список
• Разделение по аспектам коммуникаций: возможности, проектно-административный, архитектурный, аналитический
• Систематизация коммуникаций.
  • Роли и результаты
  • надо разводить людей с разными культурами и убеждениями: адептов PMI и Agile в одной комнате не собираем

Ожидания и результаты совпали. Цели достигнуты, система передана в эксплуатацию, стейкхолдеры довольны. В общении выяснили 10+ задач, чтобы получить платформу.

Практики устранения асинхронности информации (неполноты информации у участников проекта) - погружение команд в полный контекст, представление целевой и использующей подсистем, в результате команда сама могла доработать решения. Для одной команды прошло хорошо, но при масштабировании на все команды не все гладко, команды не могли принять решение из контекста всей системы, и не принимали общую цель, иногда хотели свой участок. Однако, у них ситуация, когда дополнительные команды работали над системой не full-time, а примерно на 20%

Николай Варич. Канбан путь в Agile сквозь жизненный цикл

Интересный и характерный кейс. Из производственной компании от собственника-директора приходит запрос на проектное управление. По факту компания небольшая, 20 человек, и построена вокруг директора, который является уникальным специалистом, и потому делает эксклюзивные заказы на изготовление и монтаж оборудования не только в России, но и за рубежом. Но при этом исполнение заказов сильно хромает, плюс большая текучка кадров.

Николай взялся, ему было интересно, но при этом понятно, что классическое проектное управление компании не нужно. Он рассказывал историю успешного преобразования, и, на мой взгляд, многие эпизоды и приемы в ней являются достаточно характерными.

Начали с обследования, которое и вскрыло, что компания крутится вокруг директора, который один понимает, как проходят заказы, и сколько открытых заказов вообще есть в работе. И сразу рассказал 32 практики, которые обеспечивают прохождение заказов, за пару недель вспомнил еще 32, а после описания их число дошло до 121. При этом траектория проекта практически задана на этапе заключения контракта, именно поэтому регулярное управление проекта не нужно - бюджет и скоуп зафиксированы, управлять нечем.

После обследования - сделали Kanban-доску с 14 стадиями, визуализировали процесс по актуальным заказам. Карточки на магнитах, цвет магнита соответствует менеджеру, который заказ ведет - такой простой и наглядный способ. Понятно, что когда людей много, магнитами не обойдешься, тогда эффективны аватары или фотки, важно, чтобы они опознавались при взгляде на доску.

Дальше надо было учить с этим работать. Для обучения выбран модный scrum, именно потому что он модный и легко продается, другие варианты не прошли бы. Обучились. И стали на провальных проектах делать планирование по scrum. На голосовании пошли коммуникации, люди в команде проекта начали чувствовать друг друга, а до этого все общение шло только с директором. И как результат - начали делать чеклисты, записываться планы, и работа начала налаживаться. Собственно и произошел перелом, перестройка бизнеса.

Дальше надо было снимать с директора уникальные компетенции. Было ясно, что директор не будет учить всех. Поэтому выбирали талантливого, ему объяснял директор, он остальным. Теперь в компании есть один обученный проджект, и один инженер, который взял главного инженера.

Дальше сегментировали заказы, получилось 5 типа заказов с разным размером и жизненным циклом. Людей научили работать с задачами, с физической доски перешли в bitrix. Но важно, что система - не сразу, без физической доски с листочками это бы не получилось. Некоторое время жили обе доски, электронная и физическая, и, что интересно, первичной была именно физическая, потмоу что она стала местом сбора и коммуникаций сотрудников, поэтмоу перед летучкой электронную синхронизировали.

Клиент был доволен, считает, что на 1/3 пути прошли. Трансформация будет развиваться. Текучка пока есть, но они удержали ключевых. А большая текучка связана с сезонностью работ, и они думают, что с этим делать.

Данила Медведев. Наука и инжиниринг на примере развития и кризиса нанотеха

Очень интересный доклад, который состоял из двух частей. Первый - исторический обзор развития идеи нанотехнологий, со смещением от первоначальной идеи нанороботов. Ее впервые высказал в 1959 Фейнман в лекции "Там, внизу полно места", в 1976 подхватил Эрик Декслер, и с 1986, после выхода его книги Engines of Creation пошло развитие идеи и ее институализация на уровне правительства и корпораций с выделением финансирования созданному для Декслера Foresight Institute.

А потом, в 2002-2004 произошло резкое смещение, в котором велика роль и конкретных личностей и корпораций. Вместо Декслера отцом нанотехнологий был назван Ричард Смоли, Нобелевский лауреат, который идею первоначально поддерживал, а потом заболел раком и сменил мировоззрение. Десклер развелся со своей женой, Кристиной Петерсон, которая была администратором Foresight Institute и после развода оставила его себе вместе с финансированием, а сам Декслер оказался на грани банкротства. А еще Билл Джой, со-основатель Sun, напугал всех, что наноботы завоюют мир. В результате идею наноботов вычеркнули из нанотехнологий. Но это все - поверхностно, на личностях. А если перейти на уровень корпораций, то видна другая картина: в идее нанороботов продвинуться в принципе не смогли, а деньги-то надо осваивать. И решили осваивать их на материалах с наночастицами, благо как раз пришла их эпоха. Чем успешно занимаются и сейчас.

Но ключевая идея Декслера, что нанотехнологии - это сборка структур из атомов в наномашины, оказалась размыта. Их не могли сделать, а потом и решили выкинуть, чтобы никто не пугался. Ретроспективно анализируя эту историю можно сказать, что это - частный пример отсутствия системного управления развития науки. В том числе - потому что системная инженерия не работает с моделями социума, сознательно оставляет их за рамками.

Это была критическая часть доклада. А дальше была конструктивная. Идея наноботов Даниле близка, а ключевая проблема - в том, что в дизайне наноботов, то есть механизмов, собранных из атомов и молекул, продвинуться не смогли. Даже неа уровне статей и презентаций нет ни одного реалистичного дизайна, не взирая на потраченный на тему триллион долларов. И Данила делает ставку на детей, которые не отягощены шорами взрослых ученых. Делает конструктор в виртуальной реальности для сборки атомов и молекул, по принципам Lego и Minecraft, который можно использовать для обучения химии, включая, как я понимаю, молекулярные биохимические механизмы, работающие на клеточном уровне. И надеется, что дети не только будут собирать реальные молекулы и известные механизмы, но и построят виртуальных нанороботов - после чего можно будет подумать о способах воплощения в физическом мире. Такой вот проект, который сейчас идет, без всяких Роснано и других институтов глобально изменить мир.

Виктор Минакер. ТРИЗ. Метод выбора решений

С моей точки зрения, достаточно странный доклад. Виктор полемизировал с теорией принятия решений на основе многокритериальной весовой оценки, обосновывая, что максимальная оценка - не всегда хорошо, для многих величин есть интервал достаточного и не чрезмерного значения, и выбирать конкретный вариант надо на основе попадания в этот интервал, который рекомендуется разбить на две области: хорошо и терпимо. Апеллировал он к ТРИЗу, который говорит, что любая функция может выполняться хорошо, недостаточно или избыточно. На мой взгляд, мысль очевидная, но при этом второй способ оценки легко приводится к первому простой заменой шкал. И потому к обоим вариантам применима вся та критика в части произвольности формул или оценок экспертов или по другим основаниям, о которой Виктор говорил по отношению к первому способу оценки.

Но предварял эту часть доклада довольно интересный обзор всяких экспериментальных самолетов и танков с фотографиями, которые строились перед второй мировой войны и не пошли в серию из-за своей монструозности. Это было любопытно. Жель, что без ссылок на конкретные названия. Впрочем, по картинкам в презентации все можно найти, одна из них - справа, впрочем, на ней изображен не реальный самолет K-7, а фантазии по мотивам... Эти примеры должны были иллюстрировать примитивное и дефективное решение человека, способное удержать только 6 объектов внимания, имеющее более 100 дефектов - когнитивных искажений.

Роман Чеботарев. ИИ. Стратегирование в условиях ежемесячной смены SoTA

Очень интересный доклад об организации работ в области искусственного интеллекта для обработки больших данных, где направление движения меняется каждые 3 месяца после выхода очередной статьи. Их компания применяет новые методы для того, чтобы качественнее управлять высокотехнологическим производственным оборудованием, таким как колонны аммиачного синтеза, или управления грузовиками - первый автономный БелАЗ сейчас ездит в Марокко. При этом оборудование часто уникальное, двух одинаковых колонн синтеза в мине ре существует, хотя общее число относительно велико. Особенность ситуации в том, что эти новые методы очень быстро становятся доступны публично: после выхода статьи через 4 дня код появляется на github и его можно использовать в своих проектах, а новые статьи выходят каждую неделю. И получается надо принимать решения: пытаемся мы встроить конкретный новый метод в существующий продукт для наших клиентов, или создать на их основе какой-то новый продукт, или пока нет.

Что они делают в этих условиях?

• Систематический поиск и отбор лучших технологий
• Горячая замена технологий на самом продукте
• Пристальное внимание к технологиям на предмет создания нового продукта или отстрела старых

Как делаем

• RnD отдел из 2 человек - поиск чего в мире происходит. Они выносят список интересного найденного.
• Директор по развитию создает команду анализа - технологи + экономисты
• Первичный анализ: ничего ен произошло/накопали интересную технологию
• Дальше мы смотрим на рынок. - возможность.
  • Если кто-то сейчас подхватит технологию - целесообразно ли нам заменять продукты?
  • И если да - то отдельная группа с потенциалом отдельного бизнеса.

Примеры

• Закрыли внутри process control в химии и нефтехимии - контроллер с обратной связью для возвращение к норме, потмоу что появились возможность технических решений на ардуино - они закрыли направление
• Открытие продукта для планирования операций на заводе. Текущие методы упираются в пределы размерности и потому работают в упрощенных моделях. А сейчас вышли публикации и код по технологиям neural combinational optimization - и это принципиально позволяют увеличить детализацию задачи планирования с повышением качества, увеличивать вариативность. Например, увеличиваем производительность с увеличением износа - насколько оно целесообразно.

Вопрос - почему вы не идете от клиентов, а мониторите технологии. Ответ: высококонкурентный рынок. Задачи клиентов известны, вопрос в том, дадут ли какие-то технологии существенно новое решение? Клиенты тестируют покупку, разные технологии на решение тестовых задач - и им получать конкурентное преимущество.

На этом я завершу отчет о конференции.