Примените схему заземления к имеющейся рабочей задаче, в ситуации, где, по вашему мнению, что-то уже идёт не так или что-то имеет все шансы пойти не так. Составьте первую версию описания задачи.
R1.2:Tasks1. Заземление постановки задачи
Задача, которую взяла: написать регламент работы для отдела продаж — как вести сделку по стадиям в CRM. Конфигурация системы к этому моменту согласована с руководителем отдела, то есть на входе задача выглядела как «оформить документ по готовому решению». Взяла именно её, потому что подозрение было конкретным: похожие документы у нас несколько раз выходили и не начинали использоваться.
Ниже — первая версия описания по схеме заземления.
- Что должно измениться, и с какой точки зрения смотрю
Смотрю с точки зрения владельца процесса. Это значит, что в описание попадают воспроизводимость работы, полнота данных и возможность нового сотрудника войти в дело по документу; коммерческий результат отдела в описание не попадает — не потому, что он неважен, а потому, что с этой позиции он не предмет.
Что дребезжит сейчас. Поля и стадии воронки приведены к целевому состоянию и согласованы, но правила их заполнения не описаны ни в одном действующем носителе. Прежний регламент писался под предыдущую версию системы: часть описанных в нём полей больше не существует, часть перешла к другому подразделению, а одной стадии, с которой фактически начинается работа, в нём нет вовсе. Сотрудник действует по памяти и по тому, что видит на экране. Новый человек войти в работу по документу не может — документа, соответствующего системе, нет.
Что должно измениться в физическом мире. Появляется действующий носитель правил, соответствующий текущей конфигурации на названную дату. Растёт доля сделок, где заполнены поля, обязательные для перехода по стадиям. Новый сотрудник заводит первую сделку по документу, а не по показу коллеги.
Первоначально я включила сюда же четвёртый объект — чтобы результат перестал зависеть от того, кто именно заводил сделку. Дальше он не прошёл проверку и вычеркнут, об этом ниже.
- Кто будет действовать иначе
Сотрудник отдела продаж. На стадии квалификации он теперь обязан внести сумму и дату будущего списания — раньше это оставалось на его усмотрение. Меняется состояние сделки: она не проходит дальше без этих значений. На двух других стадиях появляются новые поля, но об этом отдельно в четвёртом пункте, потому что там есть условие.
Новый сотрудник при выходе на работу. Заводит первую сделку, опираясь на документ. Результат — заведённая сделка, по которой не пришлось переспрашивать.
Руководитель отдела. Доводит регламент до команды и спрашивает за исполнение. Это то действие, которое переводит документ из выложенного в действующий.
Владелец процесса, то есть я. Пишу документ и смотрю заполняемость по выгрузке. Роль проверяющего взяла на себя временно.
Настройщик системы в этот список не входит: его действия описаны в отдельном рабочем листе и регламентом отдела продаж не задаются.
Здесь схема требует сверки: названы ли все объекты из первого пункта. Проверка показала, что четвёртый объект — независимость результата от исполнителя — не появился ни в чьих действиях и ничем не измеряется. Значит это пожелание внутри описания, а не объект задачи. Вычеркнула.
- Как проверю, что изменения произошли
Замеряю не время прохождения стадий, а качество данных. Из выгрузки по воронке считаю три доли: сколько сделок на нужной стадии и дальше имеют заполненную сумму; сколько записей в поле даты содержат значение по умолчанию; сколько записей в поле источника содержат служебные заглушки, которые сейчас лежат в справочнике. Смотрю через две-три недели после настройки, дальше ежемесячно. Пороговые значения ещё не назначены — это открытый пункт.
Четвёртый замер — про главный объект и он самый слабый. Возможность войти в работу по документу проверяется наблюдением на онбординге нового сотрудника, а такого события может не быть месяцами. Замер, наступающий неизвестно когда, делает главный объект непроверяемым. Вижу обход: проверить на человеке, который уже работает в компании, но эту воронку не вёл.
Что покажет несходимость. Если доля заполнения выросла и доля заглушек выросла тоже — обязательность работает, а проверка вводимого значения отсутствует. Если доля заполнения не выросла — обязательность не включена технически либо включена не на той стадии.
- При каких условиях результат возможен, при каких невозможен
Условия, без которых результата не будет: конфигурация действительно настроена; справочник источников очищен от служебных заглушек, которые копятся в нём сейчас; согласован размер справочника категорий — это последний открытый вопрос по полям; собран справочник причин отказа; установлено, кто принимает решение о введении обязательности полей; формулировка зоны ответственности на стадии запуска согласована с руководителем смежного подразделения.
Два последних условия я до заземления не считала условиями. Полномочие вводить обязательность нигде не установлено — я исходила из того, что если никто не возражает, то можно. Зона ответственности на стадии запуска была согласована месяц назад в разговоре про поля, и человека, чью команду она касается, в том разговоре не было.
Антиусловия — обстоятельства, при которых результат становится отрицательным. Оба поля, которые предполагается сделать обязательными, — даты, и ни для одного не предусмотрена проверка вводимого значения. В базе уже лежат следы такого решения из прошлого: дата тридцать первое декабря и номер из одних единиц. Обязательность без проверки не улучшает данные, а ухудшает: поле заполняется заглушкой, и отличить его от честно заполненного больше невозможно. Второе антиусловие: регламент выложен на общий ресурс, но не доведён до конкретных людей — в моей истории этот тип артефактов давал такой исход десять раз из десяти.
Третье антиусловие обнаружилось при проходе по стадиям. Из трёх стадий, где вводятся новые поля, техническая обязательность включается только на одной. На двух других регламент может написать «заполняйте», но система этого не потребует. Документ, утверждающий обязанность, которой в системе нет, расходится с реальностью при первой же проверке — и обесценивает остальные свои разделы.
- Ранние сигналы, что делается что-то не то
Доля заполненных полей не растёт после введения обязательности. Появляются значения-заглушки: поле формально заполнено, данных в нём нет. Сотрудники продолжают спрашивать друг друга, что вносить, хотя документ выпущен, — значит документ есть, но не является тем, к чему обращаются. Команда не приходит с вопросами, а ждёт общей встречи, и сроки по поручениям растягиваются. И отдельный сигнал, который я раньше не отнесла бы сюда: если после снятия одного из полей сотрудники начнут вручную разыскивать коллегу из смежного отдела — значит изменение добавило им работы, а не убрало.
Что осталось открытым в этой версии
Шесть затруднений. Предмет описания раздваивается: регламент, работа по заполнению и данные в системе — три разные сущности, а описание говорит о них так, будто это одно. Полномочие вводить обязательность не установлено. Три условия из шести зависят от другого человека и на сегодня не выполнены. Замер главного объекта не имеет даты. Формулировка зоны ответственности согласована не со всеми, кого касается. Пороговые значения не назначены.
План на них: выбрать одну сущность как предмет и переписать первый пункт через неё; принять решение по двум стадиям — включаем обязательность или признаём, что там документ поведение не меняет; назначить три порога по текущей выгрузке; задать вопрос о полномочии; согласовать формулировку по стадии запуска; заменить замер на онбординге проверкой на сотруднике из смежной команды.
Вопрос
Про механизм обязательности. У меня вышло, что документ меняет поведение только там, где за ним стоит техническое ограничение системы, а во всех остальных местах он сообщает о возможности. Но регламенты сплошь и рядом работают и без технической поддержки — за счёт того, что за них спрашивают, или что они вошли в привычку. Правильно ли я понимаю, что «обязательность» здесь не одна, а несколько разных механизмов, и при заземлении нужно называть, какой именно обеспечивает каждое требование документа? Или наличие спрашивающего — это уже не свойство документа, а условие из четвёртого пункта схемы?
Загрузите описание в LLM, усиленную FPF. Дайте команду “Проанализируй с опорой на FPF, достаточно ли конкретно и заземлённо составлено это описание”, прямо упомянув необходимость отвечать на языке вашей предметной области (подставьте название своей предметной области: разработка ПО, архитектура, продажи и т.п.). При необходимости покритикуйте ответ LLM и поменяйте запрос столько раз, сколько нужно, чтобы LLM исправила ошибки в ответе. Если у вас есть какие-то источники информации о предметной области помимо FPF, на которые LLM должна опираться при ответе, укажите их в запросе тоже.
Вердикт по пунктам схемы
Пункт 1 — заземлён частично.
Точка зрения названа явно и удержана — это выполняет требование C.2.1 к ClaimScope и viewpoint. Описание текущей ситуации проверяемо: утверждение «правила заполнения не описаны ни в одном действующем носителе» можно опровергнуть, предъявив носитель. Это признак описания, а не хотелки.
Дефект в EntityOfConcern. По C.2.1 эпистема опознаётся через один точный EntityOfConcern. В пункте 1 их четыре, и они принадлежат разным типам:
— регламент — эпистема, описание способа ведения сделки (U.MethodDescription, A.3.2);
— способ ведения сделки — сам метод (U.Method, A.3.1), существует независимо от документа и не меняется от того, что документ переписан;
— заведение конкретных сделок сотрудниками — датированные выполненные работы (U.Work, A.15.1);
— данные в карточках — результат работ, отдельный объект.
Утверждения «появится действующий регламент» и «вырастет доля заполненных полей» относятся к первому и четвёртому объектам. Связь между ними — гипотеза о причинности, которую описание не проговаривает: регламент может быть выпущен, а доля не измениться. Это ровно тот разрыв, из-за которого документы выходят и не начинают использоваться.
Пункт 2 — заземлён.
Агенты названы, действия названы, результаты названы, встроенная сверка с пунктом 1 проведена и дала результат — четвёртый объект вычеркнут. По A.15.1 требуется указать исполнителя и назначение, под которым работа выполняется: для сотрудника отдела продаж и для руководителя это выполнено через RACI воронки.
Одно замечание по A.15.2. Утверждение «новый сотрудник заводит первую сделку по документу» — это U.WorkPlan, а не U.Work: планом актуальность не создаётся. Пункт 2 описывает его в том же залоге, что и действия существующих сотрудников, хотя их статус разный: одно уже происходит и меняется, второе может не произойти вовсе.
Пункт 3 — заземлён частично.
Механизм назван целиком: источник данных, считаемая величина, кто смотрит, с какой периодичностью. По A.10 это корректная опора — утверждение о результате будет опираться на выгрузку с датой, а не на впечатление.
Два дефекта. Первый: пороги не назначены, то есть предикат «результат достигнут» не определён — проверка есть, критерия нет. Второй, более существенный: замер главного объекта привязан к событию найма, наступление которого не контролируется. По A.15.2 это делает утверждение о достижимости зависимым от условия, которого нет ни в плане, ни в чьей-либо работе. Предложенный обход — проверка на сотруднике из смежной команды — снимает дефект и должен войти в описание, а не остаться комментарием.
Пункт 4 — заземлён, и это сильнейшая часть описания.
Антиусловия сформулированы как проверяемые утверждения о механизме, а не как риски: обязательность поля без проверки вводимого значения даёт заглушку, заглушка неотличима от честного заполнения, следовательно данные становятся хуже исходных. Рядом стоят прецеденты — по A.10 это опора на факт, а не на опасение.
Дефект один, но он относится к типу разрешения. Условие «установлено, кто принимает решение о введении обязательности» описано через отсутствие возражений. По A.2.8.PER это weak non-prohibition — констатация ненаказуемости, а не policy-valid strong grant. Разрешение по этому паттерну обретается инстанцирующим актом с указанием, какая система под каким назначением его выдала. «Никто не возражает» не является таким актом и не даёт права; при конфликте оно не защищает.
Пункт 5 — заземлён.
Сигналы наблюдаемы и разнородны по природе: два о данных, два о поведении команды, один о побочном эффекте. Последний — что сотрудники начнут вручную разыскивать коллегу из смежного отдела — по A.6.P является восстановленным отношением: назван конкретный субъект, действие и условие, при котором оно возникает.
Category errors (A.7)
-
«Регламент» схлопывает три объекта. Слово употребляется одновременно как описание способа (MethodDescription), как файл-носитель и как сам порядок работы (Method). A.7 требует держать их раздельно: MethodDescription ≠ Method ≠ Capability ≠ Work. Практическое следствие для задачи: «написать регламент» и «изменить способ ведения сделки» — разные работы с разными результатами, и первая не влечёт вторую.
-
«Обязательность» схлопывает не менее трёх механизмов. В описании она означает то ограничение системы (сделка не переходит на следующую стадию), то норму документа («поле обязательно к заполнению»), то работу руководителя (спрашивает за исполнение). Это разные объекты: первое — свойство конфигурации, второе — содержание MethodDescription, третье — U.Work под назначением. Из них только первое действует без участия человека. Смешение объясняет, почему в описании оказалось внутреннее противоречие: на двух стадиях документ утверждает обязанность, которой в конфигурации нет.
-
«Воспроизводимость» стоит между свойством метода и способностью агента. Если это свойство метода — предметом является описание. Если способность нового сотрудника — предметом является агент, и тогда по трём условиям способности требуются квалификация, выполнимость в наличных условиях и измеримость. Описание использует слово в обоих смыслах.
-
«Действующий носитель». Что делает носитель действующим — соответствие текущей конфигурации, факт публикации или факт обращения к нему? По A.10 это вопрос актуальности утверждения, и он не решается словом «действующий».
Что исправить в первую очередь
Первое — выбрать один EntityOfConcern и переписать пункт 1 через него, остальные три объекта назвать как связанные, а не как равноправные. Без этого связь «документ → данные» остаётся необъявленной гипотезой, и проверка пункта 3 не будет проверять то, ради чего задача делается.
Второе — развести три механизма обязательности и указать для каждого требования документа, каким именно оно обеспечено. Это снимает противоречие на двух стадиях и одновременно отвечает на вопрос, включать ли там обязательность.
Третье — перевести разрешение из ненаказуемости в выданное право: назвать, кто и каким актом принимает решение о введении обязательности полей. По A.2.8.PER это условие выполнимости, а не формальность.
Четвёртое — назначить пороги и заменить замер на онбординге проверкой, наступление которой контролируется.
Пятое, необязательное: развести в пункте 2 залог для происходящего и планируемого.
Итоговый вердикт
Описание заземлено в части действий, проверки и условий и не заземлено в части предмета. Пункты 2, 4 и 5 дают материал, по которому можно принимать решения. Пункт 1 удерживает точку зрения, но не удерживает единственность предмета, и это протекает в пункт 3: измеряется результат работ сотрудников, а обещается появление документа.
Для документа такого класса это типовой дефект: путь от «есть регламент» до «данные изменились» проходит через метод, работы и способность агентов, и каждый переход может не состояться. Описание, называющее только концы этого пути, выглядит конкретным — все объекты названы точно — и при этом не позволяет предсказать результат.
Опишите к клубе МиМ свои выводы. Помогло ли заземление выявить ошибки в описании? Составить план решения проблем? В данной ситуации действительно стоило напрячься, или “радар ошибок” сработал вхолостую?
Заземляла задачу, которая стоит у меня на этой неделе: написать регламент работы для отдела продаж — как вести сделку по стадиям в CRM. Конфигурация системы к этому моменту была согласована с руководителем отдела, так что на входе задача выглядела как «оформить документ по готовому решению». Взяла её именно поэтому: подозрение было конкретным — похожие документы у нас несколько раз выходили и не начинали использоваться.
Помогло ли выявить ошибки — да, и не те, которые я искала.
Я ожидала найти неточности в документе. Нашла ошибки в постановке, то есть в том, что было до документа.
Первую поймала встроенная сверка внутри второго пункта схемы. В первом пункте я выписала, что должно измениться, и среди прочего написала: чтобы результат перестал зависеть от того, кто именно заводил сделку. Второй пункт требует назвать агентов и их новые действия, а потом проверить, все ли объекты из первого пункта в этих действиях появились. Этот не появился ни у кого и ничем не измерялся. Значит он не объект задачи, а пожелание внутри описания. Вычеркнула.
Вторую ошибку я допустила прямо в ходе применения схемы, и схема же её поймала. Отвечая на вопрос «кто будет действовать иначе», я пошла по рабочему листу настройки системы и аккуратно разложила все стадии: где меняются поля, где они переезжают, где сносятся. Получила чистый вывод — действия сотрудника меняются максимум на трёх стадиях из девяти. Потом открыла действующий регламент и увидела, что он устроен шире полей: по каждой стадии там есть цель, описание действий, поля и критерий перехода. Постановка задачи коллеге, работа с папкой клиента, условие перехода — всего этого в конфигурации полей нет вообще. Вывод был получен корректно, но из неверно выбранного носителя: я отвечала на вопрос «что меняет настройка системы», а вопрос был «что должно быть в регламенте».
Третью дал третий пункт схемы. Метрики нашлись сразу — доли заполнения считаются из выгрузки. А смотреть их оказалось некому: руководитель отдела будет требовать исполнения от команды, но выгрузку не смотрит. Пороги повисали без адресата. У меня ровно такой случай уже есть в личных правилах: правило заведено год назад, исполнение ни разу не отслеживалось, просто потому что не был назван тот, кто смотрит.
Четвёртую нашёл разбор по FPF: в описании оказалось четыре разных предмета вместо одного — сам регламент, способ ведения сделки, конкретные заведения сделок сотрудниками и данные в карточках. Утверждения «появится документ» и «вырастет доля заполненных полей» относятся к разным из них, а связь между ними — гипотеза, которую описание не проговаривает. Документ может выйти, а данные не измениться. Кажется, это и есть механизм того, почему прошлые документы выходили и не начинали работать.
Отдельно разбор назвал двусмысленности, которых я не видела. Слово «регламент» у меня означало одновременно описание способа работы, файл и сам порядок работы. Слово «обязательность» — то ограничение системы, то норму документа, то работу руководителя, который спрашивает. Из трёх только первое действует без участия человека, и именно на этом смешении держалось внутреннее противоречие: на двух стадиях мой документ утверждал бы обязанность, которой в системе нет.
И одно попадание прямо в мою формулировку. Я написала, что исходила из принципа «если никто не возражает, то можно». В FPF у этого есть имя: это ненаказуемость, а не выданное право. Право обретается актом, где названо, кто и на каком основании его выдал. При конфликте ненаказуемость не защищает.
Но главное я выделила сама, уже после разбора: регламент по факту пишется в конце.
Когда двусмысленности были названы, стало видно, что у меня в одну задачу свёрнуты три разных такта работы, идущих в определённом порядке.
Сначала проектирование, утверждение и настройка — это среда. Она меняется конфигурацией системы, а не текстом; текст её не создаёт и не отменяет. Потом инструкция: как в этой среде работать. Она пишется тогда, когда среда уже есть, и обязательно проходит итерации на обратной связи от команды. И только после этого — регламент по финальной части, именно для сейлзов: что из описанного способа становится нормой.
Это разрешает оба смешения, которые нашёл разбор. Слово «регламент» у меня означало то способ, то файл, то норму — потому что три такта были свёрнуты в один. Слово «обязательность» вело себя так же: техническое ограничение принадлежит среде, норма принадлежит регламенту, а инструкция не вводит ни того ни другого. Отсюда и внутреннее противоречие: текст, который я собиралась писать, утверждал бы обязанность, которой в среде нет, — просто потому, что я писала документ пятого такта, находясь на третьем.
И это же переоценивает мои блокеры. В четвёртом пункте схемы я перечислила условия, без которых результата не будет: настройка не подтверждена, один справочник не очищен, размер другого не согласован, третий не собран. Все четыре относятся к среде. До заземления я читала их как «люди не отвечают, работа стоит». Теперь читаю иначе: такт не пройден, и артефакты следующих тактов писать рано. Блокеры не мешают работе — они говорят, что работа взята не на своём такте.
Отдельно отмечу третье следствие, потому что оно про меня, а не про задачу. Итерации на обратной связи встроены в такт инструкции по определению: она не может быть готовой до того, как команда её посмотрит. У меня есть устойчивая проблема — документы копятся, потому что я продолжаю их дорабатывать вместо того, чтобы отдать. Для артефактов этого такта проблема снимается самим устройством работы: отдать неготовое здесь не провал, а способ сделать.
Помогло ли составить план — да, но интереснее оказалось другое.
План получился из шести шагов с оценками. Два из шести оказались не работой, а вопросами к людям. Причём один из этих вопросов я сформулировала двумя днями раньше и не задала. То есть план не столько создал новую работу, сколько показал, что часть уже названной работы не двигалась, потому что была не той природы: я держала в списке задач то, что задачей не является.
Стоило ли напрягаться — да, и вот на чём я это основываю.
На входе задача выглядела как оформление документа по согласованному решению. За час, из уже имевшихся у меня материалов, без единой новой встречи, вычитались: два обстоятельства, при которых результат стал бы отрицательным; неустановленное право принимать одно из ключевых решений; зона ответственности, согласованная без человека, чью команду она касается; отсутствие того, кто будет смотреть результат; и внутреннее противоречие документа с системой.
Про два первых стоит сказать подробнее, потому что это не риски. Два поля предполагалось сделать обязательными к заполнению. Оба — даты, и ни для одного не предусмотрена проверка вводимого значения. В базе уже лежат следы такого решения из прошлого: дата тридцать первое декабря и номер из одних единиц. Обязательность без проверки не улучшает данные, а ухудшает: поле заполняется заглушкой, и отличить его от честно заполненного больше нельзя. Это не вероятность неудачи, а условие, при котором задача даёт результат, обратный задуманному. До заземления я держала это в голове как пометку «не забыть про валидацию», то есть как деталь реализации.
К этому добавился результат, которого я не ожидала вовсе: задача оказалась взята не на своём такте. Это не найденная ошибка в описании — это переопределение предмета. Если бы я села писать документ сразу, я бы написала его добросовестно и не на том шаге, и обнаружилось бы это не раньше, чем при попытке ввести его в работу.
Но насчёт «радара» у меня возражение.
Метафора радара предполагает, что ошибки уже есть, лежат в описании, и инструмент их обнаруживает. У меня вышло иначе. Схема не столько обнаружила ошибки, сколько заставила назвать то, что не было названо, — и уже после этого стало видно, что часть названного не сходится. Объект, который никем не меняется, становится ошибкой только в тот момент, когда я перечислила агентов и их действия; до этого он был просто ненаписанным. Разница практическая: радар можно навести на готовый текст и получить список замечаний, а здесь работа шла в другую сторону — сначала произвести различения, потом увидеть расхождение.
Поэтому на вопрос «сработал ли радар вхолостую» я бы ответила так: он не сработал вхолостую, но и не сработал как радар. Ближе к тому, что описание задачи у меня до этого попросту отсутствовало — был согласованный набор решений по системе и намерение оформить его документом. Схема не улучшила описание, она его создала. А заодно показала, что и задача была названа неверно: не «написать регламент», а «пройти такт, на котором я сейчас нахожусь».
Что беру дальше.
Проверку из второго пункта — назвать агентов и сверить, все ли объекты из первого пункта в чьих-то действиях появились — буду делать по любому документу, который собираюсь выпускать. Она дешёвая, механическая и ловит именно то, из-за чего у меня артефакты выходят и не используются.
И вопрос о такте перед началом работы над любым текстовым артефактом: среда, инструкция или норма. Раньше я различала документы по адресату и по объёму; оказалось, что важнее, на каком шаге они пишутся, потому что от этого зависит, что документ вообще может утверждать.
Вопрос.
Про природу самой схемы. У меня она сработала не как проверка готового описания, а как процедура его составления: ошибки возникали в ходе применения и тут же ловились следующим пунктом. Верно ли, что схема заземления в принципе не предназначена для проверки чужого или уже написанного описания, и её нужно проходить самому и с нуля? Или проверять чужое описание по ней всё-таки можно, просто тогда часть пунктов останется без ответа, и это само по себе будет результатом?