mtsepkov

Собрал и опубликовал на сайте отчет по #MergoConf https://mtsepkov.org/MergeConf-2024-Msk Конференция впервые прошла в Москве. Два дня, 8 потоков, и среди докладов доклады были очень содержательные, конспект которых не поместился один комментарий. Я сам тоже выступал. А записей конференции не будет, так что пропущенные доклады пропали безвозвратно. Так что читайте мой конспект, хотя докладов в нем мало. А организаторам хочу пожелать успехов.

Публикую отчет по #EnterpriseAgile - https://mtsepkov.org/AgileEnterprise-2024 Общее впечатление от конференции таково: у крупных компаний, которые хотят использовать Agile-методы всерьез на масштабах компании - получается это делать, технологии набрали зрелость. Используется OKR для координации по целям и фокусировки на развитии, а из SAFe выделилось ядро полезное ядро: PI Planing для синхронизации и получения реалистичных планов на большом масштабе, до 10 тысяч человек и более, и value stream train - средство управление потоками создания ценности с трассировкой до стратегических целей вместо обычного управления потоками задач, где выполнение задачи еще не гарантирует получения ценности для компании и потребителя. И в целом получается, что компания - не механистичный исполнительный механизм, а конструкция со свободными элементами, обладающими собственной волей, но действующими скоординировано.

Отчет включает опубликованное в ходе конференции и три доклада, конспекты которых я опубликовать не успел. Это - меньше половины докладов конференции, так как параллельно шло два потока, а на части слотов нетворкинг я предпочел докладам. Вот список.
* Дмитрий Баштинский из HeadHunter. Принимаем решения об изменении процессов на основе данных (и не только).
* Максим Соловьев и Екатерина Елманова из Россельхозбанка. Внедрение Value Stream для ускорения цифровизации Банка.
* Анна Аверьянова из Робофинанс. Как OKR помог закрыть бизнес!
* Марина Кубанина. Технологии Доверия (ex-PwC). Про лоскутные одеяла, развод и Agile.
* Сергей Паршиков. Оценка производительности команды в корпоративной среде
* Сергей Лебедев и Максим Матвеев из YADRO. Тернистый путь к звездам: как мышление меняет компанию
* Евгений Михин из Яндекса. Continuous budgeting в портфельном управлении Яндекса
* Алексей Грабарник из Газпромбанка. Lean-управление портфелем стримов в Газпромбанке

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

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

С KPI есть две популярные системы: (1) волюнтаризм руководителя, который субъективно ставит продуктивность и соответствие культуре; (2) бездушная оценка системы, к которой добавляется личный фонд руководителя. В обоих волюнтаризм приводит к обидам. Реально, на мой взгляд, проблема в том, что руководители норовят не просто поставить оценки, они еще часто не хотят внятно объяснять причины, и вообще делать результаты прозрачными. Их можно понять - объяснить без обид психологически сложно и требует времени, но обиды дает это. Впрочем, идея Сергея это тоже лечит.

Когда он придумывал систему, то держал две метафоры.
* Самомотивация - игра в теннис об стенку, когда ты должен каждый раз корректировать по своим действиям
* Бежать за чемпионами - смотреть на метрики коллег и сравнивать себя. Нужна честная, прозрачная, а не субъективная оценка.

Что входит в квартальную оценку?
* Продуктовые и бизнес-метрики - это всем понятно
* Голос клиента - это тоже продуктовая, но это не предвзятый взгляд клиента. Клиенты ставят звездочки за функционал, и это транслируются.
* Эффективность производство - на прошлой конференции был отдельный доклад и в презентации есть QR код со ссылками.
* eNPS: Критика - нейтральное - промоутеры. Формула: Промоутеры - Критика.
* Visibility - публичные выступления. Когда ты подталкиваешь выступать - ты подталкиваешь к выбору интересных задач. А еще - писать в корпоративный час о запуске фич - внутренняя видимость. Это реально поменяло словарь - когда пишешь новости сам осознаешь что сделал, позиционируешь в других терминах.

Дальше эти оценки взвешиваются для общей оценки. И есть dashboard мониторинга: снежинка, тренды, сравнительные характеристики. Dashboard видят все.

Важно, что систему придумал не он сам, они о ней договорились, ее ведет Excel. Не нравится - систему можно менять. Открытые оценки и сравнение - команды начали сравнивать, задавать вопросы - и выяснили, что методики оценки разные, начали разбираться. А вот его самого топы оценивают субъективно.

#EnterpriseAgile Анастасия Заруднева из Райффайзен Банк. Continuous Big Systems Replacement. Банк меняет основную систему, которая обрабатывает 15м операций в день, над ней работает 250 команд. Проект идет три года, они в середине пути. При этом существенная часть нового в параллельной эксплуатации, а часть уже ведут в новых системах, так что есть уверенность в успехе. Важно: новую систему пишут те же команды, что и развивают старые, потому что надолго вырвать команды из создания реально работающего продукта противоречит agile-подходу. Дополнительно за счет этого команды понимают продукт, знают алгоритмику.

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

В направлении 3 стрима, 40 продуктов, примерно 15 в стриме. Пример продукта - депозиты ФЛ. На стрим - менеджер стрима, бизнес-аналитик и команды, которые пишут микросервисы. Переводят 4 продукта одновременно. Продукт-менеджеры сами решают, насоклько они проводят реинжиниринг при переносе в новую систему, будут ли они переписывать логику при переходе. Может быть выделена фича-команда или задачи помещены в общий бэклог. С бизнесом ежеквартально согласуется список продуктов, которые переносятся.

На слайде была архитектура: каналы -> продуктовая логика -> core -> главная книга -> распространение данных -> потребители (риски, отчетность и др.) Фича-команда - продуктовая умеет детать доработки для всех командах. Может параллельно работать старая и новая продуктовая логика. Новая главная книга работает параллельно со старой, но мастер пока старая.

Как управлять таким переносом?
* Делать на маленькие шаги
* Исследовать через поставку
* Ставить целью спринта приближение к target-архитектуре
* Находить возможность parallel run
* Работать с потребителем данных

#EnterpriseAgile Максим Соловьев и Екатерина Елманова из Россельхозбанка. Внедрение Value Stream для ускорения цифровизации Банка. Одна из существенных черт Agile-методов - прозрачность. И рассказ был о том, как обеспечивают прозрачность работы ИТ для топов банка через запуск value stream. На входе была ситуация, когда руководство неплохо представляет, что происходит в проектах, такая культура в банке есть, но там задействована примерна 1/3 ИТ. А 2/3 были через пулы распределены по подразделениям бизнеса и чем именно они занимаются, руководству не понятно. Более того, как выяснилось в ходе проекта, бизнесу тоже было не понятно, бизнес с ИТ не общался, и обе стороны имели не высокое мнение о другом, как это часто бывает. А еще бизнес с удивлением выяснял суммы, в которые ему обходится ИТ-пул - бухгалтерия это распределяла на общие расходы, а в управленческой отчетности это не светили.

Средство решения - реорганизация работы ИТ в value stream? как это описано в SAFe, в которых идет квартальное планирование от задач бизнеса. Каждый стрим - 10-15 команд. За 2024 запустили 13 value stream, на следующий год - еще столько же. Запуск - это определение границ, целей и задачи value stream, затем структурирование внутри. После этого идут циклы квартального планирования и реализации, и по результатам - актуализация целей и задач на следующий год.

Получили:
* Структурирование работ, и людей по направлением
* У всех - единая мотивация
* Управление достижением цели
* value stream - продуктовые, операционные, процессные.
* Связь между целями и результатами деятельности. Воронка продаж, экономика
* Метрики - cycle time, ttm, радар agile-здоровья и оценка зрелости

#EnterpriseAgile Марина Кубанина. Технологии Доверия (ex-PwC). Про лоскутные одеяла, развод и Agile. В PwC большое количество ИТ-системы были от головной компании. Поверх них кое-где были собственные решения с российской спецификой. Когда российская часть разводилась с головной, у него осталось лоскутное одеяло этих решений, а чтобы не допустить остановки бизнеса - перешли не Excel. А дальше надо было реанимировать ситуацию, и в компании создали центр продуктовой экспертизы, чтобы сделать это системно. Марина - его руководитель, в центре собраны архитекторы, devops, юридическое обеспечение и ряд других компетенций, а разработка идет отдельными командами, которую центр поддерживает. И еще просвещает в части продуктового подхода и unit-экономики. И у них получилось не просто разработать продукты, поддерживающие работу компании, но и начать выводить их на рыноК PwC этого вообще не делало. Такая вот success story. О конструкции разработки и функциях центра Марина рассказывала, но очень пунктиром, на слайдах подробности есть.

#EnterpriseAgile Анна Аверьянова из Робофинанс. Как OKR помог перезапустить бизнес! У Робофинанс с 2016 был бизнес в Испании - online выдача кредитов, в 2020 случился ковид, мораторий на платежи кредитов, с одной стороны, а с другой - поддержка ликвидности и онлайн. Они продолжили бизнес, но в 2021 выяснилось, что люди набирают кредиты и не платят. Поэтому по итогам года инвестор, он же владелец и ген.дир принял решения о закрытии бизнеса. Но такой бизнес нельзя закрыть одним днем, надо соблюсти требования регулятора, иначе можно лишиться лицензии и для других сегментов бизнеса. Поэтому был процесс на год, который решили вести по OKR, как и все остальное. Цель понятна - минимизация потерь. Было сделано 3 сценария от команды: реалистичный, негативный и позитивный. И в конце первого квартала увидели по метрикам, что развитие идет лучше даже оптимистичного сценария, и в принципе динамика позволяет предположить, что за год можно будет сохранить команду и выйти в плюс. Они пошли к владельцу, показали цифры, получили добро на попытку сохранения и поменяли цель. И у них получилось. У команды был стимул - им нравилось работать вместе и они точно хотели сохраниться. А пост-анализ показывает, что сыграли два внешних фактора: поменялся рынок потребления, то есть тех, кто брал кредиты, при этом часть конкурентов с рынка ушла. А OKR позволил во-время заметить изменение трендов, и пересобрать продукт под новый рынок.

#EnterpriseAgile Дмитрий Баштинский из HeadHunter. Принимаем решения об изменении процессов на основе данных (и не только). Это был рассказ о работе с системой метрик, применяемый в hh, иллюстрированный конкретными примерами. Основная идея - метрики лишь показывают точки потенциальных проблем, и не автоматически, а после анализа показателей на предмет нежелательной динамики или соотношение метрик. А дальше нужно породить гипотезы - что может являться причинами, и проверить их через детальный анализ, погружение в реальную работу людей. При этом, если проблемы выявлены из общих метрик, то анализ ведут в каждом из сервисов, причины могут быть различны. Общие подтвержденные гипотезы становятся фокусом на уровне компании, частные - в сервисах, масштаб определяет приоритеты.

В докладе было конкретной дерево метрик из двух групп - ресурсы и поток.
1.1. ФОТ на доход или ключевую метрику сервиса (не для всех сервисов доход - целевая метрика)
1.2. Распределение ресурсов: стратегия, продукт, тех.налог, прочее. Классификация задач, дальше корректируется продуктом, так как большие задачи могут перекашивать.
2.1. 85% lead time feature. Полный - от discovery, постановки до АБ тест и пост-продакшн. 85 выбрано ретроспективно из анализа.
2.2. Эффективность потока - блокеры.
2.3. Средняя пропускная способность за неделю

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

И в конце - шаги работы с метриками.
1. Начать собирать метрики
2. анализ и генерацию гипотез
3. провести анализ сервиса - проверить гипотезы
4. фокусы для сервисов
5. общие гипотезы для всех сервисов
6. задачи для всех и для конкретных сервисов

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

Третья проблема. На уровнях Widgets + Features + Entites - слишком много связей между модулями. Там пример TodoList - он размазывается по всем уровням, на уровне features превращается в множество команд. А рядом UserList - тоже много классов и файлов. И это все путается.

Какие решения предлагает Евгений, чтобы уйти от недостатков? Он в целом сохраняет структуру слоев и их деления, но предлагает ряд изменений.
1. Entities - не объект, а группа связанных сущностей, например, user=user+session+profile
2. Features - не use case по действиям, а блоки связанной функциональности для бизнеса, например TodoList. Фичи получаются большие, их надо структурировать.
3. Для устойчивости приложения из сегмента domain, работы с бизнес-сущностью, запрещается импортировать shared.
4. Для связывания разных объектов используется dependency injection. Это самое сложное. Пример: UI TodoList требует календаря. И мы вызываем абстрактный render calendar. Его связывание с конкретной реализацией - на уровне page.
Вроде, проблемы решаются. Правда, у Евгения вопрос: это по-прежнему FSD, или уже другая архитектура?

Я хочу начать свой комментарий к докладу с ответа на этот вопрос. Но он будет длинным. Есть такая штука - парадигмы программирования: процедурная, объектная, реляционная, функциональная и другие. Процедурная восходит к книге Николаса Вирта "Алгоритмы + Структуры данных = Программы", это 1976. Позднее добавился UI. B весь старый enterprise - 1С, SAP и многое другое сделан именно в процедурной парадигме, хотя уже на объектных языках. Потому что объектные языки появились с C++, в 1980, объектно-ориентированное проектирование (OOAD) - только через 10-15 лет, а его окончательное оформление в DDD - вообще в 2003. И если почитать шаблоны корпоративного приложения Фаулера или другие книги, то он пишет, что шаблон RichObjects, объекты предметной области - он сложный, проще работать на DTO или использовать другие аналогичные шаблоны. Отличие объектного подхода - объединение данных и поведения в одном объекте с инкапсуляцией внутреннего устройства. А в FSD данные, слой entities, отделены от поведения. оно в features, подобно алгоритмам и структурам данных у Вирта. Отсюда и сложности, если мы пробуем использовать FSD, держа в голове еще и концепцию модели предметной области DDD - она-то сделана в объектной парадигме. А изменения, которые предлагает Евгений - в рамках этого направления. Так что, на мой взгляд, получилось нечто иное.

Но это - концептуальный ответ. А есть еще прагматический. Если речь идет про объяснения новичкам, то практичнее говорить про FSD с изменениями - есть референс и известный подход, ты не говоришь про велосипед. А вот если есть амбиции больше - то можно говорить про альтернативу. Представить свой подход на международных конференциях, написать книгу. Тогда лучше позиционировать как новый подход. например. полученный в результате синтеза FSD и Clean Architecture или гибрид FSD и богатой доменной модели DDD, или что-то подобное.

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

#MergeConf Евгений Паромов из Evrone. FSD: 3 главных недостатка после 3 лет использования. В докладе было краткое изложение архитектурной методологии FSD, проблем, которые влечет его использование, если следовать букве концепции, и тех модификаций, которые использует Евгений для решения этих проблем. А в начале был рассказ о том, что такое - архитектурные методологии и зачем они нужны. Хорошо, когда архитектуру подбирают индивидуально для проекта, опираясь на требования. Но на старте проектирования требований часто нет, они прорабатываются позднее, а архитектура - нужна. Иначе получится комок грязи, спагетти-код или нечто подобное - это как раз примеры архитектур, которые складываются сами, если отдельно не думать. И тут появляются архитектурные методологии или шаблоны - набор эвристических принципов, следуя которым в среднем получаешь хорошую архитектуру, обеспечивающую надежный, расширяемый и переиспользуемый код.

Эту роль FSD выполняет: проект у мидлов с использованием FSD получается лучше, чем без этого. При этом шаблон - простой, без dependency injection, который сильно усложняет конструкции, и сделан для фронта, в то время, как большинство других - для бэка, а значит их примеры ты должен сначала переосмыслить, что сложно на начальном этапе. FSD делит код на слои:
* app - приложение в целом
* pages - экраны
* widgets - целостные компоненты интерфейса
* features - реализация действий пользователя, use case
* entities - бизнес-объекты проекта
* shared - библиотеки, не привязанные к объектам бизнеса

Каждый слой делится на срезы - slice, это модули. А slice делится на сегменты, тут типичный пример UI - model - api. Есть ограничение: реализация нижележащего слоя не должна обращаться ни к вышележащему, кроме того ни к смежным частям одного слоя, то есть один объект не может вызывать другой.

Евгений познакомился с FSD три года назад, успешно приносил и применял в командах, видел позитив. Потом он пришел в команду, где FSD начали применять до него, и обнаружил там множество очень маленьких фич, а еще активно живущий UI kit в нижнем слое, что порождало неустойчивость проекта. Он задумался: это особенности внедрения подхода в проекте, или какие-то проблемы заложены в самом подходе? Анализ выявил три проблемы.

Первая проблема - слишком изменчивый shared. Это происходит не всегда, а только в случаях. когда проект опирается на активно развиваемые библиотеки. Типичный кейс - развиваемый UI kit. И в результате надо либо сохранять совместимость, и тогда в UI kit множатся объекты, появляется button1, button2, button3, либо нужен частый рефакторинг при изменении shared-уровня, либо возникают фасады вместо конкретных классов, и это усложняет использование.

Тут как альтернативу можно посмотреть на шаблон Clean Architecture. В отличие от FSD, по нему есть книжка, где подробно объяснен не только сам шаблон, но и его основания. В нем слои другие: WebUI - infrastracture - application - domain. То есть инфраструктура поднята выше приложений, и потому она может активно развиваться. Но там мы не можем в реализацию сущности (domain) включить UI,иначе чем через dependency injection, а это сложно и потому во фронте - не прижилось.

Вторая проблема: entities не позволяет описать бизнес-модель. Потому что модель - это не только объекты, но и связи между ними. И важно отделить бизнес-модель от всего остального. А тут объекты не могут вызывать друг друга, связи, следуя шаблону, приходится выносить на уровень features, где они смешиваются с действиями пользователя. В этом отличие слоя entities FSD от domain в Clean architecture.

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

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

У меня к материалу доклада есть следующие дополнения.

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

2. Люди по-разному понимают слова "ответственность", "справедливость", "эффективность", не говоря уже о тех, которые содержат оценку, например "хорошая работа" или "успешный проект". Поэтому надо раскрывать содержание слов. О том, как правильно раскрывать содержание ценностей хорошо написано в книге Марка Розина "Успех без стратегии": для каждой ценности должен быть сияющий идеал и заземление на повседневность в виде паттернов и антепаттернов поведения, и именно о них надо договариваться. Потому что для одного "пришел на встречу во время" означает "опоздал не больше 3 минут", а для другого "пришел за 3 минуты, чтобы подготовиться", не говоря о более сложных конструктах, таких как качественный проект. И все инструменты, типа отранжируй ценности, корректно работают только после того, как о содержании договорились. Проблема многих моделей и тестов в том, что они не учитывают эту разницу смыслов. Модель Спиральной динамики говорит, что есть восемь принципиальных конструкций ценностей, которые согласованным образом переопределяют смыслы понятий. У меня об этом есть несколько докладов и статей, если интересно - дам ссылки.

3. Если берешь чужую модель ценностей - надо понимать, в какой культуре она создавалась, какой смысл там вложен в слова, каковы представления про идеальную компанию и сотрудника. И сравнить это с вашей компанией. Я не знаю, какая модель заложена в книге "Потенциал команды", о которой говорила Эльвира, я ее не читал, но я анализировал многие известные модели ценностей - карту культур Хофстеде, модель Шнайдера, карту Инглхарта-Венцеля, и даже психологические модели DISC и Big Five, и они как раз показывают соответствие идеал, при чем выработанный на материале западной культуры. Об этом у меня тоже есть статьи (по ссылке - последняя).

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

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

Как практически выяснять ценности сотрудников? Можно это делать в формате упражнений.
* Moving Motivators - выявление личных мотиваторов. Доска, сотрудники получают карточки и располагает по линии важности. Порядок, свобода, мастерство... А затем - насколько это удовлетворяю в работе, получаю ли.
* Culture design canvas. Картирование культурного кода команды. Как празднуем, как звучит в обучении, как лидерство на их основе. Netflix разработал документ по кольтуре - принципы работы, и сотрудники на них ориентируются.
* Командно-игровая сессия Ценности.
* Диагностика ценностей команды. Опираемся на историю, которая позволяет шкалировать.

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

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

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

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

Техника
* три простых дела. Если запланирвоали 4 дела и 3 сделали, четвертое пойдет легко, мозг настроен
* fresh or fried - сложное утром, простое - вечером.
* smart. выучить китайский - но нет времени. Мобильное приложение и заниматься - и результат есть, смалтолки получились
* work life balance.

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

#MergoConf Анастасия Валуйская из VK. Эффективный менеджер как им не быть или все же быть?! Если кратко, то доклад о том, что понятие "эффективный менеджер" сейчас имеет резко отрицательные коннотации, которые основаны на реальных фактах. И потому не надо таким менеджером становиться, а надо управлять иначе.

А если подробнее, то когда-то Питер Друкер характеризовал эффективного менеджера как того, кто создает стратегию, принмиает риски, погружается в команду и управляет ей. Из тех времен пришла квалификация основных стилей управления на авторитарных с жестким управлением, либералов, которые за общую дружбу, как кот Леопольд и демократов, которые полагаются на команду, но при необходимости приходят на помощь, как Гэндальф. Судя по всему, это классификация Курта Левина (1939), правда у него либеральный стиль назывался попустительским (laissez-faire в оригинале). От себя отмечу, что у Белбина есть роли Шейпера и Координатора, которые в целом соответствуют авторитарному и демократическому стилю, при этом Белбин выделял свои роли экспериментально. А попустительство получится, если руководителем назначить Душу компании, есть у Белбина такая роль, очень полезная, но не руководящая. Впрочем, Анастасия не разбирала детали этой классификации, так что в контексте доклада все это не важно.

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

Эффективным менеджером быть плохо, и Анастасия дала антипаттерны поведения в форме вредных советов.
* Заслуги - вам, провалы - подчиненным. Кейс - присвоили заслуги.
* Максимально нагружайте людей, особенно непонятными задачами. Чем больше загружен - тем эффективнее результат
* Усильте контроль, эффективный контроль - залог успеха, поставьте микроменеджемнт
* Никогда не рассказывайте команде планы, куда идет компания. Разработчик ведь перестанет писать код, узнав о целях, он будет думать о
* Не вникайте в предметную область. Кейс - человек в ИТ не знал, что есть фронт, бэк и дизайн. Отмечу, что этот вредный совет - основа английской управленческой практики 19 века: джентльмен может управлять чем угодно, ему не надо специально учиться. И именно такой подход лег в основу MBA. В отличие от немецкой традиции 19 века, воспринятой тогда же в России, где знание предмета считалось обязательным.

Дальше была часть о том, как реально управлять с пользой, а не быть не таким гротескным эффективным менеджером. По аналогии с проектным треугольником деньги-время-содержание, она предлагает люди-время-содержание.
* Тайм-менеджмент. Но! СБС - синдром бесполезных совещаний, практически эпидемия.
* Содержание. Пришла в ВК, маркировка рекламы - погрузилась, и в продукты
* Люди. Работа в косманде, мы все люди. Встречаются позитивные и негативные. Но есть и другие эмоции. Необходимо мириться, находить контакт и налаживать связи.

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

#MergeConf Андрей Гирин из Лидеры изменений. Болото операционки: чем больше шевелишься, тем сильнее увязаешь. Как реализовать стратегию и не утонуть в деталях. Проблема, что операционка кушает все врмя - распространенная. И доклад был про способ работы, методику OKR, чтобы так не происходило. Была методика, с шагами, иллюстрированная примерами. В конце был итог из 6 пунктов.
1. Сфокусировать компанию. Взять группы, которые про стратегию, и не засорять
2. Управлять целями, а не задачами. Задач - много, у них статусы и проблемы. Поэтому пусть люди идут
3. Отслеживать пульс - метрики, что компания не идет вразнос.
4. Выбирайте правильных людей, в зависимости от целей и задач.
5. Определите амбиции. Насколько можно инвестирвоать в конкретные направления в рамках стратегии.
6. Вовлекайте причастных. Их больше, чем ответственных, и они могут помочь или помешать. Никто не злой, но у причастных свои планы.

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

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

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

#MergeConf Елена Спиридонова из CUSTIS. Как executive search может решать сразу несколько задач ИТ-бизнеса. Для тех, кто не в теме, executive search - поиск редкого специалиста, обычно на позицию топ-руководителя или эксперта, с уникальными требованиями профиля. Такие специалисты могут существовать, но они не ищут работу, у них вообще не может быть резюме. При этом с ростом дефицита на рынке ИТ все больше позиций - архитекторы, аналитики высоких уровней или с конкретным опытом все больше становятся объектом такого поиска. В докладе был алгоритм и конкретные кейсы.

Шаги поиска.
1. Работа с заказчиком. Для чего нужен спец, что изменится, когда придет, что будет, если не придет. И главное - как будем встраивать, готов ли заказчик, часто - владелец или директор, тратить время на встройку.
2. Стратегия поиска. Их нет на сайтах, у них нет резюме, они не ищут работу. Используем РБК, Tadviser, habr. Авторы, блоги, подкасты, рекомендации.
3. Интервью и оценка. Люди работу не ищут. Но если пришли пообщаться - значит какой-то шанс есть. Вопрос - понять, за что можно зацепиться. Но и требования. Сulture fit. И что драйвит, обычно - не деньги. Амбиции, проекты, поднять направление с нуля, найти нового клиента и так далее. Третий не заканчиваем, пока не поймем, что интересно, и как соответствует.
4. Офер. Исходя из того, что узнали на 3.
5. Выход и адаптация. HR и собственник или другой заказчик должен быть рядом.

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

Но если делать самим, то надо понимать, что в технологии инструменты - 20%, а остальное - коммуникации и soft skill. Надо нарабатывать социальную сеть тех, кто в теме, кто готов порекомендовать специалиста. Для этого она активно ходит на конференции, не как HR, а как бизнес, общается. Надо уметь знакомится, общаться, такие специалисты не откликаются на письмо с предложением на работу, а вот если спросить про его выступления или подкасты, попросить помочь разобраться в теме, рассказать о проблеме и попросить рекомендовать, кто может помочь - они откликаются, и могут порекомендовать конкретного специалиста. А чтобы найти специалиста в моменте - используют публикации, пресс-релизы, выясняют, у кого есть опыт подобных проектов, если это - существенное требование. Или по социальной сетке, если речь идет о каком-то уникальном продукте, который используется в ограниченном числе банков или компаний - то кто конкретно вел проекты внедрения, компанию обычно можно узнать по прессе, а фамилии участников проекта - уже через знакомых.

У технологии есть ограничения, она бесполезна, когда заказчик - не настоящий. Или когда хотят замаскировать проблему, например, в описании вакансии виден CTO, но СТО в компании есть и его не хотят менять. Надо быть готовым, что не будет большого потока резюме, проекты 4-12 месяцев. И будет требоваться много времени - у HR и у собственника.

#MergeConf Юлия Черемохова из Skyeng. Провоцировать нельзя валидировать. Основной фокус доклада - про провокацию как способ перевести сотрудника в состояние "делаю то, что нужно компании" из состояния "у меня все нормально". Но первая часть была о способах поддержки сотрудника и валидации взаимодействия по нескольким уровням, начиная с валидацией присутствия и понимания и заканчивая самореализацией. Потому что провокация как инструмент констркутивна только при условии хорошего взаимодействия, а если отношения с сотрудником конфликтны, то провокация лишь усугубит ситуацию. Когда уместна провокация? Когда диагностика показывает, что у сотрудника не хватает ответственности, он приходит без результата и у него есть какие-то объяснения, которые он считает нормальными. Эту ситуацию надо отличать от ситуации, когда ожидаемый результат был невозможен или сомнителен, например, по тому, что задача была некорректна поставлена, например, вас просто неверно поняли, и это не верифицировали в момент постановки.

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

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

#MergeConf Яна Шаклеина из @outlines_tech. Однажды в сказке: повышаем продуктивность команды через внедрение фантастических персонажей. Если отжать содержание доклада до сухого остатка, то он - о том, что есть три типа сотрудников, и руководителю надо быстро их диагностировать и вести себя соответственно. Вот они.

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

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

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

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

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

#MergeConf Илья Баксанов. Идеяспособность: как думать креативно, адаптивно и продуктивно? Доклад о том, что идеи может порождать каждый, и надо себе разрешить. Задача - не только уметь пользоваться идеями, но и идеи создавать. Креативность - одна из ключевых составляющих. Конечно, для нее могут быть блоки в команде или компании - не быть поддержки новому, когда среда сопротивляется. Но важно снять блок в себе, а дальше можно проявлять в разных областях или искать подходящее место.

В докладе множество тезисов и практик, они реально полезны. Только примеряя на себя, надо помнить, что все мы - разные, каждому нужно свое подходящее. Но при этом в списке много того, что вам подойдет, он большой. Так что - пробуйте.
Итак, что помогает быть креативным?
* Смотрю на мир через идеи.
* Мы живем в мире идей. MergeConf, выступления - все это было когда-то чьей-то идеей.
* Мы креативны по природе, вопрос лишь в том, насколько ярко мы проявляем эту креативность.
* Идеяспособность: состояние (в котором могу) + навыки и методы = образ мышления и свойство личности
* Идеи - не только на работе - идея занять ребенка тоже востребована. Заинтересовать.
* Установка: каждый может придумать идею
* Полюби процесс поиска идеи и решения задачи. Он сам не сразу к этому пришел
* толерантность к новому и неизвестному. Когда надо придумать - идей нет, и это нормально, я не тупой.
* Относится к проблеме как задаче, которая не решена. Или трудность не как препятствие, а как приглашение к поиску нового
* Знать свои творческие состояния. Коллекция состояний - у человека от 7 до 15 разных состояний. И среди них должны быть состояния, где можно придумывать идею. И надо понмиать, в каком состоянии ты можешь.
* Надо понимать, что тебя вводит в это состояние. Может быть метафора, например, печка, пекущая пирожки. Включать может место, обстановка, ритуал, атрибуты, действия. У него: душ, салон самолета, музыка на повторе, прогулка с вопросом, размышления на тему. * Очень влияет музыка. Спокойная и медитативная - надо подбирать под занятие.
* Может быть простое действие, например, сказать "Так!"
* Наблюдательность. Приглядеться к окружающему миру. Липучка на кроссовке - инженер отдирал репей с собаки.
* Находчивость и изобретательность. Умение находить выход из ситуации. В Игре престолов мантии делали из ковриков Икеа, костюмер в интервью сказал - Икеа тут же сделала мануалы и начало продавать.
* Воображение. Сны - они в голове, ты придумал, увидел - воображенеи есть у всех. Деньги из листиков, секретики.
* Сегодня меня ждет день, в котором я никогда не был! Это - уникальный день! Призма меняет восприятие.
* Путешествия. Если нет возможности уехать - с чемоданом по Москве, уехать на выходные, переночевать в отеле. Но с чемоданом, как путешествие - это меняет восприятие.
* Сказать себе Ещё! Не останавливайтесь!
* Взгляд внутрь себя. Что для меня море, что для меня закат.
* Копилка идей. В записи куча разных идей. Они не запомнятся, пусть будут.
* Насмотренность. Это ингредиенты для приготовления идей. Чтобы складывать мозаику. Посмотри 1-2 даже если не смотришь
* Вдохновляться другими.
* Идействуй! Чтобы копилка идей не превратилась в кладбище. Пробуй, делай первый шаг.
* Пробовать новое. Загружать, делать это постоянно.
* Взгляд ребенка. Почему так, почему гром гремит, почему снег белый.
* Поле идей. Обменивайтесь, не держите внутри
* Футурологические прогнозы. Там часто фигня, но она будит фантазию. И можно читать старые.
* дИИалог. Дружба и сотрудничество с нейросетью. Потмоу что способ для быстрого рождения идей.

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

И заключение.
* Креативность - это выбор. Выдайте себе патент на неограниченное творчество.
* Вдохновение от слова вдок. Не забывайте его делать.