ИТ блог, про Управление разработкой, Управление командой, Управление проектом, Управление продуктом, Саморазвитие, Архитектура - все это ежедновно на канале.
Молодые и опытные TeamLead’ы и руководители тимлидов найдут на канале много полезного.
ИТ блог, про Управление разработкой, Управление командой, Управление проектом, Управление продуктом, Саморазвитие, Архитектура - все это ежедновно на канале.
Молодые и опытные TeamLead’ы и руководители тимлидов найдут на канале много полезного.
📐 Быстро, дёшево, качественно — выберите два
Треугольник проекта (Iron Triangle) связывает три параметра: содержание, сроки и стоимость. Изменить один из них, не затронув остальные, невозможно — это не лозунг, а арифметика: сократить срок вдвое при том же объёме работ означает либо расширить команду и бюджет, либо урезать функциональность.
Все три вершины нельзя зафиксировать одновременно. Поэтому ключевое решение на старте — какие две стороны фиксируются, а какая остаётся гибкой и поглощает отклонения. Если решение не принято осознанно, «гибкой» незаметно становится качество — и счёт придёт позже.
Agile реализует ту же модель: спринт фиксирует время и состав команды, а варьируется содержание. Приоритизация бэклога — это и есть управление гибкой вершиной треугольника.
🔗 Подробнее: https://agaltsovav.ru/docs/project-managment/project-triangle/
ENDOFPOST && ssh agaltsovav@100.64.0.4 wc -c /tmp/tg-post.txt && cat /tmp/tg-post.txt
«Agaltsov Anton | TeamLead-блог» - канал из категории «Блоги», подключенный к сервису кросспостинга MaxGate. Публикации канала синхронизируются между Telegram и мессенджером MAX, а на этой странице собраны ссылки на обе версии канала.
Сейчас у канала 1 004 подписчика суммарно в Telegram и MAX. За последние 26 дней в истории MaxGate учтено 47 публикаций, поэтому перед подпиской можно оценить не только размер аудитории, но и регулярность обновлений.
Чтобы подписаться, используйте кнопки «Открыть в MAX» и «Открыть в Telegram» в верхней части страницы. У отдельных постов ссылка может быть доступна в обоих мессенджерах или только в одном из них, если MaxGate получил такой URL из истории обработки.
🏗️ SOA: недостающее звено между монолитом и микросервисами
Сервис-ориентированная архитектура — стиль 2000-х годов, при котором функциональность предприятия упаковывается в крупные переиспользуемые сервисы с формальными контрактами. Сервис проектируется не под одно приложение, а как актив всей компании: его вызывают портал, ERP и расчётные задания на мэйнфрейме.
Сердце классической SOA — единая шина ESB, берущая на себя маршрутизацию, трансформацию сообщений и оркестрацию. Контракты описываются тяжёлым XML-стеком: SOAP, WSDL и спецификации WS-*.
⚠️ ESB же стал главной проблемой подхода: «умная шина» концентрирует логику, превращается в единую точку отказа и узкое место. Согласование контрактов и очередь на изменения шины удлиняли релизные циклы — скорость поставки приносилась в жертву переиспользованию.
Микросервисы взяли из SOA идею сервисов и контрактов, но убрали шину и централизацию: мелкая гранулярность, независимый деплой, автономные команды.
При этом SOA жива: корпоративная интеграция, банки и телеком по-прежнему работают на SOAP-сервисах, а service mesh наследует идеи ESB.
🔗 Сервис-ориентированная архитектура (SOA): https://agaltsovav.ru/docs/architecture/soa/
📊 AARRR: пять ступеней воронки роста продукта
AARRR, или «пиратские метрики», описывает путь пользователя через пять этапов: Acquisition — привлечение, Activation — активация, Retention — удержание, Referral — рекомендации, Revenue — выручка. Вместе ступени образуют воронку: от всех, кто услышал о продукте, до тех, кто приносит деньги и приводит других.
Главная ценность фреймворка — не в самих пяти буквах, а в диагностике: он показывает, на каком этапе продукт теряет пользователей. Классическая ошибка — лить больше трафика при сломанной активации: дорогие посетители приходят и уходят, не получив ценности. Воронка сначала чинится в середине и внизу, и только потом масштабируется сверху.
Для зрелых продуктов порядок этапов пересматривается в RARRA: удержание ставится во главу угла, а привлечение масштабируется последним.
⚠️ Без инструментирования каждого этапа фреймворк бесполезен: сначала измерение всех пяти ступеней, затем поиск узкого горлышка и приоритизация усилий.
🔗 Подробнее: https://agaltsovav.ru/docs/product-managment/aarrr-pirate-metrics/
🤝 Контракты вместо общих стендов: как работает Contract Driven Development
В распределённых системах самый дорогой класс дефектов — интеграционные: каждый сервис по отдельности работает, а вместе — нет. Классическое решение — сквозные тесты на общем стенде — с ростом числа команд превращается в узкое место: медленно, хрупко и требует одновременной работоспособности всех участников.
Contract Driven Development меняет модель: потребитель сервиса сам описывает свои ожидания от чужого API в виде исполняемого контракта. Это не документ, а тест, который провайдер запускает в своём CI при каждом коммите. Ключевой принцип сформулировал ещё в 2006 году Ян Робинсон: контракт принадлежит потребителю, а не провайдеру.
Результат — команды деплоятся независимо, без релизных поездов и координационных встреч, а интеграционные поломки обнаруживаются на коммите, а не в проде. Плата за это — инфраструктура для хранения и верификации контрактов плюс зрелая культура: красный контракт чужого потребителя должен быть приоритетом для команды-провайдера.
🔗 CDD — Contract Driven Development: https://agaltsovav.ru/docs/development-managment/cdd-contract-driven-development/
