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

Подписывайтесь на наш канал в Telegram:
больше материалов экспертов, анонсы бесплатных вебинаров и задачки для IT-специалистов

Подписаться

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

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

Subjective – Objective – Assessment – 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:

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