Что моделируем? Деятельность создателей.

Как мы уже узнали в начале, моделировать можно все, что угодно! В большинстве случаев мы делаем это и даже не замечаем. Но существуют типовые полезные случаи моделирования, то есть такие, в которых явное моделирование сильно помогает.

Большинству инженеров-менеджеров знакомы ситуации, когда нужно описывать методы работы — сюда относятся всевозможные описания бизнес-процессов, инструкции, чеклисты.

Все их можно грубо описать как набор последовательных предложений вида "Ты, находящийся в роли {роль}, найди в контексте {контекст} объект {объект} и приведи его в состояние {состояние} с помощью действия {действие}".

Иногда обсуждается один и тот же объект, который проходит смену множества состояний под воздействием действий разных ролей (например, этапы изготовления вещи).

Иногда обсуждаются разные объекты, с которым приходится иметь дело (и переводить в новые состояния) одной и той же роли (например, должностная инструкция).

Вы можете очень формально придерживаться этой структуры, вплоть до выражения ее на языках программирования или передачи как шаблона вашей любимой нейросети. Вы можете добавить в эту структуру поле для комментария: "... и обязательно учти/добавь в контекст {любые представления}.

Даже если вы пишете простой текст — обычное сообщение в чате для какого-то исполнителя или формулируете инструкцию на будущее для себя же — вам все равно нужно позаботиться о том, чтобы исполнитель нашел все выделенные фигурными скобками штуковины.

• Кто должен это делать? Роль часто "и так понятна" по тому, какой описывается метод или кому это пишут; но если вы оставляете пачку инструкций для нескольких ролей, то хорошо бы написать большими буквами в начале "Капитан воздушного судна", "Второй пилот", "Бортпроводник".
• Где искать объект (в пространстве и времени!)? Когда и при каких обстоятельствах нужно выполнять эту инструкцию? Этот пункт часто упускают, потому что в момент написания это кажется очевидным. Правки от заказчика нужно принимать самое позднее за сколько времени перед релизом? Какие обязательные элементы контекста нужно заметить, чтобы вообще найти правильный объект?
• Какой объект ищем? С чем будем производить манипуляции?

Будьте аккуратны при указании на объект, это самая важная часть. Например, частая ошибка менеджеров — "найди задачу в джире и сделай! переведи в состояние "готово"". Только дело в том, что в джире — описание задачи, а сама задача (объекты, нуждающиеся в изменении)где-то в мире, и сделать ее нужно где-то в мире. Объект, с которым мы хотим произвести изменения, назван неправильно, спутана вещь и ее описание.

Разумеется, в общей инструкции вы можете использовать указатели на объекты: "возьми объект, описанный там-то и сделай с ним то, что описанно вот там-то", но базовое правило состоит в том, что чем меньше этих указателей, тем лучши мокрые нейросетки справляются с обработкой.

• В каком состоянии объект на момент, когда мы его нашли? Если не указывать это, то до смешного часто будете сталкиваться с дублированием или повторением работы. Как в анекдоте про математика: Что нужно сделать, чтобы заварить чай? Набрать в чайник воды, включить чайник, подождать кипения воды, положить заварку в кружку, налить воду в кружку. А что делать, если в чайнике уже есть вода? Все очень просто, вылить воду и задача сводится к предыдущей!
• В какое состояние нужно привести объект? Обычно ближе к готовности.
• С помощью какого действия? Иногда, нам это неважно или это можно сделать только одним способом. Но иногда мы как раз для этого пишем инструкции и "политики" компании.

Хорошая практика — придерживаться этой структуры как можно ближе, особенно поначалу, по крайней мере, пока она не войдет в привычку.

И помните, что в работе вы можете добавить нужные поля, касающиеся более специфичных контекстов, в эту структуру