Изменения

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

* '''Олег Коровин. GraphQL: зачем на самом деле он нужен'''. Apollo Federation — дар бога. Идея в том, что GraphQL — это прорыв, онапозволяет она позволяет делать запросы, объединяя разные API, подобно тому, как ЫЙД SQL позволил делать запросы, объдиняя объединяя многие таблицы. Это — моя мысль, но она родилась в ходе доклада.

* '''Алексей Цветков. Как воспитать себе помощника: применение локального ИИ для разработки'''. Основное для меня сообщение доклада — что можно на компе разработчика развернуть локальную версию ИИ, сопоставимую по мощности с GPT-4, Gemini, Copilot. Правда, речь шла о специализированной области разработке софта, но GPT умеет получать задания, писать комментарии и общатсья общаться на естественном языке — как разработчик.

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

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

* Изменения окружаем флагами для котроля контроля нового поведения* Используем тольо только безопасные изменения внутри endpoint

* Сначала обновляем консьюмеров, потом продьюсера. Тогда сервисы перестали быть автономны по деплою, и пояляются появляются проблемы с откатом консьюмеров — для этого надо отвалить продьюсер. Частичное решение — фича-флаг в продьюсере, но то, что в очереди — лежит.

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

* У черного квадрата и последовавшего за ним направления супрематизма был вполне утилитарный смысл: для славы надо было отличаться от других, причем сильно. За счет мастерства это не получается, оно есть, но не экстра-уровня — значит делаем оригинально. Прием не новый, кто-то из скульпторов, творивших в Италии после возрождения ввел в моду барельефы, где фигуры едва намечены, почти рисунок на мраморе — чтобы отличаться от глубоких барельефов ВозрожеднияВозрождения, которые уже у всех были. Здесь логика — та же.

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

* Безопасные типы данных: структуры, которые заранее рассчитаны на ассинхронные асинхронные изменения в разных местах, и независимо от порядка синхронизации результат будет одинаков

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

* архитектурные компромиссы и оптимизации — пекетные пакетные передачи и т. п.

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

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

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

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

* Аузан . Культурные коды экономики

* The beginers beginners guide to OKR

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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