Agaltsov Anton | TeamLead-блог

📦 Lean Canvas и Business Model Canvas: бизнес-модель на одном листе Канва — одностраничный шаблон из пронумерованных блоков, в которых команда фиксирует ключевые предположения о продукте: кого обслуживаем, какую проблему решаем, какую ценность предлагаем, через какие каналы доходим до клиента и как зарабатываем. Принцип «одна страница — одна модель» заставляет отсекать второстепенное: если модель не помещается на лист, она либо не продумана, либо слишком сложна для первой проверки. У инструмента два происхождения. Business Model Canvas Остервальдера описывает модель девятью блоками и адресован зрелым компаниям. Lean Canvas Эша Морийи — адаптация для стартапов: блоки про инфраструктуру (партнёры, ресурсы) заменены блоками про риск (проблема, решение, метрики, несправедливое преимущество). 💡 Ценность канвы не в том, что она «правильная», а в том, что она делает предположения видимыми и проверяемыми. Это черновик стратегии, а не сама стратегия: красиво записанная гипотеза остаётся гипотезой до проверки через Discovery. Главный риск — выбор канвы не по стадии: Lean Canvas теряет партнёрства и ресурсы зрелого бизнеса, а BMC маскирует главные риски раннего стартапа за инфраструктурными блоками. 🔗 https://agaltsovav.ru/docs/product-managment/lean-canvas/

🤖 Параметры LLM: temperature, top_p и seed меняют ответ сильнее, чем кажется LLM вероятностны по своей природе: на каждом шаге генерации модель строит распределение вероятностей по всему словарю и выбирает из него следующий токен. Параметры инференса — temperature, top_k, top_p, штрафы за повторения, seed — управляют именно этим выбором, не меняя саму модель. Одна и та же модель с разными параметрами ведёт себя как разные системы: temperature = 0 даёт жёсткий детерминизм для извлечения фактов, JSON и бенчмарков, значения выше 1 — разнообразие ценой связности и роста галлюцинаций. Фраза «используем модель X» без указания параметров ничего не говорит о качестве ответов. 💡 top_p (nucleus sampling) адаптивнее top_k: круг кандидатов сужается, когда модель уверена, и расширяется, когда вероятность размазана. Практическая связка — temperature + top_p, без выкручивания всех ручек одновременно. seed не гарантирует воспроизводимость между бэкендами и версиями модели: различаются реализации сэмплинга, численные типы и batching на GPU. Для строгого детерминизма фиксируют и seed, и temperature = 0 — и всё равно проверяют на целевом окружении. Здоровый подход — минимализм и измеримость: менять как можно меньше параметров, обосновывать каждое изменение метрикой и фиксировать значения в конфигурации как часть контракта между моделью и продуктом. 🔗 https://agaltsovav.ru/docs/ai/llm-parameters/

🔧 RDD — Risk Driven Development: сколько архитектуры достаточно, решает реестр рисков Risk Driven Development — подход Джорджа Фэрбенкса (книга «Just Enough Software Architecture», 2010), при котором объём и глубина архитектурных усилий определяются рисками проекта. Вместо вопроса «какой должна быть архитектура?» RDD ставит операциональный вопрос «сколько архитектуры достаточно?» — и отвечает: ровно столько, сколько нужно, чтобы идентифицированные риски были сняты или снижены до приемлемого уровня. Подход вырос из наблюдения о двух симметричных провалах индустрии. Первый — архитектура «на всякий случай»: полные модели и обобщения, значительная часть которых никогда не понадобится, но требует сопровождения. Второй — «архитектуры нет вообще»: структурные решения принимаются имплицитно и задним числом, а результат получает имя big ball of mud. Риск становится измерителем дозировки проектирования: где вероятность и цена неудачи высоки — проектировать глубоко и проверять, где риска нет — сознательно не тратить усилия. Архитектурные техники — инкапсуляция, слоистость, инверсия зависимостей, паттерны — трактуются как инструменты снижения конкретных рисков и применяются тогда, когда закрывают риск из реестра. «Применять все техники всегда» так же ошибочно, как «не применять никаких». Исторический первоисточник логики — спиральная модель Боэма, где каждым витком разработки управляет список наибольших оставшихся рисков. 💡 Практический минимум, который стоит забрать даже без полного внедрения, — привычка отвечать на вопрос «какой риск закрывает эта архитектура?» до того, как платить за неё временем команды. Не путать с Readme Driven Development — то же сокращение RDD, но движущая сила там документация, а не риски. 🔗 https://agaltsovav.ru/docs/development-managment/rdd-risk-driven-development/