ИТ блог, про Управление разработкой, Управление командой, Управление проектом, Управление продуктом, Саморазвитие, Архитектура - все это ежедновно на канале.
Молодые и опытные TeamLead’ы и руководители тимлидов найдут на канале много полезного.
ИТ блог, про Управление разработкой, Управление командой, Управление проектом, Управление продуктом, Саморазвитие, Архитектура - все это ежедновно на канале.
Молодые и опытные TeamLead’ы и руководители тимлидов найдут на канале много полезного.
🏗️ Twelve-Factor App: двенадцать правил облачного приложения
Twelve-Factor App — методология Адама Уиггинса и команды Heroku (2011), выросшая из эксплуатации сотен тысяч приложений. Философия проста: приложение — самодостаточный сервис, которым платформа управляет без человека. Контейнеры и Kubernetes затем сделали эти свойства отраслевой нормой.
Каждый фактор снимает конкретный класс проблем. Конфигурация — в переменных окружения, а не в коде: пароль в репозитории и ветвление по имени сервера — прямые нарушения. Процессы stateless: сессии в памяти процесса вынуждают sticky sessions и блокируют горизонтальное масштабирование.
Стадии build, release и run строго разделены: правки руками на работающем сервере ломают воспроизводимость деплоя. Логи — потоки событий в stdout/stderr, а не файлы, которые приложение ротирует само: сбор и маршрутизацию делает платформа.
💡 Методология не касается декомпозиции системы — каждый микросервис и корректный монолит могут быть twelve-factor-приложениями. Спустя 15 лет её цитируют не потому, что тезисы спорны, а потому, что нарушения встречаются до сих пор.
🔗 https://agaltsovav.ru/docs/architecture/twelve-factor-app/
«Agaltsov Anton | TeamLead-блог» - канал из категории «Блоги», подключенный к сервису кросспостинга MaxGate. Публикации канала синхронизируются между Telegram и мессенджером MAX, а на этой странице собраны ссылки на обе версии канала.
Сейчас у канала 997 подписчиков суммарно в Telegram и MAX. За последние 30 дней в истории MaxGate учтено 42 публикаций, поэтому перед подпиской можно оценить не только размер аудитории, но и регулярность обновлений.
Чтобы подписаться, используйте кнопки «Открыть в MAX» и «Открыть в Telegram» в верхней части страницы. У отдельных постов ссылка может быть доступна в обоих мессенджерах или только в одном из них, если MaxGate получил такой URL из истории обработки.
📊 NPS и CSAT: чем лояльность отличается от удовлетворённости
NPS измеряет долгосрочные отношения: один вопрос — «порекомендуете ли продукт другу или коллеге?» по шкале 0–10. Ответы делятся на промоутеров (9–10), пассивных (7–8) и критиков (0–6), а итоговый балл — это разница долей первых и последних.
CSAT — про конкретный опыт: «Насколько вы удовлетворены покупкой, обращением в поддержку, релизом?» Рост CSAT после релиза не означает рост лояльности — метрики измеряют разное, и их смешение остаётся самой частой ошибкой внедрения.
Главный вопрос после полученного балла — «почему именно такой?». NPS без открытого вопроса и замкнутого цикла обратной связи остаётся просто числом, а метрика превращается в цель для манипуляций.
Тренд важнее абсолютного значения: сравнивать NPS следует с собственным прошлым результатом, а не с Apple.
🔗 Подробнее: https://agaltsovav.ru/docs/product-managment/nps-and-csat/
🔥 Паника, страх и дедлайны: чем управлять разработка не должна
У любого процесса есть движущая сила. В здоровых подходах это артефакт — тест, домен, реестр рисков, гипотеза. Но фольклор давно присвоил суффикс «-Driven Development» режимам, где процессом движет эмоция или давление: паника, страх, срок, крик самого громкого участника.
Panic DD — «пожарный режим»: инцидент обнуляет план, спешный хотфикс без анализа причин рождает новые дефекты, и цикл замыкается. Классический маркер — культура героев: спасателей награждают, предотвращённые аварии остаются невидимыми. ⚠️
Fear DD парализует инициативу: ошибки скрываются до последнего, решения требуют подписи начальства, а знания не делятся — «незаменимого не увольняем». Прямая дорога к потере психологической безопасности, которую Google в Project Aristotle назвал фактором номер один эффективности команд.
Общий корень у всех таких режимов один: процессом управляет давление вместо артефакта. Тест может ответить, почему принято решение, — страх нет.
🔗 Driven-подходы: антипаттерны: https://agaltsovav.ru/docs/development-managment/driven-development-anti-patterns/
🧩 DRY, KISS и YAGNI — три принципа против избыточной сложности
DRY требует не «убрать одинаковые строки», а хранить каждое знание о системе ровно в одном месте: бизнес-правило, формат данных, алгоритм. Цена нарушения — не эстетика, а рассинхронизация: копии правят неравномерно, и валидация в одном модуле начинает противоречить той же валидации в другом.
YAGNI запрещает писать код «на будущее». Каждая абстракция, созданная под гипотетическую потребность, — это поддержка, тесты и документация без ценности, плюс риск: предсказать, как именно изменится система, почти никогда не удаётся.
Балансирует пару Rule of Three: первый повтор — случайность, второй — совпадение, и только третий намекает на закономерность. А слепое следование принципам порождает wrong-DRY: Сэнди Мец предупреждала — дублирование значительно дешевле неправильной абстракции.
🔗 Подробнее: https://agaltsovav.ru/docs/architecture/dry-kiss-yagni/
