ИТ блог, про Управление разработкой, Управление командой, Управление проектом, Управление продуктом, Саморазвитие, Архитектура - все это ежедновно на канале.
Молодые и опытные TeamLead’ы и руководители тимлидов найдут на канале много полезного.
ИТ блог, про Управление разработкой, Управление командой, Управление проектом, Управление продуктом, Саморазвитие, Архитектура - все это ежедновно на канале.
Молодые и опытные TeamLead’ы и руководители тимлидов найдут на канале много полезного.
👥 Матричная структура — когда один человек подчиняется двум руководителям постоянно
Матричная модель отличается от проектной команды тем, что двойное подчинение здесь — не временное явление под проект, а постоянный способ организации. Сотрудник числится в функциональном отделе (например, бекенд-разработки), где отвечает за карьеру и стандарты работы. Одновременно он приписан к проектной ячейке, и руководитель проекта определяет, какие задачи он делает прямо сейчас.
В управленческой литературе это описывается двумя линиями. Solid line — основное подчинение, обычно функциональному руководителю: найм, оценка, повышение, отпуск. Dotted line — проектное подчинение: содержание работы и приоритеты, но не кадровые вопросы.
⚠️ Главная сложность матрицы — рассогласование ответственности и полномочий. Проектный руководитель отвечает за результат перед бизнесом, но не контролирует людей административно. Функциональный руководитель контролирует кадры, но не отвечает за проект. Это требует зрелой культуры разрешения конфликтов и прозрачного ресурсного планирования.
Матрица хорошо работает в многопроектных организациях с дефицитом узких специалистов, в энтерпрайзе и аутсорсинге. Плохо — в молодых продуктах с быстрым циклом релизов и в командах до 20–30 человек, где накладные расходы превышают пользу.
🔗 https://agaltsovav.ru/docs/team-managment/types/matrix-structure/
«Agaltsov Anton | TeamLead-блог» - канал из категории «Блоги», подключенный к сервису кросспостинга MaxGate. Публикации канала синхронизируются между Telegram и мессенджером MAX, а на этой странице собраны ссылки на обе версии канала.
Сейчас у канала 1 012 подписчиков суммарно в Telegram и MAX. За последние 11 дней в истории MaxGate учтено 22 публикаций, поэтому перед подпиской можно оценить не только размер аудитории, но и регулярность обновлений.
Чтобы подписаться, используйте кнопки «Открыть в MAX» и «Открыть в Telegram» в верхней части страницы. У отдельных постов ссылка может быть доступна в обоих мессенджерах или только в одном из них, если MaxGate получил такой URL из истории обработки.
02.0805.0808.0811.0813.08
Число постов
2
1
0
06.0807.0808.0809.0810.0811.0812.08
🏗️ Монолит — не устаревшая архитектура, а отправная точка
Монолитная архитектура — это система как единое приложение: все модули работают в одном процессе, делят общую базу данных и деплоятся одним артефактом. Компоненты обращаются друг к другу обычными вызовами методов, а границы между ними существуют лишь на уровне исходного кода и соглашений.
Слово «монолит» возникло как контрастный термин — потребовалось дать имя тому, что микросервисы противопоставляют себе. Отсюда ошибочное восприятие монолита как «плохой» или «устаревшей» архитектуры. На деле это базовый стиль, с которого начинается подавляющее большинство систем.
Виды монолита различаются строгостью внутренних границ. Единый монолит — спагетти-код без чётких разделений. Модульный монолит — структура с продуманными границами модулей, которые позже могут превратиться в сервисные. Распределённый монолит — антипаттерн: несколько сервисов, жёстко связанных и деплоящихся только вместе.
💡 Рекомендация Мартина Фаулера: начинать почти всегда с монолита, а к микросервисам переходить, когда организационная боль от монолита станет осязаемой. Монолит и микросервисы — не соперники, а этапы одного пути.
🔗 https://agaltsovav.ru/docs/architecture/monolith/
🎯 Проектная команда: временная сила под конкретную цель
Проектная команда (task force) — это кросс-функциональная группа, которая собирается под конкретный результат: запустить продукт, провести миграцию, потушить кризис. После достижения цели команда распускается, а участники возвращаются в свои постоянные отделы.
Ключевое отличие от матричной структуры — одинарное подчинение. На время проекта участник подчиняется только руководителю проекта. Функциональный отдел выступает «источником кадров», а не второй линией управления — двойного подчинения нет.
Модель работает лучше всего для разовых задач с чёткой целью и сроком: запуск MVP с нуля, переезд инфраструктуры, кризисные доработки. Но для непрерывной продуктовой разработки она не подходит — проектная команда сдаёт результат и уходит, а продукт требует постоянного владения.
Оптимальный размер — 5–12 человек. Больше — уже не единая команда, а набор подкоманд с координационным ядром.
🔗 https://agaltsovav.ru/docs/team-managment/types/project-team/
📦 Roadmap — это не проектный план, а коммуникационный инструмент
Дорожная карта продукта отвечает на вопрос «что и в каком порядке мы делаем», оставаясь выше уровнем, чем backlog. Это связующее звено между стратегией и повседневной работой команды: какие направления получают приоритет, в какой очерёдности и ради какой ценности.
Современная best practice — outcome-based roadmap в формате Now / Next / Later. В Now указываются конкретные темы с временными рамками. В Next — направления на ближайшие месяцы. В Later — только стратегические ориентиры без дат. Даты появляются лишь тогда, когда инициатива переходит в зону Now.
⚠️ Главная ошибка — позволить roadmap стать проектным планом с жёсткими датами для каждой фичи. Это превращает дорожную карту в обещание, которое невозможно выполнить в условиях неопределённости, и разрушает доверие стейкхолдеров.
Roadmap — живой документ, который пересматривается ежеквартально. Его цель — синхронизация ожиданий, а не отслеживание задач.
🔗 https://agaltsovav.ru/docs/product-managment/roadmap/
