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

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

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

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

#sqadays Вадим Лунин и Вадим Зубович, Альфа-Банк (Беларусь). ИИ в тестировании: помощник, или угроза. ИИ уверенно переходит из фазы "посмотрим, что он может" в фазу "сделаем помощника и будем использовать". На Merge я неделю назад Газпромнефть рассказывал, как собрал ИИ-помощника для работы с вакансиями и подбор персонала, закрывающего полный цикл. А тут был рассказ об использовании ИИ для тестирования.

Для начала - история. ИИ начал входить в тестирование для частных задач.
* Автомат результата автотестов - Report portal - анализировал причины падений
* Self healing automation - чтобы тестовые скрипты проходили. Helenium и еще несколько
* Автоматические анализаторы performance. Yslow, PageSpeed - рекомендации по ускорению
* Обнаружение визуальной регрессии - наложение текста и картинок.
Каждый из инструментов - узкий и изолированный, он не встраивается. Подход - от инструмента. Приходит идея - и делаем нейросеть.

Дальше все гиганты начали делать комплексные решения. Отдали спеку - она все сделает. Поскольку заменяем отдел тестировщиков, лицензия стоит как отдел - а результат сомнителен.

Но появились большие языковые модели - универсальные инструменты. И тут получается история, аналогичная тому, что было 7 лет назад: был комплексный TestComplete для корпоратов за большие деньги, появился Selenium и сообщество быстро сделало инструменты. Так будет и здесь.

По направлениям - есть еще IDE-ассистенты - автокомплит на стероидах, работает неплохо. Тут он бы выделил Tabnine: начинаешь писать название метода - он выдает реализацию. И работает без VPN.

У банка ограничения - надо уметь развернуть локально. Они выбрали Llama, Mistral, Zephir. И еще Вихрь - русифицированный Mistral.

Направления
* генерация тестовой документации
* ревью кода автотестов (и вообще всех кодов)
* фазз-тестирование

Идея - порождать тесткейсы по спекам. Для начала ui-тест, по flow для мобилки. Ни одна из моделей результата не дала. Порождали обобщенные сценарии, не понимали язык. Но появилась saiga - русифицированная Llama-3, ей скормили спеку, где картинки описали текстом - и получили приемлемый результат. Еще UI запилили, куда кидаем спеку, из нее промпт идет

Бэкэнд-тесты - они проще UI, картинок нет.
* Llame-2 что-то сгенерировала, но по-английски, и там не тестовый сценарий, а какой-то ответ. И не учтен весь пользовательский путь.
* Zephir - получилось получше, похоже на описание шагов, по английски. И дописал сценарии, которые в спеке нет
* Mistral - лучше всех, по-русски, опознал полный путь. Но с промптами пришлось поиграться серьезно.
* Развернули Вихрь - тоже хорошо.

Планы: проработать спеки для UI, и еще чтобы alure, API - проработать интеграцию с инструментами типа swagger

Код-ревью. Просто попробовали отдать поруцию кода и pull request. Появился проект Alt-man review. дает pull request, пишет ответ комментарием в git. Но не взлетело - галлюцинации, неверный язык программирования

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

Фаззинг - шумовые данные, бомбардировка приложения чтобы найти утечки данных и крэши. Вышел OSS-fuzz от google - заточен на это, по задумке он сам все сделает. По факту - сам не может, тесты надо написать самим. oss-fuzz-gen - сморит коды и порождает, только для с++ - поэтмоу они пока не копали. И им им еще надо развернуть свой кластер, и обучить работать с их моделями GPT, а не с google. Это - в планах.

По горячим следам публикую отчет с #sqadays https://mtsepkov.org/SQAdays-2024a Кроме постов, которые я публиковал в ходе конференции, там пара докладов, которые были в конце и общие впечатления с конференции. Наиболее интересное для меня связано с использованием ИИ, которое перекликается с услышанным на MergeConf неделю назад: пока теоретики спорят, о том, что он может, а что не может, практики - используют.

В Питере возобновился IT Global Meetup. Для тех, кто не знает - это замечательное мероприятие, объединяющее IT-шников и организует его сообщество сообществ Piter-United.ru Один день, 15 сообществ, 50+ спикеров, 1000+ участников. Я был на нем в субботу и публикую отчет https://mtsepkov.org/ITGM-16_2024-05 Все выступления, на которых я был - интересные и очень разные. И много знакомых. Я унес с митапа интересный формат интерактива с залом, который был у Юрия Санникова и метод волшебных друидов для работы с ограничениями в TOC. А обсуждения нужны ли HR и нужны ли менеджеры дали фокусировку собственного понимания темы.

#AnalystDays Алексей Пименов. Социология на службе аналитика. В докладе - социологическая модель племени. Есть такое направление современной социологии - корпоративная антропология, которое говорит, что "на самом деле" современный мир не слишком далеко ушли от племенных моделей, как они это представляют, и во многих компаниях проявляются те самые конструкты племенного поведения.

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

Племена. Атрибуты племенного поведения.
* У племени есть общий враг - не надо им становиться
* Члены племени наделены внутренним сходством
* У племени свои ритуалы и обряды - объекты ценности, их не надо нарушать и подрывать, вы станете врагом. Иногда надо сносить. но аккуратно
* Племя понимает источник успеха, не дает шатать
* Племени есть свой язык.

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

Концепция V'ger - это из первого фильма star track. В любой компании есть история, связанная с технологией или чем-то ядерным - и нельзя нарушать. Microsoft - Basic, он во всех продуктах. Для компании - доменного регистратора все строится вокруг домена, хостинг и другие услуги пришли как развитие. И сейчас у них проблема с продуктами в телеграм, которые строятся без домена - как так, vger отсутствует. Узнайте, что является vger компании или команды, с которой взаимодействуете. Следующий шаг - понять дает ли это ограничение, или объединяет и что с этим делать.

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

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

Социальная сплоченность: в племени думаем одинаково. Спектр от хаоса до тоталитарной секты. Социальные инновации: способность группы выдать идею. Может ли сплоченная группа выдать идею? Хуже. Команду сначала сплачивают, а потом говорят - придумывайте. Они не могут. Со сплоченностью надо остановиться как только поняли общую цель, не идти до полного единомыслия. А если вы сотрудник, то оценив сплоченность вы можете понять, как предлагать инициативу. В одних командах - можно принести самому публично, в других - привлекать сторонников по-одному, в третьих - через руководителя. А когда принесли - можно практику сделать vger чтобы она сохранилась.

Про общего врага. Это не должен быть человек или другая команда, не играйте в игру против команды PVP, играйте PVE - против внешней среды, против рынка и так далее.

Ритуалы. Как искать общее в новой команде? Первое - отношения с каждым. Выявляем соуиальные группы - ВУЗ, хобби, проживание. Дальше - разматываем, создаем личный контакт. Когда с каждым личный выстроен - объединяем. Если общее. И против проблемы. И сам: можем побороться - поддержите. С удаленщиками искать общее на порядок сложнее. Возможно, игры, стриминг, телеграм-чатики.

Вопрос. Что делать, если несколько групп? Ответ: это не страшно. Страшно - когда начинают бороться. Пример - футбол: есть кузьмичи - смотрят и ультрики - подраться. Они взаимно уважают, любят футбол. Конкуренция отделов. Варианты: лидеры борются за власть - одного убрать. Если честная конкуренция - можно позволить. Очень часто работает схема, что круче тот, у кого больше подчиненных - и набирают штата, и там можно попробовать поменять критерий на эффективность, если уместно. Бывает старая против новой части команды: кто-то использовал старый самописный фреймворк. И начинают защищать.

Как узнать компанию? Познакомьтесь на конференции, пообщайтесь, посмотрите доклады - там язык проявляется. Подпишись если блоги.

Я в заключении хочу отметить, что методы корпоративной антропологии. с одной стороны, дают рабочую модель, но, с другой - искажают восприятие. В основе лежит убеждение, что человек живет в придуманной парадигме первобытного племени, живущего в PVP с другими племенами, с этим смириться и хитрыми приемами направить эту глубинную психологию в конструктив, например, превратив PVP в PVE. Штука в том, что это - в основе - та модель псевдопервобытного племени, которую придумали, когда обосновывали колониальной экспансии белых людей. Сейчас в антропологии идет отдельная история, когда исследователи сопоставляют эти модели с реальной практикой, но это - сложно. потому что племен не так много сохранилось, а при исследованиях всегда идет интерференция понятий. Опасностей для практике несколько: мы приписываем всем людям то, что свойственно лишь части; мы видим в реальности то, чего в ней нет, потому что наша призма восприятия так настроена. Это касается всех социальных моделей.

Слайды моего доклада - на моем сайте https://mtsepkov.org/SysThink-AD24

#AnalystDays Галина Ларина Райффайзенбанк. Неочевидные практики архитектора в арсенале аналитика. За докладом стоит интересный кейс: система доставки продуктов банка. Исторически была собственная доставка и система вендора, которая ей управляла, потом начали использовать курьерские компании и сделали маршрутизатор. который запросы направлял в собственную систему или универсальный гейт для внешних компаний, при этом вендорская система собственной доставки - в процессе разработки собственной для замены. Каждой системой занималась отдельная команда в реактивном режиме, и внутри - все разнообразно. В этой ситуации бизнес решил объединить все команды в одну, в ответственность которой передать всю ИТ-поддержку доставки. И для начала команде надо было разобратсья в том зоопарке, в который им достался. Для этого она пошла в обучение solution architect, и использовала эти методы для проекта.

Цепочка методов интересная.
* Canvas Остервальдера для бизнеса (доставки)
* Goal view из Archimate для интересов стейкхолдеров
* Концептуальная диаграмма бизнес-объектов
* Event storming для понимания операционной работы бизнеса

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

#AnalystDays Ekaterina Goncharova. Что такое Custom GPTs и как их готовить. На мой взгляд, самое интересное в докладе - ситуация: Екатерина из аналитиков стала продуктом, времени на аналитические задачи стало меньше, но вместо передачи их аналитикам она выделила рутинную часть, которую передала ChatGPT. B это в целом получилось. И это как раз те изменения, которые происходят, включение GPT в виде помощников вместо людей. А в целом в докладе была техника - как добавить к GPT дополнительную информацию, которую он учитывает в ответах. Это есть в платной версии, раздел ExporeGPT. Что туда стоит класть?
* Шаблон результатов ответа, с объяснением для каких сиутаций их применять, в разных файлах.
* Инструкции - то, что добавляешь в промпе, это процедура: описал бизнес - подумай про user story и далее.
* Информация о проекте или продукте
* Информация о предметной области. Включая книги, словари и так далее

#AnalystDays Рустам Иргалиев. Антихрупкость аналитиков. Менеджмент внутри команды. Антихрупкость - способность выдерживать события и извлекать пользу. Хрупкость аналитика: одна область, инструменты, процесс, заказчик, постоянное окружение - и оно окостеневает в этих условиях, ломается, когда что-то меняется. Антихрупкость аналитика - способность действовать в разнообразных условиях, и это круто и дя него и для команды. Дальше были принципы, как к этому идти.

Децентрализация
* Несколько аналитиков на проекте
* Взаимное ревью аналитиками
* Делегирование
* Новые практики

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

Естественный отбор - выживание приспособленного
* тимлид: матрицы компетенций, соревнование (быстрее согласовать задачу)
* аналитик: защита интересов (если хочешь поменять задачу), инициативность

Принцип штанги: ресурсы вкладываешь туда, где гарантированный результат. и только часть на риск
* Тимлид: перевести понятную работу на стажеров
* Проработка нескольких вариантов. Когда менялась архитектура - привлек внешнего архитектура для альтернатив
* аналитик - новые практики, plant uml вошел, проработка интересных требований заранее он отдыхал на ней, и вау что готово

#AnalystDays Ольга Павлова. Конфликты в команде между БА и разработкой: как реализовать проект и не подраться. В докладе интересная форма: Ольга проводила опрос коллег, аналитиков и разработчиков, о причинах конфликтов и о способах их решения, и в докладе была кластеризация ответов. Поэтому он дает относительно репрезентативный срез мышления сотрудников, и проблем этого мышления. Дело в том, что основной претензией (около 50%) и для разработчиков и для аналитиков были проблемы с компетентностью другой стороны. А вот собственные ошибки аналитики относили за счет объективных обстоятельств: задача прилетела вчера, сделать надо срочно и так далее. И это - проявление основной ошибки атрибуции в части оценки негатива: ты приписываешь свои проблемы объективным обстоятельствам, а у других видишь причины в их негативных личных свойствах, в данном случае - некомпетентности. Логично было бы учесть эту проблему, когда обсуждали ситуацию и ее решения. Но в докладе этого не было. Хотя один из методов - позвать разработчика поиграть роль аналитика на встрече с заказчиком или хотя бы присутствовать на демо - как раз это решает. А вот все остальное, про поговорить и понять - он не совсем про это. Хотя, конечно, рациональный разговор без эмоций способствует тому, чтобы этой ошибки избежать. И отношение к конфликту как к точке роста, который происходит, когда ты ищешь конструктивное решение - тоже правильно.

#AnalystDays Иннокентий Бодров. Почему из аналитика плохой продакт? И что с этим можно сделать. Основное различие майндсета в том, что аналитик, как правило, пробует найти комплексное решение, которое покроет большинство случаев и устроит всех стейкхолдеров, и тратит на это много времени. А продукт - он выделяет основного стейкхолдера, на которого работает, а еще смотрит на скоуп с учетом рисков: что будет, если это не делать, и если риск невелик - то принимает решение не делать. А еще продукт - не просто арбитр желаний стейкхолдеров, у него - собственное видение развития продукта. Мышление рисками и собственное видение - изменение мышления. В докладе тезис разворачивался достаточно подробно, и это - необходимо, надо эту разницу майндсет поймать, но хорошо пересказать я не смогу, так как для меня тезис понятен.

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

#AnalystDays Елена Михайлова. BPM vs API: перестать писать код и начать его рисовать. Интересный доклад о том, как вместо алгоритмической реализации в коде, например, для расчета цены, делают реализацию в виде bmpn-схемы вызова методов, который обеспечивает нужную логику. Представление алгоритма получается наглядным и гибким, и в этом - профит.

#AnalystDays Роман Васильев, Яндекс Лавка. Data-Driven Retail: синергия бизнеса и Data Science для оптимизации процессов. Интересный доклад, в фокусе которого форма сотрудничества data-аналитиков с бизнесом. У яндекс-лавки - задача управления ассортиментом и его хранением в дарк-сторе, откуда идет доставка продуктов, и которые имеют ограниченный объем хранения. И надо учитывать специфику спроса в районах, например, в центр и спальных районы спрос различается. Он пришел два года назад, с опытом аналитики в других компаниях - Мегафон, Магнит. И сделал ошибку в позиции: мы - аналитики, мы умеем считать и все сейчас посчитаем. Выяснилось, что параметров - много, критерии оцифрованы далеко не все, а главная проблема - результат не получается объяснить :"система посчитала". И у бизнеса теряется представление об управляемости.

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

Как делать?
* Понять оргструтуру заказчика и процесс принятия решений
* Понять процессы, которые существуют
* Выделить ключевые боли бизнеса
* Совместно определить направления
* Начать внедрять аналитические продукты.

Первая задача - чистки ассортимента - выводить неэффективные товары. На входе коммерция вручную собирала каждую неделю файлики, потом считал. Они сделали автоматический сбор файла. Потом в файл интегрировали умные подсказки - что вывести. И в конце - добавили процесс, свели к еженедельному review на полчаса. Сейчас совершенствуют над ML-моделью. Но важно, что началось вообще не с аналитики, а просто с автоматизации сбора файлов, 3 дня превратились в 2 часа.

Всего у них сейчас три бока: выведение, заведение новых с прогнозом спроса, и оптимизация складов. И две особых категории: (1) овощи-фрукты-ягоды-грибы и (2) готовая еда. В них есть дерево принятия решений покупателем по выбору товара, и набор метрик по приоритизации. Например, яблоки: их можно выводить, только есть аналог и он не хуже, иначе они должны присутствовать как уникальный товар, без которого покупатель уйдет к другому.

#AnalystDays Михаил Лоренц из Инфосистемы Джет. ИТ-стратегия – фундамент устойчивого развития современного бизнеса. Как известно, в условиях неопределенности и изменений ситуации оказывается востребованной разработка стратегии, она представляется волшебной палочкой, которая решит проблему: что делать и куда идти. В докладе был рассказ о том, как принято это делать. Необходимое предусловие - понятная стратегия бизнеса, потому как стратегия ИТ должна на нее опираться. Дальше делаем картину As Is, которая особенно полезна, если в руководстве ИТ поменялись люди и им надо понять, в какой ситуации они оказались. Потом - стратегическая сессию, на которой фиксируем сценарии и развилки. А дальше создаем стратегию из четырех разделов: (1) зрелость ИТ-процессов, которую мы будем повышать; (2) операционная модель, описывающая кадры и их оплату; (3) развитие инфраструктуры - hardware; (4) портфель проектов развития с диаграммой Ганта взаимных зависимостей. Если же стратегии бизнеса нет, то вместо стратегии ИТ предлагается делать план унификации и повышения надежности и доступности.

Я тут зафиксирую ряд важных моментов, которые опущены в докладе. Во-первых, откуда берется, идея целевых преобразований? Ее нельзя вывести из As Is и проблем. Часто она уже есть у заказчика, и он заказывает стратегию, чтобы ее обосновать. Это отчасти было в примерах: на стратегической сессии обсуждали варианты ЦОД, но идея, что ЦОД необходим была постулирована. Во-вторых, по докладу есть впечатление, будто существует единственный способ создавать стратегию. Это не так, Минцберг в Стратегическом сафари выделяет 10 разных школ стратегирования, описанный процесс - это школа планирования. У бизнеса стратегия может быть разработана в рамках других школ, например, школы позиционирования, и не факт, что она будет сочетаться со стратегией школы планирования для ИТ. А если посмотреть на список Минцберга, о интересным может быть школа обучения - построение стратегии как развивающийся процесс:инкрементальные шаги, инициативы, ретро по результатам; школа внешней среды – построение стратегии как реактивный процесс и
школа конфигурации – построение стратегии процесс трансформации. Кому интересно, полный список был в моем докладе на Подлодке https://mtsepkov.org/StratPodlodka и можно читать первоисточник - Минцберга. Ну и, в-третьих, насколько полезна стратегия, разработанная внешними консультантами - не слишком понятная штука. Кроме, конечно, ситуации, когда заказчик просто хочет получить обоснование для своих идей в корпоративной среде и разработка стратегии - инструмент получения этого обоснования.

#AnalystDays Ксения Мельник из NAUMEN. Роль аналитика в маркетинге B2B-продукта: оптимизация стратегий продвижения и привлечения клиентов. Ксения работает во внутреннем стартапе, разрабатывает систему управления проектами. И это - продукт, который для компании является новым, и ориентирован на другую аудиторию потребителей, чем другие продукты. Поэтому ему необходимо отдельное продвижение, и маркетингом продукта занимается не отдел маркетинга, а сотрудники команды стартапа. Это логично: у компании много продуктов, и отдел маркетинга работает с имиджем компании в целом, и продвигает продукты пакетом, а тут аудитория и продукт сильно отличаются. А продвижение продукта - необходимо. Есть мнение у инженеров, что совершенный продукт сам себя продвинет, но оно - ложное. Каким бы ни был совершенный продукт, если он никому не известен, то его никто и не купит.

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

1) Аналитика воронки - кто обращается а запросом на демонстрацию, чем обоснована потребность, как они решают проблему сейчас, какие причины отказов называют, что отличает компании, которые купили - надо организовать текущую информацию, чтобы были основания для анализа. Аналитика по отраслям - почему такие, и аналитика поражений - можно ли было избежать. Выявили топ-3 отрасли, и попробовали найти выходы на компании этих отраслей. И проанализировали причины поражений
2) Уточнение профиля клиента. По результатам первого этапа. Фреймворк HADI: гипотеза, действия, данные, выводы. Кто: отрасль, специфика деятельности, проблема, текущее решение, ЛПР. Результат - ценность для каждого профиля клиента и план по взаимодействию.
3) Карта сервиса. CJM наоборот, мы анализируем взаимодействие клиента с компанией и смотрим, где происходят провалы. И как можно устранить. Или материалы или доработка продукта. Результат - прозрачный и понятный процесс для вас и коллег.
4) Подготовка материалов. SEO-статьи - оптимизация поиска, обновление лендинга - утонение ценности (и это не просто), обновление sales tool kit для команды продаж - скрипты, референсы - увеличение конверсии; структурное ведение базы знаний - регулярно сохранять информацию для аналитики поиске паттернов
5) Работа со смежными командами. Не только рассказать, но и налаживать сотрудничество, регулярные встречи с разбором текущих активностей, и ежемесячный анализ воронки продаж - то доработать, и квартальный анализ показателей

#AnalystDays Андрей Москаленко. Применение аналитиком генеративных нейронных сетей в реверс-инжиниринге. Я ожидал от доклада гораздо большего, конкретики по применению GPT либо в виде сложных задач, либо в виде рассказа про фактуру применения. А в нем сначала был рассказ со схемами про нейронные сети вообще стиле популярной книги для детей с красочными иллюстрациями, потом про известное использование GPT для перевода текстов, переноса таблиц ии спецификаций на yaml в markdown, и резюме по интересующим станадртам, например, по медицинскому оборудованию. При чем без подробностей, просто что "он это может". При чем не только переложить конкретную таблицу из Excel в маркдаун, но и написать скрипт на питоне, который это делает - решить задачу в общем виде. И дальше было про нетривиальную задачу - по плоскому списку конфигурации оборудования выделить типы этого оборудования. Но там тоже было без деталей: выдвигал гипотезы, GPT писал по гипотезам скрипты, я их применял и проверял гипотезы, получилось. Андрей - молодец, решил задачу. Правда, я не очень понял, зачем так там GPT. На мой взгляд, эта задача решается через то, что грузишь список в Excel и там вертишь, там всего 19к строк? и за день это делается, а с GPT потребовало 40 часов. Может, я недооцениваю - но тогда было интересно увидеть это в докладе...

#AnalystDays Артем Волчков. Применение модели Захмана для анализа корпоративной БА и жизненного цикла ИС при импортозамещении ПО. Мне было интересно посмотреть, как применяют модель Захмана для реальных задач импортозамещения, какие это профиты это дает, кроме ссылки на то, что работаем не абы как, а по науке, обоснованными методами, в чем получается практический профит. К сожалению, это не получилось, доклад в формате: вот модель, мы ее применили к такому крутому проекту и к такому, и у нас получилось их успешно сделать. Механика конкретного применения и роль модели раскрыты, увы, не были. Жаль.

#AnalystDays Юлия Дробина из Nexign. Витрина API для Solution driven подхода в разработке. У них API кастомизируется в конкретных проектах под заказчика, при этом у разных заказчиков установлены разные версии компонентов, не всегда последние. API описывали в confluence, и разобраться в этом множестве версий у разных заказчиков, найти нужное - было сложно. Поэтому была идея перевести описание API в формат, сохраняемый в git, чтобы версионирование было встроено в хранение и связано с хранением кода и его версиями. Они обозначили проблему руководству, получили поддержку. И год делали пилот с Swagger Hub, и вроде успешно по функционалу. Но потом посчитали пользователей, которые читают API, их оказалось много, 400+, и стоимость лицензий получается очень высокой. И решили делать свой продукт, пилот показал ту функциональность, которая нужна им. В оаснове спецификация OAS 3.0. Сделали. Выстроен процесс: системные аналитики пишут api в it, и разработчики там же проверяют - им нравится работать в git. Дальше ревью техписов для нормальной доки по-русски, генерация идет автоматом. А тестеры - порождают тесты. И на это переведены все проекты. Перевод занял год, так как объем описаний confluence был достаточно большим, и надо было не просто научить аналитикам новому, а еще побудить их практически поработать руками над переводом, да еще в условиях текущей загрузки по проектам. Но справились, где-то административно, а где-то - проводя беседы, что "у вас все получится".

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

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

Сложная область - где причины и следствия понимаются могучим разумом, умными людьми. Область организаций-травоядных, которые пасутся на знакомой поляне, наращивая свою массу. Они большие, и для управления уже необходим цикл PCDA: Plan-Do-Check-Act, придуманный Друкером и прочий классический менеджмент. Область работы менеджеров. И все было бы хорошо, если бы внешние условия были стабильны. Потому что шаг Plan включает глубокий анализ рынка и состояния компании, которое требует времени и ресурсов. И в нынешних условиях получается аналитический коллапс, планы не являются обоснованными, а принимаются произвольно. И получается, что такие крупные компании существуют по инерции, как большие динозавры, до сильных изменений. В идеале аналитики в таких организациях как раз проводят анализ, необходимый для планирования, а также проверяют исполнение планов. Они нужны, потому как принцип действия: два раза подумай, потом - действуй. Однако, в нынешних условиях они выполняют иную задачу: рисовать показатели от требуемого результата, а не вскрывать реальное положение дел. Тех, кто вскрывает реальную ситуацию компания отторгает.

Запутанная область - в ней много объектов, так что связь причин и следствий невозможно предсказать. Там рулит эксперимент: сначала делаем, потом думаем. И играют организации-хищники. Выигрыш в конкуренции обеспечивает быстрое принятие решений, короткий цикл НОРД (OODA): Наблюдение - Ориентация (цели) - Решение - Действие. И решение принимают топы, это - предпринимательская ставка, поэтому его не отдают аналитикам, которые могут выполнять лишь служебные вспомогательные задачи.

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

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

Дальше ваш выбор: понимайте в какой компании вы работаете, Какого волка вы кормите, Доброго или шакала? Главное - не поверить, что все организации - как ваша и других правил не существует. Это - не так, мир - разнообразен.

Что почитать? Фантастика, Цель-1 и Цель-2, Пятая дисциплина Сенге, Джефри Мур, Роджер Мартин (не игра престолов, это другой).

#AnalystDays Анна Кондратенко. Конкретные проблемы абстрактного мышления. Для начала - мое замечание о терминах. Анна не дала определения абстрактного мышления, а сформулировала, что это "сложно формализуемая штука", которую, тем не менее, надо повышать. Это - проявление мутной ситуации с понятиями мышления, которое является следствием наличия конкурирующих школ, каждая из которых претендует на наилучшее представление, в этих условиях строгое определение терминов мешает маркетингу. Но если вернуться в смысловое поле, то под абстрактным мышлением в докладе подразумевается способность к построению абстракций и работы с ними. И работа с абстракциями в ИТ проработана достаточно детально: есть типизация сущностей, полиморфизм и наследование типов, выделение интерфейсов и так далее. С объектами реального мира ситуация не столь формальная. Работа с абстракциями - часть рационального мышления, которое сейчас развивают философы-рационалисты по главе с Элиезером Юдковским, автором книги-фанфика Гарри Поттер и методы рационального мышления, написанном специально для популяризации качественного мышления. Кстати, читайте, если не читали.

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

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