ИТ блог, про Управление разработкой, Управление командой, Управление проектом, Управление продуктом, Саморазвитие, Архитектура - все это ежедновно на канале.
Молодые и опытные TeamLead’ы и руководители тимлидов найдут на канале много полезного.
ИТ блог, про Управление разработкой, Управление командой, Управление проектом, Управление продуктом, Саморазвитие, Архитектура - все это ежедновно на канале.
Молодые и опытные TeamLead’ы и руководители тимлидов найдут на канале много полезного.
📊 DAU, MAU и Sticky Factor — чем продукт «липче», тем здоровее
DAU и MAU считают не сессии и не визиты, а уникальных людей: пользователь, зашедший десять раз за день, в DAU учитывается один раз. Отношение DAU к MAU — Sticky Factor — показывает, насколько плотно «месячная» аудитория пользуется продуктом ежедневно.
Ключевая развилка — что считать «активностью»: от слабого «открыл приложение» до строгого «получил ценность» (отправил сообщение, оформил заказ, дослушал трек). От выбора порога число DAU меняется в разы, поэтому корректно сравнивать продукты только при совпадении определений.
⚠️ Растущий DAU при падающем удержании когорт — красный флаг: приток новичков перекрывает распад базы, «дырявое ведро» маскируется под рост. DAU без когортных кривых не интерпретируется.
🔗 Подробнее: https://agaltsovav.ru/docs/product-managment/dau-mau-sticky-factor/
«Agaltsov Anton | TeamLead-блог» - канал из категории «Блоги», подключенный к сервису кросспостинга MaxGate. Публикации канала синхронизируются между Telegram и мессенджером MAX, а на этой странице собраны ссылки на обе версии канала.
Сейчас у канала 994 подписчика суммарно в Telegram и MAX. За последние 30 дней в истории MaxGate учтено 36 публикаций, поэтому перед подпиской можно оценить не только размер аудитории, но и регулярность обновлений.
Чтобы подписаться, используйте кнопки «Открыть в MAX» и «Открыть в Telegram» в верхней части страницы. У отдельных постов ссылка может быть доступна в обоих мессенджерах или только в одном из них, если MaxGate получил такой URL из истории обработки.
🔺 Пирамида потребностей Маслоу: почему сотрудникам нужно разное
Теория Маслоу описывает пять уровней потребностей — от физиологических и безопасности до признания и самоактуализации. Поведением человека управляет самый нижний из ещё не закрытых уровней: пока не решён вопрос стабильности, разговоры о смысле работы не слышны.
Сам Маслоу пирамиду не рисовал — ступенчатую диаграмму придумали позже учебники менеджмента. Суть теории не в форме, а в доминанте: у каждого человека сейчас активна своя потребность, и мотивировать «всех одинаково» — значит мотивировать почти никого.
На практике это объясняет, почему два одинаковых кандидата выбирают противоположные офферы: одного убеждает стабильный фикс и «белый» пакет, другому важнее стек, задачи и траектория роста. Оба рациональны — они просто с разных этажей иерархии.
🔗 Подробнее: https://agaltsovav.ru/docs/people-managment/maslow-hierarchy-of-needs/
📜 Устав проекта: документ, с которого начинается проект
Устав проекта (Project Charter) — короткий документ на 1–3 страницы, который формально авторизует существование проекта и наделяет руководителя проекта полномочиями использовать ресурсы организации. До его подписания любые работы — лишь проработка инициативы, а не проект.
В зрелых организациях это правило звучит как «нет устава — нет проекта». Работа без устава не имеет мандата, бюджета и единого ответственного, а руководитель проекта вынужден «занимать» авторитет у функциональных менеджеров в каждой транзакции.
Устав фиксирует цели, критерии успеха, границы и ограничения — рамку, внутри которой возможны осмысленные компромиссы. Отдельная его функция — «порог выхода»: критерии успеха дают организации легитимный механизм остановить проект, который перестал достигать своих целей.
Типичные ошибки — неизмеримые цели без метрик и сроков, отсутствие подписи спонсора и границы, описанные только через «что входит». Без явных исключений каждая просьба заказчика расширяет содержание, и проект живёт в режиме постоянного scope creep.
🔗 Подробнее: https://agaltsovav.ru/docs/project-managment/project-charter/
🏗️ 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/
