Короткая ссылка: Saint-2024

На прошлой неделе в Питере прошли Saint Highload-2024 и Saint Teamlead-2024. Я участвовал в обоих, публиковал заметки с докладов, и сейчас собираю отчет. Обе конференции собрали около очных 2500 участников, Highload чуть больше, а Teamlead чуть меньше. И это требовало расширения площадки. На улицу начали выходить еще в прошлом году (или в позапрошлом), заняв двор. А в этом организаторы добавили парковку, развернув на ней шатер для выступлений и для обеда, так что выступления шли в 4 залах в здании и трех шатрах на улице. Удачно, что погода благоприятствовала, супержары, как в прошлом году, и дождей не было. Еще был бункер, где можно было посмотреть трансляцию и послушать доклады через наушники, или просто посидеть в тишине. Доклады не слушали, это, возможно, было бы актуально при жестком переполнении зала, а так те, кто слушает трансляцию не ездят на конференцию, а покупают online-билет. А вот посидеть в тишине или оставить ноут заряжаться пока ты обедаешь — актуально. И такой уголок нужен на случай рабочих созвонов во время конференции.

Общее впечатление от обоих конференций мне напомнило те, которые были в Питере два года назад, в 2022. Highload сопоставим и с тем, что было в прошлом году. Я уже объяснял причину этого: в технологиях ничего принципиально нового не происходит, люди решают те же задачи теми же методами, просто чуть лучше и с вариациями. Исключение тут — резкий взлет GPT, но он еще на этапе индивидуального освоения, технологических решений с его использованием не делают. Доклады про использование в помощь разработке уже есть, и они показывают прогресс. Замечу, что не-технологические решения уже делают, на MergeConf я слушал доклад о сборке в дочке Газпромнефти на основе GPT-решений полноценного рекрутера-помощника, закрывающего полный цикл задач. Кому интересно, есть мой отчет MergeConf-2024, записей конференции нет.

Такая ситуация отрасли отражается в докладах. На нескольких из тех, что я слушал, общая конструкция: была такая-то задача, мы ее успешно сделали. Иногда дополненная «а по дороге были такие-то грабли». И вот далеко не всегда из такого доклада можно извлечь профит. даже если работаешь с аналогичной технологией. Это лишь приглашение-информация «мы работаем с такой-то технологией и задачами, можно обсудить, если интересно». В общем-то, доклад должен быть чем-то большим. И это — в условиях, когда заявок много и была конкуренция. К Teamlead это тоже относится.'

А на Teamlead в прошлом году было много крутых докладов, в том числе от известных спикеров. Среди них много докладов было по психологии. Это было очень интересно, можно посмотреть мой отчет прошлого года TeamLead-2023-Spb. Но это был такой разовый всплеск в хорошую область, в этом году его не повторили, наверное, имея ввиду ажиотаж с поданными заявками. Но, тем не менее, хороших докладов было достаточно много. Как и осенью, в рамках Teamlead шли треки KnowledgeConf и Techlead, и там тоже были интересные доклады.

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

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

А перед этим я хочу отметить отдельные доклады.

Чему нас учит черный квадрат и причем здесь программирование на Highload. Идея Олега Бунина: расширить сознание и посмотреть на другую область. Ведь разработчики похожи на художников и других людей искусства: они создают новое, меняют реальность силой мысли. Основной рассказ вел Александр Кибасов (Doctrina et Nobiles), а Олег и Вирна Штерн давали реплики и вопросы. На мой взгляд, это был интересный и полезный опыт.
Александр Зиза. Три субкультуры в IT-компаниях на Teamlead. Очень хороший рассказ о происходящих сейчас принципиальных изменениях в культуре компаний, в контексте происходящих изменений в мире в целом. Вызвал много мыслей, которые я тоже включил в конспект, отделяя от того, что сказал Александр.

Это были те два доклада, которые произвели на меня наибольшее впечатление. То, что это по одному докладу с каждой конференции — случайность, просто так получилось.

Еще несколько технических докладов с Highload

Олег Коровин. GraphQL: зачем на самом деле он нужен. Apollo Federation — дар бога. Идея в том, что GraphQL — это прорыв, она позволяет делать запросы, объединяя разные API, подобно тому, как SQL позволил делать запросы, объединяя многие таблицы. Это — моя мысль, но она родилась в ходе доклада.
Филипп Дельгядо. Enterprise deploy: почему это больно. Многогранный доклад о разных аспектах создания безопасного деплоя. В том числе — для enterprise-приложений. установленных удаленно у клиента, который сам делает обновления, и это сильно повышает требования.
Владимир Комаров из СберТех. О распределенных транзакциях. Очень хороший доклад с обзором различных механизмов распределенных баз данных и транзакций.

И ряд докладов про ИИ, тоже с Highload

Максим Метальников, Максим Смоляков из SberDevices. Особенности и вызовы реализации технологии создания готовых музыкальных произведений с применением ИИ. Ребята собрали pipeline синтеза песни из различных инструментов ИИ. Фазы pipeline: идея — текст <-> основная мелодия — аранжировка — запись вокала и инструментов — сведение и мастеринг. ИИ это все уже более-менее умеет. Правда, pipeline — не автомат, он на ручном приводе с участием человека. Но это нормально на данной стадии развития технологий.
Иван Бондаренко из НГУ. Сильный искусственный интеллект у вас в подвале: как собрать мультимодальную LLM из опенсорса и настроить ее под вашу задачу. Это всего лишь про обучение ИИ понимать картинки и звуки. А вовсе не про решение сложных задач, недоступных пока GPT. Но все равно интересно.
Алексей Цветков. Как воспитать себе помощника: применение локального ИИ для разработки. Основное для меня сообщение доклада — что можно на компе разработчика развернуть локальную версию ИИ, сопоставимую по мощности с GPT-4, Gemini, Copilot. Правда, речь шла о специализированной области разработке софта, но GPT умеет получать задания, писать комментарии и общаться на естественном языке — как разработчик.

А это — доклады с Teamlead. Вообще хочется отметить практически все доклады, которые я слушал, в каждом — своя изюминка. При этом на Teamlead я слушал меньше докладов, чем на Highload, потому что было гораздо больше нетворкинга.

Максим Смирнов. Как рассказывать архитектурные диаграммы. Рассказ о затруднениях, которые возникают при презентации архитектуры, способах их преодоления и рекомендации, как сделать хороший рассказ.
Роман Поборчий. Особенности создания внутренних сервисов в крупных компаниях, и как избежать провала. В начале этого доклада была роскошная история — что же такое провал. И содержание тоже было хорошим — про типичные ошибки, которые ведут к провалу, потому что команда не справляется.
Юлия Лукина. Как окунуться в новую предметную область и не утонуть. Ольга сменила много областей, и в докладе был рассказ о техниках погружения, доведенный до уровня чек-листа.
Антон Огородников из Mаgnit Tech. Инженерная культура. Что это и почему она важна? В докладе была конкретная инженерная культура как набор принципов, с логикой их появления. И ценность доклада не в том, что сделана выборка принципов из книги, на которую ссылался автор. Ценность в том, что эту выборку имплементировали в реальной жизни, в своей компании, понимая что делают, то есть действуя технологично. Разница примерно такая же, как между разработкой кода для решения задачи и разработкой кода с использованием шаблонов, о которых потому еще и рассказываешь в докладе, делясь своим опытом с другими.
Ольга Муттер из СберМаркет. Прозрачная структура проектов в компании от стратегии до исполнителя. Двухлетняя история выстраивания структуры, в которой команды понимают свой вклад в стратегию и действуют сообразно, и это поддержано сквозными метриками. Есть ее статья «Как подружить проектное управление с продуктовым подходом». Я хочу отметить, что 10 с небольшим лет назад я слушал доклад про то, как в Касперском ставили единообразие процессов обработки задач и отметить разнообразие подхода. Там главным была общая система и одинаковый workflow для всех типов задач, без отдельного пространства для команд, и меряли единые характеристики, а все особые случаи согласовывал комитет по изменениям уровня компании, и их на всю компанию была пара случаев. А вот речь о трассировке задач до уровня стратегии — не шла. А в этом случае задачей было обеспечить единообразное представление только на верхнем уровне, и построить трассировку до стратегии, которую обвесить метриками. С моей точки зрения, это характеризует изменения, произошедшие за это время в культуре отрасли в целом.
Александра Прокшина из Авито. Искусство спрашивать, или 42 вопроса, которые ускорят развитие вашей команды и вас самих. Очень хороший доклад из тех, в которых автор говорит вроде знакомые и известные вещи, но рассказывает это настолько хорошо, а материал так сфокусирован, что ты обновляешь у себя это в памяти, практически переоткрываешь заново. И это не только рассказ, но и презентация, где на слайде — просто вопросы, по одному или малой группой, но в них подсвечены ключевые моменты.

Saint Highload

Олег Коровин. GraphQL: зачем на самом деле он нужен. Apollo Federation — дар бога

По этому докладу у меня возникла ассоциация с историей. Когда-то давно были базы данных без SQL, только работа с таблицами, и все join надо было вручную писать в коде. Я это еще застал. Потом пришел SQL и проблема была решена. Сейчас это повторяется: микросервисная архитектура разложила объекты о сервисами, для каждого есть свой набор API. GrapgQL позволяет объединять данные из разных узлов в единую схему и делать общие запросы. При этом тогда разработчики относились к появившемуся SQL настороженно: это же накладные расходы, сложно и непривычно. Так и сейчас к GraphQL относятся настороженно как к хипстерской поделке, которая не нужна «настоящим программистам» — OpenAPI достаточно. Докладчик показывал, как GraphQL решает проблемы, сокращает объем кода, делает его более компактным. А также — как решаются проблемы контроля доступа, единой точки отказа и безопасности. Решение GraphQL — легкое и масштабируемое, федерации — stateless, и можно поднимать разные федерации для разных клиентов, подключая только необходимые им сервисные данные. И страивать параллельный доступ для миграции, поднимая федерацию для доступа, но запуская через нее только новые запросы. Тут ситуация выгодно отличается от того, что было с миграцией на SQL-базы данных — там это можно было сделать только целиком. На мой взгляд, получился очень удачный доклад.

Роман Щербаков из Тинькофф. Пайплайны записи своими руками: думали — велосипед, оказалось — паттерны

Рассказ об организации высокой доступности для инфраструктурных потоков: логов, метрик, трейсов. 450 Мб/сек. Целевые хранилища там разные, а архитектура — общая. В докладе — много архитектурных схем, это надо смотреть презентацию. А тут мое краткое резюме принципов.

Данные пишутся в том же дата-центре, в котором создаются, то есть в каждом — свой набор pipeline, и там же они остывают. А поиск — по всем датацентрам.
Надо вести мониторинг обращений клиентов и уметь отделять тех, у кого особая нагрузка в отдельный pipeline, с которым отдельно разбираться.
Worker записи от клиента пишет в Kafka, из которой читает Worker записи в хранилище. И worker записи работает в том темпе, в котором комфортно для БД. Kafka буферизует колебания нагрузки записи. А worker записи делает пакетную запись.
Отказ операции — нормально. Особые случаи откидываем в отдельную retry-очередь, а если retry не проходит — в очередь ошибок, с которой разбираются вручную. Retry однократный, он на случай, если что-то моргнуло, а если что-то упало — то retry вреден. И такая схема обеспечивает оперативное поступление данных, с которыми все хорошо.
Если база или узел деградировал — его надо отрубить, для этого фиксировать, что пошли массовые ошибки, для этого Circuit breaking pattern. Аналогично работает bulkhead pattern — ограничение на конкурентные обращения. Это бережет БД.
Таймауты надо настраивать. Есть бюджет обработки от кафки — таймаут опроса очереди, при превышении которого она считает, что consumer отвалился, и в него надо укладываться, включая все таймауты. И для основного потока там жесткие настройки, а для retry и ошибок — свои.
Для метрик основной поток пущен напрямую, без kafka, так как на стороне клиента обычно prometheus и у него есть свои буфера. И это экономит. Но при деградации — включается полная схема.

Николай Никитин из ИТМО. Как обеспечить воспроизводимость научных исследований в AI/ML с помощью Open Source?

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

Для Николая это тезис очевиден, в то время, как в социальных реалиях современной науки это далеко не так. Если же принять этот тезис, то для современных исследований, особенно в области AI/ML, просто публикации статьи недостаточно, к статье должен прилагаться код и наборы данных, которые обеспечат легкое использование результатов, включая его проверку, но не ограничиваясь ей.

В open source есть площадки для этого. Но ученые — не программисты, разработка и создание open source для них — не профильная работа, получается довольно высокий порог входа, который полезно снизить. Они в 2020 годы в ИТМО начали это делать, и сейчас у них 10+ различных проектов. Был более подробный рассказ про фреймворк FEDOT. Тут есть особенности, связанные с тем, что есть 2-3 человека в ядре команды и ассоциированные стажры, которые делают студенческие работы. Но для успеха ядро должно быть увлеченным, в том числе проводить менторинг для студентов — и административно это не масштабируется. Такие проекты делают пиар, показывают что университет способен достигать серьезных результатов. Однако, несмотря на это уровень энтузиазма довольно велик. Тут есть вопрос финансирования, если на новые версии его еще можно получить, то на поддержку — не получается. Но сейчас есть возможность получить гранты, и то, что продуктом будет не просто публикация, а open source эксперты оценивают. И коммерческие компании тоже становятся толерантными к выкладке результатов в open source, хотя тут это каждый раз вопрос переговоров.

Лично я желаю ИТМО всяческих успехов, и надеюсь, что этот опыт будет распространяться. Для интересующихся — есть сообщество в телеграме https://t.me/itmo_opensource

Иван Чернов (Островок). Как работать с поставщиками на примере поиска доступных отелей

Чем отличается Островок от Букинга? В силу своей позиции на рынке букинг может от отелей потребовать работать в своей админке, описывать там условия отелей, и резервирование проводить внутри. А еще у него каждый отель представлен однократно. Хотя у каждого отеля есть своя система управления номерами, они очень разные, но проблемы интеграции их с букингом он отдает отелю. Островок сейчас работает как агрегатор, отели продаются через разные каналы, островок все это забирает и предлагает наиболее выгодные цены. В им надо при резервировании получать подтверждение отеля. А еще им важно кешировать запросы, чтобы сокращать число обращений к системам отелей. При этом учитывать, что данные устаревают. Динамика не столь высокая, как для динамического ценообразования в такси, но довольно высокая, при этом сильно различается в зависимости от спроса на конкретный период. При этом у отелей свое ценообразование, для раннего заказа могут быть скидки, для длинных сроков проживания тоже, плюс посредники, предлагающие отели, предлагают скидки по своим правилам. То есть ключ запроса — длинный, включает много данных.

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

Максим Метальников, Максим Смоляков из SberDevices. Особенности и вызовы реализации технологии создания готовых музыкальных произведений с применением ИИ

Ребята собрали pipeline синтеза песни из различных инструментов ИИ. Фазы pipeline: идея — текст <-> основная мелодия — аранжировка — запись вокала и инструментов — сведение и мастеринг. Все это ИИ уже более-менее умеет. Правда, pipeline — не автомат, он на ручном приводе с участием человека. Но это нормально на данной стадии развития технологий.

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

Филипп Дельгядо. Enterprise deploy: почему это больно

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

Когда-то были монолиты, которые для обновлений останавливали. Сейчас у нас много экземпляров серверов, которые работают с общей базой данных, которая тоже может быть в нескольких экземплярах, и остановить работу для изменения невозможно. Изменения правильно делить не на совместимые и несовместимые, а по безопасности: почти безопасные, возможно опасные и точно опасные. Создать новую таблицу — безопасно. Добавить поле — практически безопасно, но требует краткой блокировки таблицы, и на смеси olap и oltp транзакций под высокой нагрузкой это может выстрелить: oltp задержат дольше допустимого. А создание индекса во многих базах блокирует таблицу надолго, а в PostgreSQL есть специальные методы, как это сделать безопасно, ими надо владеть. Добавление нового значения в enum — опасность больше, надо разбираться с работой старых сервисов с объектами, у которых новое значение. Может быть, что такие записи в них в принципе не попадут, но это всегда не точно.

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

Теперь от базы данных к взаимодействию сервисов. В случае синхронного взаимодействия (http, grpc) применяем:

Версионирование по методам, а не целиком.
Изменения окружаем флагами для контроля нового поведения
Используем только безопасные изменения внутри endpoint
Маршрутизация запросов — чтобы метод получал только понятное
Контроль жизненного цикла: состояния draft, unstable, deprecated. C разными обязательствами.
Нужен инструмент управление фича-флагами: рассылка по сервисам, контроль зависимостей, канареечные флаги вместо разнесения по узлам сети, удаление неактуальных флагов

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

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

А еще — можно не делать асинхронное. Вам нужно сглаживать пики — уберите этот буфер внутрь сервиса, а не располагайте между.

Документация: политики совместимости, сценарии обновления, взаимодействия, особенно неформальные, поверх архитектуры. Тесты: процесса миграции (непросто, это end2end с фоном), частичной работоспособности, откат обновлений Инструменты: менеджер миграций, управление фича-флагми, управление выкладкой (подождать полчаса и посмотреть логи). Можно делать обновление поверх jenkins, но им пришлось сделать свое — они не могут потребовать от клиентов поставить и сопровождать Jenkins

Чему нас учит черный квадрат и причем здесь программирование

Это была идея Олега Бунина: расширить сознание и посмотреть на другую область. Основной рассказ вел Александр Кибасов (Doctrina et Nobiles), а Олег и Вирна Штерн давали реплики и вопросы. А тема Малевича была выбрана потому, что онтико использует стиль супрематизма в оформлении презентаций, а с этого года еще начала делать сувенирку — матрешки, расписанные в этом стиле, как приз за лучшие вопросы, докладчикам и членам ПК.

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

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

До Малевича искусство — это голые или обнаженные женщины, пейзажи или сюжеты с персонажами, и для понимания предполагалось знание контекста. Малевич черным квадратом сломал этот стереотип, и сделал искусство без явного смысла и контекста, а для прямого восприятия.
Искусство предназначено для созерцания, а не для интерпретаций и смыслов. Оно не должно иметь смысла, и это — правильно. Идея бессмысленного жеста — спасительна. Потому что жизнь полна смысла. В чем смысл жизни? Конечно, чтобы ходить к вам на работу. Искусство без смысла разрывает такую логику.
Искусство без смысла, для созерцания — слом мира мещан, которые везде искали смысл, потому что так принято.
Черный квадрат сломал элитарность художников: черный квадрат может нарисовать любой, он не требует мастерства. При том, что у Малевича мастерство — было.
В те времена Петербургская и Московская академии каждый год выпускали художников с классическим подходом, их было много. Черный квадрат ломал традицию.
Были последователи, ученики и те, кто тоже творил и творит в том стиле. Есть художник, который рисует синие картины, просто закрашивает одним цветом, есть — кто черные, устраивают выставки.
Кандинский — как Малевич, но для тех, кто любит цвета. Вкусы различны, одним нравится кока, другим — пепси. У него еще была бредовая конструкция, как его картины работают и какие эмоции вызывают.
После Малевича было еще три соразмерных события. Фонтан Мишеля Дюшана (1917) — нестандартно повешенный писсуар: главное, идея, а создавать предмет не обязательно, можно взять готовый, мастерство не нужно вообще. Один и три стула Джозева Кошута (1965) — инсталляция: стул, его описание и его фото; идея — язык — не рабочая структура, он не передает смыслы, провал коммуникации. И Дерьмо художника Пьетро Мандзони (1961) — вообще подвешивает сферу искусства как таковую.

Теперь мои комментарии, тоже в виде тезисов.

У черного квадрата и последовавшего за ним направления супрематизма был вполне утилитарный смысл: для славы надо было отличаться от других, причем сильно. За счет мастерства это не получается, оно есть, но не экстра-уровня — значит делаем оригинально. Прием не новый, кто-то из скульпторов, творивших в Италии после возрождения ввел в моду барельефы, где фигуры едва намечены, почти рисунок на мраморе — чтобы отличаться от глубоких барельефов Возрождения, которые уже у всех были. Здесь логика — та же.
Как мне рассказали после лекции, первый черный квадрат был вполне утилитарной вещью — это часть декорации к спектаклю, где такая картина, наверное, была уместна по замыслу. А дальше — идея зацепила.
Очень забавно: Чехов критикует мещан за отсутствие смысла, а Малевич — за то, что они везде ищут смысл. Хотя тут можно понять: у тех, кого называли мещанами, понятный смысл жизни из простых человеческих радостей. Они не ищут высокого предназначения, и не признают непонятное, художнику с ними сложно. Это целенаправлено разрушали, и в 1920-е, пока основным мотивом в СССР было низвержение старого супрематизм был в почете. А потом пошли эпоха, когда потребовалось конструирование нового.
По сути, супрематизм — начало движение деконструкции смыслов. Тогда оно было в форме протестов против предписываемой традицией формы, которая застыла настолько, что тоже была лишена смысла. Но позднее, во второй половине 20 века у деконструкции появилось идеологическое обоснование, и объявлена долгом. И деконструкция искусства — часть этого мейнстрима. В этой концепции ценность искусства определяется замыслом автора и мерой его страдания, оцениваемой по его собственным заявлениям. За подробностями могут оправить в мой пост https://mtsepkov.org/Snowflake и пост https://ivanov-petrov.livejournal.com/2287616.html Это — гораздо более поздняя история, и отдельный вопрос — в каком объеме это было у Малевича, а насколько это — поздние интерпретации. Потому как сейчас любят говорить, что Достоевский воспевал страдающих, а он их не воспевал, он лишь показывал, что бедные — тоже люди, они живут и страдают также как остальные, сообщение было другим.

На этом все. В комментариях можно обсуждать подробнее. Или очно на конференциях.

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

Из обсуждения. Rinat Enikeev: Как подвести текст к первому тезису о том, что «разработчики похожи на художников»?

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

Rinat Enikeev: О, это про меня, только часто вопрос не в удобстве, а вообще в востребованности и нужности. Как говорил Маск, основная проблема инженеров в том, что они оптимизируют то, что не должно существовать.

Владимир Комаров из СберТех. О распределенных транзакциях

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

Распределенные БД — 5 вариантов.

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

Дальше рассказ про распределенные транзакции. Самое известное — протокол двухфазной фиксации. 1986 IBM System R* — протокол уже назван хорошо известным. Проблема — отказы НЕ предусмотрены: участник может пропасть, но диск — надежен, он всегда возрождается. В 1991 XA specification — все предположения зафиксированы.

Реальные диски выходят из строя. Что с этим можно сделать?

Разделяемые дисковые механизмы. SAP HANA, Microsoft PDW, Oracle Sharding + RAC (exadata), Teradata. SAP HANA — надо считать состояние, перейти на резервный надежнее, чем на основной.
Отказоустойчивость всех участников. Google Spanner.
Смириться, что можно потерять часть участников. GreenPlum. Координатор дублирован, а других узлов много, и не страшно потерять один.
При сбое разбирать последствия остальными. Apache Ignite (координирует тот, кто начал транзакцию), Hazelcast — общение и восстановление сбойной.

А еще двухфазная транзакция — два сетевых обмена, и это — время.

Однофазная транзакция. Если мы понимаем, что завершили на ответственном участнике — то на этом и закончили.

Oracle sharding — драйвер клиента
GrinGain — решение координатора транзакции
SAP HANA — координатор сообщает, к каком узлу присоединиться
Hazelcast — клиент-приложение должен завершить и отвечает, что меняет на одном узле

CockroachDB — двухфазный вариант, но вторая фаза — асинхронная. Там, где начинаются изменения, создается объект-транзакция, клиент говорит commit — этот узел спрашивает готовность, сам записывает на диск, а остальные — записывают асинхронно.

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

Ограничения подхода:

низкоконкурентная среда, потому как оптимистические блокировки.
задержки, сбор транзакций в пачку 10мс
архитектурные компромиссы и оптимизации — пакетные передачи и т. п.

YDB. добавлены компромиссы.

Между секвенсерами и участниками — медиаторы, ограничение обменов.
Разрешение на изменения порядка операций.
Слепые транзакции: когда нам не важна версия на чтении, или напрямую записываем в участника

То есть много оптимизаций, которые разработчик должен применять разумно.

Cassandra. Каждый узел сам себе секвенсер. pid+RTC (время)+логическое время. Есть лекция Осипова. Второй узел отвечает, если нет более ранних транзакций. Алгоритм существенно рассчитывает на синхронизацию часов в кластере и учет разбега.

FoundationDB — в нем распределенный менеджер блокировок. Клиент читает данные, выстраивается последовательность изменений и по commit — идем в прокси-сервер. Координатор выдает номер. Дальше прокси говорит «хочу менять ключ», кеш отвечает можно/нельзя. Блокировки протухают через 5 сек, снятие — не нужно.

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

Их подход — сага. Platform V AppSharding. Масштабирование функциональным делением. Если много данных — шардирование. Например, для клиентов — делят, хорошего алгоритма не нашли, явно делят по спискам. Клиента маршрутизируют. L7-маршрутизатор использует межкластерный индекс. Ключ (клиент, сервис), значение — шард. Переводы между клиентами разных шардов — оркестратор, с хранением в Kafka — объект короткоживущий, данные читаются только при сбое, когда восстанавливаем оркестратор.

Хореография. Прекрасна на полотнах Дега и в балете Моисеева. А в финансах — нет. В вопросах была реплика, что это — не так, на биржах -применяется активно.

Облачные БД. Amazon Aurora, Google AlloyDB, MS SQL DB Hyperscale. Облачные БД пишут журналы, а под ним — система хранения, которая накатывает журналы на страницы, в том числе несколько версий страниц, и по необходимости — отдает экземпляру. Все хорошо, кроме сложного деплоя. Доступны только как облачные сервисы.

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

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

Иван Бондаренко (НГУ) Сильный искусственный интеллект у вас в подвале: как собрать мультимодальную LLM из опенсорса и настроить ее под вашу задачу

Началось все с участия в соревновании Strong Intelligence на AIJ-2023, где надо было сделать ИИ, способный понимать картинки и звуки. Базовую LLM давали организаторы, решение надо было представить в контейнере, дальше организаторы оценивали на своих тестах. Они пошли понятным путем, собрав энкодеры из open source решений. Энкодер — два такта, перекодировка изображения или звуков в вектор параметров, а потом перекодировав вектор параметров в вектор токенов для LLM. В презентации есть подробности — что использовано.

Заняли 14 место из 30, их результат не удовлетворил. И они подумали — а что можно сделать? Анализ показал проблему: энкодеры работают независимо от контекста разговора. И появилась другая идея: сделать общую модель мира во внешней базе данных и искать в нем, создавая контекст разговора, они назвали это припоминанием знаний. Для этого использована китайская ONE-PLANE, которая связывает разные модальности и превращенная в ANNOY-вектор для поиска английская википедия. Дополнительно потребовался генератор коротких подписей к рисункам — его результат фокусирует поиск, распознаватель звуков и преобразователи для речи и других видов звуков. И уже полученный в результате текст подается на вход LLM. В докладе было разобрана механика работы на конкретном примере.

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

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

Андрей Кузнецов (AIRI) Как научить фундаментальные модели читать, видеть, слышать и анализировать все одновременно

Реально доклад был только включение картинок. Конструкция — та же самая, LLM + энкодеры, с помощью которых описание изображения помещается в общий вектор текста. При этом работает и в обратную сторону, в ответе тоже могут быть токены, описывающие изображения, по которым будет порождена картинка. Решение OmniFusion, выложено в open source в апреле. Решение — открытое, можно подключить свои распознавалки для специфических изображений, например, медицинских снимок или космических. И другие виды тоже можно подключать, на очереди аудио и видео. А еще можно добавлять графы знаний. Они таким образом добавили работу с формулами и LaTeX.

Сергей Ларионенко (Авито) OpenTelemetry и эволюция распределенного пайплайна трейсинга в Авито

Это песня о том, как, сделав пайплайн на открытых инструментах, они разбирались с потерей 70 % трейсов, расшивая узкие горла и делая форки в туле. Проблема началась с обнаружения битых трейсов. Вставили проверку на связность графа — и обнаружили что таких 70 %. Начали разбираться. Обнаружили, что на нодах следующая конструкция: много обработчиков пишут в Go-канал, а дальше этот канал вычитывается только одним потоком и передается на другую ноду. Запись в Go-канал — точка синхронизации, буфер канала ограничен. И сделано, что когда в буфер нельзя записать, то пакет просто теряется, и увеличивается статистика сбоев. Только они этого не видят, потому что статистика в конструкторе инициализирована NullFactory. А поток вычитывания работает медленно, потому что там синхронный вызов удаленный вызов по gRpc, и на приемной стороне — приличная обработка. Для решения сделали fork Otel batching, несколько процессов чтения, из которых активен один, но при исчерпании буфера переключаемся на следующий. Массовые сбои ушли, остались индивидуальные, причина — падал коллектор данных. А он падал потому, что там две процедуры: обработка очередного события и оценка, что накопленные события пора отправлять пакетом. И оказалось, что там код написан так, что при одновременном выполнении получается конфликт и все падает. Это тоже поправили. Все заработало.

Илья Иванов из Яндекс 360. Архитектура биллинга: как не стать единой точкой отказа

В докладе — архитектура биллинга. Она по факту трехслойная. Сам биллинг получает сумму, которую надо списать за услуги, выставляет счета, принимает оплату, выдает чеки и готовит отчеты. Тарификацию ведут пребиллинги, связанные с конкретными бизнесами, в них — тарифы, промоакции и промокоды. А также платежные механики — подписки или другие способы учета. Они зависят от каждого бизнеса, свои для Яндекс 360, Яндекс Плюс, Яндекс Облако и так далее, потому что каждый из них ведет свою тарифную и рекламную политику, которую надо менять независимо от других. Собственно, независимое развитие бизнесов как раз является основанием для такой архитектуры, а вовсе не соображения про точку отказа — централизованный биллинг по-прежнему им является.

Пребиллинг в Яндекс 360 переводит конкретные тарифы в наборы подключенных услуг, которые могут быть подключены индивидуально и для компании, при этом часть услуг для компании переводится в индивидуальные для сотрудников. Добавление услуги инициирует добавление для всех сотрудников, каждое добавление выполняется индивидуально и асинхронно, простая модель состояний init-sinking-actual, поэтому даже при больших организациях 10к+ человек выполняется быстро. Добавление услуги означает обращение к конкретному сервису с установкой там каких-то квот, например, объема доступного диска. И далее этот сервис работает в пределах квоты ресурсов, или количества писем. При этом одни ресурсы, например, диск, выделяются индивидуально, а другие, например количество писем в рассылках, может быть установлено общее, на всех сотрудников компании.

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

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

Алексей Цветков. Как воспитать себе помощника: применение локального ИИ для разработки

Это был рассказ о практических возможностях ИИ быть помощником по разработке. При этом, что важно, использовалась автономная версия Mistral, которая с нормальной скоростью работает локально на обычном компе разработчика (в презентации были характеристики). А по мощности она сравнима с GPT-4, Gemini, Copilot, правда в специализированной области разработке софта. Модель не зависит от конкретного языка и знает 338 разных языков. Модели загружаются с помощью ollama, рекомендуется модель codestral:22b (при подготовке он использовал предыдущую версию), и нужен плагин continue для VScode и GoLang — он позволяет обращаться из среды к провайдерам. Модель умеет из коробки строить индекс по вашему проекту и использовать его при выполнении заданий. В презентации были конкретные команды и ссылки.

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

Дальше — попытка сделать реальный проект — прототип распределенной платежной системы: сервис на Java, который получает поручения от человека и делает балансы на шардах, каждый из которых ведет баланс. Код порождался в несколько этапов, он выдавал задания. По коду была построена компонентная схема вызовов методов и диаграмма последовательности. А еще gRPC API, dockerfile для сборки, yaml для запуска, описание и схемы и тест-кейсы. Тест-кейсы — простые, но на вопрос, а что еще можно предложить, был выдан список сложных тест-кейсов: сложные, обработки ошибок, параллелизма, нагрузочное, стабильности, времени ответа, и далее можно предложить каждый их написать. Вообще это типичный способ работы: ты не сразу требуешь написать проект, а по шагам. В том числе — предложить план, а потом этот план по шагам исполняешь. Типичная работа с джуном в обучающем режиме.

Всего генерация проекта — 30 запросов к модели, 10 уточняющих. Результат 15 файлов, 3 без исправлений, а в остальных потребовались исправления человеком при отладке, но сильно меньше объема файла, всего около 5 % строк. Правда, в Java процент больше, около 15 % На слайде была детальная информация, и это выложено на github.

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

В запросе можно указывать файлы, которые добавляются в запрос для контекста. Есть API и структура БД — и модель реализует CRUD. Смотришь — нет транзакций для согласованного изменения таблиц баланса и операций. Спрашиваешь «а ты консистентно сделал?» — модель сама говорит про транзакции, и может их в код добавить.

Механизм RAG. Кодовая база разбивается на фрагменты, и модель выдает вектор смысла. embeding и индекс. Запрос тоже пропускается через embeding и модель добавляет релевантные кусочки. Например, получить весь список сервисов. И описать конкретные сервисы. Или показать, где происходит распределение счетов по шардам. И это — помощь в освоении кода незнакомого проекта.

Модель может сделать рефакторинг, тоже по шагам: сначала — какие файлы затронет, потом — что поменять в каждом из них. Для теста он попросил в проекте поменять количество шардов с 2 до 8 и получил осмысленные результаты, хотя и с ошибками.

Что локальный ИИ не может делать хорошо

Отладка сложных кейсов в runtime — для этого надо понять состояние системы в момент ошибки, а он его не знает
Ограниченный контекст. 16384 токена, у новой — на порядок больше. Но все равно есть ограничения, и по окну внимания.
Редактирование многих файлов одним запросом, надо по-одному.
Выполнение последовательности одним запросом — надо дробить на куски (но набор кусков он может предложить).

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

Saint Teamlead

Максим Смирнов. Как рассказывать архитектурные диаграммы

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

Рассказывать на реальном сложно — погружение в контекст. Есть кейсы, на которых O’Reily проводит соревнования архитекторов, варианты выкладываются на github. Если не в курсе — гуглите, это интересно. И рассказ был на кейсе Sysops Squad: гигант электроники с продажами по всей стране. При покупке — абонентское обслуживание, при проблеме специалисты приезжают.

Пять затруднений

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

Теперь про каждую.

Сложность. В примере большая c4 диаграмма, как водится с мелкими надписями. Подробно рассказать — невозможно, а перечисление типа «5 контейнеров, 8 очередей» — это не содержание!

Реально содержание архитектуры — другое

Вытащим из монолита компоненты взаимодействия с клиентами
И все их взаимодействие — через асинхронные очереди
А взаимодействие с инженерами — вторая часть
И третья и четвертая — платежи и отчетность

Его и надо рассказывать. И я отмечу, что для этого надо подготовиться заранее: раскрасить квадратики в разные цвета, возможно, сделать обводы и фоновые выделения. А может и нарисовать более крупную диаграмму для рассказа.

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

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

В алгоритмах и поведении есть развилки, а в историях — их нет. Use case решают это через основной и дополнительные ветви. И в рассказе тоже не нужно рассказывать все варианты. Расскажите основной. Я тут дополню, что часто кроме основного есть особенно интересные кейсы, обычно касающиеся того, с чем имеются или предполагаются трудности. А структура через use case еще и поможет при вопросах про детали: вы переключаетесь на дополнительную ветку, потом возвращаетесь.

Как донести замысел решения? Есть формат.

Цель: желаемый результат, целевое состояние в которое хотим понять
Что мешает достичь целевого результата просто — препятствия
Хитрость, ловкий прием чтобы преодолеть эти препятствия

Три подсказки.

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

Шаблон Y-statements

Контекст — для чего применимо архитектурное решения
Facing — для каких требований архитектура, что мешает просто взять и сделать
we decided — что решили
and neglected — от чего отказались
we achieve — что мы достигнем
accepting what — какую цену заплатим

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

Зачем обсуждать альтернативы? Тут пример домика: дешево и быстро, быстро и дорого, дорого и хорошо, слишком хорошо. Мы проектируем индивидуально, не вовлекая заказчика. И он далеко не всегда специалист. Но если мы предлагаем варианты — то получается пространство выбора. И критерии могут быть различны.

B конце презентации был канвас для рассказа, он опубликован на канале Максима http://t.me/it_arch, посвященному архитектуре.

Александр Зиза. Три субкультуры в IT-компаниях

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

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

До субкультур надо поговорить про культуру ИТ-компаний в целом. И это — важно, хотя многие руководители говорят «вы мне практик дайте, не надо про культуру». Я замечу, что такие руководители просто не понимают, насколько у людей различается мышление, и насколько это мышление влияет на жизнь и поведение людей. При этом про себя они бычно это понимают, а вот других считают не такими, как они сами (иначе им бы не были нужны практики управления) — основная ошибка атрибуции. Впрочем, может, они и про себя понимают, и им нужны практики не только для других, но и для себя.

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

Ограничивающие убеждения, система-1 и система-2 Канемана в мышлении.
Культура цивилизаций. Тойнби: цивилизация это культура. Запад: мышление и коммуникации между равным позициями, Россия — эмоциональное присоединение. Интернет, платформы, чаты — про организацию коммуникаций. Выстраивание отношений — это не про коммуникации, отношения бывают деловые и не деловые — разные.
Культура как культура быта, артефакты. Они впитаны.
Организационная культура — инструменты спиральной динамики.
Индустрия в цифровом торнадо (digidal tornado). Каждая индустрия в разных ситуациях.
Организационные субкультуры. DevOps, продуктовый подход.

Каждый viewpoint дает фрагментированное представление, надо собирать целое.

Безработица 2,7 %, для нормального рынка труда нужно 6-7 %. В ИТ не хватает 45 % специалистов. У части ИТ-шников есть стратегия: каждый год менять место. Я тут хочу сказать, что это — не особенность России. Питер Друкер, рассматривая вызовы менеджмента 21 века, более 20 лет назад писал о том, что переход от физического труда к умственному приведет к переходу от профицитного рынка труда к дефицитному, при котором специалист будет сам выбирать место работы, при этом деньги будут не основным фактором. Собственно, это и происходит, в ИТ — раньше, в других отраслях — позже, но оно неизбежно.

Культура: цели, ценности, стереотипы, практики. Два способа движения по жизненному циклу: upstream и downstream.

Развитие технологий. Из жизни: как делаем самолеты. Три фазы.

Модель, ответ на вопрос взлетит или нет.
Два экземпляра прототипа. Один летает, второй в запасе
Дальше завод штампует.

Жизненный цикл — детальнее. Важно, что есть Разные места, разные типы деятельности: наука, производство, бизнес.

Здравоохранение — продуктовый подход.

Обычные задачи — поликлиника, регламенты, ОМС/ДМС
Сложная проблема — научный клинический центр. И там — другой подход внутри.
И еще — наука, экспериментальные методы.

Интегрировать это — все очень сложно.

Стивен Деннинг. Эпоха Agile. Складывается мозаичная система и надо интегрировать.

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

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

Итого, классификация:

Средства понятны и доступны — задачи
Средства неясны, но их можно найти — Цель
Средства никогда не созданы — Проблема.

Отмечу, что это близко к классификации Дэвида Майстера на три типа проектов: Мозги, Седина и Процедуры.

И есть вопрос владения результатом. Бизнес поставил задачу: инженер, сделай эту метрику не 10, а 5. Инженер думает, придумал, на коленках в выходные — сделал технологию, которая снимает проблему. Вопрос — кому принадлежат права на это средство? Менеджер «сделал у меня», инженер «в воскресенье на кухне». Эта бизнес-проблема, она не решенная. И пока выигрывают инженеры, которые уносят технологии — если не была явно поставлена цель.

Карта фаз развития технологии

Проектирование: технологии, рынок, орг.управление
Разработка и тестирование
Производство и эксплуатация

Каждая фаза — своя субкультура, принципиально отличающаяся от других.

Заказная разработка, культура операционной эффективности: инженеру ставят задачи. Фокус — орг.управления + производств и эксплуатация. За последние 2 года в России взорвалась — есть большой госзаказ. Как правило, коммерческие средства с гарантией результата. Создаются орг.формы и партнерства с заказчиком и так далее. Главный вызов — сформировать слой среднего управления, умеющий вести орг.проектирование
Продуктовая компания: разработка и тестирование, fail fast, гибкая технология управления
Инновационно-технологическая компания, инженерная культура. Разработка новых технологий и средств, которые обеспечат новизну. Главный вызов — связь технолога и бизнеса, это сложно, потому что говорят про разное.

Культура операционной эффективности — план-факт, все через процессы и kpi, приходят за стабильностью.
Продуктовая культура — fail fast fail cheap. Ключ — нетворкинг и сообщества. Потребление, а не деньги. Главное, чтобы заработало. Приходят за востребованностью.
Инженерная культура. Придумать, чтоб показать работоспособность, дальше не важно. Любопытство. Бизнес — обеспечивающая структура для исследований.

Александр говорит, что в компании объединяются только попарно: продукты + операционная эффективность или инженерная культура + продукты. Но я хочу сказать, что изменения текущего момента состоят в том, что надо рассматривать целостную деятельность из всех трех фаз, пусть не в одной компании, а в кооперации. Это раньше, когда развитие технологий было медленным, можно было рассматривать отдельно. У меня есть есть статья https://mtsepkov.org/De3-ground, где я формулирую такую схему деятельности ценностно.

И Александр в заключении сказал, что для целостного представления необходимо коммуницировать, несмотря на разницу культур. Коммуникация есть преодоление отвращения к точки зрения собеседника, это Александр сослался на Бориса Марковича Островского, одного из учеников Щедровицкого-старшего, от которого я тоже много почерпнул. Чтобы вести такую коммуникацию, надо говорить про дело, оставляя все остальное — за рамками.

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

Книги по различию Запада и России:

Лотман. Беседы о русской культуре
Бердяев. Истоки и смысл русского коммунизма.
Александр Зиновьев. Русская трагедия
Аузан. Культурные коды экономики
Эрик Мейер. Карта культурных различий

А начать можно с лекций Аузана, которые гуглятся по словам «Аузан Арзамас».

Книги про современную западную культуру.

The beginners guide to OKR
Никаких правил — про Netflix
Ким Скотт. Радикальная прямота
Стивен Деннинг. Эпоха Agile.

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

Ноомарксизм в комментариях: Спасибо! Очень созвучно собственным мыслям о переходе к когнитарному производству. Статьи Сложный консалтинг как нетоварное производство и Наброски к основам когнитарного предприятия.

Автор не только поделился материалами, но и сделал большой пост на своем канале с цитатами.

А я прочитал статьи, на которые были ссылки, сопоставил со своей картиной мира экономики и вот тезисно результат.

Разница между стоимостью продажи некоторого продукта и стоимостью его создания имеет три компонента: (а) технологический, связанный с использованием более прогрессивных способов создания (обычно в виде машин и инструментов), чем используют другие; (б) организационный, связанный с организацией разделения труда и выполнения операций, которое повышает производительность и (в) рыночный, связанный с работой на том сегменте рынка. где продуктов почему-то не хватает или потребители о них не знают. Маркс фокусировался на (а) — капиталист владеет средствами производства, недоступными простому ремесленнику и потому забирает себе прибыль, связанную с технологичным производством. Шумпетер, насколько я представляю, рассматривал (б) — способ организации производства, который придумал предприниматель, а также (в) — знание предпринимателя о сегментах рынка и ставке на них. С (в) также связана теория, что предприниматель получает прибыль как премию за риск, на который он идет, делая ставку. Я вполне могу ошибаться, и недооценивать понимание Марксом компонентов (б) и (в). Но в любом случае, все ти компонента надо разделять, у них — разная природа.
Когда консультант выполняет сложный консалтинг, он работает над повышением каких-то из этих трех компонентов за счет снижения стоимости производства либо выхода на более дорогие рыночные ниши, разный консалтинг — про разное. И таким образом он вносит свой вклад в систему создания продукта, получая эффект. И может претендовать на вознаграждение в виде доли, от этого эффекта. которая может быть велика. Либо, подразумевая эффект, просто назначать себе высокое вознаграждение. Поскольку продукт — уникальный, то его нельзя оценить рыночными методами, тут я согласен. Возможны лишь принятые практики, как формируется вознаграждение: за это обычно платим деньги, а за это — даем долю. Это не рыночное ценообразование и по-любому это — предмет переговоров.
По мере того, как труд из физического становится умственным, изменяется технологическая составляющая. Опыт ИТ показывает, что через технические средства + регламенты (организационная составляющая) высоких эффектов не достигнешь, начинает играть человеческий фактор. Получается высокий уровень индивидуализации производства каждого нового продукта (который тиражируется почти бесплатно). А дальше ИТ-шники с точки зрения вознаграждения становятся близки к консультантам, они могут запрашивать за свой труд сколько хотят, имея ввиду высокую прибыль от продажи многих экземпляров удачного продукта на массовом рынке.
Еще я подумал. что большинство теорий созданы вокруг самого массового явления — технологизированного труда сотрудников. который был самым массовым. Рынок труда в этом сегменте всегда профицитным, была безработица и желание получить работу. Сегмент дефицитных топовых специалистов, включая менеджеров, был относительно мал, и интересно — проводил ли кто из экономистов исследования в этом сегменте. Потому как именно он сейчас постепенно становится основным.

Еще ряд читателей прислали ссылки на другие книги. тоже интересно, буду смотреть.

Lex Mefodyev: Ещё хорошая в тему — Николай Данилевский «Россия и Европа»
Matvey Sofin: Помню, была книга «Почему Россия не Америка», не уверен, что качественная, но все же. И ещё одна: «Почему одни страны богатые, а другие бедные».
Pavel Гиренок. Ценности и смыслы в галлюценозе русского сознания. Вышла в продажу 2 дня назад.
Максим Цепков: Любопытно. Аннотация — парадоксальная, за этим может быть конструктивное содержаение, а может стоять собственная идеология. Но пока книга только бумажная. Будет электронная — буду смотреть. Как я понял, книга написана по серии лекций, их видео есть в свободном доступе. А вообще Федор Гиренок — новый для меня автор, хотя, как я посмотрел на его сайте, у него много книг и статей.

Еще интересное замечание Rinat Enikeev: Культура даже в названиях отделов проявляется.

Вместо Human Resources — People.
Вместо Management — Leadership.

И, отмечу из личного опыта, в этом есть смысл и влияние на жизнь сотрудников.

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

Игорь Гранщиков из Авито. Система управления с обратной связью

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

Возвращаясь к докладу. Целеполагание. Три группы целей:

Продукт — ценность, поставляемая в продакшн
Процессы — метрики их функционирования, например, cycle time
Люди: счастье, найм.

Цели — фиксируем ожидания. Операционное ревью: есть цели и факт. И если есть невыполнение или риск невыполнения — должен сработать триггер и дать корректировку действий.

Были рассмотрены 5 задач. 1. Контролировать результативность и эффективность 2. Настраивать процессы чужими командами 3. Запускать команды чужими руками 4. Контролировать перформанс-менеджмент 5. Развивать старших инженеров. Теперь о них по порядку.

1. Контролировать результативность и эффективность. Результативность — делать правильные вещи, эффективность — делать их правильно (быстро, качественно). Это — разное, следить надо за обоими.

Burndown. Результативность — поставка того, что выпускает. План-факт. А скорость — эффективность, производная от скорости. Одна из метрик — cycle time.

Если цель — запустить ипотечную анкету на мобильных платформах. Отставание 10 дней, один из эпиков заблокирован смежниками. Метод изменений: в начале квартала сверять планы свои со смежниками. Цель по cycle time может быть не достигнута по той же причине.

Тимлид докапывается до причин, а руководитель тимлидов смотрит на светофор. Есть еще несколько метрик индексов: support ticket sla reaction, zero bug policy, crashes, LSR SLA

2. Настраиваем процессы чужими руками. Досталось легаси плохого качества, много пользователей обращались в поддержку. Обращения матчатся с багами, для каждого известно. Цель: привести HD count к целевому значению. И количество решенных тикетов от суппорта 10+. Дальше мониторили — и получилось успешно за пару кварталов. Потом вывели на мониторинг.

3. Запускать команды чужими руками. При запуске команды есть общее: процессы и практики соответствуют стандарту. Agile periodic table — чек лист. Начал печатать, класть на стол и помечать. Но не масштабируется.

В Авито есть модель зрелости Team maturity model. Опрос по соответствию. И дальше по каждому пункту светофорная модель. Тимлид видит детали у себя, а руководитель — сводку по командам и динамику. И раз есть метрика — мы можем ставить цели по движению по по модели.

4. Контролировать performance management. Тимлиды затягивают обратную связь сотрудникам. Особенно начинающие. И начал включать в операционное ревью мини-оценку сотрудника. При этом требовалось каждого оценить, обязательно хорошо-плохо. Бинарно, нормально объединено с хорошо, и это — сознательно. Потому что у начинающего тимлида нормально — это плохо, по которому он не хочет выдавать обратную связь. Если плохо — то причины и action plan. Это побуждает тимлида давать обратную связь.

5. Развивать старших инженеров. Стандартные планы не работают, нужны нестандартные challenge. Например challenge: реализовать платформу календарей и применить для разных платформ. Или повысить SLA.

Как часто? Есть быстродействие, регулирование и точность. Слишком часто — задергаем команду, слишком редко — не будем реагировать. Целеполагание — как целеполагание в организации, у них раз в квартал. А операционное ревью 10 % — 1-2 недели (9 дней формально). На последней период операционного ревью есть выполнение целей. И мы можем воспользоваться для обратной связи. Но! Это не должно становиться KPI, это должно быть поддерживающей штукой.

Итак, построение системы управления

Настройте целеполагание
Выберите метрики
Настройте операционное ревью — формат
Поставьте ревью в календари
Make policies explicit — чтобы люди знали, что от них ожидают

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

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

Рассказ начался с вопроса, что такое провал? Мы попробовали, сделали, но это не оказалось полезным. Это провал или нет? Ответ — итерация, мы потратили свое время и чужие деньги, чтобы уточнить картину мира. Полезный опыт.

Дальше была история. 1957 Fairchild semiconductor. 8 человек уволились от William Shockley, чтобы основать свою компанию, и основали ее как дочку fairchild, которая занималась разным. Они изобрели интегральную схему и начали делать, начали делать процессоры и память. Одновременно с Килби, было признано. В 1971 Don Hoefler написал статью про Fairchild semiconductor, где впервые употребил термин silicon valley — и он прижился.

Все росло в 2 раза, и был год, когда дочка приносила 60 % холдингу, там были внутренние дележки. Но в 1968 двое ушли, основали Integrated Electronics — Intel, был первый коммерчески неуспешный год. А в 1969 — Sanders уволился и основал advanced micro devices — AMD.

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

Возвращаясь к внутренним сервисам. Внутренний сервис — это сервис, потребителями которого являются клиенты компании, может быть разным: платформа, биллинг, аналитика (человек+машина). Внутренние пользователи и внешние — отличаются. Внешние — многочисленны, обезличены. Хотя в b2b некоторые важнее других. Но в целом восполнимый ресурс. Внутри пользователей мало, они рядом с руководством, и они — не восполнимый ресурс.

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

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

Поэтому правильно оставить интеграцию клиента на другом конце: клади данные в этом формате сюда. Но! удобный API — ваша часть. И помощь в написании тестов. Но это работает начиная с 3-4 клиента, первых надо сделать самим — иначе они просто не начнут пользоваться.

2. Приоритеты. Agile учит планировать спринт, собирая заказчиков, и заказчики договариваются. В принципе работает, если общее дело, есть точки пересечения, на которых договариваются. Если же много разных подразделений, то они отказываются договариваться. Не приходят на встречу, а если пришли — только познакомились на ней. И они не договариваются между собой, а пытаются договорить вас. Ошибка — пытаться самому принять решение, кто важнее. Но если подразделения далекие и компания большая, то вы не можете сделать.

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

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

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

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

Если от внутреннего сервиса не зависит продакшн — его не обязательно резервировать. Достаточно мониторить и вешать плашку «не работаю планово». И по входным данным — вести мониторинг, вешать плашку «мы уже знаем». Это как «мы адекватны и стараемся».

Рост нагрузки системы. Измеряться может в разном, а скачки — с новым клиентом. И часто есть точка апокалипсиса — ресурс весь потребляется. Например, может быть время на ежедневную обработку данных — не должно превышать 24 часа. Пока всего мало, можно проводить тесты и предсказать точку апокалипсиса. Это надо сделать и готовиться.

Мониторинг и информирование — важнее постоянной доступности.

4. Велосипеды. Однажды было нужно строить тепловую карту России по метрикам, по регионам. Маленькая команда, Apache Superset — позволяет подобное делать. Но! Деление по регионам может быть не очень хорошим, Красноярский край — большой, надо дробить. А еще есть города — миллионники — они маленькие, людей много — их надо показывать специально. А еще состав региона надо уметь менять. Коробка — не поддерживает. В результате аналитик данных занимается тем, что пытается поставить точку в нужное место и другой борьбой с инструментом. В результате, пока боролись, другая команда напилила собственные карты, начала им предоставлять.

Готовые инструменты хороши для прототипов, но даже для MVP — не обязательно. Надо оценивать, не слишком ли он дорог. Часто на первом этапе нужно небольшое подмножество, но с нашлепкой, которую сложно сделать, и это проще сделать самим.

Эрик Бурыгин. Сила нетворкинга, или Нетворкинг как стиль жизни

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

Это иллюстрирует сквозная история — о том, как Эрик хотел сделать курсы, и даже учился этому — но у него не получалось. Но однажды он попал в Гонку героев. Потому что до этого хотел попасть в спорт, было 100500 попыток, но не складывалось. А тут увидел в инстаграме фотку с гонки героев, где был его друг, узнал, решил в очередной раз попробовать, друг дал телефон — и этот вариант зашел. И он не просто участвовал, а стал инструктором, сдал необходимое, хотя для этого пришлось с другими инструкторами договориться о переносе даты экзамена, он не мог в назначенную. А потом был тренинг по публичным выступлениям, где он человек рассказывал про Яндекс-практикум, и он подумал, что это клевое место, пошел туда работать. Но с курсом не складывалось, надо было пройти обучение, а там не было вакансий. Однако, Гонка героев осталась, он собрал команду от Яндекса, только формально они опоздали, но поскольку руководитель по спорту в Яндексе тоже был инструктором в гонке героев, он договорился. А потом, на гонке, познакомился с девочкой QA-факультета, рассказал ей про мечту о курсе, его начала включили в середину обучения, а позднее у него получилось сделать курс, и он быстро нашел команду для этого за счет накопленных контактов. И таких историй у Эрика много.

Дальше были рекомендации. Они, в общем простые и достаточно известные.

Люди часто охотно разговаривают о том, что они делают. Это кажется, что они не хотят. Просто они не обо всем.

Где и как разговаривать? Везде.

Профильные конференции
Пейте кофе, ходите на обед с новыми людьми. В Яндексе есть рандомный кофе
Тимбилдинги и неформальные встречи. Если не хватает — свои: настолки, пати, спорт…
Открытые и доброжелательные
Проявляйте заинтересованность, не отвлекайтесь на встрече
Делитесь историями
Обменяйтесь контактами
Не забывайте напоминать о себе
Будьте отзывчивыми
Не будьте навязчивыми
Если плохое настроение — перенесите

Страхи. Ему и сейчас страшно. Но он пытался изменить, потому что хотел. Как готовиться?

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

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

Чек лист быстрого старта

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

Хотел стать сейлом. Всех сейлов спрашивал — а как ты стал сейлом? Многие рассказывали. И руководители просили подчиненных.

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

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

Юлия Лукина. Как окунуться в новую предметную область и не утонуть

Юлия сменила много предметок: телеком (управление железом, портал для сотрудников), DWH+BI, Порталы госуслуг, Атомные станции, e-com (озон). Погружение в новую область кому-то тяжело, кто-то обжигаешься, кому-то больно. И она рассказывала свои техники погружения, чтобы не было страхов. Приемы — простые, превратились в чек-лист. Это про предметную область, смену стека она полагает отдельной, хотя лично я не очень вижу разницы на уровне чек-листа. Дальше по пунктам.

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

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

3. Множество новых контактов. В новом отделе 10-15 человек в принципе запомнишь через 2 недели. Но есть большие проекты, где в чате 1000 человек. Матрица взаимодействия, Миро или что-то еще. Кто за что отвечает.

Где брать на все это время? Реально достаточно 15 минут в день, как и с контактами. И надо каждый день. С визуализацией пореже, но тоже не накапливать.

4. Обязательно задавайте вопросы. Да, даже глупые, и если кажется, что это элементарно. История — термин Mesh. Все употребяют, а она не знает. Но не спрашивает, спрашивает у коллег, а те — не знают. И полтора часа потерянного времени, потому что спросить надо было того, кто сказал. При чем выяснилось, что это — сленг, включить «как на проде»

Спрашивать надо своевременно. Рассказывают про червяка, во-время не спрашивают, надеется понять из контекста, не получается. Но когда полчаса говорили, сложно. А это на отгрузке зона, куда паллеты ставят. Или вопрос про имя через два дня знакомства.

Будь тем, кто переспросит и уточнит. Особенно на фразу «не буду останавливаться, всем понятно». Не понятно — спросите. Может потом, в личке. Но лучше — сразу, не только вам не понятно.

Не бойся спрашивать у экспертов. Если у эксперта спрашиваешь «расскажи мне все» — он не знает, что ответить, он три года может рассказывать. Стоит в вопросе раскручивать от задаче, а потом идти вширь, если уместно. Не «какие бывают топологии сети», а «если роутер вышел из строя — как узнать топологии, в которых он включен»

5. Фокус на здесь и сейчас — погружение через текущие задачи. Отбрасывать все лишнее. Беречь силы. Не распылять внимание. Иначе вас может накрыть, узнать все — не реально.

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

7. Понять и простить. В первую очередь себя. Если мы принимаем решение о смене предметной области, надо заходить с пониманием на входе, что ты не понимаешь ничего. И не постигнешь все за неделю-две. Будут моменты, когда будет жестко накрывать, будете сидеть с кипящей головой. Обращаемся за помощью к себе самим, сила в нас. Тут помогает книга Е.Резанова «Это норм». А еще есть эксперты. Она ищет жертву среди экспертов, и просит рассказать, как он начинал, погружался. И в 90 % случаев они отвечают «я и сейчас не понимаю», а другие «первые полгода я не понимал». И тут становится легче. И можно явно попросить помощи, не обязательно сделать задачу за вас, а направить на правильный путь.

8. Погружение через обучение других. Когда начали понимать — помогайте, и при этом сам разбираешься.

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

И есть смысл многое вынести в онбординг в команду. Например, глоссарий.

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

В комментариях Sergey Smolny Molchanov: Поддерживаю автора — очень близко к тому, к каким приёмам прибегал сам при погружении в новые предметные области.

Антон Огородников из Mаgnit Tech. Инженерная культура. Что это и почему она важна?

У бизнеса компании есть продуктовая культура со своими принципами. Они были на слайде, но я не успел записать. А у ИТ — инженерная культура, обеспечивающая поддержку бизнеса. Принципы формулировали на уровне руководства ИТ.

Здоровье сервиса — нулевой приоритет. Если у тебя проблемы с продом — ты чинишь. А не сидишь на встрече с руководителем. Ты покрываешь сервис метриками, чтобы следить за его здоровьем, не катишь без метрик, не переключаешься на другие фичи.
Инцидент — незапланированная инвестиция в стабильность сервиса. Инцидент — нормально. Но если он произошел — сделай вклад в стабильность. Упала база, сервис — не рестарт, а постмортен и разбор причин с их устранением. Ответственность — на команде, доносим до команды целиком.
Platform by design. Если есть задача, то (а) поищи этот велосипед в других командах и (б) при разработке подумай об использовании в других командах, особенно если в ходе поиска обнаружил интерес. Сделали, когда в появилось два сервиса авторизации. Обобщение — в ответ на интерес другой команды.
Принцип горящего дома. Ситуации — разные, отпуска, болезни. Если есть проблема, то как ее изолировать от других. Ну и потушить. Поднимаем то, что упало, и потом — ищем причины. Кейс — большая кастомизация поверх базового механизма сломалась при обновлении. Сначала — делаем костыль, чтобы поднялось. Потом — хорошее решение и профилактика будущего.
Tech follows Business. ИТ поддерживают. Были прецеденты, когда расходились. В частности: мы как ИТ должны уметь давать оценки. Как можем по текущему описанию. Некоторые инженеры — не про бизнес, они про фреймворки и технологии, и таких не берем.
We build it — we run it. Команда отвечает за фичу целиком, без функционального деления, от начала и до конца. Люди приходят из разных компаний, у многих сопровождение отдельно, а у них — нет. Команда отвечает за фичи на проде, за данные, которые через себя пропускает, и метрики — чтобы следить за этим.
Explicit is Better Then Implicit. Явное лучше неявного. Все, что делаешь должно быть визуализировано и оставлять артефакты. Камеры на встречах, это упрощает коммуникацию и упрощает встречи, невербальная коммуникация. Например Feature release freeze в конце года: мы не катим фичи.
Принцип швейцарского ножа. В нем много элементов. Инженер-программист должен стремиться к тому, чтобы быть универсальным, хотя основное время пользуется 1-2 инструментами. Можно заменить того, кто заболел, не ждете его.

Выводы

Культура может являться фундаментом
Нет плохой и хорошей культуры, есть текущая ситуация
Заниматься формированием культуры можно начинать, когда становится много
Культура не высечена в камне, она живет.

Распространение. Сначала продать принципы руководству. А затем закидывать в инженеров точечно. А потом как достигается принятие нужной массой экспертов — распространяют на всех.

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

Ольга Муттер из СберМаркет. Прозрачная структура проектов в компании от стратегии до исполнителя

Структуру выстраивали на 100+ команд в 3-уровневой иерархии команда-юнит-домен. Каждая команда живет своей жизнью, у нее свой проект в Jira, разный flow, разные типы задач и виды оценок. У бизнеса проблема — предсказуемость, понять, когда будет сделана фича. А еще им интересно оценить эффективность системы в целом и работать над повышением. Они решали эту задачу 2 года. Четыре компоненты: единая точка входа, ключевые метрики по эффективности, процесс работы с метриками и культура. Есть ее статья «Как подружить проектное управление с продуктовым подходом». Дальше — по пунктам.

1. Единая точка входа. Свой мир Jira в команде оставили, но два года назад сделали единый проект, с обобщенным flow, в котором надо вести все эпики. И смогли посмотреть на работу всей компании однородно. Дальше надо было всех заставить там работать. Это — отдельный доклад. Был пилот на нескольких командах, потом директива. И это была первая итерация.

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

С апреля 2024 следующая итерация — перенести в Jira discovery. Тип работы Идея, и тоже привязан к стратегии через инициативы. И бизнес-требования, замена Excel с бэклогом. Получается трассировка: Стратегия — Инициативы — Идеи, Эпики и бизнес-требования. Решилась проблема приоритизации, потому что инициативы имеют приоритет.

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

2. Метрики. Что есть эффективность для ИТ и как выражается? Проблема бизнеса: не понимаем, когда команда разработки это сделает. Постоянные переносы.

Lead time — сроки поставки ценности
Точность поставки — попадание в сроки
Объем поставки — эффективность использую ресурсы
Эффективность поставки — чтобы не было делаю за час в течении недели

Урок: сначала накопите статистику lead time, а потом ставьте целевые значения. Они поставили сразу, и потом долго с этим мучились — команды заметали сложности под ковер и так далее.

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

У всех готовы объяснения, почему lead time нельзя улучшить. Опыт показывает, что можно — но надо проводить анализ. Поэтому на входе нельзя идти в персонализацию, надо чтобы люди научились вести анализ метрик, разбираться в проблемах? это должно стать частью культуры работы.

Целевые метрики — менялись. Добавили: t2m, cycle time discovery, value, % отмен. value — что приносим ценность, а не просто делаем объем работ. Но мерить — сложно, пока тут проблемы. Системы можно взломать, они следят и работают через контр-метрики, это — постоянный процесс.

3. Процесс. Есть поддержка от вице-президента по технологиям. Точки контроля на уровне компании — в OKR появились процессные метрики. KPI тоже пробовали, там грабли. B Performance review. Для метрик — int-autometion-bot с уведомлениями — предсказание, что не попадешь в сроки, изменение метрики и так далее.

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

4. Культура. Она не строится за месяц или за квартал. Она в том, что все понимают, что нужна задача верхнего уровня именно в общем проекте. Так устроено. Все задачи подвязаны. И бизнес появился именно поэтому вместо Excel. Работа на всех уровнях VP, EM/CPO, Unit lead, team lead. Распространение с обратной связью.

Как починили проблему? Тимлид — мини-CTO, он понимает, как он на уровне всей компании влияет на то, что компания делает. А бизнес может по каждой команде посмотреть скорость работы, попадание в обещания и построить прогноз.

В заключении я хочу отметить, что 10 с небольшим лет назад я слушал доклад про то, как в Касперском ставли единообразие процессов обработки задач и отметить разнообразие подхода. Там главным была общая система и одинаковый workflow для всех типов задач, без отдельного пространства для команд, и меряли единые характеристики, а все особые случаи согласовывал комитет по изменениям уровня компании, и их на всю компанию была пара случаев. А вот речь о трассировке задач до уровня стратегии — не шла. А в этом случае задачей было обеспечить единообразное представление только на верхнем уровне, и построить трассировку до стратегии, которую обвесить метриками. С моей точки зрения, это характеризует изменения, произошедшие за это время в культуре отрасли в целом.

Игорь Курочкин. Как стать 10x экспертом

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

Контекст. Игорь работал с высоконагруженными системами, и несколько лет назад ушел в консалтинг по этой теме вместе с партнером. Проблема — нехватка знаний, потому что есть большое разнообразие технологий и все время появляются новые, техрадар за 15 лет накопил 1600+ технологий. И большая нехватка времени в операционной работе, чтобы это освоить. Идет большой поток информации, при этом в нем много шума и мало сигналов, а у предметной области — высокая сложность. Поэтому поиск в тот момент, когда задача уже получена — слабо эффективен. Решение — вести личную базу знаний, в которой накапливать и структурировать информацию заранее. Сейчас у него накоплено 15к заметок и 50к связей, и это — персональная база. У партнера — собственная, иначе организованная, чуть меньшего масштаба — 10к заметок, и когда они решают вопрос, то идет взаимное ревью или совместное решение, при котором каждый использует свою базу.

Как он это делает? Первое — надо организовать входящий поток ограниченной мощности, который ты успеваешь перерабатывать. Он подписан на профессиональные соцсети в linkedin и github и ряд профессиональных блогов по теме. А также почтовые рассылки — они все еще живы, и среди платных есть качественные, надо отбирать. Вопрос доверия к автору. Есть платные относительно качественные. Получается лента под себя, которую разбираешь пару раз в неделю. Далее, поиск. Помимо личной базы знаний, выполняешь поиск в почте, где собраны рассылки, и настраиваешь Google CSE, ограничивая список URL, где ищем. У него в индексе 884 блога — инженерные техблоги разных компаний. И прикрутили валидацию и проверку источников. А при разборе рассылок — еще анализируют кто, где и что публикует и добавляют в базу источников.

Второе — систематизация. Быстро переработать большой материал, когда уже пришел запрос — тяжело, надо заранее. И еще вести мысли и заметки, чтобы не повторять. Этапы структурирования:

Данные — набор фактов.
Информация — раскрашивание фактов по категориям.
Знания — граф связей между фактами.
Озарение (insight) — это связь двух точек.
А мудрость (wisdom) — видение путей в графе.

У него примерно так: источников данных 10к+, информация 1к, знания 100 узлов, заметки-инсайты 1к, мудрость 10к заметок и *3 связей. За 3 года 15к заметок, 50к связей, 555к слов, 8к картинок, 800 контактов, 800 компаний, 530 конференций и других событий, 465 книг.

Инструменты: obsidian, roam research, logseq, Zettlr. Подходы: lyt/ideaverse, basp/para, Zettlercasten

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

Собственно, все. Следующие шаги, который он видит: дайджест или рассылка по списку своих блогов; поиск по tg, github, twitter; персональный дашборд; персональный помощник. НА правах идеи — я бы еще подумал о подключении к этому GPT: сейчас есть доступные технологии, при которым ты подключаешь к GPT собственный массив информации так, что он первично формирует ответ с учетом ее, в чем-то по сути это получается аналог поиска по заданному набору URL, но GPT знает про синонимы и связи понятий, что расширяет контекст.

Меня лично этот доклад заставил задуматься — а почему я не пользуюсь подобной системой личных заметок? Наверное, потому, что нарабатывал навыки работы со знаниями, когда компьютеры для этого были не доступны. А потом освоил предыдущий стек, вики-системы, которые мы в компании применяем с 2005 года, в которых вел персональные заметки наряду с проектными. При этом персональных заметок всегда было не много, потому что освоение новых областей практически всегда шло в рамках проектной деятельности. А, заметив интересное помимо проекта — тоже старался поделиться в виде блога, который с 2010 стал еще и публичным, к 2014 превратившись в собственный сайт. И как-то сложилось, что освоение новых тем я тоже делаю в публичном пространстве. Так было с конспектом лекций Петра Щедровицкого по СРТ. Так произошло с моделями soft skill, которые я собрал в модель личности: были доклады, потом — статьи и книга, в процессе подготовки было много заметок, но они вошли в книгу, остались только наборы ссылок-источников, которые вполне помещаются в GoogleDocs. Впрочем, может быть это объяснение «от ответа», чтобы не делать. Но, в любом случае я активно использую поиск по своему сайту при работе над разными вопросами, и регулярно нахожу очень интересные материалы собственного авторства :)

Александра Прокшина из Авито. Искусство спрашивать, или 42 вопроса, которые ускорят развитие вашей команды и вас самих

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

Об испытательном сроке — вопросы поступающего на работу.

Как вы узнаете, что я успешно прошел испытательный срок?
Что важное надо сделать 90 дней?
Как проявить чтобы добиться успеха в вашей компании?
Каких навыков не хватает команде, куда я прихожу?

Последние два — подстройка под конкретную компанию, это важно.

Вопросы к сотруднику на регулярной встрече.

Не «Как дела», а «Что самого интересного сделал за неделю?» — это стимулирует воспоминания. Кстати, его можно применять не только на встречах, я знаю руководителя высокого уровня, который регулярно, проходя по офису, спрашивает почти у всех в коридоре «Ну, что новенького, что интересненького?».
Не «Как я могу помочь», а «Что для тебя самое сложное в работе?» — часто люди не просят помощи, чтобы на проявить слабость, а такой вопрос подсвечивает трудности, и дальше можно по-разному раскручивать диалог.
Какую обратную связь ты хотел бы получать чаще? Кейс к вопросу: есть классный спец, ему говорят «ты классный», а он говорит «мне не хватает обратной связи — развивающей»
Важно ли тебе, чтобы тебя хвалили? Тут у всех разная потребность, одним важно каждую неделю услышать хорошее, а другим — только когда неординарное сделал.
Есть ли какая-то работа, которая была недооценена за последнее время? Возможно, что-то не заметили, а он гордится и ожидал похвалы
Какие сильные стороны ты НЕ используешь в работе? Может, что-то не используется, нам нужно а мы не знаем, а человек страдает?

Вопросы руководителю.

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

Что общего в хороших вопросах.

Есть промежуток времени. Не вообще, а конкретно.
Крайности: самое важное, интересное, сложное
Вопросы-аналогии, с чем бы ты сравнил что-то
Шкалы 1-10. Оцените довольство зарплатой, насколько склонен уволиться
Обращайте внимание на то, чего нет, не хватает

Вопросы себе. Это важная часть самоопределения и рефлексии.

Зачем я это делаю? Зачем пришел на эту конференцию, работаю на этой работе, дела этот проект
Квадрат Декарта для самоопределения: что будет/не будет если это произойдет/не произойдет.
Расширение предыдущего: что будет, если этого не произойдет никогда? Это работает против бесконечного откладывания решения об изменениях.
Если я буду продолжать делать то, что сейчас, буду ли я доволен собой результатом через год? Тоже против того, чтобы не меняться.
Есть ли кто-то, кто уже решал похожую проблему. Вряд ли твоя проблема уникальна.
А что бы на моем месте сделал авторитетный (для вас, подставить имя) человек?
Рефлексия дня. Что нового я узнал сегодня? Как это может быть полезно? Что нового я начну делать завтра?

Резюме

Вопросы — инструмент для установления связей и решения проблем
Хорошие вопросы могут вывести коммуникацию на следующий уровень
Не недооценивайте уточняющие вопросы

В вопросах к докладу: а как быть с социально ожидаемыми ответами? Она за прозрачность, может спросить «а насколько ты честен/откровенен со мной 1-10?», или даже явно «Я думаю, что ты тут не договариваешь примерно это», особенно если есть альтернативная информация. И это — помогает.

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

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

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

— Максим Цепков • 12:31, 3 июля 2024 • нет комментариев

2024-07-03: Saint Highload и Saint Teamlead - поступательное движение отрасли