Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Category:

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

Алексей Корнилов спрашивает про типичные роли в проекте (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 -- обсуждаются роли потерпевших от проекта, "как это будет сказать по-русски".
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 8 comments