Бизнес-линии, сервис-линии и платформы @ T-Bank - Part III - (Рубрика #Management)

Продолжу первые два поста (1 и 2) и расскажу как мы из квази-продуктовой команды делали платформу. Здесь речь идет про Мобильный Банк, о котором я рассказывал много раз и раньше, но самый сочный рассказ был на Higload ++ Spb 2022. Но для этого поста я сокращу его до кратких тезисов:
- До конца 2019 года Мобильный Банк Тинькофф рассматривался как самостоятельный продукт, который развивался и побеждал во всех рейтингах вида MarksWebb
- Команда была монолитной и со своими приоритетами, где фокус был на кредитных и дебетовых продуктах, а также лайфстайл сервисах
- Но в 2019 году компания решила, что Мобильный Банк должен стать супераппом, в котором представлены все бизнес-вертикали (из терминологии первого поста)
- В этой концепции мобильный банк должен был стать платформой, а точнее позволить продуктовым командам бизнес-вертикалей автономно разрабатывать свои фичи внутри приложения
- Для того, чтобы это работало надо было выделить платформенные команды, которые позволяли бы обеспечивать такие вещи как: согласованная архитектура приложения, общие инструменты для тестирования, сборки, производительности, надежности, дизайн решений

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

P.S.
В общем про подходы формирования структуры команд под запросы бизнеса я рассказывал раньше в постах про
- структуру команд
- проектный подход
- продуктовую разработку

А также рассказывал про это на конференции Yandex под конец 2023 года

#Management #Leadership #Software #Processes

Interview with Product Manager in 2024 [Corporate] (Рубрика #Humour)

Еще одно отличное видео про профессии в IT, но в этот раз про product менеджеров в enterprise (в прошлый раз я писал про agile коучей). Здесь и про dog fooding, целепологание и синхронизацию бизнеса и IT, про поитику, процессы и эмоции, ведение JIRA и использование почты и так далее. Мне особенно понравились эти цитаты

- Politics over progress, processes over logic, emotions over process
- We did not meet our OKRs this quarter, we need to change our OKRs
- I have never used our product
- I’m not saying they know what they’re doing, I’m just saying I really don’t care
- We have a tool to consolidate our documents... my downloads folder
- I'm gonna issue a Jira ticket, but I'll send it by email... so you will forget.
- Nobody has a clue what we're doing
- I barely know the names of most of the people on our team
- We define the requirements at the beginning of the project. Changes come in through change-requests. We do have the agile manifesto hanging on the wall, so to me it sounds like agile.

В общем, рекомендую посмотреть видео в оригинале и насладиться отличным юмором автора и узнаваемыми ситуациями:)

#Management #Leadership #Processes #ProductManagement #Project

Канал "Евгений Козлов пишет про 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