Agaltsov Anton | TeamLead-блог

🎯 Product-Market Fit — точка, после которой рынок тянет продукт сам Product-Market Fit (PMF) — состояние, при котором продукт удовлетворяет реальную потребность достаточно большого рынка. Формула Марка Андриссена короткая: рынок сам тянет продукт из ваших рук. Жизнь стартапа делится на две части — до PMF и после, и управляются они по разным правилам. Соответствие продукта рынку складывается из трёх элементов. Ценность — продукт закрывает настоящую потребность, пользователи называют его «must-have». Лёгкость — путь до ценности короткий, пользователь быстро доходит до сути. Охват — аудитория достаточно велика, чтобы поддерживать растущий бизнес. Дефицит любого элемента разрушает PMF. Главный опрос для замера — методика Шона Эллиса: «Как вы расстроитесь, если продукт исчезнет?» Если «очень расстроены» отвечают более 40% активных пользователей — у продукта, вероятно, есть PMF. PMF можно потерять — это спектр, а не разовое достижение. Рынок сдвигается, конкуренты переманивают ядро, погоня за новыми сегментами распыляет разработку. Сигналы потери: снижение Sean Ellis score в новых когортах, кривые удержания ниже предыдущих, рост оттока, падение доли органики. Поэтому PMF мониторят регулярно, а не «получают один раз и навсегда». 🔗 https://agaltsovav.ru/docs/product-managment/product-market-fit/

🤖 Как развести LLM по ролям: серверный кодинг, независимое ревью и свой агент OpenCode запущен на сервере через opencode serve и доступен через WebUI по HTTPS. Задача ставится, ноутбук закрывается — агент продолжает работать: правит файлы, гоняет тесты, коммитит. Прогресс мониторится с телефона. Серверный контур превращает LLM-ассистента из «игрушки на ноуте» в удалённого разработчика, задачи больше не умирают вместе с закрытой крышкой. Для code review — отдельный инструмент и другая модель. Когда код пишет одна модель, а ревьюит другая, срабатывает эффект независимого аудитора: у моделей разные слепые зоны, а ревьюер не защищает чужой код. Связка «писал на одном, поревьюил на другом» заметно сокращает число пропущенных багов и архитектурных кривостей. Третий слой — собственный агент TaigaClaw на Go: долговременная память с семантическим поиском, knowledge graph на PostgreSQL, сабагенты и cron-планировщик. Он управляет всей домашней инфраструктурой — Mac Studio, Debian-сервер, NAS и VPS в mesh-сети — по запросу из веб-чата: проверить упавший контейнер, обновить прокси, создать поддомен. 💡 Общий принцип: не искать одну «лучшую» модель, а разводить модели по ролям и держать серверный контур, независимый от рабочего места. Доверять, но проверять — разными моделями на разных этапах. 🔗 https://agaltsovav.ru/blog/how-i-use-llm/

📋 Испытательный срок — не экзамен, а двусторонняя проверка Испытательный срок — это формальный период, в течение которого работодатель и сотрудник оценивают соответствие друг друга. Цель не «выжить», а проверить, способен ли человек достигать результатов роли и интегрироваться в команду. Критерии оценки делятся на две группы. Hard — качество задач, самостоятельность, скорость обучения. Soft — коммуникация, способность принимать обратную связь, соответствие ценностям. Главное правило: критерии должны быть зафиксированы до старта, а не сформулированы постфактум. План 30/60/90 задаёт ритм: первые 30 дней — изучение процессов и первые самостоятельные задачи, к 60-му дню — стабильное выполнение рутины, к 90-му — полная самостоятельность. На каждом этапе — регулярные встречи 1-на-1 и промежуточные ревью, чтобы не оказалось, что решение принимается в последний день. ⚠️ Типичная ошибка — использование испытательного срока как источника дешёвой рабочей силы без обратной связи. В IT специфика в том, что первый инкремент и code review дают материал для оценки раньше, чем в других сферах. 🔗 https://agaltsovav.ru/docs/people-managment/probation-period/