Конференция #AnalystDays прошла на праздниках в Питере. Это был дважды юбилей: 15-я конференция и 10 лет с первой, которая прошла весной 2012 года в Минске. Как обычно был хороший уровень докладов и много общения в кулуарах.

Из общения в кулуарах я хочу отметить несколько тем, мне кажется, они будут интересны и за рамками конкретного разговора. Во-первых, люди рассказывали кейс: взяли начинающего аналитика, работает и учится уже полтора года, а эффекта - нет, человек - старательный, документы делает, но - не понимает содержания, формально. У меня тут возникла гипотеза, что у человека не поставлено мышление моделями, он мыслит просто текстами, умея их преобразовывать по аналогии, но не восстанавливая картину мира - объекты, отношения между ними и так далее. Предполагается, что такое умение есть у всех, у кого-то лучше, а у кого-то хуже. Оказывается, это не так, Прапион Медведева, рассказывая весной на конференции Школы системного менеджмента об опыте своего курса Онтологика и коммуникация привела статистику: примерно у 20% приходящих на курс такое умение, она его называет "машинка типов" - отсутствует, при этом прокачан навык коммуникации, который позволяет жить без этого, а у 30% наоборот, машинка типов хорошая, а коммуникации нет совсем. У остальных есть и то и другое, но в недостаточном виде - курс помогает развитию. За подробностями отсылаю к своему отчету.

Вторая тема касается ситуации, в которых сейчас оказался ряд крупных предприятий и корпораций. У них автоматизация базировалась на зарубежном софте, обычно основой ERP был SAP, который дополнялся BI-решениями. Выбрали они это давно. И у них были подрядчики, дружественные разработчики или интеграторы, специализирующиеся именно на используемых решениях, которым передавались задачи автоматизации - что вполне логично для такой ситуации. Это был налаженный процесс. А сейчас вдруг оказывается, что им надо искать решения на других платформах. Установленный на предприятии SAP работает, отвалилось только облако, но новые проекты на нем делать невозможно, да и дорабатывать существующее можно лишь ограничено. При этом у предприятий были планы по дальнейшей автоматизации и даже цифровой трансформации. И теперь требуется научиться выбирать платформы для решений, выбирать подрядчиков, которые их сделают, а для этого - формулировать требования "с нуля", без предположения о решении. Когда вы делаете требования для SAP, вы ведь спрашиваете, а что SAP предлагает в конкретном месте и по сути выбираете из нескольких стандартных вариантов с ограниченными доработками, а тут ситуация иная. И, в общем, это довольно сложная ситуация для предприятия, надо вырастить ИТ-службу иного уровня, чем существующая.

Еще одна тема - профстандарты. Ирина Гертовская рассказывала о подготовке профстандарта системного аналитика. Подробности - в конспекте, а здесь я хочу сказать о профстандартах в целом. Профстандарты готовит Минтруда для того, чтобы с их помощью поставить задачу перед ВУЗами по подготовке специалистов, и он запустил очередной цикл пересмотров по ИТ, предыдущий был в 2013-2014. Пересмотр касается не только системного аналитика - пересматривают Бизнес-аналитик, "Специалист по ИС" (Создание (модификация) и сопровождение информационных систем), Руководитель проектов в области ИТ и Администратор БД. Уже вышел Программист (и это отличается от Специалист по ИС). В 2021 вышел стандарт Архитектор ПО, Менеджер продуктов в ИТ, Менеджер по ИТ, Тестировщик (специалист по тестированию) в 2020 - Специалист по техподдержке, Специалист по большим данным, Специалист по дизайну графических интерфейсов. И наверняка другие - в реестре нет года обновления стандарта. Смотреть профстандарты здесь: общий список (выбрать 06 ИТ) и реестры уведомлений, проектов стандартов там нет. При этом Бизнес-аналитик - в финансах и экономике, не ИТ-шный.

Надо отметить, что задача подготовки специалистов понятная, только решается в старой логике, когда подготовили человека по профессии, например, сварщика - и он всю жизнь по ней работает, и деление между профессиями - жесткое. В то время как специализации в ИТ развиваются и смешиваются очень быстро, и это, наверное, нужно учитывать, не взирая на то, что в старую картину это нарушает. А еще разработчики стандартов смотрят шире, желая не только поставить задачу перед ВУЗами, но и сделать некоторый общий стандарт разделения труда и специализаций в отрасли. Что также невозможно ввиду высокой динамики. В этом смысле более перспективен подход SFIA, которая выделяет 200+ специализаций, предлагая позиции набирать в виде их комбинаций.

Ну и в заключении общей части я хочу отметить удачный подбор музыки на афтерпати, благодаря чему получился живой танцпол, а не стоящий на месте зрительный зал. При этом разговаривать за столиками музыка не мешала, и это - тоже достижение. А еще у конференции прикольный талисман - Чебурашка-девочка, что бы там не говорили организаторы, будто в замысле это принцесса Лея. Импортозамещение в действии!

Ну а теперь - о докладах. Я, как обычно публиковал заметки в ходе конференции, теперь - у себя в телеграм-канале, а не на FB, и некоторые из них вызвали обсуждение в комментариях, которые я тоже включу в отчет. Особенно хочу отметить доклад Антона Семенченко про когнитивное здоровье, Ольги Ботневой про эмоциональный интеллект и Николая Соколовского про описание сложной бизнес-логики через формальные правила. Но при этом напомню, что я мог быть на одном из докладов каждого слота при том, что в первый день на конференции было три трека, а во второй - четыре, так что отчет явно не полон.

Начну я со своего доклада Статусы документов: нажатие кнопки и реальные действия . Он был посвящен следующей проблеме: очень часто запросы на доработку формулируются в терминах изменения системы, например, добавьте статус документа или поле или кнопку на форме. Этот запрос выполняют, а оказывается, что новую функциональность невозможно применить, потому что люди, которые так формулировали запрос, забыли о том реальном процессе, который отражает workflow документа. И пользователь, который работает с формой - не может это поле заполнить, потому что у него нет нужной информации. А новый статус требует иной организации процесса, а не просто изменений в документе. В выступлении была общая картина и примеры конкретных ситуаций. А общий посыл: всегда помните не только об уровне работы системы, но и об уровне деятельности, процессов, которые в этой системе отражаются.

У Антона уже было несколько докладов, подготовленных вместе с профессиональным психиатром, знакомящих с психологическими моделями в разных аспектах. В этом докладе речь шла про когнитивные функции и интеллект. При этом Антон не просто рассказывает модели, он их приземляет на материал ИТ, работу аналитика. Например, все знают, что у человека есть бессознательное. Но проводя интервью аналитики обычно не задаются вопросами, действительно ли заказчик не знает ответа на какой-то вопрос или не владеет ситуацией, или у него это знание есть, только в бессознательной области, и он осознанно или неосознанно предпринимает усилия, чтобы вы тоже не поняли истинную ситуацию. Неявно предполагается, что аналитики работают в поле рационального мышления и в эти вопросы не погружаются. Хотя понимание таких аспектов может быть полезно.

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

Измерение интеллекта. Тест Векслера IQ - плохая метрика лучше отсутствия. Используется в судебной медицине. <70 - умственно отсталый и ограниченно вменяемый, от 100 умный, от 120 очень умный, а вот от 140 - слишком умный, обычно есть проблемы в адаптации и социализации.

Про бессознательное. Тут надо понимать, что есть ряд теорий бессознательного, которые по-разному его объясняют.

• Есть теория непрерывности сознания, идет от Лейбница и Сеченова.
• Другая крайность - бессознательное как нечто отличное от сознания, это Гартман, Шопенгауэр.
• Дюркгейм. Сознание как способ приспособления к среде. Есть биологическая сущность и социальная сущность, они противоречат.
• Бессознательное по Фрейду и далее - Юнгу. Биологические инстинкты, желания, чувства, аффекты. Предсознание - волевая регуляция.

В зависимости от используемой теории ответ на вопрос, действительно ли заказчик не знает ответа на ваши вопросы или скрывает их в бессознательном, и что вам с этим делать, будет разным.

Переход количества в в качества - появление сознания в ходе эволюции у животных. Муравьи со своим языком, передача сигналов, счет до 58. Гориллы обучаются до уровня 6-8 летнего ребенка. Характер, психотравмы и так далее. И у хомячков, не говоря о крысах.

Современное представление: сознания и бессознательное в гармоничном единстве. Сфера ясного сознания невелика.

Ощущение и восприятие. Сенсорная депривация и стимуляция у детей связаны с психическим развитием. Интонации и невербалика.

• Американские эксперименты на детях с лишением привычного потока сенсорной информации. Или с монотонным общением - это мама-психиатр над своим ребенком издевалась.
• Эксперименты на африканских детях. Оказывается, они более развиты до некоторого момента, чем европейские - потому что они всегда с родителями, их всюду таскают. И это дает больше, чем целенаправленное развитие в специальных условиях, но с ограниченным контактом с миром. Позднее картина меняется - потому как целенаправленное обучение все-таки срабатывает.

Мышление. Абстрагирование, Объектно-Ориентированное программирование. Восприятие картинок, абстрактный стол. Есть первобытные племена, где оно слабо развито - не было нужно. Не стоит удивляться, если у Заказчика не развито абстрагирование.

Я тут отмечу, что дихотомия Сенсорик - Интуит Майерс-Бриггс по сути меряет уровень абстрактного мышления и частоту его использования по сравнению с мозаичным мышлением из отдельных деталей.

Мышление.

• Цель мышления - вывод ответа, решение задач. Проверка гипотез. Этим занимается когнитивная система и в ней есть баги.
• Методы: Обобщение, Классификация, Абстракция.
• Виды: Предметно-действенное - до 3 лет. Наглядно-образное - может быть сложное, но очень сложно ложится на алгоритмизацию. Словесно-логическое или понятийное. Два полушария, фокусировка одного на наглядно-образном, другое на словесно-логическим.

Конкретное мышление: не понимают метафоры типа золотые руки, светлая голова, черное сердце. Вопросы что тяжелее килограмм пуха или килограмм железа; что быстрее - птица или самолет.

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

Разговор с уточкой. Объясняешь другому - и наконец-то сам понимаешь.

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

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

Эффект Зейгарник. Заканчивайте на самом интересном месте.

Рекомендации

• учить язык каждый день 5-10 минут, читать по 5 страниц дважды каждый день
• магическое число 7+-2. Задача Эйнштейна, решить без бумаги - потому что надо держать много сущностей.
• Инженерные практики: цикломатическая сложность (7-9), количество реализуемых интерфейсов (5), количество методов до 9, глубина наследования до 5 - чтобы все это помещалось в голову.

Виды памяти - двигательная, образная, эмоциональная и так далее. Рекомендация для запоминания - мелкая моторика, доски и маркеры, механическая клавиатура, беседа с уточкой, организация офиса (дартс, пинг-понг, турник, xbox). Виды внимания: непроизвольное, произвольное-волевое, послепроизвольное...

Follow ups - необходимость, иначе мысли размазываются и несфокусированные. Не только по встречам и созвонам, но и обсуждению с чатиками. Потому что когнитивные искажения, несосредоточенное внимание.

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

Рассказ про способ формальной записи развивающихся и усложняющихся правил. Которые начинаются с простой формулировки "Заявка может быть закрыта автором или исполнителем", а дальше добавляются новые роли, статусы (Отклонена), особые заявки, отметки на заявке и так далее, и текстовые формулировки становятся запутанными, а на трактовку влияют знаки препинания, что ведет к ошибкам. Это Decision Making Notation записи в виде табличек условий и заключений, столбцы условия объединяются по И, строки - по ИЛИ. Есть две визуализации, одна из 4 элементов: Входные данные, Решение, Бизнес-знания, Источник знаний, во второй погружаешься внутрь: Правила декомпозируются через Условия, они объединены в Семейства и Модели. Но основное - таблички, и фишка в том что бизнес такие таблички понимает и готов обсуждать и заполнять после 10 минут инструктажа. А по реализации - есть много движков, и можно написать свой, интерпретация довольно простая.

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

Достоинства - позволяют управлять большими наборами правил, 500+ выживают, можно увидеть зависимости, облегчают декомпозицию и управление. Сочетаются с BPMN. Автоматизация. Малый порог входа, бизнес понимает, включая финансистов и HR. Недостатки тоже понятны: еще одна нотация, слишком сложно для простых случаев. Требует аккуратного обращения с терминологией. Сложно описывать случаи, которых не было, но тут помогает сказать "ну, а пусть ошиблись - что система должна делать". Сложно согласовывать, когда декомпозиция не совпадает с границами ответственности - учитывайте их.

Для начала я хочу заметить, что название "ресурсный менеджер" для меня имеет резко отрицательную коннотацию отношения к людям как к заменяемым деталям в машине выполнения бизнес-процессов, с исключением личного отношения. У Екатерины этого отношения нет, да и в современном ИТ это невозможно, хотя лет 10-15 назад для крупных компаний было практически нормой. Но вот название должности у них в компании - осталось, и, наверное, внутри коннотаций не несет. Интересно, как это воспринимают другие участники. Может быть, оно и для других уже не несет таких коннотаций, получило новый смысл. А может, люди просто не задумываются, что на самом деле значит относиться к людям как к заменяемым ресурсам в машине бизнеса.

Ну а теперь - про содержание. Речь идет о позиции в профессионального руководителя при матричной организации, когда аналитики, разработчики, тестировщики работают в командах, задачи командам ставит продукт или проджект. И при этом специализации объединены в функциональные отделы, руководители которых решают задачи профессионального роста, дают обратную связь, найма, определения квалификации и зарплат, включая бюджеты, обучения и поддержки, решает конфликты с менеджером проекта, а также распределения аналитиков между проектами, именно с ними об этом договариваются менеджеры проектов. Аналитиков много, поэтому структура двухуровневая: есть тимлиды аналитиков, над которыми ресурсный менеджер. У нее 20 аналитиков. При этом ресурсный менеджер - 50%, вторая половина - ведущий аналитик в проекте. И нужен баланс между этими активностями. Ресурсный менеджер - супергерой, супергерои не могут выстроить день и не успевают на свою свадьбу. А по работе аналитика в проекте нужна предсказуемость.

Дальше было детальное раскрытие работы. С кем работает?

• про людей: аналитики, HR-менеджеры;
• про бизнес: руководители направлений и владельцы продуктов - чтобы понять перспективные направления развития и потребности, финансовый директор - зарплаты и бюджеты;
• менеджеры продуктов и проектов - на стыке бизнеса и людей.

Дальше нагрузка по задачам, для ее ситуации с группой 20 человек

• Раз в год бюджет делаешь группы, и когда делаешь - большое погружение
• Мониторинг группы каждые полгода, подведение итогов
• итоги работы за квартал по группе, премии
• встречи с руководителем проекта и продукта 2 раза в месяц, планирование кто где работает
• встречи с HR-менеджером
• ведение ресурсного плана: сотрудники против проектов со сроками, чтобы во-время отслеживать изменения ситуацию
• встреча 1:1 с каждым аналитиком, 1-2 раза в месяц с каждым, отслеживание наставничества

Проблемы первого года работы, по убыванию. Хотя сортировка для нее не очевидна, но опрос дал именно ее.

• увольнение сотрудника
• негативная обратная связь
• бюджет (там же нужен прогноз премий и зарплат на год)
• зарплата и премии
• удержание сотрудника
• найм нового сотрудника
• подведение итогов сотрудника

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

Как стать ресурсным менеджером? Для начала проверьте возможность, в вашей компании могут считать, что только проджект может стать, у них там было, потом компания выросла и требование отпало. Затем поговорить с руководителем, наметить план: рост до ведущего, пройти доп.обучение, начать работу с группой.

На этом все. И мне тут пришла вот какая мысль. Опыт Google говорит, что хорошие тимлиды получаются из средних, а не из ведущих разработчиков - ведущим это не интересно. Но тут - функциональное руководство и профессиональный рост, может действительно надо быть ведущим? С другой стороны, помимо роста тут куча административной работы, которая не слишком интересна ведущим. В общем, это может быть реликт старого традиционного подхода.

Мое замечание про термин "ресурсный менеджер" вызвало обсуждение в телеграм.

Denis Beskov Максим, ресурсом в это модели и риторике является время людей с определенной квалификацией, а не люди как таковые

mtsepkov. Да-да, в риторике ресурсного планирования ты берешь и распределяешь время людей, и не думаешь при этом о них как о людях, которым не все равно чем заниматься, у которых есть личное отношение к проекту и так далее. Людей нет - есть ресурсы. При этом в докладе было совершенно другое содержание, и это понятно.

Denis Beskov. Смотри, тут как выглядит

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

Но заказчикам работ это в общем случае не очень интересно. Вот тебе интересны мотивы, модель компетенций, план развития электрика, которого ты вызвал починить люстру?

Denis Beskov. Можно назвать это Capacity Management, Capability Management, Function Management, Performance Management, Talent Management, но содержательной разницы не будет

mtsepkov. Тут сложнее. Заказчику действительно не очень важно, какие именно люди будут делать проект, ему важно, чтобы они были квалифицированны и мотивированы, подходили проекту. С менеджером проекта уже не так: без понимания мотивации людей, составляющих команду, возникают риски пробуксовки с отдельными задачами в разных видах, включая перфекционизм и оверинжиниринг по каким-то аспектам работы. В реальной жизни команда всегда не идеальна, с особенностями и их надо знать - при том, что за ход операционных работ отвечает менеджер проекта. Ну и про то, что нельзя выделять людей без учета их особенностей - все верно.

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

Очень интересный доклад. Для начала была история про Марти Макфлая, герой трилогии "Назад в будущее". Он принимал решение под воздействием оценок других людей, провокаций. Но однажды сообразил: не надо так делать. Марти в этот момент включил эмоциональный интеллект, понял, что ожидают от него люди, вызывая определенные чувства, и перестал идти на поводу у манипуляторов.

Дальше был теоретический минимум. Эмоциональный интеллект - умение понимать эмоции других и, прежде сего, свои собственные: сначала надень маску на себя. Группы способностей: управление эмоциями (осознаем и контролируем), распознавание эмоций, использование эмоций (направляем эмоции на поддержку деятельности), понимание эмоций. Элементы эмоционального интеллекта - большой список: эмоциональное самосознание и самоконтроль, ориентация на результат, эмпатия и так далее. Помогает: общаться, настраивать отношения, стимулировать людей.

Мифы

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

А дальше была самая интересная часть доклада. Ольга при подготовке провела исследование, опрос про боли аналитиков и способах, которыми они с этими болями справляются. И предложила те способы, которые в этих областях дадут методы эмоционального интеллекта. Это интересно не только с точки зрения методов эмоционального интеллекта, но и с точки зрения практик, которые люди применяют.

Проблемы понятные. Тяжело в коммуникациях: играть в принятые игры, общаться с малознакомыми, отсутствие коммуникаций в командах, отсутствие обратной связи, противостояние давлению и манипуляциям. Тяжело в самоощущениях: демонстрация неготовой функциональности, критика, ответственность за других; рутина и отсутствие творчества; сохранение лица в бесконечной коммуникации. ЭИ учит распознавать манипуляцию, сознательное вызывание эмоций, помогает понимать игры и включаться в них в игровой позиции без эмоционального накала, рекомендует составлять планы для общения повышение комфортности общения и так далее.

Про восстановление после авралов в презентации было много способов, которые аналитик применяют. А ЭИ говорит, что у нас есть 4 вида энергии: физическая, эмоциональная, интеллектуальная, духовная; надо понимать где дефицит, и для каждого вида есть свои рекомендации.

Деление энергии на физическую, эмоциональную, интеллектуальную, духовную вызвало обсуждение в телегам, Ольга прислала ссылку на источник

Дмитрий Калашников. А что понимается под духовной? И в чём отличие от эмоциональной?

Olga Botneva. Духовная - это про благодарность другим, себе, прошедшему дню за что-то, например, добрые дела, ощущение своё миссии на Земле. Эмоциональная энергия - больше про возможность выражать чувства, разные (как гнев, так и радость и прочее).

Дмитрий Калашников. Как-то не очень по-научному звучит, извините :) Все прочие сферы вполне определяются наукой, везде понятны их границы: мышцы, психика, интеллект. Но вот духовность — какой-то нью-эйдж.

Olga Botneva. Эмоциональный интеллект сам по себе нью-эйдж ☺😅. Он затрагивает не только научное. Извинения излишни, мне повод на подробно разобраться.

Дмитрий Калашников. Ну не совсем. Эмоции вполне описаны наукой, там понятны почти все механизмы. А вот как вы, например, нейрофизиологам будете про духовную сферу рассказывать, я не знаю. Скорее всего заклюют :)

Olga Botneva. Не пойду к ним тогда, спасибо, что предупредили 😎

mtsepkov. А есть какие-нибудь ссылки на более развернутое описание всех четырех видов энергии? Потому что быстрый поиск по эмоциональному интеллекту этой классификации не нашел. В то же время Гоулман в своей книге о духовных ресурсах говорит (это тоже быстрый поиск, детали не смотрел).

mtsepkov. Тут надо приземлять на конкретные механизмы, нейрофизиологию смотреть на их уровне. Анна Обухова (а она нейрофизиолог по одному из своих высших образований, получала в Штатах) механизмы благодарности, механизмы значимости и осмысленности дела, которым занимаешься. рассматривает, и показывает, как с их помощью можно снимать блокировку поступления дофамина в кору, которую инициирует стресс. То есть сначала смотрим на механизмы и их наличие, а потом - на разумность именно такой группировки в 4 класса. А что психология современную нейрофизиологию в себя не включила, не осмыслила - тут я согласен.

mtsepkov. Ольга прислала ссылку на источник, которым она пользовалась для классификации энергий. Это "Жизнь на полной мощности" Джима Лоэра и Тони Шварца. Почитать обзор можно, например, здесь https://biz360.ru/materials/zhizn-na-polnoy-moshchnosti/ Это действительно не научная работа, но с точки зрения прикладной психологии там достаточно понятная классификация. Это я сужу по опубликованному summary книги, на которую ссылка.

Дмитрий Калашников. Спасибо, Максим! Да, я читал саммари на книгу ещё в том году, помню.

Видение описывает бизнес-требования к системе, цели, задачи, критерии успеха, ограничения. Надо не просто понять, а задокументировать и согласовать. Оно согласует ожидания заказчика с нашими намерениями, позволяет далее управлять ожиданиями и сравнивать фактическое продвижение с видением. Хорошее видение дает мотивацию команды. И дальше был рассказ, как его делать.

Понятные фазы

• Подготовка: шаблоны и примеры, чек-лист с вопросами, первый раунд заполнения по фазе пресейла, определение лакун
• Создание: циклично, с постоянной обратной связью и командной работой
• Финализация и утверждение, распространение и актуализация

Содержание

• Предпосылки и контекст - кто клиент; почему хочет инициировать проект; особенности ситуации компании-клиента; специфика и тренды индустрии
• Заинтересованные лица: клиент, мы, третьи стороны (консультанты). Уровни вовлеченности, области ответственности. Перепроверять, что не упустили, встречаемся лично, не забывайте тех, кто негативно настроен. Не все публично.
• Целевая аудитория (пользователи): узкая или широкая, прямая или косвенная, ядро ЦА, боли и проблемы, персоны. Частая ситуация: "сейчас делаем для себя, а потом будем продавать". А еще "не ходите к финансистам, у них сейчас отчеты." интересы пользователей и стейкхолдеров часто отличаться и даже противоречат: пользователи сайта знакомств хотят найти половину и не ходить, а стейкхолдеры - чтобы вечно искали.
• Описание проблемы: выясняем, спрашиваем текущие решения, ставим приоритеты. Аккуратнее с формулировками, это бывает чувствительно. Не забываем про цели. Помним, что озвучивают субъективное мнение, а не объективные факты.
• Цели, задачи и критерии успеха. Выясняем и формулируем цели, описываем измеримые задачи, расставляем приоритеты. Очень часто тут нет конкретики. Можно предложить, но надо себя не загнать в них.
• Границы проекта. В целом и MVP, приоритеты. Сочетаем визуализация и текстовое представление. Стараемся уменьшить MVP.
• Риски, зависимости, допущения. Все, что успеем выяснить - записываем. Зависимости и допущения часто переходят в риски. Привлекаем всю команду.
• Ограничения. Стоимость: бюджет, скрытые затраты (лицензии и т.п.), неучтенные ожидания. Время: дедлайн, особые даты и события. Границы: MVP, особые сценарии, нефункциональные требования.
• Что еще: маркетинговые исследования, внутренняя статистика, процессы AsIs и ToBe, требования к переходу, макеты, оценки трудозатрат и так далее - уровень подготовки проекта может быть разным.

Рекомендации.

• Стараемся понять и описать видение до того, как займемся деталями реализации. Не всегда работает, заказчику может быть все ясно.
• Адаптируем размер и содержание под специфику проекта
• Визуализируем и презентуем. Документы не читают, поэтому сделайте презентацию с важным.
• Доносим до команды. Не просто отдаем ей готовые документы и другие результаты, рассказываем. И потом тоже взаимодействуем, даже если ушли на другой проект.
• Следим за актуальностью. Сверяемся в ходе разработке проекта.

Обсуждение в телеграм.

Дмитрий Калашников. Кажется, это все уже давно неплохо описывает OMG Essence. Зачем изобретать велосипед?

mtsepkov. OMG Essence - он про альфы и ведение проекта. А здесь в докладе - шаблон оглавления vision из собственного опыта. Местами - более подробный, а какие-то альфы (team и technology) отсутствуют. Но можно взять и пользоваться.

Mike Spencer. Выглядит как инструмент (фреймворк), который сам по себе не приводит к успеху проекта, а лишь задаёт направление, т.е. не решает поставленную проблему. Если увидеть заранее, где находится университет, срок написания диплома не изменится.

mtsepkov. Да, это про первый шаг - написать vision. Просто его не везде делают, хотя во всех методологиях vision или аналог - нужен.

Mike Spencer. Лучше его не сделать, чем сделать плохо на коленке. Видел кейсы, где вижн делали и защищали, а затем получалось, что не учли кучу рисков и ошиблись с допущениями, но руководство помнит красивую картинку из vision, что приводит к ужасным последствиям

mtsepkov. Это сложный вопрос. Если заказчик знает, зачем ему проект, а команда исполнителя это не знает, то велик риск того, что они сделают не то, что нужно и это жестко вылезет при сдаче. Еще отсутствие вижна порождает риск, что разным стейкхолдерам проект нужен для разного, и это вскрывается в ходе разработке или при сдаче проекта.

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

Так что я думаю, что вижн лучше, чем его отсутствие - плохо подумать лучше, чем не думать вообще. Но есть еще две ситуации.

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

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

• Фазы понятные: планирование, проектирование, создание-получение, хранение-обслуживание-архивирование, использование. Но потоки данных - меняются, хранение - деформируется.
• Фокусы: осмысленность данных, выгода использования. Доступность в условиях изменчивости. Масштабируемость. Качественность, доверие данным. Безопасность данных. Температура данных - частота обращения.
• Виды данных: Small (обычные БД), Big (с ними просто не получится), Smart (информативные данные, Fast (выявление Smart в Big, Темные (это что мы не знаем).
• Деление по хранению: Широкие (много колонок) Длинные (много строк).
• Сегментирование - партиционирование - шардирование: деление больших данных на группы.
• Виртуализация данных: они лежат везде, 60-70источников - обычная история, идея - промежуточный уровень для абстрагирование от изменений в конкретных источниках.
• Качество данных. Тут много характеристик, было 4, теперь 20.
• Безопасность: генерация, маскирование, шифрование. Маскирование всегда необратимо, а отличие от шифрования, при этом маскирование может быть частичным.
• Обогащение данных. Это не только дополнение, это еще удаление ненужных данных, маскирование для увеличения доступности.

Есть много способов вести заметки, которые превращаются в базу знаний: OneNote, EverNote, Notion. Но у первых двух нет ссылок между заметками, Notion - попробовали решить ссылки через Базу данных, но там все сложно. А главное у них проплиетарное хранение в облаке, и если что - ваша база данных у вас пропала.

Obsidian - markdown в тестовых файлах. Структура - папки. Механизм шаблонов, за счет которого быстро делаем страницу. Например, хотим описывать книги - делаем шаблон "цитата" - там текст, ссылка на источник, свои мысли. И описание книги - тоже шаблон с автором, идеями и так далее. Markdown позволяет делать ссылки - и obsidian умеет рисовать граф ссылок между статьями. При этом граф можно фильтровать.

Obsidian позволяет подключать внешние плагины. Есть плагин, который формирует таблицы по заметкам. Например, если вы делали заметки по книгам - то можно делать разные списки книг. Plugin Calendar. Плагинов много, они пополняются. Поддерживает JScript и Closure - и можно делать запросы и визуализировать по-своему.

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

Еще надо отметить следующее. Есть методология ведения заметок Zettelkasten, и Obsidian ее поддерживает. Но он эту методологию не использует, потому что при следовании ей получается нечитаемый каталог. Он предпочитает самому формировать структуру каталогов и использовать механизм шаблонов.

Обзорный доклад про особенности разработки продуктов. Много интересного, часть слайдов - для подробного разглядывания и гугления, их проскакивали в рассказе.

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

• Каждый шаг - деньги - нужно основание
• лучшее основание - валидные цифровые данные
• решение исполнено - надо оценить результат
• лучшее оценка исполнения - рост цифр
• Decision Execution Management - DXM - это очень дорого
• Минутки и заметки со встреч - DXM на минималках

Главное перестроение мышления: все что приходит в голову ему или продукту - это гипотеза. Поэтому не надо бросаться делать, надо остановиться и сказать: с чего бы это? Каждая гипотеза распадается на три: гипотеза проблемы (у пользователя есть проблема), гипотеза решения (решает проблему), гипотеза ценности (решение ценно пользователю, он готов платить). Много людей восторгаются продуктами и фичами, но платить за них не готовы.

В докладе фокус на гипотезе решения. Распадается на две: What (какую фичу реализуем) и How (как ее реализуем).

• What. Часто очевидные шаги, то что есть у конкурентов - не аргумент, большие рискованные шаги. Но быстро понятно, когда идете не туда.
• How - можно сделать по-разному, формально и просто, либо большой проработкой пользовательского опыта. Это влияет на имидж продукта. И они дают кумулятивный эффект. Аналитик тут может помогать и подсвечивать слепые зоны. У него mindset копать в детали даже простую фичу и из-за этого могут не попадать в сроки.

Три доминанты в каждой команде: продукт (много счастливых пользователей), проджект (сроки и бюджет) и техлид (техническое совершенство и отсутствие рисков). Иногда их совмещает один человек, но это - разные пласты, и они плохо сочетаются. Аналитик должен видеть майндсеты, их соответствие позициям и напоминать.

Контексты решений

• Активности продукта: поиск, проектирование, разработка и поставка, развитие
• Жизненный цикл разработки: анализ, дизайн, разработка, релиз, поставка, эксплуатация. И мониторинг
• Жизненный цикл продукта

SWOT-анализ и PESTEL. Делаются, но игнорируются, и потому делаются поверхностно. Когда наняли продукта, решение о стартапе принято. Хотя это была гипотеза, и ее стоит проверять. Но для этого от продукта нужна смелость. И надо копать в недостатки и Угрозы, Преимущества и Возможности Продукт прокапает сам.

Product Vision как артефакт. Нужно для решения о деньгах. Надо собрать основания. На слайде - конкретное содержание, 10 пунктов, включая Lean canvas.

CJM и USM.

• На действующем продукте строим CJM - продукт есть. И вокруг него USM, выделяя активности и провалы.
• На стадии стартапа наоборот, строим USM, и дальше на основе опросов пользователи конкурирующего продукта делаем CJM.

Основной источник фич - USM. Но дальше надо позиционировать фичи, с учетом реализации конкурентов, ожиданий пользователей, объемов реализации.

Гипотезы - HADI-циклы

• Очень плохо работает на старте, так как не видна разница между проверкой гипотезы и разработкой.
• Наиболее эффективно - на growth
• Плохо проверяет What, хорошо How

Roadmap. Когда напилили на фичи - декомпозировали по ролям и раскладываем. Product increment у них 6 спринтов. Но! На старте нет требований, нет понимания в деталях. Поэтому резервируем место. А далее попадаем в сроки через варьирование бантиков.

Сегментация аудитории - только тогда, когда понимаем состояние продукта, которое можем транслировать в рынок. Понятно, что гипотезы были. ABCX сегментации. Понимайте, что сегмент X может убить продукт. Не дай бог продукт вашего self-made стартапа захочет на ранней стадии купить госбанк, которому нужно ИБ и много другого - это угробит незрелый продукт.

Квадраты по определенности для продукта, стейкхолдера и клиента.

Сущности и скоуп продукта. Диаграмма классов - первое, что просит от аналитика. Оно хорошо обрисовывает скоуп продукта.

UX-концептинг 101. Берем сценарий, и описываем по шаблону

Бюджет, сроки, маркетинг. Режем скоуп, меняем позиционирование, ходим в рынок.

Продуктовая аналитика: экономические метрики и поведенческие метрики CJM - как пользователи реально ходят по продукту.

Доклад начался с выбора добровольцем из зала между яблоком и грушей, после которого вскрывалась дополнительная информация, которая, возможно, влияла на решение. И которая заставляла сожалеть о решении. Почему сложно принимать решения? Неопределенность, вариативность, влияние других людей, боязнь неверного решения.

Как можно уменьшить весь этот негатив за счет процедуры принятия решений? Есть рекомендации от Тони Робинса

• Всегда принимайте решения на бумаге. Когда прокручиваем в голове - зацикливаемся,
• Надо ответить на вопрос: какая цель, что я хочу получить. Не руководство или семья, а именно сам.
• Учитывайте, что решение основано на вероятностях. Пришел в ресторан с целью что-то попробовать, а там этого сегодня нет - это не катастрофа и не стоит сильно расстраиваться, так бывает..
• Правило "решение - уточнение". Собираем факты и в моменте принимаем решение. Могут появиться новые факты - решение меняется, это нормально.

Как работать с проблемой? Есть много workflow, она делится своим.

• Определение проблемы или задачи без оценочных суждений, как цель.
• Массив возможных вариантов - все записываем на бумагу. Например, все варианты поездки в отпуск, даже если сходу отвергаем
• Оценка - вычеркните непригодное, от чего отказаться
• Выбор из оставшихся альтернатив (это дальше)
• Внедрение решения - сразу, не уходить в подбор и поиск новых вариантов. Нет аналитическому параличу.
• Анализ внедряемого решения и изменение в случае не обходимости

Про выбор из альтернатив был пример принятия решения о том, кому из сотрудников дать задачу.

1. Квадрат Декарта. Каждое решение оцениваем с 4 сторон.

• Мотивация. Что будет, если сделаю.
• Не хочу терять. Что будет, если не сделаю
• Цена решения. Что НЕ будет, если сделаю.
• Что мешает. Что НЕ будет, если НЕ сделаю.

В каждом квадранте выписываем последствия - положительные и отрицательные. Там есть плюсы и минусы. Можно посчитать плюсы и минусы по каждому решению.

2. Дальше мы видим, что проскакивает общее для всех сотрудников: знание предметной области, загрузка сотрудников, компетенция документирования, компетенция сбора требований и так далее. Значит это можно считать критериями выбора - и сделать матрицу принятия решений. Ставим весы критериев, или баллы, или произведение. Используем матрицу только когда решения сопоставимы. Если вы выбираете между теплым морем и горными лыжами, то там мы выбор сделаем просто поставив вес.

3. Если остались сомнения - делаем карту рисков. Сомнения, описываем словами или в процентах. Например, для выбора сотрудника есть сомнение: будет ли задача выполнена в срок, с тремя вариантами: во-время, немного задержится, не выдержим срока. У занятого сотрудника - высокая вероятность задержки. И это добавляем к весам.

Схема рабочая, она применяла ее на решении о переходе на роль куратора из системных аналитиков с помощью инструментов. Было 4 варианта, принимала решение неделю. И тогда реально не знала решение. Это - не подгонка обоснования под заранее придуманное решение. Хотя понятно, что в таком режиме тоже можно: поиграла весами - и получило нужный результат. Но это при любом методе можно. Есть и другие инструменты - диаграммы Парето, диаграммы Исикавы и так далее. Их тоже можно применять.

В докладе два метода: (1) рисуем колесо баланса жизни или работы и (2) применяем модель базовых бизнес-понятий BACCM для принятия личных решений. Кажется, что это интересно, но способ принятия решений до конца не проявлен. Может быть потому, что это был блиц, и просто не успел раскрыть. Если кратко изложить то, что я понял, будет следующее. Модель выявления бизнес-понятий при применении к личным ситуациям позволяет выявить ценности и факторы, которые важны именно для тебя в какой-то области, например, касающихся ведения проектов. И дальше построить в Excel матрицу оценки, применить ее для прошлых проектов и для будущих. Разглядывание матрицы может позволить увидеть корреляцию и сделать кластеризации.

Например, оценивая свои проекты, он так выяснил четыре типа: чайки, пингвины, тупики и альбатросы. И построил колесо профессионального баланса, а также смог сформулировать ожидания от новых проектов. И это не просто выбор, это как раз типология проектов, которая позволяет ориентироваться на будущее. Алексей применял этот метод не только к проектам, но и к решению о возможном переезде. И вот здесь модель базовых бизнес-понятий BACCM помогла ему выявить ценность "доехать до родителей за три часа", которое неожиданно подсветило вопрос переезда, а при обычных рассуждениях - не проявлялось. В общем, надо будет еще посмотреть на слайды детально. Да, про название. Почему это чайка-анализ я так и не понял. На входе был тезис, что это не про чайка-менеджмент, а ассоциировано с Чайкой по имени Джонатан Лингвистон Ричарда Баха, но деталей я не понял. Может, потому, что давно читал книгу.

Рассказ на простом примере "Хочу пиццу", по которому надо принять оплату, приготовить пиццу и ее доставить. В сервисной архитектуре это отдельные сервисы, которым надо дать команды: Прими оплату, Приготовь, Привези. Но Потребитель не хочет управлять, он хочет сказать "Хочу пиццу" и все. Это одно событие, на которые должны среагировать все сервисы.

Из чего делать событие?

• Разбор процесса от начала и до конца. Для Запрос-ответ мы можем взять кусочек и окружение. А тут надо найти начало, конец и всю цепочку.
• Выделение шагов-задач, необходимых для достижения цели.
• Поиск объектов, участвующих в процессе. Например, Заказ пицц. И изменение состояние объектов связан с процессом.
• Определение зависимостей. Когда повар должен начать готовить пиццу? Когда заказ становится оплаченным.

Важно мыслить не отдельными функциями, а целиком процессом.

Как вести документацию? По стримам разработки - им соответствуют процессы от начала и до конца.

• Бизнес: цели и гипотезы, не требования
• Объекты: жизненный цикл и событийный ряд
• Архитектура: схемы и зависимости
• State machine diagram и sequence diagram
• Документация - не со стороны отправителя, а со стороны получателя, их цели. Страничек - много, но они маленькие.

Как организовать события? Персонаж хочет пиццу. У разных подписчиков - разные вопросы по этому поводу.

• Notification: событие только сообщает про изменении объекта, а дальше потребитель спрашивает что ему нужно. Можно пакетировать - несколько изменений. Нагрузка на источник - повышенная.
• Event-carried state transfer - передача атрибутов в событии. В расчете на то, что их будет достаточно для всех подписчиков.

Правило проектирование

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

Связь кто и что получает - полезно фиксировать.

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

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

Event storming. Коллаборация бизнес-пользователей и ИТ по исследованию области бизнеса. И помимо разбора бизнес и ИТ вырабатывают общий язык. Там выделяют Событие, Команда, Правило, Агрегат. Начинают с события - что произошло? Дальше команды как реакция на события и агрегаты, с которыми работаем. И в конце - выделяем ограниченные контексты.

Вопрос из зала - почему не BPMN? Ответ - потому что у нас - сложная бизнес-область, кто этот BPMN нарисует? При этом если вам нравится BPMN, то потом можно на него результаты event storming переложить. И вот тут явно видна разница подходов: они описания процессов в BPMN не ведут, полагают это излишним, используя более легкие способы. А спрашивающий уверен, что без этого увидеть процесс целиком невозможно, это было видно из дальнейших уточняющих вопросов.

Минтруда регулярно обновляет профессиональные стандарты. Для них это - средство поставить задачу ВУЗам по подготовке специалистов. И они стараются собрать хорошую рабочую группу для этого по мере возможности. А рабочая группа обычно состоит из людей, которые видят в стандарте не только средство поставить задачу для подготовки специалистов ВУЗами, но и нанести пользу через прояснение содержание работ и квалификации, связанных с профессией. И учесть интересы обобщенных стейкхолеров: руководителей и заказчиков, проджект-менеджеров и тимлидов, самих аналитиков, в докладе эти интересы были обозначены. У меня лично скепсис по поводу такого влияния стандарта на отрасль, но это уже отдельная тема для обсуждения.

Предыдущий стандарт системного аналитика делала группа под руководством Дениса Бескова в 2014, а новый - группа под руководством Сергея Нужненко, в которой около 140 человек и 40 экспертов. Организует ВНИИ Труда. Ирина в этом активно участвовала, а в докладе - рассказывала об изменениях в стандарте. Основное - изменили содержание работы аналитика, вместо формулировки "Содержание работ: разработки требований" стала формулировка "Миссия: координация на уровне проектных решений". То есть меняется разделение труда. Такое изменение - не их произвол, оно проявлено в индустрии, например, это видно по изменениям требований к позиции на HH. При этом написано разграничение со смежным ролями: бизнес-аналитик проектирует организацию; системный выявляет рамки автоматизации, собирает требования, включая атрибуты качества и проектирует; архитектор создает конструкцию, реализующая атрибуты качества и детальные требования; есть границы с техническим писателем, разработчиком, тестировщиком. Правда, открытый вопрос - отражено ли это изменение в смежных профессиональных стандартах?

Содержание работы системного аналитика определено через трудовую функцию, включающую трудовые действия, необходимые умения и необходимые знания. По сравнению с предыдущим стандартом добавлена защита информации, интеграция и API, распределенные системы - в 2014 это было сильно менее актуально. А также навыки программирования. Доработан и уточнен глоссарий. Уровни квалификации: младший - работа с требованиями, средний - разработка техпроекта, старший - концепция ТЗ и ведущий - управление группой. При этом после среднего уровня - развилка, а не линейное развитие: руководить группой можно без навыков старшего аналитика. Но я подозреваю, что на практике эту развилку не воспримут. По уровням расписаны не только профессиональные компетенции, но и ответственность, работа с неопределенностью и другие, в презентации были примеры. Интересно, насколько это соотносится с аналогичными уровнями в других профессиональных стандартах. На мой взгляд, тут интересен опыт британского стандарта SFIA, где семь уровней определены сквозным образом для всех специализация с точки зрения ответственности, самостоятельности и ряда других характеристик, при этом некоторые специализации заканчиваются на 4-5 уровне, в то время как другие, руководящие - начинаются с 3-4 или выше.

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

Из обсуждения.

Mikhail Romashov. Очень интересно! Это на analyst days сейчас? Когда можно будет ознакомиться с докладом? Максим, как вы заметили интересно было бы сравнить с SFIA. Также со стандартном бизнес аналитика, тк проектирует организацию это роль бизнес архитектор. И, считаю важным, закрепить разграничение с ролью архитектора.

mtsepkov. В докладе была ссылка на чат рабочей группы в телеграм, я сейчас нашел, https://t.me/profstandart_SA думаю там можно посмотреть рабочий вариант. Стандарт бизнес-аналитика тоже пересматривают и там тот же ответственный от ВНИИ Труда в реестре о пересмотре, но я не знаю, кто участвует. При этом стандарт бизнес-аналитика относится к категории "08. Финансы и экономика", то есть это - не ИТ специализация, в отличие от системного аналитика, который относится к области "06 Связь, информационные и коммуникационные технологии". Стандарт Архитектора программного обеспечения был обновлен в 2021 году (это информация и реестра), разрабатывал Союз ИТ-директоров.

Irina. Что значит "запретить разграничение"? где видно что оно разрешено или запрещено? это разные роли, и по компетенциям и по результату. А выполнять роли может один человек, если есть компетенции. Я уже не говорю, что архитекторов тоже бывает разных и много разных.

Mikhail Romashov. Ирина, благодарю, что оперативно откликнулись!

Закрепить разграничение, на уровне задач и результатов. Часто бывают дискуссии кто должен делать те или иные активности. У себя в компании участвовал в проработке профилей ролей, понимаю какая это непростая работа.

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

И они решили, что можно улучшить ситуацию, если поставить процесс онбординга, в котором бы участвовали не только руководители, но и наставники. И они пошли создавать процесс, опираясь на свои профессиональные умения бизнес-аналитика - надо же не просто создать с нуля, а обеспечить встройку в HR-процессы. А еще - команды так или иначе решают задачу онбординга, и есть смысл опереться на их опыт. Поэтому они построили Customer Journey Map по поыту решения задачи в разных подразделениях, а потом - обобщили, консолидировали все материалы, сделали навигацию для наставника и адаптантов.

Получилось типовое описание фаз онбординга, который начинается с разработки плана руководителем и установочной встречи с новичком, где этот план с ним обсуждают, и предусмотрены промежуточные точки обратной связи, а не только по завершению срока, есть типовые вопросы, которые на встречах с новичком необходимо обсуждать. А еще - формализовали опыт наставника и добавили, согласовав с HR, отдельную мотивацию для наставников. Сейчас - пилот. К сожалению, блиц-формат не позволил раскрыть подробности. На мой взгляд, был бы интересен анализ разных CJM и способов решения проблем, чтобы люди могли взять для себя не только общую идею, она-то как раз очень похожа в разных компаниях, но и отдельные полезные практики.

Основы использования в интеграционных задачах. Основное в докладе следующее: гарантированная однократная доставка сообщения (exactly once) в природе не встречается, брокеры или теряют сообщения (at most once) или могут их дублировать (at least once), в том числе дубль может получить другой экземпляр сервиса-получателя, дублирование будет, если проблемы возникли с передачей квитанции после обработки. И вам надо проектировать системы, устойчивые к возникающим при этом проблемы. Вы не можете от проблем избавиться, но можете выбрать, с чем именно будете разбираться. Как разбираться - тоже немного было. Например, идемпотентная обработка обладает устойчивостью к дублированию. А регулярная отправка, например, биржевых курсов - устойчива к потерям.

Поведение может быть заложено в архитектуру брокера, или управляться настройками для конкретной очереди или подписки. При этом классическая подписка со многими получателями работает как at least once, а в Kafka мы имеем подписку, в которой политикой смещения счетчика (at most once или at least once) вроде может управляться для каждого получателя.

Из обсуждения.

Mike Spencer: https://habr.com/ru/company/badoo/blog/333046/ говорят, встречается, только нужно приложения проектировать особым образом. Но это просто гуглинг.

mtsepkov: Ну да, надо специальным образом проектировать обработку сообщения, а не просто конфигурировать очередь. И это естественно, потому что любая обработка состоит из 3 шагов: выбор сообщения, обработка и фиксация результата. И нельзя гарантировать, что не будет сбоя после обработки но до фиксации результата. Хотя этот промежуток может быть очень мал.

Andrey. Тут нужно разграничить еще exactly once доставку и обработку

mtsepkov. А вот это непонятно как разграничить в принципе, на мой взгляд.