Книжный куб

Опрос, который изменил опросы (Рубрика #Math) Интересная научная статья о почтовом опросе 1936 года, проведенного крупной и уважаемой газетой "The Literary Digest" среди своих двух миллионов подписчиков. Данный опрос был проведен перед очередными выборами президента США и подписчики просто должны были выбрать кандидата, которого они будут поддерживать на выборах. Результаты опроса предсказывали уверенную победу республиканского кандидата, а реальность выдала противоположный результат - а именно победу демократа с полуторным преимуществом. Такое расхождение в прогнозе и фактах в итоге привело к закрытию газеты, а причина была всего лишь в том, что журнал не принимал во внимание факт того, что на точность прогноза критически влияет репрезентативность выборки из генеральной совокупности:)) А если по простому, то для получения правдоподобных результатов надо правильно формировать множество тех, кто будет проходить опрос. P.S. После таких историй почему-то вспоминается крылатая фраза

Есть три вида лжи: ложь, наглая ложь и статистика.

которую которую больше 100 лет назад Марк Твен приписал премьер-министру Великобритании Бенджамину Дизраэли. #Math #Data #Statistics

Insights on How Team Topologies Drive Organizational Success - Manuel Pais - GOTO 2024 - Part II (Рубрика #Management) Этим постом я заканчивую рассказ про выступление Manuel Pais, со-автора книги "Team Topologies". В прошлом посте я начинал обзор этого рассказа про инсайт из практического применения топологии команд. 7. Автор затрагивает неконсистентный опыт пользователей. В качестве кейса приводится история BBC (ее тоже не на сайте). Здесь суть была в том, что у BBC было много продуктов, каждый из которых имел свой особенный интерфейс и это не очень нравилось пользователям:) В итоге, BBC просто выделили стандартные фронтовые компоненты, но и сделали большой реорг, что они описывали у себя на Medium. В итоге, автор выделяет следующие - Принцип: optimize for innovation & speed when those are needed, allow "eventual consistency" and standartization to emerge later - Practice: Collaborate, facilitate, x-as-a-service. Платформенным командам важно правильно выбирать тип взаимодействия 8. Автор переходит к медленному time-to-market. Рассматривается пример SAP, у которого сложности со скоростью из-за соблюдения требований законодательства и обеспечения безопасности (и наверное не только из-за этого). В итоге, ребята занялись внутренней платформой для упрощения работы команд разработчиков. Платформа рассматривалась как продукт, ориентированный на группы команд, страдающих от сложных процессов соответствия требованиям и безопасности. - Принцип: turn blocking dependencies into unblocking ("dependency inversion" for teams) - Practice: Product management in platform. Подробнее про это можно прочитать в моем разборе CNCF Platform White Paper: 1, 2 и 3 9. Автор переходит к работе с тезисом "we can't do that in my organization". Это кейс GfK/NIQ. У ребят аля SAFE и все команды заняты продуктовой разработкой. Они придумали, что каждый пятый спринт будут работать над платформенными задачами - Принцип: "behaviors over structures". don't wait for the ideal org / process / scale - Practice: Thinnest viable platform. Можно начать с максимально тонкой платформы, что уже приносит пользу организации 10. Топология команд рассматривается как социально-технический подход для увеличения потока и повышения удовлетворенности. Организации могут применять идеи топологии команд в разных сферах бизнеса, адаптируя их под свои нужды. Важно иметь видение и понимать принципы топологии команд. Примеры выше показывают, как можно адаптировать идеи и принципы для текущей ситуации. Сообщество вокруг топологии команд активно и заинтересовано, и есть множество ресурсов для изучения и применения этих идей. #Management #Leadership #PlatformEngineering #Software #SoftwareDevelopment #Architecture #Processes

Insights on How Team Topologies Drive Organizational Success - Manuel Pais - GOTO 2024 - Part I (Рубрика #Management) Интересное выступление Manuel Pais, со-автора книги "Team Topologies", в котором он делится инсайтами из практического применения топологии команд. Для меня это видео супер-интересно, так как я давно сделал краткий обзор этой книги в трех частях - Teams as means of Delivery - Team Topologies that work for flow - Evolving team interactions for innovation and rapid delivery А потом еще записал и первый эпизод подкаста "Code of Leadership" вместе со Станиславом Халупом. Это же выступление Manuel Pais содержит следующие интересные моменты 1. Ни один подход не решает все проблемы сразу, это относится и к топологии команд 2. Комикс Comic Agile забавно рассказывает про Team Topologies, но не слишком правильно (по мнению автора):) 3. Team topologies - это социо-технический подход для улучшения flow и hapiness. Быстрый flow требует большей автономии и четкой цели. 4. Крупные организации задаются вопросами: как расти устойчиво, как становится высоко-производительными, как вовлекать сотрудников 5. Автор разбирает проблему медленного delivery из-за высокой связности команд. В качестве case study приводится пример JP Morgan, где автор решали это через business aligned value streams. Для этого пришлось разобраться с природой зависимостей, сделать команды кросс-функциональными и улучшить коммуникации между ними. На выходе у ребят получилось уменьшить на 60% зависимости между командами. Вообще, публичные case studies доступны на сайте teamtopologies.com, но кейса JP Morgan в публичном доступе нет. Отсюда автор выводит - Принцип: decouple teams by decoupling their streams/products ("decoupling responsibilities") - Practice: Independent service heuristics (ISH). Суть в том, чтобы выделить independently-viable services. Начать можно с вопроса, а может ли такой кандидат в стримы работать как отдельный SaaS продукт в облаке 6. Автор переходит к отсутствию бизнес гибкости из-за организационных трений (org frictions). Здесь в качестве кейса приводится история Telenet (его тоже не на сайте). В этом кейсе для любой фичи требовалось участие огромного количества команд. Это замедляло любые изменения до предела. На выходе автор опять приводит - Принцип: "minimize structural complexity" through grouping closely related streams of value - Practice: Team (Tribe) interaction modeling. Надо идентифицировать и совместно стратегировать относительно командной структуры, которая сможет эволюционировать в дальнейшем Продолжение обзора в следующем посте. #Management #Leadership #PlatformEngineering #Software #SoftwareDevelopment #Architecture #Processes

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

ЦЕХ 4 - Урок #22 "Взаимодействие с обозревателями, критиками и СМИ. Эксперт — Екатерина Северина" (Рубрика #Writing) Очередной урок из курса книгописания и книгоиздания от МИФ вела PR-менеджер, драматург и книжный обозреватель. Из этого урока я вынес следующие моменты 1) Успеху книги может способствовать личный бренд, который можно повышать за счет работы со СМИ. Это помогает и в плане SEO (по вашему имени находится релевантная информация в поисковиках) 2) СМИ тоже выгодно работать с авторами - это помогает им закрыть контентный голод и получить эксклюзивный материал, а также сэкономить силы штатных журналистов 3) Важно понимать какие СМИ интересны вашей аудитории и взаимодействовать с ними. Тут пригодится анализ публикаций СМИ и их целевой аудитории (часто у СМИ есть медиакиты для рекломадателей, где эти вещи базово описаны) 4) Для анализа СМИ можно почитать и их соцсети и комментарии читателей в них 5) СМИ выстроены в пирамиду: массовые СМИ ориентированы на новичков и не погружаются в глубокие темы, тематические СМИ, такие как "Мир фантастики", предлагают материалы для профессионалов, профи и эксперты в тематических СМИ готовы платить за качественный продукт и не совершают поверхностных суждений. 6) Профи и эксперты в тематических СМИ интересуются не только книгами, но и функционированием индустрии. 7) Также можно сотрудничать с книжными обозревателями и блоггерами - это помогает запустить сарафанное радио и литературный нетворкинг. 8) В общем, для того, чтобы эффективно работать со всеми этими людьми нужна база контактов, которая должна быть рабочей, приносить результат, динамичной и актуальной. 9) Основные элементы записи в базе контактов: фамилия, имя, СМИ, адрес, электронная почта, tg-канал. 10) Важно анализировать эффективность коммуникаций через свою базу и адаптировать подходы в зависимости от результатов (в уроке приводилось куча примеров как писать правильные письма и сообщения) 11) Вообще, есть целая пачка книжных материалов, что автор может предложить СМИ/обозревателям/блоггерам - Обзор: краткое описание новых книг для привлечения читателей. - Рецензия: критический анализ и оценка произведений. - Препринт: отрывок из книги до её выхода. - Тематическая подборка: рекомендации книг по темам. - Интервью: редко встречаются, требуют весомого литературного капитала. - Новости: большие материалы о значимых событиях, таких как смерть автора. Предыдущие посты про этот курс писательского мастерства доступны здесь 1. Увидеть свое имя на обложке может каждый 2. Целевая аудитория и ее потребности в создании книги 3. Жанры и стили. Как найти тему для нон-фикшн-книги 4. Как организовать работу 5. Как преодолеть писательские блоки. Практическое занятие 6. Жду музу, а она все не приходит 7. Книга по полочкам 8. MS Word для работы с большими и сложными текстами 9. Рассказываем истории: сторителлинг в книге 10. Саморедактура: работа с текстом, сокращения, фактчекинг 11. Правила сильной книги захватывающего текста 12. Авторская стилистика 13. Как превратить рукопись в сценарий 14. Рукопись готова. Что дальше? 15. Превращение рукописи в издание 16. Авторские права и договор с издательством 17. Дизайн книги. 18. Продвижение в самиздате. 19. Продвижение автора 20. Social media marketing (SMM) 21. Ведение блога и его продвижение в Телеграме #SelfDevelopment #PublicSpeaking #Storytelling #Writing

Comic Agile - Team Topologies (Рубрика #Humor) В эти выходные я смотрел лекцию Manuel Pais, со-автора книги "Team Topologies", на конференции GoTo. В самом начале своего выступления он ссылается на этот комикс "Comic Agile". На этом ресурсе много забавных комиксов, включая тот, что про Team Topologies. В общем, рекомендую, если вам тоже нравится с юмором подходить к менеджменту:) #Humor #Management #Leadership #Processes #Software

Зачем измерять developer productivity в крупной компании? И как это делать правильно? (Рубрика #Management) Сегодня я выступаю онлайн на конференции D-Day, что оффлайн проводится в Тирасполе. Я уже выступал на этой конференции 5 лет назад, но тогда это было очно:) В этот раз я решил рассказать про тему developer productivity, начать с того, а зачем ее мерить и дальше рассказать как, а напоследок поделиться тем, как это принято делать у нас в компании. По традиции в день доклада я публикую список материалов по теме, которые позволят изучить тему сильно глубже, чем я успею рассказать за 25 минут 1) Мое выступление "Как и зачем измерять инженерную продуктивность в крупной компании" на MTS конференции 2) Обзор книги канонической книги "Accelerate" в трех частях: -- Общая информация по книге, формат исследования и DORA метрики -- Технические практики, архитектуру и интеграцию вопросов безопасности в процессы разработки -- Менеджерские и лидерские практики 3) Выпуск подкаста "Code of Leadership" про "Accelerate" с Игорем Курочкиным 4) Разбор темы developer productivity в фреймворках SPACE, DevEx 5) Разбор начальной статьи ребят из Google "A Human-Centered Approach to Developer Productivity" и рассказ про целую колонку в IEEE журнале от этих авторов 6) Разбор статьи "Measuring Developer Goals" от ребят из Google (продолжение серии про Human-Centered Approach) 7) Разбор статьи "Developer productivity for Humans, Part 7: Software Quality" от ребят из Google (продолжение серии про Human-Centered Approach) 8) Разбор выступления моего коллеги Вовы Калугина "Почему DevEx важен при разработке IDP и как его померить", где он рассказывает про нашу платформу Spirit и как мы подходим к вопросам developer experience и developer productivity #Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

Транспондер на фрилансе (Рубрика #Culture) В эту пятницу мы с женой ходили на этот спекталь в Театр.doc. Постановка показалась мне интересной и необычной, но отчасти похожей на мокьюментари-драму "Остановка" театра "Практика", на которой мы были полгода назад. В транспондере точно также участвует 4 человека, все действие развивается в небольшом пространстве, а все действо сопровождают музыкальные и видео-вставки. Этот спектакль тоже поднимает вопросы о жизни, мечтах и поиске истинного призвания, но если в остановке это все крутилось вокруг автобусной остановки, то тут все крутится вокруг творчества великого гитариста John Fruschiante (у меня в голове параллельно музыке спектакля крутилась его "Murderers"). А вообще описание спектакля выглядит так

Музыкант-неудачник встречает двух друзей и предлагает создать им что -то крутое. Пока они разбираются, что же это может быть, им придется спеть, поговорить о Боге, встретиться с гитаристом группы Red Hot Chili Peppers Джоном Фрусчанте и почти умереть, но понять, что такое настоящее призвание.

#Culture #Theater

Обложки книг Джона Маэды "Законы простоты" и "The Laws of Simplicity"

Законы простоты (The Laws of Simplicity) (Рубрика #Design) На днях я прочитал книгу Джона Маэды о законах простоты. Сам Джон является выдающимся американским дизайнером, ученым и педагогом, который известный своими работами на стыке бизнеса, дизайна и технологий. В настоящее время он является вице-президентом по дизайну и искусственному интеллекту в Microsoft. Кстати, это уже вторая книга этого автора, которая мне понравилась, первой была "ReDesisning Leadership" ("Редизайн лидерства"), о которой я уже писал в канале. Если же возвращаться к самой книге о законах простоты, то интересно, что он написал ее почти 20 лет назад, еще до выхода айфонов на рынок. Тогда она стала бестселлером, но дизайнеры с тех пор двигаются скорее в сторону сложности:) Джон предложил использовать следующий список законов для нахождения баланса между сложностью и простотой в различных аспектах жизни и работы, делая системы более интуитивными и эффективными 1. Сокращение (Reduce) — Самый простой способ достичь простоты — это осознанное сокращение. Убирайте лишнее, но будьте осторожны, чтобы не убрать что-то важное. 2. Организация (Organize) — Организация помогает сделать систему с множеством элементов более понятной и управляемой. Правильная структура делает сложное проще. 3. Время (Time) — Экономия времени создает ощущение простоты. Чем меньше времени требуется на выполнение задачи, тем проще она воспринимается. 4. Обучение (Learn) — Знания упрощают все. Чем больше вы знаете о системе или процессе, тем легче с ними работать. 5. Различия (Differences) — Простота и сложность взаимосвязаны. Чтобы оценить простоту, необходимо иметь возможность сравнивать ее с чем-то более сложным. 6. Контекст (Context) — То, что находится на периферии простоты, не является незначительным. Контекст важен для понимания и восприятия системы. 7. Эмоции (Emotion) — Больше эмоций лучше, чем меньше. Эмоциональная связь с продуктом или системой делает их более привлекательными и понятными. 8. Доверие (Trust) — Простота требует доверия. Пользователи должны доверять системе, чтобы она казалась простой в использовании. 9. Неудача (Failure) — Некоторые вещи невозможно упростить. Не все попытки создать простоту будут успешными, но важно учиться на ошибках. 10. Единое (The One) — Простота заключается в вычитании очевидного и добавлении значимого. Это объединяющий принцип всех предыдущих законов. В общем, у меня после прочтения не сложилось ощущение, что это прямо законы. Я скорее бы назвал это интересными аспектами, с точки зрения которых надо смотреть на систему, чтобы сбалансировать в ней сложность и возможности так, чтобы для пользователей она выглядела простой:) #Design #Leadership #Management #SelfDevelopment #Processes

Менторинг сессия на канале SouthHub (Рубрика #Management) Во вторник вечером я проводил менторинг сессию, запись которой доступна на Youtube. Моим менти был Антон Числов, технический директор МТС Авто. Запрос был на меторинг по теме как осуществлять крупные изменения в больших компаниях. Суть в том, что у ребят на носу 2 больших изменения 1) Переход от разработки по компонентам к stream-aligned командам 2) Переезд из MTS Digital в отдельную компанию внутри экосистемы В общем, оба изменения достаточно большие и мы с Антоном обсуждали на встрече какие ожидания от изменений, какой контекст, как спланировать изменения и осуществить их. Конечно, за час сложно обсудить такие темы целиком, но я постарался максильно хорошо понять ситуацию и дать не просто советы, а фрейм размышлений о том, как действовать в таких условиях. #Management #Leadership #Processes #Software

#psy Мы с группой коллег проводим исследование, посвященное формированию и развитию новой профессиональной идентичности. Для практической части мы выбрали профессии, связанные с управлением продуктом. Если вы недавно перешли в такую профессию, находитесь в процессе перехода или планируете его, приглашаю принять участие в нашей психаналитической группе "Как занять свое место в профессии". Примеры вопросов, которые могут возникать: - Вокруг все говорят, что ты product manager, а сам ты про себя так не говоришь/не можешь сказать кто ты; - Хочешь стать product manager, но не дают\не получается (по разным причинам); - Уже работаешь в управлении продуктом, но не можешь понять, кто ты такой в своей текущей роли на работе На группе вы сможете в окружении людей со схожим запросом поисследовать свое состояние и внутренние процессы, поделиться своими чувствами, поискать опору для движения вперед. Состав группы - 12-15 человек Длительность встречи - 2 часа Встречи будут онлайн по субботам, 6 встреч, 1 раз в неделю. Перед стартом группы будет проведена индивидуальная встреча с одним из консультантов (1 час) для знакомства с методом и друг с другом. Вся информация строго конфиденциальна и будет обезличена в рамках исследования. Если вам интересно, пишите в лс

Моя жена, Анастасия, сейчас заканчивает магистратуру "Психоанализ и психоаналитическое бизнес-консультирование" в Вышке. И в рамках дипломной работы она с коллегами проводит исследование, посвященное формированию и развитию новой профессиональной идентичности. Если вы являетесь продакт-менеджером или планируете им стать, то вы можете принять участие в психаналитической группе "Как занять свое место в профессии". Подробности в крутом канале Насти (на который вы можете подписаться) #SelfDevelopment

0b1000 в Т-Банке Сегодня у меня юбилей в Т-Банке, 8 лет:) Именно столько лет назад я пришел в тогда еще Тинькофф. Я пришел из Банки.ру, где был лидом команды разработки, что отвечала за рейтинги банков, страховых и остальной UGC (user generated content), а также лидогенерящие странички:) В Тинькофф я вышел на позицию engineering manager заниматься проектами привлечения. Планы на старте были наполеоновскими и они действительно драйвили меня. Это был период роста и моя зона ответственности постоянно менялась. Я чувствовал себя не просто engineering менеджером, а скорее менеджером непрерывных изменений с девизом "пересобери себя и свою команду или умри"... Но как только я справлялся с новым вызовом, то получал следующий. Это происходило примерно каждые полтора-два года. Про многие из этих изменений я рассказывал на YaTalks в прошлом году и в расшифровке этого выступления. С тех пор я собрал у себя dream team из руководителей, которые отвечают за отдельные большие подразделения в 200-300 человек - Клиентские интерфейсы: платформенные команды веба, мобилы и API - Маркетинговые технологии: внешняя реклама, маркетинговая платформа - Соц-медиа платформы: социальные сети, медиаплатформа, медиапроекты (ТЖ, Бизнес-секреты), игры - Цифровые экосистемы: аутентификация/авторизация, биометрия, главная страница приложения, финздоровье А еще у меня в подразделении есть важный для меня продукт в виде продуктовой аналитика и a/b платформы. Это важно для компании для того, чтобы быть data-driven, а для меня - это возможность закрыть гештальт относительно математики (теорвер, матстатистика), которая мне нравилась всю дорогу от лицея до физтеха и дальше:) Также я отвечаю за архитектуру как функцию в компании. Это мне близко как технарю, для которого важна engineering excellence и design крутых систем. Напоследок, я хотел сказать спасибо ребятам из моего юнита "Клиентские интерфейсы, маркетинг и вовлечение". Ребята и делают всю работу, которая приносит радость нашим клиентам, деньги компании, а мне позволяет рассказывать об этом. Кстати, с частью ребят я записывал интервью - Про архитектуру с моим замом, Антоном Костериным. Антон руководит архитектурной группой при мне - Про про системных аналитиков с Кириллом Крайневым. Кирилл руководит маркетинговыми технологиями, а также драйвит развитие профессии системных аналитиков - Про Staff+ инженеров, архитектуру и SDLC с Алексеем Тарасовым. Алексей руководит соц-медиа платформой, а также драйвит наши system design interview и помогает развивать направление staff+ для инженеров - Про систему для продуктовой аналитики (Statist) с Андреем Цыбиным. Андрей руководит продуктовой аналитикой и a/b платформой. Думаю, что мы не будем останавливаться на этом и будем делать все более крутой продукт, а также рассказывать о том, как мы это делаем:) P.S. В общем, 8 лет - это большой срок, который можно и отметить. Особенно с учетом того, что я не уверен в том, что "доживу" до следующего круглого юбилея в двоичной системе:) #Management #SelfDevelopment #Engineering #Processes #Software

Бегущий по лезвию 2049. Вселенная фильма (Blade Runner 2049) (Рубрика #SciFi) В конце прошлой сложной недели я взял полистать этот артбук перед сном:) Отчасти решение выбрать именно эту книгу было принято из-за получения в этот день двухтомника Сергея Маркова "Охота на электроовец", который посвящен искусственному интеллекту. Это название отсылает к книге "Мечтают ли андроиды об электроовцах" ("Do Androids Dream of Electric Sheep?") Филиппа Киндреда Дика (кстати, про него я уже рассказывал при обзоре его биографии в комиксах). Именно эта книга про мечты андроидов послужила Ридли Скотту основой для его классического фильма "Бегущий по лезвию", что вышел больше 40 лет назад. А меньше 10 лет назад появилось продолжение от Дэни Вильнева "Бегущий по лезвию 2049". В итоге, в этой книге рассказывается про создание фильма и приводится куча иллюстраций того, как выглядели локации фильма на этапе задумки и как они модифицировались дальше до того состояния, что мы видим в самом фильме. P.S. У меня есть книга про Ридли Скотта "Ридли Скотт. Гений визуальных миров. От Чужого до Марсианина", в которой значительное место уделено "Бегущему по лезвию". Но ее я прочитаю в следующий раз:) #SciFi

T=Математика (#PopularScience) 1 декабря будет день математики и мои коллеги из Т-Образования устраивают большой праздник с кучей активностей: лекции, математические игры, интенсив по финграмотности и многое другое - 11 — 24 ноября - Интенсив по олимпиадным задачам (онлайн) - подготовка к муниципальному этапу ВсОШ (разборы от опытных преподавателей, тренировки в решении задач - 16 ноября - Интенсив по финграмотности (оффлайн) - мероприятие пройдет в T-Space (Москва, м. Белорусская), в программе будет несколько докладов - 28-30 ноября - Турнир по математическим играм (онлайн) - на турнире будут командные игры: «Математический квадрат», «Математическая карусель» и «Семь чудес». Победители получат памятные призы от Т-Образования - 1 декабря в T-Space в Москве - День математика (оффлайн) - мероприятие пройдет в T-Space (Москва, м. Белорусская), в программе будут лекции, нетворкинг и фуршет. #PopularScience #Math

Как корпорации тратят деньги на AI? The Information подготовили отчёт по тратам крупнейших компаний на генеративные модели. В основном это, конечно, ллм-ки, но некоторые еще генерят картинки для креативов🥴. Сама таблица не очень удобная, поэтому я прогнал её через LLM, чтобы распределить по группам для наглядности:

### 1. Customer Support/Service - AT&T: Customer service chatbot - Doordash: Customer support/contact center chatbot, voice ordering, menu, and search optimization - Duolingo: Generating lessons, audio, and chatbot for conversational practice - Elastic: Sales, marketing, and information retrieval internal tools - Expedia: Customer-facing chatbot, internal tools - Fidelity: Generating emails to customers and other materials - Freshworks: Customer service chatbot, employee HR chatbot, document summaries - G42: Customer-facing chatbots for healthcare, financial services, and energy sectors - H&R Block: Customer-facing chatbot in tax software - Ikea: Customer-facing chatbot on the website - Klarna: Customer service chatbot and HR software - Intuit: Chatbot and customer service features - Mercedes Benz: Call center automation - Oscar Insurance: Customer-facing chatbot in insurance claim software - Radisson Hotels: Customer service assistant for managing bookings - Snap: Chatbot - Stripe: Customer service chatbot and fraud detection - Suzuki: Employee chatbot apps - T-Mobile: Customer support chatbot - Uber: Customer support and internal HR tools - Volkswagen: Voice assistant in vehicles, employee-facing tools ### 2. Marketing/Content Generation - Coca-Cola: Generating marketing materials and AI assistants for employees - Autodesk: Support, code generation, and sales - IPG: Content generation and employee-facing chatbot - Walmart: Curating personalized shopping lists, generative AI-powered search, assistant app - Wayfair: Code generation - Wendy’s: Generating suggested orders for customers ### 3. Document Processing & Information Retrieval - Morgan Stanley: Information retrieval for wealth management - Pfizer: Search documents by voice command and chatbot - Toyota: Information retrieval and coding assistants for employees - Volvo: Streamlining invoice and claims document processing - Zoom: Meeting summarization ### 4. Development/Code Generation - Goldman Sachs: Code generation, document search, summarization - ServiceNow: Generating sales emails and code generation - GitLab: Code generation - Notion: Summarization and text generation ### 5. Employee & Internal Tools - Fidelity: Emails to customers and other materials - Salesforce: Chatbots and summarization for sales and HR

Самое интересное — это, вероятно, голосовой помощник в машине от Volkswagen и забавный комментарий по поводу Pfizer (ещё помните их по ковиду?). Последние используют голосового помощника для поиска документов (никто больше голосом не работает), за исключением учеников Duolingo. У зеленой совы, кстати, неплохо вышло интегрировать LLM в свой продукт. Остальные сценарии использования довольно банальны: саммари, особенно для HR; дебильные costumer-support чат-боты (кстати, кто-то ими вообще пользуется?); корпоративные подписки на ChatGPT, Клод или Gemini для оптимизации работы сотрудников и генерация писем. Ничего примечательного. Однако всё же интересно, как каждая конкретная компания использует LLM в своей работе. И, наконец, счёт среди топовых моделей таков: OpenAI — 43 Gemini — 19 Anthropic — 12 Я даже немного удивлён, что у Gemini клиентов больше, чем у Антропиков — наверное, из-за контекста в 2М токенов. Кстати, обычно компании используют одного или двух ботов, так что общая сумма очевидно превышает 50. Табличка Статья @ai_newz

Интересная информация от канала "эйай ньюз", за которым я слежу, чтобы не отставать от новостей AI. Здесь интересна информация о том, а как крупные компании используют AI в своих процессах и оказалось, что все просто 1) Customer support/service - тут всеми "любимые" чатботы и не только 2) Marketing/content generation - генерация маркетингового контента, рекомендаций продуктов (eBay) 3) Document processing / infromation retrieval - обработка документов, суммаризация встреч, поиск по данным 4) Development/code generation - генерация кода (Gitlab, Autodesk), теста (Notion), ... 5) Employee/internal tools - внутренние инструменты для сотрудников В принципе, список неполный, но достаточно полезный. У нас, например, по всем из этих направлений тоже ведется работа.

Research Insights Made Simple #4 - Обсуждение "AI-Enhanced API Design" В этом эпизоде мы обсуждаем интересный whitepaper "AI-Enhanced API Design" от ребят из Google, где рассказывалось о том, как подходы к управлению API влияют на продуктивность и usability. Исследователи показали, что общие стандарты вместе с инструментами, которые помогают им следовать, приводят к статистически значимым улучшениям в качестве дизайна API. В разборе мне помогает крутой гость - Павел Каравашкин, мой коллега. Павел является руководителем разработки платформы T-API, а также лидером профессии системного анализа в Т-Бизнес, соведущим подкаста SA Т-Банка InSAйт. Паша любит велоспорт, Warhammer 40k и читать случайные статьи на Википедии. Кстати, эпизод доступен и в подкасте Яндекс Музыки. Материалы: - AI-Enhanced API Design: A New Paradigm in Usability and Efficiency - Мой обзор этой научной статьи - Публичное T-API для партнеров - Подкаст InSAйт Мы обсудили следующие моменты - Обзор статьи и личные впечатления Павла - Обсуждение структуры статьи - Проблемы и аспекты проектирования API - Процесс разработки API в Google - Гибкость и стандартизация в разработке API - Методология исследований в Google - Подходы к исследованием вокруг API в T-банке - Проблемы и решения в персонализации - Использование линтеров и метрик - Анализ логов и задач разработчиков - Исследования и метрики в Google - Генерация контрактов - Проблемы с архитекторами - Методология эксперимента в Google и его результаты - Ограничения эксперимента - В общем про процесс разработки и помощь автоматизированных средств - Важность этапа реализации - Архитектура и улучшение процессов - Измерение эффективности инструментария (отсылка к статье "Measuring developer goals" от ребят из Google) - Роли в разработке - Автоматизация кибербезопасности (отсылка к предыдущему подкасту)Заключение и планы на будущее #Architecture #Software #DistributedSystems #SystemDesign #SystemEngineering #API #Governance

What Is This OpenTelemetry Thing? • Martin Thwaites • GOTO 2024 (Рубрика #Architecture) Интересное выступление на goto конференции от Martin Thwaites, Principal Developer Advocate из Honeycomb. Основная суть выступления примерно такая 1) Автор начинает с истоков наблюдаемости, когда люди ориентировались еще на мигающие лампочки на самих устройствах:) 2) В 2000х годах использовались метрики для мониторинга производственных систем, так как места было мало и производительность систем была не слишком большой. Тут важно было правильно предагрегировать данные, изначально понимая какая информация будет нужна, так как метрики расчитывались заранее, а оригинальные события не хранились. Где-то в 2010х годах для хранения метрик стали использовать time-series базы данных 3) Дальше стали популярны логи, для которых зачастую использовался ELK стек (Elastic, Logstach, Kibana). Это позволило уйти от предварительной агрегации данных и улучшить наблюдаемость. По-факту, в Kibana можно было пост-фактум строить красивые дашборды, агрегируя данные так, как необходимо 4) Где-то с середины 2010х годов системы стали сложнее и распределеннее и дальше появились инструменты для распределенной трассировки и стандарты OpenTracing и OpenCensus 5) В какой-то момент они объединились и превратились в OpenTelemetry - это проект CNCF в статусе incubating, что наряду с graduated считается стабильным и пригодным для использования в проде 6) OpenTelemetry хорош тем, что он пришел на смену двум предыдущим стандартам, что со временем стали deprecated и позволил отвязать инструментализацию телеметрии от бекендов, в которые она отправляется. У этого стандарта есть протокол и SDK для всех популярных языков программирования 7) У OpenTelemetry есть и проблемы - он развивается через комитеты, что замедляет процесс доработок и расширений стандарта 😍 В OpenTelemetry есть логи, метрики, трейсы. Трейсы - это способ для описания взаимодействия сервисов с учетом причинно-следственных связей (это делается через связи между спанами). Вообще, трейсы позволяют очень удобно разбираться с поведением сложной распределенной системы. 9) Логи предназначены для людей и имеют шаблон сообщения, они полезны для локальной отладки и проверки работы трассировок 10) Метрики - это агрегированные временные ряды данных. Они используются для измерения и анализа производительности. Дешевы в хранении и быстры в обработке, но ограничены в контексте и размерности. 11) OpenTelemetry позволяет думать о соединениях между системами. Распространение данных включает корреляцию и передачу информации о состоянии. Спецификация контекста трассировки W3C определяет заголовки и данные для передачи. 12) Автор подробно говорит про W3C Baggage, propagation format for distributed context. Он как раз позволяет передавать дополнительный контекст между службами, но есть там и проблемки, например, передача данных через сторонние API может привести к утечке конфиденциальной информации. 13) Круто, когда инструментализация OpenTelemetry встроена в шаблоны ваших приложений - это помогает командам SRE получать стандартизированные observability данные 14) У OpenTelemetry есть collector, который используется для проксирования и обработки данных телеметрии. Он позволяет централизовать конфигурацию и отправку данных нескольким поставщикам, а также обеспечить центральную точку для инфобезов или обогощения данных 15) В OpenTelemetry можно настраивать семплинг для уменьшения затрат на наблюдаемость 16) Прикольно семплировать не с головы, а с хвоста, когда мы знаем что попало в трейсинг. Хвостовой сэмплер может сообщать о медленных процессах и ошибках, но компромисс здесь в том, что задержка отправки данных и большие затраты памяти. 17) У OpenTelemetry есть и проблемки - отправка данных через перекрестные зоны доступности может быть дорогой. Решения по отправке данных требуют компромиссов. OpenTelemetry требует постоянного внимания и настройки. 18) В будещем в OpenTelemetry ожидается больше семантических соглашений и библиотек #SRE #Architecture #DistributedSystems #Software