Как создать модель рабочей практики в формате научной статьи?

Я вел своих детей в детский сад и школу, и младшая спросила меня - а почему когда мы идем, то фонари двигаются на нас, а Луна улетает от нас, двигается туда же, куда и мы? Я немного подумал, и понял, почему так кажется. Дело в том, что люди воспринимают скорость как изменение угла и размера, а тут ни угол ни размер не меняется, и значит, далекие объекты кажутся нам неподвижными, или, если мы идем или едем, "двигаются" вместе с нами. В тот момент я понял, что машинально сделал то же самое, что делаю по работе - я смоделировал рабочую практику, в данном случае практику измерения расстояний. Я взял набор базовых фактов, про то, что фонари двигаются на нас и увеличиваются, а Луна двигается с нами и не меняет размер. Я взял концептуальную схему из трех понятий - угловая скорость, угловой размер, скорость наблюдателя, которая объясняет базовые факты и может достоверно их предсказать (когда мы пошли задом, Луна стала на нас надвигаться, а фонари поползли назад и уменьшились).

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

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

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

Системная инженерия наработала конкретные приемы:

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

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

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

Что такое модель?
Модель - это структура, которая описывает область обсуждения. Модель состоит из концептуальной схемы (структуры фактов) и набора базовых фактов, относящихся к области обсуждения.

Другие определения

Область обсуждения (universe of discourse, domain): совокупность физических или абстрактных объектов, относящихся к области реального мира, которые выбраны в соответствии с интересом, который они представляют для системы, подлежащей моделированию, и ее окружением.

Метамодель - модель, которая описывает другую модель.

Шаги создания метамодели практики:

Проблема 1. "3 километра терминов и определений". Решение - структурирование области обсуждения (domain partitioning and contexts definition). В хранилище проекта должна появиться папка "Область обсуждения".
Проблема 2. "А что такое вещь?". Работы как вещи, процессы и проекты как типы работ. Решение - определение состояний вещей, выделение стадии использования. Необходимо пересмотреть описания процессов и планы проектов.
Проблема 3. "Как объединить каталоги?". Решение - PBS, WBS, SBS и другие разбиения. Универсальных решений нет, но подход единый.

Проблема 4. Измерение неизмеримого. "Что измеряет панель Google Analytics?". 

Решение - концептуализация предметной области как заказчика так и разработчика плюс операционализация концептов.

Создание и применение (мета)модели практики для выявления и прохождения развилок проекта (project and design trade-offs). Научные статьи как метод рефлексии над ходом проекта и принятыми решениями.

Getting things done in greenfield is no more an option for EA

Сложно рекапить последнее выступление Марка Ланкхорста (видео, слайды), потому что идейно мы с ним очень близки, а BizzDesign дает реально лучший инструментарий для применения практики архитектуры предприятия. Поэтому я помещу тезисы его выступления в контекст и разверну один аспект, который он только слегка засветил на вебинаре.

Это выступление было в стиле data fusion, объединение различных источников в связный рассказ.

Источники идей, которые засек я:

Chess And The Art Of Enterprise Architecture, Blame the Mathematicians! by Gerben Wierda
What color is your backlog by Philippe Kruchten
The architect elevator by Gregor Hohpe

Software Architecture Guide by Martin Fowler

Центральный слайд вебинара, пожалуй, этот:

Но интуиция этого слайда некорректна, т.к. дальше невысказанной главной мыслью повествования идет "пункт назначения меняется за время путешествия". То есть лесенка справа должна вести не в ту же точку, что и слева. В текущем виде это выглядит просто декомпозицией большой цели. NI, not interested. Должна быть некая окрестность пункта назначения, которая и символизирует Эджайл. Ключевой метафорой тут является шахматный ход, когда мы не знаем конечной цели проекта автоматизации, мы лишь можем улучшить ситуацию на доске здесь-и-сейчас. Серия таких улучшений эволюционно удерживает предприятие в окрестности выживания, а не ведет к светлой цели, установленной всеведущим начальством.

Вообще, для разбирательства с идеями BizzDesign о том, как устроено проектирование и перестройка предприятия, надо вначале разобраться с понятиями Эджайла, которое противостоит GTD, getting things done.

Getting things done на русском означает "добиваться желаемого положения дел". Когда начальство говорит эту фразу, само собой разумеется что:

Начальство знает, как должно быть
Исполнители знают, как прийти в нужную ситуацию
Исполнители готовы взяться за работу под те ресурсы и ограничения, которые выставляет начальство

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

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

Добавляем в эту исходную ситуацию, когда стороны договариваются кто что кому почему и когда, неопределенность. Начальство (Заказчик) не знает, что хочет, по крайней мере вначале. Исполнители не очень хорошо понимают как они все это сделают и кто им в команду нужен. Технологии меняются. Плюс, проект исполняется не в чистом поле, и не с молодежью, которая готова освоить любую новую онтологию и радостно ее применять, а на работающем предприятии, с опытными работниками, которые забыли больше, чем молодежь когда-либо знала. Фактор brownfield, горы неотрефлексированных рабочих практик, отлаженной и работающей бизнес-машины, которая не может измениться быстро. Она может эволюционировать. Здесь неприемлем Скрам, который требует, чтобы перестроились все, вплоть до совета директоров, здесь не работает SAFe и Less, но, наверное, взлетает канбан метод эволюционной перестройки либо директивный водопад.

И тут я думаю, что канбанисты и архитекторы предприятия переизобретают велосипед, который придумали социологи, которые занимаются Science and technology studies и изучают социологию повседневности через практики. См. краткий обзор Виктора Вахштайна про онтологический поворот (видео).

Собственно, мое текущее направление исследований про boundary objects, трансдоменные объекты, которое я начал после прочтения Architectural Coordination of Enterprise Transformation ровно про то, как вытаскивать интуитивное понимание предметной области в более-менее формализованном виде, достаточном для дальнейшей координации в режиме SAFe/канбан.

Чисто практически это означает, например:
- итерации архитектуры с учетом в Jira. В каждой задаче можно создать ветку архитектуры проекта, в которую входит как системная архитектура, так и корпоративная архитектура. Именно возможность менять архитектуру через трекер и есть эти самые маленькие итерации, которые показывал на слайдах Марк;
- последовательности собраний. Ветки должны попадать в meeting sequence, как минимум арх.совет (пн.), change approval board (вт.), project status review (ср.), результат докладываться спонсору/директору проекта;
- жизненный цикл объектов и отношений. Если мы говорим про постоянное обучение, то как отражать в модели это постепенно возникающее понимание? Как отделить догадку от сформулированной и подтвержденной гипотезы, как указать на микротеорию? У объектов и отношений должны быть соответствующие атрибуты - "внесен со слов стейкхолдера", "проверен по литературе (сопоставлен с дисциплиной)", "операционализирован", "подтвержден(-а"", "опровергнут(-а)". У объектов и отношений должен быть владелец, автор, кто носит полные знания об этом куске модели реальности, у кого можно спросить, что же имеется в виду.

Выводы:

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

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