Agaltsov Anton | TeamLead-блог

🎯 Value Proposition Canvas: когда продукт отвечает клиенту, а не себе Канва из шести блоков: карта ценности (продукты, обезболивающие, создатели выгод) прикладывается к профилю клиента (задачи, боли, выгоды). Ценность возникает не внутри половин, а в соответствии между ними — его и проектирует инструмент. Порядок заполнения жёсткий: сначала профиль клиента из реальных интервью, потом карта ценности. Обратный порядок — путь к подтверждению собственных догадок вместо изучения клиента. Всё записанное — гипотезы, а не факты. Соответствие проверяется на трёх уровнях: problem-solution fit на бумаге, product-market fit на рынке, business model fit в экономике. Главный риск — «заполнить клетки» в кабинете, без единого разговора с клиентом. Формулировки болей и выгод пишутся словами клиента и почти без перевода переносятся в лендинги, демо и презентации. 🔗 Value Proposition Canvas: https://agaltsovav.ru/docs/product-managment/value-proposition-canvas/

⚙️ Lean: ценность для клиента против занятых рук Lean (бережливое производство) вырос из производственной системы Toyota: maximize ценности для клиента при минимизации потерь. Всё, за что клиент не готов платить, объявляется потерей — muda — и подлежит устранению. Классическая фабрика спрашивает: «заняты ли станки и люди?» Lean спрашивает другое: движется ли продукт к клиенту и не останавливается ли ради чего-то, кроме создания ценности. Загруженный ресурс, производящий ненужное, — не достижение, а перепроизводство, самый опасный из восьми видов потерь. Практический инструмент — карта потока создания ценности (VSM): каждое действие размечается на создающее ценность, необходимое и потерю. Результат почти всегда одинаков: собственно полезная работа занимает единицы процентов времени процесса, остальное — ожидания, перемещения и переделки. В разработке ПО запасы превращаются в незавершённую работу (WIP), перепроизводство — в ненужные функции, излишняя обработка — в gold plating. Отсюда прямая линия к Kanban с его WIP-лимитами, а в стартапах — к MVP и циклу Build-Measure-Learn как способу не копить непроверенные гипотезы. ⚠️ Граница применимости: Lean без культуры kaizen вырождается в простое сокращение издержек с увольнениями, а для greenfield-исследований, где потока ещё нет, оптимизировать нечего — его сначала нужно найти. 🔗 Подробнее: https://agaltsovav.ru/docs/project-managment/lean/

🧩 GRASP: кому какую обязанность назначить? Каждое проектное решение — «куда положить метод», «кто создаёт объект», «кто реагирует на событие» — это решение о назначении обязанности. Крейг Ларман в Applying UML and Patterns (1997) предложил девять эвристик, каждая сформулирована как вопрос проектировщика. Пять базовых паттернов закрывают повседневные решения: Information Expert — обязанность тому, кто владеет данными; Creator — создаёт тот, кто агрегирует; Controller — системное событие принимает не-класс интерфейса. Ещё четыре работают с вариативностью: Polymorphism вместо ветвлений, Pure Fabrication — искусственный класс вроде репозитория, Indirection — посредник, Protected Variations — стабильный интерфейс вокруг изменчивого. GRASP старше SOLID и лежит под паттернами GoF: Фасад — это Controller и Pure Fabrication, Адаптер — Indirection, Стратегия — Polymorphism. Один словарь обслуживает три уровня — код, компоненты, архитектуру. 🔗 GRASP: https://agaltsovav.ru/docs/architecture/grasp/