#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-практики итеративной работы
* Смешивать понятия и уровни абстракции. Смешиваются требования к разным системам, смешаны виды и уровни требований. Система должна экспортировать файл, а пользователь - переименовать. Или выполнение такого-то действия по большой зеленой кнопке.
* Излишнее дробление, недовыявление понятий и суждений. Связали камеру с координатами - ОК для стабильных стационарных, но для подвижных, а также для сменных такая модель плохо работает. Например, место дислокации, на котором еще и несколько камер.
* Тесная взаимосвязь понятий и суждений - взаимозависимые мелкие требования. Проверка на логику, трассировка, подключение воображения - что пользователи и разработчики будут делать.
* Взгляд с единственной точки зрения. Сделали красивый график средней скорости, а реализовали - по квартилям, и там неясно что нужно. Нужен контекст и пользователи.

#AnalystDays Виталий Якубин. Как понять непонятное. Думай как аналитик. В докладе - распространенные косяки аналитика и способы предотвращения. Отмечу, что рассказ был очень энергичным и с аналитико-центричным юмором: "аналитик - центр команды, на него молятся" или "аналитик всегда прав, хотя может ошибаться". Дальше конспект.

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

Команда сделала не то. Причина часто в том, что мы не умеем слушать заказчика, ведь они говорят долго и нудно.
* Надо разобраться в терминологии, аббревиатуры и термины.
* Проверять корректность восприятия - возвращать фразу.
* Синхронизировать цели и ожиданий. "Мы делаем это и сарай сгорит, ок? Да, он противный. Или "нет, вы строите новый, а этот пусть стоит"
* Разговаривать с заказчикам, есть те, кто не любит писать и не умеет
* Составлять логические модели
* Научиться телепатии, но это у него пока не получилось.

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

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

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

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

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

#AnalystDays Валерий Разномазов. Архитектура мобильного приложения. Когда-то я читал Руководство Microsoft по архитектуре приложений, она хороша тем, что там было собрано очень много архитектурных шаблонов с вариантами реализации. Валерий в своем докладе попробовал сделать тоже самое, но в меньшем масштабе, ограничившись архитектурой мобильного приложения в enterprise, а во второй части показал, как это приложение строится по DDD.

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

По технологиям в enterprise сейчас, по мнению Валерия, есть консенсус: Javascript на фронте, Java в бэке, а вот базы данных - разные, в зависимости от нагрузки: SQL и PL/SQL при низкой сменяется на noSQL и NewSQL по мере возрастания. NewSQL - это хранение Json в современных реляционках, обеспечивающих индексацию по содержимому. При этом структуру для noSQL или NewSQL описывают в YAML или ОЫЩТысруьф и валидируют как раз на уровне API.

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

Будет ли highload - надо оценивать. MAU и DAU. Для оценки - нужна ролевая модель.

Принципы говорят, что бизнес-логику надо реализовывать на бэке, однкако по факту она есть и на фронте и в базе данных, особенно если у нас есть legacy-компоненты, то есть везде можно выделить бизнес-слой. При возрастании нагрузки вынос части бизнес-логики в БД практически неизбежен, только надо понимать, как работает JDBC, иначе он съест весь выигрыш. Замечу, что в этом нет ничего принципиально нового: та же книга Microsoft различала физические слои, называемые tier, которым здесь является фронт, бэк и БД, и логические слои, layer, с выделением UI, бизнес-логики и хранения, и говорила о том, что соответствие может быть различным.

Драйвером архитектуры является семантика - разметка предметного поля. Тезис: мы не можем описать все бизнес-процессы, но можем описать все бизнес-объекты. Описание бизнес-объекта - по шаблону: Что, Где, Когда, Субъекты, объекты и связи. И получается Кредо - краткое описание бизнес-объекта, согласуется с бизнесом. И дальше системный аналитик по принципам DDD, проектирует отражение объекта в в классы, API и структуру данных на всех уровнях. Впрочем, я тут должен сделать замечание: DDD говорит про единообразное отражение в код, его не надо проектировать для каждого объекта, а надо выделить типы с формулировать для них правила. Естественно, при этом учитывается нагрузка. В докладе был пример: заявки реализуют три микросервиса: для создания-изменения заявок, для пользователей (UI) и для уведомлений.

Описание объектов - это не страница в confluence, это yaml или JSONschema, машинно-читаемое и проверяемое описание. И принцип API first. Впрочем, если требования нечетки и их надо выявлять через показ прототипов бизнесу, то возможен Design First, а API - после одобрения бизнесом.

UX/UI проектируем через намерение пользователя, такой бизнес-анализ через Figma. Матрица Эйзенхауэра (часто-важно) для построения интерфейса. И схема орбит для функциональности: главный экран, достижимость в один клик, в два клика и так далее.

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

* Практик Петя. Системный аналитик, изучает C#. Практицизм, бери и делай. Устранить проблему здесь и сейчас. Детальные инструкции, минимальные описания целей. Уместен для джунов-разработчиков и в ситуации, когда разработчикам нужны детальные инструкции. Проблемы: нет бизнес-описания, с вытекающими последствиями. И неверный дизайн, если не хватает опыта, и возможны конфликты с разработчиком. Как работать? Бизнес-часть, договариваться об уровне детализации.

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

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

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

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

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

#AnalystDays Нелли Бовина. PBR как инструмент для эффективной работы аналитика и команды в целом. Product Backlog Refinement - инструмент коллективного обсуждения задач при подготовке к включению в спринт. Идея состоит в том, что на отдельных встречах задачи представляются и обсуждаются командой, разработчики намечают способ реализации, тестировщики - способ тестирования, и задача оценивается. Такая встреча снижает неопределенность, позволяет на этапе разработки обойтись без уточнений и сделать то, что нужно. Они внедрили такой процесс, бэклог подготавливается на 2-3 спринта вперед. Внедрение - постепенное, сначала команда просто учится готовить задачи в формате заранее такого обсуждения, и уже потом учится оценивать. Профит - отсутствие необходимости уточнений и возвратов для изменения реализации, а также повышение точности планирования. Накладные расходы - часть подготовленных задач в низком приоритете в реализацию не идет, и время подготовки сгорает.

#AnaystDays Наталья Семенова. Концептуальное мышление: зачем оно вам, есть ли оно у вас, и как его развить. Это - продолжение зимнего доклада Натальи на WAW, конспект которого у меня есть в отчете с конференции https://mtsepkov.org/WAW-2024, и который можно посмотреть https://youtu.be/LuEjzZmWPP0. Мне по-прежнему интересны источники, на основе которых Наталья рассказывает про концептуальное мышление, надеюсь, она мне пришлет ссылки, а я опубликую. Пока я нашел, что компетенция концептуального мышления описана наряду с большим количеством других в книге Лайл и Сайн Спенсер "Компетенции на работе. Модели максимальной эффективности работы". И там выделено те самые семь уровней, о которых говорит Наталья, но детального раскрытия там нет.

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

И так, ясные (простые) системы. Для работы с ними нужно уровни (1) использование правил и (2) распознавание моделей концептуального мышления, доступные джунам. Требуется следующие виды мышления.
* Аналитическое мышление: делим на кусочки и каждый обрабатываем по схеме
* логическое мышление
* рациональное мышление - это логическое + отрицание чувств и эмоций
* системное мышление - целостное видение мира
* абстрактное мышление - работа с абстракциями
* репродуктивное мышление - переиспользование опыта знаний и других, используем инструкцию

Сложные системы - область известных неизвестных. Работают сеньоры, применяя фреймворки и стандарты решения задач. Уровни: (3) Применение сложных концепций и (4) упрощение сложности. Это позволяет превратить сложную задачу в набор простых. Требуется следующие виды мышления.
* продуктивное мышление - способность применять методы подходы и получать результаты
* стратегическое - достижение целей
* теоретическое мышление - работа с тем, что не щупали
* практическое - опрокидываем теорию в практику

Запутанные системы: неизвестные неизвестные, зона экспериментов, Исследуй - Воспринимай - Реагируй. Уровни: (5) создание новых концепций и (6) создание новых концепций по сложным вопросам.
* реалистическое мышление - стремление к пониманию истинны и ликвидации конфликтов в многоаспектной ситуации
* творческое мышление для создания новых концептов
* синтетическое мышление - способность к синтезу разных концептов
* индуктивное мышление - обобщение частных кейсов
* критическое мышление - посмотреть критически, особенно на свои выводы и рассуждения

Хаотичное системы. Причины-следствия неясны, Действуй - Чувствуй - Реагируй. Требуется уровень (7) создание новых моделей и следующие методы мышления.
* дивергентное мышление - способность видеть спектр решений
* альтернативное мышление - работать с разными мнениями на один вопрос, без выбора
* латеральное мышление - возможность мыслить не стандартно, как никто не подумал

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

Дальше были способы работы с задачами с примерами.

Меняем точку зрения:
* inside внутри системы
* inside out куда развиваться
* outside in я-точка в мире

Компания не очень нравится - а уйти не решаешься, и что делать? Смена позиции inside - inside out: какие направления развития в компании и за пределами. А ouside in - посмотрите от целей жизни. И решайте с учетом этого, а не только изнутри ситуации.

Концептуализация: все переводи в диаграммы.

Задача - приоритизация архитектурного бэклога платформы относительно продуктовых. Что делаем: Накидываем элементы, затем кидаем связи: Компания - Клиент и цепочка продажи; Компания: продажа, разработка, поддержка; Этапы, стоимость, сроки; Клиент: продукт стоимость качество функции; поток ценности и стоимость владения; Первая сделка: маржа, конкурентное преимущество, стоимость владения, стоимость приобретения. Получаем блоки: компания, продукт, клиент, по каждому - пункты. И дальше оцениваем наши задачи по каждому разрезу, получая основания для приоритетов.

Знать свои цели и ценности. Цикл Колба - как обучаются взрослые. Опыт - Анализ - Теория - Практика. Мы не школьники, взрослым теорию не рассказывают. Хотя я бы тут отметил, что зря люди стараются учиться исключительно на своем опыте. полезно поискать подходящие теории и на них опереться.

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

В ответах на вопросы.
* А если задача в хаосе - что сделать? Ответ. Посмотреть вокруг. Возможно, систему специально кто-то держит в хаосе. Насколько есть рычаги влияния и возможность выводить? Может, тут невозможно? Стоит ли терять время? Чему можно научиться в такой системе?
* А есть ли повышение сложности? Ответ - да. Есть методология и инструкции в компании, но их ставят под сомнение, отвергают - и сложность повышается.
* Позиция - субъективный подход к реальности, или есть объективная картина? Ответ - субъективно. Вы для джунов расписали - и им все ясно. А вы взаимодействуете с клиентом, неопределенность - там сложно. Или хаос.
* Вопрос. Если из запутанной попали в хаотичную? То как действовать, если сроки сжатые. Ответ - два варианта: (1) строгие правила от харизматичного руководителя, (2) долгий путь с обучением людей, очень сложно.
* Повышение уровня концептуального мышления - нельзя ставить такую задачу подчиненному. Потому что напрямую эффект не очевиден и желания тоже.

Почему мне интересны источники по концептуальному мышлению? Дело в том, что видно четкое ранжирование, в котором внизу - исполнение, а выше - решение творческих задач в условиях неопределенности - сильно выше. И это ранжирование совершенно не соответствует освоению разных типов мышления человеком. Ребенок замечательно умеет творчески решить задачу получения разрешения мамы посмотреть мультики, в том возрасте, когда выполнение инструкций совершенно недоступно. Потом, правда, школа успешно гробит способности к творческому мышлению, об этом свидетельствует зефирный эксперимент (ищем "Marshmallow Peter Skillman") и другие исследования. Так что основания для выделения именно таких уровней - интересно. У Спенсера этого нет. Ну и для идеи уложить все виды мышления в концептуальное с существенным их урезанием тоже интересны основания.

Собрал заметки с #AnalystDays в общий отчет https://mtsepkov.org/AnalystDays-2024a Как всегда, на конференции были хорошие доклады и много интересного общения. А еще в Питере стояла замечательная погода! Надеюсь, она будет и в конце июня, когда я поеду на #Highload и #Teamlead. Кстати, я тогда буду долго, если у кого есть желание - можно будет встретиться.

В моей работе над моделью личности - важный этап: опубликована книга "Инженерная модель личности. Меняя себя и других – понимай устройство". Доступна на ридеро https://ridero.ru/books/inzhenernaya_model_lichnosti/ и других площадках. Можно не только читать электронно, но и заказать печать по требованию в бумажном виде, но я не дорабатывал презентации под черно-белый вариант. По сравнению с серией статей, которую я публиковал зимой, в книгу включен ряд моделей, доработана структура и отдельные разделы на основе обсуждения статей и докладов по теме. Читайте! Исходные статьи по-прежнему доступны на vc.ru, а оглавление здесь https://mtsepkov.org/Self-Det