7192
правки
Изменения
Новая страница: «Конференция [https://analystdays.ru/ru/program/115980 '''AnalystDays-18'''] прошла в Петербурге 24-25.05.2024. Я участвовал…»
Конференция [https://analystdays.ru/ru/program/115980 '''AnalystDays-18'''] прошла в Петербурге 24-25.05.2024. Я участвовал почти во всех конференциях, это всегда много содержательных докладов и много общения. И среди участников конференции - много знакомых, с которыми уже неоднократно встречался на разных конференциях, а также тех, кто читает мой блог и смотрит за выстплениями, так что это получается не просто мероприятие, а встреча со знакомыми людьми. И это - при том, что на конференции очень много новых участников, состав постоянно обновляется.
Эта конференция не типична тем, что продажи очного участия были закрыты за полнра месяца по переполнению площадки. И действительно, во многих залах на докладахз было очень плотно. При том, что программа конференции тогда еще не была сформирована, по значительной части докладов решенеи принималось позднее. Что говорит о хорошей репутации конференции. Надеюсь, организаторы учтут это и смогут найти более вместительную площадку.
На конференции было много качественных докладов. В их числе я хотел бы отметить доклады про мышление и различные модели социального устройства. Это .
Мой доклад [[Системное мышление и его место в работе аналитика (AnalystDays-2024a)|'''Системное мышление и его место в работе аналитика''']] тоже был посвящен мышлению. На прошлой AnalystDays я уже делал доклад [[Рациональное и системное мышление: практики и компетенции аналитика (AnalystDays-2023)|'''Рациональное и системное мышление: практики и компетенции аналитика''']], и в обсуждении от разных участников был тезис: Системное мышление - это круто, но зачем так сложно, есть же специализированные модели - Archimate, c4 model, BPMN и другие, почему их недостаточно?", и своим докладом я попробовал ответить на это возражение. Так что рассказ строился от практических задач, в которых использование специализированных моделей влечет проблемы, если у аналитика не хватает системного мышления для удержания сложных моделей. Основных проблемных места два: стык между бизнесом и софтом, и понимание конструкции бизнеса в целом, для которого распространенной процессной модели BPMN хватает далеко не всегда. За подробностями - смотрите доклад, конспекты собственных докладов я обычно не пишу.
Среди других докладов я хочу отметить доклад [[]]. Там основное - не техника использоания ИИ, а то, что аналитик, став продактом, начал делегировать аналитическую работу, на которую перестало хватать времени, не другим аналитикам, а ИИ. Так получалось проще и эффективнее. И это - качественный переход. Да, пока редкий, но получается, что делегирвоать ИИ простую работу уже легче, чем сотруднику.
В целом доклады конференции - хорошие и востребованные аудиторией. Среди участников конференции - большинство молодых, которые в профессии недавно и развиваются. Но, на правах опытного и давно участвующего, я отмечу следующую проблему в ряде докладов: докладчик не приземляет теоретическую модель на материал, не показывает особенности применения. А ведь это - самое важное. Моодель можно прочитать. Интересно - чем именно вам помогло ее применение, как был достигнут позитивный эффект, и какие были сложности. Ведь к моделям обращаются многие, а успешно воспользоваться получается далеко не у всех. Этот феномен известен как "ошибка выжившего": мы видим, чем пользовались в успешных проектах, пробуем - а оно не получается, потому что важно еще как именно этим пользовались. И хочется, чтобы доклад это раскрывал.
А еще доклады отражают общую проблему отрасли: отсутствие культуры знакомства с проработанными сложных теорий. Термин при этом могут знать, но понимать в бытовом смысле, например, системное мышление как синомним для мышления о чем-то сложном, без понмиания стоящих за ним принципов, методов и концепций. А в результате простые вещи превращаются в сложные изи запутанные, если говорить в терминах Кеневин-фреймворка. Вместе с тем, материалов по разным териям сейчас достаточно много и стоит их искать и знакомитсья, прокачивая свой метанавык быстрого освоения новых теорий. И это - не проблема конференции, тут доклады отражают ситуацию в отрасли в целом.
Ну а теперь - о докладах.
= Алексей Пименов. Социология на службе аналитика =
В докладе - социологическая модель племени. Есть такое направление современной социологии - корпоративная антропология, которое говорит, что "на самом деле" современный мир не слишком далеко ушли от племенных моделей, как они это представляют, и во многих компаниях проявляются те самые конструкты племенного поведения.
Когда эти модели полезны аналитику? Это взаимодействие с людьми: снимать потребности, их исследовать, взаимодействовать с новым коллективом. Понимание поведения социальных групп - ключ к эффективному общению. В докладе - адаптация и упрощение практик для простых нужд.
Племена. Атрибуты племенного поведения.
* У племени есть общий враг - не надо им становиться
* Члены племени наделены внутренним сходством
* У племени свои ритуалы и обряды - объекты ценности, их не надо нарушать и подрывать, вы станете врагом. Иногда надо сносить. но аккуратно
* Племя понимает источник успеха, не дает шатать
* Племени есть свой язык.
Для начала: Мы с тобой одной крови. Идентичность. Американский психопат - визитки, меряются друг с другом. Одинаковые очки и костюмы - но они видят разницу и могут понять иерархию. Человек - которого они не пускают. Слова, одежда, жесты, рестораны. Не приходить во фраке к неформалом и наоборот.
Концепция 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 - посмотрите от целей жизни. И решайте с учетом этого, а не только изнутри ситуации.
Концептуализация: все переводи в диаграммы.
mtsepkov, [25.05.24 22:10]
Задача - приоритизация архитектурного бэклога платформы относительно продуктовых. Что делаем: Накидываем элементы, затем кидаем связи: Компания - Клиент и цепочка продажи; Компания: продажа, разработка, поддержка; Этапы, стоимость, сроки; Клиент: продукт стоимость качество функции; поток ценности и стоимость владения; Первая сделка: маржа, конкурентное преимущество, стоимость владения, стоимость приобретения. Получаем блоки: компания, продукт, клиент, по каждому - пункты. И дальше оцениваем наши задачи по каждому разрезу, получая основания для приоритетов.
Знать свои цели и ценности. Цикл Колба - как обучаются взрослые. Опыт - Анализ - Теория - Практика. Мы не школьники, взрослым теорию не рассказывают. Хотя я бы тут отметил, что зря люди стараются учиться исключительно на своем опыте. полезно поискать подходящие теории и на них опереться.
Итого, рецепт: менять взгляд, изучать модели, осваивать сопутствующие типы мышления, все в диаграммы - концептуализация.
В ответах на вопросы.
* А если задача в хаосе - что сделать? Ответ. Посмотреть вокруг. Возможно, систему специально кто-то держит в хаосе. Насколько есть рычаги влияния и возможность выводить? Может, тут невозможно? Стоит ли терять время? Чему можно научиться в такой системе?
* А есть ли повышение сложности? Ответ - да. Есть методология и инструкции в компании, но их ставят под сомнение, отвергают - и сложность повышается.
* Позиция - субъективный подход к реальности, или есть объективная картина? Ответ - субъективно. Вы для джунов расписали - и им все ясно. А вы взаимодействуете с клиентом, неопределенность - там сложно. Или хаос.
* Вопрос. Если из запутанной попали в хаотичную? То как действовать, если сроки сжатые. Ответ - два варианта: (1) строгие правила от харизматичного руководителя, (2) долгий путь с обучением людей, очень сложно.
* Повышение уровня концептуального мышления - нельзя ставить такую задачу подчиненному. Потому что напрямую эффект не очевиден и желания тоже.
Почему мне интересны источники по концептуальному мышлению? Дело в том, что видно четкое ранжирование, в котором внизу - исполнение, а выше - решение творческих задач в условиях неопределенности - сильно выше. И это ранжирование совершенно не соответствует освоению разных типов мышления человеком. Ребенок замечательно умеет творчески решить задачу получения разрешения мамы посмотреть мультики, в том возрасте, когда выполнение инструкций совершенно недоступно. Потом, правда, школа успешно гробит способности к творческому мышлению, об этом свидетельствует зефирный эксперимент (ищем "Marshmallow Peter Skillman") и другие исследования. Так что основания для выделения именно таких уровней - интересно. У Спенсера этого нет. Ну и для идеи уложить все виды мышления в концептуальное с существенным их урезанием тоже интересны основания.
= Галина Ларина Райффайзенбанк. Неочевидные практики архитектора в арсенале аналитика =
За докладом стоит интересный кейс: система доставки продуктов банка. Исторически была собственная доставка и система вендора, которая ей управляла, потом начали использовать курьерские компании и сделали маршрутизатор. который запросы направлял в собственную систему или универсальный гейт для внешних компаний, при этом вендорская система собственной доставки - в процессе разработки собственной для замены. Каждой системой занималась отдельная команда в реактивном режиме, и внутри - все разнообразно. В этой ситуации бизнес решил объединить все команды в одну, в ответственность которой передать всю ИТ-поддержку доставки. И для начала команде надо было разобратсья в том зоопарке, в который им достался. Для этого она пошла в обучение solution architect, и использовала эти методы для проекта.
Цепочка методов интересная.
* Canvas Остервальдера для бизнеса (доставки)
* Goal view из Archimate для интересов стейкхолдеров
* Концептуальная диаграмма бизнес-объектов
* Event storming для понимания операционной работы бизнеса
К сожалению, рассказ о проблемах и методах был не на материале проекта, а в метафоре зоопарка. На мой взгляд, отсутствие фактуры сильно снижает качество доклада, было бы очень интересно узнать увидеть фактуру этих методов в реальном проекте. Но связку разных методов такой рассказ неплохо показывал. Event storming рассказывали совсем пунктиром, и там тоже интересная последовательность: события - пользователи и внешние системы - связь через команды - реакция на события: read model информации пользователю и правила с командами. В общем, рассказ - любопытный, и жаль, что приземления на реальный материал в нем не было.
= Ekaterina Goncharova. Что такое Custom GPTs и как их готовить =
На мой взгляд, самое интересное в докладе - ситуация: Екатерина из аналитиков стала продуктом, времени на аналитические задачи стало меньше, но вместо передачи их аналитикам она выделила рутинную часть, которую передала ChatGPT. B это в целом получилось. И это как раз те изменения, которые происходят, включение GPT в виде помощников вместо людей. А в целом в докладе была техника - как добавить к GPT дополнительную информацию, которую он учитывает в ответах. Это есть в платной версии, раздел ExporeGPT. Что туда стоит класть?
* Шаблон результатов ответа, с объяснением для каких сиутаций их применять, в разных файлах.
* Инструкции - то, что добавляешь в промпе, это процедура: описал бизнес - подумай про user story и далее.
* Информация о проекте или продукте
* Информация о предметной области. Включая книги, словари и так далее
= Рустам Иргалиев. Антихрупкость аналитиков. Менеджмент внутри команды =
Антихрупкость - способность выдерживать события и извлекать пользу. Хрупкость аналитика: одна область, инструменты, процесс, заказчик, постоянное окружение - и оно окостеневает в этих условиях, ломается, когда что-то меняется. Антихрупкость аналитика - способность действовать в разнообразных условиях, и это круто и дя него и для команды. Дальше были принципы, как к этому идти.
Децентрализация
* Несколько аналитиков на проекте
* Взаимное ревью аналитиками
* Делегирование
* Новые практики
Принцип опциональности. Возможность выбора, но без обязательности
* Аутсорс
* выбор инструментов и практик
* управление расписанием встреч
* выбор уровня детализации задач
* возможность аналитику подключить кого-то от команды
Естественный отбор - выживание приспособленного
* тимлид: матрицы компетенций, соревнование (быстрее согласовать задачу)
* аналитик: защита интересов (если хочешь поменять задачу), инициативность
Принцип штанги: ресурсы вкладываешь туда, где гарантированный результат. и только часть на риск
* Тимлид: перевести понятную работу на стажеров
* Проработка нескольких вариантов. Когда менялась архитектура - привлек внешнего архитектура для альтернатив
* аналитик - новые практики, plant uml вошел, проработка интересных требований заранее он отдыхал на ней, и вау что готово
= Ольга Павлова. Конфликты в команде между БА и разработкой: как реализовать проект и не подраться =
В докладе интересная форма: Ольга проводила опрос коллег, аналитиков и разработчиков, о причинах конфликтов и о способах их решения, и в докладе была кластеризация ответов. Поэтому он дает относительно репрезентативный срез мышления сотрудников, и проблем этого мышления. Дело в том, что основной претензией (около 50%) и для разработчиков и для аналитиков были проблемы с компетентностью другой стороны. А вот собственные ошибки аналитики относили за счет объективных обстоятельств: задача прилетела вчера, сделать надо срочно и так далее. И это - проявление основной ошибки атрибуции в части оценки негатива: ты приписываешь свои проблемы объективным обстоятельствам, а у других видишь причины в их негативных личных свойствах, в данном случае - некомпетентности. Логично было бы учесть эту проблему, когда обсуждали ситуацию и ее решения. Но в докладе этого не было. Хотя один из методов - позвать разработчика поиграть роль аналитика на встрече с заказчиком или хотя бы присутствовать на демо - как раз это решает. А вот все остальное, про поговорить и понять - он не совсем про это. Хотя, конечно, рациональный разговор без эмоций способствует тому, чтобы этой ошибки избежать. И отношение к конфликту как к точке роста, который происходит, когда ты ищешь конструктивное решение - тоже правильно.
= Иннокентий Бодров. Почему из аналитика плохой продакт? =
И что с этим можно сделать. Основное различие майндсета в том, что аналитик, как правило, пробует найти комплексное решение, которое покроет большинство случаев и устроит всех стейкхолдеров, и тратит на это много времени. А продукт - он выделяет основного стейкхолдера, на которого работает, а еще смотрит на скоуп с учетом рисков: что будет, если это не делать, и если риск невелик - то принимает решение не делать. А еще продукт - не просто арбитр желаний стейкхолдеров, у него - собственное видение развития продукта. Мышление рисками и собственное видение - изменение мышления. В докладе тезис разворачивался достаточно подробно, и это - необходимо, надо эту разницу майндсет поймать, но хорошо пересказать я не смогу, так как для меня тезис понятен.
Еще в докладе было показан легкий формат спеки в миро, который они используют. Спеки делает продукт, аналитиков нет, она верхнего уровня, и есть презентация команде, где проговариваются цели, опасные тест-кейсы, а разработка делает концепт реализации. На мой взгляд, это - отдельная ценная тема.
= Елена Михайлова. BPM vs API: перестать писать код и начать его рисовать =
Интересный доклад о том, как вместо алгоритмической реализации в коде, например, для расчета цены, делают реализацию в виде bmpn-схемы вызова методов, который обеспечивает нужную логику. Представление алгоритма получается наглядным и гибким, и в этом - профит.
= Роман Васильев, Яндекс Лавка. Data-Driven Retail: синергия бизнеса и Data Science для оптимизации процессов =
Интересный доклад, в фокусе которого форма сотрудничества data-аналитиков с бизнесом. У яндекс-лавки - задача управления ассортиментом и его хранением в дарк-сторе, откуда идет доставка продуктов, и которые имеют ограниченный объем хранения. И надо учитывать специфику спроса в районах, например, в центр и спальных районы спрос различается. Он пришел два года назад, с опытом аналитики в других компаниях - Мегафон, Магнит. И сделал ошибку в позиции: мы - аналитики, мы умеем считать и все сейчас посчитаем. Выяснилось, что параметров - много, критерии оцифрованы далеко не все, а главная проблема - результат не получается объяснить:"система посчитала". И у бизнеса теряется представление об управляемости.
Вообще аналитик может занимать одну из трех позиций: сервис, который просто выполняет задачи; партнер, который решает проблемы вместе с бизнесом, и лидер, за которым бизнес следует. В яндекс-такси аналитики в позиции лидера. И они попробовали ее занять. А более адекватная позиция - партнер, так как коммерческий отдел до их прихода неплохо управлял ассортиментом, а значит у них тоже много знаний. И они пошли по партнерскому пути.
Как делать?
* Понять оргструтуру заказчика и процесс принятия решений
* Понять процессы, которые существуют
* Выделить ключевые боли бизнеса
* Совместно определить направления
* Начать внедрять аналитические продукты.
Первая задача - чистки ассортимента - выводить неэффективные товары. На входе коммерция вручную собирала каждую неделю файлики, потом считал. Они сделали автоматический сбор файла. Потом в файл интегрировали умные подсказки - что вывести. И в конце - добавили процесс, свели к еженедельному review на полчаса. Сейчас совершенствуют над ML-моделью. Но важно, что началось вообще не с аналитики, а просто с автоматизации сбора файлов, 3 дня превратились в 2 часа.
Всего у них сейчас три бока: выведение, заведение новых с прогнозом спроса, и оптимизация складов. И две особых категории: (1) овощи-фрукты-ягоды-грибы и (2) готовая еда. В них есть дерево принятия решений покупателем по выбору товара, и набор метрик по приоритизации. Например, яблоки: их можно выводить, только есть аналог и он не хуже, иначе они должны присутствовать как уникальный товар, без которого покупатель уйдет к другому.
= Михаил Лоренц из Инфосистемы Джет. ИТ-стратегия – фундамент устойчивого развития современного бизнеса =
Как известно, в условиях неопределенности и изменений ситуации оказывается востребованной разработка стратегии, она представляется волшебной палочкой, которая решит проблему: что делать и куда идти. В докладе был рассказ о том, как принято это делать. Необходимое предусловие - понятная стратегия бизнеса, потому как стратегия ИТ должна на нее опираться. Дальше делаем картину As Is, которая особенно полезна, если в руководстве ИТ поменялись люди и им надо понять, в какой ситуации они оказались. Потом - стратегическая сессию, на которой фиксируем сценарии и развилки.
А дальше создаем стратегию из четырех разделов:
# Зрелость ИТ-процессов, которую мы будем повышать
# Операционная модель, описывающая кадры и их оплату
# Развитие инфраструктуры - hardware
# Портфель проектов развития с диаграммой Ганта взаимных зависимостей
Если же стратегии бизнеса нет, то вместо стратегии ИТ предлагается делать план унификации и повышения надежности и доступности.
Я тут зафиксирую ряд важных моментов, которые опущены в докладе. Во-первых, откуда берется, идея целевых преобразований? Ее нельзя вывести из As Is и проблем. Часто она уже есть у заказчика, и он заказывает стратегию, чтобы ее обосновать. Это отчасти было в примерах: на стратегической сессии обсуждали варианты ЦОД, но идея, что ЦОД необходим была постулирована.
Во-вторых, по докладу есть впечатление, будто существует единственный способ создавать стратегию. Это не так, Минцберг в Стратегическом сафари выделяет 10 разных школ стратегирования, описанный процесс - это школа планирования. У бизнеса стратегия может быть разработана в рамках других школ, например, школы позиционирования, и не факт, что она будет сочетаться со стратегией школы планирования для ИТ. А если посмотреть на список Минцберга, о интересным может быть школа обучения - построение стратегии как развивающийся процесс:инкрементальные шаги, инициативы, ретро по результатам; школа внешней среды – построение стратегии как реактивный процесс и школа конфигурации – построение стратегии процесс трансформации. Кому интересно, полный список был в моем докладе на Подлодке https://mtsepkov.org/StratPodlodka и можно читать первоисточник - Минцберга. Ну и, в-третьих, насколько полезна стратегия, разработанная внешними консультантами - не слишком понятная штука. Кроме, конечно, ситуации, когда заказчик просто хочет получить обоснование для своих идей в корпоративной среде и разработка стратегии - инструмент получения этого обоснования.
= Ксения Мельник из NAUMEN. Роль аналитика в маркетинге B2B-продукта: оптимизация стратегий продвижения и привлечения клиентов =
Ксения работает во внутреннем стартапе, разрабатывает систему управления проектами. И это - продукт, который для компании является новым, и ориентирован на другую аудиторию потребителей, чем другие продукты. Поэтому ему необходимо отдельное продвижение, и маркетингом продукта занимается не отдел маркетинга, а сотрудники команды стартапа. Это логично: у компании много продуктов, и отдел маркетинга работает с имиджем компании в целом, и продвигает продукты пакетом, а тут аудитория и продукт сильно отличаются. А продвижение продукта - необходимо. Есть мнение у инженеров, что совершенный продукт сам себя продвинет, но оно - ложное. Каким бы ни был совершенный продукт, если он никому не известен, то его никто и не купит.
И был рассказ о шагах продвижения, но, к сожалению без конкретики по их продукту. В стиле: написано сделать раз, два, три - и мы это сделали. А интересны же детали. Потому как шаги раз-два-три и так можно прочитать в книге. Шаги следующие.
# Аналитика воронки - кто обращается а запросом на демонстрацию, чем обоснована потребность, как они решают проблему сейчас, какие причины отказов называют, что отличает компании, которые купили - надо организовать текущую информацию, чтобы были основания для анализа. Аналитика по отраслям - почему такие, и аналитика поражений - можно ли было избежать. Выявили топ-3 отрасли, и попробовали найти выходы на компании этих отраслей. И проанализировали причины поражений
# Уточнение профиля клиента. По результатам первого этапа. Фреймворк HADI: гипотеза, действия, данные, выводы. Кто: отрасль, специфика деятельности, проблема, текущее решение, ЛПР. Результат - ценность для каждого профиля клиента и план по взаимодействию.
# Карта сервиса. CJM наоборот, мы анализируем взаимодействие клиента с компанией и смотрим, где происходят провалы. И как можно устранить. Или материалы или доработка продукта. Результат - прозрачный и понятный процесс для вас и коллег.
# Подготовка материалов. SEO-статьи - оптимизация поиска, обновление лендинга - утонение ценности (и это не просто), обновление sales tool kit для команды продаж - скрипты, референсы - увеличение конверсии; структурное ведение базы знаний - регулярно сохранять информацию для аналитики поиске паттернов
# Работа со смежными командами. Не только рассказать, но и налаживать сотрудничество, регулярные встречи с разбором текущих активностей, и ежемесячный анализ воронки продаж - то доработать, и квартальный анализ показателей
= Андрей Москаленко. Применение аналитиком генеративных нейронных сетей в реверс-инжиниринге =
Я ожидал от доклада гораздо большего, конкретики по применению GPT либо в виде сложных задач, либо в виде рассказа про фактуру применения. А в нем сначала был рассказ со схемами про нейронные сети вообще стиле популярной книги для детей с красочными иллюстрациями, потом про известное использование GPT для перевода текстов, переноса таблиц ии спецификаций на yaml в markdown, и резюме по интересующим станадртам, например, по медицинскому оборудованию. При чем без подробностей, просто что "он это может". При чем не только переложить конкретную таблицу из Excel в маркдаун, но и написать скрипт на питоне, который это делает - решить задачу в общем виде. И дальше было про нетривиальную задачу - по плоскому списку конфигурации оборудования выделить типы этого оборудования. Но там тоже было без деталей: выдвигал гипотезы, GPT писал по гипотезам скрипты, я их применял и проверял гипотезы, получилось. Андрей - молодец, решил задачу. Правда, я не очень понял, зачем так там GPT. На мой взгляд, эта задача решается через то, что грузишь список в Excel и там вертишь, там всего 19к строк? и за день это делается, а с GPT потребовало 40 часов. Может, я недооцениваю - но тогда было интересно увидеть это в докладе...
= Артем Волчков. Применение модели Захмана для анализа корпоративной БА и жизненного цикла ИС при импортозамещении ПО =
Мне было интересно посмотреть, как применяют модель Захмана для реальных задач импортозамещения, какие это профиты это дает, кроме ссылки на то, что работаем не абы как, а по науке, обоснованными методами, в чем получается практический профит. К сожалению, это не получилось, доклад в формате: вот модель, мы ее применили к такому крутому проекту и к такому, и у нас получилось их успешно сделать. Механика конкретного применения и роль модели раскрыты, увы, не были. Жаль.
= Юлия Дробина из Nexign. Витрина API для Solution driven подхода в разработке =
У них 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. Подумать, почему сопоставление такое, почему какие-то типы при таком сопоставлении делятся, объединяются или отсутствуют и почему. Ответ, отчасти, в том, что общие типологии не учитывают место аналитика в разделении труда, они инвариантны к этому.
= Нелли Бовина. PBR как инструмент для эффективной работы аналитика и команды в целом =
Product Backlog Refinement - инструмент коллективного обсуждения задач при подготовке к включению в спринт. Идея состоит в том, что на отдельных встречах задачи представляются и обсуждаются командой, разработчики намечают способ реализации, тестировщики - способ тестирования, и задача оценивается. Такая встреча снижает неопределенность, позволяет на этапе разработки обойтись без уточнений и сделать то, что нужно. Они внедрили такой процесс, бэклог подготавливается на 2-3 спринта вперед. Внедрение - постепенное, сначала команда просто учится готовить задачи в формате заранее такого обсуждения, и уже потом учится оценивать. Профит - отсутствие необходимости уточнений и возвратов для изменения реализации, а также повышение точности планирования. Накладные расходы - часть подготовленных задач в низком приоритете в реализацию не идет, и время подготовки сгорает.
Эта конференция не типична тем, что продажи очного участия были закрыты за полнра месяца по переполнению площадки. И действительно, во многих залах на докладахз было очень плотно. При том, что программа конференции тогда еще не была сформирована, по значительной части докладов решенеи принималось позднее. Что говорит о хорошей репутации конференции. Надеюсь, организаторы учтут это и смогут найти более вместительную площадку.
На конференции было много качественных докладов. В их числе я хотел бы отметить доклады про мышление и различные модели социального устройства. Это .
Мой доклад [[Системное мышление и его место в работе аналитика (AnalystDays-2024a)|'''Системное мышление и его место в работе аналитика''']] тоже был посвящен мышлению. На прошлой AnalystDays я уже делал доклад [[Рациональное и системное мышление: практики и компетенции аналитика (AnalystDays-2023)|'''Рациональное и системное мышление: практики и компетенции аналитика''']], и в обсуждении от разных участников был тезис: Системное мышление - это круто, но зачем так сложно, есть же специализированные модели - Archimate, c4 model, BPMN и другие, почему их недостаточно?", и своим докладом я попробовал ответить на это возражение. Так что рассказ строился от практических задач, в которых использование специализированных моделей влечет проблемы, если у аналитика не хватает системного мышления для удержания сложных моделей. Основных проблемных места два: стык между бизнесом и софтом, и понимание конструкции бизнеса в целом, для которого распространенной процессной модели BPMN хватает далеко не всегда. За подробностями - смотрите доклад, конспекты собственных докладов я обычно не пишу.
Среди других докладов я хочу отметить доклад [[]]. Там основное - не техника использоания ИИ, а то, что аналитик, став продактом, начал делегировать аналитическую работу, на которую перестало хватать времени, не другим аналитикам, а ИИ. Так получалось проще и эффективнее. И это - качественный переход. Да, пока редкий, но получается, что делегирвоать ИИ простую работу уже легче, чем сотруднику.
В целом доклады конференции - хорошие и востребованные аудиторией. Среди участников конференции - большинство молодых, которые в профессии недавно и развиваются. Но, на правах опытного и давно участвующего, я отмечу следующую проблему в ряде докладов: докладчик не приземляет теоретическую модель на материал, не показывает особенности применения. А ведь это - самое важное. Моодель можно прочитать. Интересно - чем именно вам помогло ее применение, как был достигнут позитивный эффект, и какие были сложности. Ведь к моделям обращаются многие, а успешно воспользоваться получается далеко не у всех. Этот феномен известен как "ошибка выжившего": мы видим, чем пользовались в успешных проектах, пробуем - а оно не получается, потому что важно еще как именно этим пользовались. И хочется, чтобы доклад это раскрывал.
А еще доклады отражают общую проблему отрасли: отсутствие культуры знакомства с проработанными сложных теорий. Термин при этом могут знать, но понимать в бытовом смысле, например, системное мышление как синомним для мышления о чем-то сложном, без понмиания стоящих за ним принципов, методов и концепций. А в результате простые вещи превращаются в сложные изи запутанные, если говорить в терминах Кеневин-фреймворка. Вместе с тем, материалов по разным териям сейчас достаточно много и стоит их искать и знакомитсья, прокачивая свой метанавык быстрого освоения новых теорий. И это - не проблема конференции, тут доклады отражают ситуацию в отрасли в целом.
Ну а теперь - о докладах.
= Алексей Пименов. Социология на службе аналитика =
В докладе - социологическая модель племени. Есть такое направление современной социологии - корпоративная антропология, которое говорит, что "на самом деле" современный мир не слишком далеко ушли от племенных моделей, как они это представляют, и во многих компаниях проявляются те самые конструкты племенного поведения.
Когда эти модели полезны аналитику? Это взаимодействие с людьми: снимать потребности, их исследовать, взаимодействовать с новым коллективом. Понимание поведения социальных групп - ключ к эффективному общению. В докладе - адаптация и упрощение практик для простых нужд.
Племена. Атрибуты племенного поведения.
* У племени есть общий враг - не надо им становиться
* Члены племени наделены внутренним сходством
* У племени свои ритуалы и обряды - объекты ценности, их не надо нарушать и подрывать, вы станете врагом. Иногда надо сносить. но аккуратно
* Племя понимает источник успеха, не дает шатать
* Племени есть свой язык.
Для начала: Мы с тобой одной крови. Идентичность. Американский психопат - визитки, меряются друг с другом. Одинаковые очки и костюмы - но они видят разницу и могут понять иерархию. Человек - которого они не пускают. Слова, одежда, жесты, рестораны. Не приходить во фраке к неформалом и наоборот.
Концепция 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 - посмотрите от целей жизни. И решайте с учетом этого, а не только изнутри ситуации.
Концептуализация: все переводи в диаграммы.
mtsepkov, [25.05.24 22:10]
Задача - приоритизация архитектурного бэклога платформы относительно продуктовых. Что делаем: Накидываем элементы, затем кидаем связи: Компания - Клиент и цепочка продажи; Компания: продажа, разработка, поддержка; Этапы, стоимость, сроки; Клиент: продукт стоимость качество функции; поток ценности и стоимость владения; Первая сделка: маржа, конкурентное преимущество, стоимость владения, стоимость приобретения. Получаем блоки: компания, продукт, клиент, по каждому - пункты. И дальше оцениваем наши задачи по каждому разрезу, получая основания для приоритетов.
Знать свои цели и ценности. Цикл Колба - как обучаются взрослые. Опыт - Анализ - Теория - Практика. Мы не школьники, взрослым теорию не рассказывают. Хотя я бы тут отметил, что зря люди стараются учиться исключительно на своем опыте. полезно поискать подходящие теории и на них опереться.
Итого, рецепт: менять взгляд, изучать модели, осваивать сопутствующие типы мышления, все в диаграммы - концептуализация.
В ответах на вопросы.
* А если задача в хаосе - что сделать? Ответ. Посмотреть вокруг. Возможно, систему специально кто-то держит в хаосе. Насколько есть рычаги влияния и возможность выводить? Может, тут невозможно? Стоит ли терять время? Чему можно научиться в такой системе?
* А есть ли повышение сложности? Ответ - да. Есть методология и инструкции в компании, но их ставят под сомнение, отвергают - и сложность повышается.
* Позиция - субъективный подход к реальности, или есть объективная картина? Ответ - субъективно. Вы для джунов расписали - и им все ясно. А вы взаимодействуете с клиентом, неопределенность - там сложно. Или хаос.
* Вопрос. Если из запутанной попали в хаотичную? То как действовать, если сроки сжатые. Ответ - два варианта: (1) строгие правила от харизматичного руководителя, (2) долгий путь с обучением людей, очень сложно.
* Повышение уровня концептуального мышления - нельзя ставить такую задачу подчиненному. Потому что напрямую эффект не очевиден и желания тоже.
Почему мне интересны источники по концептуальному мышлению? Дело в том, что видно четкое ранжирование, в котором внизу - исполнение, а выше - решение творческих задач в условиях неопределенности - сильно выше. И это ранжирование совершенно не соответствует освоению разных типов мышления человеком. Ребенок замечательно умеет творчески решить задачу получения разрешения мамы посмотреть мультики, в том возрасте, когда выполнение инструкций совершенно недоступно. Потом, правда, школа успешно гробит способности к творческому мышлению, об этом свидетельствует зефирный эксперимент (ищем "Marshmallow Peter Skillman") и другие исследования. Так что основания для выделения именно таких уровней - интересно. У Спенсера этого нет. Ну и для идеи уложить все виды мышления в концептуальное с существенным их урезанием тоже интересны основания.
= Галина Ларина Райффайзенбанк. Неочевидные практики архитектора в арсенале аналитика =
За докладом стоит интересный кейс: система доставки продуктов банка. Исторически была собственная доставка и система вендора, которая ей управляла, потом начали использовать курьерские компании и сделали маршрутизатор. который запросы направлял в собственную систему или универсальный гейт для внешних компаний, при этом вендорская система собственной доставки - в процессе разработки собственной для замены. Каждой системой занималась отдельная команда в реактивном режиме, и внутри - все разнообразно. В этой ситуации бизнес решил объединить все команды в одну, в ответственность которой передать всю ИТ-поддержку доставки. И для начала команде надо было разобратсья в том зоопарке, в который им достался. Для этого она пошла в обучение solution architect, и использовала эти методы для проекта.
Цепочка методов интересная.
* Canvas Остервальдера для бизнеса (доставки)
* Goal view из Archimate для интересов стейкхолдеров
* Концептуальная диаграмма бизнес-объектов
* Event storming для понимания операционной работы бизнеса
К сожалению, рассказ о проблемах и методах был не на материале проекта, а в метафоре зоопарка. На мой взгляд, отсутствие фактуры сильно снижает качество доклада, было бы очень интересно узнать увидеть фактуру этих методов в реальном проекте. Но связку разных методов такой рассказ неплохо показывал. Event storming рассказывали совсем пунктиром, и там тоже интересная последовательность: события - пользователи и внешние системы - связь через команды - реакция на события: read model информации пользователю и правила с командами. В общем, рассказ - любопытный, и жаль, что приземления на реальный материал в нем не было.
= Ekaterina Goncharova. Что такое Custom GPTs и как их готовить =
На мой взгляд, самое интересное в докладе - ситуация: Екатерина из аналитиков стала продуктом, времени на аналитические задачи стало меньше, но вместо передачи их аналитикам она выделила рутинную часть, которую передала ChatGPT. B это в целом получилось. И это как раз те изменения, которые происходят, включение GPT в виде помощников вместо людей. А в целом в докладе была техника - как добавить к GPT дополнительную информацию, которую он учитывает в ответах. Это есть в платной версии, раздел ExporeGPT. Что туда стоит класть?
* Шаблон результатов ответа, с объяснением для каких сиутаций их применять, в разных файлах.
* Инструкции - то, что добавляешь в промпе, это процедура: описал бизнес - подумай про user story и далее.
* Информация о проекте или продукте
* Информация о предметной области. Включая книги, словари и так далее
= Рустам Иргалиев. Антихрупкость аналитиков. Менеджмент внутри команды =
Антихрупкость - способность выдерживать события и извлекать пользу. Хрупкость аналитика: одна область, инструменты, процесс, заказчик, постоянное окружение - и оно окостеневает в этих условиях, ломается, когда что-то меняется. Антихрупкость аналитика - способность действовать в разнообразных условиях, и это круто и дя него и для команды. Дальше были принципы, как к этому идти.
Децентрализация
* Несколько аналитиков на проекте
* Взаимное ревью аналитиками
* Делегирование
* Новые практики
Принцип опциональности. Возможность выбора, но без обязательности
* Аутсорс
* выбор инструментов и практик
* управление расписанием встреч
* выбор уровня детализации задач
* возможность аналитику подключить кого-то от команды
Естественный отбор - выживание приспособленного
* тимлид: матрицы компетенций, соревнование (быстрее согласовать задачу)
* аналитик: защита интересов (если хочешь поменять задачу), инициативность
Принцип штанги: ресурсы вкладываешь туда, где гарантированный результат. и только часть на риск
* Тимлид: перевести понятную работу на стажеров
* Проработка нескольких вариантов. Когда менялась архитектура - привлек внешнего архитектура для альтернатив
* аналитик - новые практики, plant uml вошел, проработка интересных требований заранее он отдыхал на ней, и вау что готово
= Ольга Павлова. Конфликты в команде между БА и разработкой: как реализовать проект и не подраться =
В докладе интересная форма: Ольга проводила опрос коллег, аналитиков и разработчиков, о причинах конфликтов и о способах их решения, и в докладе была кластеризация ответов. Поэтому он дает относительно репрезентативный срез мышления сотрудников, и проблем этого мышления. Дело в том, что основной претензией (около 50%) и для разработчиков и для аналитиков были проблемы с компетентностью другой стороны. А вот собственные ошибки аналитики относили за счет объективных обстоятельств: задача прилетела вчера, сделать надо срочно и так далее. И это - проявление основной ошибки атрибуции в части оценки негатива: ты приписываешь свои проблемы объективным обстоятельствам, а у других видишь причины в их негативных личных свойствах, в данном случае - некомпетентности. Логично было бы учесть эту проблему, когда обсуждали ситуацию и ее решения. Но в докладе этого не было. Хотя один из методов - позвать разработчика поиграть роль аналитика на встрече с заказчиком или хотя бы присутствовать на демо - как раз это решает. А вот все остальное, про поговорить и понять - он не совсем про это. Хотя, конечно, рациональный разговор без эмоций способствует тому, чтобы этой ошибки избежать. И отношение к конфликту как к точке роста, который происходит, когда ты ищешь конструктивное решение - тоже правильно.
= Иннокентий Бодров. Почему из аналитика плохой продакт? =
И что с этим можно сделать. Основное различие майндсета в том, что аналитик, как правило, пробует найти комплексное решение, которое покроет большинство случаев и устроит всех стейкхолдеров, и тратит на это много времени. А продукт - он выделяет основного стейкхолдера, на которого работает, а еще смотрит на скоуп с учетом рисков: что будет, если это не делать, и если риск невелик - то принимает решение не делать. А еще продукт - не просто арбитр желаний стейкхолдеров, у него - собственное видение развития продукта. Мышление рисками и собственное видение - изменение мышления. В докладе тезис разворачивался достаточно подробно, и это - необходимо, надо эту разницу майндсет поймать, но хорошо пересказать я не смогу, так как для меня тезис понятен.
Еще в докладе было показан легкий формат спеки в миро, который они используют. Спеки делает продукт, аналитиков нет, она верхнего уровня, и есть презентация команде, где проговариваются цели, опасные тест-кейсы, а разработка делает концепт реализации. На мой взгляд, это - отдельная ценная тема.
= Елена Михайлова. BPM vs API: перестать писать код и начать его рисовать =
Интересный доклад о том, как вместо алгоритмической реализации в коде, например, для расчета цены, делают реализацию в виде bmpn-схемы вызова методов, который обеспечивает нужную логику. Представление алгоритма получается наглядным и гибким, и в этом - профит.
= Роман Васильев, Яндекс Лавка. Data-Driven Retail: синергия бизнеса и Data Science для оптимизации процессов =
Интересный доклад, в фокусе которого форма сотрудничества data-аналитиков с бизнесом. У яндекс-лавки - задача управления ассортиментом и его хранением в дарк-сторе, откуда идет доставка продуктов, и которые имеют ограниченный объем хранения. И надо учитывать специфику спроса в районах, например, в центр и спальных районы спрос различается. Он пришел два года назад, с опытом аналитики в других компаниях - Мегафон, Магнит. И сделал ошибку в позиции: мы - аналитики, мы умеем считать и все сейчас посчитаем. Выяснилось, что параметров - много, критерии оцифрованы далеко не все, а главная проблема - результат не получается объяснить:"система посчитала". И у бизнеса теряется представление об управляемости.
Вообще аналитик может занимать одну из трех позиций: сервис, который просто выполняет задачи; партнер, который решает проблемы вместе с бизнесом, и лидер, за которым бизнес следует. В яндекс-такси аналитики в позиции лидера. И они попробовали ее занять. А более адекватная позиция - партнер, так как коммерческий отдел до их прихода неплохо управлял ассортиментом, а значит у них тоже много знаний. И они пошли по партнерскому пути.
Как делать?
* Понять оргструтуру заказчика и процесс принятия решений
* Понять процессы, которые существуют
* Выделить ключевые боли бизнеса
* Совместно определить направления
* Начать внедрять аналитические продукты.
Первая задача - чистки ассортимента - выводить неэффективные товары. На входе коммерция вручную собирала каждую неделю файлики, потом считал. Они сделали автоматический сбор файла. Потом в файл интегрировали умные подсказки - что вывести. И в конце - добавили процесс, свели к еженедельному review на полчаса. Сейчас совершенствуют над ML-моделью. Но важно, что началось вообще не с аналитики, а просто с автоматизации сбора файлов, 3 дня превратились в 2 часа.
Всего у них сейчас три бока: выведение, заведение новых с прогнозом спроса, и оптимизация складов. И две особых категории: (1) овощи-фрукты-ягоды-грибы и (2) готовая еда. В них есть дерево принятия решений покупателем по выбору товара, и набор метрик по приоритизации. Например, яблоки: их можно выводить, только есть аналог и он не хуже, иначе они должны присутствовать как уникальный товар, без которого покупатель уйдет к другому.
= Михаил Лоренц из Инфосистемы Джет. ИТ-стратегия – фундамент устойчивого развития современного бизнеса =
Как известно, в условиях неопределенности и изменений ситуации оказывается востребованной разработка стратегии, она представляется волшебной палочкой, которая решит проблему: что делать и куда идти. В докладе был рассказ о том, как принято это делать. Необходимое предусловие - понятная стратегия бизнеса, потому как стратегия ИТ должна на нее опираться. Дальше делаем картину As Is, которая особенно полезна, если в руководстве ИТ поменялись люди и им надо понять, в какой ситуации они оказались. Потом - стратегическая сессию, на которой фиксируем сценарии и развилки.
А дальше создаем стратегию из четырех разделов:
# Зрелость ИТ-процессов, которую мы будем повышать
# Операционная модель, описывающая кадры и их оплату
# Развитие инфраструктуры - hardware
# Портфель проектов развития с диаграммой Ганта взаимных зависимостей
Если же стратегии бизнеса нет, то вместо стратегии ИТ предлагается делать план унификации и повышения надежности и доступности.
Я тут зафиксирую ряд важных моментов, которые опущены в докладе. Во-первых, откуда берется, идея целевых преобразований? Ее нельзя вывести из As Is и проблем. Часто она уже есть у заказчика, и он заказывает стратегию, чтобы ее обосновать. Это отчасти было в примерах: на стратегической сессии обсуждали варианты ЦОД, но идея, что ЦОД необходим была постулирована.
Во-вторых, по докладу есть впечатление, будто существует единственный способ создавать стратегию. Это не так, Минцберг в Стратегическом сафари выделяет 10 разных школ стратегирования, описанный процесс - это школа планирования. У бизнеса стратегия может быть разработана в рамках других школ, например, школы позиционирования, и не факт, что она будет сочетаться со стратегией школы планирования для ИТ. А если посмотреть на список Минцберга, о интересным может быть школа обучения - построение стратегии как развивающийся процесс:инкрементальные шаги, инициативы, ретро по результатам; школа внешней среды – построение стратегии как реактивный процесс и школа конфигурации – построение стратегии процесс трансформации. Кому интересно, полный список был в моем докладе на Подлодке https://mtsepkov.org/StratPodlodka и можно читать первоисточник - Минцберга. Ну и, в-третьих, насколько полезна стратегия, разработанная внешними консультантами - не слишком понятная штука. Кроме, конечно, ситуации, когда заказчик просто хочет получить обоснование для своих идей в корпоративной среде и разработка стратегии - инструмент получения этого обоснования.
= Ксения Мельник из NAUMEN. Роль аналитика в маркетинге B2B-продукта: оптимизация стратегий продвижения и привлечения клиентов =
Ксения работает во внутреннем стартапе, разрабатывает систему управления проектами. И это - продукт, который для компании является новым, и ориентирован на другую аудиторию потребителей, чем другие продукты. Поэтому ему необходимо отдельное продвижение, и маркетингом продукта занимается не отдел маркетинга, а сотрудники команды стартапа. Это логично: у компании много продуктов, и отдел маркетинга работает с имиджем компании в целом, и продвигает продукты пакетом, а тут аудитория и продукт сильно отличаются. А продвижение продукта - необходимо. Есть мнение у инженеров, что совершенный продукт сам себя продвинет, но оно - ложное. Каким бы ни был совершенный продукт, если он никому не известен, то его никто и не купит.
И был рассказ о шагах продвижения, но, к сожалению без конкретики по их продукту. В стиле: написано сделать раз, два, три - и мы это сделали. А интересны же детали. Потому как шаги раз-два-три и так можно прочитать в книге. Шаги следующие.
# Аналитика воронки - кто обращается а запросом на демонстрацию, чем обоснована потребность, как они решают проблему сейчас, какие причины отказов называют, что отличает компании, которые купили - надо организовать текущую информацию, чтобы были основания для анализа. Аналитика по отраслям - почему такие, и аналитика поражений - можно ли было избежать. Выявили топ-3 отрасли, и попробовали найти выходы на компании этих отраслей. И проанализировали причины поражений
# Уточнение профиля клиента. По результатам первого этапа. Фреймворк HADI: гипотеза, действия, данные, выводы. Кто: отрасль, специфика деятельности, проблема, текущее решение, ЛПР. Результат - ценность для каждого профиля клиента и план по взаимодействию.
# Карта сервиса. CJM наоборот, мы анализируем взаимодействие клиента с компанией и смотрим, где происходят провалы. И как можно устранить. Или материалы или доработка продукта. Результат - прозрачный и понятный процесс для вас и коллег.
# Подготовка материалов. SEO-статьи - оптимизация поиска, обновление лендинга - утонение ценности (и это не просто), обновление sales tool kit для команды продаж - скрипты, референсы - увеличение конверсии; структурное ведение базы знаний - регулярно сохранять информацию для аналитики поиске паттернов
# Работа со смежными командами. Не только рассказать, но и налаживать сотрудничество, регулярные встречи с разбором текущих активностей, и ежемесячный анализ воронки продаж - то доработать, и квартальный анализ показателей
= Андрей Москаленко. Применение аналитиком генеративных нейронных сетей в реверс-инжиниринге =
Я ожидал от доклада гораздо большего, конкретики по применению GPT либо в виде сложных задач, либо в виде рассказа про фактуру применения. А в нем сначала был рассказ со схемами про нейронные сети вообще стиле популярной книги для детей с красочными иллюстрациями, потом про известное использование GPT для перевода текстов, переноса таблиц ии спецификаций на yaml в markdown, и резюме по интересующим станадртам, например, по медицинскому оборудованию. При чем без подробностей, просто что "он это может". При чем не только переложить конкретную таблицу из Excel в маркдаун, но и написать скрипт на питоне, который это делает - решить задачу в общем виде. И дальше было про нетривиальную задачу - по плоскому списку конфигурации оборудования выделить типы этого оборудования. Но там тоже было без деталей: выдвигал гипотезы, GPT писал по гипотезам скрипты, я их применял и проверял гипотезы, получилось. Андрей - молодец, решил задачу. Правда, я не очень понял, зачем так там GPT. На мой взгляд, эта задача решается через то, что грузишь список в Excel и там вертишь, там всего 19к строк? и за день это делается, а с GPT потребовало 40 часов. Может, я недооцениваю - но тогда было интересно увидеть это в докладе...
= Артем Волчков. Применение модели Захмана для анализа корпоративной БА и жизненного цикла ИС при импортозамещении ПО =
Мне было интересно посмотреть, как применяют модель Захмана для реальных задач импортозамещения, какие это профиты это дает, кроме ссылки на то, что работаем не абы как, а по науке, обоснованными методами, в чем получается практический профит. К сожалению, это не получилось, доклад в формате: вот модель, мы ее применили к такому крутому проекту и к такому, и у нас получилось их успешно сделать. Механика конкретного применения и роль модели раскрыты, увы, не были. Жаль.
= Юлия Дробина из Nexign. Витрина API для Solution driven подхода в разработке =
У них 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. Подумать, почему сопоставление такое, почему какие-то типы при таком сопоставлении делятся, объединяются или отсутствуют и почему. Ответ, отчасти, в том, что общие типологии не учитывают место аналитика в разделении труда, они инвариантны к этому.
= Нелли Бовина. PBR как инструмент для эффективной работы аналитика и команды в целом =
Product Backlog Refinement - инструмент коллективного обсуждения задач при подготовке к включению в спринт. Идея состоит в том, что на отдельных встречах задачи представляются и обсуждаются командой, разработчики намечают способ реализации, тестировщики - способ тестирования, и задача оценивается. Такая встреча снижает неопределенность, позволяет на этапе разработки обойтись без уточнений и сделать то, что нужно. Они внедрили такой процесс, бэклог подготавливается на 2-3 спринта вперед. Внедрение - постепенное, сначала команда просто учится готовить задачи в формате заранее такого обсуждения, и уже потом учится оценивать. Профит - отсутствие необходимости уточнений и возвратов для изменения реализации, а также повышение точности планирования. Накладные расходы - часть подготовленных задач в низком приоритете в реализацию не идет, и время подготовки сгорает.