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

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

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

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

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

Еще я хочу отметить доклады #Валерий Разномазов. Архитектура мобильного приложения и #Галина Ларина Райффайзенбанк. Неочевидные практики архитектора в арсенале аналитика.

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

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

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

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

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

Племена. Атрибуты племенного поведения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это — продолжение зимнего доклада Натальи на 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») и другие исследования. Так что основания для выделения именно таких уровней — интересно. У Спенсера этого нет. Ну и для идеи уложить все виды мышления в концептуальное с существенным их урезанием тоже интересны основания.

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

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

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

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

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

• Шаблон результатов ответа, с объяснением для каких ситуаций их применять, в разных файлах.
• Инструкции — то, что добавляешь в промпе, это процедура: описал бизнес — подумай про user story и далее.
• Информация о проекте или продукте
• Информация о предметной области. Включая книги, словари и так далее

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

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

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

Принцип опциональности. Возможность выбора, но без обязательности

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

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

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

Принцип штанги: ресурсы вкладываешь туда, где гарантированный результат. и только часть на риск

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

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

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

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

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

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

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

Как делать?

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

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

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

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

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

1. Зрелость ИТ-процессов, которую мы будем повышать
2. Операционная модель, описывающая кадры и их оплату
3. Развитие инфраструктуры — hardware
4. Портфель проектов развития с диаграммой Ганта взаимных зависимостей

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

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

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

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

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

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

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

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

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

Команда сделала не то. Причина часто в том, что мы не умеем слушать заказчика, ведь они говорят долго и нудно.

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

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

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

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

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

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

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

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

По технологиям в enterprise сейчас, по мнению Валерия, есть консенсус: Javascript на фронте, хотя могут быть варианты, Java в бэке, а вот базы данных — разные, в зависимости от нагрузки: SQL и PL/SQL при низкой сменяется на noSQL и NewSQL по мере возрастания. NewSQL — это хранение Json в современных реляционках, обеспечивающих индексацию по содержимому. При этом структуру для noSQL или NewSQL описывают в YAML или JSON schema и валидируют как раз на уровне 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. Матрица Эйзенхауэра (часто-важно) для построения интерфейса. И схема орбит для функциональности: главный экран, достижимость в один клик, в два клика и так далее.

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

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

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

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

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

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