Агальцов Антон | TeamLead-блог

🔌 REST, RPC или GraphQL — как выбрать стиль API?

REST описывает мир как набор ресурсов с адресами: клиент выбирает HTTP-метод, сервер возвращает представление. RPC — как набор операций: клиент вызывает процедуру с аргументами. GraphQL — как граф типизированных данных: клиент сам перечисляет нужные поля, и сервер собирает ответ в этой форме.

Практический выбор сводится к характеру доминирующих операций. CRUD над сущностями — родная стихия REST, действия-команды — RPC и gRPC со стримингом, сложные выборки для разнородных клиентов — GraphQL, который убирает overfetching и лишние эндпоинты под каждый экран.

💡 Зрелые системы редко живут на одном стиле: типичная схема — REST на периметре, gRPC внутри и GraphQL в BFF для мобильных клиентов. Вопрос не «какой стиль лучше», а где какая граница и кто её потребитель.

🔗 Подробнее: https://agaltsovav.ru/docs/architecture/api-styles/

🧪 Как проверить гипотезу честно: A/B-тестирование

Каждое изменение в продукте — гипотеза. A/B-тест превращает спор о вкусах в измерение: контрольная группа остаётся на текущей версии, экспериментальная получает изменённую, а решение принимается по статистически достоверной разнице метрик, а не по убеждениям самого громкого в команде.

Главная ценность — отделение причинно-следственной связи от корреляции. Сравнение «до и после» не отличает эффект изменения от сезонности и смены трафика, а параллельная контрольная группа показывает чистый эффект.

Правила надёжного теста: гипотеза и метрика решения фиксируются до запуска, размер выборки считается заранее, а подглядывать в промежуточные результаты нельзя — самая частая ошибка, ведущая к ложным выводам.

🔗 A/B-тестирование и эксперименты: https://agaltsovav.ru/docs/product-managment/ab-testing-experiments/

🎯 PIP: шанс на исправление или подготовка к увольнению?

PIP (Performance Improvement Plan) — формальный план улучшения результатов: работодатель фиксирует проблемы, ставит измеримые цели и даёт срок 30–90 дней. Инструмент включается, когда обычная обратная связь уже исчерпана, а проблемы подтверждены фактами, а не впечатлениями.

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

⚠️ Главный водораздел — честность. Честный PIP содержит реалистичные цели, поддержку и регулярные контрольные точки. Формальный — заранее провальные задачи без помощи: это soft firing, инструмент давления, а не управления.

🔗 Подробнее: https://agaltsovav.ru/docs/people-managment/pip/

✅ Когда задача считается сделанной: Definition of Done и Definition of Ready

Спор «мы закончили — нет, не закончили» — это не конфликт людей, а отсутствие контракта. Definition of Done (DoD) делает скрытые критерии завершённости явными и общими: пока «сделано» не определено явно, разработчик, тестировщик и Product Owner вкладывают в слово каждый своё.

DoR работает на входе в спринт и фильтрует «сырые» задачи — непонятные, неоценённые, с невыясненными зависимостями. Такая задача не ускоряет доставку, а конвертирует рабочую ёмкость спринта в бесконечное уточнение требований.

DoD — не список критериев приёмки конкретной истории, а общий контракт команды на всю работу. Инкремент, не прошедший DoD, нельзя предъявлять на Sprint Review: именно строгость DoD делает каждый инкремент пригодным к поставке, а velocity — честной метрикой.

Контракт работает, только когда команда выработала его сама. Навязанный сверху DoD обходится так же, как отсутствующий, а чужой чек-лист неприменим — он кодирует дисциплину конкретной команды, её стек и инфраструктуру.

🔗 Подробнее: https://agaltsovav.ru/docs/project-managment/dod-dor/

🧩 Принципы модульности: как делить систему на части

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

Дисциплина декомпозиции отвечает на три вопроса. Как делить — Separation of Concerns Дейкстры: непересекающиеся области ответственности. Сколько знать о соседях — Law of Demeter: «не разговаривай с незнакомцами», вызывай только ближайших партнёров. Чем измерять результат — связность и связанность по Константайну: высокая cohesion внутри модуля, слабый coupling между ними.

⚠️ Главная ловушка — ложная модульность через общее состояние: модули формально разделены в коде, но связаны одной базой данных или глобальным конфигом. Детектор простой: если модуль нельзя изменить или удалить без согласования с другими — границы не работают.

🔗 Принципы модульности (SoC, Law of Demeter): https://agaltsovav.ru/docs/architecture/modularity-principles/

🎯 Value Proposition Canvas: когда продукт отвечает клиенту, а не себе

Канва из шести блоков: карта ценности (продукты, обезболивающие, создатели выгод) прикладывается к профилю клиента (задачи, боли, выгоды). Ценность возникает не внутри половин, а в соответствии между ними — его и проектирует инструмент.

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

Соответствие проверяется на трёх уровнях: problem-solution fit на бумаге, product-market fit на рынке, business model fit в экономике. Главный риск — «заполнить клетки» в кабинете, без единого разговора с клиентом.

Формулировки болей и выгод пишутся словами клиента и почти без перевода переносятся в лендинги, демо и презентации.

🔗 Value Proposition Canvas: https://agaltsovav.ru/docs/product-managment/value-proposition-canvas/