2023-06-24: ЛАФ-2023 - много общения и интересных докладов

Короткая ссылка: LAF-2023

Ссылки сюда (2) →

О других конференциях

В середине июня был прошла очередной Летний Аналитический Фестиваль (ЛАФ-2023). Он традиционно проходит в субботу-воскресенье на турбазе или доме отдыха, и в этом году вернулся в пансионат Плес на берегу Волги недалеко от Костромы, где проходил в позапрошлом году. Несмотря на название «фестиваль» и формат проведения, это — полноценная конференция с качественными докладам и мастер-классами, в которой я участвую с 2010 года, хотя и с перерывами. А формат дает возможность интенсивного вечернего и ночного нетворкинга, который посвящен преимущественно рабочим вопросам. И то, что это происходит открыто, что каждый может присоединиться к любой группе и принять участие в обсуждении дает возможность получить разнообразные взгляды на насущные вопросы, сравнить твои взгляды с чужими. Это — реальная ценность ЛАФ, отличающая его от других конференций. Правда, в этот раз было реально холодно, ниже +10 ночью, а многие участники на это не очень рассчитывали, и это снизило интенсивность, но общения все равно было очень много. Так что зову всех участвовать в будущем, тем более что организаторы держат очень демократичные цены и это - еще одна фишка конференции.

Дальше, как обычно, обзор докладов. Мастер-классов там нет — они длинные, и я предпочитаю послушать несколько докладов вместо одного мастер-класса. Но по отзывам они тоже очень качетсвенные. Я выступал с докладом DDD: модели вместо требований 9 лет спустя, в котором достаточно подробно разобрал тему. Доклад получился длинным, час вместо обычных 40 минут, что как раз дало такую возможность. Спасибо организаторам, когда я на прогоне спросил «что исключить», они сказали, что исключать не надо и увеличили слот. Его полезно рассматривать вместе с докладом Требования или модели - как писать постановки (AnalystDays-2023), который я делал в апреле, но там DDD посвящено только шестая часть доклада, а тут развернутый рассказ.

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

Об учебном взгляде аналитика на работу

На фестивале я сделал наблюдение, которое опубликовал отдельным постом (репосты в группы AnalystDays и ЛАФ. Во всех трех местах идет обсуждение, при чем сильно разное и содержательное, до полусотни комментариев в день. Я его потом добавлю в отчет, а пока — сам пост.

У многих аналитиков неявно есть «учебный» взгляд на работу. Что я имею ввиду? Когда вы учились в школе и, позднее, в институте, ко всем учебным заданиям существовала инструкция, как его сделать, чтобы получить хорошую оценку. Понятно, что задания могли быть разные, предполагать творчество, например, сочинение, учебный проект или диплом, но это творчество касалось определенных элементов и по их поводу инструкция тоже в некотором виде. А еще критерием успеха являлась именно полученная оценка, которую поставит преподаватель, и эта оценка «по умолчанию» считалась верной, изменить ее требовало очень больших усилий. И дальше все это проявляется и на конференции и в работе: от докладов ждут, что там будет такая инструкция, по которым можно выполнять свою работу. А оценкой работы считают мнение принимающего твой документ, а применимость документа для следующего шага. И неявно предполагают, что оценка зависит именно от следования правилам.

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

Чтобы перейти от такого подхода к реальной работе на достижение результата надо менять мышление. Такие тренинги есть для руководителей, это переходе понимания ответственности от responsibility к accountability, но вот для аналитиков таких материалов нет, этому не учат, и вообще тема не находится в фокусе внимания. И, возможно, стоит подумать в этом направлении при подготовке конференций. Впрочем, я могу ошибаться и переоценивать значимость проблемы. Что думаете?

Сергей Нужненко. Занимательная картография и археология для аналитиков

По системам часто нет документов или громадное количество доков с инкрементом без целостного описания. Это может быть и с легаси, и с относительно свежей системой — пара студентов за год могут очень многое написать. И получается змея, кусающая хвост: бизнес спрашивает у аналитиков, аналитики — у бизнеса. Реверс за 10% затрат для системы которую 6-10 человек писали 10 лет — не реалистичен. Надо уметь понять существующее относительно дешево. Как сделать обрывочную, неточную, но полезную карту. Часто именно такую задачу ставят аналитикам. Об этом — доклад, это и есть картография и археология. Проблема типична, потому что постоянная актуализация — она тяжелая.

Что нам надо картировать, описывает V-модель, к которой сейчас наверху надо достроить бизнесовую часть. И дальше был краткий рассказ про карты, которые прижились.

• Короткая бизнес-модель
• Карта деятельности: CJM + Service, BluePrint, Карта процессов; Value stream mapping. B все это — на встречах
• Карта пользователей историй Story map
• Карта системного ландшафта — потоки данных
• Карты систем: функциональная; информационная; развертывания доступа и обслуживания — это архитектура

Бизнес-модель схематезирована по Остервальдеру, хотя Сергей на него не ссылался.

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

Карты деятельности: Карта процессов и Цепочка прибавленной стоимости; Customet Journey Map + Service BluePrint — что за сценой.

Из CJM получается Story map. Есть еще Impact Mapping: цели, деятельность. Но на ней можно потерять важное.

Раньше аналитик описывал поведение системы в целом, и команде было достаточно для разработки. А сейчас требуется перевести это во взаимодействие сервисов, фронта и бэка. Это DataFlow диаграмма. Что сервис хранит, что он получает, что выдает другим. Форматы, что передается, интерфейсы.

Археология выкопать как сейчас — это будет на мастер-классе.

• Потоки данных между системами
• Контейнерный уровень — отдельно развернутые приложения (сервер, броузер и т. п.). И потоки данных между ними.
• Компоненты.
• Код.

Постепенное погружение по уровням.

Функциональные карты: use case, DFD, User story mapping, Sequence, Robustness… Информационная карта. Функции меняются, информация живет годами.

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

Я отмечу, что тут все равно много получается. Но! Это дешевле, чем полное описание «по старым канонам», и реально можно делать неполно.

Бунто Татьяна. ETL-интеграции без валидола. Хороший доклад про разработку надежно работающей интеграции между разными системами

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

• ETL: Extract — Transform — Load. Разобраться надо со всеми тремя частями. И нужны команды, готовые отвечать.
• Надо всегда рассчитывать, что после загрузки будут корректировочные инкременты, до нескольких лет.
• Перелив данных может идти долго, у них было до 20 дней. Исправление и полная перегрузка при этом тоже 20 дней, полезна точечная перегрузка.
• В реальном мире часто интегрируют сразу на продах. Или Prod->Test. Потому что тестовые контура могут отсутствовать или не содержать репрезентативных данных. И это требует заранее проработать доступы, и дает требования на нагрузку.
• Сделайте чек лист условий для запуска: реализованы представления, открыты каналы, установлены нужные релизы и так далее.
• Трассируем бизнес-данные на их хранение в системах источниках. Например, где правильные телефоны и емейлы для юриков и физиков — это может быть в разных местах.
• Фильтры отбора: только клиентов с контрактами, или не грузите технических абонентов, или не грузите если есть признак устаревшего. Все это надо перевести в технические условия и посмотреть, что получается.
• Система-приемник. Там таблицы, ключи, обязательные поля, которые могут быть пустыми в источнике — что делать.
• Совместимость типов, особенно с датами и часовыми поясами. Что делать, когда строки не лезут в приемнике.
• Протокол системы-приемника. Например, система может быть рассчитана только на ежедневные инкременты, а может быть на нумерацию.
• Ключи. Бывает, что в системе-источнике контактные лица юрика — вообще не отдельные сущности-люди, а в системе-приемнике есть таблица физ-лиц контактов с идентичностью.
• Событийная модель. Не только создание или изменение, а с учетом фильтров. Например, абонент стал анонимным, которого не грузим.
• Логирование. Чтобы интеграция записывала, что сделала, и почему упала, и фиксировала — что там было, и в каком сообщении это пришло.
• Срочные догрузки: я нашел карточку, и срочно загрузите. Да еще со связанными сущностями. И это задача точечной перегрузки. В том числе — перегрузка пула ошибочных записей, которые нашли.
• Сверки могут быть, но они дорогие для нагруженных базах. Поэтому это обычно не регулярная процедура, а разовая.
• На начальной стадии нужно тестирование, в том числе через сверку на репрезентативных кейсах.
• Все учесть невозможно. Надо мониторить и быть готовым ко всему. Например, прилетит огромный инкремент, потому что в системе-источнике решили что-то глобально обновить.

Андрей Василевский. Мысли как архитектор. Распиливаем монолит с помощью шаблонов DDD

В докладе — конкретная методика. Сначала Event Storming для выявления групп процессов. Добавляем набор объектов, с которыми эти процессы работают. Кластеризуем процессы по их общему, визуально группируем. Границы кластеров — размыты. Если просто использовать эти группы для разрезания монолита, получится микролит — сильно связанные сервисы.

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

Дальше — доменная модель в каждом контексте, агрегаты и сущности, их инварианты. И начинаем писать код и рефакторить.

Михаил Рейнганд. Как придумать фичу, отталкиваясь от проблем пользователей

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

Одна из проблем — недоверие клиентов звонку из банка, потому что много мошенников представляются сотрудниками. И была гипотеза как это недоверие снять: сделать проверку по коду, который клиент сгенерит, а сотрудник — назовет. Сделано в приложении — требование безопасников было про доверенный контур. сделали макет, проверили на закрытой группе респондентов.

Дальше был рассказ про технику — чтобы раскатить фичу без обновления приложения, потому что AppStore заблокирован, для этого использовали SDUI — управление с мидла фронтом, тогда присылают json, который фронт отрисовывает. В идеальном мире сокращается фронт-разработка. Но есть недостатки. Андроид и iOS — разные компоненты, зависят от версии. Получилось не очень хорошо по эргономике, ну, что поделать. Фича в обычном состоянии выключена, включается безопасником через push-уведомление с нулевым приоритетом, в уведомлении — сразу ссылка на конкретный экран приложения. Может не сработать в конкретной версии и на конкретном устройстве — там содержательное сообщение об ошибки.

Показали клиентам, сделали широкую рекламную компанию. Решение взлетело. Собирают регулярную обратную связь — ежемесячно общаются с сотрудниками, после каждой верификации сотрудник пишет обратную связь, и должен указать успех-не успех — тех.ошибка. Пока операторы еще учатся разбираться с ошибками. Фичу выкатили в конце апреля, за май примерно 5 фродов предотвратили. Есть техническое ограничение: интернет вместе со звонком невозможен в 3G и если звонок и инет на разных картах. Это — одна фича, по проблемам CJM планируются и другие, например, подтверждение без звонка.

Евгений Скориков. Нефункциональные требования? Модели обеспечения качества!

Очень хороший доклад, о том, что нефункциональные требования в их привычном виде «отказоустойчивость 99.5%» или «отклик системы 5 секунд» — совершенно бесполезная вещь: непонятна осмысленность, способы удовлетворения и тестирования и риски. 99.5% — это 0.5% сбоев, если система не работает в год 1.5 суток подряд — это как, нормально? Для многих — ненормально, хотя в норматив формально укладывается. В общем, эта критика — понятная, эти требования часто берут произвольно. Например, по производительности, кстати, нет достоверных исследований: как именно скорость работы сайта влияет на бизнес. Понятно, что если ваш сайт жутко тормозит, и есть сайт конкурента, который делает все тоже самое и быстро, то люди уйдут туда. Но в реальной жизни сайт конкурента делает НЕ тоже самое, там есть чего-то меньше и чего-то больше, у него есть другая эргономика. И как это влияет? Исследований нет. Честное исследование — замедлить сайт для части клиентов и сравнить, но на это ни один бизнес не пойдет.

Гораздо интереснее, что в докладе был рассказ, чем их следует заменять, чтобы это имело смысл и реально работало. С практическими примерами, которые в интерактиве обсуждали с аудиторией. Общая схема такова.

1. Берем аспекты работы с системами: отказоустойчивость, производительность, масштабируемость, эргономичность интерфейса и другие.
2. Для каждого аспекта есть специфические проблемы, и мы декомпозируем систему с точки зрения этих проблем. Например, для отказоустойчивости смотрим на отказы базы данных, серверов приложений, сетевой инфраструктуры, клиентских приложений. Для производительности — деградацию на выполнении различных функций. И так далее.
3. Выписываем возможные проблемы в каждой части, оцениваем их значимость: если это случится — каковы последствия, потери для бизнеса.
4. Для проблем — есть специфические тактики предотвращения, которые снижают ущерб и имеют определенную стоимость. Выбираем тактики и проектируем варианты решения.
5. Выбор решения — по балансу потерь против стоимости.
6. Проектируем тест выбранного решения.

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

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

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

В целом — очень конструктивный и полезный доклад, спасибо Евгению.

Мой отзыв вызвал большое обсуждение у меня в чате с Денисом Бесковым и Филиппом Дельгадо.

Denis Beskov: «непонятна осмысленность» — для этого есть как минимум 2 инструмента:

1. трассировки на business capability
2. атрибуты требования, включая rationale, например, согласно INCOSE Requirements Writing Guide

MaximTsepkov: Инструменты есть, но ими не пользуются, множество ТЗ требования именно в формулировках, приведенных как примеры. А эта модель как раз приводит их к разумному варианту.

Denis Beskov: Я не понял, как она приводит. И вообще в какой части работ это происходит — при постановке задачи на проектирование или при проектировании?

Denis Beskov: А по мне так атрибуты качества Ит-системы выводятся из capability constraints бизнеса. Надо уточнять требования авторов бизнес-модели и владельцев capability относительно той самой непрерывности бизнеса, business continuity и если это архитектурная работа, то скорее бизнес-архитектора, который определяет его свойства или бизнес-аналитик. Так что повторю, что из-за неумения работать на бизнес уровне потом у айтишников такие сложности.

MaximTsepkov: Capacity constraint — они все реально мягкие, то есть там нет точных значений, а всегда диапазон, да еще против стоимости их выполнения. А стоимость зависит от техники. Собственно, проблема классической модели через требования — в том, что стоимость выполнения требований она не учитывает, в ней мест места, где происходит поиск баланса. В том, что говорит Женя, это место явно есть. Происходит это при проектировании, потому что это связано с другими частями проекта.

MaximTsepkov: И да, ИТ плохо умеет работать с бизнесом, потому что исторически их жестко разделили: есть бизнес, который выдает требования, которые ИТ исполняет. Это разделение — организационное и методологическое. Не зря же профстандарты позиционируют бизнес-аналитика НЕ как ИТ-специалиста. Сила организационного разделения — разная, в inhouse и продуктовых компаниях оно слабее или отсутствует, Agile-методы тоже его снижают. А методология требований — она его содержит.

Phil Delgyado: Вообще, доступность в процентах (sla) считают только для плановых остановов. Для разных инцидентов используется пара RTO/RPO, которая легко тестируется изначально. Ну и вообще доклад (судя по описанию) делал 'системный аналитик' (в плохом смысле этого слова), а не архитектор.

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

Phil Delgyado: Модель как раз не очень приводит, в ней технические детали (п2) стоят перед бизнесовыми (п3). И проблема с 'НФТ' (то, что привел автор в качестве примера — не является НФТ) — как раз в отрыве от бизнес-составляющей. Если ее добавить, то и архитектура становится очевидней и тестирование. А если сначала ставить 'падение БД', а потом 'бизнес-последствия', то будет сложно.

Phil Delgyado: По хорошему работа с НФТ — часть архитектурной деятельности, до разработки и до системной аналитики (как ее понимают в большинстве компаний). Более высокий уровень.

MaximTsepkov: Реально у бизнеса жестких требований нет. В том смысле, что он готов платить за определенное качество определенные деньги и обсуждать баланс — это как с фичами, они нужны при условии, что их стоимость оправдана. При этом, как и с фичами, функция стоимости — сильно не гладкая, а ступенчатая, холодный бэкап и горячее резервирование на standby дают сильно разные возможности за разные деньги, также как возможность автономной работы приложения против возможности работы только при подключении к инету, и там еще есть свои особенности по скорости подключения. Методика у Жени как раз позволяет превратить обобщенные НФТ в фичи, конструкция которых принципиально понятна, и дальше — выяснять, что из них бизнес готов купить.

MaximTsepkov: Делает ли это системный аналитик или архитектор — вопрос вторичный. Но вообще, я тут понял, что с архитектурой та же фигня: архитекторы не оценивают ее стоимость и не предлагают варианты, а постулируют «делаем так». Хотя, может, хорошие архитекторы это делают. Но в архитектурных докладах я такой стоимостной составляющей не слышал.

Phil Delgyado: Нее, у бизнеса есть вполне понятные требования и цены, просто не все умеют их вытаскивать. И общая архитектура системы в первую очередь зависит от НФТ, там нет возможности демонстрировать бизнесу 'можно так, а можно так', основные выборы уже не изменить. И выборов гораздо больше, чем бэкап или active-standy, их десятки только для HA, не говоря уж про время отклика и так далее.

Phil Delgyado: Почему в классической модели нет учета стоимости и создания баланса? Это базовая задача архитектора — осознавать и стоимость и требования бизнеса и предлагать адекватные решения. Собственно, потому архитекторы и вообще нужны, иначе хватало бы продуктов и разработчиков. Но если в компании нет архитектора, то да, приходится строить подобные кривые конструкции

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

MaximTsepkov: Проекты, когда реально идет обсуждение, а нельзя ли ограничиться Standard edition вместо Enterprise, а недостающий функционал сделать своими методами и будет ли это дешевле, потому как из enterprise нужно немного а разница цен, если умножить на число инстансов — велика — редкое исключение, они у меня были. И архитекторы об этом, как правило, вообще не думают — что будет сильно дороже. Или предложить отказаться для конкретного набора рабочих мест от Windows, при том, что на Linux есть определенные проблемы, включая администрирование — если ты при этом экономишь несколько тысяч лицензий.

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

Ирина Баржак. Как вытащить требования из заказчика без гипноза (и без паяльника)?

Я слушал только вторую половину доклада, потому что он пересекался с докладом Жени Скорикова. Поэтому кратко. Ирина рассказывала модель GROW структурирования встречи и задавания вопросов, которая разработана в коучинге. Встреча делится на четыре части

1. Goal — Цели, зачем почему и что мы хотим сделать
2. Reality — реальность сейчас, как это устроено, какие с этим проблемы, почему они появились и так далее
3. Options — возможности по решению проблем: какие вы видите, чтобы вы посоветовали в такой ситуации другу и так далее
4. Way Forward — как приступить к действиям — какой первый шаг, что надо предусмотреть и так далее

К каждой части на слайде было больше десятка вопросов, которые могут помочь вытащить информацию. вопросы — нетривиальные, участники придумывали свои с интересными формулировками. Например, «как наши действия помогут вам достичь наших целей?» — это про цели.

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

Высотина Александра. Vision recognition: как работает распознавание образов/лиц

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

Дальше был обзор-ликбез. Различие биометрических и не-биометрических персональных данных. Биометрические:

• все изображения на документах, которые позволяют куда-либо пройти — паспорт, водительское, пропуск
• все 3d модели, в том числе медицинские снимки
• все фото-видео, приобщенное к материалам дела

Все остальное — просто персональные данные. Съемки в публичных местах, их выкладка в инет и обработка — возможны, здесь российское правовое поле свободнее западного.

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

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

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

А еще были всякие интересные кейсы. Например, сеть научили не путаться распознавать толпу — и пропускает людей с майками, где фото с толпой. Был кейс, когда они предлагали свое решение в Штатах и обломилось на том, что сеть была необучена на неграх, и она не смогла вообще опознать потенциального партнера. При умирании лицо сильно меняется, был проект для МВД по опознанию трупов — результаты не достигнуты. А вообще лицо успешно опознается 6-7 лет. Но вот сезонные изменения лиц — очки и кепки летом, маски при пандемии и так далее — нарушают распознавание, получаются ошибки первого рода. Правда у Apple распознавание дообучается, узнает тебя в очках — но тут вопрос про ошибки второго рода.

Андрей Зеров. Chatgpt: победит ли аналитик в борьбе с ИИ?

Выводы доклада: в противопоставлении нет смысла, наоборот, стоит использовать ChatGPT как помощника в работе — он классно порождает многие документы, да еще в нужном стиле. Например, может написать письмо в деловом стиле, смысл которого ты ему объясняешь в запросе. Может сделать таблицу с заданными колонками, описать структуру базы данных, сделать диаграммы на PlantUML. При этом ты ставишь ему задачу в достаточно общем виде, абзацем текста, а потом — уточняешь. Ну а потом сам дорабатываешь результат. И вот для оценки результата важен собственный опыт, потому что он отвечает в любом случае, додумывая относительно произвольно — как поисковый запрос всегда выдает ответ, но далеко не всегда — с нужной информацией. Начинающий аналитик оценить ответ не сможет, у него не хватит опыта и знаний. О том, как формулировать запросы Андрей подробно не рассказывал, он сослался на доклад Юры Куприянова «ChatGPT в работе аналитика» на весенней AnalystDays, их можно посмотреть в презентации, которая уже опубликована на сайте конференции. У меня тут возникает вопрос: как скоро умение работать с ChatGPT появится в требованиях к компетенции аналитика и будет проверяться на собеседованиях? Или оно не появится, как нет требования к умению искать информацию в интернете — хотя далеко не каждый умеет делать это эффективно, и это напрямую влияет на освоение аналитиком новых областей.

Несколько ссылок по теме: Доклад Юры Куприянова, статья Юры Куприянова на хабре, статья Сергея Гевлича, пост Анатолия Левенчука и прикольный опыт Леонида Каганова (надо раскрыть ссылку «умилиться»).

Мария Старостина. Не провал, а ценный опыт: как избежать ошибок в продуктовой разработке

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

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

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

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

— Максим Цепков • 12:40, 24 июня 2023 • нет комментариев