Компоненты общения различные подходы к структурированию общения: ОБЩЕНИЕ: СТРУКТУРА, ЦЕЛИ, ФУНКЦИИ

• Кафедра
  • Історія кафедри
  • Навчальні дисципліни
  • Головні події кафедри
• Викладачі
  • Показники професійної активності викладачів кафедри
• Новини
• Наука
  • Наукова школа
  • Наукові заходи
  • Вісник НТУУ «КПІ»
    • Авторам
  • Звіт з наукової роботи
  • Методичні матеріали
  • Наукові та інші видання
• Студентам
  • Індивідуальна робота
  • Методички
  • Силабуси
• Студентська наука
• Аспірантура (PhD)
  • ПРОГРАМА ВСТУПУ
  • Рецензія-відгук на ОНП Психологія
  • ПРОГРАМА з підготовки аспірантів (PhD)
  • Навчальні плани
  • Робочі навчальні плани
  • Вибіркові дисципліни
  • СИЛАБУСИ
  • НАВЧАЛЬНІ ПРОГРАМИ
  • НАВЧАЛЬНО-МЕТОДИЧНІ КОМПЛЕКСИ ДИСЦИПЛІН
  • Педагогічна практика
  • Наші випускники
  • ТЕМАТИКА ДИСЕРТАЦІЙНИХ ДОСЛІДЖЕНЬ
• Партнери
• Контакти
• Мова: 
  •  Українська
  •  Русский
  •  English
• Facebook
• Telegram
• Громадське обговорення
• Інформаційні картки дисциплін

404 Page Not Found

• Викладачі
• Контакти
• Факультет соціології і права КПІ ім. Ігоря Сікорського
• КПІ ім. Ігоря Сікорського
• Індивідуальна робота

Графовый анализ — обзор и области применения / Хабр

Всем привет!

Мы — команда GlowByte Advanced Analytics. Сегодня мы расскажем об одном из перспективных направлений Data Science — графовом анализе, и покажем, какие задачи можно решать с его помощью.

Цель статьи — показать многообразие бизнес-областей, в которых можно применять графовые подходы.

Но перед этим мы вспомним основные понятия графа, поговорим о его свойствах и расскажем о семействах алгоритмов, применяемых в графовом анализе.

Что такое граф?

• Граф— математический объект, который изображает отношения между сущностями. Граф состоит из вершин (объектов) и рёбер (связей). С помощью графов можно представить разныех ситуации: например, пользователей соцсети, которые находятся друг у друга в друзьях, клиентов банка, которые переводят друг другу денежные средства, географические объекты и пути между ними.

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

• Рёбрам графа могут быть присвоены значения — веса. Веса характеризуют силу связей между вершинами. Как пример, это может быть количество звонков, сумма денежного перевода, расстояние между городами. Если у рёбер графа нет весов, то считается, что все веса равны между собой.

• Граф называется циклическим, если в графе присутствует последовательность рёбер, которая начинается и заканчивается в одной вершине. Цикл необязательно должен включать в себя все вершины.

• И наоборот, существуют ациклические графы, не содержащие замкнутых последовательностей рёбер. Их подвид, направленные ациклические графы, применяются для построения древовидных структур и используются во множестве сфер, включая биологию (эволюция), социологию. Другой распространенный пример — графы вычислений (Dask, Airflow), которые описывают набор зависящих друг от друга операций, выполняемых последовательно или параллельно.

---

Графовый анализ

Графовый (также сетевой) анализ — это набор методов, направленных на изучение связей между сущностями. При помощи этих методов исследуется структура графа и выявляются неочевидные зависимости.

Извлекать из графов полезную информацию позволяют графовые алгоритмы, которые можно условно поделить на несколько семейств. Рассмотрим эти семейства на примере социальной сети:

• Обнаружение сообществ (community detection) — это выделение тесно связанных между собой групп людей (к примеру, через большое количество общих связей). При этом совсем не обязательно, чтобы все участники взаимодействовали друг с другом напрямую. Это семейство алгоритмов является своего рода аналогом кластеризации.

• Алгоритмы центральности (centrality algorithms) поможет выявить лидеров мнений и влиятельных людей в сообществах. Под центральностью мы подразумеваем некоторую меру значимости вершины или ребра.Алгоритмы центральности и сообществ можно применять для создания новых предикторов в ML-pipeline.

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

• Алгоритмы сходства (similarity algorithms) пригодятся, чтобы найти похожие группы людей. Это может быть полезно, чтобы собрать аудиторию для рекламы по принципу lookalike или выявить поддельные учетные записи, основываясь на свойствах их окружения.

• Поиск путей (path detection) окажется полезен для того, чтобы найти кратчайшую цепочку знакомств между людьми. В качестве меры расстояния (весов ребер) можно использовать характеристики взаимодействия пользователей — например, частоту их общения.

Takeaway: Графовый анализ эффективен, когда мы рассматриваем объекты в контексте связей с другими объектами.

Работа с графами

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

Графовые базы данных

Источник

Графовые базы данных традиционно относят к NoSQL-категории. Рассмотрим их особенности:

• По сравнению с реляционными и документарными БД, графовые базы позволяют создавать гибкую структуру, в которую можно вносить любые изменения, не ломая её общую архитектуру.

• Для общения с графовыми СУБД существуют отдельные языки запросов, например, Cypher (Neo4j) и SPARQL.

• Графовые СУБД выигрывают у реляционных в скорости в тех случаях, когда мы работаем со связями и перемещаемся по графу. Это обусловлено тем, что каждая вершина графа вместе со своими связями хранится в оперативной памяти, и не используется JOIN.

Другие инструменты работы с графами

Помимо графовых СУБД, для работы с графами существуют специальные программные библиотеки (например, для Python написаны популярные библиотеки NetworkX и igraph). Также при необходимости логику графовых вычислений можно частично реализовать и в реляционных базах данных.

---

В каких бизнес-областях применяются графы?

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

Мы условно разделили бизнес кейсы на три группы:

1. Алгоритмы на графах — в этой части покажем разнообразные задачи, которые можно решать при помощи графовых алгоритмов.

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

3. Хранение и структурирование информации — посмотрим на то, как графовые подходы используются для хранения информации и взаимодействия с ней.

Алгоритмы на графах

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

Рекомендательные системы

Одноклассники

Задача рекомендательных систем — повышать продажи и удовлетворённость клиентов, угадывая их потребности и предлагая подходящие товары, услуги, цифровой контент и т.д.

Рекомендательные системы обычно включают в себя контент-ориентированные методы (сходство продуктов между собой) или коллаборативную фильтрацию (сходство предпочтений похожих пользователей).

Рекомендации возможно делать и на графах. Например, в соцсети “Одноклассники” на графах основан подбор релевантных сообществ для пользователей:

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

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

• Те вершины, на которых останавливаются случайные обходы, считаются кандидатами для рекомендации.

Графовый подход помог “Одноклассникам” увеличить релевантность своих рекомендаций и повысить количество вступлений в группы на 30%, а благодаря скорости работы графов количество генерируемых рекомендаций удалось увеличить в 4 раза.

Портрет клиента 360 градусов

Источник

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

Социально-демографические факторы, истории покупок, поведение на веб-сайтах, отзывы, банковские транзакции — всё это помогает в создании портрета пользователей и предсказании их поведения.

Пользуясь табличными данными, можно анализировать статистические показатели клиентов и групп, обобщать клиентов с помощью кластеризации.

Если представить клиентов компании и их взаимодействия с продуктом и между собой в виде графа, получится визуализация, которая будет полезна для всестороннего изучения клиентов и поиска новых идей:

• Применяя алгоритмы центральности, можно находить хорошо продаваемые товары или услуги.

• Чтобы понять, какие продукты интересны клиенту, можно прогнозировать вероятность связей между клиентом и различными продуктами, а также делать рекомендации и решать задачу Next-Best-Action.

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

• Если необходимо прогнозировать отток, то можно изучить точки соприкосновения/сходства у клиентов, которые перестали пользоваться услугами компании, а затем найти тех, кто находится в зоне риска, и постараться их удержать.

Оптимизация маршрутов (Vehicle Route Problem)

Источник

Спрос на перевозки растёт, и компаниям, занимающимся перевозками, необходимо одновременно поддерживать высокий уровень сервиса и контролировать затраты на оказание своих услуг. Одна из возможных стратегий при ручном построении маршрута — максимизировать прибыль за счёт наибольшего количества заказов на маршруте и кратчайших перегонов между точками.

Задача оптимизации маршрутов уже имеет графовую природу: чтобы построить маршрут, можно представить пункты назначения в виде вершин графа, а рёбрами станет расчётное время, за которое водитель перемещается между пунктами. Таким образом, с помощью алгоритмов поиска путей возможно найти оптимальные варианты маршрутов.

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

1. Строится граф, вершинами которого будут все возможные перегоны между нашими заказами, а ребрами соединяются те перегоны, которые невозможно включить в один маршрут.

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

IT-инфраструктура (Predictive Maintenance and Quality)

Источник PdM Источник графы

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

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

• Также можно рассмотреть логи как временные ряды и искать в них аномальные значения или паттерны, которые влекут за собой отказ элементов сети.

Сетевые инфраструктуры уже являются готовыми графами, и их возможно представить в виде виртуальных графов.

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

• При выявлении слабых мест в инфраструктуре также обнаруживаются те части системы, которые выйдут из строя в случае отказа сетевого оборудования.

Графы хакерских атак

Источник

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

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

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

• Графы атак являются направленными и представляют собой состояния сети в роли вершин и уязвимости, изменяющие эти состояния, в виде дуг.

• Анализ путей и центральности позволяет распознать уязвимости и найти среди них те, которые сопряжены с наибольшим риском.

• Автоматическое построение таких графов ускоряет процесс поиска слабых мест и позволяет исключить влияние человеческого фактора.

Графовые признаки для задач машинного обучения

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

Кредитный скоринг

Источник

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

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

Таким образом компания может заблаговременно оценить, какие условия предлагать своим клиентам, а кому и вовсе стоит отказать.

Газпромбанк (источник) использует графы для скоринга потенциальных и уже существующих заемщиков среди предприятий малого и среднего бизнеса:

• В качестве вершин берутся юридические лица с различными атрибутами: например, как давно основана компания, были ли сообщения о банкротстве, итд.

• Ребра между вершинами могут содержать разные виды связей, такие, как общие руководители, дочерние предприятия или наличие транзакций между компаниями. Транзакции описываются в свободной форме, и для их интерпретации и группировки по смыслу используются методы NLP.

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

Обнаружение мошенничества (anti-fraud):

Источник

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

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

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

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

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

Противодействие отмыванию денег (Anti-Money Laundering) (алгоритмы)

Источник

Отмывание денег — это сокрытие источника доходов, полученных преступным путём. Этот подвид операционных рисков связан с несовершенством финансовых процессов и их реализацией в информационных системах банков. Одним из факторов риска является возможное вхождение клиентов в мошеннические группы, уклонение от нагрузки или обналичивание денег.

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

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

Прогноз оттока на примере телеком-оператора (Churn prediction)

Источник

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

• Традиционно, пользователь представлен в виде отдельной единицы, к которой относятся персональные данные, тарифы, детализация звонков, сообщений итп. На основе этих признаков оценивается вероятность ухода нашего клиента.

• Переведя действия пользователя в графовое представление, мы можем выделить новые признаки исходя из его социального контекста.Пример: пользователи представлены вершинами графа, а отдельные их взаимодействия — рёбрами. Каждое из рёбер несёт в себе ряд свойств — например, вид взаимодействия и его длительность.

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

Хранение и структурирование информации

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

Происхождение данных (Data Lineage)

Источник RU Источник Neo4j

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

Информацию о движении данных можно хранить в Data Lineage — это механизм, который отслеживает, откуда берутся данные, а также куда и в каком виде они попадают.

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

• Когда потребуется внести изменения в какой-либо объект, пользователю будет известно, откуда этот объект пришёл, какие дочерние объекты затронет его изменение, кто является его владельцем, а кто — пользователем.

• Графовая СУБД обеспечит наглядную визуализацию и высокую скорость выполнения запросов, даже если в хранилище данных будут десятки тысяч объектов.

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

Анализ ведомости материалов

Определение Источник

Ведомость материалов (Bill of Materials или просто BOM) — это список материалов или запчастей, необходимых для производства, сборки или ремонта конечного продукта, с указанием количества по каждому пункту. BOM используются в первую очередь для обеспечения стабильной работы производственных потоков.

Удачным примером применения BOM послужит реальный кейс армии США: военная структура всё время растёт и должна вовремя обеспечивать своих людей оружием, техникой и другим оборудованием. Производство оборудования и поддержание его в рабочем состоянии — сложная задача для структуры такого масштаба, особенно когда это нужно делать эффективно и быстро:

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

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

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

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

• Neo4j в описании кейса армии США отмечено, что применение графов позволило сократить время получения искомых данных с 60 часов до 7-8 часов, а поддерживать такую базу теперь могут всего 2 человека, а не 9, как раньше.

Графы знаний для построения поисковых запросов

Источник

В качестве примера, как используются графы при поиске товаров, подойдёт совместный кейс eBay и Google.Целью проекта было создание чат-бота для Ассистента Google, который умел бы искать товары на основе речевых запросов и умел бы уточнять поисковый запрос, общаясь с пользователем.

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

Такой граф решает сразу две задачи:

• С одной стороны, когда пользователь задаёт сложный поисковый запрос в духе “ищу палатку, чтобы съездить вместе с супругой/супругом отдохнуть на озеро Тахо”, механизмы NLP извлекают смысл сказанного, находят на графе близкие по смыслу вершины-характеристики и предлагают пользователю товары, связанные с этими вершинами.

• С другой стороны, Google Ассистент может задавать пользователю уточняющие вопросы, двигаясь по графу от общих категорий к более детальным, тем самым дополняя свою информацию об искомом товаре и предлагая более релевантные товары. Благодаря быстрой обработке связей графовой СУБД Google Ассистент может взаимодействовать с человеком в реальном времени.

  ---

Заключение

Подведем итог:

• Графовый анализ предлагает нам новые способы взаимодействия с привычными данными, такие как:

  • Визуализация связей между объектами;

  • Генерация новых признаков для машинного обучения;

  • Анализ объектов в контексте их окружения.

• Для работы с графами уже существует достаточно большое число различных инструментов:

  • Графовые СУБД;

  • Средства визуализации;

  • Программные библиотеки для Python и других языков.

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

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

Больше про графы в реальных бизнес-задачах мы общаемся в нашем сообществе NoML:

Присоединяйтесь!

Как реализовать DDD в Go / Хабр

Image by Percy Bolmér. Gopher by Takuya Ueda, Original Go Gopher by Renée French (CC BY 3.0)

С помощью микросервисной архитектуры можно построить масштабируемое и гибкое приложение. Однако, если команда бессистемно использует этот подход в своей работе, то скоро столкнется с разочарованием и неконтролируемой сложностью. Избежать этого поможет DDD (Domain-Driven Design, предметно ориентированное проектирование). Не так давно я ничего не знал про этот подход, но сейчас я постоянно натыкаюсь на эту тему.

Представляю вам перевод статьи «How to Implement Domain-Driven Design (DDD) in Golang». Повествование буду вести от лица автора, иногда прерывая собственными мыслями в таком же формате, как и это отступление. Приятного чтения.

---

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

Если вы не понимаете, о чём я, то эта схема, возможно, поможет понять мою боль.

Keywords in DDD — Graph from Eric Evans book Domain-Driven Design: Tackling Complexity in the Heart of Software

Первым делом я хочу отметить, что эта статья описывает моё представление о DDD, а реализация, которую я здесь покажу, основана на подходах, хорошо зарекомендовавших себя в Go-проектах, над которыми я работал; нельзя сказать, что описываемый здесь подход — признанный best practice. Буду придерживаться именования папок проекта согласно терминологии DDD. В реальных проектах я бы предпочёл другой способ, но так будет легче усвоить новые понятия. Шаг в сторону боевого проекта мы сделаем ближе к заключению: там я рефакторингом переработаю структуру и объясню, зачем это нужно.

Я не раз наблюдал горячие дискуссии в интернете о DDD и его правильном использовании. И каждый раз обращал внимание, что чаще всего люди забывают про основную цель DDD и зацикливаются на спорах о подробностях реализации. По-моему, главное — следовать предложенной Эвансом методологии, а не следить за тем, чтобы сущности были названы так или иначе.

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

Что такое DDD

Domain-Driven Design — это способ структурирования знаний и создания упрощенной модели той предметной области (домена, domain), к которой относится разрабатываемое ПО. В первую очередь необходимо изучить предметную область. Ею может быть любая задача или проблема, решению которой должна способствовать создаваемая программа. При этом приложение следует конструировать так, чтобы его архитектура отражала структуру предметной области.

Согласно DDD, команда разработки должна постоянно взаимодействовать с экспертами в предметной области (Subject Matter Experts, SME). Именно эти люди хранят знания, которые необходимо отразить в коде приложения. Например, если вам нужно создать приложение для торговли акциями, то было бы неплохо сперва побольше узнать о фондовом рынке из уст человека, обладающего большим опытом.

Архитектура должна отражать в коде структуру предметной области. Как именно — мы увидим, когда начнём писать наше приложение для управления таверной.

Путешествие гофера в DDD

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

Данте и человек в высокой шляпе отлично погуляли и обсудили управление таверной. Данте узнал, что приходящих в таверну людей стоит называть клиентами, а не выпивохами. Также «шляпа» объяснил, что в таверне не только обслуживают клиентов, но и управляют сотрудниками, поставками и платежами.

Домен, модель, универсальный язык и поддомены

Надеюсь, вам понравилась история про Данте, ведь я написал её не просто так. Она послужит нам контекстом, который позволит проще объяснить некоторые ключевые понятия.

Герои нашей истории поучаствовали в сессии моделирования предметной области: «шляпа» выступал в качестве эксперта, а Данте представлял команду инженеров. Такие беседы помогают построить правильную абстракцию над теми компонентами, которые нужны для создания модели.

В нашем случае основным доменом (Core/Root domain) будет таверна. Однако Шляпа упомянул и о других понятиях; так все члены команды, работающей над проектом, формируют универсальный язык (ubiquitous language), без которого общение сбивало бы с толку, а не помогало развитию.

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

Код DDD-приложения на Go

Сущности и объекты-значения

Пора начинать писать код нашего приложения, у нас есть всё, что необходимо. Начнём с создания окружения проекта.

mkdir ddd-go
go mod init github.com/percybolmer/ddd-go

Первым делом создадим папку domain, в которой будем хранить все необходимые поддомены. Но перед тем, как мы начнём работу с доменом, нам нужна другая папка. В учебных целях назовем её entity и положим туда сущности (entity) — структуры с идентификатором, которые могут изменять состояние.

Мы создадим две сущности: Person и Item. Я предпочитаю держать сущности в отдельном пакете, чтобы их можно было использовать из всех других доменов.

Для поддержания чистоты кода я делаю маленькие файлы и компактную структуру проекта, в которой легко ориентироваться. Так что рекомендую создать два отдельных файла для каждой сущности. Сейчас там будут только определения структур, но позже мы добавим и логику.

package entity

import "github.com/google/uuid"

// Person is a entity that represents a person in all Domains
type Person struct {
	// ID is the identifier of the Entity, the ID is shared for all sub domains
	ID uuid.UUID
	Name string
	Age int
}

package entity

import "github.com/google/uuid"

// Item represents a Item for all sub domains
type Item struct {
	ID          uuid.UUID 
	Name        string    
	Description string    
}

Перейдём к объектам-значениям (Value Objects) — неизменяемым структурам, которым не нужен идентификатор. Состояние таких объектов не изменяется после создания. Объекты-значения часто находятся внутри доменов и используются для описания конкретных аспектов в них. Сейчас создадим один объект-значение

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

package valueobject

import "time"

type Transaction struct {
	// all values lowercase since they are immutable
	amount    int
	from      uuid.UUID
	to        uuid.UUID
	createdAt time.Time
}

Агрегаты: комбинированные сущности и объекты-значения

Агрегат (Aggregate) — это набор скомбинированных сущностей и объектов-значений. В нашем случае можно начать с создания агрегата Customer. Роль агрегатов — быть объектом бизнес-логики. Они не дают прямого доступа к хранимым сущностям, которых может быть несколько. Например, для определения покупателя нам потребуется не только сущность Person, но и Products вместе с Transactions.

У агрегата в DDD должна быть только одна главная сущность (root entity). Тогда, ссылаясь на основную сущность, мы также будем ссылаться и на агрегат. Например, ID сущности Person может служить для однозначного определения агрегата

Customer.

Давайте создадим папку aggregate, в которую положим файл customer.go. Там заведём новую структуру Customer, в которой будут все необходимые для представления клиента сущности. Обратите внимание, что все поля структуры начинаются с маленькой буквы (так мы запретим доступ к этим полям вне пакета структуры). Это осознанное решение, потому что агрегаты не должны предоставлять прямого доступа к своим данным. Также мы не добавляем никаких тегов в структуру, чтобы её нельзя было использовать для сериализации или сохранения в базу.

package aggregate

import (
	"github.com/percybolmer/ddd-go/entity"
	"github.com/percybolmer/ddd-go/valueobject"
)

// Customer is a aggregate that combines all entities needed to represent a customer
type Customer struct {
	// person is the root entity of a customer
	// which means the person.ID is the main identifier for this aggregate
	person *entity.Person 
	// a customer can hold many products
	products []*entity.Item 
	// a customer can perform many transactions
	transactions []valueobject.Transaction 
}
 
 

Все сущности заведены указателями, потому что они могут изменять своё состояние. И я хочу отразить это в коде.

Фабрики: способ сокрытия сложной логики

До сих пор мы с вами только заводили различные сущности, объекты-значения и агрегаты. Настало время реализовать часть бизнес-логики, и начнём мы с фабрик (factories). Паттерн «фабрика» используется для сокрытия сложной логики внутри функций, которые создают желаемые экземпляры объектов. При этом вызывающий такую функцию код ничего не знает о деталях реализации и особенностях создания желаемого объекта.

Есть отличный сайт-шпаргалка, который поможет вам ознакомиться или вспомнить основные паттерны проектирования.

Фабрика — очень распространенный паттерн, который можно использовать и за рамками DDD-приложений, и вы, скорее всего, уже делали это не один раз.

DDD предлагает использовать фабрики для создания сложных агрегатов, репозиториев и сервисов (познакомимся с этими терминами далее). Мы реализуем фабрику NewCustomer. Происходящее внутри этой функции скрыто от вызывающего её кода и никак на него не влияет.

В реальном приложении я бы предпочел держать агрегат в папке domains/customer рядом с фабрикой, но подробнее об этом поговорим ниже.

package aggregate

import (
	"errors"

	"github.com/google/uuid"
	"github.com/percybolmer/ddd-go/entity"
	"github.com/percybolmer/ddd-go/valueobject"
)

var ErrInvalidPerson = errors.New("a customer has to have an valid person")

type Customer struct {
	person *entity.Person
	products []*entity.Item
	transactions []valueobject.Transaction
}

// NewCustomer is a factory to create a new Customer aggregate
// It will validate that the name is not empty
func NewCustomer(name string) (Customer, error) {
	if name == "" {
		return Customer{}, ErrInvalidPerson
	}

	// Create a new person and generate ID
	person := &entity.Person{
		Name: name,
		ID:   uuid.New(),
	}
	// Create a customer object and initialize all the values to avoid nil pointer exceptions
	return Customer{
		person:       person,
		products:     make([]*entity.Item, 0),
		transactions: make([]valueobject.Transaction, 0),
	}, nil
} 

Сейчас фабрика взяла на себя всю ответственность по валидации входных данных, созданию нового ID и заданию всех начальных значений. Поскольку у нас появилась логика, пора добавить тесты. Добавляем файл customer_test.go в пакет aggregate.

package aggregate_test

import (
	"testing"

	"github.com/percybolmer/ddd-go/aggregate"
)

func TestCustomer_NewCustomer(t *testing.T) {
	// Build our needed testcase data struct
	type testCase struct {
		test        string
		name        string
		expectedErr error
	}
	// Create new test cases
	testCases := []testCase{
		{
			test:        "Empty Name validation",
			name:        "",
			expectedErr: aggregate.ErrInvalidPerson,
		}, {
			test:        "Valid Name",
			name:        "Percy Bolmer",
			expectedErr: nil,
		},
	}

	for _, tc := range testCases {
		// Run Tests
		t.Run(tc.test, func(t *testing.T) {
			// Create a new customer
			_, err := aggregate.NewCustomer(tc.name)
			// Check if the error matches the expected error
			if err != tc.expectedErr {
				t.Errorf("Expected error %v, got %v", tc.expectedErr, err)
			}

		})
	}

}
 

Обратите внимание на реализацию табличных тестов от автора. Такой подход позволяет избежать дублирования кода и прогнать тест на разных входных значениях.

Но далеко с текущими возможностями таверны мы не уедем. Пора взглянуть на самый лучший паттерн, который мне известен.

Репозитории

DDD говорит, что репозитории должны хранить и управлять агрегатами. Изучив этот паттерн, я сразу понял, что никогда не перестану его использовать. Он полагается на сокрытие взаимодействия с хранилищем за интерфейсом реализации. Главное преимущество такого подхода заключается в возможности заменить реализацию без опасения что-либо сломать. Мы можем ограничиться локальным хранилищем на период разработки и переключиться позже на MongoDB, например, без необходимости переписывать что-либо кроме самого кода взаимодействия с хранилищем. Это поможет не только при замене вендора, но и при тестировании: можно с лёгкостью замокать хранилище с помощью новой реализации интерфейса.

Начнём с создания файла repository.go внутри пакета domain/customer. Заведём там общие ошибки и интерфейс, который мы хотели бы видеть у хранилища.

// Package Customer holds all the domain logic for the customer domain.
package customer

import (
	"github.com/google/uuid"
	"github.com/percybolmer/ddd-go/aggregate"
)

var (
	ErrCustomerNotFound = errors.New("the customer was not found in the repository")
	ErrFailedToAddCustomer = errors.New("failed to add the customer to the repository")
	ErrUpdateCustomer = errors.New("failed to update the customer in the repository")
)

// CustomerRepository is a interface that defines the rules around what a customer repository
type CustomerRepository interface {
	Get(uuid.UUID) (aggregate.Customer, error)
	Add(aggregate.Customer) error
	Update(aggregate.Customer) error
}

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

Обратите внимание, что ошибки определены именно в пакете customer, а не в пакете репозитория. Это позволит не зависеть от реализации.

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

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

mkdir memory
touch memory/memory.go

Перед работой над репозиторием нам нужно добавить немного функциональности Customer-у.

func (c *Customer) GetID() uuid.UUID {
	return c.person.ID
}

func (c *Customer) SetID(id uuid.UUID) {
	if c.person == nil {
		c.person = &entity.Person{}
	}
	c.person.ID = id
}

func (c *Customer) SetName(name string) {
	if c.person == nil {
		c.person = &entity.Person{}
	}
	c.person.Name = name
}

func (c *Customer) GetName() string {
	return c.person.Name
}

Создадим новую структуру, фабрику для неё и методы для реализации интерфейса.

// Package memory is a in-memory implementation of the customer repository
package memory

import (
	"fmt"
	"sync"

	"github.com/google/uuid"
	"github.com/percybolmer/ddd-go/aggregate"
	"github.com/percybolmer/ddd-go/domain/customer"
)

// MemoryRepository fulfills the CustomerRepository interface
type MemoryRepository struct {
	customers map[uuid.UUID]aggregate.Customer
	sync.Mutex
}

// New is a factory function to generate a new repository of customers
func New() *MemoryRepository {
	return &MemoryRepository{
		customers: make(map[uuid.UUID]aggregate.Customer),
	}
}

// Get finds a customer by ID
func (mr *MemoryRepository) Get(id uuid.UUID) (aggregate.Customer, error) {
	if customer, ok := mr.customers[id]; ok {
		return customer, nil
	}

	return aggregate.Customer{}, customer.ErrCustomerNotFound
}

// Add will add a new customer to the repository
func (mr *MemoryRepository) Add(c aggregate.Customer) error {
	if mr.customers == nil {
		// Saftey check if customers is not create, shouldn't happen if using the Factory, but you never know
		mr.Lock()
		mr.customers = make(map[uuid.UUID]aggregate.Customer)
		mr.Unlock()
	}
	// Make sure Customer isn't already in the repository
	if _, ok := mr.customers[c.GetID()]; ok {
		return fmt.Errorf("customer already exists: %w", customer.ErrFailedToAddCustomer)
	}
	mr.Lock()
	mr.customers[c.GetID()] = c
	mr.Unlock()
	return nil
}

// Update will replace an existing customer information with the new customer information
func (mr *MemoryRepository) Update(c aggregate.Customer) error {
	// Make sure Customer is in the repository
	if _, ok := mr.customers[c.GetID()]; !ok {
		return fmt.Errorf("customer does not exist: %w", customer.ErrUpdateCustomer)
	}
	mr.Lock()
	mr.customers[c.GetID()] = c
	mr.Unlock()
	return nil
}

Как всегда, необходимо добавить тесты. И хочется отметить удобство репозиториев в том числе и при написании тестов: очень просто заменить реальный репозиторий на тестовый, который воспроизведёт условия возникновения багов.

Мне кажется, приведённый тут пример слаб. Если сделать пакет memory_test (как обычно и происходит), то доступа к внутренней мапе клиентов у нас не будет и красота примера меркнет. Но сила репозиториев, скрытых за интерфейсами, всё равно неоспорима. Нужно лишь сказать, что в тестах обычно заменяешь репозиторий его моком, и вот тут описанный подход раскрывает свой потенциал.

package memory

import (
	"testing"

	"github.com/google/uuid"
	"github.com/percybolmer/ddd-go/aggregate"
	"github.com/percybolmer/ddd-go/domain/customer"
)

func TestMemory_GetCustomer(t *testing.T) {
	type testCase struct {
		name        string
		id          uuid.UUID
		expectedErr error
	}

	// Create a fake customer to add to repository
	cust, err := aggregate.NewCustomer("Percy")
	if err != nil {
		t.Fatal(err)
	}
	id := cust.GetID()
	// Create the repo to use, and add some test Data to it for testing
	// Skip Factory for this
	repo := MemoryRepository{
		customers: map[uuid.UUID]aggregate.Customer{
			id: cust,
		},
	}

	testCases := []testCase{
		{
			name:        "No Customer By ID",
			id:          uuid.MustParse("f47ac10b-58cc-0372-8567-0e02b2c3d479"),
			expectedErr: customer.ErrCustomerNotFound,
		}, {
			name:        "Customer By ID",
			id:          id,
			expectedErr: nil,
		},
	}

	for _, tc := range testCases {
		t.Run(tc.name, func(t *testing.T) {

			_, err := repo.Get(tc.id)
			if err != tc.expectedErr {
				t.Errorf("Expected error %v, got %v", tc.expectedErr, err)
			}
		})
	}
}

func TestMemory_AddCustomer(t *testing.T) {
	type testCase struct {
		name        string
		cust        string
		expectedErr error
	}

	testCases := []testCase{
		{
			name:        "Add Customer",
			cust:        "Percy",
			expectedErr: nil,
		},
	}

	for _, tc := range testCases {
		t.Run(tc.name, func(t *testing.T) {
			repo := MemoryRepository{
				customers: map[uuid.UUID]aggregate.Customer{},
			}

			cust, err := aggregate.NewCustomer(tc.cust)
			if err != nil {
				t.Fatal(err)
			}

			err = repo.Add(cust)
			if err != tc.expectedErr {
				t.Errorf("Expected error %v, got %v", tc.expectedErr, err)
			}

			found, err := repo.Get(cust.GetID())
			if err != nil {
				t.Fatal(err)
			}
			if found.GetID() != cust.GetID() {
				t.Errorf("Expected %v, got %v", cust.GetID(), found.GetID())
			}
		})
	}
}

Отлично, первый репозиторий готов. Помните, что нужно держать его тесно связанным с соответствующим доменом (поддерживаем высокую сопряжённость, high cohesion). Сейчас репозиторий управляет только одним агрегатом Customer, так и должно быть. Не стоит добавлять сюда управление другими агрегатами, ведь мы хотим сохранять слабую связность (loose coupling).

Но как нам тогда реализовывать логику работы таверны, если нельзя полагаться на один Customer Repository? Скоро мы начнём собирать вместе разные репозитории и выстраивать процесс работы таверны.

Сервисы: реализуем бизнес-логику

Мы создали все эти сущности, агрегаты и репозитории, но до сих пор наш код не выглядит как цельное приложение. Поэтому нам нужен такой компонент как «сервис». Он свяжет все разрозненные компоненты в бизнес-логику, которая удовлетворит нуждам конкретного домена. В случае с таверной нам понадобится сервис Order, который будет связывать воедино репозитории (CustomerRepository и ProductRepository) для исполнения заказа.

Обычно сервисы имеют доступ ко всем репозиториям, которые необходимы им для исполнения заданной бизнес-логики: Order, Api или Billing. Прелесть ещё заключается в том, что сервисы можно помещать внутрь других сервисов.

Все сервисы будем держать в папке services. Начнём с файла order.go и OrderService, который будет управлять заказами в таверне. У нас пока не хватает некоторых доменов, так что заведём CustomerRepository, а остальные добавим позже.

// Package services holds all the services that connects repositories into a business flow
package services

import "github.com/percybolmer/ddd-go/domain/customer"

// OrderConfiguration is an alias for a function that will take in a pointer to an OrderService and modify it
type OrderConfiguration func(os *OrderService) error

type OrderService struct {
	customers customer.CustomerRepository
}

// NewOrderService takes a variable amount of OrderConfiguration functions and returns a new OrderService
// Each OrderConfiguration will be called in the order they are passed in
func NewOrderService(cfgs ...OrderConfiguration) (*OrderService, error) {
	os := &OrderService{}
	// Apply all Configurations passed in
	for _, cfg := range cfgs {
		err := cfg(os)
		if err != nil {
			return nil, err
		}
	}
	return os, nil
}

// WithCustomerRepository applies a given customer repository to the OrderService
func WithCustomerRepository(cr customer.CustomerRepository) OrderConfiguration {
	// return a function that matches the OrderConfiguration alias,
	// You need to return this so that the parent function can take in all the needed parameters
	return func(os *OrderService) error {
		os.customers = cr
		return nil
	}
}

// WithMemoryCustomerRepository applies a memory customer repository to the OrderService
func WithMemoryCustomerRepository() OrderConfiguration {
	// Create the memory repo, if we needed parameters, such as connection strings they could be inputted here
	cr := memory.New()
	return WithCustomerRepository(cr)
}

Автор просит обратить внимание на способ инициализации сервиса. Я не стану уделять этому много времени, потому что информации и так достаточно. Если хотите узнать подробнее, изучите код и ознакомьтесь с оригиналом.

Теперь можно добавлять методы к сервису, чтобы клиенты получили возможность покупать что-нибудь в таверне.

// CreateOrder will chain together all repositories to create a order for a customer
func (o *OrderService) CreateOrder(customerID uuid.UUID, productIDs []uuid.UUID) error {
	// Get the customer
	c, err := o.customers.Get(customerID)
	if err != nil {
		return err
	}

	// Get each Product, Ouchie, We need a ProductRepository

	return nil
}

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

ProductRepository: заключительный кусочек таверны

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

Создадим новый агрегат Product и фабрику для него.

// File: product.go
// Product is an aggregate that represents a product.
package aggregate

import (
	"errors"

	"github.com/google/uuid"
	"github.com/percybolmer/ddd-go/entity"
)

var ErrMissingValues = errors.New("missing values")

// Product is a aggregate that combines item with a price and quantity
type Product struct {
	// item is the root entity which is an item
	item  *entity.Item
	price float64
	// Quantity is the number of products in stock
	quantity int
}

func NewProduct(name, description string, price float64) (Product, error) {
	if name == "" || description == "" {
		return Product{}, ErrMissingValues
	}

	return Product{
		item: &entity.Item{
			ID:          uuid.New(),
			Name:        name,
			Description: description,
		},
		price:    price,
		quantity: 0,
	}, nil
}

func (p Product) GetID() uuid.UUID {
	return p.item.ID
}

func (p Product) GetItem() *entity.Item {
	return p.item
}

func (p Product) GetPrice() float64 {
	return p.price
}

Обязательно добавим тесты, чтобы убедиться в правильности работы кода.

package aggregate_test

import (
	"testing"

	"github.com/percybolmer/ddd-go/aggregate"
)

func TestProduct_NewProduct(t *testing.T) {
	type testCase struct {
		test        string
		name        string
		description string
		price       float64
		expectedErr error
	}

	testCases := []testCase{
		{
			test:        "should return error if name is empty",
			name:        "",
			expectedErr: aggregate.ErrMissingValues,
		},
		{
			test:        "validvalues",
			name:        "test",
			description: "test",
			price:       1.0,
			expectedErr: nil,
		},
	}

	for _, tc := range testCases {
		t.Run(tc.test, func(t *testing.T) {
			_, err := aggregate.NewProduct(tc.name, tc.description, tc.price)
			if err != tc.expectedErr {
				t.Errorf("Expected error: %v, got: %v", tc.expectedErr, err)
			}
		})
	}
}

В файле domain/product/repository.go определим интерфейс ProductRepository, реализация которого обеспечит доступ к товарам.

// Package product holds the repository and the implementations for a ProductRepository
package product

import (
	"errors"

	"github.com/google/uuid"
	"github.com/percybolmer/ddd-go/aggregate"
)

var (
	ErrProductNotFound = errors.New("the product was not found")
	ErrProductAlreadyExist = errors.New("the product already exists")
)

// ProductRepository is the repository interface to fulfill to use the product aggregate
type ProductRepository interface {
	GetAll() ([]aggregate.Product, error)
	GetByID(id uuid.UUID) (aggregate.Product, error)
	Add(product aggregate.Product) error
	Update(product aggregate.Product) error
	Delete(id uuid.UUID) error
}

Как и в случае с репозиторием клиентов, реализуем хранилище в оперативной памяти: для этого в домене product создадим папку memory.

// Package memory is a in memory implementation of the ProductRepository interface.
package memory

import (
	"sync"

	"github.com/google/uuid"
	"github.com/percybolmer/ddd-go/aggregate"
	"github.com/percybolmer/ddd-go/domain/product"
)

type MemoryProductRepository struct {
	products map[uuid.UUID]aggregate.Product
	sync.Mutex
}

// New is a factory function to generate a new repository of customers
func New() *MemoryProductRepository {
	return &MemoryProductRepository{
		products: make(map[uuid.UUID]aggregate.Product),
	}
}

// GetAll returns all products as a slice
// Yes, it never returns an error, but
// A database implementation could return an error for instance
func (mpr *MemoryProductRepository) GetAll() ([]aggregate.Product, error) {
	// Collect all Products from map
	var products []aggregate.Product
	for _, product := range mpr.products {
		products = append(products, product)
	}
	return products, nil
}

// GetByID searches for a product based on it's ID
func (mpr *MemoryProductRepository) GetByID(id uuid.UUID) (aggregate.Product, error) {
	if product, ok := mpr.products[uuid.UUID(id)]; ok {
		return product, nil
	}
	return aggregate.Product{}, product.ErrProductNotFound
}

// Add will add a new product to the repository
func (mpr *MemoryProductRepository) Add(newprod aggregate.Product) error {
	mpr.Lock()
	defer mpr.Unlock()

	if _, ok := mpr.products[newprod.GetID()]; ok {
		return product.ErrProductAlreadyExist
	}

	mpr.products[newprod.GetID()] = newprod

	return nil
}

// Update will change all values for a product based on it's ID
func (mpr *MemoryProductRepository) Update(upprod aggregate.Product) error {
	mpr.Lock()
	defer mpr.Unlock()

	if _, ok := mpr.products[upprod.GetID()]; !ok {
		return product.ErrProductNotFound
	}

	mpr.products[upprod.GetID()] = upprod
	return nil
}

// Delete remove an product from the repository
func (mpr *MemoryProductRepository) Delete(id uuid.UUID) error {
	mpr.Lock()
	defer mpr.Unlock()

	if _, ok := mpr.products[id]; !ok {
		return product.ErrProductNotFound
	}
	delete(mpr.products, id)
	return nil
}

Как всегда, добавим тесты.

package memory

import (
	"testing"

	"github.com/google/uuid"
	"github.com/percybolmer/ddd-go/aggregate"
	"github.com/percybolmer/ddd-go/domain/product"
)

func TestMemoryProductRepository_Add(t *testing.T) {
	repo := New()
	product, err := aggregate.NewProduct("Beer", "Good for you're health", 1.99)
	if err != nil {
		t.Error(err)
	}

	repo.Add(product)
	if len(repo.products) != 1 {
		t.Errorf("Expected 1 product, got %d", len(repo.products))
	}
}
func TestMemoryProductRepository_Get(t *testing.T) {
	repo := New()
	existingProd, err := aggregate.NewProduct("Beer", "Good for you're health", 1.99)
	if err != nil {
		t.Error(err)
	}

	repo.Add(existingProd)
	if len(repo.products) != 1 {
		t.Errorf("Expected 1 product, got %d", len(repo.products))
	}

	type testCase struct {
		name        string
		id          uuid.UUID
		expectedErr error
	}

	testCases := []testCase{
		{
			name:        "Get product by id",
			id:          existingProd.GetID(),
			expectedErr: nil,
		}, {
			name:        "Get non-existing product by id",
			id:          uuid.New(),
			expectedErr: product.ErrProductNotFound,
		},
	}

	for _, tc := range testCases {
		t.Run(tc.name, func(t *testing.T) {
			_, err := repo.GetByID(tc.id)
			if err != tc.expectedErr {
				t.Errorf("Expected error %v, got %v", tc.expectedErr, err)
			}

		})
	}

}
func TestMemoryProductRepository_Delete(t *testing.T) {
	repo := New()
	existingProd, err := aggregate.NewProduct("Beer", "Good for you're health", 1.99)
	if err != nil {
		t.Error(err)
	}

	repo.Add(existingProd)
	if len(repo.products) != 1 {
		t.Errorf("Expected 1 product, got %d", len(repo.products))
	}

	err = repo.Delete(existingProd.GetID())
	if err != nil {
		t.Error(err)
	}
	if len(repo.products) != 0 {
		t.Errorf("Expected 0 products, got %d", len(repo.products))
	}
}

Добавим OrderService-у возможность использовать ProductRepository с помощью соответствующей опции.

// OrderService is a implementation of the OrderService
type OrderService struct {
	customers customer.CustomerRepository
	products  product.ProductRepository
}

// WithMemoryProductRepository adds a in memory product repo and adds all input products
func WithMemoryProductRepository(products []aggregate.Product) OrderConfiguration {
	return func(os *OrderService) error {
		// Create the memory repo, if we needed parameters, such as connection strings they could be inputted here
		pr := prodmemory.New()

		// Add Items to repo
		for _, p := range products {
			err := pr.Add(p)
			if err != nil {
				return err
			}
		}
		os.products = pr
		return nil
	}
}

Давайте прокачаем метод CreateOrder: теперь можно искать заказанные продукты и возвращать суммарную их стоимость.

// CreateOrder will chain together all repositories to create a order for a customer
// will return the collected price of all Products
func (o *OrderService) CreateOrder(customerID uuid.UUID, productIDs []uuid.UUID) (float64, error) {
	c, err := o.customers.Get(customerID)
	if err != nil {
		return 0, err
	}

	// Get each Product, Ouchie, We need a ProductRepository
	var products []aggregate.Product
	var price float64
	for _, id := range productIDs {
		p, err := o.products.GetByID(id)
		if err != nil {
			return 0, err
		}
		products = append(products, p)
		price += p.GetPrice()
	}

	// All Products exists in store, now we can create the order
	log.Printf("Customer: %s has ordered %d products", c.GetID(), len(products))

	return price, nil
}

Поправим тесты order_test.go, чтобы сервис создавался с обоими репозиториями.

package services

import (
	"testing"

	"github.com/google/uuid"
	"github.com/percybolmer/ddd-go/aggregate"
)

func init_products(t *testing.T) []aggregate.Product {
	beer, err := aggregate.NewProduct("Beer", "Healthy Beverage", 1.99)
	if err != nil {
		t.Error(err)
	}
	peenuts, err := aggregate.NewProduct("Peenuts", "Healthy Snacks", 0.99)
	if err != nil {
		t.Error(err)
	}
	wine, err := aggregate.NewProduct("Wine", "Healthy Snacks", 0.99)
	if err != nil {
		t.Error(err)
	}
	products := []aggregate.Product{
		beer, peenuts, wine,
	}
	return products
}

func TestOrder_NewOrderService(t *testing.T) {
	// Create a few products to insert into in memory repo
	products := init_products(t)

	os, err := NewOrderService(
		WithMemoryCustomerRepository(),
		WithMemoryProductRepository(products),
	)

	if err != nil {
		t.Error(err)
	}

	// Add Customer
	cust, err := aggregate.NewCustomer("Percy")
	if err != nil {
		t.Error(err)
	}

	err = os.customers.Add(cust)
	if err != nil {
		t.Error(err)
	}

	// Perform Order for one beer
	order := []uuid.UUID{
		products[0].GetID(),
	}

	_, err = os.CreateOrder(cust.GetID(), order)

	if err != nil {
		t.Error(err)
	}
}

Tavern: сервис, который содержит другие сервисы

Приступаем к заключительной части: сервису Tavern. У него будет доступ к OrderService, чтобы создавать заказы. Такая упаковка помогает реализовать дополнительную логику. Например, для Tavern целесообразно управлять счетами. Обратите внимание, как легко мы можем встроить логику заказов в этот сервис, не заботясь о подробностях реализации.

package services

import (
	"log"

	"github.com/google/uuid"
)

// TavernConfiguration is an alias that takes a pointer and modifies the Tavern
type TavernConfiguration func(os *Tavern) error

type Tavern struct {
	// orderservice is used to handle orders
	OrderService *OrderService
	// BillingService is used to handle billing
	// This is up to you to implement
	BillingService interface{}
}

// NewTavern takes a variable amount of TavernConfigurations and builds a Tavern
func NewTavern(cfgs ...TavernConfiguration) (*Tavern, error) {
	// Create the Tavern
	t := &Tavern{}
	// Apply all Configurations passed in
	for _, cfg := range cfgs {
		// Pass the service into the configuration function
		err := cfg(t)
		if err != nil {
			return nil, err
		}
	}
	return t, nil
}

// WithOrderService applies a given OrderService to the Tavern
func WithOrderService(os *OrderService) TavernConfiguration {
	// return a function that matches the TavernConfiguration signature
	return func(t *Tavern) error {
		t.OrderService = os
		return nil
	}
}

// Order performs an order for a customer
func (t *Tavern) Order(customer uuid.UUID, products []uuid.UUID) error {
	price, err := t.OrderService.CreateOrder(customer, products)
	if err != nil {
		return err
	}
	log.Printf("Bill the Customer: %0.0f", price)

	// Bill the customer
	// err = t.BillingService.Bill(customer, price)
	return nil
}

Чтобы попробовать сервис в деле, можно создать тест.

package services

import (
	"testing"

	"github.com/google/uuid"
	"github.com/percybolmer/ddd-go/aggregate"
)

func Test_Tavern(t *testing.T) {
	// Create OrderService
	products := init_products(t)

	os, err := NewOrderService(
		WithMemoryCustomerRepository(),
		WithMemoryProductRepository(products),
	)
	if err != nil {
		t.Error(err)
	}

	tavern, err := NewTavern(WithOrderService(os))
	if err != nil {
		t.Error(err)
	}

	cust, err := aggregate.NewCustomer("Percy")
	if err != nil {
		t.Error(err)
	}

	err = os.customers.Add(cust)
	if err != nil {
		t.Error(err)
	}
	order := []uuid.UUID{
		products[0].GetID(),
	}
	// Execute Order
	err = tavern.Order(cust.GetID(), order)
	if err != nil {
		t.Error(err)
	}
}

Давайте теперь заменим реализацию CustomerRepository. Выберем в качестве реального хранилища MongoDB. Тут паттерн «репозиторий» засияет во всей красе. Я очень ценю возможность заменить с такой лёгкостью репозиторий.

Сам я неоднократно слышал, что в проектах меняют базу данных. Например, MySQL на PostgreSQL, но в наших проектах такой потребности ещё не было. Правда, однажды пришлось менять библиотеку для работы с MongoDB. И это было больно. Так что даже если вы не рассматриваете сценарий смены хранилища как возможный, то ещё один повод прятать реализации за интерфейсами — облегчение замены коды, взаимодействующего с вашим хранилищем.

Создадим пакет mongo внутри домена customer и структуру, удовлетворяющую репозиторию CustomerRepository.

Хочется отметить внутреннюю структуру mongoCustomer, которая используется непосредственно для управления данными из MongoDB. Мы не стали использовать для этих целей уже готовый aggregate.Customer, потому что это связало бы агрегат и хранилище (в агрегат просочились бы bson-теги и заменить при желании хранилище стало бы сложно). А мы, наоборот, хотим, чтобы репозиторий полностью отвечал за (де)сериализацию данных, не распространяя свои внутренние сущности вовне. Поэтому мы и не использовали непосредственно в структуре агрегата теги json или bson. Перегонять же из внутренней структуры в агрегат и наоборот будем с помощью функций.

// Mongo is a mongo implementation of the Customer Repository
package mongo

import (
	"context"
	"time"

	"github.com/google/uuid"
	"github.com/percybolmer/ddd-go/aggregate"
	"go.mongodb.org/mongo-driver/bson"
	"go.mongodb.org/mongo-driver/mongo"
	"go.mongodb.org/mongo-driver/mongo/options"
)

type MongoRepository struct {
	db *mongo.Database
	// customer is used to store customers
	customer *mongo.Collection
}

// mongoCustomer is an internal type that is used to store a CustomerAggregate
// we make an internal struct for this to avoid coupling this mongo implementation to the customeraggregate.
// Mongo uses bson so we add tags for that
type mongoCustomer struct {
	ID   uuid.UUID `bson:"id"`
	Name string    `bson:"name"`
}

// NewFromCustomer takes in a aggregate and converts into internal structure
func NewFromCustomer(c aggregate.Customer) mongoCustomer {
	return mongoCustomer{
		ID:   c.GetID(),
		Name: c.GetName(),
	}
}

// ToAggregate converts into a aggregate.Customer
// this could validate all values present etc
func (m mongoCustomer) ToAggregate() aggregate.Customer {
	c := aggregate.Customer{}

	c.SetID(m.ID)
	c.SetName(m.Name)

	return c

}

// Create a new mongodb repository
func New(ctx context.Context, connectionString string) (*MongoRepository, error) {
	client, err := mongo.Connect(ctx, options.Client().ApplyURI(connectionString))
	if err != nil {
		return nil, err
	}

	// Find Metabot DB
	db := client.Database("ddd")
	customers := db.Collection("customers")

	return &MongoRepository{
		db:       db,
		customer: customers,
	}, nil
}

func (mr *MongoRepository) Get(id uuid.UUID) (aggregate.Customer, error) {
	ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
	defer cancel()

	result := mr.customer.FindOne(ctx, bson.M{"id": id})

	var c mongoCustomer
	err := result.Decode(&c)
	if err != nil {
		return aggregate.Customer{}, err
	}
	// Convert to aggregate
	return c.ToAggregate(), nil
}

func (mr *MongoRepository) Add(c aggregate.Customer) error {
	ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
	defer cancel()

	internal := NewFromCustomer(c)
	_, err := mr.customer.InsertOne(ctx, internal)
	if err != nil {
		return err
	}
	return nil
}

func (mr *MongoRepository) Update(c aggregate.Customer) error {
	panic("to implement")
}

Далее нужно добавить функцию-конфигуратор для внедрения нового репозитория в OrderService.

func WithMongoCustomerRepository(connectionString string) OrderConfiguration {
	return func(os *OrderService) error {
		// Create the mongo repo, if we needed parameters, such as connection strings they could be inputted here
		cr, err := mongo.New(context.Background(), connectionString)
		if err != nil {
			return err
		}
		os.customers = cr
		return nil
	}
}

Теперь можно с лёгкостью заменить один репозиторий на другой.

func Test_MongoTavern(t *testing.T) {
	// Create OrderService
	products := init_products(t)

	os, err := NewOrderService(
		WithMongoCustomerRepository("mongodb://localhost:27017"),
		WithMemoryProductRepository(products),
	)
	if err != nil {
		t.Error(err)
	}

	tavern, err := NewTavern(WithOrderService(os))
	if err != nil {
		t.Error(err)
	}

	cust, err := aggregate.NewCustomer("Percy")
	if err != nil {
		t.Error(err)
	}

	err = os.customers.Add(cust)
	if err != nil {
		t.Error(err)
	}
	order := []uuid.UUID{
		products[0].GetID(),
	}
	// Execute Order
	err = tavern.Order(cust.GetID(), order)
	if err != nil {
		t.Error(err)
	}
}

Теперь наша таверна умеет работать как с in-memory хранилищем, так и с MongoDB.

Вот мы и познакомились с основами предметно-ориентированного проектирования. Основные термины, с которыми мы поработали:

• сущности (entities) — изменяемые структуры с идентификатором;

• объекты-значения (value objects) — неизменяемые структуры без идентификаторов;

• агрегаты (aggregates) — комбинация сущностей и объектов-значений под управлением репозиториев;

• репозиторий (repository) — реализация управления агрегатами;

• фабрика (factory) — конструктор для создания сложных объектов и упрощения получения их экземпляров в соседних доменах;

• сервис (service) — набор репозиториев и, возможно, других сервисов, которые вместе формируют бизнес-логику приложения.

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

На самом деле автор написал вторую статью, но я решил, что заканчивать на этом моменте непозволительно.

Рефакторинг

Переносим агрегаты в соответствующие доменные пакеты

Первым делом избавимся от пакета aggregate. Мы уже разобрались, для чего нужны агрегаты, так что теперь нет необходимости так называть пакет. Я склоняюсь к тому, что агрегаты следует помещать в соответствующий домен. Например, агрегат Customer окажется в пакете-домене customer.

Переносим объекты-значения и сущности

У нас ещё есть папки entity и valueobject, что, я думаю, не так уж и плохо, ведь хранение разделяемых структур в отдельных пакетах позволяет избежать циклических импортов. Однако того же эффекта можно добиться иным, более изящным способом. Заведем корневой пакет tavern и переместим туда все сущности и объекты-значения. Получим следующую структуру проекта:

Не забудьте, что в этом случае придётся заново выполнить go mod init и переименовать импорты.

Автор постоянно напоминает о необходимости поддержания структуры проекта в опрятном виде, чтобы в нём было легко ориентироваться. Но последний шаг мне кажется не самым лучшим продолжением его мыслей. Ведь сейчас на верхнем уровне проекта при его расширении будут плодиться сущности. И в итоге всё равно придётся уносить разделяемые объекты в отдельные папки.

Разделение пакета с сервисами

Сейчас все сервисы находятся в одном пакете. Я предпочту разделить его на два: order и tavern. При развитии проекта это предотвратит замусоривание пакета с сервисами. Ещё одним аргументом в пользу такого решения послужит будущее усложнение проекта: запросто может появиться сервис обработки заказов не от индивидуальных клиентов, а от компаний.

Наконец, перед нами итоговый вид проекта.

Заключительный совет, который я хочу вам дать: держите в проекте папку cmd с пакетами запуска приложений внутри проекта. Это может быть запуск API, consumer-а, однократных скриптов и миграций. В папке cmd следует сосредоточить использование инструментов для запуска приложения из командной строки и разнообразные настройки при инициализации.

Не забудьте ознакомиться с оригиналами статей (часть 1, часть 2) и продолжайте изучать DDD.

Мне понравилось переводить, но не уверен, что переводы сейчас востребованы. Как вы считаете, необходимо ли переводить такие статьи на русский, или ознакомление в оригинале сейчас доступно каждому?

успешных коммуникационных стратегий: пять элементов | Школа непрерывных исследований Гласскока

Стратегия и стратегический — два наиболее часто используемых слова в современном бизнесе. Все, от найма до закупок и логистики, является «стратегическим», и, как следствие, этот термин потерял часть своего влияния. Однако в отношении деловых коммуникаций стратегия имеет очень специфическое значение. Деловое общение является стратегическим, если оно учитывает следующие ключевые элементы:

• Целевая аудитория
• Контекст
• Ожидаемые результаты
• Ключевые сообщения
• Соответствующая среда
• Предпочитаемый (ые) курьер (ы)

Давайте подробно рассмотрим каждый из этих элементов.

Аудитория

Стратегическая коммуникация направлена ​​на определенную аудиторию или набор аудиторий, внутри которых обычно есть первичная аудитория, вторичная аудитория и так далее. Эти аудитории, вероятно, имеют разный опыт и ожидания от вас. У них разный уровень знаний по рассматриваемой теме, а также разные приоритеты и проблемы. Наконец, они могут иметь разную степень доверия к вам и вашей организации.

Контекст

Определив аудитории для вашего общения, определите контекст, в котором это общение будет происходить.Распознавайте ключевые события и отношения (прошлые, настоящие и будущие), которые важны для каждой аудитории, к которой вы обращаетесь. Этот контекст определяет мир вашей аудитории, недавний опыт и разумные ожидания на будущее.

Результаты

Каждое деловое общение преследует ряд конкретных целей, будь то передача информации, инструкция, убеждение или преобразование (или некоторая их комбинация). Один из методов определения результатов — рассмотреть «голову, сердце и руки»; то есть, что люди должны знать, верить и делать в результате вашего общения? Какой у вас призыв к действию?

После того, как вы определили свою цель, создавайте сообщения, которые будут резонировать с вашей конкретной аудиторией в текущем контексте.Один из подходов — создать пирамиду сообщений с «заголовком сообщения», за которым следует несколько «причин почему», подкрепленных серией доказательств. Эта структура пирамиды переходит от краткого изложения вашего сообщения на самом высоком уровне к наиболее конкретным свидетельствам, которые ваша аудитория сочтет имеющими отношение к их ситуации, проблемам и интересам.

СМИ

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

Посланник (и)

Хотя вы являетесь основным мессенджером для большинства деловых коммуникаций, вы все равно должны подумать, станете ли вы самым эффективным мессенджером.Первостепенное значение при выборе посланника — «Этика», доверие к посланнику у аудитории. Факторы, влияющие на Ethos, включают:

• Состояние и мощность. Многие аудитории доверяют людям с «большими титулами» (генеральный директор) или явно влиятельным людям в организации.
• Экспертиза. Другая аудитория предпочитает посланника с продемонстрированными знаниями и опытом в предметной области.
• Отношения. Сильные предварительные отношения с аудиторией могут повысить доверие к мессенджеру.

Измерение

Для критически важных коммуникаций вам также необходимо подумать о том, как вы будете измерять свою эффективность: достигли ли вы результатов (знаний, убеждений, действий), которые вы определили в качестве своей стратегической цели? Как однажды заметил Уинстон Черчилль: «Какой бы красивой ни была стратегия, вам следует время от времени смотреть на результаты».

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

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

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

Об авторе

Рик Шелл, доктор философии, преподает лидерские коммуникации и консультативные продажи в рамках программы MBA в Высшей школе бизнеса Джесси Х. Джонса при Университете Райса. Кроме того, он является директором программы бакалавриата по бизнесу, где преподает бизнес-коммуникации. До прихода в школу Джонса он 30 лет проработал в индустрии информационных технологий, занимая руководящие должности в области продаж, стратегического и отраслевого маркетинга, связей со СМИ и аналитиками, обучения продажам и развития глобального бизнеса.Он также работал руководителем аппарата президента и генерального директора своей компании, где разрабатывал и распространял стратегические коммуникации для всех внутренних и внешних аудиторий. Шелл имеет докторскую степень. по английской литературе от Университета Райса.

Процесс общения

Процесс общения

Цель коммуникации — передать информацию — и понимание этой информации — от одного человека или группы к другому человеку или группе.Этот процесс связи разделен на три основных компонента: отправитель , передает сообщение по каналу , , получателю . (На рисунке показана более сложная модель.) Отправитель сначала разрабатывает идею, которая составляется в сообщение, а затем передается другой стороне, которая интерпретирует сообщение и получает значение. Теоретики информации добавили несколько более сложный язык. Разработка сообщения известна как кодирование . Интерпретация сообщения называется декодированием .




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

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

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

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

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

Управление организационными коммуникациями

Обзор

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

В этом наборе инструментов обсуждаются следующие темы коммуникации:

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

Важность комплексной коммуникационной стратегии

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

• Передают согласованные сообщения.
• Создайте узнаваемый бренд в сфере занятости.
• Доставлять сообщения сверху, которые соответствуют миссии, видению и культуре организации .

Влияние эффективного общения

Эффективное общение может способствовать успеху организации во многих отношениях. Это:

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

Влияние неэффективного общения

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

Двусторонняя связь

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

Построение коммуникационной стратегии

Чтобы разработать коммуникационную стратегию, работодатели должны начать с увязки коммуникации со стратегическим планом, включая миссию, видение и ценности организации; его стратегические цели и задачи; и его бренд занятости.

Эффективные коммуникационные стратегии:

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

Коммуникационная стратегия включает в себя следующие элементы:

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

Округа

Каждый в организации должен играть свою роль в коммуникации:

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

Обучение

Обучение коммуникации может охватывать любое количество тем, в том числе:

• Политики коммуникации компании.
• Эффективные навыки письма и презентации.
• Инициативы по обучению инструкторов.

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

Ответ на вопросы сотрудников

Нет лучшего способа вызвать недовольство среди сотрудников, чем попросить их высказать свое мнение, а затем не предпринять никаких действий в ответ на их опасения. Честная и конструктивная обратная связь от сотрудников начинается с доверия и понимания того, что сотрудники могут высказывать свои опасения, не опасаясь возмездия. См. Опросы вовлеченности сотрудников: почему работники им не доверяют?

Работа с внешними средствами массовой информации

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

Измерение результатов

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

Несмотря на сложность этого процесса, организациям следует стремиться к сбору качественной и количественной информации для оценки своих усилий:

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

См. Измерение рентабельности инвестиций от вовлеченности сотрудников.

Аудитория

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

Общение «наверх»

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

Географически рассредоточенная аудитория

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

Разнообразие и глобальные проблемы

Аудитории для организационной коммуникации могут отражать многие аспекты разнообразия: например, возраст, инвалидность, этническая / национальная принадлежность, пол и раса. Разные аудитории могут иметь разные представления и ожидания при предоставлении или получении информации, и эти различия следует учитывать при разработке сообщений для широкой аудитории. См. Межкультурная чувствительность и коммуникация.

Транспортные средства и подходы

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

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

При выборе лучшего средства коммуникации руководители организации должны учитывать:

• Время. Время для информации может быть обязательным, например, в чрезвычайных ситуациях.
• Расположение. Местоположение сотрудников может повлиять на этот выбор. Все сотрудники находятся в одном здании, на нескольких объектах или по всему миру? Они работают виртуально?
• Сообщение. Другой вопрос, влияющий на решение, — конфиденциальность информации. Что касается информации об увольнении или увольнении, большинство профессионалов согласны с тем, что личные встречи важнее любых других средств общения, но некоторые проблемы могут сделать эти встречи невозможными из-за географического положения сотрудников, количества затронутых сотрудников и других факторов.

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

Справочник

Справочник сотрудника используется для ознакомления со стандартными рабочими процедурами, руководящими принципами и политиками. Справочник также используется для сообщения миссии, видения и ценностей организации, помогая создать организационную культуру и бренд занятости. Хотя большинство справочников для сотрудников традиционно выпускались в печатном формате, все больше организаций переходят на электронный формат, позволяющий легко обновлять, документировать и просматривать, особенно когда все сотрудники имеют доступ к компьютерам. См. SHRM Employee Handbook Builder.

Информационные бюллетени

Информационные бюллетени используются для передачи новой информации об организации, ее продуктах и ​​услугах, а также ее сотрудниках. Информационные бюллетени могут быть в печатном или электронном формате и могут быть отправлены сотруднику, а также его или ее семье, особенно когда новости напрямую затрагивают членов семьи. Информационные бюллетени могут публиковаться на регулярной основе (еженедельно, ежемесячно, ежеквартально) или всякий раз, когда у организации есть новости для публикации.

Общие собрания

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

Электронная почта

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

Личные встречи

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

Телефон

Телефон — еще один способ передать информацию сотрудникам. Независимо от того, используется ли он в традиционном смысле, когда личное общение физически невозможно, или в более современном общении посредством вебинаров или рассылок голосовой почты, телефон является основным продуктом средств связи.

Опросы / опросы

Двусторонняя коммуникация жизненно важна для любой эффективной коммуникативной стратегии, а разработка формальной тактики выслушивания сотрудников имеет важное значение.Работодатели могут быстро получить обратную связь с помощью опросов и опросов по конкретным вопросам (например, новым преимуществам или политике) или общим проблемам.

Истории

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

Социальные сети

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

Приложения для обмена сообщениями

Приложения для обмена сообщениями, такие как Jabber и Slack, и чат-боты, которые взаимодействуют с кандидатами и сотрудниками посредством автоматизации, могут стать будущим общения на рабочем месте.Следующее поколение сотрудников предпочитает приложения для чата и обмена сообщениями традиционной электронной почте. См. Обмен сообщениями, приложения для совместной работы могут в конечном итоге превзойти электронную почту на рабочем месте и Что HR-специалисты должны знать о чат-ботах .

Виртуальные встречи команды

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

«Виноградная лоза»

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

Типы сообщений

Тип отправляемого сообщения является основным фактором при выборе подходящего канала связи.

Стандартные рабочие процедуры

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

Общие бизнес-новости

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

Банкротство, сокращение штата и реструктуризация

Работодатели должны использовать несколько различных средств связи, чтобы сообщать и информировать сотрудников, когда организация сталкивается с банкротством, реструктуризацией или сокращением штата. Будь то регулярные брифинги, проводимые высшими руководителями — посредством голосовой почты, оповещений по электронной почте или общих собраний, — или на собраниях отдела или группы, работодатель должен информировать сотрудников обо всей информации, которая может потребоваться для обеспечения бесперебойной работы организации. См. Увольнения требуют общения, сострадания и подчинения.

Изменения в выплатах

Обмен информацией о вознаграждениях сотрудникам может сильно повлиять на восприятие сотрудниками ценности их компенсационного пакета и, более того, ценности их работы в организации. Соответственно, сообщения о преимуществах следует тщательно планировать с использованием средств, соответствующих обстоятельствам: печатные сообщения, виртуальные или личные встречи, индивидуальные брифинги и так далее.Изменения основных преимуществ — например, новый оператор связи или новые опции — требуют более комплексного подхода, чем тот, который используется для обычных обновлений. Se e Сделайте свой веб-сайт о пособиях круглогодичным центром

Чрезвычайные ситуации

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

Слияние или поглощение

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

Аутсорсинг

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

Юридические вопросы

Некоторые способы связи сопровождаются юридическими ограничениями и / или руководящими принципами, которые влияют на доставляемое сообщение или то, как работодатель доставляет информацию. Например, работодатели могут столкнуться с обвинениями в несправедливой трудовой деятельности в результате того, как они доводят до сотрудников желание компании оставаться свободной от профсоюзов. См. Руководство Союза по коммуникациям: TIPS и FOE.

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

См. :

Должны ли работодатели объявлять или размещать дни рождения сотрудников?

Запрещает ли правило конфиденциальности HIPAA работодателю сообщать другим сотрудникам о рождении, госпитализации сотрудников или о неотложных семейных обстоятельствах?

Насколько правдивы вы можете быть, давая рекомендации?


Глава 6.Сообщения для повышения интереса | Раздел 1. Разработка плана общения | Основной раздел

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

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

Что мы подразумеваем под общением?

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

Связь может принимать разные формы, в том числе:

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

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

Какой план связи?

Планирование — это способ организовать действия, которые приведут к достижению цели.

В данном случае ваша цель — повысить осведомленность о долгосрочной пользе вашей инициативы для вашего сообщества.

Чтобы разработать план общения, необходимо ответить на несколько основных вопросов:

• Почему вы хотите общаться с сообществом? (Какова ваша цель?)
• Кому вы хотите это сообщить? (Кто ваша аудитория?)
• Что вы хотите пообщаться? (Ваше сообщение?)
• Как вы хотите это передать? (Какие каналы связи вы будете использовать?)
• К кому обратиться и что делать, чтобы использовать эти каналы? (Как вы будете распространять свое сообщение?)

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

• Реализуйте свой план действий. Создайте свое сообщение и распространите его среди целевой аудитории.
• Оцените свои коммуникационные усилия и соответствующим образом скорректируйте свой план.
• Держись.

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

Почему вам следует разработать план общения?

• План позволит точно нацелить ваше общение. Это дает вам структуру, чтобы определить, с кем вам нужно связаться и как.
• План может быть долгосрочным, помогая вам определить, как со временем поднять свой профиль и улучшить свой имидж в сообществе.
• План сделает ваши коммуникационные усилия более эффективными, результативными и продолжительными.
• Тарифный план все упрощает. Если вы потратите некоторое время на планирование в начале работы, вы сможете сэкономить много времени позже, потому что вы знаете, что вам следует делать на любом этапе процесса.

Когда следует разработать план общения?

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

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

Как разработать план общения?

Планирование коммуникации — это восьмиэтапный процесс. Шаги:

1. Определите цель вашего общения
2. Определите свою аудиторию
3. Спланируйте и создайте свое сообщение
4. Учитывайте свои ресурсы
5. План препятствий и чрезвычайных ситуаций
6. Продумайте, как вы будете общаться со средствами массовой информации и другими людьми, которые могут помочь вам распространить ваше сообщение
7. Создать план действий
8. Решите, как вы будете оценивать свой план и скорректируйте его, исходя из результатов его выполнения

1.Определите свою цель

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

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

2. Определите свою аудиторию

С кем вы пытаетесь связаться? Знание своей аудитории позволяет логически спланировать ваше общение. Вам понадобятся разные сообщения для разных групп, и вам понадобятся разные каналы и методы для достижения каждой из этих групп.

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

• Демография. Демографические данные — это просто базовая статистическая информация о людях, такая как пол, возраст, этническое и расовое происхождение, доход и т. Д.
• География . Возможно, вы захотите сосредоточиться на целом городе или регионе, на одном или нескольких районах или на людях, которые живут рядом с определенным географическим или созданным человеком объектом.
• Работа .Вам могут быть интересны люди, занимающиеся определенной работой, или безработные.
• Здоровье . Вы можете беспокоиться о людях, подверженных риску или страдающих определенным заболеванием — возможно, повышенном артериальном давлении или диабете — или вы можете направлять усилия по укреплению здоровья — «Ешьте здоровую пищу, регулярно занимайтесь спортом» — на все сообщество.
• Поведение. Вы можете быть нацелены, например, на курильщиков или молодежь, вовлеченную в насилие.
• Отношения. Вы пытаетесь изменить мнение людей или вывести их на новый уровень понимания?

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

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

3. Сообщение

При создании сообщения учитывайте содержание, настроение, язык и дизайн.

Содержание

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

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

Настроение

Подумайте, какие эмоции вы хотите вызвать.

От настроения вашего сообщения во многом зависит, как люди на него отреагируют. В общем, если настроение слишком экстремальное — слишком негативное, слишком пугающее, пытающееся заставить вашу аудиторию чувствовать себя слишком виноватым — люди не будут обращать на это особого внимания. Может потребоваться некоторый опыт, чтобы научиться находить правильный баланс.Сохранение позитивного тона обычно поможет большему количеству людей, чем вызов негативных чувств, таких как страх или гнев.

Язык

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

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

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

Каналы связи

Что ваша целевая аудитория читает, слушает, смотрит или чем занимается? Вы должны связаться с ними, разместив свое сообщение там, где они его увидят.

• Плакаты
• Листовки и брошюры — они могут быть более убедительными в тех местах, где люди уже думают о проблеме (кабинеты врачей по вопросам здоровья, супермаркеты по вопросам питания и т. Д.).
• Информационные бюллетени
• Рекламные материалы. Такие предметы, как кепки, футболки и кружки, могут служить эффективным каналом для вашего сообщения.
• Комиксы или другие материалы для чтения. Материалы для чтения, которые интересны целевой аудитории, могут быть использованы для передачи сообщения посредством рассказа, за которым читатели хотят следовать, или посредством убедительного характера средства массовой информации и его дизайна.
• Интернет-сайты — Помимо веб-сайта вашей организации, интерактивные сайты, такие как Facebook, Twitter и YouTube, являются эффективными средами для общения
• Письма в редакцию
• Новости, рубрики и репортажи
• Пресс-релизы и пресс-конференции
• Презентации или присутствие на местных мероприятиях и местных и национальных конференциях, ярмарках и других собраниях
• Работа с населением
• Общественные или национальные мероприятия — Великое американское дымоудаление, Национальный день грамотности, общественный вечер против насилия «Верни ночь» и другие общественные мероприятия могут служить для того, чтобы донести мысль и выделить проблему.
• Публичные демонстрации
• Сарафанное радио
• Музыка
• Экспонаты и общественное искусство — Одеяло от СПИДа, огромное лоскутное одеяло с квадратами, сделанными тысячами людей в память о жертвах эпидемии ВИЧ, является ярким примером.
• Фильмы — С самого начала киноиндустрии фильмы несли информацию о расе, статусе женщин, грамотности взрослых, гомосексуализме, психических заболеваниях, СПИДе и многих других социальных проблемах.
• TV. Телевидение может не только передавать простые сообщения — рекламу и общественные объявления (PSA), но и представлять новости и развлекательные программы, которые касаются вашей проблемы или профиля вашей организации.
• Театр и интерактивный театр — Пьеса или сценка, особенно сцена, написанная людьми, которые испытали то, что она иллюстрирует, могут быть мощным способом представить проблему или подчеркнуть необходимость услуг или изменений.

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

4. Ресурсы

Чем у вас есть деньги? Есть ли у вас люди, чтобы сделать это возможным? Если вы собираетесь потратить деньги, каковы шансы, что результаты окупятся? Кто что потеряет и кто что получит, используя ваши финансовые и человеческие ресурсы?

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

5. Предвидеть препятствия и чрезвычайные ситуации

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

Важно попытаться предвидеть подобные проблемы и составить план их решения. Кризисное планирование должно быть частью любого коммуникационного плана, чтобы вы знали, что делать в случае возникновения проблемы или кризиса. В антикризисных планах следует указать, кто за что отвечает — работа со СМИ, исправление ошибок, решение, когда что-то нужно переделывать, а не исправлять и т. Д.Он должен охватывать как можно больше ситуаций и как можно больше аспектов каждой ситуации.

6. Определите, как вы будете общаться со средствами массовой информации и другими людьми, чтобы распространять свое сообщение

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

Люди, которые могут помочь вам в распространении вашего послания, могут варьироваться от официальных лидеров сообщества — выборных должностных лиц, руководителей известных местных предприятий, духовенства и т. Д. — до общественных активистов и простых граждан. Учреждения и организации, такие как колледжи, больницы, клубы обслуживания, религиозные сообщества и другие медицинские и общественные организации, все имеют доступ к группам членов сообщества, которым может понадобиться услышать ваше послание.

7. Составьте план действий

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

8. Оценка

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

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

Стратегические коммуникации для информирования или убеждения

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

Стратегическая коммуникация включает четыре элемента: знание своей цели, понимание своей аудитории, выбор соответствующей стратегии структуры сообщения и определение соответствующего канала. Звучит просто. Так почему же мы часто слышим припев «проблема здесь в общении»?

Знать свою цель

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

Понимание своей аудитории

Эффективное общение предполагает анализ ситуации не только с вашей точки зрения как отправителя сообщения, но и с точки зрения вашей аудитории. Адаптация вашего общения к потребностям и интересам вашей аудитории гарантирует вам шанс на то, что вас поймут и вы добьетесь своей цели. Итак, что вы хотите знать о своей аудитории?

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

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

Выбор подходящей структуры сообщения

Стратегия

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

Следует рассмотреть две стратегии: косвенный и прямой подход.

Применение косвенного подхода

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

• Не информирован, требуется справочная информация и подробности
• Воспринимает вашу идею, но требует убедительности
• Враждебен вашей идее, но готов вас услышать
• Ориентация на анализ

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

Применение прямого подхода

Прямой подход часто называют «практическим» и «исполнительным» подходом, потому что он формулирует основную идею в начале сообщения. Этот подход используется для аудитории:

• Информирован и не требует дополнительной информации
• Получатель сообщения
• Готов принять плохие новости
• Ориентация на результат

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

Различия между общением с целью информирования и убеждения

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

Если ваше сообщение может расстроить аудиторию или вам нужно заставить их сделать что-то, чего они иначе не могли бы сделать, вам нужно подумать о стратегии убеждения. Особенно полезный фреймворк я рекомендую студентам и корпоративным клиентам в течение многих лет.Это классика под названием «Мотивированная последовательность», адаптированная из концепции, разработанной Аланом Х. Монро в начале 1960-х годов.

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

1. Внимание: цель состоит в том, чтобы заинтересовать читателя и представить преимущества предлагаемого действия, которое вы рекомендуете.Например, если вы предлагаете клиентам обновить их контракт на сотовый телефон или специальное оборудование, проиллюстрируйте функции безопасности голосовой активации или оборудования громкой связи.
2. Потребность: Обозначьте специфику или масштаб проблемы. Предоставьте достаточно доказательств того, что эта проблема является неотложной. Используя приведенный выше пример, вы можете отметить потерянное время, выполняя поиск по часто вызываемым номерам, а не просто произнося имя человека, которому вы хотите позвонить, или упомянуть инциденты, связанные с авариями, с участием водителей, которые использовали свои мобильные телефоны без оборудования громкой связи. .
3. Удовлетворение: расскажите аудитории, как ваше предложение устранит выявленные вами проблемы. Предоставьте доказательства того, что предложенный курс действий сработал в аналогичных ситуациях. Рассмотрите любые возражения или альтернативы, которые, по вашему мнению, могут возникнуть, и покажите, насколько другие решения менее привлекательны, чем ваше.
4. Визуализируйте: Заставьте аудиторию увидеть, какую пользу они извлекут из предложения. Обязательно покажите любое негативное воздействие, которое может произойти, если они не соблюдают правила. Покажите положительные преимущества, которые вы получите, если решите последовать вашему совету.
5. Действие: Скажите аудитории, что именно вы хотите, чтобы она сделала. В большинстве убедительных сообщений этот важный шаг игнорируется. Уверенно укажите действие, которое вы хотите. Напомните аудитории о преимуществах, на которые они могут рассчитывать. Будьте твердыми и точными. Не думайте, что они интуитивно знают, что нужно делать. В результате должен получиться обновленный контракт, включающий меры безопасности.

Выбор подходящего канала

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

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

Этот пост адаптирован из технической заметки профессора Дардена Джун Уэст Стратегическое мышление о коммуникациях (Darden Business Publishing).

(PDF) Коммуникация как стратегический инструмент в процессах изменений

384 Международный журнал деловых коммуникаций 51 (4)

Даунс, К. В., ДеВайн, С., и Гринбаум, Х. Х. (1994). Меры организационной коммуникации —

катион. В R. B. Rubin, P. Palmgreen, H.-E. Sypher и др. (Ред.), Коммуникационное исследование

меры: Справочник (стр. 57-78). Нью-Йорк, Нью-Йорк: Guilford Press.

Эрвин Д. и Гарман А. (2009).Сопротивление организационным изменениям: объединение исследований и практики

. Журнал лидерства и развития организации, 31 (1), 39-56.

Ford, J.K., MacCallum, R.C. & Tait, M. (1986). Применение исследовательского факторного анализа

sis в прикладной психологии: критический обзор и анализ. Психология персонала, 39 (2),

291-314.

Форд Дж. И Форд Л. (2009). Сопротивление изменениям: пересмотр и расширение. Исследования в области

«Организационные изменения и управление», 17, 211-239.

Ганье, М., Кестнер, Р., и Цукерман, М. (2000). Содействие принятию организационных изменений

: важность самоопределения. Журнал прикладной социальной психологии,

30 (9), 1843-1852.

Галпин Т. Дж. (1996). Человеческая сторона изменений: практическое руководство по организационной реорганизации.

Сан-Франциско, Калифорния: Джосси-Басс.

Гарвин Д. (2000). Обучение в действии. Кембридж, Массачусетс: Издательство Гарвардской школы бизнеса.

Гольдхабер, Г.М. (1999). Организационная коммуникация в 1976: Настоящая область и будущее

направлений. В П. Салем (ред.), Организационная коммуникация и изменения, (стр. 4-30).

Cresskill, NJ: Hampton Press.

Голдхабер, Г., и Кривонос, П. (1977). Коммуникационный аудит ICA: процесс, статус и критерии. Журнал делового общения, 15 (1), 41-64.

Грец, Ф., Риммер, М., Лоуренс, А., и Смит, А. (2006). Управление организационными изменениями.

Милтон, Австралия: Wiley.

Хинкин Т. Р. (1998). Краткое руководство по разработке показателей для использования в опросных листах —

анкеты, Организационные методы исследования, 1 (1), 104-121.

Джонсон, Дж. Д. (1992). Подходы к организационной структуре коммуникации. Журнал

Business Research, 25 (2), 99-113.

Джонс, К., Данфи, Д., Фишман, Р., Ларн, М., и Кантер, К. (2006). В большой компании:

Раскрытие секретов культурной трансформации.Сидней: Синергетика человека.

Ким, Дж. О., и Мюллер, К. У. (1978). Введение в факторный анализ: что это такое и как это сделать

it. Серия работ Университета Сейджа по количественным приложениям в социальных науках (серия

№ 07-013). Беверли-Хиллз, Калифорния: Sage Publications.

Кунц, Х. (2001). Менеджмент: глобальная перспектива. 10-е изд. Нью-Йорк, штат Нью-Йорк: Макгроу-Хилл.

Лангёрген А., Галлоуэй Т. А. и Оберже Р. (2006). Gruppering av kommuner etter folke-

mengde og økonomiske rammebetingelser 2003.[Групповое деление муниципалитетов на основе

на основе численности населения и экономических условий 2003] (Отчет 2006/8). Осло: Центральное бюро статистики

.

Пардо дель Валь, М., и Мартинес Фуэнтес, К. (2003). Сопротивление изменениям: обзор литературы и эмпирическое исследование

. Решение руководства, 41 (2), 148-155.

Рафферти, А. Э. и Джиммисон, Н. Л. (2010). Командный климат изменения: анализ на уровне группы

взаимосвязей между информацией об изменениях и участием в изменениях, ролевыми стрессорами и

благополучием.Европейский журнал трудовой и организационной психологии, 19 (5), 551-586.

Ребер А. С. (1995). Словарь психологии. Нью-Йорк, Нью-Йорк: Книги Пингвина.

Робертс К., & О`Рейли К.А. (1974). Измерение организационной коммуникации. Журнал

Прикладная психология, 59 (3), 321-326.

Салем П. (Ред.). (1999). Организационная коммуникация и изменения. Кресскилл, Нью-Джерси: Hampton

Press.

5 советов по улучшению коммуникации вокруг изменений

Эффективная коммуникация имеет решающее значение для каждого проекта управления изменениями.Как специалист по управлению изменениями вы знаете, что электронное письмо в понедельник для обучения во вторник и начало работы в среду не настраивают на успех затронутых людей. Коммуникации должны быть ориентированы на нужных людей в нужное время и правильными способами. Используя наш коллективный опыт и более чем двадцатилетние исследования Prosci Best Practices in Change Management, мы составили пять полезных советов, которые помогут улучшить ваше общение по поводу изменений.

общение для успеха изменений

1.Структурируйте свои усилия

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

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

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

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

2. Начните раньше


Коммуникации наиболее эффективны, когда они начинаются на ранней стадии жизненного цикла проекта.Раннее общение является более активным и может смягчить негативные последствия неспособности привлечь сотрудников. Фактически, начало коммуникационных усилий в начале проекта было третьим в списке того, что респонденты сделали бы по-другому в следующем проекте в отчете «Лучшие практики управления изменениями — 11-е издание» .

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

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

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

3. Делайте чаще


На вопрос, что бы они сделали по-другому в отношении коммуникаций, участники сравнительного исследования Prosci’s Best Practices in Change Management ответили, что они будут больше и чаще общаться с большим количеством людей и со всеми уровнями своих организаций.

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

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

Людям, передающим сообщение, может быть неудобно делать это несколько раз. Они могут сказать: «Но я уже сказал это людям». Тем не менее, специалисты по управлению изменениями являются помощниками коммуникаторов и должны требовать от них ответственности за многократное общение с помощью настраиваемых сообщений.

4. Ответьте на вопросы людей


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

Одна из основных ловушек, которую вы должны ожидать, — это то, что коммуникатор будет говорить только о том, что его волнует и что его беспокоит.Руководители высшего звена попадают в эту ловушку, говоря исключительно о видении и будущем организации. Члены команды проекта попадают в эту ловушку, сообщая исключительно о решении, к которому они пришли, и об альтернативах, которые они оценили. Это не ошибка. Мы хотим, чтобы старшие руководители были обеспокоены видением организации, и мы хотим, чтобы члены проектной группы были обеспокоены их решением. Однако, когда дело доходит до общения с сотрудниками, усилия должны быть направлены на то, чтобы ответить на наиболее актуальные вопросы сотрудников об изменении.

В начале изменения необходимо ответить на несколько ключевых вопросов:

• Почему мы меняемся?
• Какие риски не менять?
• Что это для меня?
• Как на меня повлияют?
• Как это повлияет на мою команду?

Обратите внимание на вопрос: «Каковы конкретные детали изменения?» не появляется в списке. Коммуникационные планы должны сначала ответить на основные вопросы о том, что волнует людей, прежде чем они перейдут к конкретным деталям изменения.Этот план коммуникаций для менеджеров является полезной отправной точкой для таких обсуждений, связанных с изменениями, и коучинговых сессий с сотрудниками.

5. Используйте предпочитаемые отправители


Сотрудники предпочитают слышать определенные сообщения от определенных ролей в организации во время перемен. Сравнительное исследование Prosci Best Practices in Change Management последовательно показывает, кто эти предпочитаемые отправители и какие сообщения они должны передавать.

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

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

«Голос» перемен имеет значение. Даже если содержание сообщения точно такое же, сотрудники оценят отправителя сообщения. Использование предпочтительных отправителей гарантирует, что сообщения будут получены должным образом и к изменениям будут отнесены серьезно.

Лучшее общение, лучшие результаты

Обмен данными во время изменения — это не единичное событие, которое заканчивается, когда вы нажимаете «отправить». Целенаправленный, структурированный план с целенаправленными сообщениями, отправляемыми нужными людьми в нужное время, помогает затронутым сотрудникам быстрее понять и принять изменения, избегая проблем — и все это при настройке вашего проекта и людей на успех.