Агальцов Антон | TeamLead-блог

🧠 Цена ИИ-кода — не только технический долг

Генеративные модели ускорили написание кода, но параллельно копятся два менее заметных вида задолженности. Когнитивный дол — эрозия разделяемого понимания: код сгенерирован, но никто в команде по-настоящему не прочитал и не осмыслил его. Долг намерений — утрата зафиксированного «зачем»: ИИ не оставляет обоснований и компромиссов, которые обычно фиксировались в ADR и обсуждениях.

Модель тройного долга (Triple Debt Model) Маргарет-Энн Стори связывает три слоя: технический долг живёт в коде, когнитивный — в людях, долг намерений — во внешних артефактах. Опаснее всего, что они усиливают друг друга: без записей о намерениях понимание не из чего восстанавливать, а потерянное понимание ускоряет деградацию кода. ⚠️ О потерянном понимании команда узнаёт, когда его уже нет.

Практики погашения существуют и проверены: ADR и фиксация решений в момент их принятия, ревью кода как акт осмысления, системные обходы и ретроспективы. Понимание — полноценный результат разработки, который надо планировать и бюджетировать наравне с качеством кода.

🔗 Подробнее: https://agaltsovav.ru/blog/cognitive-intent-debt/

🚀 Go-to-Market: как выводить продукт на рынок

Go-to-Market — это не запуск, а стратегия: система согласованных решений о том, кому продаётся продукт, что ему предлагается, где происходит продажа и как она монетизируется. Команда, у которой есть дата релиза, но нет ответов на эти четыре вопроса, не имеет GTM — у неё есть только релиз.

Сила стратегии — в согласованности решений. Enterprise-цена не выживет в канале самообслуживания, сложный продукт не удержится в «безлюдном» онбординге, а размытый «продукт для всех» делает сообщение безадресным. Цена, канал и модель продаж обязаны работать в связке.

Самая дорогая ошибка — масштабироваться до подтверждённого Product-Market Fit: машина привлечения будет исправно доставлять рынку продукт, из которого люди не получают ценности. ⚠️ Правило простое: до PMF — минимум GTM, после — строить машину.

🔗 Подробнее: https://agaltsovav.ru/docs/product-managment/go-to-market/

👥 Жизненный цикл сотрудника: путь от первого касания до ухода

Employee lifecycle описывает работу человека в компании как единый процесс из шести этапов: привлечение и найм, онбординг, развитие, оценка и рост, удержание и уход. У каждого этапа — свои цели, инструменты и метрики, а качество прохождения предыдущего определяет результаты следующих.

Главная ценность модели — точечная диагностика. Текучесть, долгий выход новичков на продуктивность, низкая вовлечённость — симптомы, за которыми всегда стоит конкретный этап-источник. Вместо размытого «у нас проблемы с людьми» модель даёт адресный вопрос: на каком этапе цикла потеря и какой процесс чинить.

Ошибка найма — самая дорогая ошибка цикла: она оплачивается дважды — зарплатой неподходящего сотрудника и стоимостью повторного найма. А провал онбординга оборачивается месяцами оплаченной, но непродуктивной работы.

Цикл замкнут: уход сотрудника запускает новый виток найма, а достойное расставание возвращается в компанию boomerang-наймами и рекомендациями. Метрики этапов — time-to-hire, time-to-productivity, retention rate, eNPS, regretted attrition — показывают, где система теряет людей.

🔗 Жизненный цикл сотрудника (Employee lifecycle): https://agaltsovav.ru/docs/people-managment/employee-lifecycle/

🔄 Жизненный цикл проекта: пять фаз от идеи до закрытия

Проект — работа с формальным началом и концом: начинается инициацией, заканчивается закрытием. PMBOK и ISO 21500 выделяют пять групп процессов — Инициация, Планирование, Исполнение, Мониторинг и контроль, Закрытие. Каркас универсален: меняется наполнение фаз, но не их состав.

Частая ошибка — подмена цикла разработки жизненным циклом проекта. SDLC описывает фазы создания ПО, Product Lifecycle — жизнь продукта на рынке, а Project Life Cycle — управление проектом. Это три разных цикла с разными ролями и метриками.

Возможность влиять на результат максимальна на старте, а стоимость изменений минимальна. К исполнению расходы растут, а цена переделок — экспоненциально. Отсюда ценность ранних фаз и гейтов между ними.

💡 Закрытие — обязательная фаза: без него проект «висит», ресурсы не высвобождены, а уроки потеряны.

🔗 Жизненный цикл проекта: https://agaltsovav.ru/docs/project-managment/project-life-cycle/

⚠️ Закон Мёрфи: почему надёжные системы проектируют из расчёта на отказ

Всё, что может пойти не так, рано или поздно пойдёт не так. Это не фатализм, а инженерное наблюдение: в достаточно сложной системе, которая работает достаточно долго, реализуются все сценарии отказа, которые проектировщик допустил — включая те, что он считал практически невозможными.

За афоризмом стоит реальная история: в 1949 году аэрокосмический инженер Эдвард Мёрфи разбирал провал испытаний проекта MX-981 — все шестнадцать датчиков перегрузок подключили задом наперёд. Так родился принцип defensive design: не надеяться, что ошибок не будет, а исключать саму возможность ошибки конструктивно.

В разработке ПО из этого принципа выросли целые практики: fail-fast и defensive programming, graceful degradation и circuit breaker, идемпотентные ретраи, chaos engineering и SLO с бюджетом ошибок. Классические катастрофы вроде Mars Climate Orbiter и Ariane 5 — результат не невезения, а «невозможных» сценариев, которые никто не исключил.

Инженерный вывод: надёжность системы определяется не отсутствием отказов, а поведением при отказе. Вопрос не «откажет ли», а «что произойдёт, когда откажет» — и ответ должен быть спроектирован заранее.

🔗 Закон Мёрфи: https://agaltsovav.ru/docs/development-managment/laws/murphys-law/