Я — Максим Цепков приветствую Вас на своем сайте
|
Я буду рад любым комментариям и обсуждениям. Авторизоваться для этого можно, регистрируясь на сайте или через OpenID. При желании, вы можете размещать здесь свои материалы по тематике сайта. MaksWiki содержит 708 статей IT-тематики. | |
Обо мнеМоя основная работа — проектирование корпоративных и банковских систем. Я верю, что автоматизация — дает новые возможности развития, поэтому создавая автоматизированные системы мы открываем путь прогрессу и делаем мир лучше. Я делаю это, работая главным архитектором дирекции развития решений компании CUSTIS. Я верю в эффективность командной работы, эффективность профессиональных сообществ. И я участвую в жизни ИТ-сообщества - через работу в программных комитетах конференций SECR AnalystDays и просто в коммуникациях на разных площадках. А еще я люблю путешествовать, об этом и о других идеях вне профессиональной деятельности я пишу в своем ЖЖ. |
Я в сетиhttp://www.facebook.com/mtsepkov http://www.linkedin.com/in/mtsepkov http://www.slideshare.net/mtsepkov/ e_mail M.Tsepkov@custis.ru
|
Последний пост блогаКонференция AnalystDays для меня оказалась очень содержательным завершением темы ИИ, которая началась на SQAdays и продолжилась на Highload, ArchDays и Teamlead (ссылки ведут на мои отчеты). Основных векторов развития два: (1) приложения с ИИ научились технологично встраивать в ИТ-ландшафт наряду с обычными приложениями, переходя от DevOps к ML-ops и (2) LLM успешно работает как индивидуальный помощник или специализированный функциональный агент, и теперь пора переходить к проектированию команд и компаний в целом с участием ИИ-агентов. На Teamlead я смог сформулировать: широко вещаемая цель замены людей или команд разработки на ИИ-агентов – ложная, ведь никто не ставит целью собрать мощную команду из джунов, а ИИ по многим характеристикам пока именно джун. А вот задача эффективного включения в команды и компании ИИ-джунов с уникальной компетенцией быстрого доступа к любым знаниям мира, которая присуща LLM, в отличие обычного джуна – вполне разумная и содержательная. И именно этот вектор получил развитие на AnalystDays в визионерском выступлении Димы Безуглого, который рассказывал о таком направлении развитии и о возможном месте аналитика в новом мире. А еще у Димы было гротескное представление мира ИТ, где менеджеры, не видевшие клиента и не знающие как работает система, ставят задачи разработчикам, не знающим ничего о компании. Помимо выступления Димы, про использование ИИ рассказывали Reydan Yasar, Анна Гурова Дарья Рассказова, и все выступления были про уверенное использование, а не про эксперименты. А Елизавета Французяк рассказывала про создание продуктов на основе ИИ. Были и другие доклады, но я слушал только эти. Кроме того, я хочу обратить внимание на выступления Анны Обуховой, которая впервые показала схему дофаминового пути мозга с уровнями энергии, Сергея Баранова, продолжавшее тему стоимости архитектурных решений, начатую на ArchDays, Светланы Дорониной с интересными кейсами для аналитика. А вообще все выступления, которые я слушал, были интересными, ПК конференции собрали хорошую программу. И мастер-классов тоже было много. Сам я тоже выступал с рассказом об архитектуре, рассматривая варианты решений одной задачи в монолитной и микросервисной архитектурах, а также проводил мастер-класс, на котором аналитики могли попробовать себя в роли архитекторов, сделав два варианта архитектуры для одной задаче. Тема актуальная, потому что современные ландшафты – смесь монолитов и сервисов разных размеров, и аналитику надо представлять особенности обеих архитектур. А теперь – конспекты выступлений, на которых я был. Учитывайте, что я был на малой части, потому что на конференции было пять треков, а еще много общения, которое не давало слушать доклады. Начну я с доклада Димы Безуглого, а потом пойду по порядку. Презентации уже опубликованы на сайте конференции, можно смотреть. А видео полгода будет для тех, кто купил, а потом – в свободном доступе. Дмитрий Безуглый. От техписа к архитектору: ренессанс системного аналитикаВ программе выступление называлось иначе, «Не техпис, а архитектор решений: тихое возвращение системного мышления», но смысл такой же. Вот логика рассказа.
Это – если вывернуть рассказ в позитив Димы. Потому что помимо этого была гротескная картина текущей компании, в которой менеджеры, не видевшие клиента и не знающие как работает система, ставят задачи разработчикам, не знающим ничего о компании. Применение ИИ в такой системе ведет к тому, что одни с его помощью пишут документы, а другие их обрабатывают, это будет следующий шаг на пути к потере когнитивной самостоятельности. Первый сделан давно, когда топы отдали мышление консультантам и менеджерам. А теперь – подробнее. Сначала было несколько вводных о текущей ситуации.
Итого, мы имеем иерархическую систему, в которой бизнес, который никогда не видел клиента, ставит задачу разработчикам, которые не знают ничего о бизнесе компании. Аналитики в ней соединяют тех, кому ничего не надо (разработчики) с теми, кто ничего не понимает (бизнес). Иди туда и не спрашивай зачем». Чем выше уровень – тем меньше спрашиваем «зачем». Сначала забрали у аналитиков смыслы, потом продукты забрали решения по бэклогу, AI сам напишет спецификации. Claude пишет лучше, чем аналитик с 1.5 года стажа. Пока ты поймешь, что аналитик нифига не понимает, а просто переваливает с одного на другого проходит полгода. Продукты за 15 минут с помощью ИИ генерят идеи, и спускают их аналитикам «вычитывай и сделай ТЗ». Система мертва, а мертвое не может умереть. Поэтому в такой системе аналитики останутся. Что приносит ИИ? Первый уровень – помощь, черновики, поиск идеи. Claude знает о предметной области больше, чем пользователи – можно их не спрашивать. GPT отписывает схемы лучше, чем вы сами пишете текст. А дальше это описание можно подложить в Claude. Логичный второй уровень – мы только делаем ревью документа ИИ. Результат – потеря когнитивной самостоятельности. Как только компания действительно начала использовать ИИ, способность самостоятельно принимать решение атрофируется. За год. Слои абсурда. Менеджеры, не видевшие клиента и не знающие как работает система, ставят задачи разработчикам – людям, не знающим ничего о компании. Потеря когнитивной самостоятельности началась у менеджеров давно, боссы делегировали мышление консультантам и менеджерам, а теперь оно уходит в ИИ. Дима начал использовать ИИ, чтобы писать скрипты для поддержки собственной системы, и за полгода словил эффект, который бизнес ловит давно: чем больше кода разработано – тем сложнее модифицировать. ИИ дает в 10 раз больший объем сложности, но это увеличивает хаос. Он делает пару страниц альтернатив быстро, без него шли бы два года – но это был бы осознанный процесс. Чтобы ИИ использовать разумно, он должен понимать контекст. Можно запихнуть в RAG все документы компании. Но он не разберется, потому что терминология в любой компании специфична, и передается устной традицией, в документах этого нет. И разные отделы пользуются терминами по-разному. Поэтому у ИИ – массовые галлюцинации. Он работает хорошо, если ему дали реальную модель. А запихнули переписку сотен менеджеров за 20 лет – он не разберется. Поэтому прототипы на ограниченном контексте работают, а с полным объемом данных взлететь не может. И дело не в объеме, а в том, что модель становится противоречива и идут массовые галлюцинации. Уровни управления:
Автоматизация – жесткие приложения. Если вы Walmart и все процессы залили бетоном софта, который допиливают разработчики – это окупается. Пятерочка – не очень, Азбука вкуса – еще меньше, на толпу разработчиков не хватает средств. Сейчас мы помещаем в workflow ИИ-агентов. Они могут делать триаж запросов, или оценку ценностей или пинать аналитиков и разработчиков по задачам. Строим гибридный workflow из людей и агентов. В результате то, что раньше делали 2 отдела из 50 человек, может сделать один бизнес-аналитик. Индивидуальные ассистенты. У OpenAI управление проектами работает хуже чем у Claude. Но в версии 6 они делают управление для руководителей компании, и это – другой фокус. Как iPhone когда-то сделал телефон для менеджеров, который не нужен технарям. Чтобы это работало, надо проектировать пространство компании. Диаграмма контекстов и проектирование потоков данных для формирования контекстов. Для этого нужна роль системного аналитика 2.0. У него уже есть 3-4 кейса, когда в компании используют вайб-менеджмент. Курсор, сотрудники 15-20 человек. Результат встречи – обнови задачи по проектам и добавь задачи, дальше ИИ дает изменения на ревью, можно внести или откатить. Информация из любых встреч распространяется по всем нужным контекстам – не надо быть на всех совещаниях. ИИ нормально решает задачи такого типа: возьми стратегический контекст и контекст отдела продаж, и проанализируй, что там не так. ИИ выдает адекватный анализ за 2-3 минуты. Так что большая часть запросов сверху-вниз «объясни мне как работает» можно убрать. В презентации – схема контекстов вайб-менеджмента Димы, но рассказать он не успел
Возможные позиции аналитика в этой истории.
В скором будущем настоящий системный аналитик, способный мыслить и проектировать как это понимали 20 лет назад, будет роскошью, которую компании не могут позволить себе не иметь. Предыдущая конфигурация мира умным людям не давала много возможностей – надо было долго ждать реализации. А сейчас – быстро. Про чайка-менеджмент. Эволюция людей закончилась, эволюция компаний продолжается. В Тиньков в части стратегических направлений – идет развитие. А есть синий или зеленый банки – топы с кнутом погонщика, при этом баги 15-летней давности, и там несколько тысяч аналитиков. Вопрос: сколько времени госфинансирование будет это давать. Идет конкуренция. Но есть рекомендация – не оставаться в таких местах надолго. Имитация деятельности затягивает. Максим Цепков. Архитектура софта и бизнеса в сложном ИТ-ландшафтеСовременный ИТ-ландшафт – сложная смесь приложений с разной архитектурой. Идея выступления – показать спектр архитектур, для этого я на конкретном примере показал предельные варианты – монолит и микросервисы. При этом реальная архитектура – гибридная, так как монолиты интегрируются между собой асинхронными сообщениями, а микросервисы имеют тенденцию разрастаться так, что приставка «микро» становится не уместна. Как обычно, я не пишу конспекта своих докладов. Презентация [Архитектура софта и бизнеса в сложном ИТ-ландшафте] – на странице доклада, она информативна. В дополнение к выступлению был мастер-класс, где аналитики могли попробовать спроектировать два варианта архитектуры для одной и той же задачи. У меня была для этого своя заготовка, участники предлагали свои варианты. Но в ходе голосования победил мой: турфирма, продающая типовые туры, решила дополнительно продавать индивидуальные варианты, которые покупатель набирает из готовых частей. Светлана Доронина. Use Case для мэра, халяльный кешбэк и видеоприемы психиатра: любопытные задачи в работе аналитикаАналитик сейчас очень часто сталкивается с нестандартными кейсами, и ему надо уметь погрузиться в контекст и найти решение. Светлана рассказала почти десяток разных интересных кейсов. Для работы она использует BABOK как базу знаний, BPMN для структуризации, а подходы agile и lean дают решение через итерации и эксперименты. Кейс-1. Видеоприемы в мобильном приложении клиники. Особенность: частная клиника в регионе первой внедряет такой способ обслуживания. Поэтому пациенты не понимают, что хотят получить, и заказчик не очень знает, как будет выглядеть результат. Сделать желательно дешево, во всяком случае первую версию, ведь может не взлететь. Идея заказчика – прием проходит для тех, кто уже является пациентом клиники, гипотеза, что они будут обращаться чаще, так как не надо будет ехать на прием, и качество обслуживание повысят. Она посмотрела список врачей и увидела психиатра как подходящую специализацию для пилота. Выписала участников: пациенты, врачи, регуляторы… И риски: технические – безопасность данных, юридические – нужно информированное согласие, UX-риски – к психиатру обращаются в разных состояниях, поэтому, в частности, кнопки надо подписывать словами, инфографика может не сработать. User journey map рисуем Этапы обращения. Не тривиально, что результатом этапа является эмоция пациента, на выходе – облегчение. Для каждого этапа – точки касания, которые должны обеспечить нужный эмоциональный результат. User story map – пишем все варианты, по опыту – бизнес их точно придумает, поэтому лучше иметь ввиду их наличие. А дальше – управляем через приоритеты. По сути, в приложение не просто добавили видеозвонки, а создали пространство для безопасных диалогов между врачом и пациентом. Кейс-2. Халальный кэшбек от банка. Откуда идея? Из арабских стран: в Эмиратах давно есть, люди туда ездят, и ожидают, что наши банки тоже сделают. Для проработки главное – прояснить, что халальное, а что харам, потому что ошибка дорого стоит для репутации банка. От аналитика ожидают, что он это сделает. А еще – провести SWOT-анализ, чтобы оценить полезность идеи как таковой. Сильные стороны есть – есть платформа, на ней много мусульман. Но требуется большая доработка бэка, а интеграция с халальными мерчантами непростая, так как они все новые, раньше не было практик. Преимущества не очевидны, так как банк будем первопроходцем, соберет проблемы, а конкуренты быстро подхватят. И велики риски при неверном определении статуса. В BPMN нарисовала гейты мерчантов. Там не тривиально, например, аптеки не подтверждаются, если они продают спиртосодержащие препараты, потому что это – алкоголь. Кейс-3. Оценка поведения пользователей для совместных закупок при заказе товаров стоимостью до 100 рублей. Совместные закупки до сих пор распространены в Сибири. Механика следующая. Организатор договаривается об оптовой скидке при определенном объеме закупки и организует ее, получая 16% комиссии. Люди подписываются на то, что хотят получить. Однако, требуемое количество может быть набрано не по всем позициям, поэтому ассортимент выясняется по факту, может быть меньше запланированного. И это проблема: покупатель заказал довольно много разного, а в закупку попала одна позиция за 30 рублей, например, пакетик конкретных семян, и ему за этими семенами надо ехать в пункт выдачи, да еще платить комиссию 25 рублей с заказа. Если бы в заказ попало все, что он заказал, то проблем бы не было, а так – ему не выгодно. Проблема в таком виде – результат глубинных интервью, которые она провела, на входе было просто сказано «у нас проблемы при заказе меньше 100 рублей». И оказалось, что таких заказов – довольно много, каждый пятый. Как вариант решения – предложили возможность откладывать получения заказов для консолидации, люди пользуются сервисом постоянно, а не разово. Это полечило проблему. Кейс-4. Фокус-группа пенсионеров помогла улучшить дизайн сайта. Информационный сайт бизнес накачивал сайт рекламой, не обращая внимания на пользователей: молодые, приспособятся. А оказалось, что там много пенсионеров, и они приспосабливаться не хотят. Был проведен анализ, и получилось улучшить сайт: убрали автопрокрутку, потому что пенсионеры не успевали читать, увеличили контрастность шрифта, сделали крупные кнопки. А еще вынесли автора статьи сразу после заголовка, а не в конце – люди читают избирательно. И добавили начали показывать фото автора, сделали ссылку, где появляется список всех статей. В результате журналисты начали эту ссылку в портфолио вставлять, посещаемость сайта увеличилась. Кейс-5. Отказ от красных цитат на федеральном информационном квартале. Заказчик, федеральный канал, выкладывал новости на сайт в не читаемом виде: в статьях много цитат на красном фоне. Договорились провести исследования, A/B-тестирование с разными цветами. Оказывается, цвет читателю без разницы, если он не красный. А красный – раздражает, это сигнал опасности. А еще был запрос разобраться: почему поисковики не выдают статьи? Оказалось, что большое число цитат, которое редакция считала преимуществом и требовала от журналистов, нарушает уникальность материала: цитаты копируют, а связки пишут свои. И читатели воспринимают статью с множеством цитат как copy-paste, а они хотят чтобы журналист проработал содержание. По результатам поменяли редакционную политику, число цитат снизили. Кейс-5. Увеличение числа участников спортивной секции путем опроса. Секция скалолазания пришла с запросом: какие материалы положить на сайт, для новичков или опытных? Оказалось, что они получили грант на секцию, и теперь ее надо собрать, и сайт – одно из условий гранта. И она предложила провести опрос, нужно было не дорогое решение. По сути опрос информировал родителей про такую возможность: есть секция, она бесплатна, отвлечет ваших детей от телефонов, можно заниматься с родителями, и будут бесплатные летние лагеря. За счет опроса численность учеников увеличилась на 15%. Кейс-5. АРМ мэра в планировании городской застройки. Система для генеративного проектирования: вы выделяете границы участка, задаете параметры, система она помогает проектировать, в том числе – проверяя различные нормы, включая детские сады, пожарные проезды и так далее. Это сейчас регулярно используется на градостроительных советах, для застройки можно брать текущий район или пустые территории. В ходе опытной эксплуатации говорят: инструмент – прекрасен, но где эксклюзив для мэра? Сложность в том, что прямого доступа к мэру нет. Поэтому просят ДИТ записывать реакции мэра на градостроительном совете на разные предложения в карту эмпатии. Это было долго, несколько кварталов, потому что советы проходят не часто, параллельно шла доводка проекта. Составили карту: мэр думает, как надо использовать городскую территорию и боится недовольства. Мэр соблюдает законы, учитывает не только мнение застройщиков, но и интересы жителей. Переводят это в функции, которые мэр может делать в приложении: устанавливать границы приложения, высотность застройки и так далее. Проблема в том, что это и другие пользователи могут. И тут идея: только мэр может построить генерацию без учета местных градостроительных ограничений, только с учетом федеральных). В результате Он может сравнить: как тебя ограничивает то, что приняли твои предшественники (и ты сам). Пункт – дешевый, но мэр был очень доволен. И в конце презентации – список различных инструментов. Reydan Yasar. От партнёра к катализатору: инструменты ИИ для бизнес-аналитика и владельца продуктаДокладчица – из Стамбула, Boğaziçi University. Сейчас есть много ИИ-инструментов, полезных в работе аналитика и product owner. И в выступлении было их системное представление. Инструменты поделили по способам вклада в работу: Partner – Catalyst – Connector, и для каждой фазы работы указали, какой вклад может быть внесен ИИ, в какой роли играет ИИ. Фазы работы тоже интересны, они формулируются как ответ на вопросы, и мне кажется такое представление любопытным.
А дальше был подробный обзор инструментов, многие – с экранами использования. Я тут приведу только список.
Анна Гурова из 2ГИС. LLM: Анатомия цифрового болтунаВ выступлении был исторический обзор развития LLM и его внутреннего устройства. Отмечу, что такие обзоров я слушал несколько, авторы выделяют разные реперные точки развития. У Анны были следующие.
Замечу, что в 2017 история не заканчивается, с тех пор было еще несколько прорывов, и особенно важно, что LLM научили трассировать ответы до исходной информации, объясняя свои ответы, а также рассуждать логически. Без этого нынешний уровень достигнут бы не был. Как LLM строит ответ на вопрос: «будет ли котенок играть с мячом?»
Зачем это нужно понимать аналитику?
LLM отвечают так, как будто живой человек. Но это не так. Она не думает о смыслах, так, как думаем мы, у нее нет ни здравого смысла, ни богатого личного опыта. Я лично с этим тезисом не согласен: у LLM есть и здравый смысл и гораздо больше знаний и смыслов, чем у людей – ее обучили. А что на нижнем уровне работает генеративный алгоритм – не важно, у человека в мозгу тоже электрические сигналы и химия – гормоны и нейротрансмиттеры, никакого смысла на этом уровне найти невозможно. Что будет с приходом LLM? Многие роли поменяются. Но как – неясно. Но мы найдем место и адаптируемся… Анна – амбассадор ИИ. Использует для валидации требований, проверки орфографии, создания тест кейсов, описания API. Примерно половину задач отдает LLM, потом проверяет и доводит результат. Не использует LLM, когда задача в узкой области или касается 2GIS процессов – надо передавать много контекста. Дарья Рассказова. Как с помощью ИИ провести обследование и сбор требований в новой предметной областиДарья участвует в проектах на 1С, где обследование – самый серьезный этап. Обычно аналитик проводит и обрабатывает по 3 интервью в день. ИИ снимает рутину и существенно облегчает задачу. В состав ИИ-помощника входят: OpenWebUI – интерфейс, Ollama – запуск моделей, OpenRouter – маршрутизация, LiteLLM Proxy, MCP Atlassian – доступ моделей к корпоративным источникам в confluence, это их внутренняя разработка. Система работает локально, но может обращаться к внешним LLM и API. Подготовка к Интервью. Подготовка – изучение бизнес-модели и контекста заказчика, затем – список вопросов. И ранее это часы интенсивной работы, а качество зависит от опыта аналитика и привлеченных сотрудников. Команда создала базу, куда выгрузили всю накопленную информацию в разрезе проектов и процессов. Там же вопросы предметной области, типичные интеграции, ограничения интегратора. И помощник подсказывает, как действовать, составляет опросник, в презентации было видео, как это происходит. ИИ ничего не придумывает, он берет данные из истории проектов и напоминает о важном. В результате вопросы – качественнее. Встречи – транскрибация, саммари. Но дальше надо структурировать. ИИ по готовым промптам сопоставляет саммари с опросником. Важно, что встреча должна быть проведена качественно. Проводить встречи так, чтобы они нравились ИИ – навык. Надо во-время задать уточнения, подвести промежуточные итоги. Тогда получается результат. ИИ говорит, если вопрос не обсуждался, так что еще фиксируем, что осталось обсудить. Итог – встреча превращается в источник данных. Результат – документ FTT. MindMap вместо текста – визуализация результатов встреч. Раньше это не успевали делать. Получается структурная схема, аналитик и клиент видят картину обсуждения. Переход между данными и результирующим документом. Подводя итог, ИИ дал не только инструменты, но и повод пересмотреть процессы. Не просто убрать рутину, а позволяет работать более качественно. ИИ работает не за нас, а вместе. Про качество результата. Помощник пока использован на предпроекте, который еще не пошел в разработку, поэтому мы не знаем насколько изменилось качество требований. Экспертная оценка участников – что они лучше, чем были раньше без ИИ. А дальше – практика покажет. Елизавета Французяк из Гринатом. От идеи до эффекта: как аналитики превращают гипотезы в ИИ-продуктыРассказ о переходе для ИИ-проектов на итеративную разработку через прототипы с оценкой эффектов вместо практикуемого у них традиционного водопада. В общем, и для обычных проектов итерации и промежуточные этапы уже давно стандартный способ, но корпорации живут по своим законам. И там заказчиков надо убеждать, что когда проверяешь гипотезы, и отсеиваешь неверные – то это не провал, а продвижение и экономия средств. Они привыкли мыслить в проектах с гарантированным результатом. ИИ применяется для разных направлений: обработка документов, клиентская поддержка, прогнозирование, рекомендательные системы. Елизавета рассказывала общий процесс и поясняла его на проекте встройки на корпоративный сайт рекомендательной системы, которая бы высвечивала подходящие вакансии. Логичный вопрос от Заказчика: а дает ли применение ИИ эффект? Результат зависит от данных, а в классическом подходе анализ данных идет в середине пути, на фазе разработки, а оценить эффект можно только в конце. Отмечу, что это типичная проблема водопада. Поэтому сделали первый этап быстрой проверки гипотезы на практике. И для этого надо еще сформулировать критерии успеха! Workflow получился из двух частей: сначала Гипотеза: Формирование → Исследование → Оценка результата, а уже затем Проектирование → Разработка → Тестирование → Поддержка. Рекрутеры тратят 14 часов на закрытие заявки, это медленно. Аналитик проводит интервью с рекрутерами, и у него появляются идеи применения ИИ в разных направлениях, например, для просмотра резюме и выбора перспективных, и еще несколько. Дальше оценивают перспективы каждой идеи. Потом системный аналитик изучает ИТ-ландшафт: можно ли внедрить ИИ-часть в текущую архитектуру, определяет барьеры. Для вакансий они выяснили, что резюме и вакансии в разных базах в свободной форме и плохо соответствуют друг другу. Дальше идет исследование и разработка прототипа. Для оценки резюме использовали вероятность что кандидат дойдет до конца воронки. Это первый этап работы рекрутера – ранжирование кандидатов. Прототип готовят так: data sciencetist выбирает модель машинного обучения (временные ряды, кластеризация и т.п.), для нее готовят данные и загружают. Это дешевле проекта, хотя и не мгновенно, занимает 2-4 недели, а в сложных случаев до 3 месяцев. Но это все равно не полный проект, который предусматривает настройку потоков данных, дообучение и так далее. Потом A/B-тест прототипа с рекрутерами: одни получают ранжированный список, другие – нет. Выясняется, что рекрутеры не понимают, почему модель так ранжирует кандидатов, и для них это проблема. Поэтому интерпретируемость результата стала одним из критериев, и пошла следующая итерация. Многие заказчики боятся проверять гипотезы: при провале получается не успешный проект. Но это – экономия времени. Мы не только оцениваем гипотезы, но и получаем данные о процессе, например, о наличии качественных данных. А еще – оценивают, с какими задачами ИИ справится, а с какими нет. Может быть, вообще ИИ для этой задачи сейчас бесперспективно, потому что надо сначала данные получить. Большие задачи – по кусочкам. Заказчики не понимают подход с проверкой гипотез, им это долго объясняют. Еще пример. Есть система сверки атрибутов между системами. Идея заказчика – сделать распознавание в сканах документов, а сверху робот сверки. Реальное решение – интеграция между системами и сверка по данным, без всякого распознавания. Результаты: подтвержденные гипотезы идут в проекты, есть системный процесс, заказчики не боятся говорить о проблемах. Внедрение ИИ перестало быть авантюрой, выгода видна. Nikita Taskin и Anastasia Ilyina. Постанализ юзкейсов, или как спроектировать непрерывную ABAC-авторизацию UI и APIРассказ о переходе от жесткой системы прав, прошитой в код системы, к гибкой настраиваемой модели. Кейс – таск-трекер, там были две роли: лидера команды и участника команды (и еще администратора, но это для проекта не важно). А требовалось расширение – роли стейкхолдеров двух типов: одни наблюдают за работой команды, но их права на действия ограничены относительно участников, а другие – ведут специфические атрибуты, связанные с экономикой задачи, которые должны быть скрыты от всех остальных. В общем, кейс понятный, но я ожидал большего. Наверное, потому, что много раз проектировал системы прав для корпоративных и банковских систем, где разделение ведется минимум в трех разрезах: типы сделок (платежи, кредиты, дилинг и так далее), типы клиентов (vip-корпорации, юр.лица, физ-лица, vip-физ.лица) и региональное деление по территориям, и по каждой есть еще иерархия, есть отделы, которые собирают отчетность по определенным типам сделок по всему банку, есть документы, например, платежные поручения и мемоордера, которые используются для всех типов сделок, при этом их видимость должна быть сложно ограничена, и так далее, и надо избежать комбинаторного взрыва ролей или групп пользователей. И для таск-трекера многое из этого тоже может быть нужно, если компания большая, команд сотни, они группируются по направлениям деятельности, а в таск-трекер еще организуется доступ представителей заказчика, тоже с разными правами. Рассказ начался с истории. В начале компьютеры были большие, и к ним был ограничен физический доступ. Потом появились миникомпьютеры, и на них была авторизация, логический доступ и ACL – ограничение доступа к файлам. Дальше – персональные компьютеры, электронная почта как идентификация и двухфакторная авторизация. Впрочем, тут докладчики ошибаются: ACL и разграничение доступа появились на больших компьютерах (я работал на них), потому что к ним было подключено много терминалов для доступа, а вот на первых персональных компьютерах пользователей и разграничения доступа вообще не было, они же персональные (файл можно было закрыть на запись или пометить как системный, но эту пометку мог снять любой). И почта далеко не сразу стала идентификатором, это появилось с развитием интернет и публичных сервисов, а в корпоративном мире почта – лишь атрибут пользователя до сих пор. Первая модель прав – RBAC: – роль-операция-ресурс, и в ней возникает проблема, если ц вас много филиалов, то надо делать роли для каждого филиала. Поэтому появился ABAC – атрибутивная модель, где можно описывать условиях доступа, опираясь на атрибуты пользователей и ресурсов: пользователь приписывается к филиалу, и имеет доступ только к документам этого филиала. И появился социальный логин и делегирование проверки прав провайдерам, Policy engine, которые предоставляют набор прав пользователя. В 2010 концепция zero trust: явная проверка в каждом запросе, непрерывная авторизация, наименьшие привилегии и предоставление о взломе – враг внутри и надо отследить аномалии. Я бы тут тоже расширил историю подробностями. Проверка при каждом запросе появилась с трехзвенной архитектурой, когда начали делать пул коннектов Дальше – рассказ о самом проекте. Таск-трекер, две роли: лидер команды и участник команды, лидер может все, а участник – все с незакрытыми задачами. При запуске Web-приложения шел запрос за правами доступа и их ролями. Из этого – настройка UI и фильтр списка задача на бэке, плюс проверка на бэке. Но доступ нужен не только разработчикам нужен доступ, а еще и стейкхолдерам, их делали участниками команды – получался не оправдано широкий доступ. Что изменилось. Для каждого стейкхолдера – роль со своим набором прав. Надо проверять доступ не просто доступ к задаче, а права на отдельные операции. Переход от проверки задач к проверке для каждого атрибута в контексте каждой задачи. Use case – рисуют карту. Список задач, создание задачи – команда и атрибуты, найти задачу, просмотреть, редактировать, потом заархивировать. Табличное и карточное представление. Фронт и бэк. Чтение – бэк, а отрисовка карточки в зависимости от прав – фронт, но при запросе на бэк тоже идет проверка прав. Новые, чувствительные атрибуты – часть их скрыта на чтение. И надо учитывать, формируя представление. Поэтому при запуске ходят не за правами пользователя, а за конфигурацией представлений, и за это отвечает бэк. И еще тут добавляется пост-фильтрация. И дальше запрос на конфигурацию карточки. Отмечу, что такое решение смешивает разделение фронт и бэк: бэк должен знать про карточки и их конфигурации, и изменяя фронт, мы должны одновременно вносить изменения в бэк. Я бы все-таки оставил разграничение в терминах объектов и атрибутов, а дальше фронт адаптирует интерфейс, опираясь на это. Взаимодействие фронт-бэк идет по таск-API Post-Get-Patch. Для версии-1 – достаточно было проверить роль команды, а для get – фильтр по командам. Можно ли сделать API-авторизацию на API-шлюзе? Нет. У него нет данных. А еще могут подделать данные. А запрос данных – сетевые взаимодействия, хотя можно кэшировать. Что делать, чтобы идея выиграла? Сделать кэширование, query-параметры. Я, правда, не понимаю, как это спасает от подделки параметров вызова. В таск-трекере версии-2 стейкхолдеры двух типов: работают с дополнительными атрибутами или ограниченно видят атрибуты. И поэтому для проверки нужна не только команда, а контекст всей задачи, и должны фильтроваться запросы. Поэтому авторизацию спустили на уровень сервиса задач. Для сложных кейсов – надо спускаться на уровень бизнес-логики. И язык для описания условий, на слайде были примеры. Александр Федоров из Райффайзен. От недель к минутам: как DBT + Airflow перестраивают работу аналитика и ускоряют процессы разработкиРассказ о том, как обеспечить возможность выполнения задачи аналитиком без привлечения разработчиков. До этого было классическое разделение обязанностей: аналитики разрабатывают модели, а дальше передают их разработчиком, чтобы те доводит до прода. И на стыке между аналитиками и разработчиками были трения, потому что мощность команд разработки служила ограничением. Бизнес ждет, когда идет в продуктив, им важно время от появление задачи до вывода в прод. Бизнес ставит задачи – аналитик: данные на источник и SQL-код – ждем разработку. И по пути возникает бюрократический квест – доказывать важность, аналитики борются, чтобы взять задачи в приоритете, и часто это решается решается на личных отношений. А еще есть временные лаги на стыке команд, когда задача просто лежит. Идея решения – сделать платформа самообслуживания на основе DBT+Airflow, которая позволит аналитикам самим доводить задачи до результата, сделать витрину данных для пользователя.
Бизнесу – быстрое решение. Аналитикам – быстрая проверка гипотез, простые конфигурации на yaml и не нужен python. Инженерам – фокусировка на инфраструктуре. Под капотом.
А чтобы прод не лег от тяжелых запросов, модели делают на предпроде, а перед выводом в прод – review. Решенные проблемы
Шаблон YAML – ключевой момент для описания yaml-конфигурации. И визуализация. На мой взгляд, вполне разумный подход, который дополнительно устраняет необходимость привлечения разработчиков, лишнюю коммуникацию. У нас, кстати, в свое время возникло концептуально аналогичное решение для отчетов, которое мы тиражировали во многих проектах: было сделано обобщенное решение, которое позволяло превратить готовый SQL-запрос в отчет с параметрами, доступный пользователю с интерфейса. SQL-запросы писали аналитики, обращаясь в сложных случаях к разработчикам за консультациями, с этим не было проблемы, а дальше он сразу становился доступен пользователям. Там по пути была проблема, как через этот механизм не сделать дырку в безопасности по ограничению доступа, но там тоже нашли приемлемое решение – инструкция аналитикам + review. Наталья Должкевич из Райффайзен. Критическое мышление: как не превратить анализ в драмуВыступление о том, что есть множество кейсов, когда полезно критически взглянуть на задачу прежде чем бросаться ее выполнять. Если так делать, то можно сэкономить много сил и не делать не нужную работу. Для этого полезно критическое мышление, которое Наталья понимает широко, включая туда не только рациональный анализ, соотнесение задачи с целями и контекстом, но и эмоциональный интеллект, эмпатию для понимания скрытых потребностей заказчика. Ты строишь продукт, а получается монстр. Чем умнее человек, тем больше рисков сделать ошибку, если не умеет мыслить критически. Приходят: кнопку сделать зеленым, потому что я так думаю. А потом конверсия упала… Надо уметь отделать личные мнения от аргументов. Делали систему, в ней 12 полей у каждого контакта. Оказывается, большая часть пустые – если бы запросила данные, то не потратили бы кучу сторипойнтов. Критическое мышление – про адекватность и осознанность. Критическое мышление – не только анализ данных, но и понимание контекста, логики принимающего решение. А еще это эмоциональный интеллект, эмпатия для понимания скрытых потребностей заказчика – это обогащает критическое мышление. . И коммуникация: выбрать нужное время для вопроса, описывать сложные конструкции простым языком. А также внутренняя мотивация, побуждающая проверять и перепроверять выводы, даже удобные, на это нужны усилия. И открытость к новому. Когнитивные искажения. Мозг действует по шаблонам и дорожкам, и делает это через искажения. Об этом был ее доклад на AD-19. Что мешает критическому мышлению? Чаще реагируем, чем анализируем и чаще тушим пожары, чем предотвращаем. Потому что мы в текучке: баг на проде, потом митинг по скоупу, потом письмо от заказчика, потом проголосовать про цвет кнопки. Инфошум, давление сроков и командные стереотипы. И «нужно сделать быстро» – заклинание чтобы пошли в первое попавшееся интуитивное решение. А командные стереотипы ограничивают нам поле действий: аналитик только пишет ТЗ, разработчик выполняет задачи, менеджер всегда прав – это все набор функций по умолчанию. Как взять критическое мышление? Его нельзя купить, но можно прокачать. Приемы: смена ролей, три глупых вопроса (что такое CRM, какова цель продукта), назначение антилидера-критика, реверсивное мышление (как сделать, чтобы на мероприятии никто не зарегистрировался), игра в заказчика, пять почему. Есть книги, и – неожиданно – есть настолки, которые его прокачивают. И в них можно сразу попробовать. И есть минигайд, в презентации была ссылка. Критическое мышление начинается с вопроса «зачем». Для нее это – главный вопрос. В целом понятный и актуальный доклад. У меня к нему тут два дополнения. Первое – хорошим маркером критического мышления является устойчивость к рекламе и пропаганде. Прокачка его на профессиональных вопросах заодно прокачает эту устойчивость, которая в нынешнем мире полезна. Впрочем, я знаю людей, которые применяют его избирательно, только в некоторых ситуациях, и не включают в других. А вот про чрезмерно сложные решения есть такая засада. Есть исследования командных ролей Белбина, и они показали, что Генератору идей, который как раз порождает сложные решения, обязательно нужен умный оппонент, чтобы избежать излишней сложности, обычно это роль Аналитик-Стратег. Обе роли могут совмещаться в одном человек (у меня это так), но оппонировать самому себе он не может, потому что для него собственное решение уже является простым. Хотя он может задать себе вопрос: «Как придуманным будут пользоваться?». Я в некоторый момент начал его задавать, и не только себе, но и другим людям, предлагавшим сложные решения. Если задаешь другим, то лучше так: «Мы сможем научить пользователей, или они будут обращаться к инженерам поддержки, а она – приходить к тебе, чтобы ты все настроил?», это помогает лучше, потому что Генератор обычно не хочет решать задачи поддержки. Подробнее про командные роли Белбина у меня есть статьи и доклады. Сергей Баранов. Как архитектура может обанкротить продукт и что с этим делать аналитикуЭто был рассказ о том, о чем очень редко говорят – про цену архитектурных решений. Сергей делал аналогичный доклад на ArchDays, но там я послушал только конец ([мой конспект]). И это выступление не было повторением: на ArchDays Сергей рассказывал глубоко, для архитекторов, а здесь фокус был на том, что может сделать аналитик, какие вопросы ему надо задать в ходе обследования, чтобы архитектор смог принять адекватные решения по архитектуре. Но для начало было про экономику архитектуры. Архитектура невидима для конечного пользователя и бизнеса. И аналитики тоже не всегда ее видят, примерно треть умеет разбираться. При этом написать и прочитать – разные компетенции. Но архитектура – важна, Фаулер говорил, что архитектура – невидимый слон в комнате. Цена архитектуры – это не прямые расходы на лицензии и поддержку выбранной базы данных, это opportunity cost – какую выгоду мы не можем получить из-за выбранных архитектурных решений, какие ограничения она накладывает. Если выбрали Postgress – чем при этом пожертвовали? Выбрали супер-быстрый rpg, который в России знают только 150 человек – какие последствия для поддержки и развития? Архитектурные решения часто дают невидимую сложность, которая несет когнитивную нагрузку, и дальше разработчикам и инженерам сложно, у них стресс, который блокирует мозги – в результате они принимают плохие решения. Получается, что платим столько же, а ценности получаем меньше, потому что система сложнее. А дальше сложность накапливается, растет технический долг, идет деградация архитектуры. Есть оценки: объем технического долга в США 1.52Т$, а архитектурный из них – самый жесткий. Еще одна цена архитектуры – cost of delay, цена задержки поставки решения из-за сложности архитектуры. Ее тоже понимают плохо, потому что мыслят итерациями. МЧС, скорая, пожарные – те хорошо понимают. В ИТ цена пониже, но есть. Вывели фичу на неделю позже – и конкурент получил кусок рынка и возможность продавать дороже. Фича не вовремя – бюджеты выходят из под контроля. Казалось бы, при чем здесь аналитики? Долг архитектурный – пусть архитекторы и разбираются. Но в SDLC есть analysis и design, там нет архитектора. А еще проблемы проявляются между testing и maintainance. Где аналитик соприкасается с архитектурой? Сбор требований. Аналитик фиксирует бизнес-задачу. Есть архитектурные ограничения. Правильный вопрос аналитика: можно ли реализовать требования в текущей архитектуре, как новая фича повлияет на существующие модули? Нужно формулировать требования в архитектрном контексте. Как тут можно обанкротить? Требование идет до разработчика, и он делает как понял, а если не понял, то достараивает до какой-то определенности, допридумывает, особенно если скучная задача станет от этого интересной. Требования к базе данных: быстрая, безопасная (это цитаты). В этом случае любой выбор корректен. Но спрашивать «насколько быстрая» – вредно, нужны примеры для выбора из альтернатив. Заказчик-юрист не скажет про скорость открытия страницы. А разработчик часто мыслит в локальном контексте и принимает решения у себя, и система в целом – не оптимальная. Какие бывают архитектурные ловушки в требованиях? Например, делают приложение или платформу для какой-то компании, а потом оказывается, что его надо использовать для нескольких компаний, админы которых создают собственных пользователей с ограниченем доступа, и появляется требование изоляции в multitenant. Согласование требований. Требования сначала определяют архитектуру, а потом – живут в ней. Когда архитектура оформилось – она становится жесткой. Можно ли выйти в новую страну, заложено ли это? И если архитектор узнал слишком очень поздно, то реализация может обанкротить продукт. Добавление в бэклог. По задачам есть зависимость, в том числе – в архитектуре. И вполне может получиться, что из 100 задач 90 сделали, но ни один из 10 эпиков не готов. Архитектурный долг не виден в бэклоге. Границу модулей нарушили, что-то сделали смежники ради скорости, но дальше каждое изменения этого функционала требуют работы смежной команды. Задача – построить стратегию разрешения зависимостей. Разработка. Во время разработки аналитик должен общаться с командой. Здесь причина банкротств менее очевидна. Разработчик прочитал требования как книжку, увидел, что все логично. А потом берет в реализацию – а оно не реализуется. Например, «система должна выводить несколько рекламных сообщений». Несколько – это сколько? Или насколько большой должен быть размер титула? Важно, чтобы аналитик был рядом, и помогал удерживать целостность. Если разработчик решает вопросы сам в рамках отдельной задачи, то локальная оптимизация ведет к глобальной деградации. Аналитик должен писать требования, пригодные к архитектурной реализации. Помогать держать целостность. Реальный кейс. В одной компании постановки были проработаны на 120 задач, это 1.5 года разработки. Проработка новых – не имеет смысла. Что аналитики будут год делать? Они стали подключаться к тестированию и сдаче, и скорость выросла в 2-3 раза. И эти задачи сделали за 5-6 месяцев, и пошло по потоку. Тестирование. Критерии приемки. И архитектурные проблемы. На малых данных ОК, а на больших потянет? Прод-данные, прод-поведение поиска… Сделали поиск по первым буквам – хорошо. А в продашн на каждую букву идет запрос к БД – база падает. Новая фича. Нефункциональные требования (NFR) могут потребовать новых компонентов. Как фича может сломать архитектуру? В системе сделан шардинг по регионам, при этом маркетинговую компанию проведи только в одном, и нода упала от перегрузки. Изменение существующей фичи. Оно может повлиять на существующие NFR. Самая большая жесть – в интеграции между пользователем и продуктом. Пользователь привык, он мог решить свои задачи, а теперь – не может, потому что поменяли интерфейс и стало долго, не безопасно, неудобно. Взаимодействие с архитектором. Аналитик пишет простое требование и думает “оно простое”, кнопочку изменить – а это по всем слоям изменить атрибут, и еще выгрузку поправить. Или фичей пользуются несколько пользователей, но она тяжелая и роняет работу остальных. Кейс года – для 3 сотрудников сделали отчет, который роняет БД на проде. В тестовом контуре все хорошо – там нет конкурирующих пользователей. Сложность через призму паттернов. Выставили асинхронное взаимодействие в синхронной системе или наоборот. Новые типы решений – DSL, rule engine или новый COTS – какую технологию выбрать. Выбор между разными облачными провайдерами. Может, выбрав одного – мы получим недостатки у другого. С чего начать аналитику? Барьер часто в том, что неясно о чем общаться с архитектором. Поэтому он в каждом месте вписывал вопросы. И объясняет архитектору: я хочу, чтобы мои требования вписывались в архитектуру. И сделать план по неделям. Для начала – встретиться, попросить рассказать, выявить долги, сделать реестр рисков. Потом выстроить практику совместного анализа требований (и у менеджера ее проявить), создать шаблон для ASR (архитектурно значимые трбеования), обучить команду. А вот дальше – пересмотреть требования в бэклоге, с учетом архитектурного влияния, написать ADR для ключевых решений. Потом – ретро с командой, скорректировать проблемы. В презентации есть, о чем говорить. Архитекторов мало, аналитиков – больше. Они часто конфликтуют. А будущее определяют они совместно, надо сотрудничать, потому что вместе – сильнее! Вопрос-кейс. Есть требование, которое не лезет в архитектуру. Рефакторинг – 600 часов. Заказчик их платить не хочет, всегда за 50 часов делали – поверх старого. Ответ. Архитекторы планируют на годы, продуктовые команды – недели и месяцы. Была ошибка, или правильно, но давно. Накоплено много долга, управление арх.долгом – они известны, их можно встраивать в процесс. Построены они на принципах в agile-манифесте. Компрометация Agile – потому что его продавали как средство за 2 недели сделать то, что делали 2 месяца. Там про то, как не наращивать TTM. Он бы заглянул в Sonar-куб, и не накапливал новый, а при этом придется отдавать старый. И сделать точки расширения там, где требуется гибкость – и именно там делал иначе. Вопрос: а если архитектора нет? Ответ: Искать. Иногда за него техлид, или среди разработчиков есть с архитектурными амбициями. Это нарабатывается. И можно собственную компетенцию. Зависит от масштаба, архитектура есть везде, а архитекторов как специализации может не быть, может быть простой продукт. Вопрос: можно ли архитектуру? Архитектуру можно эффективно вынуть, у него был кейс: есть неделя извлечь знания из архитектора. Сделали воркшоп на 50 человек, в миро – быстрое восстановление архитектурных знаний. Для восстановления есть методика – у Сергея было выступление, оно записано. Татьяна Половинкина Цифровой колониализм мозга: как выжить в эпоху информационного цунамиЭто был очень эмоциональный рассказ о том, как в нынешнем мире интенсивных информационных потоков быть позитивным и продуктивным, получать энергию от деятельности, а не терять ее. Без глубокого погружения и сложных систем, а за счет простых практик. Просто свое состояние делаем одним из фоновых фокусов внимания, и если у тебя есть немного времени – погладь котика или пару раз потянись, а не проверяй ленту. И, что важно, в докладе не было тяжелой борьбы: выдержать, выстоять, надо перестроиться, а было позитивное отношение к жизни, при этом – очень деятельное: жизнь – для действий, а не чтобы лежать на диване. Предыдущий абзац – моя личная интерпретация, которая может быть неверной. А теперь – конспект доклада. Мы – уязвимы в нынешнем информационном потоке, эволюция нас к этому не готовила. Но мы – можем справиться, просто надо разбираться, что происходит. Наши уязвимости:
В результате время концентрации у нас 8 секунд, меньше, чем у золотой рыбки, для которой каждый круг по аквариуму – новый (у нее – 9 секунд). Эмоциональные качели, синдром усталого мозга, клиповое мышление и потеря возможности скучать. Что делать, чтобы этого не было? Есть простые практики.
Это действует не на всех, много индивидуального. И надо делать регулярно. Это дает дополнительную энергию, освобождает от мыслемешалки. Дальше был интересный слайд с инфографикой, что такое аутизм, и пояснением, что если там человеку добавить телефон, то ее можно отнести к большинству из нас. На выступлении его пролистали быстро, а когда я писал отчет, то его поразглядывал и привожу здесь. Тезис Татьяны – верный: если добавить телефон, то получится типичный современный человек.
Но вот если на инфографику всерьез посмотреть, как на способ диагностики аутизма, то становится весьма печально, потому что я увидел легкий способ навесить ярлык пожизненного заболевания практически любому ребенку. Реально. Я полез искать источники, и обнаружил эту инфографику в изданиях профессионалов: Рахматуллина Лилия Рамиловна. Памятка. Что такое аутизм? (надо нажать «Картинками», чтобы посмотреть не скачивая), а в этом списке материалов она на 3 слайде презентации Байкаловой Ольги Александровны, адресованного школьному психологу (второй материал в списке), при этом английский вариант этой инфографики тоже есть, и даже в стебном варианте, где одна из иконок заменена на «играет в minecraft». Поэтому мамы и папы, относитесь осторожнее к тому, что вам говорят психологи. Потому что учителя заинтересованы в том, чтобы вместо реальной работы с вашим ребенком, повесить ему ярлык сложного. Отмечу, что в 1930-е годы при переходе на массовое образование была аналогичная история: не слишком послушных или успевающих детей начали отправлять в спецшколы с особенностями развития. Тогда это пресек Сталин, заявив, что советскому обществу нужны здоровые дети, так что пусть учителя в школах делают свое дело, а не устраивают саботаж (цитата неточная и по памяти). А сейчас спасение утопающих – дело рук самих утопающих, вернее, их родителей. Возвращаюсь к докладу. Если вы не платите за продукт, то продукт – это вы. Вы сдаете свой мозг – с вас собирают данные, чтобы потом вы сделали тот выбор, который нужен вовсе не вам. Вопросы для самопроверки:
Книга Джеймса Клира «Атомные привычки». Основное – не ставить цель, а сделать вокруг себя систему, которая заставляет делать дело. Сделать привычку очевидной, сделать ее привлекательной (10 приседаний за тупление в канал), сделать легкой и сделать приятной. Информация отравляет мозг и душу, должна быть дозирована. Цифровой детокс. Лагеря в лесу без телефона. ИИ. Работа с ожиданиями. Вопли: LLM уничтожит способность мыслить. До этого тоже самое говорили про калькулятор. А Платон говорил: «мы разучимся помнить, записывая на бумаге». А про часы говорили, что мы разучимся жить в своем ритме, а будем подчиняться механическому прибору. Дальше был ряд тезисов про LLM, со многими с частью из них я не согласен и привожу со своими комментариями.
Эмоции. Это очень рациональный механизм, который появился в ходе эволюции как способ выжить. Страх – избегание опасности. Гнев – движение к изменениям. Грусть – срубили деревья, а корни остались, вычистить пространство. Радость = благодарность: спасибо миру, солнышку, близким. Любопытство – поиск новых путей и возможностей. Эмоция – это энергия, эмоции – круто и здорово. Практика: благодарность комплименты, СтихиЧи – чувствуя ритм вместе, поиск нового – найдите и запишитесь на пробные занятия, их много. А замыслом доклада было закрыть всех на 40 минут молча гладить котиков, но так – не получается. Человек – возможность, у тебя все время проект. Ты не продукт, который лишь работает или потребляет. От человеческого капитала к человеческому потенциалу. Важно повторять каждый день: качественно дышать, спать, есть, пить, двигаться. Замедляться и дальше бездельничать, получать качественный контент, завершать циклы стресса. Будьте куратором своей жизни: что вы получите, листая ленту? Любить себя? Нет, любовь – всегда про нескольких. Любить себя – уходить в одиночество, не надо. Книга Асмолова «От психологии полезности к психологии достоинства». Не кто-то должен поставить лайк, а ты сам себе ставишь. Отмечу, что книга – интересная, в ней много правильного, но у меня многое вызывает вопросы, смотри мой отзыв Асмолов. Психология достоинства. Не потреблять, а осмысливать, прислушиваться к эмоциям, тренировать мозг как мускул. Качественно делать себя счастливым. Вопрос: Что делать, если человек рядом тупит в телефон? Ответ. Правильный ответ – это его выбор, но как мама 4 детей – я не согласна, надо изучать манипуляцию и отвлекать. У каждого есть выбор, а у меня есть выбор предложить что лучше. Мы любопытны, используйте приемы маркетинга. Реплика. HR не смотрят на совместимость команд, и это боль. Ответ – нет, это не страшно. Да, есть тесты, можно организовать. Но она верит в двухстороннюю эволюцию команды: ты растешь в команде, и при этом команда растет в целом. И это хорошо. Не надо искусственно создавать хорошие условия. Я с этим согласен лишь отчасти: конфликты есть констркутивные, в которых мы движемся вперед, развиваемся и получаем результат, и деструктивные, где мы разрушаем себя, других и результат. Конфликты можно предсказать, оценивая совместимость, и HR должен позаботиться о том, чтобы конфликты были конструктивны и вели к развитию. Например, за счет того, что тимлид верит в эволюцию команды и умеет ее организовать. НО есть и другие способы. Анна Обухова. Сколько энергии нужно, чтобы быть аналитиком?Анна Обухова много лет рассказывает про механизмы нейрофизиологии, устройство нашего мозга, которые полезно знать и принимать во внимание, чтобы быть эффективными. Тут как с устройством баз данных или механизмов управления памятью в Java: для эффективных программ нужно представлять, как это устроено внутри. При этом, хотя теме много лет, Анна регулярно добавляет новое. И в этом докладе появился очень важный слайд о соответствии между механизмами распространения дофамина в мозге и уровнями энергии, я привожу его в конспекте. А еще – оценка, какой уровень энергии нужен аналитику для выполнения своих обязанностей. Для заинтересовавшихся другими выступлениями сразу напишу, что у меня есть сборка Анна Обухова и другие про нейрофизиологию в работе с моими конспектами, а на youtube поиск "Анна Обухова" дает много выступлений. На RuTube тоже есть, но меньше. А вообще нейрофизиологи очень много узнали о работе мозга. А вот психологи не торопятся подвергнуть свои модели сомнению и пересобрать их с учетом нового знания. Меня это огорчало настолько, что пришлось попробовать сделать это самому, так родилась книга Инженерная модель личности. А теперь – содержание выступления. К теме нейрофизиологии Анна пришла, когда работала в банке UBS: она руководила разработкой по ценным бумагам (security), у нее было 40 владельцев продукта и 60 команд. Идея в том, что мы работаем с умными людьми, рабочие станки у них находятся в головах, и если их настроить, можно увеличить производительность. Измерения говорят, что получаем 17% чисто на настройке мозга. В организме есть 4 слоя энергии: внутри клетки, электрический, стрессовый, нейромедиаторный. В каждой клетке есть митохондрии, и на мембране происходит выработка энергии АТФ, отрывается одна группа. Это – очень тяжелая молекула, на день нужно 40 кг. Поэтому запас клеточной энергии есть только на 5-6 минут, идет постоянный обмен и восстановление энергии в клетке. Расход обычно превышает восстановление, но восстановление быстрое. Устали на тренажере – отдохнули минуту-две – и готовы к следующему. В мозгу – тоже самое. Префронтальная кора устала, вы начали отвлекаться. Как только устали – надо тупить одну минуту. Взгляд из монитора и считаешь до 60. Энергия восстанавливается. Или походить-подумать – при этом другие части мозга работают. Мозг обеспечивает энергию на желание и действие. Упрощенная схема. Внутренний крокодил. На него идет информация из внешнего мира. И дальше он передает подкорковым ядрам, в которых где потребности – 15 штук, у всех одинаковый набор. Витальные: сон, вода, еда, лень; социальные – общение, статус, саморазвитие. Мы рождаемся с одинаковыми потребностями, но дальше идет дифференциация по прошлому опыту. И подкорковые ядра ведут анализ: то, что произошло, дает ли надежду на удовлетворение потребности? Если да – идет зачаток позитивной эмоции. Это как раз интуиция: сигнал, что произошло что-то хорошее, или, наоборот, что-то плохое. Сигнал идет в лимбическую систему, внутреннему котику, это наш социальный мозг. И эмоции уже проявляются четко: скучно, страшно, любопытно и так далее. Крокодил и котик обеспечивают привычные действия. Привычные действия требуют меньше энергии. И вот над ними – префронтальная кора, внутренний человечек, которая обеспечивает волю и внимание, формирует человека. Основная передача нейрона – электрическая. У нейронов нет спонтанной электрической активности, она должна быть инициирована снаружи. Ретикулярная формация – 25 тысяч отростков, сила сдувающая дивана, и эта сила у всех разная. Активность ретикулярной формации определяет масштаб личности, ранговый потенциал. Фантастика – это про высокий ранговый потенциал. Придумывать миры – это вообще круто, голова, позволяющая придумывать миры. И в этом проблема: как только задача становится менее масштабная – становится не интересно, и лезем в книжку или пишем книжку, а не дело делаем. Стрессовая энергия. Нейроны не соприкасаются, нейрон выбрасывает в щель нейротрансмиттер, а другие нейроны – возбуждаются или тормозят. Нейротрансмиттеров много, среди них есть общего характера ускоряющие или тормозящие, а есть прицельные, которые активируют отдельные зоны мозга. Главный – дофамин. Когда крокодил прикладывает активность, идет дофамин «здесь есть что-то вкусное». Чтобы сделать задачу, надо чтобы электрическая и дофаминовая активность пришло в нужный участок префронательной коры. По пути – поднять в гиппокампе и теменной части смысл. Выработка дофамин – в носе крокодила, его вырабатывают всего 7500 нейронов из пости 100 миллиардов. И человечек понял задачу, он идет к крокодилу за энергией, а тот спрашивает «а что мне за это будет?» Если ответа нет, то возможности сконцентрировать на задаче не будет, вы полезете в телефон, захотите есть или спать и так далее. Крокодил должен его дать. А по пути дофамина, в котике – миндалина, она проводит проверка: есть ли конфликт, понятна ли задача, каково общая состояние организма? Если проверка не прошла, и миндалина решила, что надо не думать, а спасаться, то в префронатальную кору дофамин не пойдет. Вместо этого будет выброс адреналина и кортизола. Проверка – из прошлого опыта, но она – не избирательная. Вы получили плохой email, переживали – и теперь любой email – потенциальная опасность. Может быть более избирательно, не любой, а только от начальника или плохого клиента. Но это происходит еще до того, как вы email открыли. Миндалина говорит: энергия нужна на привычные действия. Бегать, орать, копать канаву будете быстрее, а вот думать – не сможете. При этом адреналин в крови распадается 15 минут, а вот у кортизола полураспад 1.5 часа, а значительные следы остаются сутки. И у вас все это время плохо работает голова. Быстро убрать Кортизол – не получится. Есть мышечные техники, но пока вы их делаете уже пришел следующий емайл. Так что надо успокоить себя и разжать эту причину, чтобы стресс не возникал. Передняя поясная извлина – переключатель «думаю – делаю». Пока вроде задача ценная, и стресса нет – надо себя пошевелить, начать действия. Нормальная задача – это когда проблем нет, есть намерение и понятен результат для себя (не для команды – крокодилу команда не интересна. А дальше – следующий вопрос. Если ты сделал задачу и превысил ожидание – будет выброс дофамина. А сделал хорошо-ожидаемо – то всего лишь не будет наказания, не будет выброса. Крокодилу-то обещал блаженство, а его нет, а энергию ты потратил. Он и говорит: ты продолбал энергию, и снова снова дам – опять продолбаешь, поэтому не дам. Непрерывно говорить «я молодец» – не получится, это обесценивается. Можно использовать авторизацию результата, она дает серотонин, но это другой механизм. Изменить из всего этого можно только уровень стресса. Определяют гаджеты по сердечному ритму – там разница биения. В теории можно по кортизолу, но его очень сложно надежно замерить, большие ситуативные вариации. У трубы дофамина есть сечение, и стресс показывает, сколько уходит на текущую деятельность, то есть не доходит до префронтальной коры. У Welltory есть более сложная модель, она выдает уровень стресса и отдельно энергию батарейки. Есть ресурсная модель человека, при этом не у всех размер батарейки 100%, в модели абсолютная шкала. Вот такой слайд требуемого уровня энергии получается.
При этом есть ситуативные колебания. Человек сидит пьет кофе, у него 74% стресса, но ему нормально. А вот постоянно меньше 40% энергии – выгорание. Если энергии 42% и больше – человек смотрит вперед, строит картинки будущего в мозге. И чем больше энергии – тем дальше может отодвинуть. Планы на год – надо 60% энергии. Сидеть пить кофе, когда 60% энергии скучно: у человека пошли идеи, что бы такое сделать. А если сангвиник или холерик, то срабатывает сила сдувающая с дивана, и он бежит на две экскурсии подряд. Что человек может в зависимости от уровня энергии?
И еще энергия определяет время проектирования будущее. Если у человека слот в неделю, а горизонт планирования в два дня – он займется в конце недели, и задача вылетит за сроки. Он просто не может думать больше, чем на два дня. А если горизонт – неделя, то он будет неделю помнить, будет ответственность. Если глубина мотивации месяц, то бесполезно ставить цели на год, именно поэтому многие долгосрочные планы развития проваливаются, если их не делят на кусочки, адекватные уровню энергии. И разным людям нужны разные размеры кусочков. Добавлю тут, что после выступления мы обсуждали эти вопросы, и Анна сказала, что техника Worklife balance, колесо баланса требует 60+% энергии, для тех, кто уже устал она бесполезна. Спрашивать у утомленного человека, что он хочет бессмысленно, он хочет, чтобы от него все отстали. Дальше выступлении Анна взяла профессиональный стандарт системного аналитика компетенции бизнес-аналитика от IIBA и выписала уровни энергии, требуемые для каждой строки, обязанности и IIBA. Для Junior достаточно 35-50%, но только там, где работа в освоенной области и с наставником. На освоение нового нужно 60+% И горизонт планирования у него месяц. Среднее количество энергии офисного сотрудника – 33%, он не справится. У Middle – кастомные процессы, а еще требуется, чтобы твои идеи воспринимались другими людьми, а это 55+% Получается профпригодность 55-60%, а для катомизации процессов 60-65%, и горизонт планирования год. Компетенции старшего аналитика требует 60% энергии. Тимлидам, чтобы держать процессы, нужно 40%, для хорошего agile – 45%. Определение стратегии – 75% и горизонт несколько лет. Можно вести мониторинг: взять welltory, и измерять энергию до совещание и после, до прогулки и после прогулки. Только прогулки – это именно прогулки, а не решение проблем на улице. Кейс, человек говорит: мне прогулки не подходят. А что вы делаете? А мы идем с дочкой и обсуждаем ее проблемы. Это – не прогулки. Для огромного количества людей работа повышает энергию. Но не везде, а там, где попадаешь в состояние потока, и это зависит от типа задач. А деятельность, в которой получаешь энергию и заряжаешься – это отдых. И пока мидл – учись держать энергию 75+, потом это заметят окружающие – и повысят. И в конце доклада – практики, как повышать и держать энергию.
Первое – простое, но сложно описывать – она телесная. Я попробую, но лучше дождитесь записи. Она очень простая, делать можно сидя. Сцепляешь руки перед собой, ладони горизонтально, и прикладываешь усилие, чтобы растянуть. Ищешь по вертикали положение, где растягивание идет трапецивидной мышцей, это индивидуально, у кого-то выше лба, у кого-то на уровне глаз или рта, или ниже на уровне груди. Когда нашел – тяньшь сильно несколько секунд, а потом расцепляешь и руки падают вниз. Эффект – вокруг должно стать четче и цветнее. Это чистая физиология: вы напрягли мышцу, а потом расслабили и освободили артерию и вену, пошло больше крови в голову. Действует 10-20 минут и первые 2 минуты – сильный эффект, чтобы начать задачу, втянуться в решение. Вам может не действовать – ищите свою, таких практик много, и достаточно освоить пару, много не надо. Как протащить энергию к префронтальной коре – модель AGROW (Action GROW). Там схема вопросов? которая обеспечивает движение, сначала смысл, потом переключение намерение-реальность.
Нельзя переставлять и выбрасывать куски. Вопросы 6 и 7 – похожи, но задаем два: если сразу 7, то может быть ступор, страх. Метод конфигурирует мозг, ч тобы начать делать задачу. Актуализация результата. Я сделал задачу – и что, что я получил? Дает признание, что мои действия привели к моему результату – внутренний мурк, серотонин. Однократно – не заметно, 14 единиц, но на полдня есть эффект. А если 6 задач, то синдром горячей руки, состояние я офигенный, я справлюсь.
Когда говорим, зачем результат – надо быть честным. Потому что это крокодил проверяет. Не надо произносить вслух, а себе не врём. Я не просто яичницу пожарил, а семимильными шагами несусь к смыслу жизни. И с отчетом тоже самое. Крутим в цикле. И чем лучше прокручивается – тем меньше энергии, протоптанная тропинка. И когда начинаешь часто делать, то мозгу начинает нравится процесс обработки задачи. И появляется энергия. Отмечу, что это – короткий вариант. В полном добавляется еще пункт «Как я могу рассказать это другим» – тогда задача превращается в часть личной истории и записывается в долговременную память. На AgileDays-2022 Анна рассказывала нейрофизиологию процесса, записи этого выступления нет, но есть мой конспект – по ссылки в начале раздела. А после выступления было два с половиной часа интересной беседы по разным вопросам, но это уже без конспекта. Ради таких бесед и другого общения и имеет смысл лично ходить на конференции. На этом я завершаю свой отчет. |
Блоги друзей |
