Я — Максим Цепков приветствую Вас на своем сайте
|
Я буду рад любым комментариям и обсуждениям. Авторизоваться для этого можно, регистрируясь на сайте или через OpenID. При желании, вы можете размещать здесь свои материалы по тематике сайта. MaksWiki содержит 654 статей IT-тематики. | |
Обо мнеМоя основная работа — проектирование корпоративных и банковских систем. Я верю, что автоматизация — дает новые возможности развития, поэтому создавая автоматизированные системы мы открываем путь прогрессу и делаем мир лучше. Я делаю это, работая главным архитектором дирекции развития решений компании CUSTIS. Я верю в эффективность командной работы, эффективность профессиональных сообществ. И я участвую в жизни ИТ-сообщества - через работу в программных комитетах конференций SECR AnalystDays и просто в коммуникациях на разных площадках. А еще я люблю путешествовать, об этом и о других идеях вне профессиональной деятельности я пишу в своем ЖЖ. |
Я в сетиhttp://www.facebook.com/mtsepkov http://www.linkedin.com/in/mtsepkov http://www.slideshare.net/mtsepkov/ e_mail M.Tsepkov@custis.ru |
Последний постОсенняя AnalystDays-19 прошла 22-23.11.2024 и принесла много сильных докладов и хорошее общение. Я участвую в конференции много лет и отметил бы эту за высокий уровень и хорошее содержание докладов. И я надеюсь, что следующая, юбилейная 20 конференция, которая будет в мае в Петербурге, окажется не хуже. А теперь - конспекты докладов. Отмечу, что доклада Натальи Семеновой в программе нет - это BarCamp. При этом BarCamp идет в трансляцию и записывается, так что это получается возможность сделать полноценный доклад или обсудить актуальные темы с записью. B надо понимать, что на 5 конференции было 5 треков, так что мои конспекты - лишь малая часть докладов. Максим Цепков. Модели личности – основа для успешной коммуникации и развитияУ меня был очередной доклад, рассказывающий про модель личности Модели личности – основа для успешной коммуникации и развития (AnalystDays-2024). Как архитектора, меня глубоко огорчала фрагментарность моделей soft skill и отсутствие под ними базовой модели, которая бы позволяла видеть их основания и сопряжение между собой. При этом выступления Анны Обуховой, а также другие материалы по современной нейрофизиологии показывали, что такая база уже есть, просто психологи не торопятся ее использовать и пересобирать свои модели. Пришлось делать самому. зимой 2022-2023 родилась серия статей «Модель личности», осенью 2023 была начата серия докладов, а весной 2024 вышла книга Книга «Инженерная модель личности — Меняя себя и других — понимай устройство». Конспекта доклада не будет, можно смотреть доклад Взаимодействуй с людьми и развивайся с опорой на модели личности (ЛАФ-2024), а также другие доклады серии Модель личности. Доклады не являются повторением, содержание развивается, также как логика изложения и кейсы, иллюстрирующие применение модели. Татьяна Половинкина из НЕОФЛЕКС. В чем смысл цели?Офигенно крутой доклад про работу с целеполаганием по X-матрице Стратегия - Тактика - Задачи (гипотезы) - Результаты. Матрица - потому что у тебя не обычное дерево, ты на каждом шаге заполняешь взаимную зависимость и отсекаешь то, что оказывается малозначимым. По каждому такту - лайфхаки, и иллюстрация сквозным примером. К докладу была интересная подводка про смену эпох и про приход человекоцентричного мира, которые не про счастье людей, а про счастливых людей, которые лучше работают в компаниях. Ее я прокомментирую в конце. А сейчас - основное содержание. Цель - желаемый осознанный результат. Но желаниям человека свойственна нерациональность и субъективность, нельзя сделать, чтобы человек захотел сделать хранилище данных, он может захотеть лишь самостоятельно. Средство для этого - осознанность. X-матрица - способ осознанной работы с целями. Стратегия - тактика - задачи - результаты. Хотя я бы назвал его способом рационально работать с целями, потому что эмоциональную и мотивационную компоненты он не охватывает. Лайфхаки стратегии.
Если человек хочет машину, чтобы его замечали - может, ему достаточно просто перестать скромничать и его начнут замечать? Тактика - это вектор действия в направлении стратегической цели. Лайфхаки тактики.
Лайфхаки задач.
Матрица: какие идеи на какие тактические вектора движения работают. Ставят баллы. И это отсекает гипотезы, которые в тактику не укладываются. Лайфхаки результата.
Матрица: какие задачи-гипотезы на какие метрики результата влияют. Там тоже индикатор - насколько гипотеза влияет, тут отсев гипотез. Кейс, на котором дальше был разбор - ее стратегическая цель. Была 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, у меня в блоге есть конспект. В докладе - сквозной кейс: хочу открыть фитнес-клуб DomFit. QR-код на турникете, найти и записаться, оплатить на тренировку и многое другое. В списки появляются объекты - о клубе, о тренировке, о тренерах, профиль пользователя. Если так понятнее - делайте такие истории. Но помните, что хранение объектов не имеет ценности без их использования для других историй. Расположили каркас в строку. Что делить? То, что не пролезает в спринт, и то, что включает несколько приоритетов. Очень часто части истории имеют разную важность. Задача Product Owner - поделить истории, чтобы можно было оставить наверху ценные части. Делим vertical valuable visible. Не всегда получается вертикально, они не будут ровными кусками - где-то UI больше, где-то - бэк. Но обязательно что-то в UI - история должна быть видима. В кейсе выделили: регистрация, пропуск по QR, записаться и оплатить. Регистрация - куча вариантов как залогиниться. И для каждого - варианты, например через почту - много способов. Альтернативы по сценариям и данным. И надо найти 1-2 самого ценного вариант, а остальные - убрать. Опускаем вниз на user story map. Личный профиль. Делим: атрибуты объектов, типы, справочники, интеграция. В MVP берем малое: телефон, почта, QR. Интеграция - потом, совсем без нее или самую простую. Если сосем не можете сделать без нее - возьмите в начале, потому как с ней риски по смежникам. Аналогично - записаться на тренинг, там много частей. Очень много, оставляем: найти тренировку и записаться. Поиск: на сегодня, на неделю, фильтры по дате, по тренеру, фильтр по городу, по карте - это деление по бизнес-правилам. Оставляем только одно, без справочников и интеграции. И еще можно просто выпустить расписание для статического просмотра - так тоже работает. Записаться. Самое простое - записаться и отменить, переносы, изменения - потом, это бантики. Итого - что получилось из user story. суммарная визуализация, и в рассказе было 9 способов декомпозиции. Есть еще.
Через все проходит вопрос: что минимальное мы можем делать, принося ценность. Какой самый скупой минимум мы можем реализовать, чтобы история по-прежнему называлась так, как называется. Размер декомпозиции. 5 историй в спринт. Ему такая цифра нравится. Реально идем итеративно от какого-то старта. Выгоды маленьких история - мы можем многое опустить вниз, и на это место положить ценное. B снижает риски: если история одна и что-то заблокировала - стоп. А если три - нормально. Все про MVP знают. Но не делают. Оправдания разные.
Все это отмазки. И что будут слишком маленькая история, которая не приносит ценности - тоже, так получается редко. Так что делите истории, чтобы они были ценными и маленькими. User story - микропроект, который можно сдать заказчику. Шпаргалка с методами декомпозиции от Дмитрия. Ольга Кулапина из Red Collar. Куда приводит Discovery. Как работать с неопределенностьюДоклад был о том, как подружить продуктовые практики и заказную разработку. От аналитиков продуктового мышления ожидают в разных ситуациях, например когда компания делает pet-проект или когда средний оффлайн выходит в онлайн, или в других подобных случаях. Они обращаются к тем аналитикам, которые есть. Понятно, что на входе они под такую работу не подписывались, но на практике часто нет выбора. А еще это интересная задача. И, наконец, многое тут можно сделать, используя знакомые практики аналитика. Да, полностью задачи продукта ты не решишь, маркетинг, продвижение и unit-экономика останется за рамками, но провести discovery, подготовить первый шаг - вполне. Что сделать то, что не делали, нужны две вещи: знакомые точки кристаллизации, от которых можно оттолкнуться и сегментация, разложение процесса по шагам. Что будет точкой кристаллизации? Можно представить discovery как работу аналитиком в ситуации, когда требования сводятся к идее нового продукта, изучение потребностей целевой аудитории представить как выявление пользовательских требований, а изучение рыночного ландшафта - как изучение предметной области. Вроде получается почти знакомый проект. Далее по шагам. Шаг 1. Перепрошиваем мозг, меняем майндсет. Продукт думает: зачем это нужно бизнесу и пользователю, и спрашивает бизнес, почему пользователь будет покупать именно этот продукт. Ориентация на цели, сроки и бюджет вторичны. Гипотезы и проверка через данные - не фантазии. Постоянные улучшения, гибкость, толерантность к неопределенности. На дискавери надо не все: спрашивать зачем, понимать потребности пользователя, связываем задачи бизнеса с пользователем (это умеем), строим гипотезы, не боимся неопределенности. Шаг 2. Ищем знакомое в незнакомом, перепрошиваем и развиваем навыки. Cust Dev похож на бриф, исследуем конкурентов - как заказчика, на открытых данных, объемы рынка - по открытым данным конкурентов. Cust Dev.
Исследование конкурентов. Поле конкурентов и ответ - стоит ли лезть на это поле. Фреймворков много. Ее любимый - магический квадрант Гартнера, Фичи и UX, кружок - объем рынка. Объемы рынка. Зачем? Если пришли с идеей, а денег нет - люди не привыкли платить - то лучше не лезть, это трудно. Фреймворков много, наиболее легкий - TAM-SAM-SOM. Все эти фреймворки в пределе сводится к здравому смыслу и business view. Неопределенности стало меньше, но появился хаос данных. Шаг 3. Гипотезы - проводник через хаос данных. Научиться мыслить гипотезами. Верхнеуровневые рамочные - цифровые - улучшение продукта. Рамка - идея, например, всем будет полезен магазин готовых маршрутов. Цифровые про MVP, проверка продукта. Шаг 4. MVP. Определились с составом продукта, теперь его надо обрезать. Все кивают на концепцию, но как только реально доходит до урезания - не режут. Не переживайте, что первый продукт бедный - будет возможность дополнить. HADI цикл. И есть лайфхак: у вас будет не бедный продукт, а сфокусированный или сконцентрированный, смена термина многое меняет в восприятии. Здесь много трагедий и боли. Стартап хотел цивилизовать рынок щебня. Ребята 4 месяца разговаривали на прототипов. Самолет, к которому прилепили бассейн и спортзал. Срезать не удалось, потому что MVP срезать не удалось, заказчик полюбил. В результате MVP разрабатывали год, потратили все деньги ,на маркетинг и продвижение не осталось - а это дороже разработки. А сейчас конкуренты пришли с идеей выкупить идею - рынок созрел. Для сокращения MVP - делайте быстро и малыми силами. Не 30 человек год, а три за месяц. Шаг 5. Во-время останавливаемся. Discovery - продуктовая гипотеза. Весь продуктовый цикл не закрываете. Там маркетинг, юнит-экономика и много чего. И в заключении. Иногда discovery - крик бизнеса о помощи, не игнорируйте. Бизнес-аналитик - может сделать. Вера Бонарева из Сбербанк. Преодоление сложностей в интеллектуальном распознавании документов: инновационные подходы и роль LLMЭто блиц-рассказ о том, как усложнялась по мере реализации задача распознавания документов, появлялись все новые кейсы и способы распознавания.
Такое вот усложнение системы в ходе разработки и эксплуатации - типичная история. Наталья Семенова. Коллеги, мы тоже на одном языке говоримРассказ об известной всем аналитикам, и не только им, проблеме, что одни и те же слова в разных проектах могут означать совершенно разное. Потому что значение слов определяет контекст, к которому относится не только предметная область, но и способ ведения проекта, например, в заказной, продуктовой и inhouse-разработке работа с требованиями сильно отличается, хотя описывается одним и тем же выражением "собрать требования" или "выявить требования". Проблема как бы известна, но многие почему-то уверены, что это происходит потому, что люди неправильно употребляют слова. начинается холивар и апелляции к словарям. И это, в том числе, проявляется на собеседованиях: ответ отклоняют как неверный. А реально проблема в различии контекстов. Это даже в BABOK есть, правда очень кратко. И аналитик должен уметь распознавать контексты, и дальше вести коммуникацию с их учетом. А если подозревает, что контекст ему не знаком - то не стесняться спрашивать или иным образом уточнять значения слов. В докладе - много кейсов, а также подходы к прояснению контекста. Этого доклада не было в программе - Наталья выступала на BarCamp, рассказывал доклад, который делала на Стачке, и то ли конференция вообще не вела запись докладов, то ли запись этого не получилась. А AnalystDays ведет запись и трансляцию не только основных треков, но и BarCamp, так что теперь запись есть. Для начала были кейсы, касающиеся различных типов проектов. Потому что именно о них часто не подозревают, и на собеседованиях наступают на эти грабли. Мини сценка, разговор двух аналитиков:
Собрать требования.
Это различия внутренней, заказной и продуктовой разработки - требования собираем по-разному. И это - за рамками разговора. Взаимодействие с командой.
Разные методы работы команды. И отличия надо понимать, выяснять. что тебя ждет в проекте и действовать сообразно, или предлагать изменения, тоже осознанно. А что делать до разработки?
Тоже заказная и продуктовая разработка. Ретро, разное отношение
Зависит от зрелости бизнес-процессов: хаотичные, по регламентам, постоянные улушения - на слайде была шкала из 5 уровней. Я бы отнес это не к зрелости бизнес-процессов, а к культуре ведения проекта, но такое различие терминов - тоже часть культурной рамки. Степень свободы аналитика
Начинающим интересно по регламентам, опытные - сами решают по ситуации. Как выявлять диференцииаторы контекста? Рассматривают 4 квадранта: Знать - Узнавать; Все просто - Все серьезно. Все просто.
Все серьезно.
Как узнавать дифференциалы в серьезных случаях?
По концептуализации у Натальи был доклад на прошлой AnalystDays. В конце было еще обсуждение с кейсами от участников. Галина Кореневская из ГК Самолет. Как мы изобрели Business and Data Flow DiagramВ 2022 Самолет решил стать лидером рынка за счет покупки крупной компании. Перед Ит поставили задачу поддержать быстрый переход компаний в однородное состояние, для чего сделать описание бизнес-процессов, которое бы соответствовало действительности. И разобраться с более, чем 350 ИТ-системами. Для описания бизнес-процессов надо выбрать нотацию. Они собрали цели бизнеса и ИТ. Бизнесу достаточно BPMN, а ИТ, помимо описания бизнес-процессов, хотели видеть его поддержку ИТ-системами, сущности и интеграцию систем. И они доработали BPMN-нотацию для описания. Рассказ был о доработках и о требованиях к описаниям.
Результаты.
Григорий Печенкин. Пять граней мышления аналитикаКто такое - хороший аналитик? Это человек с особым типом мышления, у которого есть 5 аспектов. Доклад был о них, на кейсе работы с обобщенным университетом по внедрению системы индивидуальных образовательных траекторий студентов. На первой встрече присутствуют трое: Проректор, который хочет модель, где студенты сами выбирают что изучать; руководитель учетно-методического отдела, который говорит, что для этого надо совсем немного: зафиксировать индивидуальные планы и сделать выбор нагрузки; и главный от ИТ, который поддерживает и говорит, что все данные есть - остались от предыдущего заказчика. Проректор слышит коллег и говорит: ОК, все поддерживают, договорились, работаем. Вопрос: о чем договорились, ко эти лица и что делать дальше? И тут нам как раз помогает способы мышления. 1. Системное мышление. Смотрим на мир как на систему систем. Книжек - много. Но! это не формальная теория, которая дает аппарат, а философская концепция с шаблонами мышления. У него было три подхода: в институте, (2) когда стал аналитиком - Системный анализ, почитал книгу, к жизни отношения не имеет (3) книга где описано как действует. Сколько уровней требований? Три. Это - хорошее число. А еще теория систем: наш продукт - часть надсистемы, и оттуда верхний уровень. Внутри системы есть взаимодействие с внешним миром - это пользовательская и интеграция, окружение. И третий - требования к устройству (функциональные или системные). И это - причины классификации, а не формальная классификация. Три стейкхолдера, они на разных уровнях.
2. Логическое мышление. Иногда логика дает сбои - когнитивные искажения и другие. Искажения частное-общее: Чрезмерное обобщение, эффект знакомства, иллюзия кластеризации. Решаем не задачу, которая стоит, а знакомую: фрейминг и другое. Трехцветных котов не бывают, только кошки, так говорит генетика и вы это знаете. Приходит заказчик, говорит: у меня трехцветный кот. Как к этому относиться? Может быть, это исключение - хотя генетика теоретически не позволяет, реально на 3000 котов один такй есть. Либо у кота просто три оттенка серого цвета, и еще голубые глаза. Или модный постер с многоцветным котом. Наши ограничения, что трехцветных не бывает - эффект фрейминга. Фраза - гипотезы, что за ней - отсечение гипотез. Дальше - уточняющие вопросы. И верификация. Потом - вывод. Разветвляющийся конус гипотез, потом - схлопываем. Главное - не пренебрегайте верификацией. В 9 из 10 проговорите то, что всем понятно. Но в 1 из 10 оказывается, что все неправильно. Главный по ИТ может быть
И надо уточнять. И далее - уточнять его интересы 3. Мир интересов. Его надо видеть. У Главного по ИТ могут быть такие интересы:
У других - тоже свои интересы, и получается диаграмма интересов. Луковичная диаграмма. Рисуем стейкхолдеров по слоям подсистема-надсистема, и рисуем интересы. 4. Критическое мышление. Во всех университетах говорят, что это надо ставить, но понимают по-разному. Его понимание - это Сомнения на пути к истине. Профессия, где необходимо - судья. Состязательный способ ведения процесса, две стороны. И судья должен смотреть обе точки зрения, полагаться на независимые свидетельства. В жизни тоже: что выбрать айфон или андроид. И убеждения - основание. На вас можно повлиять.
Манипулируют все. родители детьми, супруги друг другом и так далее. И когда приходите со своей системой - она влияет на интересы и весь спектр может быть применен. 5. Визуальное мышление. Это было кратко, как замыкание предыдущих. При этом под визуальным мышлением Гриша имеет ввиду представление не виде образов, а в виде схем, графическое отражение различных объектов и связей. Наталья Должкевич из Райффайзен. Как когнитивные искажения портят продуктПредупреждение: Я записывал на слух, в телеграфном стиле, так что формулировки могут быть искажены
Что делать: отталкиваться от user story - что нужно пользователю. И молчаливый брейншторм - идеи на стикерах, и все зачитывают - чтобы полнота картины. Как победить когнитивные искажения? Их нельзя победить, их можно контролировать и отслеживать. Нужно слушать и анализировать себя - как пришли к этому выводу. Для многообразия мнений у них в команде используют молчаливые брейнштормы - есть те, кто подавляют, а есть тихие с ценными идеями. Лев Немировский из ПСБ. От проектирования до поддержки: работа с AsyncAPIОсновная мысль доклада в следующем. Для синхронного API задача качественного описания с версиями, примерами, контролем и генерацией кода и остальным необходимым достаточно технологично решена: есть спецификация Open API, есть Swagger и другие инструменты. А для асинхронного часто по-прежнему используют вики с сопутствующими проблемами: описания разъезжаются с кодом, примеров нет или мало и так далее. Но вышла спецификация AsyncAPI, которую тоже поддерживает Swagger, и для асинхронного взаимодействия тоже можно создавать технологичное описание. Итак, Где описывают задачи? Одни в таске, другие в вики. Вопрос - версии API, которые поддерживают параллельно - в коде это git. А здесь? Описания разъезжаются с реализацией. Разработчик решил добавить статус, сделал, а в описание не отразил. Или уточнения к задаче пошли через чат, и в чате остались. Онбординг нового с такой докой - очень тяжело. А еще нет единого формата, каждый проект приносит свое. Версионности и валидации схем нет, это статьи в конфлюенс. С синхронным взаимодействием это полечил OpenAPI: генерация, валидация, единая точка правды. Хотелось бы такого для асинхронного. И это решает спецификация AsyncAPI. Она очень похожа на OpenAPI, и это - огромный плюс. Поддерживает все протоколы: Kafka, Rbbit, IBM MQ, Apach Pulsar - и там можно указать особенности системы. Включает Info, Сервера, Сообщения и Конфигурацию, был разбор. Лев сделал специальный репозиторий - можно сделать репорт, попробовать поменять. Там github action на изменения. Документация - swagger. Внедрение спецификации не исключает все ошибки. Что бывает?
Есть утилиты проверки и логика. Команды разработки могут свои инструменты писать. Шаблоны и review - у нас Doc As Code - и можно делать merge и review. Начинайте с простого - документация. Потом проверки и расширение. ЖЦ асинхронного похож на синхронный. Swagger. Async API studio. IDE-интеграция, ChatGPT Co-pilot. Обратное проектирование - он не сторонник, он считает ,что проектирование сначала. Но если API есть а доки нет - есть инструменты для любого современного языка. Тестирование и валидация - тоже много инструментов. Есть mocker - чтобы создать псевдосервер для тестирования. Генерация кода. Главное - не экономия, а то что новая версия спецификации и генерации позволит понять, что изменилось, и тесты обвалятся. Swagger умеет. Публикация - тоже: html, makrdown. Есть генераторы SDK на множестве языков, проверки на предпроде и проде. Изменение процесса.
Итого - единый стандарт, автогенерация кода, валидация, упрощение коммуникаций. Татьяна Онофрюк СберЗвук. Все лучшее сразу - как улучшить подбор артистов для нового пользователя музыкального стримингаДоклад о персонализации предложения для первого касания стриминга новым слушателем - чтобы ему с большей вероятностью понравились эти предложения, чем если просто предложить самое популярное, и он остался на сервисе. Участник - новыЙ, однако он может быть известен другим сервисам экосистемы Сбер и ее партнерам, поэтому для него можно получить вектор данных из 300 параметров. Вектор содержит свернутые числовые данные, персональные данные из него напрямую не восстанавливаются. Однако, можно получить такие же вектора на уже имеющихся участников сервиса, музыкальные вкусы которых известны. И дальше предположить вкусы нового человека на основании схожести векторов. Понятно, что напрямую посчитать схожесть векторов со всем массивом участников - тяжело. Поэтому для начала мы строим кластеры участников по их предпочтениям. Для уменьшения вычислительной сложности кластеризации вектор параметров свертывается от 300 параметров до 50. А к кластерам предъявляются следующие требования: кластеры должны быть достаточно дифференциированы по музыкальным предпочтениям, и достаточно хорошо делить аудиторию на группы. Конструкции, когда есть один большой кластер. в который попадают почти все, вокруг них малые специфичные - не интересно. и также не интересно, если слушатели будут различаться параметрами, но предпочтения будут похожими. Оценивать выполнение требований в пространстве из 50 параметров не возможно, поэтому для визуальной оценки кластеризации применяется свертка на плоскость, где изображаются отдельные группы и их объединение в кластеры. Именно в этом виде в докладе были результаты. В докладе были методы, которые применялись для кластеризации и ее результаты. Получилось 16 кластеров музыкальных предпочтений по жанрам: поп, рок, шансон, разные смеси жанров, дифференциация по современности. Дифференциирующие параметры - пол и место жительства: Москва, Петербург, регионы. Но этими параметрами дифференциация не ограничивается, и не для всех кластеров все параметры существенны, есть смешанные группы. Подробности - в презентации. Дальше провели А/Б - тестирование, получили хорошие результаты. Что важно для кластеризации: надо сформулировать требования на кластера до старта, и проверять их выполнение по результатам кластеризации. |
Блоги друзей |
