Category: Статьи

Фреймворк 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:

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

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

В этой статье я хочу поделиться своей маленькой историей успеха, которая, надеюсь, будет полезна для кого-то из моих читателей.
Помимо того, что я 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.

Удовлетворённость 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.

Три урока управления организацией от боевого офицера

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

Источники силы

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

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

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

Выводы для менеджера: 

Я лично знал несколько руководителей, чья власть опиралась только на формальный страх – депремирование, штрафы, увольнение и прочее. И иногда это работает. К счастью, мы не на войне, но и “на гражданке” страх ненадёжная опора для руководителя. Хорошие специалисты от такого руководителя уйдут при первой же возможности. Остановить их можно будет только предложив достаточно большую зарплату, намного выше средней, да и это не всегда сработает. Плохие останутся – потому что плохому специалисту податься некуда. Молодёжь какое-то время может поработать у такого босса – но ровно пока не наберётся достаточно опыта, чтобы уйти. Получается, что такой руководитель за своих сотрудников переплачивает, а сохраняет при этом только самые худшие кадры. Так что проигрывает и сам руководитель, и его сотрудники, и организация. А если ты профессионал, и обладаешь харизмой – люди будут с тобой потому, что они у тебя учатся, потому что чувствуют себя надёжно, уверенны, что такой руководитель и подскажет, и поддержит, и поможет. Такой руководитель собирает сильную команду, и вместе с ним растёт каждый член команды, так что все оказываются в выигрыше.

Решения “сверху”

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

Сейчас основная точка принятия решений в армии – командир батальона. Но план операций всё равно составляют наверху, и составляют очень подробно. Сидят они высоко, да далеко. Смотрят на карту, проведут по ней курвиметром – от блокпоста до точка “А” 5 километров. Средняя скорость 4 километра в час, ну накинем на пересечённую местность, да ещё на какой-нибудь непредвиденный риск… Два часа на всё про всё. И получает рота боевой приказ: в 12:00 выдвинуться с блок-поста и занять высоту N к 14:00. Время. Собрались. Пошли. Прошли 4 километра, подошли к горе. На карте-то остаётся километр. А в жизни это километр вперёд и ещё 900 метров вверх. Тут не полчаса, а сутки надо на подъём. Да и двигаться на виду у противника. Лезть напролом – верная смерть. А выжидать – времени нет. Можно, конечно, обойти. Но обход – дело долгое, и опасное. Там по плану будет артподготовка через 10 минут.  И в таких условиях командиру на месте надо решать. И он взвешивает риски. Иногда можно сообщить, что задачу выполнить в заданное время невозможно. Но за такое никто по голове не погладит. Могу и крайним сделать, обвинив в срыве операции. Вот и выбор: будешь действовать по плану – точно не справишься, пойдёшь в обход – попадёшь под свои же миномёты, но есть шанс, а будешь бездействовать – можешь всю операцию сорвать. И иногда идёшь на риск – выбираешь из двух зол меньшее. Под собственный артобстрел я трижды так попадал, а уж сколько по нашим же минным полям ходили потому, что напрямую не пройдёшь – не счесть. А всё потому, что там в штабе тебя слушать никто не хочет: есть приказ – иди, и как хочешь, но исполняй.

Выводы для менеджера:

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

У победы сто отцов

Есть такое выражение: “у победы сто отцов, а поражение – сирота”. Когда операция удаётся, все спешат отчитаться о том, какие они молодцы. А если что-то пошло не так, каждый стремится показать, что уж он-то всё сделал правильно, а в том, что произошла беда, виноваты другие. Когда начальство ищет крайнего, это – логичное решение. Но толковый командир при таком раскладе после успешной операции проводит разбор, а после неудачной – два. Один – для отчёта наверх, второй – для себя и своих людей. Чтобы понять, где были допущены ошибки, и как их не повторить. Потому что даже если наверху требуют, чтобы ошибок не было, в жизни ошибки неизбежны. А на войне ошибка часто стоит жизни. Поэтому из каждой ошибки надо извлечь урок. Чтобы это сделать, нужно послушать всех участников – каждый участник боя видит всё по-своему, со своей колокольни. А полную картину можно получить только если послушать всех. И здесь важно доверие подчинённых. Чтобы они не боялись сказать командиру, что тот не прав, или ошибся. Такое доверие надо заслужить. Спрашивать, слушать, и достойно принимать критику. Стоит один раз показать, что ты не хочешь слышать критики – и такого доверия как и не было вовсе.

Вывод для менеджера:

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

Как я сдавал PSM-III

Недавно в обдом из обсуждений на Facebook несколько человек попросили поделиться опытом сдачи экзамена Professional Scrum Master III on scrum.org. Экзамен этот сложный (о чём недвусмысленно свидетельствует сравнение числа обладателей PMS-I, II и III: 153 702, 1 734 и 550 сооветственно). Я недавно его успешно сдал (дважды, 89% и 90,6% при проходном балле 85%), и я подумал, что будет интересно описать мой опыт в статье, чтобы, так сказать, за один раз поделиться со всеми интересующимися. (Как я вообще решился сдавать этот экзамен , и почему я сдавал его дважды— тема отдельной статьи. Которую я, может быть, когда-то тоже напишу). На scrum.org есть статья о подготовке к PSM-III, и я надеюсь и мой опус окажется полезен кому-то 🙂

Подготовка

Сдавал я не сразу PSM-III — сначала я сдал PSM-I и PSM-II. Я думаю, что это, хоть и наиболее затратный, но оптимальный подход. Я мог постепенно подготовить себя к возрастающей сложности вопросов, углубить и систематизировать свои познания, да и просто привыкнуть к самому процессу экзамена.

Готовясь к каждому из PSM-экзаменов я перечитывал Руководство по Скраму (также известное как Scrum Guide). Много раз. Здесь важно, во-первых, читать именно последню версию — экзамен отражает все изменения в Руководстве по Скраму на текущий момент. Во-вторых, важно то, как его читать. Я последовал совету Славы Москаленко: в первом чтении фокусироваться на общем понимании, во втором — на ключевых элементах, а в тертьем — задаться вопросом, почему каждый элемент описан именно так. Так я читал его перед первым и вторым PSM, но и перед третьим прочитал 2 раза, ища взаимосвязи между частями Скрама. Важно не выучить Руководство наизусть — это просто, важно понять, как оно описывает Скарм, и почему выбран именно такой а не какой-то иной способ изложения.

Перед третьим PSM лучше читать Scrum guide на английском. Сам экзамен сдаётся на этом языке, и всем нам — тем, для кого английский не родной язык — дополнительную сложность представляет именно языковой барьер (как минимум один ответ у меня был засчитан как неправильный потому, что я неверно подобрал слова, и лингвистические тонкости оказались весьма существенными).

На scrum.org есть список рекомендуемой литературы. Из рекомендуемой литературы я читал Ленциони 5 пороков команды, скрам покет гайд (его я читал прямо перед сдачей — не скажу, что там было что-то новое, но думаю, это тоже сыграло роль в систематизации знаний).

Я нашёл в интернете список вопросов PSM-3. Как оказалось, там не было ни одного вопроса, которые попадались мне, и, подозреваю, что этот список имеет очень отдалённое отношение к экзамену.Нно пройтись по этим вопросам и продумать ответ (как бы я ответил, и, главное, почему я бы ответил именно так) было полезно.

Суперполезным был тернинг PSM (я его проходил дважды, один раз у Славы Москаленко, второй у Саймона Рэндла) — некоторые из тем, рассматриваемых на тренинге, были довольно близки в нескольким вопросам.

В день экзамена

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

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

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

Медитируйте. Серьёъно. Я это делаю перед каждым событем, из-за которого я волнуюсь — и это реально помогает (не верите моему опыту — обратитьесь кобширным исследованиям на эту тему). Мне помогает конфентрация на дыхании в течении 5–20 минут.

Приготовьте воды. Это сложный момент: с одной стороны, мучимые жаждой вы не сможете эффективно думать, с другой — слишком много воды приведут к потере драгоценного времени (см. пункт про туалет).

Приготовьте блокнот и ручку. В PSM 3 нет возможности отмечать вопросы, к которым вы хотите вернуться. Запишите номера этих вопросов на бумаге, чтобы проще было потом их пересмотреть (если останется время).

Не торопитесь. Но следите за временем. Из 34 вопросов, примерно, 30 — открытые (т.е. вопрос и TextBox — пиши что хочешь). Вам надо ответить максимально кратко и точно. Я прикидывал тайминг на каждые 5 вопросов, и старался оставаться в рамках того тайминга. Лучше в лёшкой спешке ответиь на все вопросы, чем в полной спешке пропустить все вопросы.

Следите за количеством вопросов в вопросе (обычно оно равно числу вопросительных знаков 🙂 Но это не точно). Убедитесь, что в ответе вы ответили на все.

Проверье, что в ответе вы учли ключевые элементы: эмпиризм, правила Скрама, роли, артефакты, события. В ответах про работу с командой помните, что Скрам-мастер — лидер-слуга (servant leader).

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

Коллеги из scrum.org рекомендовали отвечать в два захода. Сначала максимально быстро и кратко ответить на все вопросы, а потом (если останется время), вернуться, пересмотреть вопросы, и добавить деталей и красок там, где это необходимо.

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

После экзамена

Наберитесь терпения. Сразу после завершения экзамена вы получите результат failed — вопросов в выбором недостаточно для того, чтобы пройти. Но это ещё не окончателный результат — окончательный бвы получите через некоторое время, после того, как кто-то из scrum.org проверить ваши написанные вручную ответы. Обычно это занимает от 1 до 2 недель.

Почему модели управления из MBA не работают на практике? (globalcio.ru)

Эта статья — продолжение размышлений о проблемах управленческого образования, навеянных статьёй Екатерины Ляско на портале globalcio.ru «Мираж. Управление. MBA». В первой части я поделился своими рассуждениями о том, почему одного лишь бизнес-образования недостаточно для становления менеджера. Dj второй части статьи я хочу обсудить с вами вопрос о том, почему методы и модели управления, изучаемые в рамках современной бизнес-школы, в частности, внедрение изменений, отторгаются организациями, и что с этим делать.

Мой ответ на первый вопрос читайте в статье “Почему модели управления из MBA не работают на практике?

Картинка скопирована отсюда

MVP умер. Да здравствует RAT!

Рик Хайхэм (Rick Higham) опубликовал прекрасную статью о том, что не так с идеей MVP, и почему её нужно заменить на RAT. Я полностью согласен с автором, и не мог не сделать перевод, который предлагаю вашему вниманию. Continue reading…

Теория ограничений и преподавание танцев

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

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

Грозовая туча – это графическая диаграмма, состоящая из 5 блоков: A, B, C, D, D’, обычно располагаемых вот так:

   [B] ← [D ]                      [A]
  /       ↑                       /   \
[A]    конфликт       ИЛИ       [B]   [C]
  \       ↓                      ↑     ↑
   [C] ← [D’]                   [D] ↔ [D’]

Блоки представляют противопоставляемые желания, составляющие конфликт (D, D’), потребности (необходимые условия), которые каждая сторона пытается удовлетворить (B, C), и общая цель или задача (A), которую обе стороны пытаются достичь. Стрелки между блоками представляют причинно-следственные связи (читаются “для того чтобы”, “потому, что”, “так, что”).

Использование грозовой тучи состоит из 7 шагов1:

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

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

Блок Наводящий вопрос
D Что хочет делать другая сторона? / Что я вынужден делать под давлением другой стороны?
D′ Что я хочу делать?
C Какую потребность я удовлетворяю засчёт действия D′?
B Какую потребность удовлетворяет другая сторона засчёт действия (или вынуждая меня действовать) D?
A Какая общая цель будет достигнута за счёт удовлетворения потребностей B и C?

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

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

Теперь надо понять, для чего мы этого хотим, и к какой цели мы стремимся. Тут всё довольно просто:

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

Мы изобразили это в виде диаграммы конфликта:

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

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

Теперь нижняя часть тучи:

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

Ну и главное допущение – то, что лежит в основе противоречия:

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

В итоге наша “туча” обросла дополнительными облаками:

И в этот момент я понял то, что теперь выглядело очевидным – но каким-то непостижимым образом ускользало от моего внимания! А с чего я решил, что нельзя делать занятия лёгкими и весёлыми, давать много поддержек и при этом делать упор на базовую технику и многократное повторение?! Можно, и я точно знаю как!

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