Рабочий вариант модели практик и ролей

Новая грамотность
1

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

Получилось, что центральной сущностью в схеме описания оказалась практика.

image-58
image-581024×566 237 KB
Схема описания
  • Навык рассматривается как один из многих компонентов практики, которые могут иметь различный уровень владения пользователем. Например, практика ведения совещаний может использовать навыки активного слушания, модерации и саммаризации, каждый из которых прокачивается самостоятельно, но все они нужны для успешной реализации практики.
  • Привычки рассматриваются как триггеры, возможности, выделенные ресурсы времени и сил, позволяющие реализовать практику. Дискутабельно, относятся ли привычки к практике или отдельным навыкам практики в строгом смысле. Пример: практика конспектирования требует привычки иметь открытый Obsidian для ведения исчезающих заметок
  • Картина мира используется данной практикой. Например, практика ведения списка дел и проектов основывается на картинах мира "Джедайских техник" и GTD.
  • Стандарт описывает минимальные требования к рабочему продукту, при котором ролевой интерес будет удовлетворён. Например, исчезающие заметки должны быть написаны своими словами, быть полны и содержать возникшие во время чтения вопросы и ссылки на упомянутые дополнительные источники.

В результате, получается ряд таблиц вида

image-59
image-591024×246 56.1 KB
Таблица с практиками, work-in-progress

Ценность, которую я, как мне кажется, получил из создания данной модели:

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

2

Антон, отличный способ схематизации, но к формулировкам есть ряд вопросов.
— Навык — это умение, способность деятельности. Компонентом мы называем конструктивную часть системы, а практикой — само действие. Поэтому навык не может быть компонентой практики.
Все перечисленные вами “навыки” (“активного слушания, модерации и саммаризации”) — это тоже практики, и в них человек либо имеет навык, либо нет — действует с различной степенью “профессионализма” (см. квадрат компетенций в главе 3, раздел Осознанность).
— Можно рассматривать привычку как триггер, так как с ростом становления привычки она стимулирует выполнение практики, но привычка не равна практике. Практику вы выполняете. Вы можете выполнять практику систематически, но это может не стать вашей привычкой. Например, приехали в отпуск, каждое утро ходите на пляж загорать — 10 дней выполняли практику приёма солнечных ванн, вернулись домой, практику выполнять перестали.
— Картина мира это то, что обуславливает ту или иную практику, а не “используется ей”. Выполняя практику мы используем технологию (инструмент) и дисциплину (знание).
— Стандарт (как свод правил) может описывать некий рабочий продукт, но “интересоваться” (role preference) этим продуктом могут разные роли, и кому-то (какой-то роли) нужно чтобы заметка была “написана своими словами”, а кому-то — “была написана быстрее”.

Для разбирательства с отношениями понятий главы можно посмотреть соответствующие таблицы в курсе “Тренажёр системного мышеления”

3

Поддерживаю Ivan Metelkin по поводу навыков.
У меня всего одна таблица. В ней и навыки, и просто регулярные задачи, и задачи, к которым есть какие-то инструкции или чек-листы (СОП), и целые (бизнес-)процессы.
Эта таблица связана с самой собой “входит в/включает в себя”, так что, к примеру, “навык” “Программирование на Python” без проблем группируется в “практику” “Анализ данных”.
“Привычка” это просто свойство (статус, флаг) в этой таблице. Или даже формула: если практика выполняется регулярно, но расписание для таск-менеджера не установлено — значит это привычка.

“Рабочий продукт” я бы переименовал в просто “Класс” (мета-модели). “Продукт” — это роль в отношении “создаёт”. Но есть ведь и обратное отношение: “потребляет” или “использует”. “Мышление письмом” потребляет “Исчезающие заметки”.
Если ввести оба отношения, можно будет построить диаграмму потоков данных.
Классы можно разделить на “конечные” и “промежуточные”. Что это даст? Например, у нас начали накапливаться “исчезающие заметки”. Это “промежуточный” класс — значит, такое накопление создаёт проблему. Смотрим, какие практики создают этот класс, а какие потребляют. И работаем и над первыми (понижаем скорость, частоту, длительность и т.п.), и над вторыми (соответственно повышаем). В общем — управляем проходом данных.

Помимо связи с рабочими продуктами (или классами), стандарты ещё связаны с практиками, 3 отношениями:

  1. Практика предназначена для поддержки стандарта (это взгляд P.A.R.A. - области имеют стандарты, которые требуется бессрочно поддерживать. Т.е. это способ группировки практик и соотв. им задач по областям). Стандарт “Входящие разобраны” поддерживается практикой “GTD”.
  2. Практика проверяет выполнение стандартов. Пройтись по списку стандартов, оценить, выполняется ли этот стандарт, а если не выполняется — запланировать какие-то корректирующие действия. Скорее всего это будет одна практика для всех стандартов, что-то типа ежемесячного или полугодового обзора. Но, например, у меня несколько стандартов проверяются отдельно от такого обзора, в других практиках. Практика “Проверка наличия продуктов в холодильнике” проверяет выполнение стандарта “Продукты в наличии” (но, в отличие от 1, эта практика не поддерживает этот стандарт, она просто фиксирует что стандарт не выполняется)
  3. Стандарт должен выполняться в процессе практики. Например, стандарт “Я использую левую руку” должен выполняться в ходе практики “Бритьё”.
    Такие стандарты создают или убирают побочные эффекты, но не влияют на рабочий продукт (если он вообще тут есть).

“Интереса” в моей модели пока нет. У Вас получается его выделить? У меня есть гипотеза, что “интерес” это тот же самый стандарт (если он постоянный) либо какое-то разовое требование.

P.S. used_by_roles

4

ох, ну вы запутали больше, чем распутали.
не понятно примерно всё:
— Сложную деятельность вы не опишите одной таблицей, у вас обязательно должны появиться представления для разных ролей, даже если эти роли играете вы.
— «Рабочий продукт» я бы переименовал в просто «Класс» (мета-модели).
“Рабочий продукт” — это тип, концепт ментального мира. Для бухгалтера рабочий продукт — это финансовый отчёт или сданная декларация, для режиссёра монтажа — final cut.
— «Продукт» — это роль в отношении «создаёт». 
Продукт — это не роль. Роль — это функциональный объект. Не сам объект, а поведение, которое выполняет объект.
— «Мышление письмом» потребляет «Исчезающие заметки».
Мышление письмом ничего не потребляет, это практика. Исчизающие заметки — это технология. Агент (человек в роли исследователя, например) с помощью исчезающих заметок (я ряда других технологий) применяет мышление письмом.
— Данными мы управляем на основании определённой дисциплины — Data Management. Если вы берёте понятие “промежуточный класс” из этой дисциплины, это ок. Если вы его выдумали, это не ок.
—  Практика проверяет выполнение стандартов. 
Нет. Практика — это поведение, действие по какой-то дисциплине с помощью какой-то технологии. Поведение ничего не проверяет.
— Скорее всего то, что вы называете “стандартом”, это чеклист, какой-то документ (описание), с помощью которого проверяем “сделано/не сделано” и как должно быть сделано. Даже в этом случае “стандарты” ничего не создают — люди в ролях создают описания и следуют им, чтобы удовлетворить свои потребности.

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

Обязательно обратите внимание на долгосрочную программу ШСМ (описание у Левенчука Проблемы описания учебных программ. Пример: "Системный менеджмент и инженерия" : ailev — LiveJournal) С вашей любознательностью её усвоение это только вопрос времени. Пользу почувствуете сразу — вас люди понимать начнут, что и зачем вы говорите.

5

Иван, спасибо за комментарии. Долго не видел его, т.к. не разобрался с уведомлениями.
Прежде всего, я делал эту схему в рамках курса “Системное саморазвитие”, с другими курсами Школы пока не знаком и фокусировался на личных проектах.
Надо понять, где мы имеем дело с терминологическими расхождениями, а где с архитектурными.

  • Например, навыки выделены в отдельную сущность потому, что они по отдельности не дают интересующего меня рабочего продукта. Их можно заменять, например саммаризацию заменить на распознавание речи и GPT. Мне это было интересно, как разные уровни методологии.
  • С привычками, видимо, я не иллюстративно нарисовал стрелку. Привычки в данной схеме запускают практики. Например, чтобы запускать практику управления задачами, надо иметь привычки смотреть в таск-менеджер, делать еженедельный обзор и так далее.
  • Я не понял терминологическую разницу между "использовать" и "быть обусловленным"
  • Поскольку я пытался рассмотреть личные проекты и роли, смоделировать конфликт интересов мне как-то в голову не пришло, вероятно, зря...
Подумаю, как учесть в следующей итерации.
6

Сложную деятельность вы не опишите одной таблицей, у вас обязательно должны появиться представления

Так представления или таблицы?
Если объекты одного класса (одинаковые свойства), тогда достаточно одной таблицы (БД Notion). А представлений с фильтрами можно наделать сколько угодно.

7

да, я именно об этом. Для проекта выделяются роли, под роли формируются view (от общей БД)

8

Антон, привет) как успехи с моделированием?

подготовил простой шаблон, который помогает связать роли и рабочий продукт (для простоты обозначил его результатом). Будет интересно услышать твоё мнение.

9

Иван, всё-таки, почему у нас не получилось договориться по “Класс” и “Продукт”?
Т.к. комментарий был большой, я пропустил некоторые фразы, в надежде что и так будет понятно. Но видимо непонятно — пытаюсь понять, что конкретно.

Вы пытаетесь перепридумать онтологию системного мышления, а она уже есть

Перепридумать онтологию не пытался. Очень жаль, что Вы не смогли понять мой комментарий.
А вот допилить мета-С-модель для применения в Notion — да, пытаюсь.

Продукт — … Не сам объект, а поведение, которое выполняет объект.

С этим я полностью согласен. Я назвал это поведение “ролью”, в школе, насколько я понял, для неодушевлённых объектов используют термин “функция” (“функциональное рассмотрение”). С моей точки зрения это суть одно и то же. На “Продукт” это неочевидно, лучший пример это “Исполнитель”. Поэтому я это называю просто “ролью”. (может быть это моя личная профессиональная деформация?)

Моё предложение заключается в том, чтобы не моделировать “продукт” как отдельный класс объектов ментального пространства.
Потому что получаются пересечения. Допустим, рабочим продуктом практики “Постановка привычки” является привычка (экземпляр класса Привычка). Но Привычка у нас и так выделена как класс.
Получается дублирование: “привычка как экземпляр класса Привычка” и “привычка как экземпляр класса Рабочий продукт”.

Ментально это нормально.
Но в Notion — как и в большинстве подобных инструментов — нет наследования и множественной реализации.

Поэтому я бы добавил кусочек мета-модели и с её помощью нормализовал структуру. “Рабочий продукт” — это название колонки в таблице практик (= название отношения). А ссылается эта колонка на таблицу классов.
Замечу, что на приведённом скриншоте — в “Рабочих продуктах” уже частично указаны не конкретные экземпляры классов, а сами классы (“Исчезающие заметки”).

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

Это всё относится к модели в Notion. Если рассматривать только диаграмму на первой картинке, в ней “Рабочий продукт” нормально смотрится.

Что касается связей практик и стандартов:

  • Я не понял, где вы прочитали должествование. У каких-то практик есть такие связи, у других нет. Я просто обратил внимание, что такие связи могут быть, и их можно добавить в модель. При необходимости.

  • Практика — это поведение, действие по какой-то дисциплине с помощью какой-то технологии

    Если пользоваться этим определением, то проверка — это тоже практика. Допустим, “испытание металла на прочность”. С использованием дисциплины “сопротивление материалов” и соответствующих технологий.

    Но откуда Вы сделали вывод Поведение ничего не проверяет? Если я правильно понял, далее Вы ошибочно сузили определение практики только до практик по созданию, а все остальные исключили из рассмотрения.

    Сами по себе стандарты ничего не создают — согласен. Но в результате проверки выполнения стандартов что-то всё же может создаваться.
    Рабочим продуктом практики по проверке — могут быть заполненный чек-лист; продукция, рассортированная на “прошедшую проверку” и “не прошедшую”; список замечаний и план работ по их устранению (возможно пустые), или наконец просто уверенность, что всё Ok.

10

— Нам будет проще договориться, если мы примем методологию ШСМ за базу.
— Вы кусок контекста вырвали из цитаты: “Продукт — … Не сам объект, а поведение, которое выполняет объект.”
— Продукт — это как раз физический объект. У него есть размеры, он существует в пространстве-времени. “Не сам объект” — это роль. Роль — ментальный объект. Ни размеров у него нет, ни понятие времени к нему не применимо.
— “Привычка” — не объект. Соответственно экземпляром класса “рабочий продукт” он быть не может.
— “Проверка — практика”, совершенно верно. В этом выражении “практика::тип”. И поведение::тип. Когда я говорю “поведение ничего не проверяет”, я имею в виду, что если мы не уточняем конкретную практику/поведение (в вашем примере “испытание металла на прочность”), то оно ничего не проверяет. Тип ничего не проверяет.
— В вашей формулировке “Рабочим продуктом практики по проверке” есть морфологическая ошибка (если я правильно её классифицировал). Верно: “Рабочим продуктом по практике проверки”. Проверка::практика. И “уверенность” сложно считать за рабочий продукт — о границах не договоримся.

11

Продукт — это как раз физический объект. У него есть размеры, он существует в пространстве-времени. “Не сам объект” — это роль. Роль — ментальный объект. Ни размеров у него нет, ни понятие времени к нему не применимо

  • Если мы рассматриваем практику как физический объект (т.е. конкретная реализация, например, “пекарь Анастасия прямо сейчас печёт пирог”), тогда согласен, в этом случае “продукт” физический объект, а “роль” — ментальный
  • Но я полагаю, что нас интересует не одна эта ситуация, а набор связанных. Например, добавляем следующую практику “приём пищи”. Чтобы связать их между собой, добавляем в нашу модель объект “пирог”. И в такой объединённой модели “продукт” получается уже тоже “не сам объект”, а лишь отношение между практикой и физическим объектом (т.е. ментальный объект). Пирог является продуктом только по отношению к первой практике, а по отношению ко второй — является исходным материалом.
  • Плюс полагаю, что (в модели в Notion) нас вообще интересуют не конкретные экземпляры практик и продуктов, а интересуют абстрактные (“в целом”). А тогда у нас всё — и практика, и продукт, и роль — ментальные объекты. На скриншоте сделано именно так — тут нет времени, это всё не конкретные реализации и не физические объекты

“Привычка” — не объект

Мы говорим про конкретный экземпляр (допустим, привычка конкретного человека “отвечать на входящие письма в тот же день”) или про привычка::тип?
Если конкретный экземпляр, то почему не объект?
Существует в физическом мире и есть временные границы существования (когда привычка появилась и когда владелец от неё избавился).
Да, может быть сложно провести границы. Но в курсе приведён пример “разговор”. С ним те же проблемы, и тем не менее мы его выделяем (или пытаемся выделить) как физический объект.

Соответственно экземпляром класса “рабочий продукт” он быть не может

А как бы Вы смоделировали “практику по постановке привычки”?

“Рабочим продуктом практики по проверке” … Верно: “Рабочим продуктом по практике проверки”

  • “Продукт по практике” vs “Продукт практики”
    По аналогии, “Исполнитель роли”. В курсе используется этот вариант.
    Вариант “Исполнитель по …” мне встречался, но согласно гуглу, употребляется гораздо реже. Считаете, что это нормативный вариант?
    Может быть вот такая аналогия лучше: “Результат деления”.

  • “Практика по проверке” vs “Практика проверки”
    Без предлога, с моей точки зрения, можно присоединять роль, реализующую практику, (“практики тестировщика”), или группу, в которую практика входит, (“практики саморазвития”).
    Но “проверка” — это не роль и не группа, это вид деятельности. Поэтому, чтобы сформировать группу (или подтип), приходится использовать предлог.
    Аналогии: “Задача по созданию”, “проект по исправлению”.

А есть ли у Вас какие-то возражения не по употреблению слов, а по существу — предложенным доработкам модели в Notion?

12

Мы не рассматриваем “практику как физический объект”. Точка. Практика — ментальный объект.
Продукты, являющееся результатом работы агента по практике, мы можем определить по их физичности. Как с “уверенностью”, физичность которой мы определить не можем, а следовательно сложно договариваться о её состоянии, так выбираем физический объект как целевой нашей деятельности — “письмо”, “пирог” и тп. И у этих “писем и пирогов” уже есть состояния: задумано, написано, испечён, съеден.
Предметно по доработке модели в Notion сказать ничего не смогу. Не понимаю, с чем работаем, что дорабатываем.
— Я на всякий случай повторю: Нам будет проще договориться, если мы примем методологию ШСМ за базу. Читайте курс Моделирование и собранность, читайте Системное мышление. База там.

13

Если аргументы закончились — достаточно просто признать ошибку, незачем выходить из себя.
А ссылаться каждый раз “читайте курс” — признак инфоцыганства, не красит ни школу, ни Вас лично.

14

дорогой дорогой, я очень далёк от выхода из себя, тем более по причинам мне не понятным. Мне правда не понятен предмет нашего рассуждения. Я предлагаю его приземлить на методологию опробированную на нескольких тысячах студентов. Если принять эту методологию за отправную точку, в ваших рассуждениях онтологические ошибки, о которых я вам говорю не потому, что хочу самоутвердиться, а чтобы помочь вам разобраться в методологии. Если вы хотите идти своим путём и разрабатывать инструменты на каких-то других принципах, я, боюсь, не смогу вас поддержать. Не потому что не хочу, а потому что вижу в них несоответствие усвоенным мной описаниям картин мира. И здесь, в этом блоге, моё мнение может отличаться от “мнения” школы.

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

По средам я провожу открытые мероприятия посвящённые результатам наших выпускников. В эту среду гость с 20+ стажем в разработке. Приходите, послушайте, задайте ваши вопросы, уточните своё понимание. Мероприятие в чате Экскурсии ШСМ: Telegram: Contact @AisystantEvent Буду рад видеть вас там!

15

Я привёл пример про “разговор”. Который взят из курса.
Пример корректный, или ошибка в курсе?
Если пример корректный, тогда почему “разговор” — это физический объект, а “привычка” — нет?

16

либо не актуальный курс, либо развалилась конфигурация курсов (работаем сейчас над управлением конфигурацией). Мы полностью отошли от “систем-процессов”. Только физический объект называем системой.
В “разговоре” тоже можно дотянуться до физичности: включить все объекты, участвующие в процесс. Но всё равно не удобно обсуждать системность