Agaltsov Anton | TeamLead-блог

📊 Почему «сделали много, а клиенты недовольны»: модель Кано Самое важное свойство продукта может вообще не приносить удовлетворённости: базовые функции (вход в аккаунт, работающая оплата) лишь предотвращают недовольство — клиент воспринимает их как должное. Вкладывать в них ресурс нужно безусловно, но ждать роста лояльности — напрасно. Удовлетворённость создают свойства двух других типов: ожидаемые, по которым клиент прямо сравнивает продукты (скорость, цена, ёмкость), и вау-свойства — неожиданные «приятности», которых никто не просил, но которые запоминают и пересказывают другим. Категории не назначаются экспертно — они измеряются Kano-опросом: парные вопросы «как вы себя чувствуете, если свойство есть / нет» и матрица свёртки ответов. Без опроса команда проецирует собственные ожидания на клиента. Вау-эффект недолговечен: сенсорный экран прошёл путь от восторга до «должно быть» за десятилетие. Дифференциация — не разовая инвестиция, а постоянный процесс генерации новых вау-свойств. 🔗 Модель Кано: https://agaltsovav.ru/docs/product-managment/kano-model/

🗂️ Зачем проекту WBS — дерево работ, а не список задач WBS (Work Breakdown Structure) — это иерархическая декомпозиция полного объёма работ проекта: от «проекта целиком» до пакетов работ, которые уже можно оценить, назначить исполнителя и проконтролировать. Ключевой принцип: декомпозиции подвергается результат, а не действия. Элементы дерева — не «разработка» и «тестирование», а «сервис заказов» и «прошедший приёмку релиз». Результат можно принять: он либо есть, либо нет. 💡 Правило 100% — фундаментальный инвариант: сумма дочерних работ равна 100% родительской, и всё вместе покрывает весь объём проекта. Ветви не пересекаются. Пропущенный блок или лишняя работа сразу видны в арифметике дерева. Из WBS вырастает остальная плановая архитектура: диаграмма Ганта, RACI-матрица, бюджет, реестр рисков и критический путь получают исходные данные из одной структуры. 🔗 Подробнее: https://agaltsovav.ru/docs/project-managment/work-breakdown-structure/

🗺️ Одна диаграмма — это не архитектура: C4 и 4+1 Архитектуру невозможно уместить в одну картинку: инвестору нужен контекст из семи коробок, новому разработчику — состав сервисов и баз, архитектору — внутренности конкретного модуля. Попытка угодить всем порождает нечитаемый лист A0 со смешанными уровнями детализации. Модель 4+1 Крухтена (1995) делит описание на пять представлений под разные аудитории — логическое, процессное, физическое, представления разработки и сценариев. C4 Model Саймона Брауна работает как зум карт: Context → Container → Component → Code, от системы в окружении до отдельных классов. Контейнер в C4 — приложение или база, а не Docker. Подходы дополняют друг друга: 4+1 отвечает, какие взгляды на систему нужны, C4 — как их рисовать. HLD ложится на Context+Container, LLD — на Component+Code, а ADR добавляет к диаграммам «что есть» ответ на вопрос «почему так». 🔗 Модели описания архитектуры — C4 и 4+1: https://agaltsovav.ru/docs/architecture/c4-and-4plus1/