DDD — это стильно, модно, уже не очень «молодежно»,но до сих пор нечасто применимо! Словарь — это понятно, неинтересно, «покрыто пылью»,
но привычно и является стандартом на начальных этапах проектирования.

Я хочу предложить вам найти связь между словарем и DDD. На примерах понять, как словарь может стать отправной точкой DDD и как, описывая бизнес-контекст, оказывать влияние на архитектуру и выстраивать разумную коллаборацию, основанную на симбиотических связях между бизнесом и разработкой.

Что по итогу:

• Основы DDD – общая теория. Язык и словарь – как основа DDD и выстраивания разумной коллаборации между бизнесом и разработкой
  
• Поделюсь методикой эволюционного, а не революционного внедрения DDD, вместе с новыми проектами в компании (методика апробирована и дает хорошие результаты)
  
• Разберем правила формулирования определений, и поймем, как через определения строить архитектуру
  
• Тренировочная часть формулирования определений и их влияния на архитектуру.
  
• Помогу найти свой стиль «словоплетства» и дам обратную связь.
• Разберем процесс внедрения такого подхода в компании, работу с возражениями

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

На МК рассмотрим:

− причины порождения «мира артефактов», обсудим, как не стать «артефактором»;
− проблемы интеграционных проектов, и что это за роль «интеграционный менеджер»;
− четыре экзистенциальных вопроса проектирования;
− разберем какие «вижины» проектирования существуют и их взаимосвязь;
− поймем, почему метрики – не «хайп», а индустриальный стандарт.

База повествования охватывает опыт и продуктовой разработки, и «кровавый энтерпрайз».

Что по итогу:

• Поймем разницу между открытыми и закрытыми вопросами, попрактикуемся в использовании открытых вопросов.
  
  
• Разберем проблемы, которые порождают артефакты, чтобы понять, что не стоит приносить в процесс проектирования.
  
  
• Узнаем почему DDD – может помочь проложить дорогу к проектированию от ценностей, что такое эти ценности, как их создавать, сохранять и развивать.
  
  
• Разберем виды «вижинов», взаимосвязи между ними.
  
  
• Потренируемся использовать «вижины» в различных ситуациях, а заодно вспомним что такое риск—менеджмент и инцидент-менеджмент.
  
  
• Разберем кейсы интеграционных проектов, потренируемся использовать подход «вижинов» и базировать решения на метриках, а не предположениях.
  
  
• Участники получат шаблоны некоторых артефактов.
  
  
• Участники увидят насколько близки в проектировании бизнес и разработка
  
  

МК – это комбинация теории и практики рисков и работы с ними, в том числе практика обнаружения «проблем» и выстраивания процесса коммуникации между бизнесом и разработкой. Рассмотрим какие практики менеджмента для работы с рисками нужны и как их применять, чтобы строительство коллаборации, закончилось успехом.

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

Что по итогу:

• Познакомимся с теорией риск-менеджмента, узнаем какие бывают риски, а главное – почему необходимо уметь работать не только с «негативными» рисками, но и с «позитивными».
  
  
• Узнаем, как определить возможно ли внедрять риск-менеджмент в вашей работе и на каком уровне. Поймем причем тут коллаборация.
  
  
• Составим описание риска необходимое и достаточное, чтобы работать с риском.
  
  
• Определим сильные и слабые стороны работы с рисками с использованием ROAMboard и MindMap.
  
  
• На практике проверим выявим основные правила работы с рисками и зафиксируем их
  
  
• Команды разберутся насколько риски разных подразделений зависимы друг от друга
  
  
• Участники учатся мыслить категориями общих рисков и общих результатов
  
  

Мы привыкли жить в делении на системных и бизнес-аналитиков. Иногда аналитик не может усидеть спокойно "на стуле" и тогда его называют - "гибридом". Еще лет 15 назад любой аналитик свободно чувствовал себя на уровне модели базы данных, потом как-то все разделились на бизнесовых и системных. И не последнюю роль в этом сыграл "бардак" на уровне кода. IT набирало обороты, увидев "новую игрушку" в нее надо было "наиграться". Вместо монотеизма в архитектуре, было модно возводить пантеон культур, оправдывая его фразой про "здравый смысл".

Я не берусь открыть "новый свет" или подарить миру "новую религию", я хочу познакомить аудиторию с моим подходом к проведению анализа задачи, который строится на симбиозе продуктовой и IT стратегий; функциональном и архитектурном подходах.

Что по итогу:

• Пошаговый алгоритм и особенности его применения при проведении анализа на сложных проектах.
  
  
• Чек-лист и список вопросов/заметок для проведения анализа.
  
  
• Выжимка теории о дизайн-мышлении и применение нескольких практик на учебных кейсах.
  
  
• Изученный материал и практики позволят шире смотреть на задачу и прорабатывать ее на фундаментальном уровне, учитывая требования всех заинтересантов.
  
  
• Увеличивается вариативность решений
  
  
• Сокращается количество костыльных решений
  
  

О ценностях привычно слышать от CEO или эйчаров, но в инженерной команде отношение к самой этой теме — нейтрально-скептическое

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

Мы поговорим о прикладной стороне ценностей. Почему без общих ценностей у вас будут проблемы с архитектурой. Как продуктовый подход помогает в работе с ценностями. И как работать с ценностями без нудного морализаторства и гуманитарного шаманства.

А главное мы разберем, как выстраивать процессы, в инженерных командах "не по книгам", а согласно смыслу, который вы в них вкладываете и результату, который вы хотите получить. Рассмотрим примеры организации практик и вспомним о базовом их назначении.

Что по итогу:

• Вернем процессам исходную ценность, пересоберем практики с максимальной выгодой для компании и команд.
  
  
• Шаблоны артефактов и инструкции к ним.
  
  
• Лайф-хаки продажи практик заинтересованным сторонам: бизнесу и разработке. Работа с возражениями.
  
  
• Практические советы, как трансформировать имеющееся или создать недостающий минимум, чтобы оптимизировать работу.
  
  
• Рост вариативности практик, нахождение подходящей именно вам, так как понимая смысл и ценность, можно вместо "следования методички" строить оптимальные для вас процессы.
  
  
• Выстраивание коллаборации между бизнесом и разработкой опираясь на DevOps философию.