Юниты, домены, кластеры и другие звери корпоративного мира

? О чём говорим?

В компаниях есть свои названия. Часто они обозначают похожие вещи разного масштаба: зоны ответственности бизнеса

? Что видит менеджер
Мне нравится inDrive. Возьму их предметную область в качестве примера:

- Онбординг водителя
- Заказ
- Подача машины
- Поездка

Есть другие домены, с которыми обычно менеджер не сталкивается в работе, но знает о них. Например, бухгалтерия. Домены нужны для управления сложностью. Большой домен сложнее понимать. Много доменов сложнее держать в фокусе

Домены связаны. Плохо заонбордили водителя - плохо подали машину. Есть связи внутри домена: скорость поставки ценности и качества (например связь с product-market-fit в моём телеграм-канале)

Чем занимается
Отвечает за домены:
- приоритизирует проекты
- управляет ожиданиями стейкхолдеров
- гарантирует ключевые показатели
- решает зависимостей

?‍? Что видит инженер
Команд много. Домены ассоциируются с конкретными сервисами и командами. Например, сообщения соседней команде отправляем, она - нам. Про большую часть сервисов компании, кроме соседей, инженер ничего не знает

Чем занимается
Реализует передачу данных из одного сервиса в другой. Инженер сфокусирован на своей предметной области. У соседнего домена всё по-другому. Доработки сложны - раньше такого никогда не было и не предполагалось

? Где непонимание менеджера и инженера
Менеджер видит связи доменов упрощённо и не знает о двух каналах сообщений. Нет информации и о том, что это рисковый способ передачи. Неожиданностью будет 2-3 или даже 10 связей вместо 1-ой

Инженер знает особенности в конкретной интеграции. Он будет удивлён, что "Подача машины" и "Заказ" как-то связаны в принципе, да ещё и через SOAP (протокол)

? Как договариваться
Емкость памяти ограничена. Это как норма управляемости в 7 человек в команде - здесь похожие механизмы работают

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

Решение
Настроить обмен информации для конкретного проекта. Встречи для обмена информацией. Можно делать документы, которые будут понятны каждой стороне. Организацией и выбором формата часто проще заняться менеджеру. Инженеру следует объяснить устройство систем с картинками, рисунками, текстом, без кода. Есть большое число разных вариантов: C4, UML, Event Storming, блок-схемы, - взять карандаш и бумагу и нарисовать что-нибудь

Важно не забывать и поддерживать эту активность. Зачастую в Scrum она называется груминг или pbr

? Выводы
- Кто-то должен отвечать за инструмент передачи сообщений. Рост создаёт эту зону ответственности
- Домены и структура в компании нужны для управления сложностью
- Инженер не знает доменов кроме своего и соседей
- Менеджер знает топологию компании без способа организацию связей

Пост про product-market-fit

Часть 2
Saga без специального сервиса (Хореографическая)
Цель. Минимизировать ситуации зависимых фичей за счёт РАЗДЕЛЕНИЯ зон ответственности
Способ. Чётко разделить зоны ответственности без возможности в явном виде наблюдать за всем процессом целиком
Особенности. В ряде случаев может быть неконсистеность, на которую менеджеры идут осознно: не нужна там консистентность. Например, в случае последовательности сборки и доставки (одно после другого)
Шаги. Каждый сервис самостоятельно отвечает за свою часть работы — будь то сборка или доставка. Координация не нужна. После завершения задачи сервис отправляет уведомление другим системам, что может вызвать обновление состояния на их стороне. Это позволяет сервисам работать независимо, без необходимости ждать подтверждения от центрального узла. Преимущество такой модели — высокая скорость разработки и меньшая зависимость между командами. Однако это также может привести к проблемам с последовательностью операций, если информация между сервисами распространяется в непредсказуемом порядке. Важно предусмотреть механизмы, которые помогут управлять этими ситуациями и обеспечивать корректное взаимодействие между частями системы.

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

1. Менеджеру следует организовать встречи для синхронизации терминологии. Шаги:
   - Организовать регулярные встречи, на которых разработчики будут объяснять менеджерам технические термины и процессы простым языком
   - Совместно создать глоссарий терминов, который будет использоваться всеми участниками команды для обеспечения единого понимания
2. Разработчикам следует описывать функциональность сервисов с точки зрения бизнес-ценности. Шаги:
   - Разработать документацию, которая описывает каждый сервис, его функции и как он способствует достижению бизнес-целей
   - Проводить презентации для менеджеров, объясняя, как новые функции интегрируются в общую архитектуру системы и как они решают бизнес-проблемы
3. Определить и закрепить зоны ответственности за конкретные сервисы. Шаги:
   - Создать схемы процессов для визуализации, включая точки передачи данных и ответственности
   - Заключить договоренности о "контрактах" на границах зон ответственности, четко описывающие входы и выходы каждого сервиса

? Выводы
- Нагрузка на команды, нагрузка на сервисы и число коммуникаций - линейно зависимые показатели
- Про product-market-fit. Техническая метрика "качество" связана с "retention" пользователей. А "скорость поставки ценности" - с "числом пользователей". Для циклов product-market-fit внедрение оркестрации можно частично ассоциировать с этапом удержания пользователей, а хореографию - с ростом

Часть 1

Сага о синхронизации данных и product-market-fit

? О чём говорим?

Взгляд разработчика и менеджера на вопросы согласованности данных и перформанса

? Что видит менеджер

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

Последний инцидент был страшен: один из клиентов получил сразу 5 доставок по 100 пачек колы и его склад не смог их принять, хотя должен был получить только 3 доставки по 1 пачке

Чем обычно занимается менеджер
- Планирование фичей и координация команд
- Приоритизация фичей
- Управление ожиданиями стейкхолдеров и требованиями
- Прогресс выполнения задач

?‍? Что видит инженер

Половина данных о сборке товаров находится в одном сервисе, другая - в другом. Каждая новая фича приводит к исправлениям в 3-4 сервисах, которые ясной независимой бизнес-ценности не несут. Число встреч между разработчиками и командами растёт. Даже запланирован оффсайт с отличным банкетом

Один из сбоев привёл к отсутствию согласованности между различными сервисами, ответственными за доставку и сборку. Каждый сервис действовал независимо, что привело к дублированию.

Чем обычно занимается инженер
- Написание кода и встраивание его в существующие системы
- Исправление текущих проблем
- Обсуждение технических деталей с коллегами из разных команд
- Верификация системы с требованиями

? Где непонимание менеджера и инженера

Менеджер видит:
- Сборка
- Доставка

Разработчик видит (см. картинку):
- Доставка из сервиса 1
- Доставка из сервиса 2
- Доставка из сервиса 3
- Сборка из сервиса 2
- Сборка из сервиса 3
- Сборка из сервиса 4

Менеджер не до конца представляет деление системы на части и всю терминологию каждого сервиса. Есть 2 известных понятия для менеджера: сборка и доставка. Но совершенно не понимает, как сборка может быть в 2х состояниях одновременно

Разработчик осведомлён о всех 4х сервисах и опускает часть названий: "из сервиса n". Для разработчика есть целых 6 сущностей и их названий и у него вскипает голова от их объёма информации и отслеживания: где и что сломалось

? Как договариваться

Варианты решения проблем

Saga со специальным модулем управления (Оркестрация)
Цель. Исключить ситуации с различными данными, сфокусироваться на качестве за счёт более тесной СВЯЗИ зон ответственности
Способ. Создать сервис для наблюдения за процессом работы (заказ), а не только его частями (сборка и доставка)
Особенности. Зависимости (заказ и сборка, заказ и доставка) и повышенная нагрузка на отдельные команды (заказ) и сервис
Шаги. Сервис заказов позволит наблюдать менеджерам за всем процессом и синхронизировать 2 других сервиса (доставка и сборка). Сервис заказов содержит информацию о сборке и доставке. Он всегда знает, кто в какой стадии находится и без его ведома ничего сделать невозможно. Таким образом, можно сказать, доставка и сборка зависят и отдают часть своей информации сервису заказов. За сервис заказов должна отвечать какая-то из команд

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

Очень круто, когда партнёры по бизнесу становятся друзьями ?

Один из самых моих любимых бизнесов - @flesspro. Очень крутое время было! Мы сделали отличную работу ?

Удивительная история, как тесен мир ?. Много лет назад, когда мне было 15 лет, я учится в ЛКШ (@sisdaily), занимался олимпиадками и некоторые наши преподаватели говорили: когда вы начнёте работать, обнаружите среди своих коллег и партнёров людей, с которыми учились

Так и вышло. Оказалось, что мы с Витей Рогуленко когда-то были в ЛКШ. А теперь катаемся на лыжах и иногда созваниваемся, даже не смотря на то, что жизнь нас раскидала по миру на расстояние в 10 000 км

Помню как последний раз виделись вживую в Стамбуле, пили чай ☕️, а потом гуляли

https://t.me/want_to_it

? Чем пахнет код? Длинные функции в глазах менеджера и разработчика ?

? О чём говорим?

Взгляд разработчика и менеджера на длину функции в коде. Вопрос очень простой и бытовой: рефакторинг

? Что видит менеджер

Разработчик говорит: "надо порефачить - это на день". После диалога выясняется, что есть большая функция на 400 строк и размер растёт. В глазах менеджера это непонятно: на что влияет длина функции, кроме длины функции. Менеджеру непонятны причины проблемы - есть риск блокировки проектов, что серьёзно

?‍? Что видит разработчик

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

Теперь задача анализа вложенных условий. Большие части придётся переписать, чтобы осознать зависимости. Поэтому при работе с этой частью проекта, разработчик очень сильно выматывается и демотивируется из-за когнитивной нагрузки

? Что будет делать разработчик

Любой программист избавит себя от проблем, выше:
- Перегруппирует код
- Вынесет части кода в отдельные функции
- Уберёт сложные условия и циклы

? Где непонимание

Менеджер не понимает процедуры рефакторинга и эмоционального ощущения разработчика из-за незнания процесса написания кода

Разработчик не описывает проблему и её влияние на бизнес-результаты. Анализ способ написания кода, нажимания на клавиши и степень влияния на бизнес-показатели - та ещё задача

? Как договариваться

Менеджеру нужно поросить разрабочика рассказать и даже показать, как он пишет код, чтобы увидеть трудности воочию

Со стороны разработчика важно рассказать о способе влияния на сроки и привязаться к бизнес-показателям:
- Длинные функции анализировать и менять дольше, чем короткие
- Очень длинные - экспоненциально дольше

Отсюда легко увидеть связь со сроками на выполнение задачи

? Причины

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

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

Коль канал у меня про IT, поделюсь с Вами нашествием 1000 ботов в мой азиатский чатик

Спас этот парень @GHClone4Bot