Загрузите последнюю версию FPF в LLM по вашему выбору (используйте VPN и зарегистрируйтесь на зарубежный e-mail при необходимости). Дайте команду "В приложении находится спецификация First Principles Framework (FPF). Отвечай на все вопросы с опорой на эту версию FPF".
ChatGPTрежим thinking расширенный.
Промт: “Покритикуй мои рассуждения на языке инженера-менеджера в прикрепленной заметке”.
К чату прикреплен пост, в инструкциях к проекту лежит FPF, с пометкой “В приложении находится спецификация First Principles Framework (FPF). Отвечай на все вопросы с опорой на эту версию FPF”
Оцените ответ LLM. Вы согласны с её критикой или нет? Объясните, почему, не ограничиваясь коротким ответом "согласен, нравится" или "не нравится, вообще не то". Если вы не понимаете, о чём пишет вам LLM с FPF, попросите разъяснить непонятные концепты/понятия на языке инженера-менеджера, который только начинает осваивать фреймворк (инженер-менеджер новичок). Попробуйте дать команду: "Найди нужный паттерн FPF, который поможет ответить на вопрос правильно, и отвечай с учётом этого паттерна". Вы можете попросить LLM разъяснить вам содержание этого паттерна с примерами.
Мои вопросы отметил как правильных ход рассуждений. Но обратил внимание, что смешаны разные объекты - с этим полностью согласна, так как это был первый черновик, где просто фиксировались мысли о заземлении терминов МИМ на мой рабочий проект.
Дальше замечания LLM и мои комментарии к ним:
1. Главная проблема: не зафиксирована граница целевой системы.
Тут соглашусь, и это было видно по моим вопросам в заметке.
Предложение от AI:
Вопрос Инженерно-управленческая формулировка Целевая система Лечебный многопрофильный корпус как объект капитального строительства / инфраструктурный актив Надсистема Медицинская организация / больничный комплекс / система оказания медпомощи Использование Оказание медицинских услуг в помещениях корпуса Пользователи/операторы Пациенты, врачи, медперсонал, эксплуатационные службы Описания системы ОТЗ, проектная документация, рабочая документация, исполнительная документация, акты, разрешения
2. Заказчик — не просто “создатель” и не просто “пользователь”
Дальше ИИ предлагает уточнить роли, которые были перечислены в заметке, например для заказчика предлагает перечень ролей:
Владелец потребности, держатель требований, приемщик результата, возможно будущий эксплуатант
То есть с этим можно работать дальше.
FPF для этого использует не глобальную сущность “агент”, а связку holder-role-context: один и тот же участник может иметь разные роли в разных контекстах. В спецификации A.2/A.2.1 это задано как контекстное назначение роли, а A.15 связывает роль с методом и фактической работой
3. “Создатели/агенты” смешаны с контролерами и участниками среды
В продолжение развития темы ролей и функций
4. “Свойства” сейчас записаны как мощность, но не как обоснованная характеристика
Мне нравится раскладка от ИИ, позволяет не только думать о текущем документе и проекте, но и переносить на объекты и документы:
Поле Пример Характеристика Стационарная мощность Значение 125 коек Тип шкалы Количественная, натуральные единицы Источник ОТЗ редакции 2022 года Основание Демографический расчет / поток пациентов / программа медпомощи / расчет загрузки Период применимости На какую дату или горизонт планирования рассчитано Критерий достаточности Почему 125, а не 180 Изменение относительно прошлой версии Было 180, стало 125 Причина изменения Должна быть в change rationale / решении / приложении
5. Критика ОТЗ у тебя сильная, но ее надо перевести из “мне не нравится” в дефект требований
ИИ предложил более сильную формулировку, чтобы это указать как замечание.
В ОТЗ отсутствует прослеживаемость ключевых мощностных характеристик. Изменение с 180/18 коек в редакции 2021 года до 125/25 коек в редакции 2022 года не сопровождено расчетным основанием, ссылкой на модель потребности, решением об изменении базовой мощности и указанием статуса актуальности редакции 2022 года. Это создает риск проектирования по числам, которые выглядят как требования, но не имеют проверяемого происхождения и управляемого статуса.
Это вынесу даже на обсуждение с командой, подумаем как это вынести на более высокий уровень (управления)
6. ОТЗ надо трактовать не как “описание системы”, а как design-time baseline
Звучит как уточнение, то есть ОТЗ - это всё равно описание системы (один из viewpoint).
7. В эксплуатационном сценарии смешаны функция здания и функция медицинской системы
Тут соглашусь, всё-таки граница системы была изначально определена недостаточно точно.
Корпус обеспечивает размещение и функционирование медицинских процессов
в заданных отделениях, с заданной мощностью, потоками пациентов,
инженерными режимами, санитарными требованиями и нормативной безопасностью.
И в целом предложение по переписыванию заметки:
Объект анализа
Целевая система: лечебный многопрофильный корпус как объект капитального строительства.
Граница системы: здание, помещения, инженерные системы и встроенная инфраструктура,
необходимые для размещения медицинских процессов.Не входят в целевую систему: пациенты, врачи, медицинская организация как субъект
эксплуатации, процессы диагностики и лечения. Они относятся к use context / операционной
надсистеме.Ключевые характеристики
- Стационарная мощность: 125 коек круглосуточного стационара.
- Реанимационная мощность: 25 коек.
- Источник: ОТЗ редакции 2022 года.
- Открытый вопрос: отсутствует расчетное основание и статус актуальности этих значений.
Участники и роли
- Заказчик: владелец потребности, держатель требований, приемщик результата.
- Проектная организация: разработчик проектных решений.
- Госэкспертиза: внешний gatekeeper допустимости проектных решений.
- Строительные организации: исполнители физического создания объекта.
- Стройнадзор: контрольный контур исполнения.
- Медицинский персонал: операторы медицинской деятельности в эксплуатационном контексте.
Основной риск требований
В ОТЗ отсутствует прослеживаемость мощностных характеристик.
В редакции 2021 года указано 180 коек стационара и 18 коек реанимации;
в редакции 2022 года — 125 и 25 соответственно. Изменение не сопровождено
обоснованием, расчетом потребности, ссылкой на решение или указанием, что редакция
2022 года является актуальной базой проектирования.Риск: проектирование ведется по числам, которые имеют форму требований,
но не имеют проверяемого происхождения и управляемого статуса.
Мне понравилось, что LLM+FPF подсветил слабые места, и предложил ответы на вопросы, либо уточняющие действия, чтобы эти ответы получить.
Отдельный плюс для меня в этом прохождении (в РР не было еще FPF) - это ссылки на паттерны при выполнении заданий, то есть заодно, прокачаю навыки более точного использования FPF.