2021-02-07: LeadManage IT 2020 - публикую отчет

Короткая ссылка: LeadManageIT-2020

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

О других конференциях

Facebook напомнил, что год назад в этот день я был в Минске на Lead/Manage IT Тогда еще нельзя было предполагать дальнейшую траекторию прошедшего года - эпидемию, политические события в Беларуси и во всем мире... Но эпидемия пойдет на спад, а политика пойдет в конструктивном русле. И конференция еще повторится, во всяком случае в этом году будет online, как я увидел на сайте. В прошлом году было много общения и интересных докладов. Я с удивлением обнаружил, что я не опубликовал по итогам конференции отчет, остались только отдельные посты в FB. Исправляюсь.

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

Я выступал с докладом Роли в проекте: как поделить поляну ответственности?. Это - очередная пересборка моего доклада на эту тему.

А теперь - заключительная фотка конференции и заметки с докладов.

Оригинал на FB

Егор Яворский. Проект с заказчиками и командами из других культур

Пост FB Первый доклад - Егор Яворский. Проект с заказчиками и командами из других культур. На основе Erin Meyer The Culture Map - она фундаментальная, но простая. Есть источники еще проще - но там за счет простоты хромает теория. Теория реально интересная, разложение по ряду прикладных дихотомий.

Коммуникации - объем контекста:

• низкоконтекстные - выдают все детали, не думают, что догадаешься
• высококонтекстные - подразумевается, что ты знаешь все вокруг, поэтому детали не выдаются

Что делать в низкоконтекстных

• говорить прозрачно, уточнять все ли понятно
• не пытаться считывать, уточнять - потому что ошибешься

В высококонтекстных

• слушать и слышать
• просить больше деталей
• не судить раньше времени

Аргументация.

• сначала теория
• сначала про ситуацию

Кейс - наладка Scrum в российской команде. Сначала - про теорию.

• США - сплошная практика.

советы:

• если людям важна теория - ее надо будет объяснять, иначе практические страны не воспримут.
• если практика - то много кейсов и советов, и нафиг теорию

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

Разногласия:

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

Доверие:

• task-based, на выполненных задачах. Дружелюбие - не дружба, дружбу надо устанавливать делом
• relationship-based, налаживание отношений. Сначала едим или пьем водку, до этого работы не будет. Арабские страны, Китай

Фидбэк

• одна ось: прямой негативный против косвенного
• вторая: детальный контекст против обобщенного содержания

Варианты

• явный фидбек и много деталей - Голландия.
• США, Британия - там смягчают, но с деталями.
• прямой негативный без деталей - уточняйте - Россия, Испания, Италия, эмоции пропускаем
• косвенный и без деталей - там очень тяжело. Япония, Индия, Бразилия

Стиль руководства. Братский против иерархического.

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

Принятие решений

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

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

Отношение к времени

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

Применение. Помните, что своя культура не ощущается. Позиционируйтесь относительно себя в дихотомиях - и учитывайте в работе. Хорошо, когда ваша компания однородна по культуре. Если разнородна - то надо договариваться. При споре деремся в openspace или уходим отдельно?

В докладе было распределение стран по культурам. Что интересно, США и Британия по некоторым дихотомиям были на противоположных концах. А из зала были замечания, что по Штатам многое зависит от конкретного штата и конкретной индустрии - там разнообразие.

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

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

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

Роман Сорока и Александр Стецура. Как выжить в роли тимлида

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

• представиться. собрать всех в команде и рассказать о себе и своих планах в команде.
• встретиться один на один, надо анонсировать на общей встрече и встретиться.
• А дальше делать команду. Модель Такмана.

Часто фокусируются на чем-то глобальном, но ключевая вещь - регулярные встречи общие и один на один, собираться и давать обратную связь.

• Обучение и менторство. Тайм менеджмент. Культура ответа на письма. Вкладывайтесь в людей, это окупится.
• Установить ев команде, как делится знаниями. Сделать культуру.
• Звезданутость - это нормально. Но надо уметь с ними работать. И ситуация должна быть прозрачной, звезды и привилегии у членов команды должны быть обоснованы.

Только перешли к performing - приходит новый член команды и все изменяется.

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

• В большой организации нет друзей, есть коллеги. Друг может превратиться в соперника, вы делите один пирог
• Все обсуждают друг друга, в том числе - начальнику расскажут про вас за спиной.
• Подставлять никто не будет, но воспользоваться - обязательно. Обо всех промахах расскажут.
• Никто никому не верят, надо проходить через бумаги. Но репутация - ускоряет
• Построение зависимости. Успех - от вашего. Разбираешься в технологии - ликвидируй конкурентов.
• Со всеми дружелюбной.

Отделы делятся на дружеские и вражеские. Надо учитывать. Серебряная пуля - правильные ответы.

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

Цель выживания - внедрять нужные заказчику фичи и получать за это плюшки. И чтобы никто не мешал.

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

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

Но вообще, от себя отмечу, что Александр изнутри и четко описывает тот бессмысленный корпоративный мир, который очень ярко критикует Логан в "Лидер и племя".

А еще, уже из обсуждения в кофе-брейки. попробовали приземлить "хорошие зарплаты" на цифры, и почему-то кажется, что 300-400тр в месяц в таких корпорациях нет, а на 200-250тр можно найти гораздо более комфортные условия.

В кулуарах мы уточнили про зарплаты, Александр сказал, что я хорошо угадал про деньги, платит Сбер 300-400 и даже больше бывает. Тимлидам...

Yuliya Kurapatsenkava из Spotify. Как измерять неизмеримое: метрики продуктивности

Пост в FB. Доклад очень интересный, но по нему весьма сложно написать отзыв. Потому что на самом деле доклад не про конкретные метрики, а про культуру, которая лежит в основе и неявно предполагается. Именно неявно, но без нее доклад не имеет особого смысла. У культуры несколько составляющих.

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

А еще в докладе постоянно звучит тема использования и интерпретации метрик, и она - нетривиальна. Например, составная часть реакции на pull request время, когда он пройдет review. Фишка в том, что если оно велико, то разработчики начинают устанавливать горизонтальные связи с ревьюерами, это проходит внесистемно и является лишними накладными расходами.

Еще интересная метрика - новые фичи против совершенствования. И в ее анализе несколько нетривиальных составляющих.

(а) Если все время уходит на поддержку, а не новые фичи, то, может быть, пора рефакторить систему, чтобы ее оздоровить.

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

Софтовые метрики

• engagement - как готовы выйти за регламенты, чтобы достигнуть цели
• feedback
• отношения с командой и коллегами. Измерение связей между людьми
• персональный рост. initial - деньги, потом ветвление: интересные проекты или персональный рост.
• признание - близко с персональным ростом. вербальная или письменная обратная связь, да короткая на несколько дней
• Стресс. Пришла в индустрию недавно. Где стрессовые штуки.
• eNPS - позвали ли бы вы своего друга работать в нашу компанию да/нет. Если падает - то что-то испорчено, и надо принимать меры.

ВСЕ эти метрики мониторятся по опросам в еженедельном(!) режиме. Это как раз культура постоянного мониторинга.

Метрики компании

• T-shapeness
• время для onboading -- меряется просто по 10му коммиту в репозиторий.
• сложность домена -- от него зависит онбординг. Поэтому онборжинг надо мерить в разрезе сложности.
• коммиты в совместные репозитории -- риск падения увеличивается с числом разных инженеров, вносящих вклад.
• SLO/SLA - насколько часто продукт падает, когда вышел на маркет

Отмечу при этом, что поскольку культура работы с метриками - такая же, как в метриках public web по своему продукту, то все механизмы статистики там работают.

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

Timur Batyrshin. При еженедельных опросах способность адекватной оценки у людей не забивается?

Максим Цепков. Ну, вопрос в том, что такое "адекватная оценка". В целом, думаю, не забивается, особенно если опрос простой. Тут же главная цель - зафиксировать момент резких изменений в оценке человеком, увидеть, что "что-то изменилось" - а потом начать разбираться. Кстати, для меня тут характерный пример опроса по счастью, о котором рассказывала Виктория Юркевич на Highload-2018. Они вообще вместе с фиксацией времени на задачу отмечают смайлик уровня счастья "здесь и сейчас". И, оказывается, динамика получается вполне говорящая.

Timur Batyrshin. У нас был сервис, который раз в неделю спрашивал "Как настроение? Помогает ли вам ваш менеджер? Насколько хороший у вас work-life balance?" по десятибальной шкале. Через несколько месяцев использования даже если что-то не так, рука тянулась поставить оценку не сильно отличающуюся от предыдущей — "ну это же вот только вчера так было, а в целом все хорошо". Возможно это только у меня так. Или если собирать обратную связь еще чаще, как предложила Виктория, она станет точнее. Или десятибальная шкала сбивает и если ее заменить на "плохо-хорошо-супер" начнет работать.

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

Андрей Солощак. Игорь Беспальчук, если задаешься таким вопросом, то значит тебе это не нужно. Тут проблема причины и следствия. Такие метрики не вводятся просто, чтобы улучшить какие-то текущие показатели. Это результат работы над развитием гуманистической культуры компании и эти метрики носят естественный для данной культуры характер. Если же нет стартовой культуры, то и метрики ничего не дадут. Что за культура? Неплохо описано в книге Basecamp “It doesn’t have to be crazy at work”.

Игорь Беспальчук. Андрей Солощак Если я езжу на лошади, это не значит, что мне не может быть интересно, как устроен ДВС.

Андрей Солощак. Игорь Беспальчук ну ты же не спрашиваешь какие подковы при этом используются 🙂

Игорь Беспальчук. Андрей Солощак Да, спрашиваю про КПД и расход масла.

Андрей Солощак. Игорь Беспальчук сравнение с двигателем не очень удачное. Если вспомнить Киневин, то двигатель это complicated domain, а организация это complex domain. Для двигателя невозможно объяснить, почему для сохранения высокого КПД на много лет нужно постоянно экспериментировать с процессом техобслуживания.

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

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

Андрей Солощак. Игорь Беспальчук наверное всё-таки я был немного не прав, потому что упустил некоторые моменты в описании. Там действительно есть неочевидные вещи. И в этом случае твой вопрос абсолютно релевантен.

Максим Цепков. Игорь, думаю, можно написать Юлии, но по ощущениям от доклада в процессе - это немного, это встроено в общую систему, примерно как регулярная фиксация времени на задачи. То есть ты периодически быстро заполняешь опросы. А дальше ситуация тоже как с фиксацией времени - аналитика и обратная связь встроена в общие процессы работы компании, у тебя еще один источник данных. То есть тут как с системой мониторинга производительности приложения: вопрос сколько она стоит - некорректен. Явно видна стоимость повседневной поддержки (вписывания в новый код) и стоимость наблюдения. Еще есть стоимость начального создания, но она отчасти размазана во времени. А дальше есть стоимость устранения проблем и совершенствования, которая может работать как без мониторинга (по фейлам и падениям), так и с мониторингом (в светофорной модели показателей), и для которой мониторинг дает сильно много дополнительной информации.

Игорь Беспальчук. Максим Цепков И тем не менее система мониторинга приложения тоже не бесплатная, и в части начального создания, и в части сопровождения, и выделить эти прямые затраты вроде несложно. Я же не спрашиваю, окупается ли она, это действительно сложнее понять. Для примера - помню доклад Авито, начальная стоимость системы мониторинга их приложений - примерно 1 ч*год хорошего специалиста по инфраструктуре. И кстати, вписывание в код как раз фиг выделишь, но это уже использование системы. А вот ее собственное сопровождение и развитие - также легко выделяется.

Mikhail Fedorenko. Такое тотальное измерение и фокус на метрики окупается? Измерения - это все же накладные расходы, трансакционные издержки в понятии институционалистов. Понятно, что без измерений сложно оценить степень достижения целей, своевременно понять, что что-то идёт не так, и пора меняться. Но затраты на измерения следует балансировать.

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

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

Роман Кононов из Uber. Как сочетать подход OKR в высокоуровневом стратегическом планировании и Scrum - в тактическом

Пост в FB В докладе был хороший рассказ про OKR с раскрытием фреймворка. Из интересного для меня: только 30% целей идет сверху, 60% наоборот поднимается снизу, и 10% - от соседей. Остальное я знал - полная прозрачность, амбициозность целей, отвязка от денег. И несколько раз подчеркивалось, что цели не должны превратиться в task list.

Дальше сопряжение со Scrum, в целом понятное: берем квартальные цели, делаем фокусировку. Но вот дальше происходит магия, с помощью которой эти цели превращаются в backlog с тасками, и она не раскрыта. Но потом тоже ясно - таски связаны с целями, дают в них вклад, и Product Owner отвечает за фокусировку. Uber использует OKR года четыре для выравнивания по всей компании.

Про Scrum подробного рассказа не было, о нем и так все знают. Важно, что ответственность за процесс у них на уровне команды, и вариативность большая. В одних - классический Scrum, в других очень разные вариации, вплоть до отсутствия скрам мастеров. Везде есть Product Owner, 2 или 4-недельные спринты с поставкой ценности и feature team. Но поверх команд построена сложная структура, на слайдах была схема, которую надо внимательно смотреть. Но она. опять-таки не общая, он рисовал из своего подразделения, а голосом говорил про различные вариации.

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

В комментариях к посту был вопрос от Yuri Veretelnikov: Я вот только одно не понимаю: вас не смущает, что эта полная "отвязка от бизнеса" как-то курьезно перекликается с финансовыми результатами Uber? Нет, я понимаю, плановая убыточность, и т.п., но по каким вообще метрикам тогда оценивать оптимальность, эффективность их решений? Ну т.е. ничего, кроме анекдотичного "мы хорошо делаем скрам и достигаем целей OKR, поэтому убыток $1B, если бы плохо достигали, был бы убыток $2B" в голову не приходит

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

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

Владимир Горшунов. Coaching Agile Transitions - или как разворачивать ваш корабль

Название доклада отсылает к книге Дэвида Марке "Разверните ваш корабль" (Turn the Ship Around) - от капитана подводной лодки США о том, как он перестраивал систему управления. И в результате лодка лучшей.

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

Есть 4 фокуса

• Time to market. Не только IT-разработка, но и раскатка до прода.
• Solution Quality. Измеримое качество, уровень при котором продолжают пользоваться - устраиваемое качество
• Employee engagement/ Отсутствие - итальянская забастовка
• Productivity.

Что хочешь сделать с каждым пунктом? По сравнению с конкурентами.

И еще два важных аспекта.

• Transparancy - прозрачность, должна быть как минимум через один уровень, а лучше через всю компанию.
• Alignment - выравнивание, когда сотрудник и команда понимают, какой вклад в стратегию компании дает то, что они делают.

В целом надо балансировать хаос и бюрократию. И задача - делать такой баланс, чтобы улучшать указатели.

Agile Coach competency framework: facilitating, coaching, teaching, mentoring

При любой трансформации до улучшения показателей идет этап ухудшений - пока новое настраивается. Когда становится плохо, многие делают шаг назад - и трансформацию останавливают. Поэтому они делают трансформацию итерациями: небольшие просадки и quick win. При этом они не делают чек-лист трансформации, который показывает, что "все хорошо", а смотрят на результат деятельности организации. Хорошо - когда они изменились.

• Behaviours and practice. Люди не привыкли договариваться на собраниях, а привыкли сидеть с недовольным лицом, а потом придти к руководителю через уровень и сказать "там ерунда, я знаю как, но им не скажу"
• Capability and Structures. Оргструктура и расположение влияет на действие. Одна команда в распределенном варианте, или в общем помещении работает по-разному. А если выровнять по OKR даже без оргизменений - будет хорошо. Надо не только менять оргструктуру, но и учить новому поведению
• Mindset. Надо менять ценности. И для них важна валидация реальностью.

SAFe. Большая картинка.

• Есть SAFe implementation roadmap
• Контрольная точка готовности к изменениям - сверху и снизу. Если готовности нет, получится максимум партизанский Scrum.
• Нарезаем на стримы - train. Change agent, затем Managers and leaders

Поведенческие модели у человека меняются за 2 года - если человек хочет меняться, а среда поддерживает.

• Если не хочет, или нет поддержки - затягивается
• Есть кейс компании, которая каждые два года заказывает agile-audit и запускают трансформацию. Через некоторое время владельцы целиком меняют топов, и цикл повторяется.

Agile-трансформации

• From Red to Green or Orange to Green (по Лалу)
• Organizational tribal: from stage 3 to stage 4. Это по Логану
• От функциональных колодцев к командам
• Клиенто-центричная модель, когда чем ближе к клиенту - тем важнее, а управленцы их обслуживают или создают среду.
• Смотрят на организацию целиком, а не строят agile-острова

От учета эффективности сотрудника переходят к эффективности команды.

Антипаттерн: рост сотрудника ради роста, без открытия возможностей новых проектов, без привязки к развитию компании.

Андрей Сокол. Как предотвратить выгорание у себя и команды

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

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

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

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

И многие легкие позитивные практики - движение, улыбка (только искренняя), любовь, секс. Отвлечение

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

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

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

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

— Максим Цепков • 15:49, 7 февраля 2021 • нет комментариев