Онтологика ролей в исполнении индивида

Онтологика ролей в исполнении индивида

by Евгений Волков -
Number of replies: 0
Пишет Anatoly Levenchuk (ailev)
2019-11-11 15:14:00

Про типичные роли в проекте, метонимию и конкретность

https://ailev.livejournal.com/1495913.html

Алексей Корнилов спрашивает про типичные роли в проекте (https://www.facebook.com/alx.kornilov/posts/2438413123036909), там уже 129 комментов от самых разных людей. В треде для меня важны два положения из онтологики:
-- не попадаться на метонимии, https://ru.wikipedia.org/wiki/Метонимия (есть исполнитель роли и роль, их не нужно путать -- Принца Гамлета плохо называть Васей Пупкиным, но вот Васю Пупкина часто называют Принцем Гамлетом)
-- чтобы договориться, нужно идти не к абстрактному, а к конкретному в ситуации: роли нужно называть по ситуации, избегая "всеобщности". Минимально абстрактная роль, минимальный класс, а не самый объемлющий из возможных. Роль "человек" для человека мало что проясняет, роль "пользователь" для игры лучше назвать "игрок".

Вот мои ответы в той дискуссии (as is):

Внешние проектные роли каждый раз называются исходя из ситуации -- но я не рекомендую использовать очень общие слова "заказчик", "покупатель", "пользователь". Нужно использовать более специфичные слова (скажем, после запрета на слово "покупатель" в интернет-магазине нашли с клиентской стороны семь разных ролей, которые могли играть шесть разных человек -- ибо парочка ролей всё-таки обычно совмещалась одним человеком, но вот остальные -- не факт).

Поэтому общего ответа тут нет, в каждом проекте нужно думать. И не нужно называть людей общими именами типа "выгодоприобретатель". Если это помощник инвалидам, то там должен быть инвалид (а не общее "выгодоприобретатель"), если уборщик мусора -- то плательщик, дворник, жилец, контролёр (а не "заказчик" или "покупатель робота"). Но и куча других ролей тоже, зависит от детальности рассмотрения ситуации.

[-- инвалид может быть и заказчиком, и плательщиком, а может и не быть. Вот эти базовые типовые представления какие лучше использовать?]
"Инвалид может быть и заказчиком, и плательщиком, а может и не быть" -- это мы разбираем на онтологике. Путаются Иван Иванович (исполнитель ролей) и его роли "инвалид", "плательщик", "заказчик", "муж", "отец", "матерщинник" и т.д.. Это метонимия -- когда мы вдруг Ивана Ивановича называем его ролью "инвалид" и потом говорим, что "инвалид -- это плательщик" (то есть роль -- это роль, имея ввиду исполнителя роли, а не саму роль).

[-- если нет общепринятых, то каждая роль должна быть как-то описана, причём так, чтобы всем участникам проекта было понятно, о чем речь. Поэтому все равно должен быть какой-то общий контекст. Он как задается, при том, что у участников проекта может быть разное образование, разный опыт и пр. ?]
Вообще-то в команде проекта принято обсуждать проект и договариваться, а как иначе? Если не договариваться, то проект сделать невозможно. Если я называю уборщика территории дворником, а кто-то таки уборщиком -- нам нужно договориться, мы про одну роль говорим или таки про разные. Ибо "общепринятые" у меня и у моих собеседников могут быть совершенно разные представления. Поэтому общепринято только договариваться о ролях, добиваться однозначного понимания командой, и признавать, что роли таки разные.

Если у команды похожий опыт, то договариваться будем быстро. Если в команде программисты, железячники, преподаватели средней школы, школьники и пара студентов-гуманитариев, то договариваться будем долго )))

[-- а как тогда быть со стандартами, где эти роли определены? Игнорируем и договариваемся по месту?]
Cтандарты (включая юридические документы) существуют в количестве. На каждый стандарт одной отрасли найдётся пять других стандартов других отраслей или даже той же, на каждый учебник найдётся пять научных статей с другими мнениями от самых авторитетнейших людей, и т.д.. Наличие стандартов это аргумент, но от договаривания в команде не избавляет. Например, команда должна договориться, что использует какой-то определённый стандарт. Но стандарт наверняка не закроет все роли какой-то ситуации. По остальным ролям, не определённым стандартом, придётся таки договариваться.

[-- но мы же не скажем, что "а давайте того, с кем заключён договор на создание приложения, называть «договорщиком», а пользователя, который через него будет делать заказ - «заказчиком»"]
Мы не скажем, а в какой-то команде скажут. И нормально, если будет понятно, какие практики у этих ролей.

Вообще, роли называются по практикам, которые они практикуют. Если инженерная практика -- роль инженер. Если практика закупок (procurement), то закупщик. И так далее.

Но это нужно опять-таки, договориться в команде, что там за практики и как называются их практикующие роли. Мнения тут могут быть разные. Стандарты или учебники тут помогают, но это только аргументы. Чей аргумент сочтётся более адекватным в ситуации проекта -- зависит от команды.

[-- вышесказанное ко всем стейкхолдерам относится?]
Мы не рекомендуем пользоваться термином "стейкхолдер", ибо он таки порождает путаницу: путают исполнителя роли и саму роль. Стейкхолдером и Принца Гамлета легко назвать, и играющего эту роль Васю Пупкина. Васю Пупкина ролью не назовёшь. В учебнике это написано.

[-- предприниматель делает робота для инвалидов, рассчитывая, что роботов будет приобретать и раздавать инвалидам социальная служба. Чтобы договариваться с командой о ролях в проекте, с какого варианта роли для инвалида и для социальной службы начали бы обсуждение?]
Если "инвалид" это роль, то вопрос про роль клиента (роль роли) или пользователя (роль роли) бессмысленный. Иван Петрович -- инвалид (играет роль инвалида, а ещё у него есть роли писатель, отец, инженер). Иван Петрович может быть инвалидом, писателем, отцом и инженером одновременно. Это в треде мы уже разбирали, но использование метонимии (это именно она! в учебнике тоже прописана) продолжается. Этого не нужно делать, от этого как раз проблемы непонимания.

И повторюсь, что роль "пользователь" -- плохая. Ибо непонятно, что пользователь делает, какая его практика. И даже про инвалида мы можем уточнить роль: безногий, или быстроустающий, или какой ещё.

Нужно быть конкретными и избегать обобщений. Обозвать Ивана Петровича исполнителем роли "человек" -- это будет математически правильно, а по сути -- бесполезно. Переобобщение "заказчик/клиент" тут тоже часто бесполезно (ибо есть множество более специфических ролей: заказчик часто разваливается на держателя бюджета, казначея/плательщика, стороны договора/гаранта сделки, трёх разных видов пользователей -- ибо "пользователь" тоже переобобщение, оператора/администратора/наладчика и т.д.),

Так что никаких шаблонов и переобобщений. Тщательное обсуждение для каждого проекта.

ISO42010, например, даёт минимальный состав ролей, который должен быть обсуждён -- и я привожу обычно тамошний список как совершенно недостаточный. Это просто неуклюжий способ авторов стандарта сказать, что ролей много и они не все технические:
The following stakeholders shall be considered and when applicable, identified in the architecture description:
— users of the system;
— operators of the system;
— acquirers of the system;
— owners of the system;
— suppliers of the system;
— developers of the system;
— builders of the system;
— maintainers of the system.

[-- Нет, инвалид - не роль, мы как раз выясняем, в какой он роли! Вот, из перечисленных - он user, operator, acquirer или owner?]
Проблема в онтологике, точной работе с понятиями и отношениями при их более-менее строгой типизации. Инвалид, конечно, роль. А исполнитель роли инвалида (человек) может иметь ещё десяток других ролей -- желательно более конкретных, а не более абстрактных.

Я третий раз уже указываю, что метонимия тут совершенно сбивает с толку -- не разобравшись с тем, что есть роль "инвалид" и есть исполнитель разных ролей "Иван Петрович", мы дальше не двинемся. И ситуацию помощи инвалиду много лучше описывать с использованием роли "инвалид", а не роли "user".

UPDATE: Обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10216738778395879
А вот ещё одна дискуссия про обобщения в ролях: https://www.facebook.com/photo.php?fbid=2440011399543748&set=a.1377271229151109 -- обсуждаются роли потерпевших от проекта, "как это будет сказать по-русски".
 
 
Подписаться на Telegram канал ailev
 
 
грядет еще один стандарт...
Судя по задаваемым вопросам, таки грядёт ))) Вот тут его контуры -- https://www.facebook.com/photo.php?fbid=2440011399543748&set=a.1377271229151109
Да, договариваться надо.

А мне интересно: что если доверить (чисто из любопытства) весь процесс этого договаривания искусственному интеллекту? Не подключая к нему белковые организмы с ограниченными интеллектуальными возможностями? Какими тропами и иными стилистическими средствами эти кремниевые (пока?) мозги будет оперировать? На какой язык перейдут? Или, в конце концов, сведут всё к нулям и единичкам, как это получается у некоторых страстотерпцев из начальной школы?
Боб: Пит, пойдём обедать.
Виртуальный ассистент Боба виртуальному ассистенту Пита: Уважаемый мистер Питер, не соблаговолите ли вы разделить со мной трапезу, прервав ваши неотложные занятия прямо сейчас? С нижайшим поклоном и надеждой на взаимопонимание жду ответа. Искренне ваш, Роберт.
Виртуальный ассистент Пита Питу: Боб зовёт обедать.
Пит: Ага, пару минут.
Виртуальный ассистент Пита виртуальному ассистенту Боба: Уважаемый Роберт, я с удовольствием принимаю ваше приглашение и буду готов буквально через пару минут. Надеюсь, это ожидание не покажется вам долгим, и заранее спасибо за проявленное терпение. Со всем почтением, Питер.
Виртуальный ассистент Боба Бобу: Пит пойдёт на обед через пару минут.

Как-то так )))
) ) )

Но мне кажется, что виртуалы, вслед за своими родителями-программерами, быстренько включат бритву Оккама и перейдут на куда менее ресурсоёмкий русский мат: доходчивей.
Кажется, значительная часть непонимания вызвана вот чем:

Люди тут думают, что роли образуют некое иерархическое разбиение. В корне - Роль, потом все эти стандартные Заказчик-Пользователь-Регулятор, потом Пользователя можно декомпозировать на Игрок-Зритель-Инвалид .... и т.п.

А на самом деле это не так. Роли не образуют никакой иерархии, это просто плоский список. Вот когда роли распределяются по исполнителям - возникает иерархия. Или не возникает )

В Проект1 Заказчик (в смысле роли, подписывающей контракт) - OOO "Аленький цветочек", Инженер по требованиям и Инженер по приёмке - Инжиниринговый центр OOO "Аленький цветочек", Плательщик - бухгалтерия OOO "Аленький цветочек". И тут возникает естественное иерархическое разбиение, знание о котором можно использовать в проекте.

А в Проект2 Заказчик - Министерство бомбостроения, Инженер по требования - ООО "Лютик", выигравшее конкурс на предыдущем этапе разработки, а Плательщик - Казначейство Министерства финансов. И эти лица-исполнители образуют вовсе не иерархию, а более сложную сеть.
Тут сложное сочетание различных классификаторов и/или системных разбиений (тут нужно ещё разбираться, как это моделировать) для ролей. С одной стороны, системный инженер может быть разбит на инженера по требованиям и системного инженера (а если учесть метонимию, то исполнитель роли системный инженер, может быть отклассифицирован более узко как инженер по требованиям или инженер архитектор). Дальше борьба разных тусовок за существование разных стандартных классификаторов и разных стандартных разбиений, удобных для разных целей. С другой стороны, роли и исполнители даны просто списками, а их отношения -- это сложный граф (и нужно ещё договориться, как его моделировать).

Я же утверждаю в дискуссии, что стандарты разбиений ролей или классификации ролей не заданы изначально, допроектно.

Онтология ролей разбиралась Мэтью Вестом когда-то, но там такое 4D, что никому мало не кажется ))) Вот: http://www.matthew-west.org.uk/publications/RolesFOMI2008.pdf -- и ещё не факт, что с ним многие согласятся )))

Но непонимание множественности и непредписанности/нестандартности "из коробки" всяких классификаторов или разбиений -- вот его нет, это да. Нет бумажки -- ты букашка, нет бумажки -- ты не роль )))
Не, этого я не понимаю. С того момента как мы вообще открыли наличие ролей инженера по требованиям и системного архитектора - нет смысла использовать роль системного инженера. Это может быть классификатор для целей какого-то оглавления, или абстрактный класс, не имеющий членов, а имеющий только подклассы. Что и означает плоский список по сути.

1797 words