Author: admin

Доказательный менеджмент. Интервью с Патрисией Конг из scrum.org

Доказательный менеджмент. Интервью с Патрисией Конг из scrum.org
Трансформаторная

 
 
00:00 / 43:14
 
1X
 

Сегодняшний выпуск “Трансформаторной” экспериментальный: я решил попробовать формат интервью. У меня в гостях (виртуально, конечно) была Патрисия Конг (Patricia Kong) – Владелец Продукта энтерпрайз-решений в scrum.org. Патрисия около 7 лет работает в scrum.org, помимо этого у неё есть некоторый бэкграунд в организационной психологии, а так же бизнес-бэкграунд. Она рассказала о том, что такое фреймворк “Доказательный менеджмент”, как он был создан в scrum.org и какие выгоды организация может получить от его применения. Также она поделилась некоторыми советами о том, с чего начать внедрение Доказательного менеджмента в организации.

Как вы наверно уже поняли, интервью на английском языке, но на youtube я выложил версию с русскими субтитрами.

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

В интервью упомянуты:


Музыка для заставки: Our Only Lark, любезно опубликованная Blue Dot Sessions под лицензией Creative Commons Attribution-NonCommercial License.

Деминг был не прав! (И Пикулев с Петровым тоже.)

Деминг был не прав! (И Пикулев с Петровым тоже.)
Трансформаторная

 
 
00:00 / 8:09
 
1X
 

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

Музыка для заставки: Our Only Lark, любезно опубликованная Blue Dot Sessions под лицензией Creative Commons Attribution-NonCommercial License.

Фреймворк SOAP для организационных изменений

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

Фреймворк SOAP используется в рамках проблемно-ориентированного подхода к медицинским записям. Это удобный способ структурирования работы с пациентами, предложенный доктором Лоуренсом Уидом в 1970х. Он может применяться как при первичном осмотре для сбора анамнеза, так и при последующих осмотрах чтобы уточнить диагноз, проверить эффективность лечения и, при необходимости, скорректировать лечение. В медицине этот фреймворк содержит следующие компоненты:

Subjective – ObjectiveAssessment – Plan. Таким образом собирая анамнез и делая медицинские записи, врач последовательно проходит по 4 элементам:

  • Субъективные данные. Здесь собирается максимум информации о том, как больной оценивает своё состояние, историю развития этого состояние и т.п. Дополнительную структуру этой части опроса создаёт мнемоника OLDCHARTS (Onset, Location, Duration, Character, Aggravating / Alleviating factors, Radiation, Timing, Severity), описывающая ключевые элементы субъективной картины болезни: Возникновение, Локализация, Длительность, Характер, Усиливающие/Смягчающие факторы, Распространение, Тайминг, Серьёзность.
  • Объективные данные. Сюда входит изменение различных жизненных показателей (кровяное давление, пульс, температура и т.д.), результаты осмотра и инструментальных тестов (рентгенография, УЗИ и т.п.)
  • Оценка. В последнее время assessment всё чаще заменяют на Hypothesis так что мнемоника превращается в SOHP, чтобы сделать акцент на использовании доказательных подходов (этот вариант мнемоники был предложен клиническим психологом Барбарой Л. Инграм в её книге о клинической концептуализации), но принципиально суть этого элемента не меняется: в этой части врач описывает свои предположения о том, каков диагноз пациента на основе данных, полученных в предыдущих элементах. Оценка состоит из собственно диагноза и обоснования его постановки.
  • План. Собственно тут описывается план терапии с учётом полученных данных и диагностической гипотезы.

 

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

 

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

 

При некоторой адаптации этот фреймворк хорошо подходит для работы с организационными изменениями, особенно для первичного знакомства с клиентом/командой и для планирования изменений. Начинаю я сессию с информирования клиента о том, как будет проходить наша работа (рассказ о структуре SOHP и о том, почему мне важна вся эта информация), получаю его согласие на эту работу, а далее использую адаптированный для agile-коучинга SOHP фреймворк:

  • Субъективные данные. Задача – собрать максимум информации о том, как клиент оценивает существующие проблемы организации и каковы его ожидания от привлечения Agile-коуча. Мнемонику OLDCHARTS  я немного расширил, так как, в отличии от медицины, где существуют объективные показатели здоровья, в организационных изменениях определение успеха может сильно отличаться у разных клиентов. Я использую OLDCHARTERS (Onset, Location, Duration, Character, Aggravating / Alleviating factors, Radiation, Timing, Expectations, Results at success/failure, Severity): Возникновение, Локализация, Длительность, Характер, Усиливающие/Смягчающие факторы, Распространение, Тайминг, Ожидания, Результаты в случае успеха и неудачи, Серьёзность. Для уточнения субъективной картины я использую такие вопросы:
    • Что побудило вас обратиться за помощью? (Так же как и с пациентом, я рекомендую начинать с максимально открытого вопроса и дать возможность клиенту высказаться, чтобы получить общее представление о том, как клиент воспринимает текущую ситуацию. Следом за этим можно задать вопрос, побуждающий к более детальному описанию проблемы: А что ещё?)
    • Как давно у вас существует эта проблема? Были ли у вас подобные ситуации в прошлом? Если да, то что именно и что вы делали в прошлый раз, чтобы улучшить ситуацию? (Возникновение / Длительность)
    • На сколько сильно вас беспокоит эта проблема? Мешает ли она вашим нормальной работе организации? Какую метафору бы вы использовали для описания проблемы? Как бы вы оценили интенсивность проблемы от 1 до 10? Как изменялась проблема с течением времени? (Серьёзность / Характер)
    • Описанная проблема характерна для всей организации, или какой-то её части?  Как локализация проблемы распространялась со временем? (Локализация/Распространение)
    • Что вы уже пробовали, чтобы изменить ситуацию? Как это повлияло на ситуацию? (Усиливающие/Смягчающие факторы)
    • Становится ли проблема со временем хуже, лучше или не меняется? Если есть изменения, с какой скоростью они происходят? (Тайминг / Длительность)
    • Есть ли какие-то ещё связанные проблемы? (Помогает выявить проблемы, которые клиент считает отдельными, но которые могут быть связаны с основным запросом)
    • Чем по вашему вызвана проблема? Чего вы опасаетесь в связи с этой проблемой? (эти вопросы помогают выявить предположения клиента о том, в чём причина и к чему может привести проблема, если её не решить)
    • Почему вы решили именно сейчас обратиться за помощью? Что изменилось по сравнению с тем, как эта проблема проявляется обычно? (Это может быть связано с тем, что проблема или ситуация ухудшилась, или, возможно, у клиента изменилось восприятие важности проблемы. Последнее часто происходит после посещения тренингов или наблюдения каких-то изменений в дружественной организации).
    • Чего вы ожидаете от меня в рамках нашего взаимодействия? Что, по вашим ожиданиям, я буду делать? Что, по вашим ожиданиям, я не буду делать? (Это очень важные вопросы, нацеленные на прояснение, чего ожидает клиент от вас и можете ли вы работать в соответствии с его ожиданиями, или вам нужно обсудить и выровнять ожидания.)
    • Как вы поймёте, что наша работа по изменениям привела к успеху? Что вы увидите в своей организации через полгода(год, три и т.п.) если мы вместе сможем решить проблему? (этот вопрос позволяет выявить, как клиент видит успех, а также оценить реалистичность ожиданий клиента)
    • Как вы поймёте, что наша работа стала полным фиаско? Что вы увидите в своей организации через полгода(год, три и т.п.) если наши усилия будут неудачными? (этот вопрос помогает выявить, что для клиента является критериями неуспеха, а также выявить возможные сценарии, при которых организационные изменения могут ухудшить ситуацию)
  • Объективные данные. На этом этапе проводится сбор имеющихся метрик, связанных с проблемой, которые помогут в дальнейшем оценить эффект от тех или иных изменений, сбор и систематизация результатом наблюдений за работой организации, качественная и количественная оценка текущего состояния. Здесь же можно предложить начать сбор дополнительных метрик, которые могут быть полезными для того, чтобы оценить эффект от изменений.
  • Гипотеза. Следующим шагом я строю гипотезу об источниках проблемы и обосновываю своё предположение. Чтобы эта часть была по-настоящему гипотезой, я не просто описываю, что я считаю причиной и почему я так думаю, но и описываю то, как я смогу проверить, что моё предположение верно, и какие эксперименты я могу провести, чтобы подтвердить или опровергнуть своё предположение, и какие результаты этих экспериментов я буду считать подтверждением.
  • План. Здесь я описываю план экспериментов по организационным изменениям с учётом полученных данных и гипотезы.

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

 

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

Контекст:

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

Subjective:

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

Objective:

Команда использует все элементы фреймворка Скрам. На текущий момент команда проработала 2 двухнедельных спринта, но пока не поставила ни одного инкремента продукта. Видение продукта явно не определено, хотя члены команды могут в целом описать, что они делают и кто их конечные пользователи. В бэклоге команды присутствует 12 элементов в формате User Story, ни у одного элемента не определены критерии приёмки.  Владелец продукта представитель бизнес-подразделения, транслирующий пожелания руководителя подразделения-заказчика. Владелец продукта затрудняется ответить, какой из элементов бэклога наиболее ценен с точки зрения бизнеса. Команда распределённая: Команда Разработки и Скрам-мастер сидят в одной комнате, владелец продукта находится в здании, расположенном в другой части города. Пока никаких метрик не собирается, кроме скорости работы команды (в Сторипоинтах). В течении первых двух спринтов команда поставляла около 50% от того, что было запланировано.

Hypothesis:

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

Plan:

  • Провести сессию по формированию Видения продукта и сессию улучшения бэклога продукта с привлечением бизнес-заказчика (руководителя подразделения на стороне бизнеса).
  • Рекомендовать пригласить руководителя подразделения-заказчика на Обзоры Спринта.
  • Наблюдение за событиями Скрама и коучинг Скрам-мастера по улучшению событий.
  • Персональный коучинг Скрам-мастера.

Эпизод 6. Иерархия в Скрам-команде

Эпизод 6. Иерархия в Скрам-команде
Трансформаторная

 
 
00:00 / 12:17
 
1X
 

Говорят, то в Agile и иерархии несовместимы. И что в Скрам команде нет иерархии. И в Команде Разработки внутри Скрам-команды все равны. Вот что я думаю…

Музыка для заставки: Our Only Lark, любезно опубликованная Blue Dot Sessions под лицензией Creative Commons Attribution-NonCommercial License.

Внедрение канбана среди трёхлетней девочки

В этой статье я хочу поделиться своей маленькой историей успеха, которая, надеюсь, будет полезна для кого-то из моих читателей.
Помимо того, что я agile-коуч, психолог и философ любитель, я ещё и счастливый отец замечательной девочки. И, как и многие родители, сталкиваюсь с тем, что научить ребёнка убирать за собой игрушки непросто. И часто для того, чтоб по квартире можно было безопасно передвигаться, приходится по несколько раз на дню наводить порядок.
Я читал несколько статей о том, как родители используют Скрам или Канбан для того, чтоб помочь детям организоваться и внести немного порядка. Но в тех статьях речь шла о детях школьного возраста. А что если твоей дочке всего 3? Я бы сделал ей канбан карточки с тем, что надо сделать, но она не умеет читать? Но это меня не остановит 🙂
Ещё одна проблема: я могу, конечно, сделать карточку “Убрать игрушки”, но для неё это может быть слишком сложно, и не даст той динамики, которую я хочу создать: возможность видеть свой прогресс.
А что если я смогу разделить уборку игрушек на маленькие шаги и нарисовать то, что надо сделать? И я решил попробовать.
Я зашёл в комнату, где Лана играет. Весь пол был покрыт слоем самых разных игрушек. Кое где были места, куда можно было бы шагнуть, но идти надо очень аккуратно, чтобы на что-нибудь не наступить. Доченька поиграла. 🙂 “Хорошо”, сказал я себе,- “давай посмотрим, что я смогу придумать”. Я посмотрел, какие игрушки сейчас разбросаны по комнате. Их можно было разделить на 3 группы: машинки, динозавры и мягкие игрушки. Я решил для каждого вида нарисовать отдельную канбан карточку.
-Зайка давай мы с тобой поиграем в игру. Смотри, мы сейчас с тобой нарисуем карточки с твоими игрушками, которые надо убрать. Что это такое?
-Динозавр!
-Да. У тебя есть динозавры. А ещё у тебя какие есть грушки?
-Машинки.
-Давай нарисуем машинку.
-Хорошо!
-А что я нарисовал сейчас?
-Это мишка!
-Точно. Это будут все твои мягкие игрушки. Теперь пойдём в комнату.
У нас есть доска, на которой можно рисовать мелом, и она оказалась чистой.
-Смотри. Вот тут у нас будет три части. Красная – это то, что нам надо сделать. Белая – то, что мы делаем сейчас. Зелёная – то, что готово. Что ты хочешь убрать сначала: динозавров, машинки или мягкие игрушки?
-Машинку!
-А потом?
-Мишку!
-Ну а потом динозавтров?
-Да!
Я наклеил стикеры на доску. Интересно, что из этого выйдет?
-Посмотри на доску. Что мы будем убирать первым?
-Машинку!
-Хорошо. Возьми этот листочек и переклей его в среднюю колонку. Вот. Теперь давай пойдём и уберём машинку.
Я, конечно, ей помогал, но следовал строго нашей схеме. Пока она тащила из кухни свою большую машинку-самокат, я пособирал маленькие машинки в комнате.
И вот машинки все убраны на свои места.
-Зая, ты все машинки убрала на места? Посмотри, не осталось ли где-то ещё?
Она обошла комнату и внимательно посмотрела, есть ли где машинки.
-Нет.
-Хорошо. Тогда возьми эту карточку, и переклей её в колонку готово.
Лана переклеила карточку.
-А теперь давай похлопаем себе и отпразднуем эту маленькую победу!
Она с искренним удовольствием похлопала в ладоши.
-Хорошо. Что у нас следующее?
-Мишки!
Она была явно вовлечена в эту игру.
-Точно! Переклей карточку с мишкой в среднюю колонку.
Через пару минут все мягкие игрушки были сложены в коробку. Она переклеила карточку с мишками, и мы
 вместе похлопали в ладоши и порадовались.
С начала эксперимента прошло около 10 минут, а пол в комнате был полностью свободен от игрушек, и все они лежали на своих местах. Довольная собой Лана хлопала в ладоши и радовалась тому, что все карточки оказались в колонке “Готово”, а в комнате воцарился порядок. И я был бесконечно доволен своей дочкой – всё таки она у меня такая умничка!

Это была бы история успеха: я внедрил канбан среди трёхлетки. Но на самом деле всё ещё оптимистичней! На следующий день в обед она подошла ко мне и сказала: “Папа, давай сыграем в твою игру с карточкам”? И мы снова сделали
канбан, и навели порядок в комнате. А вечером того же дня мы вместе сделали расширенную версию: она сама добавила туда пару типов игрушек (конструктор и пластилин), попросила заменить мишку на коровку на карточке для мягких игрушек, и мы добавили туда же горшок, зубную щётку и книжку со сказками – и так наш канбан позволил нам плавн

о объединить уборку игрушек с ритуалом отхода ко сну.

Я не знаю, сколько продержится наша эта игра, и как быстро она надоест Лане (или мне). Но за эти два вечера я убедился в двух вещах. Во-первых, в невероятной силе agile инструментов и принципов: самоорганизации, сотрудничества, грамотной декомпозиции и визуального менеджмента. И эти инструменты на столько хороши, что даже трёхлетка способна их понять. А, во-вторых, в том, что прежде чем отбрасывать какие-то вещи как заведомо не подходящие, стоит подумать о том, как их можно адаптировать к имеющейся среде и уровню подготовки участников, проверить на практике, и лишь потом делать выводы.

Эпизод 5. Что такое Тень и как с ней бороться

Эпизод 5. Что такое Тень и как с ней бороться
Трансформаторная

 
 
00:00 / 12:07
 
1X
 

Недавно я перепостил в фейсбуке упражнение для работы с Тенью:

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

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

PS: Теперь меня можно слушать не только тут, но и на iTunes и в Google Podcast.

Музыка для заставки: Our Only Lark, любезно опубликованная Blue Dot Sessions под лицензией Creative Commons Attribution-NonCommercial License.

Эпизод 4. Лучший способ ведения войны

Эпизод 4. Лучший способ ведения войны

 
 
00:00 / 5:50
 
1X
 

Какой способ ведения войны лучший? В этом эпизоде я поделюсь тем, что на этот счёт написал Сунь Цзы – автор древнекитайского трактата “Искусство войты”, и как это относится к теме изменений.

Теперь меня можно слушать не только тут, но и на iTunes и в Google Podcast. 🙂

Музыка для заставки: Our Only Lark, любезно опубликованная Blue Dot Sessions под лицензией Creative Commons Attribution-NonCommercial License.

Удовлетворённость Agile и пятифакторная модель личности

В конце прошлого (2018) года я разместил в нескольких Facebook-группах, посвящённых Scrum и Agile (Scrum Russia, Enterprise Agile Russia, Large-Scale Scrum (LeSS): на русском, Agile вне IT / Business Agility Russia и Kanban.club (Scrum-friendly)) опросник, с помощью которого я хотел исследовать связь между характеристиками личности (Большая пятёрка) и удовлетворённостью работой в Agile команде.
Я хотел проверить гипотезу в том, что степень удовлетворения от работы в Agile будет определяться двумя характеристиками личности: высокой добропорядочностью и высокой открытостью к новому опыту. По результатам опроса оказалось (N=99), что ни одна из личностных черт не коррелирует с удовлетворённостью Agile. То есть корреляции есть, но их статистическая значимость крайне мала. Лишь одна характеристика личности коррелирует с удовлетворённостью Agile с некоторой статистической значимостью (впрочем, не достаточно высокой для того, чтобы заявить, что я нашёл “эликсир счастливой Agile-команды” ). Это добропорядочность. Однако эта корреляция не сильно выражена.  Интересно, что эта же черта, наряду с IQ, является наиболее точным предиктором общей производительности сотрудника.
Какие выводы можно сделать из полученных данных?
Во-первых, корреляция ещё не означает причинно-следственную связь. Возможно высокодобропорядочным людям работа в Agile команде позволяет выкладываться по максимуму и видеть результаты своих стараний, или добропорядочность делает agile “особенным” и это приносит удовлетворение. А возможно есть какой-то третий фактор, зависящий и от agile, и от добропорядочности. Или это просто особенность данных в моей выборке, а на самом деле эти два параметра вообще никак не коррелируют.
А во-вторых, несмотря на то, что моя гипотеза не подтвердилась, это хорошая новость. Даже с учётом того, что у меня искажённая выборка – опрос видели только те, кто состоит в группах Facebook про Agile, а это сужает круг опрашиваемых до тех, кто как-то интересуется agile. Хорошая она потому, что, судя по полученным данным, для того, чтобы быть довольным работой в Agile команде не нужны какие-то особенные характеристики личности. Это не значит, что какой-то особенный набор характеристик не будет создавать недовольство работой в Agile команде, но из имеющихся данных я не могу сделать какого-то вывод об этом. Выходит, что нет Agile и не-Agile людей. И не нужно искать сотрудников с какими-то особенными характеристиками (кроме, возможно, высокой добропорядочности, но эта черта будет полезна независимо от того, на каких принципах устроена ваша организация).
Получается, что Agile очень демократичен 🙂

Эпизод 3. Позитивная сторона негативной визуализации

Эпизод 3. Позитивная сторона негативной визуализации

 
 
00:00 / 8:15
 
1X
 

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

Музыка для заставки: Our Only Lark, любезно опубликованная Blue Dot Sessions под лицензией Creative Commons Attribution-NonCommercial License.

Эпизод 2. Одна карта чтобы изменить всё

Эпизод 2. Одна карта чтобы изменить всё
Трансформаторная

 
 
00:00 / 7:38
 
1X
 

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

Музыка для заставки: Our Only Lark, любезно опубликованная Blue Dot Sessions под лицензией Creative Commons Attribution-NonCommercial License.