Изменения

{{Conf-Ref}}Конференция [https://analystdays.ru/ru/program/115980 '''AnalystDays-18'''] прошла в Петербурге 24-25.05.2024. Я участвовал почти во всех конференциях, это всегда много содержательных докладов и много общения. И среди участников конференции - конференции — много знакомых, с которыми уже неоднократно встречался на разных конференциях, а также тех, кто читает мой блог и смотрит за выстплениямивыступлениями, так что это получается не просто мероприятие, а встреча со знакомыми людьми. И это - это — при том, что на конференции очень много новых участников, состав постоянно обновляется.

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

Мой доклад [[Системное мышление и его место в работе аналитика (AnalystDays-2024a)|'''Системное мышление и его место в работе аналитика''']] тоже был посвящен мышлению. На прошлой AnalystDays я уже делал доклад [[Рациональное и системное мышление: практики и компетенции аналитика (AnalystDays-2023)|'''Рациональное и системное мышление: практики и компетенции аналитика''']], и в обсуждении от разных участников был тезис: Системное мышление - мышление — это круто, но зачем так сложно, есть же специализированные модели - модели — Archimate, c4 model, BPMN и другие, почему их недостаточно?", и своим докладом я попробовал ответить на это возражение. Так что рассказ строился от практических задач, в которых использование специализированных моделей влечет проблемы, если у аналитика не хватает системного мышления для удержания сложных моделей. Основных проблемных места два: стык между бизнесом и софтом, и понимание конструкции бизнеса в целом, для которого распространенной процессной модели BPMN хватает далеко не всегда. За подробностями - подробностями — смотрите доклад, конспекты собственных докладов я обычно не пишу.

Среди других докладов я хочу отметить доклад [[#Ekaterina Goncharova. Что такое Custom GPTs и как их готовить]]. Там основное - основное — не техника использования ИИ, а то, что аналитик, став продактом, начал делегировать аналитическую работу, на которую перестало хватать времени, не другим аналитикам, а ИИ. Так получалось проще и эффективнее. И это - это — качественный переход. Да, пока редкий, но получается, что делегировать ИИ простую работу уже легче, чем сотруднику.

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

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

Ну а теперь - теперь — о докладах.

В докладе - докладе — социологическая модель племени. Есть такое направление современной социологии - социологии — корпоративная антропология, которое говорит, что "на «на самом деле" деле» современный мир не слишком далеко ушли от племенных моделей, как они это представляют, и во многих компаниях проявляются те самые конструкты племенного поведения.

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

* У племени есть общий враг - враг — не надо им становиться

* У племени свои ритуалы и обряды - обряды — объекты ценности, их не надо нарушать и подрывать, вы станете врагом. Иногда надо сносить, но аккуратно

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цепочка методов интересная.

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

На мой взгляд, самое интересное в докладе - докладе — ситуация: Екатерина из аналитиков стала продуктом, времени на аналитические задачи стало меньше, но вместо передачи их аналитикам она выделила рутинную часть, которую передала ChatGPT. B это в целом получилось. И это как раз те изменения, которые происходят, включение GPT в виде помощников вместо людей. А в целом в докладе была техника - техника — как добавить к GPT дополнительную информацию, которую он учитывает в ответах. Это есть в платной версии, раздел ExporeGPT. Что туда стоит класть?

* Инструкции - Инструкции — то, что добавляешь в промпе, это процедура: описал бизнес - бизнес — подумай про user story и далее.

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

Децентрализация

Естественный отбор - отбор — выживание приспособленного

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

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

= Иннокентий Бодров. Почему из аналитика плохой продакт? =

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

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

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

Интересный доклад, в фокусе которого форма сотрудничества data-аналитиков с бизнесом. У яндекс-лавки - лавки — задача управления ассортиментом и его хранением в дарк-сторе, откуда идет доставка продуктов, и которые имеют ограниченный объем хранения. И надо учитывать специфику спроса в районах, например, в центр и спальных районы спрос различается. Он пришел два года назад, с опытом аналитики в других компаниях - компаниях — Мегафон, Магнит. И сделал ошибку в позиции: мы - мы — аналитики, мы умеем считать и все сейчас посчитаем. Выяснилось, что параметров - параметров — много, критерии оцифрованы далеко не все, а главная проблема - проблема — результат не получается объяснить:"система посчитала"«система посчитала». И у бизнеса теряется представление об управляемости.

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

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

= Михаил Лоренц из Инфосистемы Джет. ИТ-стратегия – стратегия — фундамент устойчивого развития современного бизнеса =

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

А дальше создаем стратегию из четырех разделов:

# Развитие инфраструктуры - инфраструктуры — hardware # Портфель проектов развития с диаграммой Ганта взаимных зависимостей

Я тут зафиксирую ряд важных моментов, которые опущены в докладе. Во-первых, откуда берется, идея целевых преобразований? Ее нельзя вывести из As Is и проблем. Часто она уже есть у заказчика, и он заказывает стратегию, чтобы ее обосновать. Это отчасти было в примерах: на стратегической сессии обсуждали варианты ЦОД, но идея, что ЦОД необходим была постулирована.

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

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

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

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

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

Мне было интересно посмотреть, как применяют модель Захмана для реальных задач импортозамещения, какие это профиты это дает, кроме ссылки на то, что работаем не абы как, а по науке, обоснованными методами, в чем получается практический профит. К сожалению, это не получилось, доклад в формате: вот модель, мы ее применили к такому крутому проекту и к такому, и у нас получилось их успешно сделать. Механика конкретного применения и роль модели раскрыты, увы, не были. Жаль.

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

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

Теперь вернусь к докладу. О развитии абстрактного мышления предлагались практики: * Тренировать насмотренность

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* Практик Петя. Системный аналитик, изучает C#. Практицизм, бери и делай. Устранить проблему здесь и сейчас. Детальные инструкции, минимальные описания целей. Уместен для джунов-разработчиков и в ситуации, когда разработчикам нужны детальные инструкции. Проблемы: нет бизнес-описания, с вытекающими последствиями. И неверный дизайн, если не хватает опыта, и возможны конфликты с разработчиком. Как работать? Бизнес-часть, договариваться об уровне детализации. * Стратег Зоя. В СА из бизнеса, хорошо понимает и генерит космические и прорывные идеи. Процессный подход, ограничения лишь в голове. Способ решения - решения — выгодный бизнесу, в описании это очень хорошо. А дизайна - дизайна — нет, оно не прорабатывается. Хорошая работа с мотивированными разработчиками. Ориентация на будущее помогает подбирать решения сейчас. Но! если разработчики неопытные, джуны - джуны — будут проблемы. И с техдоком может быть пробел. А ще стратег не может оценить реализуемость, сроки и ресурсы - ресурсы — и может быть большая сложность решений. Соответственно работа с опытным разработчиком или с тех-экспертом* Педант Федя. Работал проектным менеджером, подвыгорел, и пошел в аналитики. Фокус - Фокус — процесс и документация, формализация и проработка мелочей. Фокус на процесс, сплочение коллектива на задаче. Может начать управлять или быть оркестратором процесса - процесса — это профит. А минусы - минусы — когда он навязывает свое видение сроков и решений, возможны конфликтам. А следование правилам и формализм дают накладные расходы. И тут надо очертить ответственность, смягчение выпадов.

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

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

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

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