Выявление и анализ ролей и практик. Часть вторая

Блоги Eugene Romanenko (блоги)
,
1

Роль - система ожиданий от деятельности агента; деятельностное его положение в проекте, характеризующееся его целью и предметом интереса (который отличается от интересов личности агента в роли). Культурно обусловлена, название в культуре закреплено.
Роль существует постольку, поскольку у неё кесть предмет интереса (concern) к системе/проекту.
Ролевое поведение определяется view (предпочтением) по отношению к этому concern.
Действия роли — это стратегия достижения view.
А язык и инструменты, на которых она об этом думает и говорит — это viewpoint.
Метод/практика - устойчивый способ деятельности, освоенный и закреплённый в культуре, поддержанный дисциплиной и технологией.
Связь роли и практики всегда контекстна. Она проявляется в рамках конкретного проекта по созданию конкретной целевой системы.

Карта ролей и практик — это структурированное описание всех ролей, которые субъект играет, и всех практик, которые он исполняет в рамках этих ролей и конкретных контекстов (проектов), с указанием уровня мастерства, смысловых ориентиров (concern–view–viewpoint), и стратегий развития. Это центральный инструмент ролевого мастерства - онтологическая карта деятельности, которая связывает всё: роли, практики, проекты, мастерство и смысловые отношения между ними.

Компонент Смысл / Определение Пример Вопрос для анализа
Роль (Role) Социальная или проектная позиция, в рамках которой агент действует с определённым намерением и ответственностью Экономист, модератор сообщества, продакт-менеджер Как культурно называется эта позиция? Какова её функция в деятельности?
Метод / Практика (Method / Practice) Типовая форма действий, через которую роль реализует себя; способ достижения результата Анализ данных, интервьюирование, проектирование Каким способом выполняется работа в этой роли?
Рабочий продукт (Work Product) Наблюдаемый результат практики — то, что остаётся после выполнения деятельности Отчёт, интервью, дизайн-макет Что создаёт или производит роль?
Предмет интереса (Concern) То, что важно для роли — характеристика системы, которую она стремится поддерживать или улучшать Понимание причинно-следственных связей, качество взаимодействия, ценность продукта Что в мире важно для этой роли? Что она хочет сохранить или улучшить?
Метод описания (Viewpoint) Способ видения и описания предмета интереса; формируется дисциплиной или школой Экономическая теория, UX-подход, системное мышление Через какую дисциплину роль описывает реальность?
Ролевое предпочтение (View) Каким роль хочет видеть предмет интереса — желаемое состояние системы «Люди понимают экономические процессы», «Пользователи получают ясный интерфейс» Какое состояние предмета интереса считается желательным?
Стратегия (Strategy) Последовательность действий и решений, направленных на достижение предпочтительного состояния Публиковать аналитические статьи, проводить исследования, внедрять обратную связь Какие действия предпринимает роль для достижения своих целей?
Дисциплина / Теория (Discipline / Theory) Система знаний, формирующая мышление и методы роли Австрийская школа экономики, дизайн-мышление, lean-подход Какая теория или школа лежит в основе практики роли?
Технология / Инструменты (Technology / Tools) Средства реализации практики — материальные или цифровые инструменты Excel, Notion, Midjourney, блокчейн Какие инструменты использует роль для реализации практики?
Современность (State of the Art) Степень соответствия практики мировому передовому уровню Использует последние исследования, методологии или софт Насколько современна и актуальна практика этой роли? Что сегодня cutting edge?
Мастерство (Maturity) Степень компетенции и осознанности агента в роли Новичок, профессионал, мастер, наставник Каков уровень владения ролью и рефлексии над ней?
Взаимосвязи (Dependencies / Interfaces) Другие роли, с которыми взаимодействует агент в этой роли Экономист ↔ Политик, Продакт ↔ Дизайнер, Модератор ↔ Сообщество С кем взаимодействует эта роль? От кого зависит результат её деятельности?

Уровни эмерджентности при анализе практик
┌──────────────────────────────┐
│ 5. КУЛЬТУРНЫЙ УРОВЕНЬ │
│ Практика как культурная форма│
│ (узнаваемая, передаваемая, │
│ именуемая) │
└─────────────┬────────────────┘
│
┌─────────────┴────────────────┐
│ 4. РОЛЕВОЙ УРОВЕНЬ │
│ Кто исполняет? В какой роли? │
│ Каков продукт/результат? │
└─────────────┬────────────────┘
│
┌─────────────┴────────────────┐
│ 3. ПРОЦЕДУРНЫЙ УРОВЕНЬ │
│ Последовательность шагов, │
│ операций, инструментов. │
│ (методы, техники, шаблоны) │
└─────────────┬────────────────┘
│
┌─────────────┴────────────────┐
│ 2. ПОВЕДЕНЧЕСКИЙ УРОВЕНЬ │
│ Наблюдаемые действия, │
│ телесные и речевые акты. │
│ (“говорит”, “записывает”) │
└─────────────┬────────────────┘
│
┌─────────────┴────────────────┐
│ 1. МИКРОАКТЫ И ЖЕСТЫ │
│ Элементарные моторные или │
│ когнитивные движения. │
│ (“нажимает кнопку”, “смотрит”)│
└──────────────────────────────┘

10 типовых практик и ролей в любой деятельности

№ Название практики Цель Роль Продукт Наблюдаемые признаки
1 Наблюдение Понять, что реально происходит в ситуации. Наблюдатель, исследователь, аналитик. Зафиксированные факты, наблюдения, гипотезы. — человек молчит, но внимательно смотрит или слушает;
— записывает происходящее без оценок (“говорит… делает…”);
— уточняет детали (“когда именно?”, “в каком порядке?”);
— задаёт вопросы про факты, а не про мнения;
— не вмешивается, пока не закончит фиксацию.
2 Анализ Разложить ситуацию на части и понять структуру. Аналитик, архитектор, стратег. Карта, схема, список проблем или факторов. — раскладывает сложное на части (рисует, группирует, пишет списки);
— задаёт вопросы: “из чего это состоит?”, “что влияет?”, “какая причина?”;
— выносит элементы на бумагу, доску, экран;
— ищет связи и различия;
— использует слова “структура”, “паттерн”, “фактор”.
3 Формулирование замысла Определить, что хотим сделать и зачем. Инициатор, проектировщик, лидер. Замысел, концепция, brief. — говорит формулировками будущего (“мы хотим, чтобы…”);
— использует метафоры, образы, примеры;
— ставит рамки (“вот это важно, а это — не сейчас”);
— уточняет критерии успеха (“как поймём, что получилось?”).
4 Моделирование Представить систему и её логику. Архитектор, системный мыслитель, инженер. Модель, схема, диаграмма. — рисует стрелки, связи, блоки;
— обозначает роли, объекты, процессы;
— уточняет термины (“как мы называем вот это?”);
— проверяет модель на полноту и связность;
— задаёт вопрос “если убрать этот элемент — что изменится?”.
5 Проектирование Придумать решение, удовлетворяющее интересам ролей. Дизайнер, инженер, разработчик. Проект, прототип, чертёж, сценарий. — генерирует варианты (“можно так, можно так…”);
— оценивает их по критериям (“лучше по времени, хуже по рискам”);
— комбинирует идеи (“а если соединить эти две?”);
— делает черновики, эскизы, прототипы;
— обсуждает, как решение будет работать “в поле”.
6 Экспериментирование Проверить гипотезу действием. Инноватор, исследователь, тестировщик. Результаты проверки, данные, новые знания. — формулирует гипотезу (“если сделать X, произойдёт Y”);
— запускает пробный шаг;
— замеряет результат и сравнивает с ожиданием;
— фиксирует выводы;
— решает: “продолжаем / меняем”.
7 Координация Согласовать действия и ресурсы. Координатор, менеджер, фасилитатор. Общий план, протокол, синхронизированные действия. — уточняет статусы (“кто делает?”, “когда готово?”);
— подытоживает договорённости;
— следит, чтобы участники понимали друг друга;
— делает заметки о следующем шаге;
— завершает разговор распределением ответственности.
8 Коммуникация Обменяться смыслами, донести или понять позицию. Коммуникатор, собеседник, представитель. Понимание, согласование, отклик. — активно слушает (переспрашивает, уточняет);
— формулирует ясно и по существу;
— использует жесты и мимику для усиления смысла;
— избегает многословия и обобщений;
— стремится к взаимопониманию, а не к победе.
9 Оценка Определить качество или успешность результата. Оценщик, наставник, аудитор. Вывод, заключение, рекомендации. — сравнивает факты с критериями (“ожидалось X, получилось Y”);
— даёт аргументированную обратную связь;
— различает процесс и результат;
— формулирует улучшения (“следующий раз стоит сделать…”).
10 Рефлексия Понять, чему научился и как действовать лучше. Рефлектор, обучающийся, лидер. Осознания, выводы, планы изменений. — говорит о себе в прошедшем времени (“я заметил, что…”);
— выделяет трудности, инсайты, уроки;
— сравнивает ожидания и реальность;
— переводит выводы в намерения (“в будущем буду делать так”).

100+ типовых concern

Concern (Рус.) Concern (Eng.) Типовая роль
Принятие ответственности, Ответственность, Подотчётность Accountability Руководитель. Руководитель проекта, Руководитель подразделения
Достоверность Accuracy Аналитик данных
Адаптируемость Adaptability Архитектор решений, Change-менеджер
Адаптация Adaptation HR-бизнес-партнёр
Эстетика Aesthetics Дизайнер
Согласованность Alignment Менеджер по коммуникациям
Привлекательность Attractiveness Маркетолог
Доступность Availability Операционный менеджер, UX-исследователь
Информированность Awareness Коммуникационный специалист
Непрерывность бизнеса Business Continuity Операционный директор
Затраты на смену Change Cost Консультант по трансформации
Понятность Clarity Редактор
Совместимость Compatibility Системный аналитик, Системный интегратор
Развитие компетенций Competence Development HR-специалист
Конкурентоспособность Competitiveness Стратег
Соответствие нормам, Соблюдение стандартов Compliance Юрист/регулятор, Юрист
Понимание Comprehensibility Коммуникатор
Непротиворечивость Consistency Архитектор
Понимание контекста Context Awareness Системный аналитик
Непрерывное улучшение Continuous Improvement Lean-координатор
Контролируемость Controllability Процесс-менеджер
Координация Coordination Проектный менеджер
Стоимость Cost Финансовый аналитик
Ориентация на клиента Customer Focus Аккаунт-менеджер
Удовлетворение заказчика Customer Satisfaction Customer Success Manager
Ценность для клиента Customer Value Продуктовый аналитик
Целостность данных, Надёжность данных Data Integrity Инженер данных, Специалист по данным
Документируемость Documentability Технический писатель
Простота взаимодействия Ease of Interaction UX-дизайнер
Результативность Effectiveness Менеджер проектов
Эффективность Efficiency Менеджер проекта, Операционный менеджер
Энергия и фокус Energy and Focus Лидер
Энергопотребление Energy Consumption Инженер по энергоэффективности
Участие Engagement Фасилитатор
Этичность Ethics Этический офицер / консультант, Консультант по устойчивому развитию
Справедливость Fairness Медиатор
Реалистичность Feasibility Технический эксперт
Обратная связь Feedback Фасилитатор
Гибкость Flexibility Продуктовый менеджер
Понимание целей Goal Alignment Team Lead
Рост Growth Бизнес-девелопер
Гуманность Humanity Психолог
Доступ к информации Information Access Контент-менеджер
Информационная безопасность Information Security CISO
Информированное решение Informed Decision Директор
Инновационность Innovativeness Руководитель исследований, Исследователь
Интеграция Integration Архитектор
Интероперабельность Interoperability Архитектор интеграций
Обучаемость системы, Обучаемость Learnability Инженер обучения / тренинг-менеджер, Методист
Культура обучения Learning Culture HR-координатор
Легальность Legality Юрист
Долгосрочная перспектива Long-term Perspective Стратег
Сопровождаемость, Поддерживаемость Maintainability DevOps-инженер, Инженер по сопровождению
Управляемость Manageability Сервис-менеджер
Оценимость Measurability Менеджер по KPI
Моральный климат Morale Лидер команды
Мотивация Motivation HR-специалист
Оптимизация Optimization Инженер-проектировщик
Ответственность за результат Ownership Продуктовый менеджер
Вовлечённость Participation Комьюнити-лидер
Производительность Performance Системный инженер
Переносимость Portability Разработчик продукта
Точность Precision Инженер
Прогнозируемость Predictability Планировщик
Приоритизация Prioritization Продукт-оунер
Конфиденциальность Privacy Специалист по защите данных
Превентивность Proactivity Аналитик
Продуктивность Productivity Менеджер по эффективности, Руководитель команды
Рентабельность Profitability Финансовый директор
Прогресс Progress Менеджер по изменениям
Качество Quality Контролёр качества
Рациональность Rationality Экономист
Рефлексия Reflection Коуч
Надёжность Reliability Инженер по качеству, Инженер-архитектор
Надёжная коммуникация Reliable Communication PM
Репутация Reputation PR-менеджер
Соответствие требованиям Requirements Compliance Бизнес-аналитик
Прочность (устойчивость) Resilience Оператор системы
Утилизация ресурсов Resource Utilization Менеджер операционной эффективности
Скорость отклика Responsiveness Архитектор приложений
Видимость результатов Result Visibility PMO
Управление рисками Risk Management Риск-менеджер
Масштабируемость Scalability Системный архитектор, Архитектор решений
Безопасность Security Инженер по безопасности, Архитектор системы
Самоорганизация Self-organization Агиль-команда
Краткосрочная эффективность Short-term Efficiency Операционист
Простота Simplicity UI-дизайнер
Социальное воздействие Social Impact Сотрудник по устойчивому развитию
Стабильность Stability Системный администратор
Баланс интересов Stakeholder Balance Менеджер по взаимодействию с заинтересованными сторонами
Надёжность поставок Supply Reliability Логист
Экологичность, Устойчивость Sustainability Экологический инженер: Экологический аналитик
Системность Systemicity Системный аналитик
Масштабное мышление Systems Thinking Системный архитектор
Командное взаимодействие Team Collaboration Скрам-мастер
Тестируемость Testability Тестировщик
Время выхода на рынок Time to Market Продакт-менеджер
Соблюдение сроков Timeliness Руководитель проекта
Стоимость владения Total Cost of Ownership Финансист
Прослеживаемость Traceability Системный инженер
Прозрачность Transparency Аудитор / контролёр, Бизнес-аналитик
Доверие Trust Комьюнити-менеджер
Уменьшение неопределённости Uncertainty Reduction Аналитик рисков
Удобство использования Usability UX-дизайнер
Удовлетворённость пользователей User Satisfaction Аналитик по продукту, UX-исследователь
Доказываемость Verifiability Тест-инженер

Где перечислены concerns

Источник / стандарт Что содержит Контекст
ISO/IEC/IEEE 42010:2011 “Architecture Description” Определяет понятие concern и вводит систематизацию “stakeholders — concerns — viewpoints — views”. Системная и программная инженерия, архитектурное описание сложных систем.
TOGAF (The Open Group Architecture Framework) Распределяет concerns по четырём архитектурным доменам: бизнес, данные, приложения, технологии. Корпоративная архитектура.
ArchiMate (Open Group) Определяет типовые concerns архитектурных слоёв и заинтересованных сторон. Модельный язык архитектуры.
Systems Engineering Body of Knowledge (SEBoK) Приводит типовые concerns системных заинтересованных сторон: performance, safety, interoperability, usability, cost, etc. Системная инженерия, управление жизненным циклом.
ISO 9001 / ISO 15288 Фиксируют concerns качества процессов и систем (качество, эффективность, риск, устойчивость, соответствие, безопасность). Управление качеством и жизненным циклом.
Boehm’s Quality Model / ISO 25010 Даёт развёрнутый список concerns качества систем и программ: функциональность, надёжность, удобство, эффективность, сопровождаемость, переносимость. Программная инженерия.

Критика Текста “Выявление и анализ ролей и практик. Часть вторая” с Точки Зрения FPF

Общие сильные стороны текста:

  • Фокус на сборе данных: Автор предлагает конкретные U.Methodы для сбора U.Episteme: Evidence (интервью, наблюдение, анализ документов), что соответствует FPF-принципам.
  • Итеративность и динамичность: Признание того, что U.Episteme: RoleDescriptionCard — это живой документ, который “постоянно уточняется и дорабатывается”, прямо соответствует U.Evolvability и Canonical Evolution Loop (B.4).
  • Множественные перспективы: Идея о сборе информации из трёх перспектив (“я сам”, “меня видят”, “я вижу других”) отлично соответствует FPF-концепциям U.Concern, U.Viewpoint и U.View, хотя и не использует этих терминов.
  • Визуализация: Предложение использовать “таблицу ролей” соответствует Thinking Through Writing (E.11) и Lexical & Representation Discipline (E.10).

Методологические Ошибки и Предложения по Улучшению (с FPF-обоснованием):

  1. Недостаточное Определение U.Holon: ConceptualOrchestrator:

    • Критика FPF: Автор говорит о “лидере процесса”, “фасилитаторе”, “том, кто собирает информацию”. FPF потребовал бы явного определения U.Holon (агента) и его U.Role: ConceptualOrchestrator, который несёт U.Accountability за весь этот процесс выявления и анализа ролей. Без этого U.Holon и его U.Role (как мы обсуждали ранее), весь процесс рискует быть невыполненным или выполненным ненадлежащим образом.
    • Предложение: В начале статьи явно выделить U.Role: ConceptualOrchestrator, который является U.Holon: TransformerAgent для U.Episteme: SharedUnderstanding в команде.

  2. Слабость U.Episteme: Evidence и U.Trust & Assurance Calculus:

    • Ошибка: Автор предлагает “спросить” и “наблюдать”, что является хорошим U.Method для сбора U.Episteme: Evidence. Однако не хватает методологии для оценки надёжности этой информации. “Правдивы ли ответы? Насколько точны наблюдения?”
    • Критика FPF: FPF бы потребовал U.Episteme: EvidenceValidationMethods (методов валидации доказательств). Например, для интервью: U.Method: CrossReference (перекрёстная ссылка с другими источниками), U.Method: CorroborateObservation (подтверждение наблюдением), U.Method: FalsificationAttempt (попытка фальсификации).
    • Предложение: Добавить U.Methodы для проверки U.Episteme: Reliability (надёжности) и U.Episteme: TrustValue (ценности доверия) собранных U.Episteme: Evidence. Например, можно ли найти подтверждение словам человека в его реальных U.WorkProducts?

  3. Недостаточная Строгость в Разрешении Конфликтов U.Episteme: Mismatches:

    • Ошибка: Автор говорит о “конфликтах представлений” и предлагает “согласовать их”.
    • Критика FPF: FPF бы потребовал U.Method: ConceptualConflictResolution (метод разрешения концептуальных конфликтов) с явными шагами. Это не просто “согласовать”, а U.Work по выявлению U.Episteme: Mismatch между U.Episteme: SubjectiveRoleDescription, его U.Concernами и U.Objective U.Role.
    • Предложение: Детализировать U.Method: ConflictResolution. Возможно, с использованием U.Episteme: TransductionGraph для понимания, как U.Episteme: Views расходятся, и U.Episteme: UnifiedTermSheet для разрешения терминологических разногласий.

  4. Слабость в Управлении U.Episteme: Evolution (Эволюцией) Ролей:

    • Ошибка: “Постоянно уточнять и дорабатывать” — это верное направление, но не хватает формализации.
    • Критика FPF: FPF бы явно закрепил U.Episteme: RoleCard как живую U.Episteme, которая проходит через Canonical Evolution Loop (B.4). Это означает, что должны быть чётко определены:
      • U.Method: TriggerForUpdate (Триггеры для Обновления): Что именно инициирует пересмотр роли? (Например, смена U.Objective проекта, появление нового U.Holon, сбой в U.WorkProductFlow).
      • U.Method: RoleUpdateProcess (Процесс Обновления Роли): Кто (U.Holon в U.Role) отвечает за инициирование, сбор данных, согласование и утверждение изменений?
      • U.Method: Versioning (Версионирование): Как мы отслеживаем изменения в U.Episteme: RoleCard (например, через DRR)?
    • Предложение: Явно интегрировать U.Episteme: RoleCard в Canonical Evolution Loop (B.4) с чёткой спецификацией U.Methodов для Observe, Refine и Run фаз.

  5. Недостаточное Различение U.Viewpoint и U.View:

    • Ошибка: Автор говорит о “перспективах”, но не формализует их как U.Viewpoint (линза) и U.View (результат применения линзы).
    • Критика FPF: Чёткое разделение этих понятий, как мы обсуждали, позволяет более строго управлять информацией. U.Viewpoint — это как смотреть, U.View — это что видеть.
    • Предложение: Использовать U.Viewpoint для описания “перспективы” (например, U.Viewpoint: SelfPerception, U.Viewpoint: PeerPerception) и U.View для конкретного артефакта, который эта перспектива генерирует (например, U.Episteme: SelfDescribedRoleView, U.Episteme: PeerEvaluatedRoleView).

  6. “Таблица ролей” как U.Episteme: SingleSourceOfTruth:

    • Ошибка: Автор предлагает “таблицу ролей”, но не акцентирует её роль как U.Episteme: SingleSourceOfTruth.
    • Критика FPF: FPF требовал бы, чтобы эта таблица была единым, авторитарным, публично доступным и актуализируемым U.Episteme, на который все U.Holons в команде ссылаются как на истину о ролях.
    • Предложение: Явно указать, что “таблица ролей” должна быть U.Episteme: SingleSourceOfTruth и закрепить U.Accountability за её поддержание за U.Holon: ConceptualOrchestrator.