2024-05-30: AnalystDays в Питере - хорошие доклады и много общения

Короткая ссылка: AnalystDays-2024a

Ссылки сюда (4) →

О других конференциях

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

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

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

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

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

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

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

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

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

Алексей Пименов. Социология на службе аналитика

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дмитрий Безуглый. Эволюция организационного интеллекта и роль системного аналитика

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

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

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

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

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

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

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

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

Наталья Семенова. Концептуальное мышление: зачем оно вам, есть ли оно у вас, и как его развить

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

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

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

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

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

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

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

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

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

• дивергентное мышление — способность видеть спектр решений
• альтернативное мышление — работать с разными мнениями на один вопрос, без выбора
• латеральное мышление — возможность мыслить не стандартно, как никто не подумал

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

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

Меняем точку зрения:

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

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

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

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

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

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

В ответах на вопросы.

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

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

Галина Ларина Райффайзенбанк. Неочевидные практики архитектора в арсенале аналитика

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

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

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

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

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, которая особенно полезна, если в руководстве ИТ поменялись люди и им надо понять, в какой ситуации они оказались. Потом — стратегическая сессию, на которой фиксируем сценарии и развилки.

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

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

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

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

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

Ксения Мельник из NAUMEN. Роль аналитика в маркетинге B2B-продукта: оптимизация стратегий продвижения и привлечения клиентов

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

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

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

Андрей Москаленко. Применение аналитиком генеративных нейронных сетей в реверс-инжиниринге

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

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

— Максим Цепков • 14:32, 30 мая 2024 • нет комментариев