среда, 11 марта 2020 г.

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

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

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

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

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

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

Что такое практика?

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

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

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

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

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

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

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

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

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

Комментариев нет:

Отправить комментарий