Канал "Евгений Козлов пишет про IT" (Рубрика #Recommendation)

Мой коллега ведет интересный канал @careerunderhood, в котором он делится своим опытом. Я сам подписан на этот канал и почитываю его, ведь Женя в отличие от меня своими руками и руками своей команды делает сложные и высоконагруженные продукты. Он руководит командой разработки Statist - это наш внутренний инструмент для продуктовой аналитики, который заменил нам Amplitude (я про него уже рассказывал). Со времен замены мы выросли по объемам хранения в несколько раз, а Женя и его ребята успешно справляются с этим ростом и косты на эксплуатацию этого решения растут сублинейно. В общем, Женя - молодец, у него хороший блог и хорошая команда, в которой можно попробовать применить те подходы, что рассказывал Мартин Клеппман в "Кабанчике" (или более официально "Designing Data Intensive Application"). Кстати, иногда в своем блоге Женя пишет о вакансиях, которые открываются в его команду, как было в середине мая - https://t.me/careerunderhood/283

P.S.
Кстати, один из выпусков "Code of Leadership" был с руководителем Жени, Андреем Цыбиным, где мы обсуждали путь Андрея и Statist как продукт в общем.

#Analytics #Architecture #DistributedSystems #Management

A Short Summary of the Last Decades of Data Management • Hannes Mühleisen • GOTO 2024 (Рубрика #Data)

Интересное выступление от Hannes Mühleisen на тему истории развития систем управления данными и куда они будут развиваться дальше. Сам Hannes является ученым по CS, а также создателем DuckDB и кофаундером DuckDB Lab.

Вот основные моменты выступления
- Автор начинает с отсылкам к глубокой истории, когда глинянные таблички использовались для учета в хозяйстве и это было раньше, чем появилась абстрактная письменность
- Дальше автор сразу переходит к роли IBM, чья история стартанула еще с переписи населения в США в 19 веке, а в начале 20 века после объединения нескольких компаний получилась IBM:) И взлет IBM именно как компьютерного гиганта начался с мейнфреймов, которые использовались для космонавтики в США
-- IBM придумала иерархическую систему для менеджмента данных и она использовалась в этих мейнфреймах
-- Дальше Edgar Frank "Ted" Codd придумал основы реляционной модели данных, в научной статье "A Relational Model of Data for Large Shared Data Banks"
-- В 1973 году IBM сделала свою IBM System R, в которой была пилотная реализация реляционной модели
- Но в 1979 Oracle обошла IBM на повороте с промышленной реляционной базой Oracle
- В 1983 году IBM тоже включилась в гонку со своей IBM DB/2
- А уже в 1996 году в рамках академического проекта была создана PostgreSQL. Ее создал Michael Stonebraker из Berkley
- Для тех, кто интересуется генеалогией различных СУБД может быть интересна карта RDBMS Genealogy

Где-то в 80-е годы стало понятно, что одна база не покрывает всех сценариев и появилась развилка вида
- Transactional - в этом сценарии пользователи работают с транзакциями. Данные здесь эффективно хранить построчно (row-based), так как обычно нужна большая часть записи для чтения и обновления
- Analytical - в этом сценарии пользователи анализируют данные, здесь уже не особо нужны транзакции. Данные здесь эффективно хранить поколоночно (column-based), так как для расчета показателей часто нужны значения из конкретных колонок, при хранении их по колонкам их проще сжимать при хранении, а также считывать для рассчетов
Для того, чтобы показать различия между СУБД автор приводит метафору пикапа и машинки формулы 1.
- Пикап - надежная рабочая лошадка, которая всегда должна работать и ей являются транзакционные базы
- Машинка формулы - это аналитические базы, которые должны быть быстрыми, но могут работать не всегда, так как они обычно не блокируют всю работу компании.

Дальше автор рассказывает про движение No SQL!
- 2006 год - Map/Reduce от Google для параллельной обработки задач на ненадежном оборудовании, из этого подхода вырос Hadoop. Изначально там не было SQL, но в 2010 году появился Hive, который вернул SQL поверх map/reduce, так как без SQL было слишком сложно писать запросы
- 2009 год - Schemaless от MongoDB. Тут концепция была в том, чтобы была не schema on write, что контролировалось базой, а schema on read, что должен был проверять app developer. В 2017 году в MongoDB появилась schema validation
- 2008 год - нет ACID транзакций и вместо этого tunable consistency в Cassandra. В 2023 году в Cassandra появились транзакции
- 2014 год - нет внутреннего storage в Apache Spark. В 2024 году появился внутренний storage

Все изменения были из-за того, что трио
- Таблицы
- SQL
- ACID
слишком удобно для разработки приложений и именно туда будет двигаться работа с данными. Автор вспоминает про Postgres и SQLite, а также про newSQL как подход, что комбинирует это трио с масштабированием как в NoSQL. А дальше он говорит, что реляционные базы съедят почти все сценарии и показывает как это сделать с key/value, document, time series, vectors, graphs, data frames. Но, например, уже full text search не очень укладывается в реляционную модель.

Напоследок автор говорит о том, что big data мертва, так как теперь у нас есть возможность собрать очень мощную машинку, на которой запустить обработку того, что раньше крутилось в распределенной системе. И это, возможно, будет сильно эффективнее.

#Data #Architecture #Management #History

Процессы найма в большие компании и типы интервью в Т-Банк (Рубрика #Management)

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

Я верю в то, что в крутой компании должны работать крутые сотрудники, поэтому я достаточно сильно погружен в процессы найма и провожу много собеседований разных типов. А сегодня случился юбилей и мне пришло оповещение, что я теперь могу проводить 5 типов интервью в компанию и вот их список:
1) Engineering management - интервью по менеджменту для engineering managers и directors
2) System Design - интервью про проектирование системы для software developments engineers и не только
3) Troubleshooting - интервью про работу во время инцидента для SRE (site reliability engineers)
4) Architecture & SDLC - интервью про опыт кандидата в проектировании сложных систем, выстраиванию архитектурных процессов и улучшение инженерных практик в командах. Его мы даем кандидатам, претендующим на высокий грейд (staff+) в треке индивидуальных контрибьюторов (IC)
5) System Design for Engineering Directors - system design для высокоуровневых технических руководителей
Забавно, что я думал, что пятой секцией станет Programming, где мы с кандидатом совместно пишем код в web IDE, решая easy/medium алгоритмическую задачку. Но так сложилось, что я пока только восстанавливаю свои навыки программирования и в эту секцию пока не заонбордился, но случился fork секции System Design и теперь у нас отдельный пул интервьюеров для Engineering Directors. Предполагается, что тут кандидаты могут приходить достаточно подкованные и с ними можно задизайнить что-то интересное.

Кстати, про все эти секции я уже много и подробно рассказывал про каждое из них, вот ссылки для тех, кому интересно узнать подробности
- Engineering management (Managers & Directors) - выступление "Как нанимать технических руководителей" на Teamlead Conf 2023
- System Design - про этот тип собеседований я много рассказывал + проводил публичные интервью. Например можно посмотреть в общем про system design в Tinkoff, больше про то, как мы оцениваем прохождение собеседования и как подготовиться к собеседованию или публичные интервью на ArchDays
- Troubleshooting - про это интервью я рассказывал на DevOps Conf (видео), а также на DevOops было публичное интервью
- Architecture & SDLC - про это мы говорили с моим коллегой, Лешей Тарасовым, на одном из выпусков моего подкаста "Code of Leadership"

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

P.S.
Кстати, я не сдаюсь и до конца года планирую разблокировать для себя и собеседования по программированию:)

#Career #HR #Management #Architecture #Software #Leadership #Processes

Результаты практики представителем в Оренбурге (Рубрика #Management)

В продолжении поста про гембу я решил поделиться своим опытом бытия представителем Т-Банка, который доставляет продукты нашим клиентам.
Собственно, про доступность опции стажировки нам сообщили на менеджмент встрече руководителей. В прошлом году уже была такая поездка в регионы, но я в тот раз не смог, а в этот раз у меня получилось записаться на стажировку. Дальше события развивались примерно так

1) За пару недель дот отъезда я прошел онлайн курс для представителя.

2) 16 июля я прилетел вечером в Оренбург, заселился в отель и уснул в предвкушении интересного дня

3) 17 июля я приехал в наш офис и получил все артефакты, положенные новичку-представителю: сумку, телефон Samsung, сим-карту, зарядку и провода для соединения с iPhone, три ручки и неименные продукты компании (дебетовые и кредитные карты, симки и так далее). Я подписал несколько бумаг о том, что я принял материальные ценности и все такое. Мне достался опытный представитель Светлана, которая подхватила меня и мы отправились в путь. В этот день я практиковал shadowing и был в роли стажера, который наблюдает за старшим товарищем. День прошел достаточно плотно и я увидел доставку разных продуктов, а также как выглядит x-sell на практике. Честно говоря, Светлана очень непринужденно оформляла документы, консультировала клиента по продуктам, отвечала на вопросы и предлагала комплементарные продукты, что могли пригодиться клиенту. Я фиксировал интересные моменты и уточнял по некоторым моментам насколько часты такие ситуации + что хотелось бы улучшить в процессах или приложении. Когда этот длинный день закончился, я вернулся в отель и уснул без задних ног

4) 18 июля я рано проснулся, позавтракал и проверил рабочее приложение - в нем уже были встречи, которые назначили на меня, так как я работал в формате первого пилота. Уже в 8 утра мне позвонил клиент и попросил поменять адрес доставки, что я и сделал:). К 10.30 я приехал в офис и забрал конверты с именными продуктами для клиентов, отсканировав их, чтобы эти документы числились за мной. Дальше я встретил Светлану, которая в этот день была моим куратором. Мы обзвонили клиентов и предупредили, что приедем к ним в назначенный временной интервал. Я всегда говорил, что я стажер и со мной будет куратор, который поможет мне провоести встречи правильно (кажется, что уже лет 20 как я не представлялся стажером:)) Интересно, что я выучил процесс выдачи продукта и не особо лажал, но вот консультации по продукту и дополнительные продажи мне не особо давались - оформление продуктов еще не стало автоматическим, чтобы я мог в параллель делать еще что-то сложное. С 11 до 20 мы доставляли продукты, но у нас был перерыв с 15 до 17, когда мы спокойно пообедали и обсудили полученный опыт. Вечером я вернулся в отель и лег спать.

5) 19 июля был свободным днем, который я потратил на обычную работу. Но начал я с того, что написал подробный отчет, в котором описал свой опыт и свои мысли о том, что можно сделать для улучшения процессов и софта, которым пользуются представители. Ниже напишу основные мысли
- Работа представителя достаточно сложная, но опытный представитель способен предоставить оптимальный сервис клиентам
- Приложение представителей сделано хорошо - даже новичок спокойно работает с ним, так как там проработаны основные сценарии работы и все сделано так, чтобы ошибки были минимальны
- Есть моменты, которые можно улучшить: работу автораспределения заданий, формирования дополнительных предложений клиенту, верификации входных данных при создании заявки, анонса новых фичей приложения представителей, чтобы они знали про доработки. Это важные моменты, но общий уровень процессов и софта мне показался крутым. Мои коллеги отлично поработали над их оптимизацией.

6) В ночь с 19 на 20 июля я улетел обратно в Москву

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

#Management #Leadership #Processes

Working Backwards: Insights, Stories, and Secrets from Inside Amazon (Стратегия Amazon) - Part II (Рубрика #Management)

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

Принцип 1. Лидерство установило принципы
Джефф Безос с самого начала написал 14 принципов лидерства Amazon, чтобы направлять новых сотрудников компании. Он сделал это, когда понял, что не успевает лично обучить принципам новых сотрудников. Теперь они проникли во все, что делает Amazon. Теперь принципов уже 16 и звучат они достаточно просто: Customer Obsession, Ownership, Invent and Simplify, Are Right, A Lot, Learn and Be Curious, Hire and Develop the Best, Insist on the Highest Standards, Think Big, Bias for Action, Frugality, Earn Trust, Dive Deep, Have Backbone; Disagree and Commit, Deliver Results, Strive to be Earth’s Best Employer, Success and Scale Bring Broad Responsibility. Подробности можно почитать на сайте Amazon.
Основной вывод для читающих в том, что в компании стоит создать набор принципов лидерства, в которые вы верите, а затем создайте механизмы и процессы, которые будут укреплять их день ото дня.

Принцип 2. Используйте найм сотрудников для постепенного повышения планки.
Отличительной особенностью процесса найма в Amazon является привлечение к работе специалиста по поднятию планки (BarRaiser). Его задача - следить за тем, чтобы вы со временем нанимали более умных крутых сотрудников, а не закрывали глаза на недостатки кандидатов, потому что вы завалены работой и вам срочно нужны люди.

Принцип 3. Организуйте организацию с однопоточными лидерами (single-threaded).
Для каждого проекта или инициативы Amazon назначается один руководитель, который занимается только этим проектом. Вам также нужны члены команды, которые также будут сосредоточены на том, чтобы этот проект работал. В Amazon не существует многозадачности. Чем-то это напоминает подход к stream-aligned командам из Team Topologies (подробнее здесь). Но тут все еще круче, так как руководители не расфокусируются на кучу активностей.

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

Принцип 5. Начните с желаемого качества обслуживания клиентов
При разработке новых идей или продуктов всегда работайте в обратном направлении от желаемого качества обслуживания клиентов. Лучший способ сделать это — часто писать пресс-релиз и FAQ (часто задаваемые вопросы). Используйте эти инструменты для решения сложных проблем сразу. В общем, эта глава как раз про working backwards и применение первого принципа лидерства "Customer Obsession".

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

Продолжение в следующем посте.

#Management #Leadership #Processes #Strategy

Turbo ML Conf (Рубрика #ML)

Сегодня ночью я прилетел из Оренбурга, а днем уже отправился на первую конференцию по ML от Т-Банка. И сегодня на конфе коллеги сделали анонс о выкладке в open source нашей модели T-lite на 8 миллиардов парамеров. Скачать модель можно здесь. Также были выступления про нашего ассистента для разработчиков Nestor, дискуссия про будущее AI, RL в embodied AI, подходы к построению LLM и так далее. Как будут готовы записи докладов, я ими поделюсь в канале.

#AI #ML #Conference #Software

ЦЕХ 4 - Урок #10 " Саморедактура: работа с текстом, сокращения, фактчекинг. Эксперт — Юлия Потемкина" (Рубрика #Writing)

Столько работы навалилось, что только сейчас дошли руки продолжить свой путь к написанию книги. Для этого я прохожу курс МИФа о том, как стать автором. Программа уже ушла на месяцы вперед, но я я не унываю. В этот раз я расскажу про 10 урок, который был посвящен работе с текстом, саморедактуре и проверке фактов. Предыдущие посты доступны здесь: 1, 2, 3, 4, 5, 6, 7, 8 и 9.
Если возвращаться к самому уроку, то вот основные мысли, что я вынес из него:

- Для того, чтобы редактировать текст надо понимать своего читателя и его уровень - чем шире аудитория, тем проще должен быть текст
- Текст должен быть написан в одном стиле без резких перепадов. Например, стиль может быть разговорным, научным, художественным, официальным, публицистическим, но он должен быть только одним:)
- В тексте должна быть логика, если при чтении текста вы видите в ней дыры, то это стоит починить. То же самое относится и к неоднозначностям и противоречиям в тексте
- В зависимости от типа текста правильно использовать дедукцию или индукцию для написания книги. Условно, индукция (от частного к общему) подходит для научпопа, а дедукция (от общего к частному) подходит для деловой литературы
- В тексте должен быть ритм, который позволяет читателю погрузиться в текст и настроить своего дыхание под него (при чтении вслух)
- У авторов книг бывает свой авторский стиль (и не обязательно его устранять при помощи следования советам книги "Пиши, сокращай", про которую я как-то писал)
- Важно самому ревьювить свой текст перед публикацией, дав ему отлежаться. Также можно отдать текст на ревью знакомым
- Надо проверять факты, которые упоминаются в тексте. Они должны быть достоверными и безоценочными. Важно правильно цитировать авторов изречений, что автор решил использовать в книге
- Для объяснения сложных вещей можно использовать метафоры, а также упрощать текст до минимально необходимого уровня
- Иллюстрации для книги - это геморрой:) Я понял, что лучше их делать самому.
- Автору может помочь профессиональный редактор, который не будет дописывать текст за автором, но покажет стилистические ошибки и возможности для упрощения и сокращения текста

#SelfDevelopment #PublicSpeaking #Storytelling #Writing

Mastering Tech Leadership in 50 Minutes • Tim Berglund • GOTO 2023 (Рубрика #Management)

Интересное выступление на тему лидерства от Tim Berglund, VP of DevRel компании StarTree, что занимается real-time аналитикой для user-facing applications. В этом докладе автор выделяет и подробно рассказывает об аспектах лидерства, которые он считает важным для технических руководителей. Вот этот список
1) Vision-casting - здесь речь идет про создание видения. Лидерство предполагает распространение своего видения и призыв к людям следовать за ним. Лидерство начинается с определения целей и объединения усилий для их достижения. Если начать с создания миссии, то скорее всего получится рафинированный компромисс из N+1 точек зрения, где N - это количество участников во встрече для создания mission statement:) Лучше, начинать с целей, перспектив, приоритетов и получать из этого список конкретных действий, а дальше из этого уже может родиться миссия (или не родиться)
2) Discontent - здесь автор говорит про то, что лидеру свойственно недовольство миром и стремление к его улучшению. Без этого не ясно как ставить под сомнение сложившийся статус кво и драйвить изменения.
3) Shepherding - здесь автор погружается в то, что лидер должен заботиться о своей команде. Он вспоминает проект Аристотель от Google (Google's Project Aristotle), где ребята из Google изучали факторы, что делают их команды успешными (и тут psychological safety был основным фактором). Правда, в shepherding он делает фокус на двух моментах

-- Air time management: every team member felt like they had the ability to be heard in group discussions.
-- Social sensitivity: team members could sense how each other felt through unspoken cues.

И это обусловлено тем, что под угрозой наш мозг переходит на краткосрочное мышление, уменьшается креативность, исчезают полутона и остается только черное и белое, а также начинается мышление шаблонами. И автор дает следующие советы
- Для управления временем в эфире: помочь высказаться молчаливым людям, помочь меньше говорить болтунам, как лидеру говорить последним, а также сделать так, чтобы идеи лидера можно было критиковать
- Для повышения социальной чувствительности: смотреть за выражением лиц, использовать режим gallery в Zoom, прокачивать себя в эмоциональном интеллекте
Для этого автор предлагает качать коммуникативные навыки. Ну и один из вариантов взять модельку DISC как инструмент для понимания того, как общаться с командой. Собственно, лидер может адаптироваться к предпочтениям команды в общении.
4) Management - здесь автор рекомендует инструментарий с сайта manager-tools.com, где есть разделы про то как и зачем проводить встречи один на один (one-on-ones), как давать обратную связь, как быть коучем, как делегировать работы, проводить эффективные встречи. Честно говоря, этот список является базой для менеджеров и не обязательно покупать материалы с этого сайта, чтобы изучить эти вопросы:)
5) Being followed - для того, чтобы быть лидером, за вами должны хотеть следовать:) Ну а лидер должен помогать расти своим сотрудникам, звучит это напутствие так

- People should grow under your management
- Growth in strengths
- Mitigate weaknesses
- Think about trajectory
- As much as you can, care for the person

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

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

#Management #Leadership #Processes #Strategy #SelfDevelopment #Software

Working Backwards: Insights, Stories, and Secrets from Inside Amazon (Стратегия Amazon) - Part III (Рубрика #Management)

Заканчивая разбор книги про Амазон, начатый в постах 1 и 2, расскажу про вторую часть книги "Машина для изобретений в действии". В этой части книги автор рассказывает про 4 топовых продукта Amazon, которые стали топовыми в компании. Сам рассказ интересен в разрезе демонстрации применения принципов из первой части книги. Собственно, вот эти продукты
1) Kindle - история про Kindle начинается с того, как Amazon вообще сделал ставку на цифровые товары. Это было не просто, так как до этого фокус был на физических товарах, где ассортимент и логистика были конкурентными преимуществами Amazon. Здесь эти преимущества уже не имели значение. В итоге, развивать это направление отправился single-threaded руководитель уровня первого вице-президента, а до этого этим направлением руководил продакт менеджер на 4 уровня ниже в оргструктуре. Суть в том, что ребята в Amazon смотрели на вопрос цифровых продуктов с точки зрения платформы, где на одной стороне есть создатели контента, на другой потребители контента, а посередине цепочки создания ценности есть аггрегация их в одном месте. Дальше ребята пошли от потребностей клиентов и решили, что им нужно сделать так, чтобы читать электронные книги было удобно. Отсюда появилась идея сделать читалку, причем компанию не смутило отсутствие компетенций в создании железа. В 2005 году Amazon купил французскую компанию Mobipocket, что делала софт для просмотра и чтения электронных книг, а также открыли Lab126 для создания hardware. Суть устройства была в том, чтобы оно хорошо лежало в руке, синкалось с электронной библиотекой без проводов (через мобильную сеть) и имело e-ink экран, который обеспечивал долгое время работы. По итогу нескольких лет работы получился бестселлер в виде Kindle.
2) Prime - история про созданию подписки, которая позволила Amazon наращивать пользовательскую базу и частотность покупок. Интересно, что тут не получалось посчитать экономический эффект и Джефф Безос дал отмашку на эксперимент, который закончился успешно. Многие компании теперь тоже пытаются создавать свои экосистемные подписки, но мало у кого это работает хорошо
3) Prime Video - здесь рассказ начинается с первой попытки запуска видео-сервиса, дальше продолжается переходом на VOD модель (video-on-demand), а дальше созданию видеосервиса как части подписки Prime. Собственно, это убрало давление на продукт с точки зрения оценки cost vs value, так как он стал бесплатным для подписчиков. Это был способ перехода Amazon на сторону производителей контента, так как потом Amazon начал снимать свои фильмы и конкурировать с другими создателями контента вида: Netflix, HBO, Disney, ...
4) AWS - история самого популярного облака раскрыта слабовато, если оценивать со стороны гиков, но тут есть интересный момент, что AWS начиналось изначально с создания API для affiliate программ - это партнерский маркетинг, где партнеры Amazon могли отображать на своих страницах в интернете продукты с сайта Amazon. Если посетители сайтов покупали какие-то товары на Amazon, переходя по этим ссылкам, то владельцы сайтов получали небольшую денюжку от Amazon. Собственно, для этой программы создали API для получения данных о товарах, а дальше пошло-поехало и дальше API становилось все больше, а в 2006 году появился AWS с generic-сервисами вида EC2 и S3, которые позволяли собрать свои приложения на облачной инфре от Amazon.
Интересно, что авторы говорит не только про успехи, но краем задевают и неудачи вида Fire Phone, который прожил чуть больше года:)

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

#Management #Leadership #Processes #Strategy

Alexa Is in Millions of Households—and Amazon Is Losing Billions (Рубрика #Management)

В продолжение обзора книги "Working backwards" подоспела статья от "The Wall Street Journal" на тему того, как юнит smart devices в Amazon создавал успешные продукты, которые генерировали миллиарды убытков каждый год. Этот кейс интересно разобрать в стыке с примером про Kindle из второй части книги (подробнее здесь). Суть статьи примерно следующая
- В 2014 году был запущен Echo и Alexa с моделью типа Gillette, где сам станок продавался за гроши, а дальше заработок был на сменных лезвиях. Примерно так же делал и Amazon, который демпинговал, продавая Echo
- Через 10 лет Echo у сотен миллионов человек, но этот подход не сработал - люди не стали значимо покупать через товары на Amazon через голосовой ассистент Alexa
- Когда CEO был Джефф Безос направление устройств имело зеленый свет и его значимость измерялась при помощи метрики "downstream impact", который присваивает финансовую ценность продукту или услуге на основе того, как клиенты тратят деньги в экосистеме Amazon после их покупки
- Для некоторых продуктов такой подход работал хорошо - например
-- Для Kindle, так как после покупки читалки пользователи покупали на Amazon электронные книги
-- Для Fire TV, где рекламные объявления можно было аттрибутировать к самому продукту Fire TV
- Но вот для части устройств это работало не очень хорошо и в 2021 году, когда CEO стал Andy Jassy, то он сделал ревью прибыльности бизнес линий и погрузился в бизнес девайсов, где были закрыты: Astro, Halo fitness tracker, Amazon Glow и так далее
- А вот сейчас для Alexa ключевой момент - ребята добавят gen AI, что расширит функции ассистента, а также принесут дополнительные деньги в копилку компании за счет дополнительной подписки

P.S.
В общем, книга + статья смотрятся вместе интереснее:)

#Management #Leadership #Processes #Strategy

Complexity is the Gotcha of Event-driven Architecture • David Boyne • GOTO 2024 (Рубрика #Architecture)

Интересное выступление от David Boyne, Senior Developer Advocate at AWS, который рассказывает в своем докладе про преимущества и недостатки event-driven architecture (EDA). Суть в том, что сложность присуща архитектуре, управляемой событиями, сразу с самого начала, но если использовать правильные подходы, то по мере роста системы эта сложность не увеличивается настолько быстро, как при других подходах к проектированию.
Собственно автор выстраивает свое выступление следующим образом
- Сначала он рассказывает про потенциал EDA - как EDA делает архитектуру эволюционной, а не статичной:)
- Потом он рассказывает про guardrails для того, чтобы справляться со сложностью EDA
- Как можно обосраться с EDA

Потенциал EDA можно увидеть, построив график по двум осям: size и time. Дальше на графике надо отобразить решения, которые надо принимать, а также знания, которые у нас имеются для этого. Суть в том, что в начале проекта знаний у нас мало, а решения нам надо принимать крупные. Это называется "project paradoxon", для решения которого нам надо уметь откладывать крупные решения до получения нужного количества знаний ... или учиться быстрее. Но, принимая решения без нужного количества знаний, мы часто оказываемся в условиях статичной архитектуры, которая характеризуется свойствами: tightly coupled, low cohesion, resistance to experimentation, team interdependency. В противовес этому автор утверждает, что использование EDA позволяет создать эволюционную архитектуру (как в книге "Building evolutionary architecture", подробнее здесь), у которой как говорит автор есть свойства: loosely coupled, high cohesion, platform to experiment, team dependency. К тому же она
- Позволяет создавать компоненты, которые можно менять местами в зависимости от ситуации.
- Повышает качество кода и позволяет экспериментировать.
- Может привести к инновациям, но также увеличивает сложность.

Дальше автор показывает как определить события, а дальше как начать им обмениваться между producers и consumers. Дальше это все начинает эволюционировать и легко получить ад из разных событий, разных producers и consumers и с отсутсвием любого понимания о том, как все это работает:) Для решения этих проблем автор предлагает использовать guardrails
1) Behavior vs implementation - начинать надо не с деталей имплементации, а с поведения системы. Здесь автор вспоминает про Альберто Брандолини и его подход Event storming, про которую я уже вспоминал. Эта техника позволяет начать с событий внутри системы, а в итоге понять ее поведение и заодно разобраться с bounded contexts:)
2) Event evolution strategy - при старте EDA проекта надо подумать про эволюцию событий. Автор приводит метафору о том, что events рассказывают историю, а tables - описывают состояния прямо сейчас. Автор предлагает контролировать сложность схемы событий через обратную совместимость, опциональные поля и параллельные версии событий
3) Define coupling strategy - это можно сделать через использование в консьюмерах подходов conformist, ACL (anti-corruption layer) и open-host principle (хорошо описано в книге "Learning DDD", подробнее здесь). Тут же автор предлагает разделять public и private events - внутри домена или между ними

Но самая большая проблема в том, что есть мантра

Producers should not know about consumers

приводит к тому, что управлять этой системой по мере эволюции становится невозможно. Поэтому автор предлагает использвать следующие инструменты
- cloudevents - cпецификация для общего описания данных о событиях.
- AsyncAPI - фактически, OpenAPI для асинхронных API
- EventCatalog.dev - open source проект автора с описанием, который помогает документировать сообщения, команды, запросы и события, а также создавать версии доменов и служб.

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

#Architecture #SoftwareArchitecture #DDD #SystemDesign #DistributedSystems

How Google Works (Как работает Google) (Рубрика #Management)

Интересная книга от Эрика Шмидта (ex CEO Google) и Джонатана Розенберга (ex VP Google), которая была издана в оригинале 10 лет назад и рассказывает про внутреннее устройство Google. Книга хорошо структурирована и состоит из следующих частей
1) Введение - авторы рассказывают про то, как они оказались в Google и как им пришлось отвыкать от диаграмм Ганта и следовать совету "просто пойди и поговори с инженером". Также они говорят про скорость изменений, которые происходят сейчас в бизнесе, а также тут появляется определение умного креативщика, условного инженера, которым теперь и приходится руководить менеджером. Этот умный креативщик сильно отличается от синего воротничка с конвейера, так как он зачастую лучше знает как именно сделать сложную задачу, которая не пугает его, а скорее заставляет проявить свои лучшие качества.
2) Корпоративная культура - эта глава начинается с рекомендации, что надо "поверить в собственные лозунги", так как культура - это про поведение, а не про громкие фразы. Глава начинается историей про AdWords, когда записки Ларри Пейдж в 2002 году нашел проблему с релевантностью рекламы в поиске и повесил на кухне примеры этой рекламы с комментарием "эта реклама - полный отстой". Дальше за выходные команда умных креативщиков (во главе с Джеффом Дином) никак не связанная с командой AdWords разобралась с проблемой, придумала концепцию и запилила прототип. Это стало возможным благодаря культуре стартапа, где умные креативщики верили в ценности компании и важность пользователя и то, что они делают этот мир лучше. Дальше идет совет про то, что креативщикам лучше работать в тесноте (аля в open space), не слушать Hippo при принятии решений. Авторы делятся своими мыслями про плоскую структуру и организацией команд - приводится совет о том, что команды под одним руководителем должны насчитывать не меньше 7 человек. Вообще, в этой главе много интересных мыслей и хороших историй - рекомендую ее прочитать в оригинале.
3) Стратегия - основная мысль здесь в том, что тяжеловесные стратегии из прошлого не работают в современном динамичном мире. Авторы предлагают делать ставку на технические инсайты, а не на маркетинговые исследования.
4) Кадры - глава посвящена тому, что подбор персонала - это самое важное. А умение проводить собеседования - это важный навык:)
5) Решения - здесь авторы рекомендуют принимать решения на основе данных, говорят о том, как принимать меньше решений, а также, что у решений должен быть "хозяин"
6) Коммуникации - менеджерам авторы советуют быть хорошими маршрутизаторами информации, а также быть открытыми by default. Здесь опять всплывает история про psychological safety и проект Аристотель
7 Инновации - авторы используют метафору первичного бульона, из которого появились первые аминокислоты. Именно такой первичный бульон для зарождения инноваций они и предлагают создавать внутри компании. Они отмечают, что на первом месте при инновациях должен стоять пользователь, а также рассказывают про использование OKR для постановки целей. Также авторы настаивают на том, что надо отгружать продукт пользователям, а потом итеративно его улучшать.
8) Заключение - здесь авторы заботливо приводят основные мысли относительно того, что в современном мире побеждают платформы (подробнее в книге "Machine, Platform, Crowd", про которую я уже рассказывал), а также про важность информации и умения работать с ней.
Книгу действительно интересно читать, хотя есть ощущение, что история получается слишком красивой, чтобы быть правдой:)

#Management #Leadership #Processes #Strategy #SelfDevelopment #Software #Bigtech

AMA сессия нашего core и data tech в Т-Банк (рубрика #Management)

Мои коллеги из наших технологических платформ собрали сегодня сессию Ask Me Anything. Они делают крутые инженерные штуки, но раньше им не хватало внутреннего пиара и открытости. Теперь они решили с этим побороться и собрали на нашей крыше большую встречу, на которой откровенно ответили на вопросы, часть из которых была довольно острой. Думаю, что такие встречи станут доброй традицией.

#Engineering #Management #Processes #Software

ЦЕХ 4 - Урок #11 "Правила сильной книги захватывающего текста. Эксперт — Лариса Парфентьева" (Рубрика #Writing)

Очередной урок из курса МИФа для начинающих/продолжающих авторов на пути к своей книге. Интересно, что этот урок был больше сфокусирован на художественной литературе, а я неторопливо пишу non-fiction. Но даже так его было интересно послушать и попытаться намотать на ус подходы, которые можно использовать в своей книге. Эксперт построила свой рассказ прямо по пунктам и вот они
1) Проверьте начало и конец каждой главы - если начало главы не интересно, то дальше можно и не читать. А если окончание не интересное, то конверсия перехода к новой главе может просесть:)
2) Проверьте героя на симпатичность - читатели обычно хотят сопереживать героям, но если герой совсем не вызывает симпатии, то высока вероятность закрыть книгу вместо погружения в приключения героя
3) Задайте вопрос "Можно ли отложить достижение цели" - если ответ да, то конфликт не достаточно мощный для того, чтобы за ним было интересно следить читателям. Важно, чтобы было ощущение urgency
4) Герой должен сомневаться в себе - если это не так, то читателям не интересно следить за приключениями идеального героя, у которого нет никаких сомнений
5) Не рассказывайте, а показывайте - картинка является важным инструментом для движения сюжета.
6) Проверьте плотность фактуры - в тексте должна быть определенная плотность смысла.
7) Проверьте скорость текста - если скорость разная, то где-то читатель заскучает, а где-то наоборот начнет пробуксовывать и упустит какую-то важную мысль
😍 Не забывайте про метафоры - я помню, как про их важность узнал больше 20 лет назад из классической книги Стива Макконелла "Code Complete", о которой я уже рассказывал
9) Сокращайте - если что-то можно выбросить из текста без потери смысла, то это стоит сделать. Тут вспоминается цитата Антуана де Сент-Экзюпери

Совершенство достигается не тогда, когда уже нечего прибавить, но когда уже ничего нельзя отнять.

Ну и эксперт предлагает
- Убирать лишние слова и детали, которые не влияют на смысл текста.
- Использовать активный залог вместо пассивного.
- Избегать причастных и деепричастных оборотов, слов-паразитов и усилителей.
- Не злоупотреблять восклицательными знаками.
10) Не останавливайтесь на одной книге - первая книга - это только начало:) После первой книги будет вторая, третья, ...

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

Предыдущие посты доступны здесь:
1) Увидеть свое имя на обложке может каждый
2) Целевая аудитория и ее потребности в создании книги
3) Жанры и стили. Как найти тему для нон-фикшн-книги
4) Как организовать работу
5) Как преодолеть писательские блоки. Практическое занятие
6) Жду музу, а она все не приходит
7) Книга по полочкам
😍 MS Word для работы с большими и сложными текстами
9) Рассказываем истории: сторителлинг в книге
10) Саморедактура: работа с текстом, сокращения, фактчекинг

#SelfDevelopment #PublicSpeaking #Storytelling #Writing

Дизайн пользовательского опыта (Design for How People Think: Using Brain Science to Build Better Products) (Рубрика #Design)

Эта книга Джона Уэлена рассказывает про создание UX дизайна продуктов с использованием знаний о человеческой психологии. Автор пытается разложить опыт клиентов на шесть компонентов, а дальше использовать их для создения идеального продукта. Английская версия была издана в 2019 году, а в этом году ее неплохо перевел МИФ. Автор неплохо разбирается в когнитивной психологии и использует ее для того, чтобы быть лучше как продуктовый дизайнер.

Если говорить про 6 основных составляющих подхода автора, то это
1) Визуальное восприятие, внимание и автоматизм - что привлекает потребителей? Какие слова, изображения и объекты они стремятся найти?
2) Навигация - Как потребители понимают пространство, в котором они находятся (в физическом мире и в виртуальном)? Как они ориентируются в этом пространстве, как представляют себе взаимодействие с ним, а также с другими участниками?
3) Язык - Какие слова используют потребители? Какой смысл они вкладывают в эти слова? Как можно понять их уровень подготовки из того, какие слова они используют?
4) Память - Какой прошлый опыт используют потребители при взаимодействии с вашим продуктом? Какие ментальные модели и стереотипы участвуют при этом, какие у них ожидания того, как будут работать вещи в этом мире и что будет дальше?
5) Принятие решений - Какую проблему решают потребители с их точки зрения? Совпадает ли их мнение о проблеме с реальной проблемой? Какие промежуточные проблемы надо решить на пути к главной цели?
6) Эмоции - В чем состоят глубинные цели, желания и страхи потребителей? Какие из этих эмоций влияют на принятие решений? Чего они стремяться добиться?

На эти моменты автор обращает внимание при проведении контекстных интервью, которые автор ценит выше фокус-групп, опросов и глубинных интервью. Если объяснять на пальцах, то это такой тип интервью, что
- Проводится в обычной рабочей/домашней обстановке потребителя
- Исследовать наблюдает за выполнение работы потребителем
- И задает уточняющие вопросы для того, чтобы понять почему потребитель делает то или другое действие
Автор предлагает проводить десятки таких интервью в поисках инсайтов и дальше их классифицировать по 6 приведенным выше категориям. Дальше после такого анализа можно провести сегментацию потребителей и сформулировать гипотезы о том, как улучшить продукт. Например, автор рассказывает про создание лендинга для малого и среднего бизнеса, что хочет подключиться к Paypal. Он объясняет как было проведено исследование, какие гипотезы были созданы, а дальше получился лендинг. Мне кажется, что он пропускает часть с большим количеством a/b тестов, но ему это простительно, так как он скорее занимается качественными исследованиями.

Ближе к концу книги автор рассказывает про дизайн-мышление (design thinking) и процесс дизайн double dimond.
В общем, это очень простаяя, но полезная книга для создаетелй продуктов:)

P.S.
Мне на самом деле ближе количественные исследования, поэтому рекомендую глянуть книги на тему проведения a/b экспериментов, про которые я рассказывал раньше
- Как лгать при помощи статистики (How to Lie with Statistics) - на пальцах объясняется как врут с помощью статистики, а отсюда становится ясна мотивация создания системы подведения итогов экспериментов
- Understanding Statistics and Experimental Design. How to Not Lie With Statistics (Статистика и планирование эксперимента для непосвященных) - в этой книге рассказывается про дизайн экспериментов и математику, что стоит за ними
- Доверительное a/b тестирование (Trustworthy Online Controlled Experiments) - а эта книга позволяет еще и понять как сделать платформу для проведения экспериментов на уровне всей компании
- Темные данные (Dark Data. Why What We Don’t Know Is Even More Important Than What We Do) - книга про то, как можно облажаться с данными и что с этим можно сделать

#Architecture #Management #Thinking #Leadership #SystemDesign #SystemThinking #Design