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

Часто у начинающих Скрам-мастеров и 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:

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

Источник - блог Сергея Макаркина

Последние статьи в блоге

В Учебном центре IBS планируется запуск курсов по продуктам TData

Читайте о стратегическом соглашении TData и IBS и наших новых курсах

11 июня 2025

Компетенции бизнес-аналитиков: Junior и Middle в сравнении

В условиях динамично развивающейся ИТ-индустрии важно чётко понимать, какие навыки и знания необходимы для успешной работы на каждом этапе карьерного пути. Сегодня обсудим разницу в компетенциях ИТ бизнес-аналитиков уровней Junior и Middle. Если вы только начинаете свой путь в ИТ бизнес-анализе или, наоборот, уже обладаете некоторым опытом, этот материал поможет вам понять, какие навыки необходимы на каждом уровне и как развиваться дальше.

Новости
05 июня 2025

Лимит на сбои. Как понять, что система перегружена, а не просто плохо сделана?

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

Новости
03 июня 2025

Кто такой аналитик 1С?

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

Новости
28 мая 2025

Разбор задачи: UML-диаграмма классов для системы регистрации на курсы

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

22 мая 2025

Бизнес-аналитик и системный аналитик в ИТ: кто есть кто и в чем разница

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

21 мая 2025

5 распространенных ошибок в работе системных аналитиков

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

20 мая 2025

Итоги работы Центра сертификации IBS

Центр сертификации IBS начал свою работу в апреле 2023 года, поэтому мы традиционно подводим итоги работы в апреле-мае. Прошедший год стал для нас периодом важных изменений. В 2024 году произошло несколько знаковых событий: наша команда обновила программы сертификации системных аналитиков и Java-разработчиков, подготовила к запуску сертификацию бизнес-аналитиков, получила аккредитацию от АПКИТ и стала обладателем Гран-при премии «Смарт пирамида». Рассказываем подробнее, каких результатов мы достигли в уходящем году и как это отразилось на нашей работе.

Новости
19 мая 2025

Какой метод тестирования выбрать: черный, белый или серый ящики?

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

14 мая 2025

Удостоверение, диплом и сертификат: в чем разница и что выбрать

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

12 мая 2025

Выгодный май — на курсы залетай!

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

05 мая 2025

Кейс: кастомизация курса по Jira

Кейс по проведению кастомизированного курса «Основы Jira» для крупной российской компании, занимающейся производством цифровой техники.

05 мая 2025

Зачем специалистам по 1С изучать системный анализ и архитектуру ПО

Как системный анализ и архитектура ПО помогают эффективнее работать в 1С.

29 апреля 2025

Банка Nutella, IT, ESG — что общего?

Когда вы читали этикетку на продукте не из-за состава, а из-за ESG-маркировки?

25 апреля 2025

Каковы плюсы и минусы монолитной и микросервисной архитектуры при разработке ИТ-продуктов?

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

25 апреля 2025

Станьте архитектором ПО с выгодой! Только в апреле сэкономьте 20 000 ₽ и получите новый модуль по микросервисам в подарок

24 апреля стартует обучение на комплексной программе «Архитектор ПО. Путь к мастерству в проектировании систем»*.

14 апреля 2025

Архитектурные ошибки в корпоративных системах, которые могут создать проблемы в долгосрочной перспективе

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

Новости
10 апреля 2025

Кейс: Интенсив по управлению проектами для промышленной компании

Мы адаптировали курс по управлению проектами под запрос команды крупной промышленной компании и провели обучение. Вот что из этого вышло.

27 марта 2025

Кейс: Обучение сотрудников крупной компании работе с ClickHouse

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

19 марта 2025

Платформа сертификации IBS получила аккредитацию АПКИТ

Ассоциация предприятий компьютерных и информационных технологий (АПКИТ) приняла новый регламент сертификации ИТ-специалистов.

Новости
10 марта 2025

Не нашли, что искали? — Просто напишите, и мы поможем

Корпоративное обучение Оценка персонала Сертификация О нас Стань тренером Блог
Пользователь только что записался на курс ""
Спасибо!
Форма отправлена успешно.