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

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

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

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

Содержание

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

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

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

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

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

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

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

советы:

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

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

Доверие:

Фидбэк

Варианты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отмечу при этом, что поскольку культура работы с метриками - такая же, как в метриках 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 фокуса

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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