Примените схему заземления к имеющейся рабочей задаче, в ситуации, где, по вашему мнению, что-то уже идёт не так или что-то имеет все шансы пойти не так. Составьте первую версию описания задачи.
Задача: внедрить issue tracker для заявок в отдел IT/САПР.
Желаемая ситуация: вместо звонков, сообщений, устных просьб к сотрудникам отдела IT/САПР, пользователи обращаются с проблемами в issue tracker (в исключительных случаях сотрудник отдела IT/САПР сам заводит issue перед тем, как выполнять задачу). В issue tracker приведен полный список текущих issue с приоритетом их выполнения, при появлении нового issue ответственный за направление сотрудник берет задачу на исполнение (либо получает назначение от руководителя). Пользователь видит порядковый номер в списке на исполнение сотрудником отдела IT/САПР и текущий статус своей задачи. Сотрудники отдела IT/САПР придерживаются правила последовательного выполнения работ по поступившим заявкам без отвлечения на новые/параллельные. В наличии регламент общего характера, по которому сотрудник отдела IT/САПР обрабатывает заявку (поступление issue - взятие в работу/назначение сотруднику - прояснение деталей у пользователя (при необходимости) - выполнение задачи - уведомление пользователя о результатах - принятие от пользователя - закрытие issue).
Объект: работы сотрудников отдела IT/САПР по поступившим от пользователей заявкам.
Роль: специалист поддержки в области IT/САПР.
Агенты, которые будут теперь действовать иначе: сотрудники отдела IT/САПР, пользователи.
Действия: фиксация статусов работ в issue tracker, улучшенная коммуникация по статусам задач.
Результаты действий: актуальные статусы работ отображаются в issue tracker, доступны сотрудникам отдела IT/САПР и пользователям.
Контроль наличия нужных изменений: отслеживание количества issue, заведенных в issue tracker. Отслеживание issue, идущих “в обход”.
При каких условиях результат возможно получить? Issue tracker создан и развернут. Сотрудники отдела IT/САПР, пользователи согласны с введением нового подхода.
А при каких невозможно? Issue tracker не развернут. Сотрудники отдела IT/САПР или пользователи категорически против введения нового подхода.
Какие сигналы могут вам указать заранее на то, что делается что-то не то? Все issue идут “в обход” issue tracker.
Загрузите описание в LLM, усиленную FPF. Дайте команду “Проанализируй с опорой на FPF, достаточно ли конкретно и заземлённо составлено это описание”, прямо упомянув необходимость отвечать на языке вашей предметной области (подставьте название своей предметной области: разработка ПО, архитектура, продажи и т.п.). При необходимости покритикуйте ответ LLM и поменяйте запрос столько раз, сколько нужно, чтобы LLM исправила ошибки в ответе. Если у вас есть какие-то источники информации о предметной области помимо FPF, на которые LLM должна опираться при ответе, укажите их в запросе тоже.
Ответ ИИ: для уровня problem frame / инициативного описания — да, у вас текст уже достаточно конкретный и заземлённый. Для уровня FPF-модели, по которой можно без двусмысленности проектировать процесс, роли, статусы и контроль, — ещё не до конца.
С тем, что модель не полна для начала проектирования issue tracker - согласен.
Опишите к клубе МиМ свои выводы. Помогло ли заземление выявить ошибки в описании? Составить план решения проблем? В данной ситуации действительно стоило напрячься, или "радар ошибок" сработал вхолостую?
Да, заземление прояснило для меня самого некоторые моменты, заставило подумать над важными вопросами: чего конкретно я хочу, каков порядок смены статусов issue, как происходит коммуникация по issue, что нужно не забыть сделать (или какие вещи держать во внимании) для того, чтобы реализация проекта была успешной.
Кроме того, ИИ c FPF предложил дальнейшие действия для уточнения описания и создания модели, которая будет использоваться для реализации issue tracker.