2021-05-16: AgileDays - жизнь продолжается

Короткая ссылка: AgileDays-2021

Ссылки сюда (3) →

О других конференциях
Мой пост на FB
Пост в AgileRussia

Полтора месяца назад, в конце марта была пятнадцатая конференция #AgileDays. И она была для меня первая оффлайн-конференция после долгого перерыва на пандемию. Полноценная, с виски-парти. Правда, очно был всего один день, а не два - воркшопы второго дня были online. Но все равно, офлайн-конференция с живым общением - это очень хорошо, активное общение всегда было важной частью конференции, его не хватало в online-формате. Как обычно, я публиковал заметки с докладов во время конференции, а сейчас собираю их в отчет. Можно было быстрее, но я надеялся на майских посмотреть записи докладов и отчет расширить. Это не очень получилось, были другие дела. Но я посмотрел панельную дискуссию и доклад Сергея Щербинина про работу трансформаторов, о них тоже напишу.

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

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

Панельная дискуссия Agile: что с ним не так и есть ли альтернативы?

Для начала - про дискуссию "Agile: что с ним не так и есть ли альтернативы?" Я не буду ее пересказывать - там не было инсайтов, во всяком случае, для меня, я поговорю о мыслях, которые она вызвала.

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

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

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

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

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

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

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

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

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

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

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

Павел Алферов. Варианты и примеры гибридизации

Пост на FB 20 лет Agile-манифесту и 15-я конференция. Первый день - гибридный и я тут очно, второй - online. Будут Кен Бек и Джо Джастис. Анонсирована премия agileawards.ru по развитию сообщества.

Первый доклад, который я слушаю - Павел Алферов. Варианты и примеры гибридизации. В общем, история закономерная, начавшаяся с того времени, когда гибкие подходы завоевывали мир и начиная с PMBOK-4 (2008) PMI институт пытается включить гибкие методологии в классику. Тогда получилась ужасная эклектика. Но предпосылки объективны - топы, с одной стороны, хотели преимущества, которые дает Agile, а с другой стороны - сохранить привычную им культуру и способы управления. И через некоторое время этом получилось сделать у IBM, они придумали Disciplined Agile, адаптировав agile к культуре крупной корпорации и рационально объяснив, чем исходные варианты не подходят, да еще обогатив все это design thinking. Это было в начала 2010х. Наконец-то PMI до этого дошел и встроил это в PMBOK-6. А в PMBOK-7, наконец, обещают убрать ключевое утверждение что "проект это набор процессов". В общем, процесс идет, но не слишком хорошо.

Тем не менее, запрос продолжает быть актуальным. Тем более, что Agile-методы ведь принципиально перестроили внутреннее устройство IT-проекта для обеспечения своих принципов, таких как инкрементальная поставка, а далеко не для всех проектов это возможно. Павел, кстати, начал с того, что перечислил - что именно Agile явно привнес нового. Большинство как рекомендуемые практики было, но опционально. А Agile сказал - must.

• Частая поставка продукта
• Активное вовлечение заказчика.
• Минимум согласования документов. Реально. Ни один стандарт проектного управления не требует много документов, хотя практическое внедрение часто к ним сводится
• Регулярная коммуникация внутри команды. Не на усмотрение руководителя.
• Цикл улучшения и ретроспективы. After action review было много лет, но опционально - а тут жестко в конце каждого спринта
• Визуализация потока работ. Штаб проекта, war room всегда был, но не было обязательным.

А вот реальная инновация - делегирование и самоорганизация. Классическое проектное управление стоит на замковом камне "Руководитель проекта" - требуется, чтобы топы ему делегировали полномочия, а уже дальше он за все отвечает. Agile потребовал делегирования на команду.

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

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

1. Через неопределенные элементы скоупа. Через Кеневин или матрицу сессии.
2. По уровням управления
3. Через факторы сложности.
4. По этапам, переключаясь на разных этапах в разные методы
5. По инструментам

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

Антон Зотин #agileism 50 оттенков лидерства

Пост на FB Anton Zotin #agileism 50 оттенков лидерства. Очень интересная конструкция доклада. Пять историй вдохновляющих историй про современные бирюзовые и зеленые продукты, команды и организации. Завершенная историей сети випасна-медитаций, которая полностью централизованная, на донайшн, который дают только после медитации. И это - в бедной Индии, основателю говорили, что будут просто есть, или даже воровать еду другим, а он отвечал, что если они будут при этом медитировать, то ок. Идея, что продукт должен соответствовать команде. А в заключении было совсем про другое. Про то, что вы, конечно, можете подумать о том, как тянуть вашу команду на более высокие уровни. Но на самом деле, если вы посмотрите выше, то там будет Евгений который говорит "так, в скрам поигрались, где деньги?" и готов ради этого приковывать людей. Или Василий, спрашивающий "А где регламент по скраму?", или Антон с красным стилем лидерства. И все это идет в команду сверху. И, может быть, именно поэтому от скрама ничего не остается... Поэтому посмотрите вокруг, поймите какие продукты делает ваша компания, какие в нем люди и как-то приведите к единому знаменателю. Проблемы могут быть наверху- рыба гниет с головы. А если с головой замечательно, то проблемы могут быть в шее, промежуточных уровнях, где как раз находятся Евгении, Василии или Антоны.

Крис Кондрашевич из Банка Санкт-Петербург. Энтерпрайз под стрессорами: через Канбан к трансформации крупного бизнеса

Пост на FB Крис Кондрашевич из Банка Санкт-Петербург. Энтерпрайз под стрессорами: через Канбан к трансформации крупного бизнеса. Agile в банке начинался с уровня команд уже более трех лет назад, и оказался не слишком соответствующим корпоративной культуре. А в этом докладе был рассказ про следующую волну, на основе Kanban и метрик. Которая в реализации оказалась гораздо лучше соответствующей потребностям банка. Потому что метрики - это то, что в банках хорошо понимают. А Kanban включает в себя разнообразные метрики, которые показывают, как, собственно, идет процесс. И после того как получилось на основе ведения дел в jira получить систему ведения метрик, начиная с бизнес-уровня до конкретных задач, то возникло пространство коммуникации вокруг проблем, целей и действий между руководством, бизнесом и ИТ. О построении этой системе и ее конструкции и был рассказ. Она не является красиво-совершенно-идеальной, но она - работает. И один из важных эффектов - сотрудники видят, на что влияют их конкретные действия и выдвигают идеи по решению проблем, по позитивному расширению этого влияния.

Александр Горник из Mindbox. Масштабирование разработки: автономные команды с монолитом и 400к RPM

Пост на FB Александр Горник из Mindbox. "Масштабирование разработки: автономные команды с монолитом и 400к RPM." Александр рассказывал детальную историю развития Mindbox. Начиналось все с единственного продукта, потом появился второй - отдельная продуктовая команда, потом появлялись новые продуктовые команды, они росли вдвое в год, все круто. Но при этом в коде - монолит. А потом в черную пятницу, которая дает пиковую нагрузку на все продукты они легли. Тяжело и поняли, что есть проблема с надежностью. И дальше Александр рассказывал историю их движения, вовсе не однозначную и прямую, чем она и интересна.

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

Они завели специального CTO, в замысле - главный архитектор и выделили ему 30% ресурсов на исправление надежности. Ритуал надежности. Критические баги, дефекты копятся и раз в 2 месяца разбирают. И централизованное управление не взлетело. Тогда СТО придумал - а пусть команды сами рассказывают что они сделали для надежности. И вот это работало. Хотя в следующую черную пятницу они снова легли, было видно, что ситуация меняется.

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

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

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

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

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

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

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

Евгений Денисов и Елена Доркина из Дом.рф. Как взломать культуру

Пост на FB Евгений Денисов и Елена Доркина из Дом.рф "Как взломать культуру". Интересный доклад с большим количеством деталей и подробностей. Часть про анализ - понятная, на основе модели Шнайдера и Спиральной динамики разные индикативные характеристики, которые позволяют понять культуру. Хорошо, теперь мы знаем текущую культуру. А теперь мы хотим перейти к Agile.

Как ее менять? И тут возникает интересный метод culture hacking - приемы, которые позволяют принести небольшие изменения в желаемом направлении, достаточно безопасны, не вызывают резкого отторжения, а при успехе дают позитивный эмоциональный отклик. Как примеры было широкое соучастие в создании agile cookbook. Или проведение встреч по изменениям не в формате зажигательной речи первого лица или отчета ему, а в формате рассказа команд о ее продвижении. При этом, если культура отчетности была развита, то формат должен препятствовать, чтобы это свалилось к привычным отчетам. Чеклисты здоровья команды - но у них исключительно в варианте самооценки, и без внешних целей. Встречи по вечерам в online-формате, когда отделы рассказывают другим отделам, что происходит. И так далее. Вариантов много. Главное, что ты должен понимать, какое изменение ты хочешь принести конкретной практикой, и совместима ли она с конкретной культурой. Поэтому я жду презентации, в которой был набор разных практик, уместных для разных уровнях Спиральной динамики.

Петр Александров, Спортмастер. Управление сроками для продуктовых команд

Пост на FB Петр Александров, Спортмастер. Управление сроками для продуктовых команд.

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

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

Есть три способа визуализации для массовых транспортных сервисов.

1. Визуализация расписания. Электрички и автобусы по нему следуют, клиенты подстраиваются. Заказчик, когда приходит за сроками хочет получить расписание. И дальше получить результат к указанному сроку.
2. Сервисная модель, Яндекс-такси. Никакого расписания нет, заказал услугу - и видишь, как она исполняется. Все хорошо, но только когда хватает мощности, свободный таксист всегда есть. С ИТ-разработкой ситуация явно не такая, мощностей явно недостаточно, но перевозки должны удовлетворять бизнес.
3. Модель общественного транспорта - Яндекс-транспорт, сейчас уже в картах. Автобусы едут сами по себе, как могут с учетом дорожной обстановки и пробок, пассажиры это видят и могут ориентироваться. И еще простенький прогноз - когда какой автобус придет к тебе на остановку и как он будет идти.

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

Что у них получилось?

• 4 типа задач: бизнесовые, технические, эксплуатация, устранение дефектов
• Стандартные реперы жизненного цикла
  • Когда команда начала думать про задачу
  • Когда команда поняла, как задачу делать. DoR. Можно делать.
  • Когда команда начала работать. Точка принятия обязательств. До этого обязательств нет.
  • Конвейер команды
  • Пронос релиза на продуктив.
• Метрики - портал метрик, которые как раз показывают движение задач по этому жизненному циклу.
• Профили команд - набор leadtime и долей мощности для задач разного типа. Профиль дает представление о том, как работает команда и когда можно ожидать результатов, с учетом текущего списка задач.

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

Анна Обухова. Как помочь людям меняться

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

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

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

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

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

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

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

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

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

За привычное поведение ответственны другие центры.

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

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

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

Например, если вместо абстрактных слов "у нас опасная ситуация" возникают более конкретные слова "у нас опасность опоздать с поставкой", которые содержат отсылку к ранее известной из опыта или описанной в книгах ситуации, то идет перенос оценки опасности с глубинного уровня работы с неведомым на уровень префронтальной коры. Это называется labeling. При этом важно действительно поставить понятную метку из 1-3 слов, которую глубинный уровень опознает как "нечто понятное", а не "какая-то муть, опасно", и действительно передаст префронтальной коре управление. Аналогично, планируемые действия тоже должны быть понятны и реалистичны, пункт "так, всем успокоиться" реалистичным не является, а вот пункт "подумаем, что случится если релиз выйдет позже", наоборот, реалистичен. Пункт "подождем, что скажут стейкхолдеры", при всей неопределенности, тоже реалистичен, особенно если там предложены ожидаемые варианты. И так далее.

Определенность карты для энториальной коры - различные DoR, DoD, Sprint pulse и им подобные. Безопасная среда и хорошее командное взаимодействие. Разбор прошлого и авторизация отрицательного результата - извлечение опыта из провалов превращает его из негативного поражения в приобретение ценного опыта. Авторизация положительного результата. Проговаривание имеющегося позитивного опыта, чтобы команда вспомнила, что с аналогичными ситуациями и вызовами она уже справлялась.

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

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

Но это - средняя команда. А бывает уставшая команда, которая делает только совершенно типовые задачи, и которой при сложных нужна поддержка и контроль, и которую надо восстанавливать. Регламенты и процедуры как раз обеспечивают такую поддержку за счет снятия неопределенности. И тут важно соответствия уровня регламентов, контроля и энергетике команды. Или наоборот, огонь-команда, которая работает над сложными задачами в условиях высокой неопределенности. Заметим, что если такую команду поставить на рутинный поток задач, то у нее очень быстро наступит выгорание скуки и она растеряет свою энергию или разбежится, то есть заранее накапливать 10% уровня энергии под будущие изменения - нельзя. Таким образом, у вас как раз конкретная ситуация.

И важно, работать именно с ней, в том числе - презентуя изменения и сохраняя в ней уровень амбициозности, неопределенности и вызовов адекватным текущему состоянию команды. Команде с низкой энергией бесполезно говорить о 5-летних целях, она работает в горизонте текучки 1-2 дней, а через пять лет для нее - это почти в загробном мире. Да и для средней команды большие горизонты и реально амбициозные цели часто являются нереалистичными, поэтому надо держать два горизонта - большую вдохновляющую цель и первый, обозримый шаг в ее направлении с понятным изменением. И так далее. А чтобы это делать, лидер, драйвер изменений должен обладать личной энергией, для которого амбициозная цель достижима, обычно его энергия должна быть на 10-15% больше, чем энергия команды. И поэтому выгоревший лидер в принципе не может проводить изменения в команде, ему восстанавливаться надо.

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

Протоколы авторизации результата - простые, о них я подробно писал в конспекте доклада Анны на AgileDays-2019 "Саботаж — понять и не простить" https://mtsepkov.org/AgileDays-2019.

Сергей Щербинин. Терапия для трансформаторов: как принять неизбежное и ловить кайф от изменений

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

В конце доклада был чеклист трансформатора, он подводил итоги, а я с него начну.

• Понять цель. Нафига им. Что это - не просто потому, что на конфу сгоняли.
• Вы - не один? Есть сторонники? Кроме CEO надо минимум несколько человек, желательно из разных углов компании.
• Как будут мерить успех те, кто нанимают. Это надо понять на входе.
• Возможность ошибаться. Ошибки точно будут, и у вас и у других людей в компании, и если культура компании их запрещает, то это безнадежно. Ну или надо работать над изменением этой культуры, непрестанно говоря про эксперименты.
• Должны быть хоть какие-то ресурсы, чтобы меняться. Потмоу что часто ты один с помощником и мало денег, а в компании - тысячи

Если плюсы в большинстве - можно начачинать.

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

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

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

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

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

В обоих случаях успеха - не будет, а трансформатор - разочаровывается и уходит. Быть может, выгорев. Правильный подход - делать команду, а для этого должно быть минимум 2-3 сторонника, желательно из разных углов компании с разным взглядом - смотри чеклист.

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

В целом все справедливо. А я в заключении тут я хочу вспомнить доклад о трансформации Альфы, который Алексей Марей и Сергей Дмитриев делали на первой Agile Business Conference в 2016. Он был посвящен трансформации Альфа-банка, и там был достаточно конкретный метод: собирается команда топов для поддержки трансформации, а потом выбирают конкретный сегмент бизнеса и в нем Agile-коучи запускают одну команду за другой снизу. Эти команды встречаются с сопротивлением менеджеров среднего уровня, работа с которым и является основной задачей команды топов. Подробности - в моем отчете, там же есть ссылки на видео и презентацию. Я не хочу сказать, что он универсален, в разных корпорациях - разная ситуация. И команду поддержки из топов еще надо собрать, для чего разморозить ситуацию. Но тот рассказ был достаточно конкретен, чтобы его стоило посмотреть.

На этом я завершаю свой отчет.

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

— Максим Цепков • 07:36, 16 мая 2021 • нет комментариев