Как формировать структуру команд под запросы бизнеса - часть 3

Продолжу пост про структуру команд и проектный подход и в этом посте мы поговорим про продуктовую разработку. В прошлом посте я много говорил про полезность проектного подхода и возникает вопрос, а зачем нам нужна продуктовая разработка, если есть такие замечательные проекты. Но проекты хороши для старта новых инициатив или ведения кросс-командных активностей. А вот если мы хотим более планово и непрерывно поставлять ценность, то мы приходим к концепции продукта, где
- Есть конкретная целевая аудитория продукта
- Есть примерное понимание какие фичи, стори, JTBD (jobs to be done) мы хотим реализовать
- Есть желание выкатывать эти изменения небольшими порциями и тестировать как они работают
- Есть понимание, что план может гибко меняться в процессе движения
С таким набором ожиданий становится ясно, что проектный подход нам не подходит. В итоге, мы приходим к продуктовым процессам разработки, про которые я рассказывал в докладе "Совершенствование потока разработки программного обеспечения", где я рекомендовал почитать книгу "Making Work Visible" от Доминики Деграндис, про которую я писал раньше. Но вообще есть несколько подходов к тому как организовывать работу и планировать время ее выполнения. Однако важно помнить про ироничный закон Паркинсона

Работа заполняет время, отпущенное на неё

Этот закон дает понять почему планирование работы с буферными запасами проблема, а именно так часто планируют в проектном управлении. Но если планировать работу задач на команду в режиме push, то можно столкнуть с тем, что требования к командам и их производительность не сбалансированы, что не позволяет выполнить все задачи вовремя. В итоге, нам нужна система с pull режимом, когда люди вытягивают новую задачу по мере завершения предыдущей. Такой системой, например, является Kanban. Но важно понимать какие задачи попадают в такой процесс - важно не соглашаться на все подряд, а обдуманно давать добро только на самые важные в конкретный момент и делать это визуально. Для этого надо организовать систему рабочего потока, выполняющую следующие задачи
- Делает работу видимой
- Ограничивает количество незавершенной работы
- Оценивает рабочий поток и управляет им
- Эффективно определяет приоритеты
- Вносит коррективы на основе метрик и обратной связи

И проблема со временем и его утеканием обязана следующим пяти факторам
- Too WIP - история про незавершенную работу, бутылочное горлышко и закон Литтла.
- Unknown dependencies - здесь про архитектурные проблемы и зависимости между системами и разными командами.
- Unplanned work - незапланированная работа крадет время у запланированной. Этим она делает систему непредсказуемой, а главное для нас — это прогнозируемость и ожидания.
- Conflicting priorities - если все задачи приоритетные, то ни одну из них нельзя назвать реально важной. Без внятных приоритетов людям приходится пытаться сделать слишком много сразу, что автоматически приводит к росту WIP, который замедляет всю систему.
- Neglected work - часто такая работа проявляется в форме техдолга, который накапливался в системе, когда люди только клепали фичи без работы по повышению технического совершенства системы. Вообще, часто проседает важная но не срочная работа, которую так любят откладывать … пока она не перерастет в экстренную ситуацию, когда станет незапланированной работой, от которой нельзя отказаться.

В итоге, я всегда стремился выстроить продуктовые кросс-функциональные команды, используя Kanban подходы. В целевом виде эти команды являлись stream-aligned командами из Team topologies (подробнее в обзоре 1, 2, 3). Про то, как я строил продуктовую разработку я рассказывал в контексте нашего веба Tinkoff.ru в двух давних докладах
- Доклад на Teamlead Conf 2018 про масштабирование фронтовых команд Tinkoff.ru с управленческой точки зрения
- Доклад на ArchDays 2019 про эволюцию всей связки фронт - бек - система a/b тестов, где фокус больше на архитектурных изменениях

#Management #Leadership #Project #ProjectManagement #Software

Tinkoff TeamLead Meetup 1

Интересный митап на тему тимлидов от Тинькофф, которое прошло под знаменем наджености и в котором было 4 выступления по 20 минут + 10 минут на вопросы/ответы. Вот эти доклады

1) Как выиграть гонку с бизнесом на высоконагруженном сервисе, обеспечивая высокий уровень надежности
Выступление Владислава Хачатурова из Сбера на тему того, как выстроены внутренние процессы на самом высоконагруженном сервисе "Главный экран" для приложения Сбербанк Онлайн в условиях вечной гонки, с обеспечением высокой надежности. Тут много было про inner-source и как сделать платформенную команду, которая работает над архитектурой, надежностью, принимает сервисы в эксплуатацию от продуктовых команд, которые контрибьютят в сервисы платформенной команды.
2) Как мы падали и поднимались. И чему научились в процессе.
Выступление Ильи Барбашова из Авито, где он рассказывает про как в Авито захворали важные инфраструктурные сервисы (Kafka as a Servioce). А дальше как ребята изменили подход к оценке их надежности, и как это помогло планировать им работу и общаться с пользователями, которыми являются продуктовые разработчики.
3) Настройка окружения
Выступление Алексея Калакина из билайн, в котором он рассказал о проблемах взаимодействия с инфрой, и с интеграционно связанными приложениями. Он разобрал как настроить свзяь бизнеса и технических лидов, а также показал как решать это различными методами.
4) Стратегия управления техническим долгом
Выступление Никиты Ульшина из Тинькофф, в котором автоп рассказывает про то, откуда берётся техдолг, как он влияет на продуктивность и мотивацию команды, как правильно планировать работу над техдолгом и как избавиться от него. Дальше идет обсуждение приоритизации и того, как продавать результаты работы над техдолгом. Интересно, что Никита работает в команде, которая делает бекенд систему для нашего server driven UI для веб приложений, а про эти системы я уже раньше упоминал в других докладах:)

#Management #Engineering #Software #SoftwareDevelopment #Architecture #Processes #SRE #Leadership

Радость познания (The pleasure of finding things out) - 1

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

А теперь немного про содержание книги

1. Радость познания сути вещей - статья, что дала название всей книге. В ней мы видим как подход к познанию Ричарда сформировался под влиянием отца, который не учил терминам или теориям, а учил наблюдать за окружающим и видеть суть и взаимосвязи. Мне особенно понравилось познание через аналогии ака "тиранозавр в окне" (смотри на эту тему рекомендую "Большую книгу аналогий") и разбор алгебры для практичного человека, где Ричард рассказывает про инструкции из школы про решение задач как "целый набор шагов, с помощью которых вы могли бы получить ответ, если не понимаете, что вы пытаетесь сделать". Остальная часть статьи тоже очень интересна, не даром она идет первой в книге.
2. Компьютеры будущего - в этой статье Ричард выступает провидцем и говорит о параллельных компьютерах и их миниатюризации. Достаточно интересно обсуждался вопрос обратимых и необратимых вычислений и связи скорости вычислений с потреблением энергии. Все это рассматривается не с позиции технических возможностей почти сорокалетней давности (лекция 1985 года), а скорее с точки зрения концептуальных возможностей и того, что это видение не противоречит существующим физическим законам
3. Лос-Аламос - взгляд снизу - это рассказ про времена Фейнмана в Лос-Аламосе и участие в Манхэттенском проекте. В принципе, это все обсуждалось и в уже упоминавшейся книге "Вы, конечно, шутите ..."
4. В чем состоит и в чем должна состоять роль научной культуры в жизни общества - здесь Ричард рассказывает про научный подход, выдвижение гипотез и теорий, их полезность и фальсифицируемость. Он верит в то, что и жизнь общества должна идти по пути, похожему на научный - "всегда нужно оставлять место сомнениям, дискуссиям" и что "придет время, когда люди полностью осознают, что сила власти ограничена, что правительства не уполномочены решать вопрос, ценна ли научная теория или нет ... Они не должны присваивать себе право делать выбор между различными версиями описания истории, экономической теории или философии"
5. Как много места в глубине - в 1959 году Фейнман в Калтехе рассказывал про нанотехнологии - это было провидческое выступление, где он упоминал про: хранение информации, аналог фотолитографии, выстраивание атомов для создания новых материалов. В конце он устроил конкурс по миниатюризации, который в итоге превратился в премию Фейнмана по нанотехнологиям
6. Ценность науки - лекция в формате урока для молодых ученых о том, что они несут ответственность за будущее цивилизации
7. Особое мнение Ричарда Фейнмана, касающееся следствия по делу космического корабля-челнока "Челленджер" - если говорить на it'шном, то Ричард участвовал в написании постмортема по инциденту с "Челленджер", но его мнение не хотели учитывать в официальном отчете, поэтому он написал свое "особое мнение" и добился включения его в официальный отчет (в приложении)

P.S.
Продолжение разбора в следующем посте.

#PopularScience #Physics #Biography

На корпоративе коллеги пошутили со сцены, представляя меня, что в 2024 году

Александ Поломодов научится читать книги быстрее, чем авторы их писать

С учетом плана написания своей книги, это очень вероятно:)

#Humour

Как формировать структуру команд под запросы бизнеса на YaTalks 2023

Появилась запись моего выступления на YaTalks, где я рассказывал про основы и принципы дизайна команд, которые помогали мне на протяжении 7 лет работы в Тинькофф.
Часть выступления уже доступна в виде расшфировок
1) пост про структуру команд
2) пост про проектный подход
3) пост про продуктовый подход
4) пост про масштабирование (пока на очереди)

В общем, для тех, кто больше любит видео, теперь оно доступно для просмотра:)

#Management #Leadership #Project #ProjectManagement #SoftwareDevelopment #Software

Code of Architecture рзабор white paper «Google's Hybrid Approach to Research»

Сегодня в 18:00 мы проведем новогодний стрим по архитектуре. В рамках встречи мы поговорим про то, как устроено RnD (Research and Development) в Google
— какую цель исследований поставила для себя компания и почему;
— к каким резльтатам она привела;
— как устроен гибридный подход к исследованиям там;
— как выглядят паттерны организации взаимодействия исследовательских и продуктовых инженерных команд;
— почему и зачем компании инвестируют в Google.

Гостями эфира станут наши коллеги
- Игорь Маслов, руководитель управления базовых технологий и обработки данных Тинькофф
- Станислав Моисеев, директор инженерных исследований в Тинькофф

На тему стрима можно почитать материалы
- PDF версия доступна здесь
- Мой обзор этой статьи доступен здесь
- Моя статья про RnD в крупных компаниях (Google, Amazon, Yandex, Tinkoff)

#Software #Architect #SystemDesign #Philosophy #SoftwareArchitecture #Processes #Management #RnD #CoA

Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services

Я уже рассказывал про знаменитую CAP теорему за авторством Eric Brewer. А сегодня я расскажу про whitepaper 2002 года от Seth Gilbert и Nancy Lynch, в котором гипотеза стала теоремой. Сама гипотеза для доказательства звучит так

It is impossible for a web service to provide the following three guarantees: consistency, availability, partition-tolerance

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

1) Начать стоит с consistency, где авторы идут в сторону atomic data objects или линеаризуемой консистентности (linearizable consistency)

Under this consistency guarantee, there must exist a total order on all operations such that each operation looks as if it were completed at a single instant. This is equivalent to requiring requests of the distributed shared memory to act as if they were executing on a single node, responding to operations one at a time.

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

2) Второй характеристикой является availability, где для непрерывной доступности каждый запрос, попавший на несбойную ноду системы должен получить свой ответ. Таким образом любой алгоритм для генерации ответа сервисов должен оканчиваться в конечном счете (eventually terminate). Интересно, что это слабое определение доступности, так как нет верхней границы на время ответа - это позволяет unbounded computation. Но если рассматривать это с позиции устойчивости к разделению, то это может рассматриваться как сильное определение доступности - даже если происходят сбои в сети, каждый запрос должен завершиться.

3) Для моделирования partition-tolerance авторы предлагают считать, что в сети может теряться произвольное количество сообщений, что отправляются от одной ноде к другой. А значит мы можем моделировать любой паттерн потерь

When a network is partitioned, all messages sent from nodes in one component of the partition to nodes in another component are lost. (And any pattern of message loss can be modeled as a temporary partition separating the communicating nodes at the exact instant the message is lost.)

Дальше авторы переходят к доказательствам

1) Начнем сначала с асинхронных систем

Theorem 1 It is impossible in the asynchronous network model to implement a read/write data object that guarantees the following properties:
• Availability
• Atomic consistency
in all fair executions (including those in which messages are lost).

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

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

Theorem 2 It is impossible in the partially synchronous network model to
implement a read/write data object that guarantees the following properties:
• Availability
• Atomic consistency
in all executions (even those in which messages are lost).

Доказательство тут похоже на предыдущее как две капли воды:)

Оставшаяся часть white paper посвящена Delayed-t consistency в частично синхронных системах, про которую мы тут говорить не будем.

А в следующем посте поговорим про теорему PACELC.

#Software #Architecture #DistributedSystems #SystemDesign

Пара записей с поездки в Питер на ICPC и ВКОШП

Я уже писал раньше о том, как ездил в Питер на эти мероприятия, чтобы поучаствовать в них, так как Тинькофф спонсирует эти чемпионаты по программированию. Мне очень понравилась атмосфера контеста и его участники, поэтому я рад, что съездил туда + я поучаствовал не только в церемониальных частях мероприятий, но и побывал на прямых трансляциях, где обсудил с Лидией Перовской разные моменты

1) Трансляция ВКОШП - эта трансляция командных соревнований школьников и здесь мы поговорили на следующие темы
- про формат соревнований и почему они настолько интересны
- почему командные соревнования по программированию неплохо моделируют командную работу инженеров в реальной разработке
- про роль тимлида в команде
- про то, что можно успеть за 26 минут
- про выступление на YaTalks про структуру команд
- про то, как я почти не пишу код в последнее время, но стабильно читаю его
- интересно про инциденты и отсылку к публичному интервью по troubleshooting на Devoops
- про a/b платформу и продуктовую аналитику
- про найм олимпиадников в команды (тут я рассказал забавную историю из опыта)

2) Трансляции ICPC - это трансляция командных соревнований студентов и здесь мы поговорили про следующие темы
- про мою зону ответственности в Тинькофф
- про мое обучение в МФТИ
- про сложность подготовки к соревнованиям
- про стажировки в компаниях, где выстроены процессы разработки (лучше в Тинькофф)
- хорошие советы о том, как правильно работать в команде по спортивному программированию:)
- про канбан-метод и визуализацию работы
- про сложные процессы в больших компаниях и синхронизацию знаний
- про важность ретроспектив
- про современные шахматы, обучение им и как это прокачивает мышление

#Software #SoftwareDevelopment #Conference #Engineering

День влюбленных в математику

В следующем году Тинькофф, ИТМО и Тинькофф Образование организует конкурс для студентов, которые любят математику. Победителям достанутся денежные призы и классный мерч. Всего будут три этапа:
- Отборочный онлайн-тур - Разнобой, 12-18 февраля
- Офлайн-полуфинал в регионах России - Интеллектуальная викторина, 2 марта
- Финал в Москве - Математическая регата, 23 марта

P.S.
Мне с самого детства нравилась математика, поэтому я и поступил в МФТИ на факультет управления и прикладной математики. Ученого из меня не получилось, но я до сих пор люблю читать научно-популярную литературу по математике. Например, я раньше уже писал про следующие интересные книги, связанные с математикой
- Модельное мышление (The Model Thinker)
- Принцип ставок (Thinking in Bets)
- Заходит экономист в публичный дом (An economist walks into a brothel)
- Теория игр (A Game Theorist's Guide to Success in Business and Life)
- Игра случая (Fluke. The Math and Myth of Coincidence)
- Теория игр в комиксах
- Величайшие математические задачи (The Great Mathematical Problems)
- Понимать, но не предвидеть. Предвидеть, но не понимать (Comprendre sans prevoir, prevoir sans comprendre)
- Математический беспредел. От элементарной математике к возвышенным абстракциям (Beyond Infinity: An expedition to the outer limits of the mathematical universe)
- Статистика. Краткий курс в комиксах (The cartoon guide to statistics)
- Статистика в комиксах (Inroducing Statistics. A Graphic Guide)
- What Is ChatGPT Doing ... and Why Does It Work?
- Романтика искусственного интелекта
- Занимательная статистика. Манга (The Manga Guide to Statistics)

#Math #PopularScience #Education #SelfDevelopment

Материалы к Code of Architecture по white paper «Google's Hybrid Approach to Research»

В этот понедельник мы провели новогодний стрим по архитектуре. В рамках встречи мы поговорили про то, как устроено RnD (Research and Development) в Google.
Гостями эфира были наши коллеги
- Игорь Маслов, руководитель управления базовых технологий и обработки данных Тинькофф
- Станислав Моисеев, директор инженерных исследований в Тинькофф

Материалы, которые мы упоминали в рамках выпуска представлены ниже
- Мы обсуждали сам white paper, доступный здесь
- Для визуализации взаимодействий мы использовали слайд с топологией команд, который был из моей статьи с обзором этого white paper
- Мы проводили параллели с Team Topologies, про которую я отдельно рассказывал в трех частях: 1, 2, 3
- Мы обсудили и обновленную философию RnD от Google с сайта research.google. Интересно, что она чуток поменялась со временем написания whitepapaer про гибридный подход
- Мы пробедали быстро по крупным технологическим whitepaper от Google, про которые я отдельно рассказывал в статье про RnD в крупных компаниях (Google, Amazon, Yandex, Tinkoff)
- Поговорили про наши технологические продукты, которые были созданы для решения продуктовых задач и доступны на нашем сайте, например, про observability платформу Sage или наш Tinkoff VoiceKit для обработки голоса

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

#Software #Architect #SystemDesign #Philosophy #SoftwareArchitecture #Processes #Management #RnD #CoA

Patterns & Anti-Patterns for Effective Feature Flagging • Edith Harbaugh • YOW! 2019

Интересное выступление от Edith Harbaugh, co-founder и CEO платформы для фича флагов LaunchDarkly. В самом начале Edith вспоминает про темные времена, когда она работала в компании, где релизы были раз в полтора года ... и это было быстро, потому что у конкурента они были каждые три года:) Дальше начинается рассказ про паттерны и анти-паттерны их использования. Но до этого хотелось бы обсудить, что сама идея флагов кажется очень простой: нам надо уметь закрывать часть функциональности в коде флагом, который можно удаленно включить/выключить. Это помогает с несколькими вещами
- С feature flags хорошо работает TBD (trunk based development), а без них почти нет
- Release management становится проще (особенно в мобилках)
- Можно тестировать функциональность на части аудитории, например сотрудниках
Но тут мы оказываемся на стыке двух миров - работы с кодом и релизами и экспериментами (a/b тесты, сегментация пользователей, персонализация, ...)

Ну а дальше давайте я расскажу про какие вещи говорила Edith

Паттеры и хорошие способы применения флагов
- Feature kill switches - паттерны для отключения фичей на случай проблем или на случай спайка нагрузки
- Мердж бранчей без конфликтов - условно feature flag - это enabler для TBD, про который я уже говорил
- Controlled rollout - условно раскатка порции трафика на новую фичу
- Early access betas для самых лояльных/лучших пользователей
- Для блокировки фичей для некоторых пользователей (например, тех, кому нужны только отстоявшиеся фичи)
- Для тестирования в проде и сокращения важности staging контура (Edith предлагает его вообще убить)
- Для подписок, где часть фичей доступна только по подписке (я думаю, что это странный кейс конечно)
- Для отключения старых фичей

Антипаттерны и косяки
- Кривое наименование флагов - это просто путает и мешает использовать флаги
- Overused flags - одни и те же флаги, которые используются разными командами по разному, условно одни думают, что этот флаг лечит от кашля, а другие, что от запора:)
- Конфликтующие флаги - учитывая комбинаторику, конфликтующие очень легко получить, особенно если не подумать заранее о том, что именно мы закрываем флагами
- Использование флагов для критической функциональности, которая уже давно не должна отключаться - пример с CMS системой, где можно флагом было отключить загрузку файлов, что эффективно отключало всю систему:) Смысл в том, что такой флаг уже давно стал бесмыссленным:)
- Флаги, что остаются в коде и никогда не выпиливаются - это просто ухудшает кодовую базу

Напоследок приводятся рекомендации
- Flag carefully
- Lock down access
- Remove flags

P.S.
У нас в компании были разные системы для управления флагами и экспериментами. Сейчас мы идем в сторону общего решения, где
- Базовые сценарии управления флагами будут прямо внутри нашей IDP (internal developer platform) - эта часть про код + release management
- Расширенные сценарии управления будут внутри a/b платформы - это часть про использование флагов для экспериментов, персонализаций, бет и так далее

Если вам нравятся такие задачи и у вас есть опыт промышленной разработки, то вы можете написать мне:)

#Software #Devops #SRE #Reliability #Architecture #Engineering #Processes