Agaltsov Anton | TeamLead-блог

🧭 Теория X и Y Макгрегора: во что руководитель верит о людях Дуглас Макгрегор показал, что каждое управленческое решение вырастает из неосознаваемых допущений руководителя о человеческой природе. Менеджер, считающий людей ленивыми, строит контроль и наказания; считающий способными к самостоятельности — делегирование и вовлечение. Теория X описывает человека, который не любит работу, избегает ответственности и требует принуждения. Теория Y — человека, для которого труд так же естественен, как игра, и который при приверженности целям сам ищет ответственность. Это не два типа людей, а два взгляда, из которых вырастают противоположные системы управления. Ключевой механизм — самоисполняющееся пророчество: жёсткий контроль создаёт поведение «по X», доверие — поведение «по Y». Не люди делают контроль необходимым, а устройство работы делает уклонение от неё естественной реакцией. В ИТ-командах Y-стиль оказывается не идеализмом, а инженерной необходимостью: творческая работа не раскладывается на контролируемые операции, а знание о системе у инженера выше, чем у руководителя. Но у инцидентов и комплаенса — свои законы. 🔗 Подробнее: https://agaltsovav.ru/docs/people-managment/mcgregor-theory-x-and-y/

📋 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/