#систематика /// Как избежать провалов коммуникации
Чтобы избежать провалов в коммуникации, и сделать коммуникацию успешной стоит предпринять ряд действий.
1) Объяснить цель
- используем язык адресата (проверяем нашу способность к этому по ИТТ)
- рассказываем собесднику / адресату какие его предпочтения будут удовлетворены в результате этой коммуникции
- рассказываем адресату какие наши предпочтения будут удовлетворены в результате этой коммуникции
- получаем согласие о том, что цель общая и предпочтения не противоречат
- приступаем к самой коммуникации (то есть заканчиваем мета-коммуникацию и переходит к целевой коммуникации)
Таким образом мы делаем настройку максимы модальности, делаем коммуникацию более связной.
2) Разрешить конфликт [цель коммункиации — неудобств коммуникации]
- наблюдаем: что в коммуникации неудобно агенту?
- нам трудно / не получается соблюдать максимы кооперации
- собеседнику трудно / не получается соблюдать максимы
- подтвреждаем или опровергаем наблюдения — прямо или косвенно, задавая вопросы (чем более косвенно, тем лучше, особенно в долго длящихся дискомфортных коммуникациях)
- предполагаем / оцениваем шаги, которые надо совершить для снижения неудобств — и если их надо выполнять нам, то остается ли ценность достижения цели для нас?
3) Сглаживаем резкие смены ролей
- наблюдаем: в какой момент агент меняет роль, и почему это может происходить; возможные причины:
- в ответ на нашу смену ролей
- в ответ на предполагаемое нарушение предпочтений одной из ролей агента — это как сигнал тревоги
- в ответ на другие внешние для агента сигналы, переключающие его внимание с одних объектов на другие; часто это переключение плавное.
- чаще проговариваем свою роль — "я как разработчик понимаю это ...", а люди склонны подражать, и такое проговаривание также будет их "удерживать" в роли
- если есть возможность, прямо или косвенно спрашивать/уточнять роль агентов — "а ты это говоришь как кто? как менеджер или как аналитик?"; не всегда можно прямо это спросить, поэтому можно спрашивать "а что ты желаешь получить?" / "какие твои ожидания" — это будут предпочтения в интересе роли, которую можно выявить из этих предпочтений в ходе коммуникации.
4) Выявляем общие объекты коммуникации
- Обсуждаем общую прагматическую цель: при согласованной общей цели коммуникации совместно решаем / обсуждаем что именно и с чем надо сделать для достижения основной цели: "вот наша цель такая-то, но что мы будем менять, чтобы этой цели достичь?"
- Заземляем — приземляем коммуникацию на общее 4D-поле, то есть настраиваем коммуникацию на обсуждаение объектов, которые можно "потрогать": "мы хотим увеличить скорость автомобиля, что для этого будем менять — колёса, двигатель, вес авто?"
5) Настраиваем общий язык
- Заземляем
- Отделяем наблюдения от оценок (— Количество запросов растет. — Да, и это ужасно! — Ужасно или нет еще обсудим, сейчас важно согласиться, что кол-во запросов растет, и мы обсуждаем этот рост)
- Отделять предложения конкретных действий от предложений изменить картину мира агента, то есть отделить "Обсуждаем делать или не делать то-то" от "Объясняем как это работает, и что будет если сделать то-то".
___
#коммуникация #цель #роль #интерес #заземление #мета_язык
Чтобы избежать провалов в коммуникации, и сделать коммуникацию успешной стоит предпринять ряд действий.
1) Объяснить цель
- используем язык адресата (проверяем нашу способность к этому по ИТТ)
- рассказываем собесднику / адресату какие его предпочтения будут удовлетворены в результате этой коммуникции
- рассказываем адресату какие наши предпочтения будут удовлетворены в результате этой коммуникции
- получаем согласие о том, что цель общая и предпочтения не противоречат
- приступаем к самой коммуникации (то есть заканчиваем мета-коммуникацию и переходит к целевой коммуникации)
Таким образом мы делаем настройку максимы модальности, делаем коммуникацию более связной.
2) Разрешить конфликт [цель коммункиации — неудобств коммуникации]
- наблюдаем: что в коммуникации неудобно агенту?
- нам трудно / не получается соблюдать максимы кооперации
- собеседнику трудно / не получается соблюдать максимы
- подтвреждаем или опровергаем наблюдения — прямо или косвенно, задавая вопросы (чем более косвенно, тем лучше, особенно в долго длящихся дискомфортных коммуникациях)
- предполагаем / оцениваем шаги, которые надо совершить для снижения неудобств — и если их надо выполнять нам, то остается ли ценность достижения цели для нас?
3) Сглаживаем резкие смены ролей
- наблюдаем: в какой момент агент меняет роль, и почему это может происходить; возможные причины:
- в ответ на нашу смену ролей
- в ответ на предполагаемое нарушение предпочтений одной из ролей агента — это как сигнал тревоги
- в ответ на другие внешние для агента сигналы, переключающие его внимание с одних объектов на другие; часто это переключение плавное.
- чаще проговариваем свою роль — "я как разработчик понимаю это ...", а люди склонны подражать, и такое проговаривание также будет их "удерживать" в роли
- если есть возможность, прямо или косвенно спрашивать/уточнять роль агентов — "а ты это говоришь как кто? как менеджер или как аналитик?"; не всегда можно прямо это спросить, поэтому можно спрашивать "а что ты желаешь получить?" / "какие твои ожидания" — это будут предпочтения в интересе роли, которую можно выявить из этих предпочтений в ходе коммуникации.
4) Выявляем общие объекты коммуникации
- Обсуждаем общую прагматическую цель: при согласованной общей цели коммуникации совместно решаем / обсуждаем что именно и с чем надо сделать для достижения основной цели: "вот наша цель такая-то, но что мы будем менять, чтобы этой цели достичь?"
- Заземляем — приземляем коммуникацию на общее 4D-поле, то есть настраиваем коммуникацию на обсуждаение объектов, которые можно "потрогать": "мы хотим увеличить скорость автомобиля, что для этого будем менять — колёса, двигатель, вес авто?"
5) Настраиваем общий язык
- Заземляем
- Отделяем наблюдения от оценок (— Количество запросов растет. — Да, и это ужасно! — Ужасно или нет еще обсудим, сейчас важно согласиться, что кол-во запросов растет, и мы обсуждаем этот рост)
- Отделять предложения конкретных действий от предложений изменить картину мира агента, то есть отделить "Обсуждаем делать или не делать то-то" от "Объясняем как это работает, и что будет если сделать то-то".
___
#коммуникация #цель #роль #интерес #заземление #мета_язык
#систематика /// Модель, метамодель, мегамодель
При воплощении чего-либо нам нужно описание этого, того, что будет воплощено. Обсуждать надо описания, обсуждать до воплощения. Одна из частей описания — модель.
Модель необходима для обсуждения интересов, предпочтений и намерений.
Кол-во моделей для обсуждения пропорционально кол-ву интересов в системе.
Модель — абстракция от реальности и конкретики; "правильное упрощение" в смысле отсечения лишнего, упрощения до лишь самых важных нюансов.
Модель — это описание, прогнозирующее как будет работать воплощение системы. Для каждой системы есть НЕ одна модель, модели зависят от интересов проектных ролей.
Пример модели: при проектировании здания создается его чертёж, это его модель. Но чертежей будет несколько — один для электриков, один для безопасников, один для инженеров по станадартам. Чертёж как модель должен быть задокументирован, и документ может включать все перечисленные чертежи-описания сразу, но для каждой роли важем будет лишь одна из моделей, представленных в документе. Еще один пример — карта с легендой этой карты. Карта это модель местности, а легенда карты есть метамодель.
Для создания моделей используются метамодели — описания моделей, по которым участникам проекта становится понятно, что за модель рассматривается, в каком аспекте.
Пример метамодели: для изготовления панамы делаются выкройки, это модель, но есть и легенда — заштрихованные области на выкройке означают, допустим, вельвет, а пустые контуры означают, скажем, войлок; кружочки, закрашенные сеткой — декоративные пуговицы. Вот эта штриховка и символы пуговиц и есть метамодель.
Ошибки необходимо выявлять на стадии моделирования. Именно для этого создаются модели, по одной для каждого интереса, совокупность моделей есть мультимодель. Модели обсуждаются для достижения непротиворечий, для этого модели обязательно документируются с помощью метода описания. Предоставляя на обсуждение описание (модель), обязательно указывается метод описания.
Пример: показывая функциональную схему мы обязательно сообщаем, оформлена ли она формально, напимер, в UML, или же это вольный схемоид для вернеуровневого обсуждения;
ещё пример: предоставляя значения цветов мы обязательно указываем, в какой нотации они записаны: HEX / RGB / SMYK / HSB / Pantone (Обычно это следует из формата или префикса, но обязательно наличие индикатора, нельзя просто написать, что цвет равен 006011, это может оказаться как # 006011, так и HSL H00 S60 L11 ).
При обучении моделированию обучаются метамоделям, а не моделям. Модель каждый раз будет своя для каждого уникального проекта. А вот метамодели часто совпадают (пример: .XML и .JSON есть метамодель для описания метаданных).
Метамодель также называется интерпретатором описания. "Язык для описания языка" — например, легенда карты или список сокращений в документе техзадания.
Самый понятный интерпретатор это естественный язык.
Важно держать в уме вопросы, которые мы хотим/можем задать описанию и какие ответы хотим/можем получить — это влияет на выбор интерпретатора нами и на восприятие интерпретатора потребителем описания.
Повторим: интерпретатор = метамодель = описание описания = мета-язык.
При рассмотрении отношений модели и метамодели будем использовать термины описание и его интерпретатор.
___
#роль #модель #метамодель #мегамодель #описание #мета_язык
При воплощении чего-либо нам нужно описание этого, того, что будет воплощено. Обсуждать надо описания, обсуждать до воплощения. Одна из частей описания — модель.
Модель необходима для обсуждения интересов, предпочтений и намерений.
Кол-во моделей для обсуждения пропорционально кол-ву интересов в системе.
Модель — абстракция от реальности и конкретики; "правильное упрощение" в смысле отсечения лишнего, упрощения до лишь самых важных нюансов.
Модель — это описание, прогнозирующее как будет работать воплощение системы. Для каждой системы есть НЕ одна модель, модели зависят от интересов проектных ролей.
Пример модели: при проектировании здания создается его чертёж, это его модель. Но чертежей будет несколько — один для электриков, один для безопасников, один для инженеров по станадартам. Чертёж как модель должен быть задокументирован, и документ может включать все перечисленные чертежи-описания сразу, но для каждой роли важем будет лишь одна из моделей, представленных в документе. Еще один пример — карта с легендой этой карты. Карта это модель местности, а легенда карты есть метамодель.
Для создания моделей используются метамодели — описания моделей, по которым участникам проекта становится понятно, что за модель рассматривается, в каком аспекте.
Пример метамодели: для изготовления панамы делаются выкройки, это модель, но есть и легенда — заштрихованные области на выкройке означают, допустим, вельвет, а пустые контуры означают, скажем, войлок; кружочки, закрашенные сеткой — декоративные пуговицы. Вот эта штриховка и символы пуговиц и есть метамодель.
Ошибки необходимо выявлять на стадии моделирования. Именно для этого создаются модели, по одной для каждого интереса, совокупность моделей есть мультимодель. Модели обсуждаются для достижения непротиворечий, для этого модели обязательно документируются с помощью метода описания. Предоставляя на обсуждение описание (модель), обязательно указывается метод описания.
Пример: показывая функциональную схему мы обязательно сообщаем, оформлена ли она формально, напимер, в UML, или же это вольный схемоид для вернеуровневого обсуждения;
ещё пример: предоставляя значения цветов мы обязательно указываем, в какой нотации они записаны: HEX / RGB / SMYK / HSB / Pantone (Обычно это следует из формата или префикса, но обязательно наличие индикатора, нельзя просто написать, что цвет равен 006011, это может оказаться как # 006011, так и HSL H00 S60 L11 ).
При обучении моделированию обучаются метамоделям, а не моделям. Модель каждый раз будет своя для каждого уникального проекта. А вот метамодели часто совпадают (пример: .XML и .JSON есть метамодель для описания метаданных).
Метамодель также называется интерпретатором описания. "Язык для описания языка" — например, легенда карты или список сокращений в документе техзадания.
Самый понятный интерпретатор это естественный язык.
Важно держать в уме вопросы, которые мы хотим/можем задать описанию и какие ответы хотим/можем получить — это влияет на выбор интерпретатора нами и на восприятие интерпретатора потребителем описания.
Повторим: интерпретатор = метамодель = описание описания = мета-язык.
При рассмотрении отношений модели и метамодели будем использовать термины описание и его интерпретатор.
___
#роль #модель #метамодель #мегамодель #описание #мета_язык
#систематика /// Зачем учитывать контекст
Необходимо учитывать контекст при коммуникации: принимать его и передавать.
Это нуждля того, чтобы текст, явное сообщение, лучше было принято и усвоено.
Метафора: у адресата сообщения есть фон с дыркой для текста-объекта, который мы ему коммуницируем; эта дырка в форме прямоугольника, а наш объект круглый; и вот нам надо понять какие уголки контекста надо достроить, чтобы объект максимально полно сложил пазл на стороне адресата / агента.
Что же именно может делать контекст при коммуникации:
- Помогает соблюсти максиму модальности, делает сообщеня для адресата более связным
- Дает намек на интерпретатор для передаваемого сообщения
- Помогает привести адресата в нужное состояние
- Сообщает адресату нашу роль, из которой мы коммуницируем
- Помогает сообщить адресату его роль, к которой мы коммуницируем
___
#текст #контекст #фон #объект #роль #коммуникация
Необходимо учитывать контекст при коммуникации: принимать его и передавать.
Это нуждля того, чтобы текст, явное сообщение, лучше было принято и усвоено.
Метафора: у адресата сообщения есть фон с дыркой для текста-объекта, который мы ему коммуницируем; эта дырка в форме прямоугольника, а наш объект круглый; и вот нам надо понять какие уголки контекста надо достроить, чтобы объект максимально полно сложил пазл на стороне адресата / агента.
Что же именно может делать контекст при коммуникации:
- Помогает соблюсти максиму модальности, делает сообщеня для адресата более связным
- Дает намек на интерпретатор для передаваемого сообщения
- Помогает привести адресата в нужное состояние
- Сообщает адресату нашу роль, из которой мы коммуницируем
- Помогает сообщить адресату его роль, к которой мы коммуницируем
___
#текст #контекст #фон #объект #роль #коммуникация
#систематика /// Отношения между объектами
Помимо того, что объекты бывают разных типов, между собой объекты могут быть связаны разными отношениями.
1) Иерархии — надкласс-класс-подкласс, класс-экземпляр, часть-целое.
2) Репрезентация — как термин / слово реферирует к сущности / концепту / понятию / объекту. Слово отсылает, объект — к чему оно отсылает.
3) Язык и мета-язык — есть язык и есть договоренность / правила его использования. И между ними граница, разделяющая репрезентации: референция для одного термина будет разная для языка и мета-языка.
4) Агент и роль — агент играет роль в момент времени, а в целом играет набор ролей; у агента есть статусы (например, эпистемический), а у роли есть интерес, предпочтение в нем и намерение по воплощению этого предпочтения.
5) “Верить в" + "допускать, что" — "коммуникационное" отношение между агентом и картиной мира, содержащей объкеты; это два степени (первая сильнее) для описания отношений агента и объектов.
6) "Хотелось бы, чтобы" + "Обязательно нужно, чтобы" — "коммуникационное" отношение агентов и объкетов; две степени (вторая сильнее), применимо как для агентов, так и для ролей.
___
#иерархия #референция #мета_язык #роль #коммуникация
Помимо того, что объекты бывают разных типов, между собой объекты могут быть связаны разными отношениями.
1) Иерархии — надкласс-класс-подкласс, класс-экземпляр, часть-целое.
2) Репрезентация — как термин / слово реферирует к сущности / концепту / понятию / объекту. Слово отсылает, объект — к чему оно отсылает.
3) Язык и мета-язык — есть язык и есть договоренность / правила его использования. И между ними граница, разделяющая репрезентации: референция для одного термина будет разная для языка и мета-языка.
4) Агент и роль — агент играет роль в момент времени, а в целом играет набор ролей; у агента есть статусы (например, эпистемический), а у роли есть интерес, предпочтение в нем и намерение по воплощению этого предпочтения.
5) “Верить в" + "допускать, что" — "коммуникационное" отношение между агентом и картиной мира, содержащей объкеты; это два степени (первая сильнее) для описания отношений агента и объектов.
6) "Хотелось бы, чтобы" + "Обязательно нужно, чтобы" — "коммуникационное" отношение агентов и объкетов; две степени (вторая сильнее), применимо как для агентов, так и для ролей.
___
#иерархия #референция #мета_язык #роль #коммуникация
#систематика /// Интеллект, обучение и компетенции
Интеллект и навыки
Мозг нужен для "думания", но это "думание" может быть разным.
Верхнеуровнево это думание можно поделить (!!!очень условно!!!) на сложное и простое.
Сложное — это процесс мышления, при котором проблемы переводятся в задачи, клубки данных "распарсиваются", взятая "на разбор" часть мира перемалывается и выражается в объяснениях — и как результат упаковывается в модели с определенной степенью предсказательности.
Простое думание — процесс применения результатов-моделей из сложного мышления. Либо проверка гипотез-моделей, либо применение проверенных моделей уже как инструментов.
Интеллект занимается первым, сложным, процессом думания, исследованиями.
Навыки занимаются применением освоенных моделей, сборкой решений из готового материала.
Прокачивать интеллект — прокачивать умение решать неизвестные задачи, то есть превращать проблемы (задачи неизвестного класса) в задачи и подбирать к ним уже освоенные навыки.
Двухтактное обучение
Интеллект прокачивается обучением. Качественное обучение состоит из двух тактов — предобучение и прикладное обучение.
Предобучение — освоение практик мышления, развитие интеллекта; оно необходимо для более быстрого освоения прикладных навыков. Это большая и сложная часть обучения, но необходимая в современном мире, где не прожить с одним прикладным навыком (профессией).
Например, практиками предобучения являются логика, системное мышление, управление вниманием (собранность).
Прикладное обучение — освоение прикладных практик, "работ руками" (на самом деле и головой тоже, но чаще всего это простые вычисления, но не мышление в виде исследования).
Прикладными практиками являются, например, проектирование, инженерия, программирование; причем далее может следовать разделение на более узкие практики: UX-проектирование, инженерия загородных домов, backend-разработка.
Можно осваивать прикладные навыки и без предобучения, но это неэффективно: без предобучения прикладные навыки не получится освоить с полным пониманием, за рамками освоения останутся причинно-следственные связи, объяснения и понимание почему это так работает. С предобучением же освоение прикладных практик больше похоже на подстройку / тюнинг базовых умений, полученных из трансдисциплин.
Т-компетенции
Результат обучения выражается в компетенциях.
Компетенции необходимы для успешного встраивания в проекты — устройства на работу, ведения бизнеса, выполнения разовых заказов, построения личного бренда.
Компетенции бывают прикладные и базовые.
Прикладные — те, которые используются для выполнения конкретных рабочих задач, например, нарисовать иллюстрацию.
Базовые — переносимые не только из проекта в проект, но и из отрасли в отрасль: умение организовать (себя и команду), готовность агентно коммуницировать, работать в команде, etc.
Если представить, что прикладные компетенции выражены вертикальной чертой |, а базовые компетенции выражены горизонтальной --, то вместе их можно преставить как Т-образную характеристику. (Полагаю, что именно "Т" для удобства, по идее уместо было бы использовать и "__|__" и "-|-" и "+"; но обозначение неважно). Иногда две горизонтальных половинки разделяют на две части базовых навыков — коллективных (лидерство, организация, etc) и личных (этические установки, собранность, etc).
Самое важное — одно без другого не работает. Без базовых компетенций не встроиться в команду, не скоммуницировать, не построить стратегию для единоличных проектов. Без прикладных навыков просто нечего будет делать: встроиться в команду и системно мыслить мало, за это не платят зарплату и это нельзя продать клиентам.
Компетенции — базовые трансдисциплины и прикладные дисциплины — необходимы для успешного отыграывания ролей: на работе, в проектах, в бизнесе, etc.
___
#интеллект #мышление #навык #трансдисциплина #практика #роль #компетенция #дисциплина
Интеллект и навыки
Мозг нужен для "думания", но это "думание" может быть разным.
Верхнеуровнево это думание можно поделить (!!!очень условно!!!) на сложное и простое.
Сложное — это процесс мышления, при котором проблемы переводятся в задачи, клубки данных "распарсиваются", взятая "на разбор" часть мира перемалывается и выражается в объяснениях — и как результат упаковывается в модели с определенной степенью предсказательности.
Простое думание — процесс применения результатов-моделей из сложного мышления. Либо проверка гипотез-моделей, либо применение проверенных моделей уже как инструментов.
Интеллект занимается первым, сложным, процессом думания, исследованиями.
Навыки занимаются применением освоенных моделей, сборкой решений из готового материала.
Прокачивать интеллект — прокачивать умение решать неизвестные задачи, то есть превращать проблемы (задачи неизвестного класса) в задачи и подбирать к ним уже освоенные навыки.
Двухтактное обучение
Интеллект прокачивается обучением. Качественное обучение состоит из двух тактов — предобучение и прикладное обучение.
Предобучение — освоение практик мышления, развитие интеллекта; оно необходимо для более быстрого освоения прикладных навыков. Это большая и сложная часть обучения, но необходимая в современном мире, где не прожить с одним прикладным навыком (профессией).
Например, практиками предобучения являются логика, системное мышление, управление вниманием (собранность).
Прикладное обучение — освоение прикладных практик, "работ руками" (на самом деле и головой тоже, но чаще всего это простые вычисления, но не мышление в виде исследования).
Прикладными практиками являются, например, проектирование, инженерия, программирование; причем далее может следовать разделение на более узкие практики: UX-проектирование, инженерия загородных домов, backend-разработка.
Можно осваивать прикладные навыки и без предобучения, но это неэффективно: без предобучения прикладные навыки не получится освоить с полным пониманием, за рамками освоения останутся причинно-следственные связи, объяснения и понимание почему это так работает. С предобучением же освоение прикладных практик больше похоже на подстройку / тюнинг базовых умений, полученных из трансдисциплин.
Т-компетенции
Результат обучения выражается в компетенциях.
Компетенции необходимы для успешного встраивания в проекты — устройства на работу, ведения бизнеса, выполнения разовых заказов, построения личного бренда.
Компетенции бывают прикладные и базовые.
Прикладные — те, которые используются для выполнения конкретных рабочих задач, например, нарисовать иллюстрацию.
Базовые — переносимые не только из проекта в проект, но и из отрасли в отрасль: умение организовать (себя и команду), готовность агентно коммуницировать, работать в команде, etc.
Если представить, что прикладные компетенции выражены вертикальной чертой |, а базовые компетенции выражены горизонтальной --, то вместе их можно преставить как Т-образную характеристику. (Полагаю, что именно "Т" для удобства, по идее уместо было бы использовать и "__|__" и "-|-" и "+"; но обозначение неважно). Иногда две горизонтальных половинки разделяют на две части базовых навыков — коллективных (лидерство, организация, etc) и личных (этические установки, собранность, etc).
Самое важное — одно без другого не работает. Без базовых компетенций не встроиться в команду, не скоммуницировать, не построить стратегию для единоличных проектов. Без прикладных навыков просто нечего будет делать: встроиться в команду и системно мыслить мало, за это не платят зарплату и это нельзя продать клиентам.
Компетенции — базовые трансдисциплины и прикладные дисциплины — необходимы для успешного отыграывания ролей: на работе, в проектах, в бизнесе, etc.
___
#интеллект #мышление #навык #трансдисциплина #практика #роль #компетенция #дисциплина
#систематика /// Практика в менеджменте
Оргроль — это про практики, так как роль проектная, а проект требуется осуществления / выполнения практик.
Оргзвено — это про работы, так как оргзвено есть исполнитель+инструмент, и этот исполнитель делает работу, играя оргроль по какой-либо практике / каким-либо практикам.
Как сказано выше, оргроль выполняется оргзвеном, то есть исполнитель в ходе работ применяет инструмент (становится оргзвеном), чтобы выполнить практики, соответствующие занимаемой исполнителем (оргзвеном) оргроли.
Практика определяется дисциплиной, а не технологиями. Основной прием определения / выявления практики — спросить / понять “откуда знание о том, как выполнить работы (по обсуждаемой практике)?”. Ответ будет указывать на дисциплину, теорию / обучение — и это позволяет определить практику.
Пример:
— Вы взялись сшить панамку, откуда вы знаете как это делать?
— Я окончил курсы кройки и шитья, вот на мне жилет и под ним рубашка, они сшиты мною.
— И у вас есть весь необходимый инструмент?
— О да, я вожу с собой швейную машинку Panamaster, всё, что мне нужно — это сырьё и дизайн изделия.
Из ответов можно понять, что исполнитель заступает на роль швейного мастера и будет выполнять практику “ткацкого дела на швейной машинке” по одноименной дисциплине с применением соответствующей технологии (швейная машинка Panamaster).
— — —
#практика #дисциплина #роль #оргзвено
Оргроль — это про практики, так как роль проектная, а проект требуется осуществления / выполнения практик.
Оргзвено — это про работы, так как оргзвено есть исполнитель+инструмент, и этот исполнитель делает работу, играя оргроль по какой-либо практике / каким-либо практикам.
Как сказано выше, оргроль выполняется оргзвеном, то есть исполнитель в ходе работ применяет инструмент (становится оргзвеном), чтобы выполнить практики, соответствующие занимаемой исполнителем (оргзвеном) оргроли.
Практика определяется дисциплиной, а не технологиями. Основной прием определения / выявления практики — спросить / понять “откуда знание о том, как выполнить работы (по обсуждаемой практике)?”. Ответ будет указывать на дисциплину, теорию / обучение — и это позволяет определить практику.
Пример:
— Вы взялись сшить панамку, откуда вы знаете как это делать?
— Я окончил курсы кройки и шитья, вот на мне жилет и под ним рубашка, они сшиты мною.
— И у вас есть весь необходимый инструмент?
— О да, я вожу с собой швейную машинку Panamaster, всё, что мне нужно — это сырьё и дизайн изделия.
Из ответов можно понять, что исполнитель заступает на роль швейного мастера и будет выполнять практику “ткацкого дела на швейной машинке” по одноименной дисциплине с применением соответствующей технологии (швейная машинка Panamaster).
— — —
#практика #дисциплина #роль #оргзвено