2021-02-07: LeadManage IT 2020 - публикую отчет
Facebook напомнил, что год назад в этот день я был в Минске на Lead/Manage IT Тогда еще нельзя было предполагать дальнейшую траекторию прошедшего года - эпидемию, политические события в Беларуси и во всем мире... Но эпидемия пойдет на спад, а политика пойдет в конструктивном русле. И конференция еще повторится, во всяком случае в этом году будет online, как я увидел на сайте. В прошлом году было много общения и интересных докладов. Я с удивлением обнаружил, что я не опубликовал по итогам конференции отчет, остались только отдельные посты в FB. Исправляюсь.
Конференция собрала 500-600 участников и проходила в два потока. На вводной панели был оглашен гендерный состав участников и развеян образ IT как мужской среды. Оказывается, IT - это мужчины-разработчики, которые программируют под руководством прекрасных дам.
Я выступал с докладом Роли в проекте: как поделить поляну ответственности?. Это - очередная пересборка моего доклада на эту тему.
А теперь - заключительная фотка конференции и заметки с докладов.
Содержание
[убрать]- 1 Егор Яворский. Проект с заказчиками и командами из других культур
- 2 Роман Сорока и Александр Стецура. Как выжить в роли тимлида
- 3 Yuliya Kurapatsenkava из Spotify. Как измерять неизмеримое: метрики продуктивности
- 4 Роман Кононов из Uber. Как сочетать подход OKR в высокоуровневом стратегическом планировании и Scrum - в тактическом
- 5 Владимир Горшунов. Coaching Agile Transitions - или как разворачивать ваш корабль
- 6 Андрей Сокол. Как предотвратить выгорание у себя и команды
Егор Яворский. Проект с заказчиками и командами из других культур
Пост 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 и другие сейчас делают отдельные комнаты и капсулы для этого. Полифазный сон позволяет демпфировать жаворонок-сова, а это генетическая разница.
Естественно, на выгорание влияют эмоции, при этом был разбор механизмов возбуждения разных эмоций в лимбических системах с последующей передачей через поясную кору в префронтальную. При этом области возбуждения эмоций с большой индивидуальной вариабельностью, например, размер миндалевидного тела, отвечающего за страх и тревожность может отличается в три раза, и это обусловлено и генетически и воспитанием.
И многие легкие позитивные практики - движение, улыбка (только искренняя), любовь, секс. Отвлечение
Интересный подход финнов - немного подбухивать дома, не выходить. И будет счастье. У них для этого есть специальное слово. Но не в дым с перезагрузкой.
[ Хронологический вид ]Комментарии
Войдите, чтобы комментировать.