Возьмите полученную вами модель путешествия объекта, выберите наиболее знакомый вам узел графа создателей, опишите его, назовите - какая роль осуществляет взаимодействие с объектом в этом узле и по каким методам агент в этой роли действует
Выбрал узел “характеризация”, в котором объект «запрос фичи» превращается из качественно описанной проблемы в измеримую. Здесь определяем:
- что именно мы будем измерять, чтобы понять, решена ли проблема
- по какой шкале
- в каких единицах
- какое направление — «лучше»
На этом этапе агент в роли “аналитик” (AcceptanceCharacterizerRole по FPF) взаимодействует с объектом “запрос фичи” (в виде ProblemCard по FPF) по следующим методам (в скобках применимые паттерны FPF):
- Привязка проверки ожидаемых улучшений к характеристикам объекта (A.17 + A.18 CSLC)
- Описание каждой характеристики (C.16)
- Формирование многомерного пространства характеристик (A.19)
- Оформление “комплекта характеристик” как SLA (C.25)
Опишите, в каком состоянии должен находиться объект в результате взаимодействия
Объект перешёл из состояния «поняли проблему» в состояние «знаем, как доказать, что проблема решена» (т.е. цель реализации фичи достигнута). Он готов к сравнению вариантов решения — потому что теперь у вариантов есть общее пространство координат, в котором их можно сопоставить.
Запишите контрольные вопросы, которые позволят оценить, выполнены ли нужные действия по методу и пришел ли объект в нужные состояния. Не забудьте включить вопросы, которые позволят провести и необходимые измерения изменений
Метод 1. Привязка проверки ожидаемых улучшений к характеристикам объекта
| № | Вопрос | Цель проверки |
|---|---|---|
| 1 | Перечислили ли мы все измеримые стороны проверки улучшений (improvement check) из исходной карточки проблемы (ProblemCard@Context)? |
Действие выполнено |
| 2 | Остались ли в проверке улучшений утверждения, которые мы не смогли привязать ни к одной характеристике (U.Characteristic)? |
Обнаружить неизмеримый остаток — если он есть, то возврат к проблематизации |
| 3 | Для каждой ли характеристики указан род шкалы — порядковая, отношений, имён? | Состояние: соблюдена связка характеристика-шкала-уровень-координата (CSLC) |
| 4 | Для каждой ли характеристики на шкале отношений указана единица измерения (U.Unit)? |
Состояние: число без единицы измерерия — бессмысленно |
| 5 | Для каждой ли характеристики явно указана направленность — что считать улучшением? | Состояние: без направленности нельзя сказать «стало лучше» |
| 6 | Можно ли по исходной проверке улучшений и полученному набору характеристик проследить, какое утверждение в какую характеристику превратилось? | Измерение изменения: прослеживаемость от слов к осям |
Метод 2. Создание шаблона для описания каждой характеристики
| № | Вопрос | Цель проверки |
|---|---|---|
| 1 | Для каждой ли характеристики из пространства создан шаблон измерения (U.DHCMethod)? |
Действие выполнено |
| 2 | Указан ли в каждом шаблоне источник данных (U.EvidenceStub) — откуда мы будем брать значения? |
Состояние: шаблон полон |
| 3 | Определена ли для каждого шаблона граница прямой сравнимости: с какими другими замерами его можно сравнивать напрямую (один и тот же шаблон), а с какими — нельзя? | Состояние: граница сравнимости зафиксирована |
| 4 | Есть ли среди задекларированных шаблонов такие, для которых источник данных сейчас недоступен? | Обнаружить потенциальный изъян: замер без источника невозможен |
| 5 | Зафиксировали ли мы, какая версия карточки проблемы послужила источником для каждого шаблона? | Измерение изменения: прослеживаемость к исходной проблеме |
| 6 | Можно ли по шаблону однозначно восстановить: что меряем, в какой шкале, в каких единицах, в какую сторону лучше? | Состояние: осмысленность замера (C.16) |
Метод 3. Формирование многомерного пространства характеристик
| № | Вопрос | Цель проверки |
|---|---|---|
| 1 | Собраны ли все характеристики в одно многомерное пространство (U.CharacteristicSpace)? |
Действие выполнено |
| 2 | Для каждого ли слота (измерения - dimension) в пространстве явно указана пара «характеристика — шкала»? | Состояние: соблюдена слотовая дисциплина (A.19) |
| 3 | Нет ли в пространстве двух мест, которые измеряют одно и то же, но названы по-разному? | Обнаружить повтор |
| 4 | Есть ли в проверке улучшений такие стороны качества, которые не попали ни в один слот пространства? | Обнаружить неполноту |
| 5 | Если качество сложное (например «надёжность»), оформили ли мы его как «комплект характеристик» (Q-Bundle), а не попытались свести к одному числу? |
Состояние: выбор конечной точки (C.25) — одна характеристика или свёртка |
| 6 | Зафиксировали ли мы, какой набор слотов в пространстве был до характеризации и какой после? | Измерение изменения: разница в составе измеряемых сторон |
Метод 4. Оформление «комплекта характеристик» как соглашения об уровне качества
| № | Вопрос | Цель проверки |
|---|---|---|
| 1 | Для каждого ли качества, которое несводимо к одному числу, оформлен «комплект характеристик» (Q-Bundle)? |
Действие выполнено |
| 2 | Содержит ли каждый комплект обязательные части: название, что оценивается (QualityBearer), границы применимости (ClaimScope), набор показателей (Measures)? |
Состояние: состав комплекта соблюдён |
| 3 | Указаны ли в комплекте защитные приёмы (Mechanisms, например повторная попытка при сбое), если они влияют на оценку качества? |
Состояние: защитные приёмы отделены от показателей |
| 4 | Не подменили ли мы в комплекте измерение — наличием защитного приёма? (Например: «есть повтор — значит надёжно») | Обнаружить лже-правило: наличие приёма ≠ измерение |
| 5 | Зафиксировали ли мы окно применимости (QualificationWindow) — в каких условиях комплект считается действительным? |
Состояние: окно применимости |
| 6 | Можно ли по комплекту проследить, из каких характеристик он собран, и все ли они имеют шаблоны измерения? | Измерение изменения: прослеживаемость от комплекта к характеристикам и шаблонам |
Сквозные вопросы
| № | Вопрос | Цель проверки |
|---|---|---|
| 1 | Совпадает ли набор заявленных характеристик с проверкой улучшений из карточки проблемы или мы что-то потеряли по дороге? | Измерение изменения: сохранность проверки улучшений |
| 2 | Можем ли мы теперь для каждой характеристики сказать, какое значение будет считаться «проблема решена» — порог приёмки? | Состояние: порог приёмки определён |
| 3 | Зафиксировали ли мы, что именно не является предметом характеризации — что осталось за границей отсечения (scope cut) карточки проблемы? |
Состояние: граница зафиксирована |
| 4 | Если карточка проблемы обновится — сможем ли мы определить, какие характеристики затронуты изменением и требуется ли перехарактеризация? | Измерение изменения: условие возврата к обновлению (G.11) |
Итоговый вопрос для перехода к следующему узлу
Готов ли предмет рассмотрения к переходу в узел «Сравнение» — то есть: многомерное пространство заявлено, все его места имеют шаблоны измерения, граница сравнимости зафиксирована, неизмеримого остатка нет?
- Да → Сравнение
- Нет → возврат к тому методу, где обнаружен изъян
Обсудите полученный чеклист с командой, отметьте полученные замечания и поправки.
Пока не сделано
Опишите, где в коллективном (или личном) экзокортексе будет размещён полученный чеклист
- В личном хранилище Obsidian
- Интегрирован в DPF по бизнес-анализу
Проведите обучение использованию чеклиста
- Первый ожидаемый пользователь - я (как и один из двух создателей). Первичное обучение пройдено одновременно с созданием.
- Возможно проведение внутреннего вебинара для аналитиков - TBD.