На докладе расскажу, как выстраивали порядок и коммуникации при изменениях в общей инфраструктуре. 

Инфраструктура - как выглядит у нас и в чем сложность взаимодействия между командами:

1. Аналитическая инфраструктура состоит из запутанных связей и зависимостей - сервера связаны с серверами, базы с базами, команды с командами. Изменения в одном узле может повлечь изменения в другом.

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

3. Ошибки при взаимодействии. С чем столкнулись и как пришли к чек-листу.

4. Инструмент или панацея? Что изменилось с введением чек-листа, ограничились только им и нужны ли еще какие-то изменения.

5. Выводы и рекомендации, опыт команды.

Продолжительность ~40 минут.

Что такое DWH? Почему бы нам не использовать привычные базы данных? Есть ли между ними отличия?

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

В ходе доклада мы разберем особенности DWH, выясним, что же это за зверь.

Помимо общего знакомства с концепцией DWH, фокус доклада сосредоточен на том, что же конкретно делает аналитик на проекте DWH? Сложно это или просто? Какими компетенциями должен обладать такой аналитик и какие прикладные задачи он решает? 

Целевая аудитория - системные аналитики, заинтересованные в работе с хранилищами данных, системные архитекторы. Уровень аналитиков любой, опыт работы с хранилищами данных не требуется.

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

• По дереву виден весь объём данных: маленький кустик или большое дерево.
• Можно делать многомерный анализ: по поставщикам, по предмету закупки, по суммам и другие разрезы данных, а также перейти к конкретному контракту.
• Можно наложить риск-мониторинг: слой показывает признаки нарушений и их интенсивность — от небольшого количества (жёлтый) до критически большого (тёмно-красный).
• Можно управлять рисками и тушить пожар с помощью проверок: по дереву видно, какая зона требует особого внимания и менять вектор — ставить более корректные задачи исполнителю.

Про проектирование, моделирование ИС написано большое количество книг и статей, сделано значительное количество интересных докладов. Но несмотря на весь это без сомнения полезный труд, что многие из нас видят в проектах, продуктах или любом другом процессе или подходе, направленном на создание ИС, программные продуктов, сервисов и т.п.?
"Пилите таски из jira!". Вот и вся работа. А результаты проектирования пыляться и скучают где-то в килотоннах документации (если она есть), или находятся в голове 5% старожилов команды и строго хранятся этим орденом. Конечно, это скорее преувеличение, но тем не менее зачастую моделирование и проектироание или не включено в поток, или в ключено, но очень слабо.

В докладе будут затронуты возможные причины такого состояния, предложены варианты выхода из ситуации в конкретных сценариях.

Я расскажу про базовые принципы описания интеграционных интерфейсов, соблюдение которых является залогом быстрой и качественной интеграции. За 20 лет работы я выработала такие базовые принципы интеграций: 

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

- соблюдать договоренности внутри команды / внутри проекта,

- учитывать справочные значения в интеграционных интерфейсах.

Кроме этого есть еще ряд нюансов, которые тоже следует учитывать в работе интеграционного аналитика:

- работу с пустыми и отсутствующими значениями,

- работу со всевозможными маппингами (преобразованиями) между разными интеграционными слоями,

- обработку ошибок на всех ветках алгоритма,

- сокращение Http Status Code = 500.

Если следовать этим принципам и учитывать нюансы, то "блох" интеграции, выявленных при тестировании и при выходе в ПРОД, будет в разы меньше.

В рамках бизнес-игры участники:

1. Составят опросник для сбора требований.
2. Посмотрят на вопросы глазами заказчика.
3. Обработают результаты обследования и сформулируют концепцию предлагаемого решения.

По итогам мы обсудим:

1. Как различные модели поведения представителей заказчика и аналитика влияют на результат обследования.
2. Как выявлять вопросы, на которые аналитик получает «не те» ответы.
3. Как самому проверить полноту и корректность вопросов к заказчику.
4. Типовые ошибки, которые приводят к неправильному пониманию вопросов и получению "не тех" ответов. 
5. Рекомендации по минимизации риска ошибок при сборе требований.

Участники будут работать в командах по 5-6 человек. Каждый участник сможет последовательно поставить себя на место аналитика, заказчика, а затем снова аналитика, примерив при этом разные ролевые модели поведения.

Бизнес-игра состоит из следующих блоков:

1. Вводная часть. Вы узнаете правила игры и разобьетесь на команды.
2. Сбор требований. Каждая команда пройдет полный цикл работ от разработки опросника до формализации концепции предлагаемого решения проблемы заказчика.
3. Подготовка рекомендаций, которые помогут на этапе составления опросника подстраховаться от риска искажения информации. Обсуждение типовых ошибок аналитика при сборе требований.
4. Обратная связь от ведущих игры.

Ведущие бизнес-игры:

Букреева Наталья, ведущий аналитик Croc Code
Астанина Светлана, ведущий аналитик Croc Code
Подклетнев Евгений, старший системный аналитик Croc Code 

Продолжительность бизнес-игры: 2 часа

При составлении бэклога или списка требований часто возникает проблема трассировки задач бизнеса на конкретные фичи продукта. Не всегда из набора фичей складывается ясная картина влияния продукта на целевые метрики бизнеса.

Impact Mapping — это мощная техника выстраивания соответствия целей и конкретных решений. Она позволяет быстро выявить полезную функциональность (и избавиться от бесполезной), приоритезировать состав функций продукта и сфокусироваться на решении задач бизнеса, а не запиливании фич.

Кроме того, техника дает каркас для выработки решений, не связанных с изменением продукта, а лежащих в области изменения процессов и маркетинга.

На мастер-классе участники самостоятельно попробуют применить Impact mapping на учебной задаче, получат фидбэк и разбор всех нюансов построения карт влияния.

Длительность мастер-класса - 2 часа.

Системный аналитик производит тексты. В истории ИТ постоянно появляются попытки перевести все артефакты в форму диаграмм, но даже в диаграммах есть слова и подписи. Да и не всегда удобны диаграммы оказываются и для разработчиков и для согласующих. В общем, аналитик производит тексты - описания процессов, требования, технические задания. И это тексты на естественном языке. А естественный язык - это не формальная система. В словах куча неоднозначностей, умолчаний, двусмысленностей, недоговоренности, подразумеваемых значений... И если такие слова просачиваются в тексты требований - жди беды. В докладе я расскажу про требования к текстам требований (и даже приведу выдержки из соответствующих стандартов) и дам список "стоп-слов" - таких слов и выражений, при встрече которых в документе или на диаграмме у аналитика должна мысленно "загораться красная лампочка" и включаться сигнал тревоги. Очистим тексты аналитиков от двусмысленностей и неоднозначностей! Доведем тексты требований до совершенства!

В IT есть два типа людей: те, кто пропагандирует использование REST API, и те, кто его не ненавидит. Мы встанем на третью сторону и посмотрим, какие границы применимости имеет эта концепция при проектировании API.

На воркшопе спроектируем HTTP API в рамках REST парадигмы и обсудим сложности, которые возникнут в процессе. После рассмотрим менее очевидные проблемы при использовании REST API.

Будет полезен для специалистов, имеющих опыт проектирования реальных или учебных REST API.

Длительность: 90 минут

Краткое описание: Рассказ о том, как принимать и понимать бизнес сферы FMCG. Чем отличаются, например Coca-Cola от Мираторга, кроме сегмента и производимых продуктов.

Тезисы:

Суть бизнеса – Рассказ о том, что такое FMCG, каковы его реалии в нынешней ситуации и суть концепции «от поля до прилавка».

«Краткий разговорник» - небольшой сборник «фраз ловушек», которые следует понимать не так, как они слышатся и читаются.

Как уметь «продать» свою концепцию – экскурс в процесс того, как бороться с фразами типа: «Мы тут производим и продаём, а не ИТ компанию строим»?