Если рассказывать и о самой работе, которую нужно выполнить с предметами, то в практику придётся добавить дела (activities).
Дело (activity) описывает какую-то работу, которую нужно выполнить -- в практике "забить гвоздь" будут дела "взять молоток", "взять гвоздь", "определить место забивания и нацелить гвоздь", "колотить по шляпке", "проверить прочность соединения", и опционально "выпрямить кривой гвоздь". Обратите внимание, что дела меняют состояния рабочих продуктов (и тем самым -- альф), и что именуем мы дела обычно глаголами.
Эта работа считается выполненной, если выполнен её завершающий критерий (достигнуты указанные состояния альф и уровни детальности рабочих продуктов) -- неважно, достигнут этот критерий упорным трудом команды, или удачно сложившимися обстоятельствами ("полить грядки" будет выполнено либо после полива из лейки, либо после вовремя случившегося дождя -- завершающий критерий будет в терминах контрольного вопроса по состоянию альфы: "почва мокрая"). Важно отметить, что достижение критерия не "объективно": достижение критерия решается командой, которая отвечает на контрольные вопросы.
Дело вполне можно понимать как совокупность предметов, с которыми производятся действия (actions) этого дела. Дело тем самым -- это такой сложный разбросанный в пространстве и протянутый во времени предмет-дело, составленный из отдельных взаимодействующих и взаимоменяющихся предметов-рабочих продуктов (вернее, тех темпоральных частей этих предметов-рабочих продуктов, которые попадают во временнЫе границы этого дела). Действия (actions) -- это по факту отношения участия предметов-альф и рабочих продуктов в деле-как-предмете. Ура, в так понимаемое "дело" можно теперь ткнуть пальцем, погрузить его в тачку, пнуть его ногой -- не забывая при этом, что всё это происходит в какой-то определённый период между событиями начала дела и событием окончания дела, то есть не забывая о том, что с участвующими предметами по ходу дела происходят изменения.
Действия с рабочими продуктами в деле обычно подразумеваются одного из четырёх видов (kind): создать ("create"), ознакомиться (в случае информационных объектов -- читать, "read"), изменить ("update"), уничтожить ("delete"). Тут нужно учесть, что Essence в оригинале -- это про программную инженерию, и эта классификация действий (CRUD) традиционная именно для работы с информацией и данными. Когда же приходится говорить об альфах, то Essence о видах действий стыдливо умалчивает -- kind там это просто текстовая строка, так что такое умолчание вполне возможно.
Практика в её делах только рекомендует действия с предметами, но не требует их. Более того, эти связывающие дело с его предметами действия даже не указывают на то, что для этих предметов нужно достичь каких условий завершения дела. Например, дело "Ретроспектива спринта" (то бишь "разбор полётов") в практике Scrum будет иметь альфу "технология" (way of working -- метод работы, то есть используемый набор практик, в том числе практика Scrum) как предмет для действия "измени" (modify), потому что вполне возможно, что команда решит изменить технологию, базируясь на результатах ретроспективы. Однако, в модели Essence не будет никакого специального отношения, указывающего на то, что "Ретроспектива спринта" будет считаться законченной, если альфа "технология" достигнет определённого состояния -- и поэтому такое состояние "технологии" не будет указано среди критериев завершения. Опять же, дело по мониторингу результативности команды может считаться завершённым, если команда пришла в состояние "распущена" (гусары, молчать!) -- но само дело не подразумевает действий по изменению альфы "команды".
Дела в рамках практики связаны друг с другом отношениями (ActivityAssociations) -- эти отношения не ограничивают завершения дел, но позволяют конструировать из отдельных дел более сложные структуры: задавать их цепочки (последовательности выполнения -- если вид отношений start-before-end, start-before-start, end-before-start, end-before-end), группировать в структуры разбиения работ (activity breakdown structures, если отношение part-of). В любом случае, завершение каждого дела происходит не дожидаясь того, завершатся ли связанные с ним другие дела -- ибо определяется по критерию завершения в терминах состояний предметов, а не выполнения действительной работы (помним про "почва мокрая").
Дела группируются в деятельности (ActivitySpace), при этом одно и то же дело может быть включено в разные деятельности. Общая идея тут такова, что деятельности определяются в дисциплинах и оперируют состояниями альф главным образом, а дела определяются конкретной "технологией", конкретной практикой и они оперируют главным образом рабочими продуктами (хотя стандарт разрешает делам иметь дело и с альфами тоже). Essence рекомендует считать, что деятельности -- это такие абстрактные "пустые места" (placeholders), которые должны заполняться много более конкретными делами из практик. Эти дела из практик, отражают разные подходы к достижению целей деятельности (т.е. к достижению определённых состояний альф), и поэтому сочетаемость дел ограничивается.
Так, дисциплина программной инженерии, прописанная в самом стандарте Essence включает в клиентской области интересов деятельность "исследовать возможности" с критерем завершения "стейкхолдеры::признаны, возможность::определена, возможность::нужно решение, возможность::польза установлена". Как в случае любой дисциплины -- эту деятельность с подобным способом сформулированным критерием завершения можно найти в огромном множестве конкретных проектов, в любых предприятиях, разрабатывающих системы для любых сегментов рынка. Но вот дела, которые будут выполняться в этих деятельностях для достижения указанных состояний альф стейкхолдеров и возможности будут различаться разительно в зависимости от выбранных практик.
Разница в делах поэтому требует и разницы в компетенциях (competence), а часто и уровнях компетенции исполнителя (competency level -- "не мешает, а иногда и поможет", "справится, если за ним приследит кто-то опытный", "мастер: самостоятельно работает", "эксперт: придумывает хитрые новые решения"). Поэтому компетенции с их уровнями привязываются именно к делам.
Для особо продвинутых добавлю, что все проблемы с разницей между "делами", "видами дел", "экземплярами дел" и т.д. я понимаю, равно как и многие другие проблемы. Но разработчики Essence не слишком церемонятся с формальностью описаний, отдавая приоритет понятности в ущерб онтологической точности. Ну, я старался следовать этой же традиции -- а онтологической точности мы добьёмся по итогам ISO 15926 моделирования Essence, которое уже началось. В подходе ISO 15926 (назовём его 4D -- пространственно-временным, ибо все "настоящие предметы" имеют ширину-высоту-длину-протяжённость во времени) к описанию дел их описывать много точней и проще, чем в традиционном "процессном" подходе с 3D предметами (в 3D ведь "движенья нет, сказал мудрец" -- в движение-то как таковое пальцем не ткнёшь, его в тачку не погрузишь, договориться поэтому о границах этого движения и о самом предмете спора представляется очень трудным -- особенно, если ты на предприятии и вокруг нет философов. А вот о предметах договориться очень легко: достаточно ткнуть в предмет пальцем и дать собеседнику его пощупать -- даже если это бумажка, даже если это вывод на экран монитора. Я давно озабочен этой темой -- см. 2007г. http://ailev.livejournal.com/517723.html, 2010г. http://ailev.livejournal.com/867599.html).