Я — Максим Цепков приветствую Вас на своем сайте
|
Я буду рад любым комментариям и обсуждениям. Авторизоваться для этого можно, регистрируясь на сайте или через OpenID. При желании, вы можете размещать здесь свои материалы по тематике сайта. MaksWiki содержит 669 статей 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
|
Последний пост блогаВ прошедшие выходные второй раз прошел Winter Analуtical Weekend — конференция аналитиков, зимний брат Летнего аналитического фестиваля (ЛАФ). Он ориентирован на практику, основное содержание — мастер классы, которых было три трека. Но один трек докладов тоже был, и я, в основном, был на нем. Среди докладов сильно звучала тема ИИ, но другие темы тоже были. Было много нетворкинга и совершенно замечательная атмосфера, вторая конференция получилась не хуже, а лучше первой, и это - радует. Благодаря атмосфере общения я подметил одну штуку, которую не слишком понимаю. Некоторые аналитики с гордостью говорят о себе «я — душнила». Спрашивается, чем тут гордиться? Потому как у меня коннотации к этому слову — отрицательные, и появилось оно именно таким образом. Может, это гримасы времени. Раньше при отрицательной оценке другого ты рисковал получить в морду. Потом детям начали объяснять, что драться — плохо. появилось «кто как обзывается, сам так называется». А теперь, получаетсЯ, социум требует признать негативную оценку? Хреновый это социум, на мой взгляд… Еcли у кого есть мнение — высказывайтесь. А теперь — про доклады. Во многих - не просто пересказ, много моих замечаний по содержанию. Это - субъективное мнение, которое не претендует на абсолютную истину и может не совпасть с вашим. Круглый стол о процессах и возможностях ИИНачну я с круглого стола «Стандарты в процессах разработки в эпоху ИИ». Я там активно высказывался, так что заметок не вел, а записываю по памяти. Надо сказать, что обсуждение получилось с активным участием зала, и участники высказывали свои тезисы, а не просто спрашивали экспертов. И этому очень способствовала обстановка: Сергей Нужненко в самом начале предложил сделать большой круг вместо традиционной конструкции эксперты против зала. И это, на мой взгляд, позитивно сыграло. Вообще позиции были очень различны, и у экспертов и в зале. Среди экспертов были Юра Куприянов, который давно использует ИИ в своей работе и рассказывал об этом еще в 2023 году, был Роман Смирнов, который драйвит использования ИИ у себя в компании, потому что в естественном темпе процесс идет медленно и компания теряет возможности, и он рассказывал об этом в докладе на WAW. C другой стороны, Сергей Нужненко относится к текущим возможностям ИИ с большим скепсисом, не взирая на достижения, и эта позиция разделяется рядом участников. Так что обсуждение было жарким. Так что то, что вы увидите дальше — не конспект выступлений экспертов, а мое тезисное изложение содержания вместе с моими оценками, и без детализации конкретных позиций. И я точно субъективен, потому что у меня по многим вопросам есть сформированное мнение, которое я активно высказывал. Итак, тезисы.
К сожалению, это все, что я успел вспомнить, призываю читателей, которые были на круглом столе дополнять. Максим Цепков. Развитие общества в эпоху ИИМой доклад фокусировался не на ИИ, а на развитии общества. По всем сценариям, стабилизация — не близко, лет 15, до 2040 года минимум будет турбулентная эпоха, в которой людям предстоит самостоятельно ориентироваться. И это связано с развитием технологий, не только ИИ, и началось не вчера, а в 1960-х, которые могли привести к принципиальной реорганизации структуры управления обществом. И консерваторы попытались это предотвратить, устроив устойчивое развитие и конец истории. Сейчас понятно, что у них не получилось, но такая попытка привел к тому, что на предсказания на основе циклов развития из прошлого в нынешней ситуации опираться тоже нельзя. Что касается ИИ, то это драйвер, который приведет к не менее, а, вероятно, более сильным изменениям в социуме и бизнесе, чем интернет, google, смартфоны и соцсети вместе, повлияет на решение многих проблем, в частности с образованием. Мне нравится формулировка: Google лишил человека права не знать — каждый может погуглить, а ChatGPT лишил права не понимать — спроси, пусть объяснят. Развитие ИИ продолжается. Только в этом январе появление DeepSeek показало, что будет много экземпляров больших LLM и что при необходимости за разумные деньги можно будет обучить новый. До этого был сценарий, что создание больших LLM будет происходить под контролем управляющих структур — крупных государств и корпораций, и их экземпляры тоже будут под контролем. И это — позитивный сдвиг. В докладе было много подробностей, которые я не буду пересказывать. Видео ожидается, а пока можно смотреть презентацию Развитие общества в эпоху ИИ (WAW-2025). Роман Смирнов. Внедрение AI в процессы IT компанииРоман — директор ИТ-компании. Он был разработчиком, но разрабатывать перестал 15 лет назад, у него было 15 стартапов, 5 успешных. В использовании ИИ он видит большие перспективы. Он дал очень сильную метафору: вот, вы читали фантастику, что прилетят инопланетяне — и они прилетели, жизнь точно изменится и надо в этом участвовать. А участвуют — не все, из зала только половина использует ИИ каждый день, а каждую неделю — не сильно больше. И у него в компании было так же: кто-то использовал, а кто-то — не особо интересовался, естественный процесс распространения шел медленно. И на этом терялись возможности, которые дает ИИ. Возможностей — много, по его оценки, потенциал ИИ сейчас используется в ИТ на процентов на пять, в очевидных местах. А может он больше. Поэтому он процесс внедрения ИИ ускорил, вплоть до встройки в процессы, когда шаг «review AI» становится обязательным для постановок и других вещей. Рассказ был об этом. Как они идут? Принципиальных изменений от внедрения каких-либо сильных технологий тут нет.
Общие соображения
Низко висящие фрукты
По поводу последнего тезиса я хочу заметить, что выглядит как запрос на волшебную кнопку: мы не знаем, что делать с 200 метриками, а ИИ нам скажет. Нет, он не скажет. Хотя помочь — может. Что делать
И так далее. Чтобы внедрять процесс — надо самому попробовать. И на январских праздниках за 10 дней сделал 20к строк кода на разных языках. И получил систему, которая строит mindmap с помощью ИИ — она работает, он выхожил в инет — можно посмотреть http://rmind.ru и бесплатно пользоваться. Суть не в том, что хорошая штука, а в том, что это сделано человеком, который не умеет программировать (хотя 15 лет назад — умел). То есть реально сделать много прототипов, и не простых, проверять идеи. И это — микроавтоматизация. Есть агенская схема, но все-таки, перейти на промптинг — чтобы любой аналитик мог сделать любой инструмент. И есть множество рутинных задач. И уже есть штука, которая делает любое приложения. Неважно, сколько раз вы используете ИИ — вы все равно используете его мало. Был вопрос, Как смотрят безопасники? У них — разные проекты, с госами — не используют. А что касается безопасности кода, то есть LLM и есть программисты, и вопрос не в том, чтобы LLM делал без ошибок, а чтобы с его помощью программисты делал лучше. А закладки могут быть в любом коде, и это надо решать. Ну и можно запускать модельки локально, внутри — тогда информация не утечет. Сергей Нужненко. Как писать сильные требования и постановки задачЭто был рассказ об осмысленном подходе аналитиков к своей работе. Боль, которая вызвала этот рассказ — понятна: часто аналитики отрабатывают свои задачи формально, используя какие-то шаблоны и не вникая в содержание. И это получается бесполезная работа, а аналитик — первый кандидат на сокращение персонала. И Сергей рассказывал, как этого избежать. Мне то, что Сергей говорил — понятно. Почему аналитики так не поступают, а действуют по антипаттернам — неясно, потому что никакого потаенного смысла в этом нет, все известно. Наверное, это вопрос из серии «почему люди не занимаются спортом. хотя знают, что это нужно», и рассказом о пользе спорта ситуация не меняется. Но, может, я тут предвзят, и для кого-то доклад принесет пользу. И перечисление антипаттернов по-любому несет пользу: человек может подозревать, что он зря механически использует шаблоны, потому что «так сложилось в компании». и, послушав доклад, он начнет пытаться поменять ситуацию, и это — полезно. Тема ИИ в явном виде в канву доклада не входила, однако во многих вопросах — звучала. У Сергея большой скепсис по поводу возможностей ИИ. Но при этом он сравнивает возможности ИИ с реальным сотрудником, а требует от него идеального ТЗ в ответ на невнятные пожелания. и говорит, что ИИ к этому не способен. Правильно, не способен. Так и человек не способен. Так что позиция, на мой взгляд, не конструктивна. А теперь — подробнее о содержании доклада. Сергей 30 лет в ИТ, он сооснователь школы системного анализа. И 30 лет назад все знали, что такое сильные требования: полные, непротиворечивые и так далее. А в 2001 году появился Agile и все сломал: не надо писать, общайтесь у доски, фломастер. В 2010 появилась связь, общаться начали дистанционно, а в 2015 появились доски-платформы. Продуктовые проекты растут без аналитиков. Но системы растут, усложняются, появляется много команд, люди увольняются и контекст теряется, перестают отличать баги от фич. Примерно с 2015 появляется тренд «верните аналитиков, мы запутались». Я тут замечу, что сам работаю в ИТ 40 лет, из которых чуть меньше 30 — в enterprise-разработке (с 1995). И все это время, задолго до Agile относился к требованиям с большим скепсисом. Я работал с помощью моделей, это было задолго до появления DDD, и я до сих пор считаю, что это — наиболее эффективный способ разработки. И полагаю, что требования практически не нужны, за исключением ситуации, когда они выполняют роль контракта. который ИТ сначала подсовывает заказчику, а потом им прикрывается: «мы сделали, что заказывали, деньги — на стол, надо другое — с удовольствием переделаем за новые деньги». Впрочем, Сергей дальше говорил про модели, а не только про требования. А разграничение ответственности и организация взаимодействия между бизнесом и ИТ — отдельная тема. Задача Сергея — чтобы аналитики в его команде эффективно писали требования. Много писать — легко, но бесполезно. Надо писать мало и компактно, мало текста и много смысла — это и есть сильные требования. И надо уметь это делать быстро и эффективно. Почему это необходимо? У них 30 человек, 80 фич в квартал, 500 задач в квартал плюс еще 50 инцидентов и 20 багов в месяц, получается 1-2 задачи в неделю на человек. Человек в темпе 1-2 задачи в неделю загружать по задаче 100 страниц в голову. Когда сокращают ИТ, чтобы сэкономить - кого выбирают? Разработчик пишет задачу за 2 недели, а аналитик раздувает задачу ее до 2 месяцев. Да, разработчик за 2 недели напишет не все, но еще за пару недель он доделает, и будет быстрее. И если принимающие решение, увидят ситуацию таким образом, то аналитики будут первыми в очереди на сокращение. Задача Сергей - предотвратить аналогичный сценарий. Кстати, отмечу, что именно таким образом Андерсон объясняет эффективность Agile-методов: если написать ТЗ со всеми хотелками, реально нужных из них будет 20 %, правило Парето тут вполне применимо. А в классическом преокте оценивают полный скоуп, а потом его требуют. В Agile (независимо от конкретного метода) выделили скоуп первых итераций, сделают самое нужное — и проект можно закрывать. Да, где-то ошибутся с выделением, сделают не только 20 % самых нужных, а еще 10 % не слишком нужных — все равно экономия при разумном подходе втрое. И Андерсон этого достигал на реальных проектах. Продолжаю рассказывать доклад. Задача аналитика — не превратиться в «ноги с ушами». Аналитик, который просто запишет то, что ему сказали, возможно, был актуален в прошлом, когда писать не умели. Но сейчас можно надиктовать, транскрибировать и причесать. Можно отдать человеку, чтобы он причесал, writer стоит 200 рублей за 1000 знаков, а LLM вообще делает бесплатно, и это она умеет. Задача аналитика — разбираться и передавать смыслы. Документ — адресный, его пишут, чтобы адресат что-то пошел и сделал, или стал делать иначе — а для этого нужны смысловые представления. Цепочка: кодирование — текст — передача и накопление — интерпретация — действие. Если есть разрыв контекста, цепочка нарушается. Если текст не формирует представление, или представление не соответствует ожиданием — тоже нарушается. Agile-практики выстрелили потому, что у доски контекст синхронизируется. Прототипы тоже его синхронизируют. Но надо разбираться в ситуации. Бывает, что разработка просто не хочет понимать и принимать задачи — тогда аналитик не поможет. Был кейс: 7 менеджеров на 2 разработчика, наняли аналитика, потому что разработчики говорили «пишете дичь». А реально в бэклоге уже было работ на 3 года вперед, и менеджеры все порождали и порождали новое в режиме потока сознания, не было нормальной работы с приоритетами. Если ситуация непонятна — надо выяснить. Если встретиться и выяснить почему-то нельзя, то не надо делать, это бесполезная работа. Малярная бригада из 2 человек за сезон зарабатывает 5 млн, это 500 тр в месяц на человека — есть выгодная альтернатива, и там ты точно приносишь пользу. Антипаттерны, которые ведут к плохому восприятию документа
Антипаттерны, из-за которых трудно понять
Аналитик пишет не текст. Он описывает модель. Значит его можно реализовать в виде схем. А если схемы нарисовать не получается — значит есть проблемы. Можно начать с учебника по формальной логике. Не сложные силлогизмы, а начала. Гусев «Искусство правильного мышления» — полкниги читаются за два вечера, и этого достаточно. В шаблоны укладываем после построения модели, а не до нее, и заполняем в них существенное для этой модели. Если сразу брать шаблоны — в них будет не то, и не так, и куча лишнего. Структурный подход: раскладываем по коробочкам, отделяем устройство коробочек от сопряжения коробочек. Чтобы выстроить коробочки в линейный текст, используйте принцип пирамиды Барбары Минто. Есть задача — встать в тапки адресата (потребителя) документа, так, чтобы разработчик смог выполнить его. Надо понимать, что за разработчик — субподрядчик, аутсорсер, или разработчик внутри команды, которая в контексте. Им нужны разные документы, неуместной может быть и слишком подробная постановка и недостаточно подробная. Если ставки высоки — можно попробовать карту эмпатии или любые методы разведки. У них любая задача у них презентуется лично: аналитик рассказывает разработчику, и тогда они смотрят в глаза, проверяют на понимание. И эта — не пустая трата времени, они проверяли, у них раньше было иначе. Они перестроились, число задач на уточнение и переделку сократилось сильно, и производительность выросла. Можно представлять по чистому скраму на сессии планирования, но им удобнее таким образом. Если два человека общаются у доски — они эффективно синхронизируют контекст и понимают друг друга. Но текст тоже нужен, потом — надо записать, о чем договорились. Или наоборот, сначала аналитик записал, а потом — рассказал, и поправил, если надо. Надо фильтровать решения в коммуникации. Ответственность за кнопки и работу пользователя — на аналитике, разработчики — дизайн таблиц. Но есть таблицы, которые интерфейсные для интеграции — они в документации. Надо различать, что внешнее, а что внутри. Разработчики начинают ныть «а мы не знаем, где лежит» — нормально ответить «мы тоже не знаем», иди ищи по коду. Ильяхов написал «Пиши, сокращай» настолько кратко, что потом написал еще две книги. Дальше был тезис, что все это не может сделать ChatGPT. Тут я не согласен, многое из этого ChatGPT делает, есть доклады, люди делятся опытом. Еще Сергей говорит, что ИИ, в отличие от человека, не может получить связь от окружающей среды, провести эксперимент, у кого-то спросить. Это верно лишь отчасти: ИИ умеет отлаживать программы, может вызвать команду, которая что-то напишет в чат. И в ответ на это была реплика Романа Смирнова, автора предыдущего доклада: ему уже звонят роботы, когда надо что-то выяснить. А Сергей Гевлич сделал технологию, с помощью которой можно переложить на ИИ любой хорошо описываемый тренинг, включая побуждение конкретных действий. ИИ будет об этом напоминать через чат (подробнее — здесь). Так что развитие — идет и очень быстро. Может ли ИИ порождать смыслыВообще контраст докладов Сергея Нужненко и Романа Смирнова по оценке ИИ вызвал мой пост. Сергей очень правильно говорил про краткое и смысловое написание документов, которые должны передавать смысл, включать модель, а не быть просто литературным текстом, и обеспечивать выполнение целевого действия от адресата. Но в конце был тезис, что ИИ никогда не сможет сего этого делать. А доклад Романа был о том, что ИИ уже все это может помогать делать. И я с Романом согласен: ИИ вполне может проверять наполнение смыслами по чек-листам, может вставать в позицию другого человека и так далее. Правда, его надо об этом правильным образом спросить, это сложный промпт, который надо написать, разово или как многократно повторяемый чек-лист. ИИ знает формальную логику, и может ее проверить из текста. И картинки в plantuml он рисует. И доступ в реальный мир у него есть, может быть посредством человека: например, он написал код, ты запустил, и написал ему «не работает выдает это», а какой-то код он уже сам может запускать. В группе конференции он вызвал небольшой отклик. обсужденеи продолжили очно на круглом столе, а вот на моем канале — более 30 комментариев на тему, способен ли ИИ порождать смыслы, или это прерогатива человека. Я не буду здесь пересказывать, там каждый остался при своем мнении, но за счет обсуждения позиции сторон очень четко проявляются, есть интересные аргументы. Так что читайте и формулируйте свое мнение. Наталья Семенова. Время против нас. Что нам нужно делать уже сейчас, чтоб не оказаться не у дел завтра? Спасибо AIЭто рассказ о личном опыте. Наталья ушла с позиции руководителя большого отдела аналитики, около 80 человек, если я правильно запомнил, в свободное плавание предпринимательской деятельности. При этом она понимала, что если нарисовать розочку требуемых компетенций. то там будет некоторое количество провалов — направлений, по которым она в принципе не работала. Эти пиар, маркетинг, продажи и ряд других. И для начала она решила освоить их на модельном проекте, в котором уже имелся задел по содержанию — подготовка спикеров к выступлениям, для ИТ-аудитории, с которой она знакома и понимает проблемы. Если кратко, то многие рекламируемые методы оказались не работающими в той нише, которую она выбрала, она нащупывает и осваивает другие. В каких-то вопросах надо переступать через внутренние ограничения, которые, например, не давали делать звонки по знакомой аудитории, и оказалось, что поскольку аудитория — не из какой-то базы данных, а знакома с ней по выступлениям, то получается содержательный разговор, CustDev. Процесс не закончен, но ряд вех — пройдены. А ИИ в этом помогает разобраться, например, проверить формы договоров. С ним надо работать, задавать вопросы, но опыт аналитика это позволяет. А вот нанять специалиста — не получается, потому что специалисту надо ставить задачу, да еще объяснять специфику ИТ-аудитории, с которой она знакома. Но самое главное — многие из этих направлений надо учесть на уровне разработки стратегии, то есть специалиста надо будет сделать партнером и ему доверять, либо освоить самой, иначе либо стратегия получится однобокой. Вот она и осваивает, потому что пока нет задачи сделать партнерскую компанию, она двигается сама. Помощники тоже возможны но там, где она может поставить задачу, и один уже появился. Проект, который она сейчас продвигает — нишевой, это ей понятно, и тут задача — набрать необходимые компетенции, а потом пойдут и другие проекты. Вообще, это интересное решение. Ведь если взять тему, где ты — эксперт, но готового материала у тебя нет, ты сначала займешься знакомым, тем, что умеешь — будешь делать материал. А только потом займешься его маркетингом и продажами. Вполне возможно, что для успеха материал должен быть другим, и нишу надо по-другому формировать — то есть ты пройдешь к тем же граблям, но позднее. А со знакомым материалам она уже ряд граблей прошла, и в следующем проекте их учтет. А теперь — рассказ подробнее. Одна из причин выхода из большой компании было желание попробовать и освоить новое, включая ИИ. Аналитиков ценили за знание теорий, понимание трендов и так далее. ИИ это умеет. ИИ не сможет мотивировать, творчество, эмпатия и интуиция — это наше. Тут Наталья ошибается, есть опыт ИИ-чат-ботов психологической помощи, они проявляют больше эмпатии, чем люди-психологи и меньше раздражаются, а мотивировать, если на это есть запрос — умеют. В чем ИИ может помочь: стратегия — тактика — операционка. Он знает методологии, или ты сам можешь положить, сделать набор агентов, они будут определять задачи, декомпозировать, и из разных ролей это выполнить. Роль ему можно описывать, у нее есть шаблон еще из опыта аналитиков: guides — input — output — enablers. Шаблон в докладе подробно не раскрывался, Наталья о шаблоне она рассказывала на нескольких докладах, а я слушал на barcamp AnalystDays осенью 2024, есть мой конспект, и будет доступна запись, когда организаторы выложат в открытый доступ. ИИ для нее составлял пачку договоров без всякого юриста. Но при этом спрашивала у ИИ анализ договора под разными углами — на соответствие законов, со стороны партнера, у которого претензии и так далее. Корпорации — зарегулированы, там ограниченный доступ к технологиям, дефицит мощностей, жесткие требования к данным и так далее. До корпораций докатится не скоро. И вы можете игнорировать, работать в отстающих компаниях. Взгляд предпринимателя: много тем, поделены на желтые и белые: знакомое и незнакомое. В знакомом: видение, продуктовая разработка и много других пунктов. Но! в незнакомом — маркетинг, продажи, финансы, юристы, рост и развитие. Подробности можно посмотреть в презентации Наталья ее уже опубликовала на канале конференции и на ее собственном канале подготовки спикеров. В каждом направлении — свой вклад со стратегию. Нанять специалиста — нельзя, alignment не достигнешь. Нужно единое видение, и с учетом реализуемости. Надо учитывать все. И понимать стратегии по всем направлениям самой — а для этого быть профи. Как выбраться? Выход — можно делегировать это ИИ. Это работает, и это возможность себя разгрузить. Маркетинг. Гипотеза — План — Действия — Ревью — Гипотеза. Наташа позиционировала это как нестандартный PDCA, я тут вижу HADI-цикл, типовой для проверки гипотез. Разница — в mindset, PDCA подразумевает, что мы придумали надежный план, который не сработал из-за каких-то нюансов и надо несколько адаптировать, а HADI ориентирован на гипотезы, которые запросто могут оказаться неверными. Наталья за осень протестировала 100 гипотез. Первый продукт — обучение быть спикером. Она умеет, курс записан. Только продавать она не умеет. И осенью, отдохнув после ухода из компании, она начала пробовать. Первая гипотеза — продукт может быть интересен лояльной аудитории бывших сотрудников, которая у нее есть. Оказалось, что сотрудники привыкли получать от нее все бесплатно. Кроме того, выступать они не очень хотят, или есть объективные причины, почему не стремятся к этому, и они — общие для ИТ. Вывод: не продукт развивать, а рынок развивать, и она пробует это делать, сделала сообщество. Так со временем выясняются стратегии, которые работают. Она оставляет стратегию на себе, теперь может нанять человека для тактику. Но это уже потом. Это был пример про маркетинг, который она считала самым слабым звеном, и поэтому решила прокачивать первым. И только сейчас нашла маркетолога, и там отдельный вызов — научить маркетолога говорить по ИТ. Продажи. Верила, что маркетинг поможет вести продажи. Нет, люди приходят, воронка большая, а курс не покупают. И она дошла до черты, исчерпала запасы средств, начались кредитные деньги. И тут она поняла, зачем проводила бесплатные вебинары: она теперь знает людей, которые интересуются. А раз так — у них можно выяснить про рынок подробнее. Пишет в телеграм — откликаются. Но не у всех телеграм, у кого-то телефон. Начала звонить — холодные звонки. И тут на звонок — позитивный отклик, оказывается хотят посоветоваться, аналитики ее знают. Самые негативная реакция у HR или DevRel. И в этих разговорах оказалось кладезь custdev и инсайтов, она многое узнала про аудиторию. Вывод. Магические автоворонки с прогретыми лидами на ИТ не работают. Надо по-другому. Сейчас она вышла примерно на операционный ноль. И продает классный продукт тем людям, которые его используют. Рекомендации по ИИ
Юлия Ермакова. Как в билайне системные аналитики используют ИИСамое интересное в докладе то, что использование ИИ — не большой проект в рамках корпорации, которой является билайн, а частная исследовательская инициатива в одном из подразделений, в рамках большой задачи поиска способов уменьшения TTM. Таким образом, если есть желание и инициатива — подходящие возможности всегда можно найти. Конечно, полной свободы сделать что угодно — нет. Но они смогли развернуть ИИ локально, потому что работают с закрытыми данными, и начать тестировать гипотезы. Мощностей пока мало, это ограничение исследовательского проекта, но они нащупывают перспективные гипотезы, и если это получится — то будет защита перед руководством конкретного проекта. Тут ИИ не отличается от других инструментов: первая фаза — чистое исследование, давайте посмотрим на технологию, должна смениться на следующую: исследования показали, что с помощью технологии можно сделать это и это, давайте запускать проект. Итак, был запрос от руководства — сокращение TTM, не только для аналитиков. Они проверяли разные гипотезы. А ИИ — инструмент. Одна из гипотез — все больше сложности систем и требований, много легаси и плохо структурированной документации, высокая нагрузка на аналитиков. Идея — переложить часть рутины на ИИ
В преокте — 4 аналитика и 3 разработчика, которые помогали разворачивать модель. Развернутую модель использовали не только аналитики, но и разработчики для своих гипотез, и они вовлекали другие отделы, всего у модели сейчас 25-30 уникальных пользователей в день. Как работали? Сначала обсуждали с аналитикам кейсы возможного использования. Дальше разработчики отвечали: может ли моделька переварить или точно нет. Если потенциально может — то тестировали: подбирали запросы, подключали данные контекста и так далее. Тестировали Llama 3.1 и deepseek-coder-v2. Разработчики сравнивали на своих кейсах — ревью кода, написание unit-тестов, аналитики — на своих, собирали потребности из других направлений. Инструменты
Зашли кейсы
Где ограничения
Результаты
Дальнейшие планы
Итого
Анастасия Соболева. Агент изменений. Опыт аналитика в командах без устоявшихся процессовЭто был рассказ про внедрение и налаживание процесса анализа в команде. Такая задача стоит не только перед руководителем отдела аналитики, и, более того, она часто неявная. не проявлена в вакансии. Ты пришел работать, и оказывается, что ты — первый аналитик в команде, люди привыкли работать без аналитика. Или, что хуже, был негативный опыт, несколько аналитиков уже сбежали. А может быть, что аналитики есть, но совсем недавно, и процессы не построены. Анастасия несколько раз оказывалась в таких ситуациях, и доклад — обобщение опыта. Причины включения аналитика в команде
Аналитик может придти в команду, в которой не было аналитика — и они не привыкли с ним работать, не привыкли читать документацию, самостоятельное определение реализации, неверифицируемый легаси При этом
Хорошо, если есть понимающий менеджер или тимлид. Но у них не всегда есть ресурс для встраивания аналитика. Аналитику надо решить проблему самому. При том, что такая задача явно не ставится. Она с такой задачей несколько раз. И у нее сложился некоторый шаблон для решения проблемы захода в команду. Roadmap в виде mindmap
Оценка ситуации
Обратная связь от команды: стейкхолдеры, боли, ожидания, есть ли негатив и какой, предыстория — почему так, блокеры в решении проблем. Чем больше болей — тем больше рассказов. Ожидания бывают не реалистичные, но они важны. Бывает камуфляж: все хорошо, нет проблем, но хочется, чтобы было меньше переделок — так может, проблемы есть? Смотрит, о чем говорят все — это общие проблемы. При оценке были гипотезы стороннего наблюдателя, они тоже верифицируются на обратной связи. Решает, какие проблемы что решает сейчас, а что — нет. Бывает, что в команде проблемы с докой, ее нет, а как пожелание — автоматизировать. Набор проблем, с которым работает — согласует с командой. Чтобы люди признали — это старт изменений. Презентует: «вы мне говорили…». Договаривается об объеме изменений и их измерения, например, проблема с доками — с чего начинаем. Важно тут быть прозрачным для руководством, особенно если оно не ставило задачу изменений. По изменениям — стейкхолдеры и интересы. Быват, что в команде кто-то держит свою территорию, не готов к документированию — надо понимать, как вести коммуникацию. Балансы, особенно когда функция не авторизована:
И есть реальный пример.
Таймлайн. Около 2 месяцев шло осознание и диагностика, что происходит. И диалог с менеджментом. Это был самая сложная часть процесса. Другие аналитики — были двое около года, и у них была сложная ситуация. После признание менеджментом проблем — за неделю согласовали изменения, в команде было много накопившихся мыслей. Документирование основной части и привычка работать с ней у разработчиков — около полугода. А дальше — продолжается, но за полгода написали достаточно для качественного перехода. Сложный момент был — именно донести мысль о необходимости изменений, чтобы они вовлеклись в процесс. И тут полезно формулировать проблемы, и не давать решений, а вовлекать в их поиск — они дают предложения, которые готовы делать. Резюме, просто как повторение тематики
По ссылке — шаблон + материалы — книги. Вопрос: почему пошли в такой сложный проект? Ответ: на собеседовании сложность была непонятна, как раз 2 месяца поэтому появились. Но проект — интересный, R&D. Так что она думает, что пошла бы, даже если бы поняла. Евгений Ильюшин. Безопасный искусственный интеллект: от теории к практикеЭто — единственный доклад конференции, которой мне не понравился. Потому что теория вся была в виде классификаций без особых оснований, а практика ограничивалась тем упоминанием разных кейсов атак, в том числе умозрительных, без разбора, как именно этого избежать в практической работе. И, главное — нужно ли избегать, есть ли от этого реальный ущерб и каков он, или это — просто страх, который еще и закрепили в нормативке. И кейсы были старые, эпохи использование для распознавание лиц. Но кое-что любопытное было, так что я решил не убирать доклад из конспекта, а снабдить комментариями. Точки опасности систем с ИИ. Если слегка поменять анкету или назначение платежа, система антифрода или одобрения кредита — обманывается. Если система работает на датчиках телеметрии — можно вмешиваться в телеметрию, подменять ее. Компьютерное зрение беспилотников обманывается — видят нарисованных пешеходов. От чат-ботов с самоообучением можно добиться изменения позиции, так злоумышленники за ночь после запуска одного из чат-ботов добились от него отрицательных отзывов на одного вице-президента страны, был скандал. Причины
Вывод: нельзя обучить модель навсегда, надо дообучать. Я бы сказал, что это все — очевидные вещи. Да, если ты решил сделать систему опознания по лицам сотрудников, например, для наших автозаправок, где много людей из Средней Азии, а в обучающей выборке у тебя американские негры и белые, то система будет распознавать плохо. Ну, не поступай так глупо. А если на цены действует тренд, вообще не учитываемый в предсказаниях — емкость рынка, то она будет предсказывать фигню. И так далее. Принцип обучения — 1974, и там основа: данные одинаково распределены. А в реальной жизни они распределены по-разному. Фото — разных устройств, разные изображения. А еще — разная классификация исходных данных, зависимость от того, кто размечает. И там сложная математика, 7 разделов. Я тут хочу отметить, что математика уже давно на нижнем уровне, а дальше это собирается в сложные конструкции. Примерно как все численное моделирование и многое другое. При этом и в алгоритмах и в архитектуре было много прорывов, которые обеспечили тот успех, который мы имеем сейчас у систем ИИ. И которые могли принести свои особенности, если говорить о безопасности, так что смотреть на старую базу, наверное, несколько наивно. Как описывать мотивацию пирамидой Маслоу, который придумал ее в 1940 — это было приличное первое приближение, но не более. Безопасность. Функциональная (физическая) и информационная. Угрозы ИБ: конфиденциальности, целостности, доступности, злоупотребления. Особо злоупотребление: LLM классно пишет тексты, а тексты далее используют преступники. Я тут отмечу, что злоумышленники всегда использовали технологии, напримеР, рисовали фотки в фотошопе. ИИ принципиально не меняет ситуацию, тем более что у тех, кто противодействует он тоже есть в распоряжении. Способы атак
Принципы создания систем ML
Международных методик нету, мы «смотрим как это создается». Я тут хочу заметить, что ждать международных методик — это отставать на много лет. А вот мысли включить голову и делать самим — не возникает. И все ссылки в докладе были на западные статьи. При том, что практическая работа внутри идет, на MergoConf осенью я слушал интереснейший доклад по анализу архива украинских мошенников из центра в Бердянске, который в 2022 попал в российские руки, и более новые материалы в докладе были. А еще я хочу сказать, что в методике — все верно, и про риски, и про разные категории нарушителей, которые должна описывать модель. А вот дальше в примерах все дается на общем уровне: есть БД — ее могут взломать, есть данные — их могут украсть, используем библиотеки — их могут подменить. Все эти категории в примерах не показаны. Пример: распознавание по биометрии лица.
Модель нарушителя:
Оценка качества на дискретом множестве. Статистические, эмпирические. Чаще всего — статистические, проверка результата на наборе точек. Реально этого недостаточно, но формально проверку проходит. А устойчивость к атакам — не проверяют Тут были ссылки на западные научные статьи. И, к сожалению, уровень примеров, которые в этих статьях разбираются, на мой взгляд оставляет желать лучшего, там очевидные кейсы или модельные, такой сферический конь в вакууме. Это — не претензия к автору, это — печалька по поводу состояния мировой науки в этом месте. Комплексная оценка — несколько разных оценок: на исходном распределении, к сдвигам, к атакам, неопределенности (уверенность решения модели), интерпретируемости, способность детектировать выход из распределения. И дальше дофига формул. И взвешенная оценка, веса задает эксперт в зависимости от системы. Я бы сказал, что веса подирает эксперт для того, чтобы получить нужный результат при проверке безопасности системы, как это делают в куче других случаях. Забавная история. ИИ учили распознавать волка от хаски по снимкам. Она успешно научилась. Но когда стали анализировать ошибки, то выдвинули далее подтвердившуюся версию, что система смотрела не на животное, а на фон: на снегу — хаски, в лесу — волки. Понятная проблема обучающей выборки. Важный вопрос: не страшно ли, если модель ошибется. Здесь он. как ученый, ставит на математические доказательства на модели. Если это сделано — нормально. А если не так, а от ошибки многое зависит — не стал бы. Но для LLM доказательств этого нет. Я тут хочу сказать, что это — типичный подход не только к ИИ, но и к другим технологиям: пусть докажут, что работает без ошибок, тогда разрешим. Реально человек, который сейчас делает те же операции, делает ошибки. А важно, чтобы технология делала их не хуже, а желательно — лучше. У автопилотов аварийность меньше, чем у людей водителей, об этом — молчат, а каждый кейс раздувают до небес. К LLM будут отдельные требования, и они лицензируют эту деятельность, обременяя ответственностью создателей модели. Он сравнивает это с правилами дорожного движения, которые структурировали поток автомобилей. Я такой аналогии не вижу. Я вижу, что разговоры о лицензировали появились после снижения стоимости создания и развертывания моделей, особенно после того, как DeepSeek нарушил монополию Запада. Стандарты на экологичность автомобилей Евросоюз вводил так. чтобы не пустить китайцев, и ограничить американцев на свой рынок, хотя на флаге была экология. Власти проморгали соцсети и мессенджеры как значимый политический фактор, не ввели лицензии, теперь пытаются восстановить контроль с большим трудом. Поэтому на площадке LLM решили это устроить сразу. Был вопрос про закладки в DataSet. Если изображения — то проще всего encode-decode — они уберут закладки. И со звуком можно, бывают закладки на инфразвуки для голосового помощника. С текстом — сложнее, не знает. Очень понятный ответ, и хотелось бы, чтобы такого материала — что делать — в докладе было побольше. Ирина Гертовская. Как организовать работу аналитиковВ докладе — системный взгляд на организацию работы аналитиков. с фокусом на интересы разных стейкхолдеров, включая самих аналитиков. Система — это что-то, что решает чьи-то проблемы. И есть синергия целого (это еще Аристотель). В ИТ система включает оборудование, программы, данные и персонал (пользователи). Мы различаем целевую систему, которую мы создаем, и систему в обеспечении, которая создает эту систему. У системы в обеспечении тоже есть оборудование, на котором идет разработка, программы и данные, которые используются при этом и персонал — разработчики, аналитик и другие члены команды. Система проходит фазы: задумываем, проектируем, разрабатываем и- используем. Работы не жестко привязаны на них идут волнами, на слайде известная горбатая диаграмма из RUP. Успешность системы в обеспечении определяется тем, добиваются ли с помощью целевой системы успеха ключевые заинтересованные стороны — те, кому целевая система нужна, ради кого ее создаем. Однако, у обеспечивающей системы в лице команды разработки есть своя обеспечивающая система — те, кто создавал эту команду, и есть свои стейкхолдеры со своими интересами. И успешное создание с помощью команды разработки целевой системы — только часть этих интересов. Например (это — мой пример), сценарий, когда команда сделала целевую систему, но при этом вся выгорела или уволилась может быть нежелательным, стейкхолдеры могли рассчитывать. что сотрудники будут работать и дальше, создавая другие системы. Стейкхолдеры для обеспечивающей системы: руководство, аналитики, другие команды, внешние стейкхолдеров. И дальше на слайдах были их интересы, подробного разбора не было — акцент был на некоторых пунктах. Но слайды можно использовать как более полный список.
У самих аналитиков тоже есть интересы, которые различаются для разных групп: лиды, мидлы и сеньоры, джуны.
И всем нужны знания для работы Концепция — что я строю для своего подразделения. Как руководитель отдела системного анализа я хочу настроить работу отдела так чтобы удовлетворить ключевых стейкхолдеров. И дальше — их рассматриваем. РП интересна обеспеченность сотрудниками и технологиями, аналитикам — интересные задачи и предсказуемость хода проекта, и так далее. На основе оценки интересов получается дорожная карта: цели, окружение, оценить ресурсы, составить планы. Задачи — из карты: выделить критичное, определить ресурсы, выделить направления максимального эффекта, показатели оценки. СИтуации проектов различаются, бывает критичные кейсы. Например, бизнес-аналитики разошлись, системных еще нет, а нормативка резко меняется… И дальше в презентации таблица: активности аналитиков, результаты, артефакты, для кого (это — важно). Получается большая простыня, дальше делим. Важно — выписать все работы. Потому что, например, взаимодействие с разработкой и тестированием или сопровождение может занимать много времени, до 70 %, и это надо учесть при планировании. Для активности: результат — какой артефакт и для кого, источник информации, техники и методы. Состав документации и ее содержание. И ключевое — ценность передачи информации, которую обеспечивает каждый раздел документации. Взаимодействие с другими командами и стейкхолдерами должно быть согласовано. Правила дорожного движения должны быть. Не надо спрашивать аналитика, статус должен быть виден через jira. Триада технологического развития: технологии, знания, обучение.
Прямые связи: Технологии -> Знания ; Технологии -> Обучение -> Знания. И обратные так же. Оценка эффективности:
И смотреть динамику. Не формально, а практически для применения. Несекретные Ингридиенты
Поиск сотрудников различается по способу оценки. У джунов оцениваем отношение к проекту, готовность мыслить, желание работать и учиться. А у мидлов — умение работать в команде, софты, харды. Требования к сотрудникам подбираем совместно с РП, проводим согласование кандидата. И в каждом проекте должен быть сильный лидер и вдумчивый аналитик, эти компетенции могут быть у одного аналитика, или у двух разных, но нужны обе. Задача подразделения: снизить неопределенность, не допускать простоя. Заранее дать доступы, подготовить, что изучить новичку, выбрать наставника. Для всех важно обеспечить человеческое отношение и отсутствие страха перед ошибкой. Компоненты успеха.
Остальное — нарастает. А еще: «Улыбка, здравый смысл и виски решают все проблемы» — Билл Мюррей. Здравый смысл приходит из опыта, а опыт — из отсутствия здравого смысла. |
Блоги друзей |
