Изменения

В прошедшие выходные второй раз прошел [https://events-pro.ru/conference/WAW2025 Winter Analitical Weekend] -  — конференция аналитиков, зимний брат Летнего аналитического фестиваля (ЛАФ). Он ориентирован на практику, основное содержание - содержание — мастер классы, которых было три трека. Но один трек докладов тоже был, и я, в основном, был на нем. Среди докладов сильно звучала тема ИИ, но другие темы тоже были. И, как обычно, было много нетворкинга и совершенно замечательная атмосфера.

Благодаря атмосфере общения я подметил одну штуку, которую не слишком понимаю. Некоторые аналитики с гордостью говорят о себе "я - душнила"«я — душнила». Спрашивается, чем тут гордиться? Потому как у меня коннотации к этому слову - слову — отрицательные, и появилось оно именно таким образом. Может, это гримасы времени. Раньше при отрицательной оценке другого ты рисковал получить в морду. Потом детям начали объяснять, что драться - драться — плохо. появилось "кто «кто как обзывается, сам так называется"называется». А теперь, получаетсЯ, социум требует признать негативную оценку? Хреновый это социум, на мой взгляд... взгляд… Ели у кого есть мнение - мнение — высказывайтесь.

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

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

Вообще позиции были очень различны, и у экспертов и в зале. Среди экспертов были Юра Куприянов, который давно использует ИИ в своей работе и рассказывал об этом еще в 2023 году, был Роман Смирнов, который драйвит использования ИИ у себя в компании, потому что в естественном темпе процесс идет медленно и компания теряет возможности, и он рассказывал об этом в докладе на WAW. C другой стороны, Сергей Нужненко относится к текущим возможностям ИИ с большим скепсисом, не взирая на достижения, и эта позиция разделяется рядом участников. Так что обсуждение было жарким.

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

# Как совместить скорость и качество 25 лет назад показал Agile (это - это — мой тезис), это можно делать вполне успешно, и ИИ тут не меняет ситуацию.# Постановка вопроса "ИИ «ИИ или человек" человек» в принципе неверная, правильная постановка "человек «человек вместе с ИИ"ИИ», и уже сейчас ИИ дает много возможностей, которыми надо пользоваться, он ускоряет разработку. Казалось бы, понятный и конструктивный тезис. Но у многих скептиков реально звучит "раз ИИ - «раз ИИ — не серебряная пуля - пуля — не будем им пользоваться вообще"вообще». И это я слышал от многих людей не на круглом столе: люди почему-то считают, что обращение к ИИ снижает их профессиональную самооценку, и не хотят этого. # Люди очень любят обсуждать процессы вообще, на абстрактном уровне. #* Было очень много холиварных обсуждений о необходимости процессов, которые не имеют отношения к ИИ вообще, я все это слышал 5-10-15 и более лет назад. При этом конкретику - конкретику — какие процессы имеют ввиду - ввиду — обычно умалчивают. Когда на нее приземляешь, то говорят "нет«нет, мы говорим о разумных процессах, например, что задачи должны быть в таск-трекере, а не в почте"почте». Я тут согласен: задачи должны быть в таск-трекере, а при проверке DoD и DoR уместны чек-листы, и это - это — уровень гигиены. #* Надо понимать, что соблюдение процессов на таком уровне не дает гарантии результата. А от процессов говорят именно гарантий результата: мы все сделаем правильно, и фичи будут разрабатываться с соблюдением бюджета и сроков. То, что так не работает, показал Том Демарко в книге "Человеческий фактор" «Человеческий фактор» еще в 1987, провал RUP и успех Agile-методов, по которому есть статистика. #* Тезис о том, что "у «у нас два сеньора со своими представлениями о правильной архитектуре, их невозможно договорить, поэтому надо принять стандарт"стандарт», на мой взгляд, наивен. Кто это напишет? Кто-то третий? Или одного назначат главным? В любом случае, это - это — не организация процесса, а волевое решение, при чем дурацкое, потому что разногласия наверняка не во всех случаях, ситуативно могут часть решений принимать согласием, при чем равным, а стандарт будет действовать по принципу "безобразно«безобразно, зато единообразно"единообразно».

= Максим Цепков. Развитие общества в эпоху ИИ =

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

Что касается ИИ, то это драйвер, который приведет к не менее, а, вероятно, более сильным изменениям в социуме и бизнесе, чем интернет, google, смартфоны и соцсети вместе, повлияет на решение многих проблем, в частности с образованием. Мне нравится формулировка: '''Google лишил человека права не знать - знать — каждый может погуглить, а ChatGPT лишил права не понимать - понимать — спроси, пусть объяснят'''.

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

=Роман Смирнов. Внедрение AI в процессы IT компании=

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

И у него в компании было так же: кто-то использовал, а кто-то - то — не особо интересовался, естественный процесс распространения шел медленно. И на этом терялись возможности, которые дает ИИ. Возможностей - Возможностей — много, по его оценки, потенциал ИИ сейчас используется в ИТ на процентов на пять, в очевидных местах. А может он больше. Поэтому он процесс внедрения ИИ ускорил, вплоть до встройки в процессы, когда шаг "review AI" «review AI» становится обязательным для постановок и других вещей. Рассказ был об этом.

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

* Это - Это — системное изменение. Производительность труда программистов вырастет раз в 10, и это не только разработчики. Роман знает, что пока достигли 30-5050 %, это было в докладе дальше.

* Сжатие процессов по вертикали и горизонтали - горизонтали — количество согласований и ти т.п п. В одной из компаний процесс - процесс — 32 согласование, 1.5 месяца. Сжатие по вертикали - вертикали — без согласование, сжатие по горизонтали - горизонтали — меньше этапов процесса. * Все компании - компании — разные, пути будут различны.* Сейчас внедряем не инструменты, а другую культуру труда. Разведчики (инноваторы), те, кто по тренду, и те, кто сопротивляется. "Да«Да, я сделаю лучше" - "Далучше» — «Да, но за 8 часов, а не за 3 минуты"минуты».

* Обработка заявок, тикетов и так далее. Где идет из внешнего мира. LLM анализирует лучше людей. На задаче оценки входящих лидов - лидов — 30 критериев, человек не может выбрать, LLM как-то поможет. * DevOps и мониторинг - мониторинг — надо оценивать поток алертов* Генерация кода и рефакторинг - рефакторинг — есть до 20 инструментов, местами в несколько раз* Автоматизированное тестирование - тестирование — покрытие можно повышать быстро.

* Оптимизация работы с данными - данными — поиск информации с помощью ИИ. Он думал единый чат-бот компании за год получится, но сейчас прогноз 2-3 года.* Data Governance - Governance — распознавание данных и ти т.п п.* Предсказательная аналитика - аналитика — больше ML, чем LLM. Но ChatGPT знает про ML и умеет делать анализ данных - данных — он отрабатывает запрос гораздо быстрее. И еще можно осваивать новые области. Мечтает прикрутить аналитику к метрикам команды - команды — Jira снимает 200 метрик, а что делать дальше - дальше — неясно.

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

* Планирование встречи - встречи — составление повестки

* Генерация нового функционала - функционала — API, алгоритмы обработки информации, макеты UI и даже готовый фронт* Генерация бизнес-решений внутри контекста - контекста — в планах. Не хватает пока окна контекста 32-64к для контекста проекта мало, но есть модельки от 2М токенов, и появляются новые - новые — это решает проблему.

* Стремимся: проверка спецификации по чек-листу. * дизайнеры: идут в DeepSeek и просят сделать промпт, потом отрабатывают его - его — и получают приемлемый макет, можно просить доработать по замечаниям. 3 минуты вместо 1 часа.* Разработчики. GigaCode и Cursor.ai. Они с помощью ИИ в 9 раз срезали косты на code review. В Сбере начали заставлять использовать GigaCode - GigaCode — перестали ждать естественного проникновения. Статистика 1000 строк, cursor.ai - ai — 2-2.5 тыс 5 тыс. после внедрения, то сделал 30к. 8080 % разработчиков начинают использовать. Статистика по отрасли - отрасли — 20-2525 %, они ждут 100100 % в год.

Чтобы внедрять процесс - процесс — надо самому попробовать. И на январских праздниках за 10 дней сделал 20к строк кода на разных языках. И получил систему, которая строит mindmap с помощью ИИ - ИИ — она работает, он выхожил в инет - инет — можно посмотреть http://rmind.ru и бесплатно пользоваться. Суть не в том, что хорошая штука, а в том, что это сделано человеком, который не умеет программировать (хотя 15 лет назад - назад — умел). То есть реально сделать много прототипов, и не простых, проверять идеи.

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

Неважно, сколько раз вы используете ИИ - ИИ — вы все равно используете его мало.

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

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

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

А теперь - теперь — подробнее о содержании доклада.

Сергей 30 лет в ИТ, он сооснователь школы системного анализа. И 30 лет назад все знали, что такое сильные требования: полные, непротиворечивые и так далее. А в 2001 году появился Agile и все сломал: не надо писать, общайтесь у доски, фломастер. В 2010 появилась связь, общаться начали дистанционно, а в 2015 появились доски-платформы. Продуктовые проекты растут без аналитиков. Но системы растут, усложняются, появляется много команд, люди увольняются и контекст теряется, перестают отличать баги от фич. Примерно с 2015 появляется тренд "верните «верните аналитиков, мы запутались"запутались».

Я тут замечу, что сам работаю в ИТ 40 лет, из которых чуть меньше 30 - 30 — в enterprise-разработке (с 1995). И все это время, задолго до Agile относился к требованиям с большим скепсисом. Я работал с помощью моделей, это было задолго до появления DDD, и я до сих пор считаю, что это - это — наиболее эффективный способ разработки. И полагаю, что требования практически не нужны, за исключением ситуации, когда они выполняют роль контракта. который ИТ сначала подсовывает заказчику, а потом им прикрывается: "мы «мы сделали, что заказывали, деньги - деньги — на стол, надо другое - другое — с удовольствием переделаем за новые деньги"деньги». Впрочем, Сергей дальше говорил про модели, а не только про требования. А разграничение ответственности и организация взаимодействия между бизнесом и ИТ - ИТ — отдельная тема.

Задача Сергея - Сергея — чтобы аналитики в его команде эффективно писали требования. Много писать - писать — легко, но бесполезно. Надо писать мало и компактно, мало текста и много смысла - смысла — это и есть сильные требования. И надо уметь это делать быстро и эффективно.

Почему Сбербанк сокращает аналитиков? Потому что разработчик пишет задачу за 2 недели, а аналитик раздувает задачу ее до 2 месяцев. Да, разработчик за 2 недели напишет не все, но еще за пару недель он доделает, и будет быстрее. Поэтмоу там аналитики - аналитики — первые в очереди на сокращение. Сергей работает не в Сбере, но его задача предотвратить аналогичный сценарий.

Кстати, отмечу, что именно таким образом Андерсон объясняет эффективность Agile-методов: если написать ТЗ со всеми хотелками, реально нужных из них будет 2020 %, правило Парето тут вполне применимо. А в классическом преокте оценивают полный скоуп, а потом его требуют. В Agile (независимо от конкретного метода) выделили скоуп первых итераций, сделают самое нужное - нужное — и проект можно закрывать. Да, где-то ошибутся с выделением, сделают не только 2020 % самых нужных, а еще 1010 % не слишком нужных - нужных — все равно экономия при разумном подходе втрое. И Андерсон этого достигал на реальных проектах.

Продолжаю рассказывать доклад. Задача аналитика - аналитика — не превратиться в "ноги «ноги с ушами"ушами». Аналитик, который просто запишет то, что ему сказали, возможно, был актуален в прошлом, когда писать не умели. Но сейчас можно надиктовать, транскрибировать и причесать. Можно отдать человеку, чтобы он причесал, writer стоит 200 рублей за 1000 знаков, а LLM вообще делает бесплатно, и это она умеет.

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

Но надо разбираться в ситуации. Бывает, что разработка просто не хочет понимать и принимать задачи - задачи — тогда аналитик не поможет. Был кейс: 7 менеджеров на 2 разработчика, наняли аналитика, потому что разработчики говорили "пишете дичь"«пишете дичь». А реально в бэклоге уже было работ на 3 года вперед, и менеджеры все порождали и порождали новое в режиме потока сознания, не было нормальной работы с приоритетами.

Если ситуация непонятна - непонятна — надо выяснить. Если встретиться и выяснить почему-то нельзя, то не надо делать, это бесполезная работа. Малярная бригада из 2 человек за сезон зарабатывает 5 млн5 млн, это 500 тр в месяц на человека - человека — есть выгодная альтернатива, и там ты точно приносишь пользу.

* шаблон больше содержания - содержания — много лишних заголовков* принудительная телепортация - "как телепортация — «как в той задаче"задаче», без сути, что в той задаче важного* письмо дяди шарика - шарика — поток сознания

* уход в детали не месте -- месте — 10 скриншотов в середине, а потом 2 пункт, он затерян* скачет терминология: клиент делает, потом оператор, потом пользователь - пользователь — а кто-то из них один и тот же человек

Аналитик пишет не текст. Он описывает модель. Значит его можно реализовать в виде схем. А если схемы нарисовать не получается - получается — значит есть проблемы. Можно начать с учебника по формальной логике. Не сложные силлогизмы, а начала. Гусев "Искусство «Искусство правильного мышления" - мышления» — полкниги читаются за два вечера, и этого достаточно.

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

Есть задача - задача — встать в тапки адресата (потребителя) документа, так, чтобы разработчик смог выполнить его. Надо понимать, что за разработчик - разработчик — субподрядчик, аутсорсер, или разработчик внутри команды, которая в контексте. Им нужны разные документы, неуместной может быть и слишком подробная постановка и недостаточно подробная. Если ставки высоки - высоки — можно попробовать карту эмпатии или любые методы разведки.

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

Если два человека общаются у доски - доски — они эффективно синхронизируют контекст и понимают друг друга. Но текст тоже нужен, потом - потом — надо записать, о чем договорились. Или наоборот, сначала аналитик записал, а потом - потом — рассказал, и поправил, если надо.

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

Ильяхов написал "Пиши«Пиши, сокращай" сокращай» настолько кратко, что потом написал еще две книги.

Дальше был тезис, что все это не может сделать ChatGPT. Тут я не согласен, многое из этого ChatGPT делает, есть доклады, люди делятся опытом. Еще Сергей говорит, что ИИ, в отличие от человека, не может получить связь от окружающей среды, провести эксперимент, у кого-то спросить. Это верно лишь отчасти: ИИ умеет отлаживать программы, может вызвать команду, которая что-то напишет в чат. И в ответ на это была реплика Романа Смирнова, автора предыдущего доклада: ему уже звонят роботы, когда надо что-то выяснить. А Сергей Гевлич сделал технологию, с помощью которой можно переложить на ИИ любой хорошо описываемый тренинг, включая побуждение конкретных действий. ИИ будет об этом напоминать через чат (подробнее - подробнее — [https://gpttor.ru/manual/index здесь]). Так что развитие - развитие — идет и очень быстро.

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

В [https://t.me/wawconf/1280 группе конференции] он вызвал небольшой отклик. обсужденеи продолжили очно на круглом столе, а вот [https://t.me/mtsepkov/951 на моем канале] -  — более 30 комментариев на тему, способен ли ИИ порождать смыслы, или это прерогатива человека. Я не буду здесь пересказывать, там каждый остался при своем мнении, но за счет обсуждения позиции сторон очень четко проявляются, есть интересные аргументы. Так что читайте и формулируйте свое мнение.

=Наталья Семенова. Время против нас. Что нам нужно делать уже сейчас, чтоб не оказаться не у дел завтра? Спасибо AI =

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

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

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

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

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

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

Роль ему можно описывать, у нее есть шаблон еще из опыта аналитиков: guides - input - output - guides — input — output — enablers. Шаблон в докладе подробно не раскрывался, Наталья о шаблоне она рассказывала на нескольких докладах, а я слушал на barcamp AnalystDays осенью 2024, [[Блог:Максима Цепкова/2024-11-26: AnalystDays-19 - сильные доклады и хорошее общение#Наталья Семенова. Коллеги, мы тоже на одном языке говорим|есть мой конспект]], и будет доступна запись, когда организаторы выложат в открытый доступ.

ИИ для нее составлял пачку договоров без всякого юриста. Но при этом спрашивала у ИИ анализ договора под разными углами - углами — на соответствие законов, со стороны партнера, у которого претензии и так далее.

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

Взгляд предпринимателя: много тем, поделены на желтые и белые: знакомое и незнакомое. В знакомом: видение, продуктовая разработка и много других пунктов. Но! в незнакомом - незнакомом — маркетинг, продажи, финансы, юристы, рост и развитие. Подробности можно посмотреть в презентации Наталья ее уже [https://t.me/wawconf/1310 опубликовала на канале конференции] и на ее собственном [https://t.me/SmartSpeaker_public канале подготовки спикеров].

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

Маркетинг. Гипотеза - План - Действия - Ревью -  Гипотеза — План — Действия — Ревью — Гипотеза. Наташа позиционировала это как нестандартный PDCA, я тут вижу HADI-цикл, типовой для проверки гипотез. Разница - Разница — в mindset, PDCA подразумевает, что мы придумали надежный план, который не сработал из-за каких-то нюансов и надо несколько адаптировать, а HADI ориентирован на гипотезы, которые запросто могут оказаться неверными. Наталья за осень протестировала 100 гипотез.

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

Это был пример про маркетинг, который она считала самым слабым звеном, и поэтому решила прокачивать первым. И только сейчас нашла маркетолога, и там отдельный вызов - вызов — научить маркетолога говорить по ИТ.

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

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

Вывод. Магические автоворонки с прогретыми лидами на ИТ не работают. Надо по-другому.

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

** смена профессии - профессии — лучше опираться на предыдущее

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

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

Идея - Идея — переложить часть рутины на ИИ

* Искать ошибки или противоречия в требованиях - требованиях — на разборе инцидентов видно, что они часто есть в причинах

В преокте - преокте — 4 аналитика и 3 разработчика, которые помогали разворачивать модель. Развернутую модель использовали не только аналитики, но и разработчики для своих гипотез, и они вовлекали другие отделы, всего у модели сейчас 25-30 уникальных пользователей в день.

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

Тестировали Llama 3.1 и deepseek-coder-v2. Разработчики сравнивали на своих кейсах - кейсах — ревью кода, написание unit-тестов, аналитики - аналитики — на своих, собирали потребности из других направлений.

* CodeGPT - CodeGPT — для IDEA и WebStorm

* Документации: генерация sequence-диаграмм по текстовым описаниям, описать критерии приемки по описанию * Исследования по коду без разработчика, * Поиск ответов по одной странице confluence, это делает Page Assist. Запустить поиск по всему, подключив как контекст, пока не получилось - получилось — есть ограничения модели. Но у них есть огромные страницы больших описаний, найти там конкретное не просто.

* Нельзя скормить все java-файлы и спросить "как «как работает сервис" - сервис» — кода слишком много, надо идти по кусочкам кода, подкладывая нужное* В диаграммах последовательности - последовательности — очень много излишней документации, и там лишние акторы, а бывает, что нет важного alt - alt — надо докручивать. На 75-8080 % модель справляется.

* ускорение обработки требований на 1515 % -  — до 50 человек принимали участие, и опрос по экспертной оценки, насколько быстрее* начинали с тестирование с 4 аналитиками, после начала экспериментов используют 10 аналитиков - аналитиков — преодоление скепсиса, заходит тяжело* техдолг по документации перестал казаться непосильной задачей - задачей — задачи можно потихоньку перекладывать на ИИ

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

* Измерение ttm этапа проработки требований на основе показателей - показателей — задача в статусе InAnalysis

* ИИ - ИИ — не замена, а помощник

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

* Реверс инжиниринг существующей системы - системы — обычно для замены* Контроль требований заказчика - заказчика — упорядочить поток желаний

* Проектирование сложных систем - систем — мат-модель, статистика, экономика или просто много бизнес-правил

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

При этом

* Аналитик тонет в задачах: много проблем срезу - срезу — давит менеджмент, проблема с коммуникацией, недостаточный онбординг

* Быстро сориентироваться на проекте

* Есть ли предыстория отношений с аналитиком - аналитиком — бывает, что уже несколько потонули, а бывает что позитивные ожидания

Обратная связь от команды: стейкхолдеры, боли, ожидания, есть ли негатив и какой, предыстория - предыстория — почему так, блокеры в решении проблем. Чем больше болей - болей — тем больше рассказов. Ожидания бывают не реалистичные, но они важны. Бывает камуфляж: все хорошо, нет проблем, но хочется, чтобы было меньше переделок - переделок — так может, проблемы есть?

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

Набор проблем, с которым работает - работает — согласует с командой. Чтобы люди признали - признали — это старт изменений. Презентует: "вы «вы мне говорили..."говорили…». Договаривается об объеме изменений и их измерения, например, проблема с доками - доками — с чего начинаем. Важно тут быть прозрачным для руководством, особенно если оно не ставило задачу изменений.

По изменениям - изменениям — стейкхолдеры и интересы. Быват, что в команде кто-то держит свою территорию, не готов к документированию - документированию — надо понимать, как вести коммуникацию.

И есть реальный пример. * Команда со старожилами-экспертами, 5-10 лет, доки локально, не разделяли. Проект - Проект — новый, пара лет, но команда - команда — старая, она делала другие R&D проекты до этого. Команда - Команда — 15 человек + 20 смежных команд по интеграциям и пересечениям.

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

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

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

* Интеграция в команду - команду — нужна

По ссылке - ссылке — шаблон + материалы - материалы — книги.

Вопрос: почему пошли в такой сложный проект? Ответ: на собеседовании сложность была непонятна, как раз 2 месяца поэтому появились. Но проект - проект — интересный, R&D. Так что она думает, что пошла бы, даже если бы поняла.

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

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

* Ковариантный сдвиг. Классификатор  Классификатор котиков и собак на реальных изображениях плохо распознает нарисованных, мультяшных. Распознавание на разных телефонах - телефонах — зависит от материалы. * Сдвиг в метках. Обучили птичек на одном регионе, а там 9090 % одинаковых птичек - птичек — она резких плохо классифицирует.* Дрейф концепции. Доп.тренд, которого нет. Модель предсказывала стоимость аренды недвижимости в Москве, система выделяла признаки. А пандемия дала массовый отъезд людей, признаки сохранились, а цены поменялись.

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

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

Безопасность. Функциональная (физическая) и информационная. Угрозы ИБ: конфиденциальности, целостности, доступности, злоупотребления. Особо злоупотребление: LLM классно пишет тексты, а тексты далее используют преступники. Я тут отмечу, что злоумышленники всегда использовали технологии, напримеР, рисовали фотки в фотошопе. ИИ принципиально не меняет ситуацию, тем более что у тех, кто противодействует он тоже есть в распоряжении.

* Атака отравлением - отравлением — злоумышленники выкладывают наборы данных, где stop размечен как ограничение скорости* Model inversion - inversion — злоумышленник восстанавливает обучающую выборку, восстанавливает лица людей. И там есть люди, которой система не должна увидеть. Или выборка рентгенографических данных. Или фрод - фрод — обучили на банковских данных, его выложили в облако, а злоумышленники восстановили.* Membership inference - inference — есть модель, обученная на данных медицинского учреждения. Можно понять - понять — лечился ли там человек и от чего.

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

* Разработка требований и списка свойств, включая - включая — модель качества. Для ИИ своя специфика. Основное отличие - отличие — свойство робастности

Международных методик нету, мы "смотрим «смотрим как это создается"создается».

Я тут хочу заметить, что ждать международных методик - методик — это отставать на много лет. А вот мысли включить голову и делать самим - самим — не возникает. И все ссылки в докладе были на западные статьи. При том, что практическая работа внутри идет, на MergoConf осенью я слушал интереснейший доклад по анализу архива украинских мошенников из центра в Бердянске, который в 2022 попал в российские руки, и более новые материалы в докладе были.

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

Модель нарушителя:

* Цели: несанкционированный доступ, кража персональных данных. Увы, без привязки к категориям. * Возможности, например, физический доступ (в облаке - облаке — можно взломать стену и унести комп...комп…)* Уязвимости - Уязвимости — открытые модели, отсутствие liveness detection, ...…* Способы реализации... реализации… Включая отравленный набор данных или библиотек.

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

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

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

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

Важный вопрос: не страшно ли, если модель ошибется. Здесь он. как ученый, ставит на математические доказательства на модели. Если это сделано - сделано — нормально. А если не так, а от ошибки многое зависит - зависит — не стал бы. Но для LLM доказательств этого нет. Я тут хочу сказать, что это - это — типичный подход не только к ИИ, но и к другим технологиям: пусть докажут, что работает без ошибок, тогда разрешим. Реально человек, который сейчас делает те же операции, делает ошибки. А важно, чтобы технология делала их не хуже, а желательно - желательно — лучше. У автопилотов аварийность меньше, чем у людей водителей, об этом - этом — молчат, а каждый кейс раздувают до небес.

К LLM будут отдельные требования, и они лицензируют эту деятельность, обременяя ответственностью создателей модели. Он сравнивает это с правилами дорожного движения, которые структурировали поток автомобилей. Я такой аналогии не вижу. Я вижу, что разговоры о лицензировали появились после снижения стоимости создания и развертывания моделей, особенно после того, как DeepSeek нарушил монополию Запада. Стандарты на экологичность автомобилей Евросоюз вводил так. чтобы не пустить китайцев, и ограничить американцев на свой рынок, хотя на флаге была экология. Власти проморгали соцсети и мессенджеры как значимый политический фактор, не ввели лицензии, теперь пытаются восстановить контроль с большим трудом. Поэтому на площадке LLM решили это устроить сразу.

Был вопрос про закладки в DataSet. Если изображения - изображения — то проще всего encode-decode - decode — они уберут закладки. И со звуком можно, бывают закладки на инфразвуки для голосового помощника. С текстом - текстом — сложнее, не знает. Очень понятный ответ, и хотелось бы, чтобы такого материала - материала — что делать - делать — в докладе было побольше.

= Ирина Гертовская. Как организовать работу аналитиков = В докладе - докладе — системный взгляд на организацию работы аналитиков. с фокусом на интересы разных стейкхолдеров, включая самих аналитиков.

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

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

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

* Мидлы и сеньоры - сеньоры — повышение квалификации, расширение компетенций, переход на квалифицированную работу

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

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

И дальше в презентации таблица: активности аналитиков, результаты, артефакты, для кого (это - это — важно). Получается большая простыня, дальше делим. Важно - Важно — выписать все работы. Потому что, например, взаимодействие с разработкой и тестированием или сопровождение может занимать много времени, до 7070 %, и это надо учесть при планировании.

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

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

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

Оценка эффективности:

* инциденты по по новым релизам и разбор причин ошибок, а также времени исправления - исправления — чтобы анализировать серьезность

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

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

* Начальник отдела - отдела — не отдельная профессия, организатор должен знать что и как делать, то есть быть аналитиком.

Остальное - Остальное — нарастает.

А еще: "Улыбка«Улыбка, здравый смысл и виски решают все проблемы" - проблемы» — Билл Мюррей. Здравый смысл приходит из опыта, а опыт - опыт — из отсутствия здравого смысла.