Изменения

Перейти к: навигация, поиск
м
Нет описания правки
А на Teamlead в прошлом году было много крутых докладов, в том числе от известных спикеров. Среди них много докладов было по психологии. Это было очень интересно, можно посмотреть мой отчет прошлого года [[Teamlead-2023-Spb]]. Но это был такой разовый всплеск в хорошую область, в этом году его не повторили, наверное, имея ввиду ажиотаж с поданными заявками. Но, тем не менее, хороших докладов было достаточно много. Как и осенью, в рамках Teamlead шли треки KnowledgeConf и Techlead, и там тоже были интересные доклады.
А еще забавно, что на Teamlead был Макс Дорофеев, он вместе с Александрой Брызгаловой вел мастер-класс по теории ограничений. Но его не было в расписании в качестве ведущего, чтобы люди не ломанулись. Правда, все равно вместо 50 участников было 120, и это не вина организаторов: они честно поставили 50 столов, просто остальные — саморганизовались самоорганизовались и обеспечили себя местами. Проблема в том, что в конструкцию мастер-класса заложено внимание ведущего каждому столу, и это — ограниченный ресурс, когда участников много, каждый получает меньше. Но ведущих было двое, они справились. А то, что Макс решил приехать на конференцию в таком варианте — свидетельство высокой репутации конференции.
Дальше будут заметки с докладов в том же порядке, в котором я слушал. А перед этим я хочу отметить отдельные доклады.
Еще несколько технических докладов с Highload
* '''Олег Коровин. GraphQL: зачем на самом деле он нужен'''. Apollo Federation — дар бога. Идея в том, что GraphQL — это прорыв, онапозволяет она позволяет делать запросы, объединяя разные API, подобно тому, как ЫЙД SQL позволил делать запросы, объдиняя объединяя многие таблицы. Это — моя мысль, но она родилась в ходе доклада.
* '''Филипп Дельгядо. Enterprise deploy: почему это больно'''. Многогранный доклад о разных аспектах создания безопасного деплоя. В том числе — для enterprise-приложений. установленных удаленно у клиента, который сам делает обновления, и это сильно повышает требования.
* '''Владимир Комаров из СберТех. О распределенных транзакциях'''. Очень хороший доклад с обзором различных механизмов распределенных баз данных и транзакций.
* '''Максим Метальников, Максим Смоляков из SberDevices. Особенности и вызовы реализации технологии создания готовых музыкальных произведений с применением ИИ'''. Ребята собрали pipeline синтеза песни из различных инструментов ИИ. Фазы pipeline: идея — текст <-> основная мелодия — аранжировка — запись вокала и инструментов — сведение и мастеринг. ИИ это все уже более-менее умеет. Правда, pipeline — не автомат, он на ручном приводе с участием человека. Но это нормально на данной стадии развития технологий.
* '''Иван Бондаренко из НГУ. Сильный искусственный интеллект у вас в подвале: как собрать мультимодальную LLM из опенсорса и настроить ее под вашу задачу'''. Это всего лишь про обучение ИИ понимать картинки и звуки. А вовсе не про решение сложных задач, недоступных пока GPT. Но все равно интересно.
* '''Алексей Цветков. Как воспитать себе помощника: применение локального ИИ для разработки'''. Основное для меня сообщение доклада — что можно на компе разработчика развернуть локальную версию ИИ, сопоставимую по мощности с GPT-4, Gemini, Copilot. Правда, речь шла о специализированной области разработке софта, но GPT умеет получать задания, писать комментарии и общатсья общаться на естественном языке — как разработчик.
А это — доклады с Teamlead. Вообще хочется отметить практически все доклады, которые я слушал, в каждом — своя изюминка. При этом на Teamlead я слушал меньше докладов, чем на Highload, потому что было гораздо больше нетворкинга.
* '''Роман Поборчий. Особенности создания внутренних сервисов в крупных компаниях, и как избежать провала'''. В начале этого доклада была роскошная история — что же такое провал. И содержание тоже было хорошим — про типичные ошибдки, которые ведут к провалу, потому что команда не справляется.
* '''Юлия Лукина. Как окунуться в новую предметную область и не утонуть'''. Ольга сменила много областей, и в докладе был рассказ о техниках погружения, доведенный до уровня чек-листа.
* '''Антон Огородников из Mаgnit Tech. Инженерная культура. Что это и почему она важна?''' В докладе была конкретная инженерная культура как набор принципов, с логикой их появления. И ценность доклада не в том, что сделана выборка принципов из книги, на которую ссылался автор. Ценность в том, что эту выборку имплементировали в реальной жизни, в своей компании, понимая что делают, то есть действуя технологично. Разница примерно такая же, как между разработкой кода для решения задачи и разработкой кода с использвоанием использованием шаблонов, о которых потому еще и рассказываешь в докладе, делясь своим опытом с другими.* '''Ольга Муттер из СберМаркет. Прозрачная структура проектов в компании от стратегии до исполнителя'''. Двухленяя Двухлетняя история выстраивания структуры, в которой команды понимают свой вклад в стратегию и действуют сообразно, и это поддержано сквозными метриками. Есть ее статья «Как подружить проектное управление с продуктовым подходом». Я хочу отметить, что 10 с небольшим лет назад я слушал доклад про то, как в Касперском ставли ставили единообразие процессов обработки задач и отметить разнообразие подхода. Там главным была общая система и одинаковый workflow для всех типов задач, без отдельного пространства для команд, и меряли единые характеристики, а все особые случаи согласовывал комитет по изменениям уровня компании, и их на всю компанию была пара случаев. А вот речь о трассировке задач до уровня стратегии — не шла. А в этом случае задачей было обеспечить единообразное представление только на верхнем уровне, и построить трассировку до стратегии, которую обвесить метриками. С моей точки зрения, это характеризует изменения, произошедшие за это время в культуре отрасли в целом.
* '''Александра Прокшина из Авито. Искусство спрашивать, или 42 вопроса, которые ускорят развитие вашей команды и вас самих'''. Очень хороший доклад из тех, в которых автор говорит вроде знакомые и известные вещи, но рассказывает это настолько хорошо, а материал так сфокусирован, что ты обновляешь у себя это в памяти, практически переоткрываешь заново. И это не только рассказ, но и презентация, где на слайде — просто вопросы, по одному или малой группой, но в них подсвечены ключевые моменты.
== Олег Коровин. GraphQL: зачем на самом деле он нужен. Apollo Federation — дар бога ==
По этому докладу у меня возникла ассоциация с историей. Когда-то давно были базы данных без SQL, только работа с таблицами, и все join надо было вручную писать в коде. Я это еще застал. Потом пришел SQL и проблема была решена. Сейчас это повторяется: микросервисная аргиюетура архитектура разложила объекты о сервисами, для каждого есть свой набор API. GrapgQL позволяет объединять данные из разных узлов в единую схему и делать общие запросы. При этом тогда разработчики относились к появившемуся SQL настороженно: это же накладные расходы, сложно и непривычно. Так и сейчас к GraphQL относятся настороженно как к хипстерской поделке, которая не нужна «настоящим программистам» — OpenAPI достаточно. Докладчик показывал, как GraphQL решает проблемы, сокращает объем кода, делает его более компактным. А также — как решаются проблемы контроля доступа, единой точки отказа и безопасности. Решение GraphQL — легкое и масштабируемое, федерации — stateless, и можно поднимать разные федерации для разных клиентов, подключая только необходимые им сервисные данные. И страивать параллельный доступ для миграции, поднимая федерацию для доступа, но запуская через нее только новые запросы. Тут ситуация выгодно отличается от того, что было с миграцией на SQL-базы данных — там это можно было сделать только целиком. На мой взгляд, получился очень удачный доклад.
== Роман Щербаков из Тинькофф. Пайплайны записи своими руками: думали — велосипед, оказалось — паттерны ==
Теперь от базы данных к взаимодействию сервисов. В случае синхронного взаимодействия (http, grpc) применяем:
* Версионирование по методам, а не целиком.
* Изменения окружаем флагами для котроля контроля нового поведения* Используем тольо только безопасные изменения внутри endpoint
* Маршрутизация запросов — чтобы метод получал только понятное
* Контроль жизненного цикла: состояния draft, unstable, deprecated. C разными обязательствами.
Асинхронные взаимодействия через очереди. Тут нет мгновенного изменения, в очереди живут необработанные события старых версий. И на них нельзя запустить обновление, они придут в виде, в котором посланы. Мы не всегда знаем участников взаимодействия — что читает, кто пишет. И делать версии событий базовые инструменты не позволяют. И тут хороших решений нет.
* Самое простое — новый топик для новых событий. Но при этом мы теряем порядок и партиционирование, нужно сложное переключение и администрирование.
* Сначала обновляем консьюмеров, потом продьюсера. Тогда сервисы перестали быть автономны по деплою, и пояляются появляются проблемы с откатом консьюмеров — для этого надо отвалить продьюсер. Частичное решение — фича-флаг в продьюсере, но то, что в очереди — лежит.
* Отправка нескольких версий — и консьюмер выбирает нужную. Это сложно в реализации, потому что стандартные способы передачи и контроля перестают работать — у вас несколько схем на одно событие, например.
* Можно возложить маршрутизацию на service mesh — чтобы он отправлял на нужных консьюмеров.
Итак, тезисы Александра о Малевиче, супрематизме и искусстве в целом. Отмечу, что он в лекции не разделял явно то, что Малевич говорил явно от позднейших интерпретаций.
* До Малевича искусство — это голые или обнаженные женщины, пейзажи или сюжеты с пресонажамиперсонажами, и для понимания предполагалось знание контекста. Малевич черным квадратом сломал этот стереотип, и сделал искусство без явного смысла и контекста, а для прямого восприятия.
* Искусство предназначено для созерцания, а не для интерпретаций и смыслов. Оно не должно иметь смысла, и это — правильно. Идея бессмысленного жеста — спасительна. Потому что жизнь полна смысла. В чем смысл жизни? Конечно, чтобы ходить к вам на работу. Искусство без смысла разрывает такую логику.
* Искусство без смысла, для созерцания — слом мира мещан, которые везде искали смысл, потому что так принято.
Теперь мои комментарии, тоже в виде тезисов.
* У черного квадрата и последовавшего за ним направления супрематизма был вполне утилитарный смысл: для славы надо было отличаться от других, причем сильно. За счет мастерства это не получается, оно есть, но не экстра-уровня — значит делаем оригинально. Прием не новый, кто-то из скульпторов, творивших в Италии после возрождения ввел в моду барельефы, где фигуры едва намечены, почти рисунок на мраморе — чтобы отличаться от глубоких барельефов ВозрожеднияВозрождения, которые уже у всех были. Здесь логика — та же.
* Как мне рассказали после лекции, первый черный квадрат был вполне утилитарной вещью — это часть декорации к спектаклю, где такая картина, наверное, была уместна по замыслу. А дальше — идея зацепила.
* Очень забавно: Чехов критикует мещан за отсутствие смысла, а Малевич — за то, что они везде ищут смысл. Хотя тут можно понять: у тех, кого называли мещанами, понятный смысл жизни из простых человеческих радостей. Они не ищут высокого предназначения, и не признают непонятное, художнику с ними сложно. Это целенаправлено разрушали, и в 1920-е, пока основным мотивом в СССР было низвержение старого супрематизм был в почете. А потом пошли эпоха, когда потребовалось конструирование нового.
== Владимир Комаров из СберТех. О распределенных транзакциях ==
Очень хороший доклад с обзором различных механизмов распределенных баз данных и транзакций. Проблема Сбера — гигантские БД на уникальном оборудовании. Идея замены была — распределенные БД. Он изучал и был противником, потому что разработчики не разбраются разбираются с тем, что внутри БД. И в распределенной БД тоже, поэтому пойдут нежелательные эффекты, и разработчик будет винить вендора или поддержку, а не себя. А если вместо распределенной БД предложены механизмы работы на уровне приложения, то проблемные точки видны. А в докладе — результаты изучения разных БД. И они не только в докладе — Влабимир Владимир написал '''книгу Путеводитель по базам данных''', потому что не нашел такого готового обзора. Дальше конспект, он заведомо неполный, и лучше его читать, смотря на презентацию — в ней много архитектурных схем.
Распределенные БД — 5 вариантов.
* Кластеризация монолита. Реплики, бесконечный масштаб чтения, запись — через один узел, и он — точка отказа.
* Распределенный консенсус.
* Безопасные типы данных: структуры, которые заранее рассчитаны на ассинхронные асинхронные изменения в разных местах, и независимо от порядка синхронизации результат будет одинаков
* Компенсирующие механизмы: мы быстрее запишем, а потом как-нибудь согласуем. Или не согласуем.
* Распределенные транзакции. Когда несколько агентов взаимодействуют и либо подтверждают либо откатывают.
CockroachDB — двухфазный вариант, но вторая фаза — асинхронная. Там, где начинаются изменения, создается объект-транзакция, клиент говорит commit — этот узел спрашивает готовность, сам записывает на диск, а остальные — записывают асинхронно.
2012. Детерминированные транзакции, Кальвин-машина. Название — в честь Кальвина, который говорил про предопределение как замысел Бога, которому следует все живаоеживое. Роль Бога тут выполняют клиенты. система пишет журнал их действий и применяет на всех серверах, получая детерминированный результат. Транзакция — набор чтений и записей, и при чтении в журнале фиксируется версия объектов, при повторении журнала это контролируется. То есть оптимистичные блокировки. Есть секвенсер, который пишет журнал. Если кто-то не может — сообщает остальным.
Ограничения подхода:
* низкоконкурентная среда, потому как оптимистические блокировки.
* задержки, сбор транзакций в пачку 10мс
* архитектурные компромиссы и оптимизации — пекетные пакетные передачи и т. п.
YDB. добавлены компромиссы.
Облачные БД. Amazon Aurora, Google AlloyDB, MS SQL DB Hyperscale. Облачные БД пишут журналы, а под ним — система хранения, которая накатывает журналы на страницы, в том числе несколько версий страниц, и по необходимости — отдает экземпляру. Все хорошо, кроме сложного деплоя. Доступны только как облачные сервисы.
К сожалению тема надежного диска и восстановления при сбое одного из узлов не была явно акцентирована. Потому что синхронная передача дает задержки, а асинхронная потенциально теряет данные. У них в Саге для клиентов внизу каждый шард дублируется синхронной репликацией — и да, это работает, так как для масштабирования можно увеличить число шародовшардов, уменьшив объем каждого.
От себя отвечу, что есть отдельный интересный вопрос — решение, устойчивое к потере дата-центра. Там играет то, что скорость связи между дата-центрами сильно ниже локальной, и, более того, может кратковременно деградировать очень сильно. И надо отличать деградацию связи от деградации самой ноды при высокой производительности. Мы смотрели, правда несколько лет назад, и обнаружили что все кластерные решения существенно ориентированы на работу внутри дата-центра с быстрой и устойчивой сетью между узлами…
Первым было тестовое задание: напиши функцию на Go для слияния каналов в один. За минуту достаточно хороший код, еще с комментариями на русском. Правда, с ошибками. И в реальной задаче мы их не можем увидеть через ревью. Однако, модель можно попросить написать юнит-тесты, и дальше рассматривать по-отдельности. И модель пишет тесты с большей охотой, чем разработчики.
Дальше — попытка сделать реальный проект — прототип распределенной платежной системы: сервис на Java, который получает поручения от человека и делает балансы на шардах, каждый из которых ведет баланс. Код порождался в несколько этапов, он выдавал задания. По коду была построена компонентная схема вызовов методов и диаграмма последовательности. А еще gRPC API, dockerfile для сборки, yaml для запуска, описание и схемы и тест-кейсы. Тест-кейсы — простые, но на вопрос, а что еще можно предложить, был выдан список сложных тест-кейсов: сложные, обработки ошибок, параллелизма, нагрузочное, стабильности, времени ответа, и далее можно предложить каждый их написать. Вообще это типичный способ работы: ты не сразу требуешь написать проект, а по шагам. В том числе — предложить план, а потом этот план по шагам исполняешь. Типиная Типичная работа с джуном в обучающем режиме.
Всего генерация проекта — 30 запросов к модели, 10 уточняющих. Результат 15 файлов, 3 без исправлений, а в остальных потребовались исправления человеком при отладке, но сильно меньше объема файла, всего около 5 % строк. Правда, в Java процент больше, около 15 % На слайде была детальная информация, и это выложено на github.
Его и надо рассказывать. И я отмечу, что для этого надо подготовиться заранее: раскрасить квадратики в разные цвета, возможно, сделать обводы и фоновые выделения. А может и нарисовать более крупную диаграмму для рассказа.
Другая идея: смотреть на картину как на карту и поверх нее рассказывать, как развиваются события — просто показать последовательность как взаимодействуют компоненты. Я бы для этого тоже крупно заранее пронумеровал пунты пункты такого взаимодействия.
Еще отмечу, что это — два разных рассказа, для разных целей и аудиторий, и надо понимать, что именно ты рассказываешь.
Интегрировать это — все очень сложно.
'''Стивен Деннинг. Эпоха Agile'''. Складывается мозаичная система и надо интегрировать.
Инженер: назначение бизнеса — обеспечивать развитие науки и технологии. На Highload очень много докладов, и за каждой — стоит тот, кто так думает. Из основного процесса развития технологии появляются боковички развития технологии: о — можно упаковать и продать. И это может быть сырая непонятная шняга. Или Технология как продукт — он рисковая, может быть голубой океан, а может — пусто. А может быть технология как коммерческий продукт. Но инженер об упаковке не думает. Он видел историю со светодиодами времен СССР: у нас развивали науку и рассказывали, а японцы упаковывали.
* Бердяев. Истоки и смысл русского коммунизма.
* Александр Зиновьев. Русская трагедия
* Аузан . Культурные коды экономики
* Эрик Мейер. Карта культурных различий
А начать можно с лекций Аузана, которые гуглятся по словам «Аузан Арзамас».
Книги про современную западную культуру.
* The beginers beginners guide to OKR
* Никаких правил — про Netflix
* Ким Скотт. Радикальная прямота
А я прочитал статьи, на которые были ссылки, сопоставил со своей картиной мира экономики и вот тезисно результат.
# Разница между стоимостью продажи некоторого продукта и стоимостью его создания имеет три компонента: (а) технологический, связанный с использованием более прогрессивных способов создания (обычно в виде машин и инструментов), чем используют другие; (б) организационный, связанный с организацией разделения труда и выполнения операций, которое повышает производительность и (в) рыночный, связанный с работой на том сегменте рынка. где продуктов почему-то не хватает или потребители о них не знают. Маркс фокусировался на (а) — капиталист владеет средствами производства, недоступными простому ремесленнику и потому забирает себе прибыль, связанную с технологичным производством. Шумпетер, насколько я представляю, рассматривал (б) — способ организации производства, который придумал предприниматель, а также (в) — знание предпринимателя о сегментах рынка и ставке на них. С (в) также связана теория, что предприниматель получает прибыль как премию за риск, на который он идет, делая ставку. Я вполне могу ошибаться, и недооценивать понимание Марксом компонентов (б) и (в). Но в любом случае, все ти компонента надо разделять, у них — разная природа.
# Когда консультант выполняет сложный консалтинг, он работает над повышением каких-то из этих трех компонентов за счет снижения стоимости производства либо выхода на более дорогие рыночные ниши, разный косалтинг — консалтинг — про разное. И таким образом он вносит свой вклад в систему создания продукта, получая эффект. И может претендовать на вознаграждение в виде доли, от этого эффекта. которая может быть велика. Либо, подразумевая эффект, просто назначать себе высокое вознаграждение. Поскольку продукт — уникальный, то его нельзя оценить рыночными методами, тут я согласен. Возможны лишь принятые практики, как формируется вознаграждение: за это обычно платим деньги, а за это — даем долю. Это не рыночное ценообразование и по-любому это — предмет переговоров.# По мере того, как труд из физического становится умственным, изменяется технологическая составляющая. Опыт ИТ показывает, что через технические средства + регламенты (организационная составляющая) высоких эффектов не достигнешь, начинает играть человеческий фактор. Получается высокий уровень индивидуализации производства каждого нового продукта (который тиражируется почти бесплатно). А дальше ИТ-шники с точки зрения вознаграждения становятся близки к консультантам, они могут запрашивать за свой труд сколько хотят, име6я имея ввиду высокую прибыль от продажи многих экземпляров удачного продукта на массовом рынке.
# Еще я подумал. что большинство теорий созданы вокруг самого массового явления — технологизированного труда сотрудников. который был самым массовым. Рынок труда в этом сегменте всегда профицитным, была безработица и желание получить работу. Сегмент дефицитных топовых специалистов, включая менеджеров, был относительно мал, и интересно — проводил ли кто из экономистов исследования в этом сегменте. Потому как именно он сейчас постепенно становится основным.
*: Максим Цепков: Любопытно. Аннотация — парадоксальная, за этим может быть конструктивное содержаение, а может стоять собственная идеология. Но пока книга только бумажная. Будет электронная — буду смотреть. Как я понял, книга написана по серии лекций, их видео есть в свободном доступе. А вообще Федор Гиренок — новый для меня автор, хотя, как я посмотрел на [https://fedor-girenok.ru/ его сайте], у него много книг и статей.
Еще интересное замечение замечание '''Rinat Enikeev''': Культура даже в названиях отделов проявляется.
:* Вместо Human Resources — People.
:* Вместо Management — Leadership.
Если цель — запустить ипотечную анкету на мобильных платформах. Отставание 10 дней, один из эпиков заблокирован смежниками. Метод изменений: в начале квартала сверять планы свои со смежниками. Цель по cycle time может быть не достигнута по той же причине.
Тимлид докапывается до причин, а руководитель тимлидов смотрит на светофор. Есть еще несоклько несколько метрик индексов: support ticket sla reaction, zero bug policy, crashes, LSR SLA
2. Настраиваем процессы чужими руками. Досталось легаси плохого качества, много пользователей обращались в поддержку. Обращения матчатся с багами, для каждого известно. Цель: привести HD count к целевому значению. И количество решенных тикетов от суппорта 10+. Дальше мониторили — и получилось успешно за пару кварталов. Потом вывели на мониторинг.
Рассказ начался с вопроса, что такое провал? Мы попробовали, сделали, но это не оказалось полезным. Это провал или нет? Ответ — итерация, мы потратили свое время и чужие деньги, чтобы уточнить картину мира. Полезный опыт.
Дальше была история. 1957 fairchild Fairchild semiconductor. 8 человек уволились от William Shockley, чтобы основать свою компанию, и основали ее как дочку fairchild, которая занималась разным. Они изобрели интегральную схему и начали делать, начали делать процессоры и память. Одновременно с Килби, было признано. В 1971 Don Hoefler написал статью про fairchild 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. Стабильность'''. Начинается на маленьком железе, старый сервер. Внутренние лучше внешних, они не уходят, осознают ресурсный голод. Но в какой-то момент не могут терпеть. Как оттянуть этот момент, и успеть сделать нормально?
Если от внутреннего сервиса не зависит продакшн — его не обязательно резервировать. Достаточно мониторить и вешать плашку «не работаю планово». И по входным данным — вести мониторинг, вешать плашку «мы уже знаем». Это как «мы адекватны и стараемся».
Мониторинг и информирование — важнее постоянной доступности.
'''4. Велосипеды'''. Однажды было нужно строить тепловую карту России по метрикам, по регионам. Маленькая команда, Apach Apache Superset — позволяет подобное делать. Но! Деление по регионам может быть не очень хорошим, Красноярский край — большой, надо дробить. А еще есть города — миллионники — они маленькие, людей много — их надо показывать специально. А еще состав региона надо уметь менять. Коробка — не поддерживает. В результате аналитик данных занимается тем, что пытается поставить точку в нужное место и другой борьбой с инструментом. В результате, пока боролись, другая команда напилила собственные карты, начала им предоставлять.
Готовые инструменты хороши для прототипов, но даже для MVP — не обязательно. Надо оценивать, не слишком ли он дорог. Часто на первом этапе нужно небольшое подмножество, но с нашлепкой, которую сложно сделать, и это проще сделать самим.
Доклад с одной сквозной историей о пользе нетворкинга и множестве частных. Основная идея: не бойтесь начать, и активно делайте. Потому что нетворкинг реально помогает достигать своих желаний и осуществлять мечты. Сила в том, что когда вам что-то нужно — вы знаете у кого спросить, и вам расскажут. Например, вы умеете шить одежду, захотели запустить производство — и вам расскажут процесс в деталях, ведь уметь шить — далеко не все. А еще через нетворкинг можно найти ресурсы. Но чтобы это случилось, надо активно знакомится, знать кто чем может помочь. Не когда у вас возник конкретных вопрос, а заранее, чтобы когда вопрос возник — уже было понятно кто ответит. При этом жизнь часто ходит очень извилистыми путями, но приводит в нужном направлении, если вы при этом активны и ловите моменты.
Это иллюстрирует сквозная история — о том, как Эрик хотел сделать курсы, и даже учился этому — но у него не получалось. Но однажды он попал в Гонку героев. Потому что до этого хотел попасть в спорт, было 100500 попыток, но не складывалось. А тут увидел в инстаграмме инстаграме фотку с гонки героев, где был его друг, узнал, решил в очередной раз попробовать, друг дал телефон — и этот вариант зашел. И он не просто участвовал, а стал инструктором, сдал необходимое, хотя для этого пришлось с другими инструкторами договориться о переносе даты экзамена, он не мог в назначенную. А потом был тренинг по публичным выступлениям, где он человек рассказывал про Яндекс-практикум, и он подумал, что это клевое место, пошел туда работать. Но с курсом не складывалось, надо было пройти обучение, а там не было вакансий. Однако, Гонка героев осталась, он собрал команду от Яндекса, только формально они опоздали, но поскольку руководитель по спорту в Яндексе тоже был инструктором в гонке героев, он договорился. А потом, на гонке, познакомился с девочкой QA-факультета, рассказал ей про мечту о курсе, его начала включили в середину обучения, а позднее у него получилось сделать курс, и он быстро нашел команду для этого за счет накопленных контактов. И таких историй у Эрика много.
Дальше были рекомендации. Они, в общем простые и достаточно известные.
Юлия сменила много предметок: телеком (управление железом, портал для сотрудников), DWH+BI, Порталы госуслуг, Атомные станции, e-com (озон). Погружение в новую область кому-то тяжело, кто-то обжигаешься, кому-то больно. И она рассказывала свои техники погружения, чтобы не было страхов. Приемы — простые, превратились в чек-лист. Это про предметную область, смену стека она полагает отдельной, хотя лично я не очень вижу разницы на уровне чек-листа. Дальше по пунктам.
'''1. Глоссарий'''. В новой сфере он свой, и там куча сокращений, сленга. Который ясен тем, кто работает внутри. Глоссарий часто собран в головах. И тогда надо сделать самому. И удобно сделать общедоступным. И не надо накапливать, заносить быстро, каждый день. При этом полезно не только понимать термины, но и самому начинать употреблять.
'''2. Волна непонятной информации'''. Визуализировать и собирать по крупицам. Как собирать паззл или вести расследование. Картинку сразу увидеть хочется, но ты не увидишь. Только вот в паззле есть целевой образ, а у нас — нет. Нужно место, и тоже надо обновлять регулярно, пару раз в неделю. И видеть прогресс. Стикеры в миро как процесс или сущности и связи или что-то еще. Схема процессов, но это — на любителя.
'''3. Множество новых контактов'''. В новом отделе 10-15 человек в принципе запомнишь через 2 недели. Но есть большие проекты, где в чате 1000 человек. Матрица взаимодействия, Миро или что-то еще. Кто за что отвечает.
Где брать на все это время? Реально достаточно 15 минут в день, как и с контактами. И надо каждый день. С визуализацией пореже, но тоже не накапливать.
'''4. Обязательно задавайте вопросы'''. Да, даже глупые, и если кажется, что это элементарно.Исnория — История — термин Mesh. Все употребяют, а она не знает. Но не спрашивает, спрашивает у коллег, а те — не знают. И полтора часа потерянного времени, потому что спросить надо было того, кто сказал. При чем выяснилось, что это — сленг, включить «как на проде»
Спрашивать надо своевременно. Рассказывают про червяка, во-время не спрашивают, надеется понять из контекста, не получается. Но когда полчаса говорили, сложно. А это на отгрузке зона, куда паллеты ставят. Или вопрос про имя через два дня знакомства.
Не бойся спрашивать у экспертов. Если у эксперта спрашиваешь «расскажи мне все» — он не знает, что ответить, он три года может рассказывать. Стоит в вопросе раскручивать от задаче, а потом идти вширь, если уместно. Не «какие бывают топологии сети», а «если роутер вышел из строя — как узнать топологии, в которых он включен»
'''5. Фокус на здесь и сейчас — сейчас''' — погружение через текущие задачи. Отбрасывать все лишнее. Беречь силы. Не распылять внимание. Иначе вас может накрыть, узнать все — не реально.
'''6. Практика'''. Наблюдай, как реально работает предметная область, если есть возможность. Если есть порталы, приложения, сайты — попробуй работать как пользователь. Посещая объекты, для которых работаешь — если есть возможность. В озоне она реально работала на складе, 12 часов. А на немецкой атомной станции, для которых работала, было без шансов. Погружение позволяет почувствовать требуемую эргономику.
'''7. Понять и простить. В первую очередь себя'''. Если мы принимаем решение о смене предметной области, надо заходить с пониманием на входе, что ты не понимаешь ничего. И не постигнешь все за неделю-две. Будут моменты, когда будет жестко накрывать, будете сидеть с кипящей головой. Обращаемся за помощью к себе самим, сила в нас. Тут помогает книга Е.Резанова «Это норм». А еще есть эксперты. Она ищет жертву среди экспертов, и просит рассказать, как он начинал, погружался. И в 90 % случаев они отвечают «я и сейчас не понимаю», а другие «первые полгода я не понимал». И тут становится легче. И можно явно попросить помощи, не обязательно сделать задачу за вас, а направить на правильный путь.
'''8. Погружение через обучение других'''. Когда начали понимать — помогайте, и при этом сам разбираешься.
И в конце это сведено в чек-лист: глоссарий, визуализация, карта взаимодействий, фокус на задачах, изучай в реальности что делаешь, не пытайся объять необъятное, изучай в реальности что делаешь, не пытайся объять необъятное, фокусируйся на своих сильных сторонах, обращайся к опыту и помощи экспертов, погружайся через помощь менее опытным.
# 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, в котором надо вести все эпики. И смогли посмотреть на работу всей компании однородно. Дальше надо было всех заставить там работать. Это — отдельный доклад. Был пилот на нескольких командах, потом директива. И это была первая итерация.
Вторая итерация — новый тип работ — инициатива. Инициатива — это направление бизнеса, нацеленное на изменение бизнес-метрик компании. К ним должны быть привязаны все эпики, и это дает связь эпиков со стратегией. И можно было увидеть, куда тратим время и ресурсы. Появилось единообразие полей, отчеты и метрики.
Этот путь требовал много работы: воркшопы обучения, шаблоны structure представления информации, дерево продуктовых меток, плагины wip-лимитов, доски под все нужды, дашборды визуализации работ, документация, сбор обратной связи, чат поддержки.
'''2. Метрики'''. Что есть эффективность для ИТ и как выражается? Проблема бизнеса: не понимаем, когда команда разработки это сделает. Постоянные переносы.
# 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, он понимает, как он на уровне всей компании влияет на то, что компания делает. А бизнес может по каждой команде посмотреть скорость работы, попадание в обещания и построить прогноз.
В вопросах к докладу: а как быть с социально ожидаемыми ответами? Она за прозрачность, может спросить «а насколько ты честен/откровенен со мной 1-10?», или даже явно «Я думаю, что ты тут не договариваешь примерно это», особенно если есть альтернативная информация. И это — помогает.
{{wl-publish: 2024-07-03 12:31:23 +0300 | MaksTsepkov }}

Навигация