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