November 11th, 2019

2019

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

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

lytdybr

Группа "Системного менеджмента и стратегирования" (шестнадцатый поток! третья версия курса!) опять отстала на полдня от графика. Прошлый поток более подробно проходил управление жизненным циклом и управление конфигурацией. А вот эта группа вдруг вернулась к материалу про функциональные объекты, функции, порты и соединения против конструктивных объектов, сервисов, интерфейсов. При этом в материале управления жизненным циклом по этой же линии различали практики и работы. Баек (то бишь "примеров из жизни") было рассказано немерено. Половина группы -- строители. Но есть и парочка "маркетплейсов", и диалоговые AI-боты. Как всегда: одно мышление, помогающее во всех проектах. А ещё час был потрачен на вопрос об управлении вниманием с использованием технических средств -- на примере меня, любимого (основной тезис был: "это не у меня память хорошая, а у Гугля". Ну, и дальше по мелочи -- полторы тысячи заметок в Evernote, почти шесть тысяч записей в "Лабораторном журнале", обсуждение на почти тридцать тысяч моих комментов в ЖЖ и несчитанное количество в фейсбуке и других сетях, и прочие средства помощи коллективному мышлению с моим участиемсо стороны компьютеров и интернета).

Завтра вечером вылетаю в Сочи на корпоративную конференцию, буду там всю среду заниматься системным мышлением в части обеспечения смычки между инженерами и менеджерами (увы, в той тусовке с предпринимателями будет туговато). Участники конференции даже учебник получат бумажный, лишь бы учились. Всё это "государственный бизнес", то есть не бизнес, и поэтому весьма искажённая инженерия (не очень системная). Но учить буду: сегодня тамошние инженеры и менеджеры работают в госкорпорации, но мы не знаем, где они будут работать завтра -- поэтому осмысленно их учить (но не консультировать по их текущим проектам. Именно учить, готовить к реальной инженерии и реальному менеджменту, а не искажённому дармовыми для них деньгами налогоплательщиков). В мировой системной инженерии (и заодно менеджменте), которые быстро-быстро отплывают от государственного финансирования, сейчас идёт выход на принципиально иной уровень сложности: четвёртый запуск одной и той же ракеты Falcon 9 (и второй запуск сохранённого обтекателя), которая вывела на орбиту 60 первых (то есть не экспериментальных, а рабочих) спутников StarLink -- https://www.space.com/spacex-starlink-launch-fourth-rocket-landing-success.html. Эта ракета планируется быть запущенной в космос и в пятый раз -- об этом говорится явно. В середине 2020 сеть StarLink уже планирует начать работу -- и интернет опять существенно поменяется. Вот это -- и бизнес, и инженерия. Про бизнес SpaceX, кстати, читайте вот тут: https://smoliarm.livejournal.com/419187.html (текущее снижение цен на запуск малых спутников силами SpaceX втрое-вчетверо).

Провели методологический семинар по схематизации и рендерингу (обсуждали https://ailev.livejournal.com/1494762.html). Написал длинный протокол в преподский чат. Содержание трёх курсов (онтологики, схематизации, коммуникации) будет в ближайшее время существенно пополнено и доработано. Длительность курсов увеличится. Очень хочется, чтобы состояние курсантов "знакомы с идеями, очень интересно" перешло в состояние "имеем компетенции, используем "на автомате"". Пока же, увы, этим похвастаться не можем. Для интересующихся темой агентности и обучения мышлению рекомендую поглядеть текст про обучение мышлению машинного интеллекта (и я считаю, что это же применимо для обучения мышлению и человеческого интеллекта тоже. Поглядите, там все слова знакомые): https://medium.com/intuitionmachine/an-advanced-capability-maturity-level-for-artificial-general-intelligence-b300dafaca3f. Просвещение переводит людей со ступеньки неосознанной некомпетентности к осознанной некомпетентности. А дальше — образование.

Провели методологический семинар по Айсистенту и blended learning services. Неожиданно тема SysMoLan пересеклась с тематикой RPA (и да, там новости по линии Microsoft -- https://venturebeat.com/2019/11/08/microsoft-has-entered-the-rpa-market-what-does-that-mean/). Текущий RPA состоит из набора коннекторов к софту, набора коннекторов к человеку (все эти распознавания речи), плюс BPM-движка (можно думать, насколько там близко к case management -- они ж себя процессниками считают, и языки там типа CMMN есть, хотя пока выглядит как "голимый недоBPMN"). На чём пишут архитектуру RPA? На диких скриптовых языках довольно низкого уровня, "архитектуры нет, есть коды -- они же документация". Дальше вопрос "адаптивности" как в кейс-менеджменте: если шаблоны пишут программисты, то "просто кейс-менеджмент" (так что RPA сегодня это "просто RPA"). Но если шаблоны пишут непрограммисты, то это будет adaptive RPA. Очередной виток процессного управления. Дальше вопрос: кто пишет на SysMoLan. Если SysMoLan это язык представления знаний (скажем, Common Logic или что-то типа CYC и так далее по линии логических движков), то редкие люди, их в природе единицы. Если SQL (первое же, что предлагают обычно), то герои-админы. Если DSL на Julia, то можно думать об инженерах (но именно что думать). В любом случае, речь в Айсистенте идёт о том, чтобы скриптами (конфигурация -- это код) держать федерирование нескольких разных тяжёлых систем типа той же Teams, корпоративного вебсайта, биллинга и т.д.. В общем, после этой встречи есть о чём подумать. Опять же -- длинный протокол, хотя и не в преподавательской, а в спецчате.

Заодно отладили интерфейс решения задач по системному мышлению. Там решаются программерские проблемы, и я очень надеюсь, что в конце этой недели первая группа из 15 студентов ВШЭ начнёт идти по курсу из учебника-2019 и кейсы-2019 с проверкой. Напомню, постановка задачи была вот тут (и задачи после этого хочется называть кейсами): https://ailev.livejournal.com/1482241.html

Один из побочных выходов посиделки по Айсистенту -- уточнение пары кейсов на один уровень:
Курс
-- решить про курс
-- найти препода
-- подготовить материалы
-- заслушать на семинаре
-- дать анонс (видео)
-- сделать landing page
-- перейти к ЖЦ первого потока
-- менять материалы курса
-- уволить курс

Поток
-- согласовать с преподом курс и время
-- дать объяву на сайт + вставить в расписание
-- начать сбор заявок ("объявить набор")
-- в день X принять решение о старте потока (ибо может быть недобор, или может быть перебор, тогда запустить набор на новый поток, а этот продолжить)
-- оформить договора и оплаты
-- прогнать через онлайн курс (учебник+задачник)
-- дать доступ к материалам курса (библиотека+слайды. Слайды могут быть к каждому дню "оперативно", а не сразу)
-- завести списк курсантов потока
-- завести для курсантов чат потока
-- завести репо для материалов потока
-- зарезервировать аудиторию (возможны пересечения с другими курсами)
-- вести занятия потока (координация через чат): использовать аудиторию и дистант (сейчас ZOOM)
-- снимать и публиковать видео только для потока
-- проверять домашние задания в репо
-- провести защиту
-- выписать сертификаты
-- занести курсантов потока в чат выпускников (закрытая коммуникация)
-- занести курсантов потока в список выпускников (у них будут скидки)
-- занести курсантов потока в комьюнити выпускников (фейсбук, открытая коммуникация)
Опубликовали первое видео наших курсантов социального мультиданса: https://vk.com/wall-179019873_373. В группе много выпускников курсов ШСМ, а на видео есть два профи -- сможете их отличить от начинашек в танцах? Методика работает, ускорение обучения социальным танцам получается в разы по сравнению с традиционным способом, я очень доволен. Чему мы учили целый месяц эту группу, сформулировано вот тут: https://vk.com/wall-179019873_372. А ещё получили развёрнутую правильную рецензию от приезжавшей к нам на пару дней Елены Унру из Питера (и там фотография меня, изображающего непослушную партнёршу): https://vk.com/wall-170497991_610. Правильность рецензии в том, что про социальные танцы нужно именно так и писать: про ощущения в паре, а не про внешние формы. Из забавного: использовал свежую разработку MIT по равновесию двуногих роботов для разговора о равновесии в социальных танцах -- https://vk.com/wall-179019873_374. А вот и я попал на видео танцующим -- на вечеринке Ностальжи Кизомба в эту субботу: https://vk.com/video40271596_456239303. И ещё один мой текст: про удовольствие в социальных танцах -- https://vk.com/wall-179019873_367.

НИУ ВШЭ опять отличилась в казарменную сторону: меня не пустили на факультет компьютерных наук с самокатом -- даже с самокатом в руках (весит-то он всего 4.2кг). Это вообще первый случай, когда меня не пустили куда-то с самокатом (а уж в каких только офисах, вузах, предприятиях или клубах я ни побывал с самокатом за последних пятнадцать моих самокатных лет!), предложили оставить самокат на уличной стоянке для велосипедов и самокатов. А у меня даже цепи для него нет, это ж ручная кладь по габаритам и весу. Конечно, все дурацкие запреты были обойдены -- сел в местную преподскую машину вместе с самокатом, и въехал на машине прямо на тамошнюю подземную стоянку. В машине же можно провозить хоть пулемёт. Но вот самокат приравнивать к пулемёту -- это что-то новенькое. У меня уважение к НИУ ВШЭ после последних тамошних политических подвигов и так было не очень, но упало почти до нуля. В казарме наука не живёт, она чахнет и умирает.

Блюдо недели -- тыквенная запеканка из Пан Запекан (при этом тыква на вкус там не обнаруживается ни мной, ни другими людьми -- проверено. Но очень вкусно). Я пришёл туда целевым визитом (у меня их точка на Октябрьской в самокатной доступности, прицелился и назначил там встречу-обед), не рассчитал вес-объём, и взял 0.7кг разных запеканок. Едва осилил, под 0.4л латте. Правильное место, я такие люблю: показываешь пищу пальцем и немедленно её получаешь, а не тыкаешь в фотографию из меню и потом ждёшь сюрпризов.