Agaltsov Anton | TeamLead-блог

📋 RACI: кто делает, кто отвечает, кого спрашивают RACI — таблица, где по строкам задачи проекта, по столбцам роли, а в клетках буква типа участия: R (исполнитель), A (ответственный за результат), C (консультируемый) и I (информируемый). Инструмент из PMBOK, решающий вечную проблему проектов — неопределённость ответственности. Главное правило матрицы: у каждой задачи ровно один Accountable. Ноль A — «дыра», задача ничья, и отвечающим оказывается тот, кто забыл её назначить. Два и больше A — конфликт полномочий: решение не принято, пока «утверждающие» спорят. RACI распределяет роли, а не людей: человек играет несколько ролей, при ротации буква переходит вместе с ролью. Поэтому столбцы — «Tech Lead», «QA», «Бизнес-аналитик», а не фамилии. Матрицу проверяют на sanity: минимум один R на задачу, роли «только I» из матрицы убираются, перегруз Accountable (порядка 5–9 зон на человека) лечится делегированием. Частая путаница R и A разрешается вопросом «чьё слово последнее при приёмке?» — это и есть A. 🔗 Подробнее: https://agaltsovav.ru/docs/project-managment/raci-matrix/

🏗️ Гексагон и луковица: зачем разворачивать зависимости Гексагональная архитектура (Ports & Adapters) и Onion — два названия одной идеи: бизнес-логика образует ядро, изолированное от внешнего мира, а UI, базы данных, очереди и сторонние сервисы подключаются снаружи через порты и адаптеры. Механика у обоих одна — инверсия зависимостей, поднятая с уровня классов до уровня всего приложения. Зачем это нужно: ядро тестируется без базы данных и HTTP — на место адаптеров подставляются заглушки, и тесты за доли секунды проверяют именно бизнес-правила. Смена базы, протокола или UI-фреймворка перестаёт быть событием для домена. 💡 Паттерны появились как ответ на дефект классической слоистой схемы, где домен зависит от слоя доступа к данным, и в бизнес-логику просачиваются схема БД, SQL и детали ORM. Clean Architecture — прямой синтез обоих подходов. Когда оправдано: сложная доменная логика (биллинг, страхование, логистика), много доставок и интеграций, долгоживущий продукт. Для простых CRUD честный controller → service → repository дешевле. 🔗 Hexagonal (Ports & Adapters) и Onion: https://agaltsovav.ru/docs/architecture/hexagonal-onion/

📊 Воронки и конверсии: где продукт теряет пользователей Воронка раскладывает путь пользователя на измеримые шаги и показывает, сколько людей доходит до каждого. Главная задача — не следить за всеми конверсиями сразу, а найти узкое горлышко: шаг, на котором теряется больше всего людей. Арифметика здесь решает: сквозная конверсия равна произведению шаговых, поэтому улучшения накапливаются мультипликативно — рост каждой из четырёх конверсий на 10% даёт не +10%, а +46% к итогу. При этом усилия стоят вкладывать именно в слабое звено: у сильных шагов просто нет запаса для роста. Проценты часто скрывают масштаб потерь: шаг с «здоровой» конверсией 50% может терять больше людей в абсолютных числалах, чем финальный шаг оплаты. Приоритет определяется произведением низкой конверсии на большие абсолютные потери. Воронка отвечает на вопрос «где», но не «почему»: причина отвала выясняется интервью, записями сессий и тепловыми картами, а решение проверяется экспериментом. 🔗 Подробнее: https://agaltsovav.ru/docs/product-managment/funnels-and-conversions/