Короткая ссылка: Highload-2022-Spb

В Петербурге подряд прошли конференции Saint Highload и Saint Teamlead, и поэтому я публикую общий отчет с обоих конференций. Конференции, в целом - не сильно отличаются от соответствующих московских по общему направлению. При этом доклады - не повторяются, так что имеет смысл быть и в Москве и в Питере. Питерские меньше московских, но собирают по 1000 участников каждая, так что нет впечатления, что они камерные, как было на первых, уже нет.

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

Организаторы, помимо обычных докладов, стремятся дать на каждой конференции какую-то тему. Для Saint Highload это были обзорные доклады по истории - архитектуры, языков программирования, способов интернет-атак и так далее. А на Saint Teamlead - доклады про психологию от профессионалов, не только психологов, но и психиатра. Все это есть в моих заметках по докладам.

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

Происходящее актуализирует тему личного самоопределения. Этой весной профессиональное самоопределение оказалось завязано на геополитику гораздо сильнее, чем раньше. И принимать решения о том, как жить и действовать дальше, самоопределяться приходится гораздо чаще. Об этом было мой доклад Как строить образ будущего и идти к нему - схемы самоопределения (Saint Teamlead-2022) - я давал схемы, которые позволяют думать о самоопределении системно. При этом многие из них нужны не только для самоопределения, но и для коммуникации, понимания других, постановки цели, работы с собственным драйвом от деятельности и так далее. Это все смежные темы, и без них самоопределение не слишком получится. Поэтому схем - много, а доклад - обзорный. Но по части из них у меня есть материалы, а по другим - готов подробнее ответить.

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

Saint Highload

Александр Тоболь. Архитектура: история и будущее на примере ВКонтакте

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

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

История web

85-94 - компьютер только на работе, интернет текстовый, мейнфреймы,
95-2000 buble, интернет 24*7б музыка видео многопользовательские игры, рост, нелинейное скалирование. Пузырь dotcom и свободное оборудование
2000-2003 - эра эффективного развития. Большое количество commodity-железа лучше, чем один mainframe. Победил OpenSource - linux, Apache, PHP-python
Second Web 2003-2010. Дата-центры, web 2.0? персоналки пользователей
Cloud с 2010. Безграничная поляна вычислительных ресурсов.

Будущее туманно - если учитывать законы Мура и Амдала. Закон Мура: сначала - тактовая чистота, потом количество транзисторов на кристалле, упирается в физические ограничения. Амдала: распараллелить все что угодно, но скорость зависит от самого короткого пути. 2025 - физический предел по закону Мура и по параллелизму по Амдалу. Но есть квантовый компьютер, пока он вскрывает криптографию, но мы надеемся.

Wed 1.0 по 2003. Web 2.0 - социальные сети. С web 3.0 - проблема. Все думали, что будет AI и всякие помощники. Но все закрылись, весь контент стал внутри каждой сети отдельно. И открытой системы не случилось.

По Вконтакте - пересказывать не буду. Там кэши и балансировка, оптимизация хранения, куча собственных решений, таких как собственный RPC поверх UDP. Из интересного для меня - язык KPHP, который сначала был транслятором на C++ для производительности, теперь транслирует в бинарники и там при совместимости с PHP есть контроль типов, шаренная память, параллелизм. А по железу - отказ от RAID, потому что если сервер работал 10 лет и остановился - все диски не стартуют. Поэтому распределенное хранение на многих серверах с восстановлением памяти.

Дмитрий Завалишин. Языки программирования: прошлое, настоящее и будущее

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

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

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

Правда, это - про JIT-языки первого эшелона - Java, C# - с которыми работают серьезные команды, которые делают JIT-компиляцию. Для динамически компилируемых языки второго эшелона JIT (Python, PHP) - хуже. Но для них есть своя ниша. Так же как для интерпретируемых (Lua и др.). Именно потому, что выбор - многофакторный и для разных проектов важно разное.

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

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

Станислав Сидристый. Гибридная архитектура: разделяемый на микросервисы монолит

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

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

Антон Быстров. Dashboard as a code, или Путь от правок в UI до grafonnet

Задача. Когда у вас множество дашбордов. Стандартный способ создания dashboard - через UI, при сохранении получается примерно 5к строк кода на dashboard. А дальше возникает задача доработать какую-то конкретную панель, которая присутствует сразу во многих дашбордах. Конкретно у них возникла задача про панель, которая была на 50 дашбордах. И вносить идентичные правки через UI - тяжело и дорого. Можно напрямую править описания, но это на свой страх и риск. Они начали искать способ, инструментов - несколько, есть на Kotlin и Python, а они выбрали Grafonnet. Это средство на основе jsonnet, который создавался в Google для описания конфигураций, развитое для Grafana, где есть набор шаблонов для описания именно дашбордов. И дальше был рассказ с примерами кода, как это делается. При этом сначала новый дашборд делают через UI - потому что по текстовому описанию сложно представить, как будет на экране, удобнее накидать визуально и потом - переводят в описание json для grafonnet. В целом работает, есть сложности с обновлением версий Grafana - нет совместимости шаблонов, надо вручную.

Денис Васин. Блокчейн в корпоративной архитектуре — дань моде или необходимость?

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

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

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

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

Александр Поломодов. Канал. Продукт. Платформа, или Эволюция подходов к развитию мобильного банка Тинькофф

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

Интересно, то при переходе на сквозные команды Mobile - APIs - Back изменилось проектирование: от описания изменений экранов и API перешли к описанию user story, которые дают целостную картину изменений.

Наряду с feature teams есть core-команда, но у нее задачи - не общая платформа или библиотеки, а инфраструктурные вещи: архитектурные подходы по модульному делению; надежность через мобильные SRE и фиксацию проблем; масштабируемость - как мерить просадку, и лучше на тестах, а не у пользователей.

Есть правила, общие для команд, обеспечивающие качество, но тут было пунктиром, перечисление, что в них входит, а не конкретные правила. И непонятно, как сочетаются общие правила и вариабельность для команд.

Еще в докладе была ссылка на книгу Team Topologies. В ней описаны триггеры потребности в эволюции команд: софт стал чрезмерно большим; темпы поставки значительно замедлились; бизнес-сервисы опираются на разрозненный набор нижележащих, собираешь паззл. И симптомы по каждому, это было в презентации. А еще типы команд и взаимодействий, и это помогает конструировать ваш набор команд. Типы: streamed-aligned команды, enabling, complicated subsystem, platform team. Взаимодействие: collaboration, as service, facilitating. И это использовалось при переходах как шаблоны.

Филипп Дельгядо. Микросервисы через боль и превозмогание

У Филиппа всегда очень емкие и насыщенные доклады. Поэтому практически конспект по тезисам. Микросервисы - 150+ определений. Определение Криса Ричардсона с microservices.io, там часть - пожелания, а часть - про организацию. При этом у него были проекты (и малое приложение и enterprise). Его определение тоже социальное: много компонентов (5+), много баз данных, современные протоколы, современные подходы к разработке.

Зачем нужны. Крис много пишет, частично копируя определение. При этом многое вовсе не есть черта микросервисов, а частично и противоречат. И даже если это - правда, вопрос - что мы платим. Проблемы:

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

Зачем же они?? Пример - продажи.

Оплата картами - одно регулирование PCIDSS
В кредит - 152-ФЗ
Распродажи - пиковая нагрузка
Счета пользователей - надежность

Если монолит - то все это должно быть у всего монолита, и это - сложно. Если мы поделили на микросервисы, то:

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

Далее часть - как работать со сложностью - у нас множество взаимодействующих микросервисов. Есть инструменты

coupling & cohesion - декомпозиция с выделением подсистем, связанных внутри и слабо снаружи. Подход дает теория систем
топология - есть множество разнообразных типовых решений, и можно ограничить типологию взаимодействия
типизация - не все одинаковы, разные типы сервисов и архитектурная диаграмма взаимодействия
нейминг - понятное наименование микросервиса, если вы не можете придумать понятное и точное название - вы выделили неправильно
контроль - design review, простые картинки, мониторинг сложности. Смысл картинки в том, что сложную сложно рисовать, она ограничивает сложность.
Документация - интерфейсы (особенно асинхронные), типологии, стандартные решения

Дальше набор источников

Теория систем и системная инженерия
ТРИЗ
Современная психология
И отдельно: Ричард Фейман статьи, ТФКП, "Как спроектировать табуретку" на хабре.

Надежность

Незапланированные проблемы - отказы оборудования, софта, сети - это известно
Запланированные проблемы - выкладки новой версии сервиса.
- Совместимость версий - потому что отключаем-включаем экземпляры по-одному, а не сразу
- Инструменты миграции БД - надо писать, малыми кусочками, без дополнительной нагрузки. Как-то шло 3 месяца в Яндекс-деньгах
Canary-deploy чтобы новые релизы сначала тестировались на группах пользователей. Но с учетом, что новая фича - на нескольких сервисах, поэтому надо как-то помечать входящие запросы и дальше направлять на группы сервисов. Это уже не балансировщик, а сложные средства.
- Service mesh
- Query transformed - когда взаимодействие через очереди, и тут - сложнее, решений поверх Kafka - нет.
Сложная логики выкладки - для постепенного перехода. Императивная, стандартных решений нет, ansible - декларативный
Целостность. Перевод от плательщику получателю - много проверок, единая бизнес-транзакция. Saga. Но содержания - нет. Есть теоретический алгоритм: сценарий, шага, компенсация для каждого в случае проблем. Средств нет.

Варианты для саги

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

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

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

Аналитика - нет решения. Подходы типа Data mesh и другие - скорее называют проблему, они все сложные. Есть микропаттерны и советы.

А еще проблемы

Производительность
Мониторинг-логгирование
безопасность
разграничение прав

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

Михаил Малышкин. Как сэкономить на масштабировании, переехав с Cassandra на Scylla DB

Понятный доклад о переезде. Рекомендательный сервис для банков по данным мобильных операторов - экспресс-оценка заемщика, жесткие требования по ответу сервиса, и как следствие - по ответу БД, при этом БД ежедневно 800GB новых данных. Проблемы: всплески latency на garbage collector, фантомные данные после подключения ноды после падения - откуда-то подтягивались, они не мешали, но беспокоили, загрузка данных 12 часов - не укладывались в ночь, дорогое масштабирование (12 нод в кластере и вкидывание новой - не давало прироста).

Переход на Scylla показался quick win. Она совместима по протоколу. Думали, что за 2 спринта, оказалось чуть подольше. Сделали кластер 3 нод, зеркалирование запросов, чтобы оценить скорость выполнения и запустили сравнительный - мониторинг - время отклика меньше.

Проблемы

Scylla не поддерживает загрузку SSTable - заранее оптимизированных данных в памяти. В Кассандру они готовили его сами, в Scylla разработчики считали, что уязвимость. Поэтому надо загружать в БД.
Выбор правильной компакции. Scylla поддерживает 7 вариантов, попробовали всех, кром enterprise, попробовали все, выбрали leveled по тестам. Пробовали без компакции - был взрывной рост commit log, занимал все место на диске
Перекос запросов по ключам. Кассандра использует cpu, нет шардирования по ядрам. У Scylla есть шардирование, и был перекос по шардам, нагруженные треды. Надо было править приложение, чтобы ключи хорошо распределялись по шардам.
Перекос в сетевых маршрутах до ноды - шло по низкопроизводительной ветки.

Что тестировали

Восстановление данных после аварийного вывода ноды. Сравнивали с кассандрой
Потеря данных при рестрате кластера. В Кассандре была проблема когда погасла стойка - что-то из памяти потерялось. Cо Scylla это не произошло.
Деградация скорости диска. В Кассандре была, на Scylle делали стрессовую нагрузку, скорость ответа выросла в 2 раза, но осталась в пределах.
Тестирование выпадения одной ноды по сети - она была изолирована, скорость ответа кластера не деградировали
Вывод и ввод нод на горячую - в этот момент идет активный обмен между нодами, но в срок ответа сохранился

Результаты: избавились от фантомов, упростили инфраструктуру (5 нод вместо 12, пробовали 2 добавить - оказались лишние), удешевили масштабирование. ускорили загрузку - 7-8 часов вместо 12, избавились от пиков. В целом Scylla обходится в 1.5 раза дешевле при лучших характеристиках.

Проблемы эксплуатации. Мониторинг. Scylla дает 1500 метрик на каждый сервер, которые в развертке по времени превращаются в 150к точек, Prometheus не очень хорошо себя с этим чувствует, все метрики нужны. Надо ограничивать CPU и память, иначе она заберет все, и все убьет. Не усмотрели за диском - тоже надо, чтобы не сожрала весь диск и ушла в аварию.

После доклада - много вопросов, на такой переезд смотрят многие.

Дарья Петрова. Цифровизация бизнеса на базе Jira: от сейла до бухгалтера

Рассказ о том, как Jira из инструмента разработчика сначала стала использоваться для управления проектами (пилоты и внедрение), затем охватило остальные отделы - бухгалтерия, юристы, а затем - заменила CRM. Драйвером первого этапа была интеграция проектных задач с задачами разработки, которые обеспечивают их выполнение. При этом потребовался технологический отдел, который бы прорабатывал технологичное использование Jira, обеспечивал потребности пользователей, так как там не очевидные решения и надо сопрягать потребности разных команд.

Когда топы начали видеть проекты в Jira у них было желание подтянуть туда все процессы компании. Но административно это не сработало, не взлетало. Путь был иным, через success story. сделали в Jira внутренний Service Desk и управление потоком кандидатов - там были готовы меняться. Процессы затрагивали все отделы, и попробовав работать с ними, другие отделы тоже захотели для своих задач. Ведение задачи в Jira стало частью корпоративной культуры.

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

И последний такт - продажи, там была своя CRM. Большинство CRM - на большой поток коротких продаж, а у них поток невелик, а продажи длинные, до трех лет. Сначала был Excel, по мере роста Мегаплан, Битрикс, в 2017 выбрали Zoho CRM, но проблемы с аналитикой везде были, и Excel сохранялся как параллельная штука. При этом внутри продажи запускаются пилоты и проект внедрения, это - в Jira. Проблема двух систем - систем - ручной перенос, у сейлов нет доступа к задачам разработки, а у Product Owner не было доступа к CRM. Плюс Zoho CRM - облако, там проблемы. B 2020 еще раз анализ. CRM - под потоковые продажи, SalesForce - очень дорого и много лишнего. А в 2021 году коммерческий директор понял, что все остальные - в Jira, увидел аналитические отчеты, которых ему не хватало - и решился на переход. Они с Jira сделали интерфейсы под account manager, визуально аналогичные проектному менеджменту (она показывала скрины) и аналитику по воронкам продаж. Разработка CRM в Jira - 650тр, это полгода использования Zoho.

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

Евгений Лукин. Как не провалить импортозамещение. Меняли в Сбере шину данных, а сделали платформу

На входе - MQ на IBM Web Sphera. Отдельные команды интеграции - перегружены - задача от постановки в очередь до решения 1 год при длительности выполнения 5-7 часов. А еще - централизованное решение перестало работать даже на топовом сервере, потребовалось много шин под разные данные и выросла сложность.

Идея: принципиально изменить способ интеграции, чтобы ее могли делать сами разработчики, и отдельных команд интеграции было не нужно. Взяли Service Mesh. Интеграция описывается через Yaml-конфигурации, и могут делать сами команды разработки. Это было в идеале, а на практике разработчикам надо было научиться писать Yaml и это оказалось сложно, Yaml реально много. Они начали обучать, но этого не хватало. Сделали внутренний dev-портал, где разработчик начинает разработку. dev-труба, sizing, готовые схемы интеграции. SyMPLe. B Yaml-файлики автоматом генеряться, какая-то тестовая интеграция уже ходит.

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

И дальше было много разных доработок. Горизонтальное масштабирование. В теории можно растягивать на кластер, а потом - освобождать. На практике старт - по использованию CPU. Но старт подов - дорого до 40 секунд и ресурсоемко. А вот на Go - старт быстрый. И по производительности тоже. В результате ключевые компоненты, в частности адаптер MQ переписали на Go.

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

Плата ресурсами за надежность. Два дата-центра и балансировщик. И в каждом ЦОД под должен быть поднят, а лучше два для дублирования, потому что между дата-центрами не перекидывают трафик - и получается дорого. Перешли на Federated Super Mesh. В результате если в одном ЦОД упало, трафик перенаправят в другой - можно не дублировать.

Стандартного OpenSource в Enterprise не хватает. Например, визуализация подтянула все связи кластера - out of memory. Или service mesh - рассылает все файлики всем, а у вас 10к сервисов и файликов - надо рассылать умнее.

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

Резюме - совмещайте импортозамещение с решением архитектурных проблем.

Даниил Разумов. Общий флоу разработки в Ozon. Как сделать жизнь разработчиков проще?

Идея проста: flow доставки приложения на тест, а затем - на прод - достаточно сложная конструкция. Поэтому при множестве сервисов эффективно сделать стандартные потоки, которые настраивают специалист, которыми бы пользовались все команды. Это они и сделали, около 40 вариантов flow собраны в проект в git, и в проект включают подходящий. Но это потребовало определенной стандартизации процесса разработки - всегда в feature-ветке, с процессами тестирования и стандартизации состояний в jira, так как проход по flow должен отражаться в движении тикетов в jira, например, первый комментарий с тикетом - сигнал к переходу в InProgress, merge request feature-brahch синхронизован с переходом в InReview и так далее. Синхронизация с jira особенно важна на конечных этапах, когда релиз со многими задачами движется целиком.

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

Анастасия Абрашитова из Яндекса. Вторая космическая: как преодолеть притяжение внутренней платформы разработки и выйти в открытый код

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

Какой код кладем. Граф зависимостей - он может быть сложным и меняется. И при выкладке надо еще проверить, что в проект не включили зависимость от того, что выкладывать нельзя. И от ограничений проект может сломаться.
Кроме кода есть тесты, тестовые данные, лицензии и многое другое.
Выкладывать только мастер, или какие-то ветки тоже? Когда выкладывать - по каждому коммиту, или как-то еще.
Как указывать авторов коммита? Можно по рабочей почте - но пока кто-то не захочет использовать личный аккаунт на github, или кто-то не попросит не светить Имя-Фамилию, которые в личной почте
Комментарии в коммитах. Их надо чистить, за ними следить - ссылки, конфиденциальная информация. При чем это коммиты не только в выкладываемом проекте, но и в тех, которые он использует - а они могут содержать внутренние цели.
CI/CD. Люди хотят собирать стандартно. Никто не хочет брать вашу собственную систему сборки, даже если она выложена. Поэтому нужен экспорт тестов.
Тестировать тоже хотят общепринятыми способами.
Проверка в выложенной версии open source проекте по CI/CD. Могут быть ошибки, их надо чинить, письма счастья прилетают разработчикам, которые делают внутренние вещи...
Обратный ход - когда кто-то из внешних контрибуторов доработал проект. Нужна проверка во внешнем мире, дальше надо привезти, ваши тесты могут сломаться, надо как-то чинить.
А еще работу контрибуторов надо как-то юридически оформить.
И надо пиарить чтобы использовали. Просто выложить - не работает.

Профит

Развитие проекта
Устранение технического долга
Популярность компании
Привлечение внешних людей к разработке. Хотя это не сразу и не просто
Помогает найму.

А в дальнейшем - самостоятельно коммерческому успеху продукта.

Георгий Тарасов. Эволюция распределенных атак в Интернете: 1994 — настоящее время

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

Saint Teamlead

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

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

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

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

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

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

Виталий Леонов. Приборная панель тимлида. Как оцифровать все и спать спокойно

В докладе - подробно рассказан набор метрик, которые показывают здоровье команды по трем направлениям: техническое качество, процессы, команда. Метрики в целом хорошо известны: стоимость инфраструктуры на пользователя, среднее время отклика, cumulative flow diagram, lead time for changes, текучесть сотрудников, скорость онбординга и так далее. Так что ценность тут, скорее, про то, что дан некоторый исчерпывающий список, которого достаточно. Но вот выбор именно таких метрик - раскрыт слабо, при том, что метрик довольно много.

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

Никита Логинов. Мышление эксперта. Как опытные специалисты принимают решения

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

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

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

А дальше - конспект, потому что интересного много.

Что именно отличает эксперта от новичка.

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

Примеры, которые считаются универсальными.

Постановка точных диагнозов в медицине. Не-специалисты - студенты - закончившие обучение - 10 лет работы. Число точных диагнозов с профессионализмом возрастает, ожидаемо. Интересно: через 10 минут просят вспомнить кейс - оказывается, что эксперты кейс быстро забывают, в отличие от предыдущих. А это значит, что эксперты работают на интуиции, а не на рациональном мышлении. Я: отчасти понятно, но именно как вывод из пары метрик - сомнителен. У экспертов много неосознанного знания, но при объяснении экспертности они это рационализируют, а дальше пишут книги про success story - в них получается ложь. Есть исследования, как можно нащупать пути передачи опыта, например, моторными датчиками меряем напряжение мышц опытного пианиста, а потом электродами стимулируем мышцы новичков - оно работает. Или фокусировкой внимания по траектории глаз эксперта - эффективность новичка повышается.

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

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

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

Другой кейс - диктатор-бургомистр в маленьком немецком городе Лоххаузен. Хорошие бургомистр отличались следующим.

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

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

Тезис про снятие ограничений как источник инсайтов иллюстрирован языковыми головоломками

Два человека 5 раз сыграли в шашки, каждый выиграл четное количество раз, ни разу не сыграли вничью. Ответ - играли не только друг с другом
Экстрасенс Джим может предсказать счет любого хоккейного матча до его начала. Как? Ответ: очень просто, счет до начала любого матча - 0:0.
Хомяк может съесть килограмм овса, а лошадь - нет. Почему? Ответ: хомяк не может съесть лошадь.

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

Феномен выученной беспомощности. Люди, обладая компетентностью для решения задачи, не позволяют себе это сделать из-за предыдущего негативного опыта.

В основе. Есть неявная классификация области: какие области мы считаем стабильными, а какие - изменчивыми, где можно работать.

Интеллект: фиксированный - наращиваемый
Личность: фиксированная - изменчивая
Эмоции: неконтролируемые - контролируемые
Отношения: судьба - работаем с этим
И т..д

И это дает неявные установки, которые нас ограничивают.

Пути формирования экспертности.

Доктрина формальных дисциплин - латынь, шахматы помогут интеллекту. Ответ - в большинстве случаев - не помогут. Стратегическое мышление в шахматах оказывается привязанным к шахматам.
Когнитивные тренировки - всякие геймифицированные упражнения, например, паровозики возить или lumosity. Тоже за пределами игры это не влияет, не память, ни что другое.
Длительное научение в локальной профессиональной области. Накапливаем опыт в своей области много лет. Он ведет к цели.
Развитие метакогнитивной осознанности. Тренировка осознанных способов переносов опыта между областями. Менее надежный, но дает эффект.

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

Книга Expertise and Expert Performance (Cambridge, группа авторов)

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

Олег Балбеков из Evrone. Забота компании о сотрудниках — это измеримый показатель

Как организовать заботу, автоматизировать и правильно считать ее на масштабах сотен человек. Забота - это польза, которую компания нанесла сотрудникам. Деньги, внимание ,сервисы. Подарок на день рождения, митап, решение проблем выгорания, выявленных на 1:1. Забота повышает лояльность. В компании 29 видов забот наносят разные отделы. На этих масштабах хорошо бы это измерять - сколько заботы нанесли всего, что никто из сотрудников заботой не обделен и никто не потребляет чрезмерно.

Для измерения сделали информационную систему. Любое нанесение заботы - touchpoint, точка касания. Каждый имеет 3 характеристики: польза сотрудника, стоимость в деньгах, уровень эмоций - все оценили в баллах 0-10, эмоции оценила группа экспертов, на слайде - примеры. Интересно, что стоимость для компании прибавляют, а не вычитают, и для этого показателя выгодно заботиться дорого - но ограниченность бюджета побуждает заботиться эффективно. Любой touchpoint фиксируется - и обновляется индекс заботы. Большинство данных обновляется автоматом, так как фиксируется в ERP. На слайдах виды заботы по категориям: знания (митапы, конференции, обучение), развлечения, компенсация и рост (премии, грейды), поддержка (фидбеки по программе роста, one2one, смена проекта).

Недостаточно просто суммировать touchpoints. Нужен показатель, чувствительный ко времени. И тут аналог из игр, где у каждого персонажа есть мана, она тратится на выполнение работ и пополняется за счет заботы. Каждый рабочий день уменьшает ману. Гипотеза: если мана есть - сотрудник лоялен.

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

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

Юрий Сиволап. Психиатрия в обыденных ситуациях

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

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

Юлия Аравина. 6 «мягких» навыков для того, чтобы не разрушаться в кризис

Практический доклад о том, как можно держать себя в кризисной ситуации. Основа - методика Хэррис. Навыки:

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

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

Техника Стоп (STOP). Надо остановить физически всю текучку. Сделать шаг назад - отделиться от ситуации. Выписать что чувствуйте. Отделите факты от тревоги. Осмотритесь вокруг, осознайте где и что делаете. Поступайте осознанно - какие действия эффективны.
Поддерживать контакт с настоящим. Гибко управлять вниманием - никакой эзотерики. Внимание к телесным ощущениям. 5-4-3-2-1: найти 5 (красных) вещей, 4 текстуры, 3 звука, два вкуса, один запах - это способ остановки тревожности.
Сменить тон внутреннего диалога. Замечать, когда включается радио-безнадега. Найти не только критикующую, но и поддерживающую
Отключить режим борьбы со своим состоянием. Не "соберись, тряпка". Принимать и переживать то, что чувствуем - даем на это время. Отделить круг влияния от круга забот: есть то на что влиять не можем, и есть то, на что можем повлиять, и разнести по ним мысли. Наши ценности всегда с нами.
Отделиться от негативных мыслей. Которые затапливают, и тянут в яму. Тут надо отпустить веревку, за которую нас тянут. Это же наши мысли. Их нельзя перестать думать, но они - наши. Не "я - неудачник и все пропало", а "мой мозг подкидывают мысль, что все пропало и лучше не будет". Выход в позицию наблюдателя.
Нащупать ценности. Представить себя через 10 лет и, оглядываясь на ситуацию; понять о чем сожалеешь; какой опыт хочешь получить (борьбу здесь или в чужой стране); поисследовать боль и причины; подумать, что бы хотел услышать на 90 лет;
Идти к ценностям: что отдаляет от ценностей (например, постоянное откладывание важного); что приближает (обсуждаю с другими, обращаюсь психологу). Последствия (долгосрочные и краткосрочные) этих действий.
Главный вопрос: что нам стоит борьба с внутренними желаниями? Какую цену мы платим за то, что делаем не то, что хочется.

Что делали команды и компании

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

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

Кирилл Бобрик из ЦФТ. Менеджмент vs Разработка: причины конфликтов и как их преодолевать

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

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

Правила:

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

Обязательства

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

В результате получилась хорошая система работы с бизнесом. Исчез фактор стресса.

Потом был второй такт, работа с TTM. Структурировали, там две больших части: Разработка и Согласование юридической части - оно ПОСЛЕ разработки, а может потребовать переработки. С этим пока ничего не сделали. А свою часть поменяли.

Правило: всегда нарезаем задачу на куски, логически законченный инкремент, несущий ценность.
Обязательства: стремимся поставить ценность за 2 спринта (1 месяц).

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

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

Как резюме. для преодоления конфликта

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

Илья Прахт. На работу как на праздник — как сделать так, чтобы сотрудники кайфовали на своих проектах

Компания Lineate, 150 человек, 30 проектов одновременно, работа на рынки Штатов и Европы, головной офис в Нью-Йорке, 2 офиса разработки в России, теперь 3 новых офиса - Армения, Польша, и выходят на рынок России. До ковида была матричная структура - people mаnаgement - функциональные подразделения, delivery - проектный офис. Люди реально счастливые, они это измеряли, и не было проблем с наймом при средней зарплате, текучка меньше 10% в квартал. Но дорогой менеджмент - утилизация 60-70%, 30+% на менеджмент. Когда пришел ковид - заказчики начали отваливаться, были проблемы и перестала сходиться экономика из-за дорого менеджмента. Они перешли от матричной структуры на проектное управление, убрали много дополнительных активностей, менеджмент стал всего 5+% и 90+% утилизации, но люди стали недовольны - много запросов на ротацию, текучка до 30% в квартал. Они поняли, что нужна компенсация и сделали систему пипл-менеджмента, и счастье сотрудников вернулось, при этом затраты на менеджмент выросли не так сильно, сейчас 10+%. О деталях и был рассказ.

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

тим-мораль, форма с вопросами, заполняется сотрудником. И нет субъективности - но заполняемость 30%. 2-3 раза в квартал. Галочка "хочу ротацию". Нужен модератор - рассылает, пингует не заполнивших, анализ. Форма есть в презентации, вопросы Хочу работать, Приношу пользу и так далее, оценка в баллах.
people status - руководителем или hr, после вопросов на 1:1. Заполняемость выше, но данные - субъективные и тут сложность. 3 показателя: лояльность к компании, удовлетворенность проектом, оценка компанией качества работы. 6 бальная шкала. Эскалация и исторический тренд при изменениях. Проблема с приватностью данных: когда тимлид меняется - надо старое спрятать.

Что меняли в пипл-менеджмент

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

Улучшения стаффинга: процесс ротации, сделали, чтобы люди работали на интересные задачи.

Ротация:

Разгребли бэклог запросов на ротации - сделали по каждой план со сроками
Составили планы по заблокированным сотрудникам, например, тимлиды, которых заказчик любит. Часто они и сами не хотят, но при этом уперлись в потолок и без ротации не получится
Вывели тех, кому не нравится, поставили тех, кому нравится
Прозрачная ротация: галочка "хочу ротацию" для инициации, SLA на ротацию - 1-6 месяцев, целевой 3 месяца; update по статусу ротации с каждым; четкие критерии, когда можно, и когда нельзя. Зависит от взаимоотношений с клиентом, менять команду можно не в произвольный момент, а менять половину команды - вообще нельзя.

Интересность проектов

популяризировать проекты, перекрестная информация про разные проекты: рейтинг интереса проектов, ярмарки проектов, дайджесты, реклама работы наружу
сделали проекты технически интереснее: внутренние процессы; убрали проблемы (bottleneck на приемки, over commitment - много типичных); поиск технических улучшений
компенсировали дискомфорт: многие молчат - не молчите; сделали чтобы цели ИПР были достижимы в проекте; разделили техническую и тимлидскую метку; сделали нравится/не нравится для скиллов и начали учитывать при распределении работ и учет целей; добавили финансовую мотивацию за работу в неудобные часы; бонусы за длительный вход в проект, в которые заходишь надолго.

Инструмент Technical summaries: инфо о клиенте, проблема, что сделали, почему интересно, результат, технологии, крутые вызовы, которые решили. Можно писать по каждой проблеме. Пишет кто-то их команды - тимлид или разработчик. И это - классная заготовка для маркетинга (на американский рынок). Поставлено на поток, 5-10 summary за квартал. 30 за год при 30 одновременных проектов. Очень влияет на мотивацию команды - они же сами пишут и гордятся проектом.

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

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

За реорганизацию 6+ месяцев - довольные сотрудники (5 из 6), интересность проектов (5 из 6), запросы на ротацию 2-3 в месяц, текучка 10-15% в квартал, средняя по отрасли.

Ван Хачатрян из Ozon. Как делать звезд, а не нанимать их

Основной тезис доклада: в любой команде нужны звезды - сверхпродуктивные сотрудники, способные драйвить команду. Если их получается нанять - хорошо, но это сложно и тогда их стоит растить внутри. Не из каждого сотрудника, но из одного-двух, а когда они выходят на этап самостоятельного роста - переключаться на следующих, это должен быть процесс. Потому что молодые (20-25) работают в команде 1.5 года, и потому звезды нужны новые. Да , с ними сложнее, но плюсов больше чем минусов, это разобрано.

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

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

Как их растить? Есть базис.

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

Не всегда можно обеспечить все 5 позиций, по разным причинам. Но это и не нужно - разным сотрудникам важны разные позиции, так что надо выбрать несколько, на них опираться и их прокачивать. При этом есть уровень must have, и если там провал надо устранять, и есть драйверы.

Эрик Бурыгин и Виталий Качановский. Как я перестал бояться общаться с руководителем

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

Какие трудности?

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

Как общаться эффективно

Ощущение безопасности и доверие. Будьте честны с собой, руководителем и окружающими. Придерживайтесь общей точки зрения. Не щемите руководителя. Советуйтесь. Например, когда решаете все переписать.
Уточняйте ожидания. Не стоит переносить прошлый опыт других компаний или другого руководителя на этом месте.
Проявляй инициативу, приходи с идеями. Не надо ждать, пока к вам придут.
Четко формулируй цели и запросы. Не просто развиваться, а куда именно, или какие запросы.
Спрашивая Почему и Зачем. Особенно когда мутная задача - может, не надо будет делать, а может важность поймешь. А не страдать полгода, делая непонятно что непонятно зачем
С руководителем можно не соглашаться. Но лучше 1:1 или в узком круге, а не публично. Аргументируйте позицию. Не переходите на личности, вы не согласные не с руководителем, а с его решением.
Готовьтесь к 1:1 - о чем я хочу поговорить. Если нет - инициируй самостоятельно. Пишите повестку - тупой карандаш острее умной памяти
Неформальное общение рулит - кофе, смалталк. Но чем больше общаетесь - тем больше секретов можете узнать.
Используйте типологии людей. MBTI, DISC - их тысячи. Выписываете паттерны и экспериментируйте. Найдете ключик.
Главный помощник - практика.
И просто говори. Пока не пойдете и скажете - не поможет. Часто ждем, когда кто-то другой начнет.

Когда начинать? Чем раньше - тем лучше. А если распределенная команда? Zoom рулит: можно в настолки играть, чай пить. У одного из них есть встреча 1.5 часа по не-рабочим вопросам.

Артур Орлов. Дебажим коммуникацию: протоколы общения человеков

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

Disclaimer: Если рассказанное противоречит тому, что вы знаете - вспомните 4 закон Артура Кларка: для любого эксперта существует аналогичный с противоположной точкой зрения - мне очень понравился.

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

Ключевые вопросы коммуникации: Какой результат, Чего ради и какой ценой, Как я пойму, что достиг.

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

Коммуникация - обмен сообщениями, двухсторонний, (реже 3-4, больше - разваливается на парные), асинхронный. Кажется, что часто синхронный диалог - но это отдельный навык, а когда двое кричат друг на друга - никакого диалога. Мультиканальный вербальная и невербальная; информационная и эмоциональная составляющая (факт и отношение к нему). Эмоции чаще передают невербально, но это не обязательно так. Далее - про вербальную историю. Невербальная - отдельные тренинги.

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

Синхронизация контекстов.

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

Виды потерь информации.

Обобщение. Все, всегда, никогда, как обычно. На практике есть конкретная ситуация.
Упущение. Лучше, Хуже, Самый, Сложно, Надо, Невозможно, Не сработает - какие основания, почему лучше. Невозможно обычно - я не знаю способа. Задача "оптимизировать" - по каким критериям, а то увеличили скорость, а надо было уменьшить память.
Искажение. Номинализация (глагол превращается в существительное, рефакторинг или техдолг), Форма глагола (сделать что-то или поработать над чем-то (бесконечно)).

Как восстанавливать.

Разделять: вы понимаете или у вас иллюзия понимания.
Анализ структуры речи до содержания. По форме можно многое понять. Слышишь "это лучше" - спрашиваешь критерии
Восстанавливать пропущенное (критерии сравнения, убеждения, ценности) - почему считаем так, а не иначе, кому ты должен
Приводить к разделяемым критериям - факты, по которым мы будем согласны.
Бонус: видеть карту мира говорящего. Вы будете понимать, что ему важно.

Ключевые идеи доклад.

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

Чек-лист на коммуникацию.

Понимать чтобы что. Зачем я в этой коммуникации. Выплеснуть эмоции - нужен ли собеседник.
Подстроиться под человека, попасть в его ритм и его цели.
Передача на языке собеседника
Сверка понимания. Ты задачу понял, скажи как - не слишком хорошо, лучше "Давай сверимся, я хочу понять, правильно ли рассказал"
Восстановление информации. Хочешь-то ты чего? Каковы цели другого

Анастасия Артамонова. 10 «синдромов» в одной команде

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

Екатерина Дубровская из Газпромнефть. Изменение роли команды, от функциональных колодцев к проектной команде, как сделать рабочую команду, когда участники с разным опытом командной работе, из разных культур (из компаний с разными культурами)

Доклад про налаживание работы совместных команд из производственников и ИТ для реализации технических проектов. Культура отличается очень сильно по широкому спектру вопросов, от бытовых до экзистенциальных:

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

При этом время сработаться - ограничено, и есть недоверие к взаимодействию на входе.

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

Советы в смешанной команде

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

Советы руководителю

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

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

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

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

— Максим Цепков • 12:22, 29 сентября 2022 • нет комментариев

2022-09-29: Saint Highload и Saint Teamlead - рабочая обстановка