Просмотр исходного текста страницы Блог:Максима Цепкова/2024-11-26: AnalystDays-19 - сильные доклады и хорошее общение

{{Conf-Ref}}
Осенняя [https://analystdays.ru/ru/program/121860 '''AnalystDays-19'''] прошла 22-23.11.2024 и принесла много сильных докладов и хорошее общение. Я участвую в конференции много лет и отметил бы эту за высокий уровень и хорошее содержание докладов. И я надеюсь, что следующая, юбилейная 20 конференция, которая будет в мае в Петербурге, окажется не хуже.

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

= Максим Цепков. Модели личности – основа для успешной коммуникации и развития =

У меня был очередной доклад, рассказывающий про модель личности [[Модели личности – основа для успешной коммуникации и развития (AnalystDays-2024)]]. Как архитектора, меня глубоко огорчала фрагментарность моделей soft skill и отсутствие под ними базовой модели, которая бы позволяла видеть их основания и сопряжение между собой. При этом [[Анна Обухова и другие про нейрофизиологию в работе|выступления Анны Обуховой]], а также другие материалы по современной нейрофизиологии показывали, что такая база уже есть, просто психологи не торопятся ее использовать и пересобирать свои модели. Пришлось делать самому. зимой 2022-2023 родилась серия статей «Модель личности», осенью 2023 была начата серия докладов, а весной 2024 вышла книга [https://ridero.ru/books/inzhenernaya_model_lichnosti/ '''Книга «Инженерная модель личности — Меняя себя и других — понимай устройство»]'''. Конспекта доклада не будет, можно смотреть доклад '''[[Взаимодействуй с людьми и развивайся с опорой на модели личности (ЛАФ-2024)]]''', а также другие доклады серии [[:Категория:Модель личности|'''Модель личности''']]. Доклады не являются повторением, содержание развивается, также как логика изложения и кейсы, иллюстрирующие применение модели. 

= Татьяна Половинкина из НЕОФЛЕКС. В чем смысл цели? = 

Офигенно крутой доклад про работу с целеполаганием по X-матрице Стратегия - Тактика - Задачи (гипотезы) - Результаты. Матрица - потому что у тебя не обычное дерево, ты на каждом шаге заполняешь взаимную зависимость и отсекаешь то, что оказывается малозначимым. По каждому такту - лайфхаки, и иллюстрация сквозным примером.

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

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

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

Тактика - это вектор действия в направлении стратегической цели. Лайфхаки тактики.
* Проверка фокусировки. Хочу 1 млн прибыли - а что делать будешь сейчас? - буду путешествовать. Стоп. Или зарабатывать, или путешествовать. Ну или покажи связь.
* Тактика "от" и "к" - Чего хотите достигнуть и что сейчас мешает.
* Гибкость. Мелкие задачи, появляются новые возможности и ограничения. Нужен ли этот бой сейчас? 

Лайфхаки задач. 
* Цель - не средство. Не прочитать книгу, а стать книголюбом, или изучить и применять знания. Изучить курс - не цель. 
* Помните, что задача - это гипотеза! Работайте по HADI циклу проверки гипотез
* Эффект Икеи или Брейншторм. Когда хотите достичь цели - позвольте людям набросать гипотез, не давайте пути сами. Когда делаешь мебель своими руками - она чудесна. Так и с любыми путями. 
* Людей, которые хотят знать алгоритмы, алгоритмы (ИИ) заменят в первую очередь.
 
Матрица: какие идеи на какие тактические вектора движения работают. Ставят баллы. И это отсекает гипотезы, которые в тактику не укладываются. 

Лайфхаки результата.
* Проверка фокусировки. Метрики, которые мы будем измерять. Основанные на ценности, цели, результате, а не на исполнении задач. Но задачи тоже меряем - это оценивает затраченные ресурсы. 
* Умение ошибаться. Это как отладка кода - мы же ошибаемся, и это не страшно. Так и со всем остальным. Надо извлекать выводы.

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

Кейс, на котором дальше был разбор - ее стратегическая цель. Была 2 года назад - максимально расширить компетенцию SQL у сотрудников - они data-аналитики. У нее: изучение навыка, применение навыка, трансляция навыка (это обязательно, синхронизация с другими). Шаги задач и результатов - в презентации были матрицы идей с конкретными баллами. Картинка оценки часто удивляла, оказывалось, что гипотеза, которая кажется перспективной, набирала меньше всего.

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

Выводы.
* Вплетите личную мотивацию в стратегию компании. Человек не может работать над задачами без смысла
* Фокусировка
* Работа с гипотезами
* Синхронизация
Результат - человек: вовлеченный, осознанный и гибкий.

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

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

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

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

Теперь отдельно про человекоцентричность. С одной стороны, я впервые засек в 2019 смену социального контракта сотрудника от компетентной работы за зарплату к искренней работы на цели компании в обмен на условия для счастья на работе, у меня об этом есть статьи и доклады. Но, с другой стороны, тут важная часть - счастье на работе. Я решительно не согласен с японской концепцией, в которой человек приходит в корпорацию на всю жизнь и работает исключительно на благо этой корпорации. И не имеет иного смысла жизни, вплоть до того, что при увольнении кончает жизнь самоубийством - кейсы известны. И с вариантом, к которому пришли некоторые американские компании (и не только они): мы все сделаем, чтобы вы могли круглосуточно не выходить с места работы, я тоже не согласен. Потому что жизнь человека не ограничивается работой. И там есть не только досуг и работа в профессиональных сообществах, но и социальные связи, а также рождение и воспитание детей. Конечно, есть концепт, что людей на Земле и так слишком много, поэтому рожать новых не нужно, но, по-моему, он доказал свою несостоятельность. Так что тут важны акценты. А Харари, на которого Татьяна ссылалась в вопросах, на мой взгляд, мыслит в рамках этих концептов. Так что индивидуальное и субъективное счастье - правильно.

'''Комментарий Татьяны''' на мои замечания. И я поддерживаю! Уж не знаю, где проскочила японская концепция, но против нее категорически. Хотелось донести мысль, что компании могут попытаться делать своих сотрудников счастливее не только на работе, согласно роли на проекте - у многих есть спорт за счет компании (лично получаю кайф избивая мяч раз в неделю), есть потребность в благотворительности, ощущение безопасности и заботы от ДМС, настольных играх, детских и взрослых МК (недавно делали фонарики бусики и флорариумы на работе) и многое другое что можно делать с коллективом . Это качественно меняет отношении к команде и проекту.  Чем больше позитивных эмоций у человека от компании, тем круче с ним в ней жить.

По поводу рожать (уж извините мать 4 детей не может промолчать). В той же Японии где с демографией давно проблема, недавно закончился эксперимент по сильному денежному стимулированию появления детей. В Китае регулярные обзвоны женщин с вопросом "вы еще не беременны?" . В поисках сотрудниках компании начинают отбор со школы и есть лагеря, где "фабрика кадров" с 10-12 лет. И глядя на этот мир, резюмирую - проблема рождаемости ляжет на государство, . Там где захотят развиваться будут "заказывать детей" и контролировать появление качественных граждан. 

Повторю мысль завершающую доклад Нам всем не хватает умных людей.

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

= Дмитрий Блинов, DBlinov.com. Декомпозируем истории и создаем User story map для фитнес-аппа =

Хороший доклад о том, как декомпозировать и резать скоуп для MVP на примере кейса создания софта для фитнес-клуба. Agile и Scrum основаны на идее быстрой регулярной поставки инкремента ценности. Возможность поставки означает, что задача должна быть готова полностью, а не на 99%. В то время как практика ответа на вопрос - задача готова почти: сделал, но не смержил; протестировал, но не везде. Мы работаем среди умных людей, и странно, если не найдет причину. Важно договориться: готова - это 100%.

Если наша задача - оставлять инкремент, то декомпозиция по слоям архитектуры или фазам разработки не подходит. Бэк без UI или требования без разработки никому не нужны. И был придуман иной способ - user story, рассказ о работе пользователя, который достигает какой-то цели. Придумал Кен Бек в XP. Основные книги: Майк Кон и Джеф Паттон. Главная фишка story - ценность, это и делает ее инкрементом. Появились шаблоны, в начале 2000-х. Потом ценность вперед переставили. История должна быть INVEST. Оцениваемая и ценная.

Рассказ - длинный, это эпик, а дальше мы его делим на кусочки и в user story map приоритизируем. Придумал Джеф Паттон: 2004 статья, 2007 термин, 2014 в книге. Кстати, в 2013 я был на тренинге Джефа Паттона, и он очень интересно рассказывал про user story map, у меня в блоге [[Блог:Максима Цепкова/2013-03-28: Как появляется PBL - Jeff Patton на AgileDays|есть конспект]].

В докладе - сквозной кейс: хочу открыть фитнес-клуб DomFit. QR-код на турникете, найти и записаться, оплатить на тренировку и многое другое. В списки появляются объекты - о клубе, о тренировке, о тренерах, профиль пользователя. Если так понятнее - делайте такие истории. Но помните, что хранение объектов не имеет ценности без их использования для других историй.

Расположили каркас в строку. Что делить? То, что не пролезает в спринт, и то, что включает несколько приоритетов. Очень часто части истории имеют разную важность. Задача Product Owner - поделить истории, чтобы можно было оставить наверху ценные части. Делим vertical valuable visible. Не всегда получается вертикально, они не будут ровными кусками - где-то UI больше, где-то - бэк. Но обязательно что-то в UI - история должна быть видима.  В кейсе выделили: регистрация, пропуск по QR, записаться и оплатить.

Регистрация - куча вариантов как залогиниться. И для каждого - варианты, например через почту - много способов. Альтернативы по сценариям и данным. И надо найти 1-2 самого ценного вариант, а остальные - убрать. Опускаем вниз на user story map. Личный профиль. Делим: атрибуты объектов, типы, справочники, интеграция. В MVP берем малое: телефон, почта, QR. 

Интеграция - потом, совсем без нее или самую простую. Если сосем не можете сделать без нее - возьмите в начале, потому как с ней риски по смежникам.

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

Итого - что получилось из user story. суммарная визуализация, и в рассказе было 9 способов декомпозиции. Есть еще.
* Деление по глубине вывода данных - для банка увидеть остаток, операции недели, важные атрибуты и т.п.
* Админка и настройки - потом!
* Элементы управления: сложные - потом. Если нет разницы текст или календарь - сделайте календарь, если его сложнее - текст. А вообще с календарем - беда, когда надо скроллить до своего года рождения - сильно огорчаешься. 
* UI. Внешний софт - простой функционал с красивым GUI, если внутренний - наоборот, просто бухгалтера хотят черные буквы на белом фоне, а не полутона.
* Производительность - можно позднее, если у вас не будет ее сразу. Но важно: когда поделили, то остаются обе истории, медленная и быстрая, а не забыли, что сделали медленно.

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

Размер декомпозиции. 5 историй в спринт. Ему такая цифра нравится. Реально идем итеративно от какого-то старта. 

Выгоды маленьких история - мы можем многое опустить вниз, и на это место положить ценное. B снижает риски: если история одна и что-то заблокировала - стоп. А если три - нормально.

Все про MVP знают. Но не делают. Оправдания разные.
* Все равно релизить, зачем откладывать; 
* Все на бэк, можем поставлять раз в месяц - про месяц правда, но можем или хотим
* Лень - когнитивная скупость.
* Еще ответ: наша ситуация уникальна.
Все это отмазки. И что будут слишком маленькая история, которая не приносит ценности - тоже, так получается редко. 

Так что делите истории, чтобы они были ценными и маленькими. User story - микропроект, который можно сдать заказчику.

[https://dblinov.com/blog/tpost/lkdal7x9s1-relizit-kazhdii-sprint-15-sposobov-dekom '''Шпаргалка с методами декомпозиции от Дмитрия''']. 

= Ольга Кулапина из Red Collar. Куда приводит Discovery. Как работать с неопределенностью =

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

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

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

'''Шаг 2. Ищем знакомое в незнакомом, перепрошиваем и развиваем навыки'''. Cust Dev похож на бриф, исследуем конкурентов - как заказчика, на открытых данных, объемы рынка - по открытым данным конкурентов. 

Cust Dev. 
* Не знаете откуда взять аудиторию? Запросить у заказчика - нормально. Еще соцсети
* Не знаете сегментирование - JTBT. Поймите, какую работу выполняет продукт, например, йогурт с высоким содержанием белка - когда его применяют. И это дает аудиторию и вопросу к ней - про 
* Какую методику выбрать? Чем больше неопределенности - качественная, подробности - количественная. 
* Интервью. Короткие - люди вам не должны. Но задавайте открытые вопросы. Не про ваши гипотезы, а про то, как они действуют. Узнаете новое. Но это - пользователям, а заказчику - гипотезы и сценарии, иначе он будет увеличивать MVP.   

Исследование конкурентов. Поле конкурентов и ответ - стоит ли лезть на это поле. Фреймворков много. Ее любимый - магический квадрант Гартнера, Фичи и UX, кружок - объем рынка. 

Объемы рынка. Зачем? Если пришли с идеей, а денег нет - люди не привыкли платить - то лучше не лезть, это трудно. Фреймворков много, наиболее легкий - TAM-SAM-SOM.

Все эти фреймворки в пределе сводится к здравому смыслу и business view.

Неопределенности стало меньше, но появился хаос данных.

'''Шаг 3. Гипотезы - проводник через хаос данных'''. Научиться мыслить гипотезами. Верхнеуровневые рамочные - цифровые - улучшение продукта. Рамка - идея, например, всем будет полезен магазин готовых маршрутов. Цифровые про MVP, проверка продукта.

'''Шаг 4. MVP'''. Определились с составом продукта, теперь его надо обрезать. Все кивают на концепцию, но как только реально доходит до урезания - не режут. Не переживайте, что первый продукт бедный - будет возможность дополнить. HADI цикл. И есть лайфхак: у вас будет не бедный продукт, а сфокусированный или сконцентрированный, смена термина многое меняет в восприятии.

Здесь много трагедий и боли. Стартап хотел цивилизовать рынок щебня. Ребята 4 месяца разговаривали на прототипов. Самолет, к которому прилепили бассейн и спортзал. Срезать не удалось, потому что MVP срезать не удалось, заказчик полюбил. В результате MVP разрабатывали год, потратили все деньги ,на маркетинг и продвижение не осталось - а это дороже разработки. А сейчас конкуренты пришли с идеей выкупить идею - рынок созрел. 

Для сокращения MVP - делайте быстро и малыми силами. Не 30 человек год, а три за месяц. 

'''Шаг 5. Во-время останавливаемся'''. Discovery - продуктовая гипотеза. Весь продуктовый цикл не закрываете. Там маркетинг, юнит-экономика и много чего.

И в заключении. Иногда discovery - крик бизнеса о помощи, не игнорируйте. Бизнес-аналитик - может сделать.

= Вера Бонарева из Сбербанк. Преодоление сложностей в интеллектуальном распознавании документов: инновационные подходы и роль LLM =

Это блиц-рассказ о том, как усложнялась по мере реализации задача распознавания документов, появлялись все новые кейсы и способы распознавания.
* Первоначально задача выглядела просто: приходят сканы и документы разных типов (xml, excel, word, pdf) - и надо опознать тип. Полный автомат, документы передает внешний сервис. ему же оправляют ответ. Настроили распознавание текста с изображений, парсеры xml и excel, систему правил, которая применяется после распознавания скана или парсера.
* Быстро выяснилось, что приходят архивы с большим количеством файлов, надо распаковать и каждый обрабатывать отдельно.
* Затем - что в архиве может приходить потоковый скан на сотни страниц, который надо разбить на отдельные документы.
* Затем - добавили верификацию пользователями того, что распозналось плохо или неуверенно - у системы появился GUI, а с документом приходят данные - кто должен подтвердить. Верификаторы - дефицитный ресурс, в пике потока получается задержка до пары дней, поэтому если в архиве документы, которые распознаются хорошо и которые плохо - то статус надо вести не у архива в целом. а по отдельным документам в нем. И еще специальные меры, чтобы документ, ожидающий верификации, не был сброшен из очереди по сроку.
* Из паспортов и некоторых других документов надо вытаскивать атрибуты - ФИО, серия, номер и так далее, для этого подключили ML, с паспортами и другими документами фиксированных форматов она справляется.
* Из договоров ML атрибуты вытаскивает плохо, там большие тексты - про них спрашивают LLM, GigaQuery и ответ сравнивают с тем, что дала система правил.
* Поскольку верификация - избирательная, то ошибки проскакивают, и пользователь может отправить на повторное распознавание, которое всегда с верификацией, даже для простых документов.
Такое вот усложнение системы в ходе разработки и эксплуатации - типичная история.

= Наталья Семенова. Коллеги, мы тоже на одном языке говорим =

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

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

Мини сценка, разговор двух аналитиков: 
:- Стейкхолдеры у нас никакие...
:- А ты что, ты же тоже стейкхолдер? 
:- Как я стейкхолдер. это же заказчики? 
  
Собрать требования. 
* Уточнить у ЛПР, поискать в документации требования и выявить заинтересованных лиц.
* Изучить бизнес-требования, запросить описания процессов, собрать у стейкхолдеров
* Сформировать гипотезы, сделать тестирование на фокус-группе, оценить стоимость и ROI.
Это различия внутренней, заказной и продуктовой разработки - требования собираем по-разному. И это - за рамками разговора.

Взаимодействие с командой.
* А что общаться, написал ТЗ и отдал, дальше на вопросы...
* У других - плотное взаимодействие: истории, DoD, сделал сторителлинг и так далее.
Разные методы работы команды. И отличия надо понимать, выяснять. что тебя ждет в проекте и действовать сообразно, или предлагать изменения, тоже осознанно.

А что делать до разработки?
* discovery и presale
* product market fit, анализ конкурентов
Тоже заказная и продуктовая разработка.

Ретро, разное отношение
* Сначала было скучно, потом весело. 
* Проводим по регламентам каждый квартал, хотя хочется чаще. 
* Проводим каждый спринт и отдельно со смежниками по необходимости.
Зависит от зрелости бизнес-процессов: хаотичные, по регламентам, постоянные улушения - на слайде была шкала из 5 уровней. Я бы отнес это не к зрелости бизнес-процессов, а к культуре ведения проекта, но такое различие терминов - тоже часть культурной рамки. 

Степень свободы аналитика
* RACI по процессам, с заданными инструментами
* задачи на синках, целесообразность обсуждается, oD и критерии качества тоже.
Начинающим интересно по регламентам, опытные - сами решают по ситуации.

Как выявлять диференцииаторы контекста? Рассматривают 4 квадранта: Знать - Узнавать; Все просто - Все серьезно.
Все просто.
* Знаем: быстрая память и интуиция из насмотренности.
* Узнаем: спросить в разговоре или погуглить. Очень часто пытаемся угадать - а это неправильно.

Все серьезно.  
* Надо знать про стандарты, метрики, модели и техники, инструменты, регламенты и заглядывать туда. по необходимости. Быстрая проверка через стандарты помогает.
* Модель IGOE: inputs - guides (как будем делать) - ouputs - enablers (что поможет выполнить). 
* Кастомные модель 6 перспектив: люди, процессы, время, ресурсы, инструменты, скоуп. Применялась в EPAM, она делала доклад, можно посмотреть.

Как узнавать дифференциалы в серьезных случаях?
* курсы, конференции - загружать теорию
* Опыт
* Моделирование и концептуализация - для тех, кто может сам из непонятных ситуаций создавать модели. 

По концептуализации у Натальи был доклад на прошлой AnalystDays.

В конце было еще обсуждение с кейсами от участников.

= Галина Кореневская из ГК Самолет. Как мы изобрели Business and Data Flow Diagram =

В 2022 Самолет решил стать лидером рынка за счет покупки крупной компании. Перед Ит поставили задачу поддержать быстрый переход компаний в однородное состояние, для чего сделать описание бизнес-процессов, которое бы соответствовало действительности. И разобраться с более, чем 350 ИТ-системами. Для описания бизнес-процессов надо выбрать нотацию. Они собрали цели бизнеса и ИТ. Бизнесу достаточно BPMN, а ИТ, помимо описания бизнес-процессов, хотели видеть его поддержку ИТ-системами, сущности и интеграцию систем. И они доработали BPMN-нотацию для описания. Рассказ был о доработках и о требованиях к описаниям.

* Нейминг - краткое наименование отражает смысл процесса. BPMN storm - тип asis/tobe. рейтинг качества, ниже 8 - надо переделать
* Границы. Старт - триггер, он должен быть подписан! А это - важно. И именно событие. Не "необходим пересмотр лимитов", а почему он необходим, например, увеличился объем работ
* Действия: гранулярность, кто выполняет и в какой системе. должен быть результат, роль которая выполняет и входящие параметры - документ. Могут быть подпроцессы.
* Стрелки - явные шлюзы, понимать: от процесса к документу - результат, от документа в задачу - параметр.
* Сущности делятся  цифровые и нецифровые. Сканы - тоже нецифровые. Цифровые - с жизненным циклом. Если жизненный цикл в одной системе - фиолетовый, а много систем - зеленый. Клиент - живет в нескольких, задача - только в jira.
* Описания интеграций. Автоматическая задача передачи данных (шестеренка) - стрелка потока нужного цвета, входит в задачу принимающей системы, на выходе - ее документ. Зеленые стрелки - передача сущностей, а фиолетовая = передача событий, меняющих состояния документов. Например, из СРМ в учетную систему идут клиент и договор - зеленая стрелка, в учетной системе к договору привязываются платежи, они в CRM не отправляются, но после оплаты идет нотификация для смены состояния договора фиолетовой стрелкой.

Результаты. 
* схемы стали объемнее. Увы. 
* 40 воркшопов с бизнесом и ИТ. 15 команд, 4 ИТ-блока.
* Архитектор не участвует во встречах с бизнесом - ему оказывается достаточно документов.
* Повысили информативность для команд разработки
* Бизнес вовлекли в описание процессов. Они не отказывались от участия.

= Григорий Печенкин. Пять граней мышления аналитика =

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

'''1. Системное мышление'''. Смотрим на мир как на систему систем. Книжек - много. Но! это не формальная теория, которая дает аппарат, а философская концепция с шаблонами мышления. У него было три подхода: в институте, (2) когда стал аналитиком - Системный анализ, почитал книгу, к жизни отношения не имеет (3) книга где описано как действует. 

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

Три стейкхолдера, они на разных уровнях. 
* Проректор - университет в целом. 
* УМУ - смежная система внутри университета. При этом она говорит из своей позиции закладывает две бомбы. Потому как индивидуальные учебные планы - сложная бюрократия, а планирование нагрузки означает, что вы предсказали, что студенты выберут.
* Главный по ИТ - а тут зависит от ситуации в университете.
 
'''2. Логическое мышление'''. Иногда логика дает сбои - когнитивные искажения и другие. 
Искажения частное-общее: Чрезмерное обобщение, эффект знакомства, иллюзия кластеризации.
Решаем не задачу, которая стоит, а знакомую: фрейминг и другое.

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

Фраза - гипотезы, что за ней - отсечение гипотез. Дальше - уточняющие вопросы. И верификация. Потом - вывод. Разветвляющийся конус гипотез, потом - схлопываем. Главное - не пренебрегайте верификацией. В 9 из 10 проговорите то, что всем понятно. Но в 1 из 10 оказывается, что все неправильно.

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

'''3. Мир интересов'''. Его надо видеть. 

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

Луковичная диаграмма. Рисуем стейкхолдеров по слоям подсистема-надсистема, и рисуем интересы.

'''4. Критическое мышление'''. Во всех университетах говорят, что это надо ставить, но понимают по-разному. Его понимание - это Сомнения на пути к истине.

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

На вас можно повлиять. 
* Изолировать от другой точки зрения: не ходите к этому, он не решает. Если не изолировать, то дискредитировать - он не решает, дурак, некомпетентен.
* Подмена свидетелей. Негатив вычеркиваем, позитив лайкаем и добавляем от себя
* Создание информационного фона. Много каналов - с анонсы, и иногда там крупицы золота. Никто не комментирует. А в два ночи - 70 комментариев. А потом - 50 к другому. И это - один человек, к нему идут. Он пришел из губернаторской команды и принес культуру с командой поддержки. И это - способ воздействия на убеждения. 
Манипулируют все. родители детьми, супруги друг другом и так далее. И когда приходите со своей системой - она влияет на интересы и весь спектр может быть применен.

'''5. Визуальное мышление.''' Это было кратко, как замыкание предыдущих. При этом под визуальным мышлением Гриша имеет ввиду представление не виде образов, а в виде схем, графическое отражение различных объектов и связей.

= Наталья Должкевич из Райффайзен. Как когнитивные искажения портят продукт =
 Предупреждение: Я записывал на слух, в телеграфном стиле, так что формулировки могут быть искажены 

# Преувеличение авторитета. Если человек - умный и часто оказывается правым, то его словам могут доверять безусловно, хотя каждый может ошибаться. А еще таким человеком часто оказывается самый активный в обсуждении, при том, что его первое суждение часто может быть неверным. 
# Преувеличение опасности - боязнь нового. Способ борьбы - декомпозиция на малые шаги, немного писем.
# Проклятие знания: много подробностей новичку, при этом пропускаем очевидное. Надо задавать вопросы.
# Эффект знакомства с объектом: выбираем знакомое и родное, вместо рационального выбора. Интеграция всегда на REST, или связи микросервисов в BPMN. Стоит выписывать полюсы и минусы, как при покупке дома или модели телефона. Хотя телефон многие тоже покупают знакомый, без анализа плюсов и минусов, или опираются на рекламу, чтобы рационализировать выбор.
# Чтение мыслей и додумывание за собеседников. Думаем, что заказчику понравилось, а он лишь вежливо улыбнулся. Или разработчик "я все понял" - а понял не так. Переспрашивайте, синхронизируйтесь. Проясняйте очевидное.
# Эффект привязки (якоря). Буду делать, как предложили на планировании. 
Что делать: отталкиваться от user story - что нужно пользователю. И молчаливый брейншторм - идеи на стикерах, и все зачитывают - чтобы полнота картины. 

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

= Лев Немировский из ПСБ. От проектирования до поддержки: работа с AsyncAPI =

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

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

С синхронным взаимодействием это полечил OpenAPI: генерация, валидация, единая точка правды. Хотелось бы такого для асинхронного. И это решает спецификация AsyncAPI. Она очень похожа на OpenAPI, и это - огромный плюс. Поддерживает все протоколы: Kafka, Rbbit, IBM MQ, Apach Pulsar - и там можно указать особенности системы. Включает Info, Сервера, Сообщения и Конфигурацию, был разбор.

Лев сделал специальный репозиторий - можно сделать репорт, попробовать поменять. Там github action на изменения. Документация - swagger.

Внедрение спецификации не исключает все ошибки. Что бывает? 
* Ошибки спецификации. Copy-Paste вместо ссылок - дальше будет расползаться.
* Версионирование. Не все команды поддерживают. Но аналитикам правильно нумеровать чтобы ссылаться на прошлые варианты
* Неполное использование протокола. Аналитик не всегда знает. Можно спросить и зафиксировать - и это поможет всем в команде. Не только сообщения, но и условия передачи
* Спецификация. Используют только JSon с примером - а можно сделать полноценное описание, там markdown - дополнить полезной содержательной информацией.

Есть утилиты проверки и логика. Команды разработки могут свои инструменты писать. Шаблоны и review - у нас Doc As Code - и можно делать merge и review. 

Начинайте с простого - документация. Потом проверки и расширение.

ЖЦ асинхронного похож на синхронный. Swagger. Async API studio. IDE-интеграция, ChatGPT Co-pilot. Обратное проектирование - он не сторонник, он считает ,что проектирование сначала. Но если API есть а доки нет - есть инструменты для любого современного языка. Тестирование и валидация - тоже много инструментов. Есть mocker - чтобы создать псевдосервер для тестирования. 

Генерация кода. Главное - не экономия, а то что новая версия спецификации и генерации позволит понять, что изменилось, и тесты обвалятся. Swagger умеет. Публикация - тоже: html, makrdown. Есть генераторы SDK на множестве языков, проверки на предпроде и проде. 

Изменение процесса. 
* Аналитик создает документацию, описание API - лиды валидируют - и идет параллельная разработка, контракт уже есть.
* Внесение изменений при ошибках - и обратный запуск merge request - чтобы все были в курсе изменений.

Итого - единый стандарт, автогенерация кода, валидация, упрощение коммуникаций.

= Татьяна Онофрюк СберЗвук. Все лучшее сразу - как улучшить подбор артистов для нового пользователя музыкального стриминга =

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

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

В докладе были методы, которые применялись для кластеризации и ее результаты. Получилось 16 кластеров музыкальных предпочтений по жанрам: поп, рок, шансон, разные смеси жанров, дифференциация по современности. Дифференциирующие параметры - пол и место жительства: Москва, Петербург, регионы. Но этими параметрами дифференциация не ограничивается, и не для всех кластеров все параметры существенны, есть смешанные группы. Подробности - в презентации. Дальше провели А/Б - тестирование, получили хорошие результаты. Что важно для кластеризации: надо сформулировать требования на кластера до старта, и проверять их выполнение по результатам кластеризации.
{{wl-publish: 2024-11-26 13:46:13 +0300 | MaksTsepkov }}