Книжный куб

Конфа по архитектуре в Лемана Тех (Рубрика #Architecture) Сегодня я участвовал в панельной дискуссии на конфе по архитектуре в Лемана Тех (это ИТ компания бывшего Леруа), где мы обсуждали следующие вопросы 1. Управление архитектурными изменениями в быстро меняющемся мире 2. Сложные кейсы архитектуры: что делать, когда все не так, как должно быть? 3. Архитектурный репозиторий: как сделать его инструментом для всех? 4. Архитектор как посредник между бизнесом и ИТ: как говорить на одном языке? 5. Эффективное управление архитектурными изменениями: от идеи до внедрения В дискуссии мы вспоминали много разных тем и конкретно книгу "The Software Architect Elevator" Gregor Hohpe, про которую я вспоминал раньше. Суть была в том, что архитектору не стоит отрываться от земли и уходить в фантазии на N-том этаже своей башни, а стоит быть поблжие к земле и спускаться в машинный зал, где работают инженеры. Забавно, что после окончания конфы спикерам раздали подарки в сумке "Do it yourself", где были шуруповерты. В общем, я понял намек на то, что слова не должны расходиться с делами и обязательно воспользуюсь этим инструментом:) P.S. Попробую запись мини-выпуск с ответами на эти вопросы, если они вам интересны. Только напишите об этом в комменатриях. #Architecture #Software #Management #Leadership

Митпа "AI в Software Engineering" в Т-Банке (Рубрика #AI) Вечером 4 марта в офисе Т-Банка в Москве пройдет митап о том, как AI трансформируют инженерные практики. На митапе будет разговор о том, куда движется RnD в разработке софта и какие у нас есть результаты на этом пути. Мои коллеги продемонстрируют реальные примеры внедрения AI в разные этапы SDLC (software development life cycle). Также будет разговор о том, какие это риски несет: новые security-уязвимости, снижение квалификации инженеров, а также фокус на качестве поддержки AI-генерируемого кода. В митапе примут участие эксперты из RnD центров и техлиды индустрии. В общем, на митапе будет полезно и интересно. P.S. Я недавно был на стратсессии нашего RnD центра и знаком с направлениями исследований, поэтому точно могу сказать, что у ребят есть что там рассказать. #AI #Software #Engineering #Architecture #RnD

[2/2] This Year in Uber’s AI-Driven Developer Productivity Revolution (Рубрика #DevEx) В продолжении рассказа, я опишу подход ребятк генерации тестов и миграциям ——— Generating tests ——— - Ребята используют стандартную пирамиду тестирования, где сквозные тесты на вершине, модульные тесты внизу - Собственно вот идеи для использования AI в тестировании: -- Сквозное тестирование при помощи AI-агентов. Забавно, что мы у себя пытались лет 5 назад прикрутить crowd тестирование, где e2e проверяли ребята из Klex, нашего внутреннего инструмента типа Я Толоки. А сейчас мможно не крауд привлекать, а AI агентов -- Анализ качества тестов (мутационное тестирование) -- Предиктивный выбор тестов для ускорения прогонов -- А на нижнем уровне можно использовать AI для генерации unit тестов - Так ребята сделали Autocover с фокусом на регрессионных тестах, повышения code coverage и оставляя разработчиков в цикле взаимодействия с autocover (keep the developer-in-the-loop). Интересно, что ребята делят этапы работы над тестами на детерменистические, а также на вероятностые ——— Java to Kotlin migration ——— - В Uber исторически было много Java кода, постепенно ребята подсели на Kotlin и потом решили полностю мигрировать на него - Платформенная команда сделала инструмент миграции и предоставила его продуктовым командам в децентрализованном режиме - Если это делать это постепенно и в ручном режиме, то это миграция закончится где-то за 10 лет, что не попадало в ожидания - Ребята решили это автоматизировать причем с использованием AI - Для этого они решили объединить подходы на основе анализа AST (abstract syntax tree) и LLM для улучшения правил работы с AST деревьями - Этот подход позволил им ускорить процесс миграции где-то на порядок Итого, ребята в Uber оптимистично смотрят на применение AI в SDLC, но отмечают, что важно правильно выбирать метрики для оценки эффекта улучшений и их побочных эффектов. Они предлагают использовать метрику времени сэкономленного для разработчиков (saved developer hours). Мне это напомнило метрику на часы просмотренного видео через Youtube. Подробнее в моем обзоре книги "Like, Comment, Subscribe" ("Youtube. Как самый популярный видеохостинг завоевал мир?"). #Management #Leadership #Software #SoftwareDevelopment #Metrics #Devops #Processes #AI #ML #DevEx

[2/2] This Year in Uber’s AI-Driven Developer Productivity Revolution (Рубрика #DevEx) В продолжении рассказа расскажу про подход к генерации тестов и миграциям ——— Generating tests ——— - Ребята используют стандартную пирамиду тестирования, где сквозные тесты на вершине, модульные тесты внизу - Собственно вот идеи для использования AI в тестировании: -- Сквозное тестирование при помощи AI-агентов. Забавно, что мы у себя пытались лет 5 назад прикрутить crowd тестирование, где e2e проверяли ребята из Klex, нашего внутреннего инструмента типа Я Толоки. А сейчас мможно не крауд привлекать, а AI агентов -- Анализ качества тестов (мутационное тестирование) -- Предиктивный выбор тестов для ускорения прогонов -- А на нижнем уровне можно использовать AI для генерации unit тестов - Так ребята сделали Autocover с фокусом на регрессионных тестах, повышения code coverage и оставляя разработчиков в цикле взаимодействия с autocover (keep the developer-in-the-loop). Интересно, что ребята делят этапы работы над тестами на детерменистические, а также на вероятностые ——— Java to Kotlin migration ——— - В Uber исторически было много Java кода, постепенно ребята подсели на Kotlin и потом решили полностю мигрировать на него - Платформенная команда сделала инструмент миграции и предоставила его продуктовым командам в децентрализованном режиме - Если это делать это постепенно и в ручном режиме, то это миграция закончится где-то за 10 лет, что не попадало в ожидания - Ребята решили это автоматизировать причем с использованием AI - Для этого они решили объединить подходы на основе анализа AST (abstract syntax tree) и LLM для улучшения правил работы с AST деревьями - Этот подход позволил им ускорить процесс миграции где-то на порядок Итого, ребята в Uber оптимистично смотрят на применение AI в SDLC, но отмечают, что важно правильно выбирать метрики для оценки эффекта улучшений и их побочных эффектов. Они предлагают использовать метрику времени сэкономленного для разработчиков (saved developer hours). Мне это напомнило метрику на часы просмотренного видео через Youtube. Подробнее в моем обзоре книги "Like, Comment, Subscribe" ("Youtube. Как самый популярный видеохостинг завоевал мир?"). #Management #Leadership #Software #SoftwareDevelopment #Metrics #Devops #Processes #AI #ML #DevEx

[1/2] This Year in Uber’s AI-Driven Developer Productivity Revolution (Рубрика #DevEx) Интересное выступление от ребят из Uber на тему developer productivity, в котором они рассказали про свой подход к использованию AI для его повышения. Подробнее о деталях можно почитать здесь, а ниже я расскажу основные мысли выступления - Uber - это крупная мультинациональня компания с распределенными командами, 156+ млн MAU, 30M поездок в день, 10к городов - В компании есть IDP (internal developer platform), внутренняя платформа разработки, которая помогает инженерам в их деятельности - Ребята в платформе фокусируются не на тулинге, а на удобстве инженеров и ориентируются на NPS (net promoter score) - Uber сталкивается с проблемами техдолга и необходимости миграций кодовой базы, также у них сейчас тоже есть тренд на flat headcount и "do more with less". В итоге, они решили фокусироваться на использовании AI для повышения продуктивности инженеров - Для решения этих задач была создана отдельная платформенная команды для работы на AI developer experience, которая включает инженеров из всех платформ + специалистов в ML, которые предоставляют модели и абстракции для создания инструментов на основе ИИ. - Uber практикует AI-хакатоны еще с 2022 года, а сейчас строит свои агентские решения строит на LangChain - Фокус в применении AI в SDLC был на трех моментах: coding assistance, generating tests, java to kotlin migrations ——— Code assistance ——— - В качестве coding assistant в Uber использовали Copilot, но потом возникла гипотеза, что нужен свой ассистент с дообученной на своем коде моделью. Для этой модели выставили критерии успешности: +10% acceptance rate, latency меньше 1s на 100 токенов, экономическая эффективность, а также интеграция ассистента в рабочие процессы. Проект включал разработку MVP и оценку эффективности различных AI решений - Проект потребовал много ресурсов и времени, но за полгода MVP было готово. Дальше авторы оценили результаты и решили остановить проект с такими выводами

- MVPs are easy, productionisation is hard - Latency requirements vary per tool - User Experience matters - UI surface cannibalization is a risk - Follow ecosystem principle - Continuously evaluate landscape

- Вывод был в том, чтобы использовать индустриальные инструменты, но смогли переиспользовать из своего MVP части про -- Code context gathering - Summarize & rank code context to provide best input to use-cases (data race fixer, linter warning fixer, crash fixer) -- Gather telemetry -- Fine-tuned LLM - Custom model with knowledge of internal libraries, custom frameworks, and company-specific best practices - Помимо ассистента по коду ребята сделали ассистента для вопросов по базе монореп, которых в Uber 6:) Также ребята проводят воркшопы для обучения инженеров лучшим практикам использования AI, а также активно евангелизируют подход внутри - В будущем планируют добавить -- Интеграция с платформами, такими как VS Code и Xcode. -- Vendor fine tuning и дополнительные возможности по расширению функционала ассистента -- Использование инструментов для аналитики и рабочих процессов Продолжение обзора в следующем посте. #Management #Leadership #Software #SoftwareDevelopment #Metrics #Devops #Processes #AI #ML #DevEx

Code of Leadership #29 "Think like a CTO" (Рубрика #Management) В очередном выпуске подкаста Code of Leadership обсуждается неоднозначная книга "Think like a CTO" ("Думай как CTO"). В разборе помогает крутой гость, Саша Шевченко. Саша - мой коллега, который является техническим руководителем в управлении цифровых экосистем. Возглавляет 10+ продуктовых команд мобильного банка. Под его управлением развивается главный экран и приватный профиль, треки UX, ESG и не-клиентов, и другие ключевые продукты и сервисы. Кстати, я уже рассказывал про эту книгу в двух частях: 1 и 2 Выпуск доступен в Youtube, VK, Podster.fm, Ya Music За час мы успели обсудить темы - Роль и зоны ответственности CTO - Жизненный цикл компании и как меняется роль CTO - Управление ожиданиями и коммуникация - Формирование команды и её управление - Технологическая стратегия и долгосрочное видение - Управление бюджетом и проектами - Качество инженерных практик: QA, reliability, security, ... - Процессы и важность документации - Саморазвитие и подготовка преемника Рекомендации для изучения от Саши Шевченко Управление - "Идеальный руководитель" | Адизес Ицхак - подробнее в моем посте - "Карьера Software Engineering Manager" | Стэньер Джеймс - есть у меня на полке, но пока не прочитал - "The Elegant Puzzle" ("Элегантная головоломка") | Уилл Ларсон - разбирали вместе с Eugene Sergueev в эпизодах Code of Leadership 9 и Code of Leadership 10 Лидерство - "Вызов лидерства. Пять практик выдающихся руководителей" | Джеймс Кузес, Барри Познер - "Turn the ship around" ("Разверните ваш корабль") | Дэвид Марке - разбирали вместе с Екатериной Шестимеровой в Code of Leadership 4 - "The Five Dysfunctions of a Team" ("Пять пороков команды") | Патрик Ленсиони - разбирали вместе с Андреем Соколовым в Code of Leadership 16 - "Servant Leadership", "Ситуационное лидерство", "Management 3.0" - книгу про "Management 3.0" я прочитал на 2/3 пару лет назад, но не смог дочитать из-за феерического количества отсылок на другие книги от автора Создание команд ⁃ "Team Topologies" | Skelton Matthew - разбирали со Стасом Халупом в Code of Leadership 1 - "Реальные полномочия. Самостоятельность сотрудников как ключ к успеху" | Шоул Джон - "Шесть гениев команды" | Патрик Ленсиони - есть у меня на полке, но пока не читал - "Уроки выдающихся лидеров" | Питер Симс - Модель Такмана - Обратный маневр Конвея Разработка - "Learning DDD" ("Изучаем DDD предметно-ориентированное проектирование") | Хононов В - я много писал про книгу и даже обсуждал ее с автором - "Accelerate" ("Ускоряйся!") | Форсгрен Николь - разбирали вместе с Игорем Курочкиным в Code of Leadership 13 - "Site Reliability Engineering" | Бейер Б - я уже рассказывал про книгу - "Building Secure and Reliable Systems" ("Безопасные и надежные системы") | Адкинс Х. - я уже рассказывал про эту книгу - Data Mesh. Новая парадигма работы с данными | Дегани Ж. Романы про разработку - Проект «Феникс» | Джин Ким - обсуждали книгу с Иваном Михеевым в Code of Leadership 5 - Цель. Процесс непрерывного улучшения| Голдратт - - Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения | ДеМарко Том Управление изменениями - Наш айсберг тает. Как добиться результата в условиях изменений | Коттер - я уже рассказывал про эту книгу - Восхождение по спирали. Теория и практика реформирования организаций | Марк Розин В книге так же есть отсылки к - Думай медленно... решай быстро | Даниэль Канеман - я уже рассказывал про эту книгу - Невозвратным затратам или эффекту Конкорда - Кривой Гартнера - недавно рассказывал про нее #Management #Leadership #Strategy #PlatformEngineering #Engineering #Software #Architecture #SelfDevelopment

#60 – Agile Metrics (Рубрика #Management) Наткнулся тут на очередной комикс от Comic Agile на этот раз на тему метрик, которая является очень интересной. Авторы комикса заслуженно иронизируют над velocity, burndown, predictability, lead time и business value, обыгрывая стандартные способы покраски этот метрик в зеленый. Дальше они отмечают, что эти метрики могут помогать с идентификацией зон для улучшений, но по их скромному мнению есть 2 метрики, что стоит мерить - NPS (net promoter score) - удовлетверенность клиентов - The hapiness of team members - удовлетворенность членов команды Забавно, что NPS - это супер-общая метрика, которую сейчас берут все и используют по принципу "не знаешь что показывать по продукту - покажи NPS". А вторую метрику авторы предлагают мерить при помощи Spotify Squad Health Check, про который я рассказывал раньше (1 и 2). Интересно, что эти метрики как и остальные приведенные в обсуждении могут быть испорчены, например, продукт есть и пользователи им довольны, команда тоже довольна своей работой, только фичи не катятся - а смысл напрягаться, когда NPS высокий:) Но дальше авторы говорят коронную фразу про outcome

We must remember that working agile is a means to an end and not the goal, itself. Therefore, thinking about what outcome we want by working agile is what we should measure.

В итоге, мысль про метрики, что рекомендуют автры, так и остается нераскрытой. #Management #Leadership #Engineering #Software #Metrics

[2/2] The Mythical Man-Month (Мифический человеко-месяц) Продолжая рассказ про классическую книгу Брукса (1 и 2), расскажу про то, в какую сторону его идеи можно развивать сейчас 1) Для профилактики задержек в графике сдачи проекта - Не стоит копить техдолг, который выстрелит ближе к сдаче проекта - Не стоит использовать мифические человеко-месяцы, а взять метрики реальной производительности: cycle time, throughput и другие 2) Архитектурные принципы - Стоит поддерживать концептуальную целостность с самого начала проекта - я бы тут предложил использовать RFC (request for comments) для обсуждения архитектурных вопросов, решения фиксировать в ADR (architecture decision records). Я про это как-то рассказывал в докладе про масштабирование архитектурных процессов лет 5 назад - Также стоит инвестировать в документацию, положить ее поближе к коду и максимально автоматизировать 3) Коммуникации - Желательно сократить по максимуму встреча, а те что исчезли перевести в асинхронный режим, а значить писать больше документов и комментить их асинхронно - Выделять сфокусированное время для работы - это позволит не рвать поток работа (flow state) 4) Масштабирование команд - Здесь я просто рекомендую глянуть подход из Team Topologies, который хорошо описывать типа команд и форматы их взаимодействия. Про эту книгу я много рассказывал и даже разбирал в первой серии подкаста Code of Leadership вместе со Стасом Халупом, моим бывшим коллегой - По-факту, тут получается 2 основных типа команд: stream-aligned и platform. Первая наносит бизнесовую пользу, а вторая делает платформенные инструменты, что используют stream-aligned команды - Ну и важно учитывать числа Донбара для понимания границ масштабирования из-за накладных расходов на коммуникации Если подводить итоги, то книга Брукса до сих пор не устарела и может быть применена к современным проблемам. Несмотря на то что Agile и DevOps решают проблемы *случайной сложности*, его предупреждения о перегрузке ресурсами и фрагментации дизайна остаются актуальными. Команды достигают устойчивой продуктивности благодаря балансу автоматизации и процессов, ориентированных на людей — подтверждая взгляд Брукса на разработку ПО как на процесс, прежде всего зависящий от человеческого фактора. В условиях роста масштабов распределенных систем возвращение к идеям *Мифического человеко-месяца* предлагает как предостережения, так и вдохновение: инструменты меняются, но динамика команд определяет успех проекта. #Management #Leadership #Software #Engineering #Process #Project #Architecture #DevOps

Предпоказ спектакля «Лукич» в Мельник центре (Рубрика #ForKids) Вчера днем мы были на детской постановке "Лукич" в Мельник Центре. Это было новое прочтение «Чиполлино» для детей 6+, но мы взяли с собой четерехлетного и девятилетнего сына - обоим понравилось. Нам с женой постановка тоже показалась интересной, так как юмор был двухуровневым - детишки смеялись над гэгами и поведением героев, а взрослые на отсылки к окружающей реальности или намеки на романтические взаимоотношения овощей. Сам спектакль был в двух частях. В первом акте принц Лимон и рыцарь Помидор захватили власть в саду, а остальные овощи с переменным успехом боролись с ними. Второй акт начинается с того, что Лукич и другие овощи оказались за решеткой, но Черешенка, замотивированный Клубничкой, отправился их спасать ... В общем, постановка была авангардной, включала музыку, шутки и вообще смотрелась бодро и динамично. Главное, что детишки были в восторге и классно провели время, а родители тоже не скучали. #ForKids #ForParents #Culture

Обложка для книг "The Mythical Man-Month" и "Мифический человеко-месяц)"

[1/2] The Mythical Man-Month (Мифический человеко-месяц) (Рубрика #Management) Эта книга Фредерика Брукса была впервые издана 50 лет назад, в 1975 года, но она до сих пор переиздается, а цитаты из нее стали классическими. Я решил вспомнить про нее к юбилею и посмотреть насколько она еще актуальна. В заглавие книги вынесена идея о том, что "добавление сотрудников в отстающий проект только увеличивает задержки" из-за роста коммуникационных издержек, времени на адаптацию новых членов команды и неделимости некоторых задач. Брукс критикует ошибочное предположение, что труд (измеряемый в «человеко-месяцах») можно масштабировать линейно, сравнивая это с невозможностью девяти женщин родить ребенка за один месяц. Это относится к области управления проектом/продуктом и так же актуально, как было 50 лет назад. Еще он подчеркивает важность концептуальной целостности — согласованной архитектуры системы под руководством единого видения — для предотвращения хаоса, вызванного "проектированием при помощи комитетов". Этот тезис относится к проектированию софта. Следующая ключевая идея относится к "эффекту второй системы" (перегрузка сложностью при создании следующей версии). Вот эта проблема кажется уже решена, так как продукты часто сейчас строятся итеративно и понятие версии системы вообще размывается:) Ну и последняя идея, которую стоит отметить - это различие между essential complexity (существенной сложностью, что присуща задаче) и accidental complexity (случайной сложностью, которая возникает из-за неэффективных инструментов или процессов). Если провести параллели между разработкой во времена Брукса (1970-е годы и засилье мейнфреймов), то мы получим следующее 1) Закон Брукса vs Agile и гибридной работы - Agile подходы снижают риск неожиданностей и даже работая проектно мы на поздних стадиях получаем меньше рисков, это соответствует мыслям Брукса о важности прототипирования в больших проектах - Гибридная работа - современные инструменты (GitHub, Jira, Slack) снижают барьеры для коммуникаций, но правило про квадратичный рост затрат на коммуникацию от роста команды никуда не девается (помним, что в полном графе n*(n-1)/2 связей) - Брукс рекомендовал использовать локализованные "хирургические команды", а у нас теперь есть two-pizza teams 2) Модульность и мокросервисы - У Брукса вызывала опасения монолитная система, что они делали для мейнфрейма, но в наше время у нас пронеслись перед глазами SOA, микросервисы, FaaS и теперь людям монолит уже не кажется таким плохим вариантом для старта - По-факту, нам нужна модульность нашего кода, а как он разворачивается можно решить потом (условно модульный монолит можно нормально разделить на отдельные микросервисы при необходимости) 3) Инструменты против человеческого фактора - Одна из ключевых мыслей Брукса была про то, что серебрянной пули для повышения производительности разработки нет - Но мы видим, что хорошие инженерные практики постепенно повышали продуктивность инженеров - речь про CI/CD и всю автоматизацию - А сейчас мы живем во время, когда щепотка AI, добавленная в SDLC (software development life cycle) навроде GitHub Copilot обещает в будущем грандиозный эффект (если LLM продолжат также прогрессировать) - Но пока мы все еще видим AI в качестве ассистента, а значит нам нужно обращать внимание на человеческий фактор, тут есть классная колонка про "Human approach to developer productivity" от Google, про которую я уже рассказывал раньше #Management #Leadership #Software #Engineering #Process #Project #Architecture #DevOps

Картинка с самим Gartner 2024 Hype Cycle for Emerging Technologies

Gartner 2024 Hype Cycle for Emerging Technologies (Рубрика #Management) Недавно столкнулся с картинкой из отчета "Gartner Hype Cycle™ for Emerging Technologies", что вышел летом прошлого года. Несмотря на то, что это по большей части маркетинг Gartner как тренд сеттера в технологиях, часто бывает интересно глянуть отчет и посмотреть, а что в нем есть кроме красивой картинки. Конкретно в этом отчете перечислены 25 прорывных технологий, сгруппированных в самые хайповые темы Autonomous AI (автономный ИИ), Developer Productivity (продуктивность разработчиков), Total Experience (общий опыт), and Human-Centric Security and Privacy (ориентированная на человека безопасность и конфиденциальность). Именно эти темы будут определять будущее бизнеса и технологий в ближайшие годы по мнению Gartner 1. Autonomous AI (автономный ИИ) Здесь фокус на развитии ИИ-систем, способных выполнять задачи с минимальным участием человека. Эта тема включает в себя такие технологии, как мультиагентные системы, обучение с подкреплением, гуманоидные роботы и machine customers. Для бизнес это означает переход к системам ИИ, которые могут динамически взаимодействовать с окружающей средой и принимать решения в сложных сценариях. 2. Developer Productivity (продуктивность разработчиков) Здесь объединены инструменты и подходы для повышения эффективности работы разработчиков. Основные технологии: ИИ для поддержки разработки ПО, GitOps, prompt engineering и внутренние порталы для разработчиков. Цель — создать условия для "потока" в работе разработчиков, улучшая их удовлетворенность, сотрудничество и качество результатов. Я на эту тему много уже писал на канале, например, "Как и зачем измерять инженерную продуктивность в крупной компании" 3. Total Experience (общий опыт) Этот пункт объединяет стратегии клиентского опыта (CX), опыта сотрудников (EX), пользовательского опыта (UX) и многоканального взаимодействия (MX). Здесь авторы говорят про такие технологии, как цифровые двойники клиентов, пространственные вычисления, суперприложения и 6G. Здесь цель в том, чтобы обеспечить бесшовное взаимодействие на всех точках контакта для повышения удовлетворенности, лояльности и вовлеченности. 4. Human-Centric Security and Privacy (ориентированная на человека безопасность и конфиденциальность) Эта тема направлена на создание доверия за счет мер безопасности, которые учитывают пользовательский опыт и совместное управление рисками. Конкретные технологии такие: AI TRISM (управление доверием, рисками и безопасностью ИИ), цифровые иммунные системы и архитектура сетевой безопасности. Здесь поощряется прозрачность, этичность и проактивное выявление угроз для повышения устойчивости организаций. Эти темы отражают стратегический подход к использованию новых технологий для трансформации бизнеса при решении таких вызовов, как чрезмерная автоматизация, проблемы конфиденциальности данных и необходимость этических рамок. #Strategy #Management #Leadership

CTO Conf X (Рубрика #Management) В этом году пройдет CTO Conf X, первая профессиональная конференция для технических директоров, от компании "Онтико". Я много выступал на других конференциях этой компании, например, Highload++, Teamlead Conf, Teachlead Conf, а теперь вошел в программный комитет этой новой конференции. Мы в программном комитете долго обсуждали какие доклады будут полезны посетителям конференции и получилось следующее - Как CTO быть партнером бизнесу, а не просто исполнителем - Как CTO создавать и актуализировать технологическую стратегию - Как не утонуть в операционке и уделять еще время стратегии и тактике - Как управлять командами разработки на масштабе (когда помнить все про всех уже не возможно) - Как и зачем появляются внутренние платформы разработки (IDP) внутри компаний - Как CTO смотрят на использование AI в SDLC (Software Development Life Cycle) Я думаю, что у нас получиться собрать крутую программу конференции и она принесет пользу тем, кто ее посетит. Если вы планируете посетить конфу, то самое время купить билет со скидкой, а если вы хотите выступить, то еще можно отправить заявку на доклад. P.S. Интересно, что еще до появления этой конференции я часто сам рассказывал доклады, которые могли бы присутствовать на ней: - Что такое CTO от стартапа до IPO, или трансформация роли CTO по мере роста компании - Highload++ 2021 - Как нанимать технических руководителей - Teamlead Conf 2023 - Эволюция роли технического руководителя от инженера до CTO - SouthHub 2022 - Как формировать структуру команд под запросы бизнеса - YaTalks 2023 - Как и зачем измерять инженерную продуктивность в крупной компании - MTS True Tech Days 2024 #Management #Leadership #Strategy #PlatformEngineering #Engineering #Software #Architecture

10 Developer Productivity Boosts from Generative AI (Рубрика #DevEx) Глянул очередное интересное и короткое видео от Martin Keen, IBM Fellow, который за много лет в IBM проявил себя как изобретатель (больше 400 патентов), технический руководитель, исследователь в AI, а также создатель контента на канале IBM Technology. В этом видео Мартин рассказывает про то, как Gen AI может помочь повысить продуктивность разработчиков, а я про эту тему рассказывал много и подробно раньше, например, в последнем докладе про то, как и зачем мерить developer productivity. Но давайте вернемся к мыслям Мартина 1) Elemenating repetitive tasks. Генеративный ИИ может помочь исключить повторяющиеся задачи, ускоряя рутинную работу. 2) Natural language interface. Интерфейс на естественном языке позволяет запрашивать генерацию кода и контроль версий. 3) Code suggestions. Подсказки помогают начать работу с незнакомыми библиотеками и пакетами. 4) Code improvements. Это улучшения для устранения избыточных и неэффективных частей кода, почти как при pair programming, но где пару составляет AI ассистент 5) Code translation. Трансляции кода с одного языка на другой, которая может быть полезна для масшабной миграции, например, со Scala на Java/Kotlin 6) Code testing. ИИ может создавать тестовые сценарии и оценивать результаты. 7) Bug detection. Автоматическая идентификация и даже исправление багов 😍 Personalized dev environment. Как я понял это история про тюнинг IDE и других инструментов под стиль разработчика 9) Generation documentation. Генерация документации на основе кода В конце автор говорит о том, что сейчас Gen AI скорее не замена разработчика, а помощь для расширения его возможностей. Это хорошо перекликается с мыслями из статьи "What Do Developers Want From AI?", про которую я рассказывал раньше. P.S. Автор не забыл про десятый пункт - он предложил зрителем самим написать в комментах:) P.P.S. У Мартина есть интересное видео про тренды AI в 2025 году, про которое я уже писал в канале. #Management #Leadership #Software #SoftwareDevelopment #Metrics #Devops #Processes #AI #ML #DevEx

Как я чувствую себя, когда иду на работу ... А вообще это обычный поход моего младшего сына в сад.

Research Insights Made Simple #8 "Measuring developer goals" (Рубрика #DevEx) В этом выпуске подкаста про инсайты ко мне в гости пришел Александр Кусургашев для того, чтобы поговорить про гугловую статью "Measuring developer goals":) Александр работает в Т-Банке в подразделении Core Tech и занимается развитием нашей внутренней платформы разработки. Он верит в законы физики, платформизацию и пользу от переиспользования. Для него важно, чтобы IT системы Т-Банка работали эффективно - от уровня физической инфраструктуры до конечных сервисов для потребителей. Большую часть своей IT карьеры Саша провел разрабатывая платформенные решения для low latency и ultra low latency electronic trading. За время подкаста мы обсудили темы: - Опыт работы Саши и его зона ответственности в Т-Банке - Обсуждение critical user journeys для определения измеримых и объективных целей инженеров - Гранулярность и декомпозиция целей - Комплексный подход к оптимизации - Важность систематического процесса выделения целей - Эволюция обратной связи в опросах Engineering Satisfaction Survey - Переход от инструментов к целям - Измерение метрик и мониторинг процессов - Вариативность инструментов и сложность стандартизации - Научный подход к улучшению процессов Выпуск доступен на Youtube, VK, Podster.fm, Ya Music P.S. Я уже разбирал этот whitepaper полгода назад. #Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

Обложка книги "Digital Nudge" и немного примеров применения концепции

Digital Nudge (Рубрика #Management) Полгода назад мне подарили эту книгу, но прочитал я ее на днях. В ней Fabio Pereira рассказывает про базовые принципы поведенческой экономики, которые могут быть применены в цифровом миру для тонкого влияния на решения и поведение пользователей. Автор вводит концепцию digital nudging или цифрового подталкивания, которая представляет собой использование тонких элементов дизайна, информации и взаимодействия в цифровой среде для управления поведением пользователей без ограничения их свободы выбора. По-факту, это адаптация nudge theory Ричарда Талера и Касса Састейна из книги "Nudge". Правда, digital nudge адаптирован к цифровому контексту, например, веб-сайтам, приложениям или онлайн-платформам, и используют элементы интерфейса, такие как настройки по умолчанию, визуальные подсказки, персонализированные рекомендации и своевременные уведомления для влияния на принятие решений. Оснонвые идеи книги 1) Choice architecture (архитектура выбора): То, как представлены варианты выбора в цифровой среде, может существенно влиять на поведение пользователей. Например, настройки по умолчанию (например, автоматическое продление подписок) часто направляют пользователей к определенным действиям. 2) Behavioral triggers (психологические триггеры): Цифровые "подталкивания" опираются на психологические принципы, такие как социальное доказательство (например, отзывы пользователей), дефицит (например, "Осталось всего 3 товара") и избегание потерь для стимулирования желаемого поведения. 3) Personalization (персонализация): "Подталкивания" могут быть адаптированы на основе данных о пользователях, таких как предпочтения или действия в реальном времени, для повышения их эффективности. 4) Low-cost interventions (дешевые интервенции): Цифровые "подталкивания" недороги и минимально навязчивы, что делает их масштабируемым решением для влияния на поведение в разных областях Автор приводит большой список примеров использования digital nudges - Электронная коммерция: Выделение ограниченных по времени предложений или персонализированных рекомендаций для увеличения продаж. - Здоровье и фитнес: Стимулирование более здорового образа жизни или регулярных тренировок через напоминания и элементы геймификации. - Продуктивность на работе: Подталкивание сотрудников к выполнению задач или освоению новых инструментов с помощью целевых уведомлений. - Образование: Повышение вовлеченности студентов с помощью интерактивных учебных материалов и функций отслеживания прогресса. Эта книга связана с другими - "Nudge: Improving Decisions About Health, Wealth, and Happiness" Ричарда Талера и Касса Санстейна — основополагающая работа о теории "подталкивания". - "Hooked: How to Build Habit-Forming Products" ("На крючке") - эта книга Нира Эяля о том, как создавать продукты, которые захватывают пользователей и становятся неотъемлемой частью их повседневной жизни. Я про нее уже рассказывал - "Thinking, Fast and Slow" ("Думай медленно... решай быстро") Даниэля Канемана — исследует психологические системы принятия решений. Я про нее уже рассказывал - "Predictably Irrational" ("Предсказуемая иррациональность") Дэна Ариели — объясняет, почему люди принимают иррациональные решения и как на них можно влиять.Я про нее уже рассказывал - "Inside the Nudge Unit" Дэвида Хэлперна — о практическом применении теории "подталкивания" в государственной политике. - "Misbehaving: The Making of Behavioral Economics" Ричарда Талера — рассказывает о развитии поведенческой экономики как научной дисциплины. Эти книги предоставляют более глубокое понимание поведенческой экономики и науки о принятии решений, дополняя темы из Digital Nudge. А вообще, сама книга "Digital nudge" очень простая и легкая, а поэтому хорошо подходит для того, чтобы познакомиться с этой темой. P.S. Я уже рассказывал про пару выступлений Фабио конференциях, из которых можно сложить отличное представление о самой концепции digital nudge - The Psychology of UX - Infobesity - How to Cope with the Overload of Information #Thinking #PopularScience #SelfDevelopment #Brain #Economics #Psychology

[2/2] Behavioral Interview Discussion with Ex-Meta Hiring Committee Member (Рубрика #Management) Продолжу рассказ про поведенческие интервью в зарубежных бигтехах, который я начал в первом посте. 9) Кандидатам важно уметь правильно презентовать свой опыт, а для этого важно понимать свои достижения и проекты, а также соотнести свои проекты с ценностями компании 10) Важно правильно выбирать проекты для рассказа. Например, автор рекомендует делить проекты по личному участию, влиянию на бизнес и масштабу. Важно, чтобы о выбранных проектах можно было интересно рассказать (рассказ об унылом проекте вгоняет интервьюера в депрессию) 11) На интервью часто задают вопросы об совершенных ошибках. Не стоит отвечать, что их не было - все люди ошибаются, но хорошие кандидаты признают ошибки и учаться на них (а лучшие учатся еще и на чужих ошибка) 12) Помимо ошибок интервьюер может спросить про слабости кандидата. Не стоит отвечать на них, что их нет или "Я - трудоголик", важно признавать свои слабости, а если еще рассказать про извлеченные из них уроки, то будет еще лучше. Но для интервьера важна честность и искренность, наигранные рассказы не принесут вистов 13) При подготовке к интервью важно подумать о том, а как показать, что вы подходите команде и решаете похожие задачи и сможете принести пользу новой компании. Лучше всего показать это через то, чтобы показать как вы добились реальных результатов на прошлом месте и принесли пользу бизнесу 14) При подготовке к интервью будьте готовы рассказать о себе, любимом проекте, а также конфликтной ситуации. В принципе, можно подготовить еще набор историй, привязанных к ценностям компании, а также отсортированных по масштабу, личному участию и импакту. Это поможет вам на интервью проще подбирать примеры из своего опыта под вопросы интервьюера 15) В конце интервью часто есть время на то, чтобы задать вопросы интервьюеру - это важный момент для того, чтобы продемонстировать интересе к компании и команде (если вас смотрят в конкретную команду), например можно задать вопросы про - О развитии отдела и технологий - О стиле управления нанимающего менеджера и динамике команды В принципе, все советы достаточно логичные и помогут не просто подготовиться к интервью, а запустить процесс рефлексии о своем рабочем опыте и своих ожиданиях от дальнейшего места. Поэтому рекомендую поразмышлять о них, даже если вы не ищите работу:) P.S. Я как-то рассказывл про то, как мы нанимаем - Технических руководителей - Staff+ инженеров В принципе, многие советы Остина полезны и для подготовки к нашим интервью. #Management #Software #Processes #Project #ProductManagement #Engineering #Processes #Leadership #Staff #Architecture #Career