Agaltsov Anton | TeamLead-блог

📄 README до кода: зачем писать документацию первой Readme Driven Development — практика, которую сформулировал сооснователь GitHub Том Престон-Вернер: README проекта пишется до кода и выступает самой ранней формой проектирования. Пока замысел не описан словами — что это, зачем и как используется, — реализация не начинается. Менять текст дешевле, чем менять код. README позволяет перепробовать структуру проекта и публичный API без единой строки реализации: ошибки замысла ловятся до того, как проникли в кодовую базу. Записанное решение превращает спор из обмена впечатлениями в предметную работу. С определённым интерфейсом команда строит интеграции параллельно, а документация возникает как побочный продукт, а не «абсолютная тоска» ретроспективного описывания. Не путать с Risk Driven Development — аббревиатура RDD совпадает, но движущая сила там реестр рисков, а здесь — текст как спецификация. 🔗 Подробнее: https://agaltsovav.ru/docs/development-managment/rdd-readme-driven-development/ ENDOFPOST && ssh agaltsovav@100.64.0.4 wc -c /tmp/tg-post.txt

⚡ События вместо вызовов: как работает EDA В событийно-ориентированной архитектуре компоненты не вызывают друг друга напрямую. Издатель публикует факт — «заказ оформлен» — и продолжает работу, не зная, кто и когда его прочитает. Падение одного потребителя не блокирует остальных, а новые подписчики подключаются без изменения издателя. Событие и команда — разные вещи. Событие сообщает, что произошло, и адресовано никому конкретно; команда приказывает, что сделать, и требует получателя. Смешение этих понятий — источник скрытых зависимостей между сервисами. Exactly-once доставка — дорогая иллюзия. На практике выбирают at-least-once и делают обработчики идемпотентными: повторное событие не должно менять результат. ⚠️ Плата за асинхронность — итоговая согласованность и сложная отладка: стек-трейса нет, есть последовательность фактов, которую приходится собирать по correlation id. 🔗 Подробнее: https://agaltsovav.ru/docs/architecture/event-driven-architecture/

🎯 OKR: как стратегия превращается в квартальные цели OKR — это всегда пара: Objective — качественная цель без цифр, отвечающая на вопрос «что хотим изменить», и Key Results — три-пять измеримых результатов, по которым в конце квартала можно однозначно проверить, достигнута ли цель. Смешение уровней — самая частая ошибка внедрения: цель с цифрой внутри превращается в сухой план, а ключевой результат без цифры — в благое пожелание, которое невозможно проверить. Амбициозность встроена в сам метод: для stretch-целей оценка 0.7 из 1.0 считается успехом, а стабильные 1.0 — сигнал, что цели занижены. Поэтому OKR принципиально не привязывают к оценке и зарплате: как только цели становятся зарплатной метрикой, они начинают занижаться, а данные — приукрашиваться. OKR занимает уровень между стратегией и операционным планом: видение задаёт направление на годы, стратегия — ставки на 1–3 года, OKR фиксирует измеримое движение на квартал, а дорожная карта наполняет это движение конкретными инициативами. Стратегия без OKR остаётся декларацией без проверяемого движения. 🔗 Подробнее: https://agaltsovav.ru/docs/product-managment/okr/

🔥 Выгорание: не слабость, а системный сбой ВОЗ определяет выгорание как синдром из трёх компонентов: истощение, цинизм и падение профессиональной эффективности. Причина — хронический рабочий стресс, который не был преодолён. Трудоголик не может остановиться, выгоревший — не может начать. Выгорание развивается месяцами и поражает не «слабых», а самых вовлечённых. Причины лежат в среде, а не в человеке: перегрузка, отсутствие контроля, недостаток вознаграждения, потеря сообщества, несправедливость, конфликт ценностей. Руководителю стоит начать с разговора один на один, снизить нагрузку и дать восстановительный режим. Менять нужно условия, а не человека. 🔗 Подробнее: https://agaltsovav.ru/docs/people-managment/burnout/