§7.06 Ключевая сущность проекта и рабочий продукт
Время: 60 мин чтение + 40 мин = 100 мин Что узнаешь: как отличить «что вы делаете» от «что получается», и почему без этого различия приёмка превращается в спор о вкусах
В одном предложении: альфа — это ключевая сущность проекта, состояние которой показывает зрелость; рабочий продукт — это наблюдаемый результат, который можно принять или отклонить; стадия завершена только когда альфа достигла нужного состояния через рабочий продукт.
Сигнатура понятий:
- Альфа — это ключевая сущность проекта (или системы), состояние которой определяет зрелость; альфа «незрима», оценивается через критерии, а не через прямое наблюдение
- Рабочий продукт — это наблюдаемый результат применения метода или прохождения стадии; артефакт, который можно показать, проверить, принять
- Состояние альфы — это дискретный уровень зрелости ключевой сущности; переход состояния = прогресс проекта
- Приёмка рабочего продукта — это проверка соответствия критериям; продукт либо принят, либо отправлен на доработку
Мем, который снимается. «Отчёт готов — значит, стадия закрыта». Нет. Отчёт — это рабочий продукт. Но рабочий продукт не гарантирует, что альфа достигла нужного состояния. Пример: отчёт о тестировании написан (продукт есть), но тестирование не проведено, данные выдуманы. Продукт существует, альфа «качество тестирования» находится в состоянии «не проверено». Приёмка продукта без проверки альфы — это формальность, а не контроль. Системный мыслитель спрашивает: «Какое состояние альфы должно быть? Какой продукт это состояние доказывает?»
Определение из источника.
В PACK-personal/ontology.md («Альфа») альфа определена как ключевая сущность проекта, состояние которой = зрелость проекта. Рабочий продукт - это наблюдаемый результат применения метода. Связь: альфа оценивается через рабочие продукты, но не сводится к ним.
Альфа - что это:
- Незримая сущность, которая «движется» через стадии.
- Примеры альф: «Требования» (насколько понятно, что строим), «Архитектура» (насколько решение устойчиво), «Команда» (насколько готова работать), «Качество» (насколько результат соответствует ожиданиям).
- Состояния альфы: для каждой альфы определены уровни зрелости. Переход на следующий уровень = прохождение стадии.
Рабочий продукт - что это:
- Зримая, наблюдаемая вещь: документ, прототип, отчёт, настроенный инструмент.
- Продукт создаётся для того, чтобы продемонстрировать состояние альфы.
- Продукт без альфы - пустая формальность. Альфа без продукта - невозможно проверить.
Связь со стадиями (§7.05): каждая стадия имеет цель - перевести одну или несколько альф в следующее состояние. Рабочий продукт стадии - это доказательство этого перехода. Без альфы стадия не имеет критерия завершения. Без продукта альфа не подтверждается.
Связь с таблицей 3×3 (§7.03): в каждой ячейке таблицы есть своя альфа. Например, в ячейке «Создатель × Система создания» альфа «Процесс создания» (насколько процесс налажен), продукт «Протокол создания» (документ). В ячейке «Пользователь × Целевая система» альфа «Удовлетворённость», продукт «Работающая функция». Если ячейка не заполнена, в ней нет ни альфы, ни продукта.
Развитие мысли.
Почему альфа важнее продукта? Потому что продукт можно подделать, а состояние альфы нет. Отчёт о тестировании можно написать, не тестируя. Но альфа «качество» при этом не изменится. Системный мыслитель ищет не «есть ли отчёт», а «изменилось ли состояние альфы благодаря отчёту».
Альфа как компас: когда проект идёт не туда, команда часто увеличивает объём продуктов («давайте ещё отчётов, ещё встреч»). Но если альфа «понимание требований» не растёт, продукты бесполезны. Альфа показывает, в каком направлении реальный прогресс.
Как определить альфу для стадии:
- Спросите: «Что должно измениться внутри проекта, чтобы стадия считалась пройденной?» — это альфа.
- Спросите: «Что можно показать, чтобы доказать это изменение?» — это продукт.
- Проверьте: можно ли принять продукт, не достигнув альфы? Если да, продукт не доказывает альфу, его нужно переделать.
Метод - минимальный шаг. Практика «Альфа и продукт для одной стадии» (40 мин):
- Выберите текущую стадию из любого проекта (5 мин).
- Назовите альфу: что должно измениться внутри проекта, чтобы стадия считалась пройденной? Запишите в формате «Альфа [X] в состоянии [Y]» (10 мин).
- Назовите рабочий продукт: что можно показать, чтобы доказать это состояние? Запишите критерии приёмки продукта (15 мин).
- Проверьте: можно ли принять продукт, не достигнув альфы? Если да, усильте критерии или измените продукт (10 мин).
Пример из жизни. Архитектор Анна проектировала систему интеграции для банка. Стадия 3 - «Интеграция с внешним API».
Альфа: «Надёжность интеграции» в состоянии «обработка 95% запросов без ошибок при пиковой нагрузке».
Продукт (первый вариант): документ «Спецификация интеграции».
Проблема: документ можно написать, не протестировав. Продукт принят, альфа не достигнута. Через месяц после запуска система падает под нагрузкой.
Продукт (исправленный): работающий прототип интеграции + отчёт нагрузочного тестирования с метриками.
Критерии приёмки: прототип обработал 10 000 запросов с 95% успехом, отчёт содержит графики latency и ошибок. Только при этих условиях альфа «Надёжность» считается достигнутой.
Анна изменила процесс: теперь на каждой стадии она сначала формулирует альфу, потом продукт с критериями. Она отметила: споры на приёмке прекратились, команда перестала спорить о вкусах и начала сверяться с критериями.
Типичная ошибка. «Альфа — это абстракция, она не нужна на практике». На самом деле без альфы приёмка превращается в субъективный спор: «Мне не нравится отчёт» vs «Отчёт хороший». С альфой спор исчезает: «Альфа требует показать метрики. В отчёте нет метрик. Продукт не принят». Альфа делает приёмку объективной.
Вторая ошибка - это смешение продукта и альфы. «У нас есть прототип — значит, интеграция работает». Нет. Прототип - это продукт. Интеграция работает - это альфа. Прототип в лаборатории не доказывает работу в боевых условиях. Продукт должен доказывать альфу, а не заменять её.
Степени мастерства:
Объясняю. Могу дать определение альфы и рабочего продукта, привести пример
Критерий: один раз определил альфу и продукт для реальной стадииУмею. Для любой стадии могу сформулировать альфу, продукт и критерии приёмки
Критерий: есть запись «3 стадии + альфа + продукт + критерии»Навык. Перед началом любой стадии автоматически спрашиваю: «Какая альфа? Какой продукт её докажет?»
Критерий: регулярно ловлю себя на смешении продукта с альфой и исправляюМастерство. Проектирую систему альф и продуктов для организации: шаблоны, чеклисты приёмки, критерии для каждой роли
Критерий: есть кейс, где внедрение альф и продуктов сократило споры на приёмке или предотвратило провал
Проверка себя.
- Понимание: вы можете объяснить, почему «отчёт готов» не критерий завершения стадии, если отчёт не доказывает достижение альфы.
- Поведение: перед началом любой стадии вы записываете: альфа, целевое состояние, продукт, критерии приёмки.
- Застревание: если приёмка превращается в спор «нравится / не нравится», вы забыли альфу. Остановитесь. Сформулируйте альфу и критерии заново.
Что дальше. Альфа и продукт дают критерии завершения стадии. Но кто принимает? Кто решает, достигнута ли альфа? Следующий подраздел - о приёмке: как провести её так, чтобы решение было объективным, а не произволом.