Agaltsov Anton | TeamLead-блог

⚙️ 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/

🧭 User Persona и Empathy Map: кого на самом деле проектирует команда «Пользователь» — растяжимое понятие: пока он остаётся абстракцией, разработчик воображает эксперта, маркетолог — новичка, основатель — самого себя. Продукт, спроектированный «для всех», в итоге не подходит никому. User Persona — это архетип сегмента аудитории в виде конкретного вымышленного человека: имя, роль, цели, боли, поведение, цитата от первого лица. Empathy Map — одностраничная схема его внутреннего мира по квадрантам Says / Thinks / Does / Feels: что человек говорит, думает, делает и чувствует. Практика показывает: карта эмпатии часто заполняется первой — как воркшоп для разбора интервью, — а затем сворачивается в персону, которая живёт в документации команды. Персона отвечает на вопрос «кто это», карта — «что этот человек думает и чувствует». ⚠️ У метода жёсткие условия качества: персоны строятся из данных интервью (без них — только честно помеченная proto-persona), их не больше 3–5 на продукт, а у портрета должна быть дата данных и цикл обновления. Дюжина персон превышает рабочую память команды — и перестаёт использоваться. 🔗 User Persona и Empathy Map: https://agaltsovav.ru/docs/product-managment/user-persona-empathy-map/