Agaltsov Anton | TeamLead-блог

🎯 Оценка 360: увидеть то, чего не видит руководитель Оценка 360 — это сбор обратной связи о сотруднике со всех сторон: от руководителя, подчинённых, коллег, клиентов и в форме самооценки. Ключевая идея: ни один наблюдатель не видит человека целиком, а наложение «секторов обзора» даёт объёмную картину, недоступную одному руководителю. Главный диагностический материал метода — расхождение самооценки и внешнего восприятия. Классика жанра: руководитель уверен, что вовлекает команду в решения, а подчинённые отмечают, что решения сообщаются постфактум. Такие слепые зоны годами незаметны: окружение молчит, а руководителю эти аспекты просто не видны. ⚠️ Сам по себе сбор данных ничего не меняет. Исследования устойчиво показывают: эффект дают только те результаты, которые обсудили и перевели в план развития. Отчёты, «легшие в стол», не улучшают ничего. А связка 360 с деньгами (премиями, повышениями) заметно повышает риск искажений — инструмент работает, только пока воспринимается как безопасный. 🔗 Подробнее: https://agaltsovav.ru/docs/people-managment/360-feedback/

📐 Scope Creep: почему «ещё одну маленькую фичу» нельзя просто добавить Scope — это границы проекта: что входит в результат, а что остаётся за ним. После утверждения базового плана любое расширение требует оценки влияния и решения — «тихо договориться» нельзя. Расползание бывает четырёх видов, и лечатся они по-разному: scope creep — давление извне, gold plating — инициатива самой команды, groping — расхождение в понимании уже согласованного, hope creep — сокрытие отставания. Диагноз определяет лечение. 💡 В Agile содержание меняется по определению — это не патология. «Расползание» там выглядит иначе: команда теряет способность завершать фичи. Защиту обеспечивают границы спринта, приоритизация и Definition of Done. 🔗 Управление содержанием и Scope Creep: https://agaltsovav.ru/docs/project-managment/scope-creep/

🔍 Наблюдаемость: понимать систему, не вскрывая её Наблюдаемость (observability) — свойство системы, по которой о её внутреннем состоянии можно судить по внешним сигналам: логам, метрикам и трассировкам. Термин пришёл из теории управления 1960-х, а сегодня это одна из сквозных забот распределённой архитектуры. Мониторинг и наблюдаемость — не синонимы. Мониторинг отвечает на вопросы, сформулированные до инцидента: диск заполнен, растут ошибки, задержка выше порога. Наблюдаемость позволяет расследовать отказы, которые никто не предвидел, — без релиза с «добавленным логированием» и ожидания повторения сбоя. Три кита — логи, метрики, трассировки — различаются природой данных: агрегаты против событий, дешёвое хранение против дорогого, готовые дашборды против произвольных вопросов. Связывает их единый trace_id, который проходит сквозь все сервисы вместе с запросом. 💡 Наблюдаемость — не продукт, который можно купить, а свойство дизайна: тонна несвязанных данных не отвечает на вопросы лучше скромного, но связанного набора сигналов. 🔗 Подробнее: https://agaltsovav.ru/docs/architecture/observability/