Agaltsov Anton | TeamLead-блог

📈 Масштабируемость: не «сколько система тянет сейчас», а «что с ней будет завтра» Масштабируемость — это не скорость системы при текущей нагрузке, а её поведение при росте: сохранит ли она время отклика и долю ошибок, когда пользователей и данных станет в десять раз больше. Быстрая система может не масштабироваться, а масштабируемая — быть неторопливой на малой нагрузке. Два пути добавить мощности различаются направлением. Вертикальное масштабирование усиливает один узел: больше ядер, памяти, быстрее диски — просто, но с физическим потолком и нелинейно растущей ценой. Горизонтальное добавляет узлы: почти неограниченный предел роста за commodity-цены, но платой становятся распределённая сложность, балансировка и согласованность данных. ⚠️ Закон Амдала задаёт жёсткую арифметику: если 10–20% работы последовательны, то N узлов не дадут N-кратного ускорения — потолок окажется на уровне 5–10x, и узлы сверх него не окупятся. Измерение узких мест предшествует масштабированию, а не следует за ним. Типичная ошибка — строить шардинг и микросервисы под «миллион пользователей», пока продукт обслуживает тысячи: Stack Overflow и Shopify годами держали миллионы пользователей на нескольких мощных серверах. Заимствовать у FAANG стоит принципы, а не топологии. 🔗 Подробнее: https://agaltsovav.ru/docs/architecture/scalability/

📊 DAU, MAU и Sticky Factor — чем продукт «липче», тем здоровее DAU и MAU считают не сессии и не визиты, а уникальных людей: пользователь, зашедший десять раз за день, в DAU учитывается один раз. Отношение DAU к MAU — Sticky Factor — показывает, насколько плотно «месячная» аудитория пользуется продуктом ежедневно. Ключевая развилка — что считать «активностью»: от слабого «открыл приложение» до строгого «получил ценность» (отправил сообщение, оформил заказ, дослушал трек). От выбора порога число DAU меняется в разы, поэтому корректно сравнивать продукты только при совпадении определений. ⚠️ Растущий DAU при падающем удержании когорт — красный флаг: приток новичков перекрывает распад базы, «дырявое ведро» маскируется под рост. DAU без когортных кривых не интерпретируется. 🔗 Подробнее: https://agaltsovav.ru/docs/product-managment/dau-mau-sticky-factor/

🔺 Пирамида потребностей Маслоу: почему сотрудникам нужно разное Теория Маслоу описывает пять уровней потребностей — от физиологических и безопасности до признания и самоактуализации. Поведением человека управляет самый нижний из ещё не закрытых уровней: пока не решён вопрос стабильности, разговоры о смысле работы не слышны. Сам Маслоу пирамиду не рисовал — ступенчатую диаграмму придумали позже учебники менеджмента. Суть теории не в форме, а в доминанте: у каждого человека сейчас активна своя потребность, и мотивировать «всех одинаково» — значит мотивировать почти никого. На практике это объясняет, почему два одинаковых кандидата выбирают противоположные офферы: одного убеждает стабильный фикс и «белый» пакет, другому важнее стек, задачи и траектория роста. Оба рациональны — они просто с разных этажей иерархии. 🔗 Подробнее: https://agaltsovav.ru/docs/people-managment/maslow-hierarchy-of-needs/

📜 Устав проекта: документ, с которого начинается проект Устав проекта (Project Charter) — короткий документ на 1–3 страницы, который формально авторизует существование проекта и наделяет руководителя проекта полномочиями использовать ресурсы организации. До его подписания любые работы — лишь проработка инициативы, а не проект. В зрелых организациях это правило звучит как «нет устава — нет проекта». Работа без устава не имеет мандата, бюджета и единого ответственного, а руководитель проекта вынужден «занимать» авторитет у функциональных менеджеров в каждой транзакции. Устав фиксирует цели, критерии успеха, границы и ограничения — рамку, внутри которой возможны осмысленные компромиссы. Отдельная его функция — «порог выхода»: критерии успеха дают организации легитимный механизм остановить проект, который перестал достигать своих целей. Типичные ошибки — неизмеримые цели без метрик и сроков, отсутствие подписи спонсора и границы, описанные только через «что входит». Без явных исключений каждая просьба заказчика расширяет содержание, и проект живёт в режиме постоянного scope creep. 🔗 Подробнее: https://agaltsovav.ru/docs/project-managment/project-charter/