Я расскажу про эволюцию методов прогнозирования (сценарии, форсайт, имитационное моделирование), поговорим о сейчас и о будущем. Также я затрону тему инструментов аналитика в свете быстро наступающего будущего.

За 5 лет изучения, внедрения и практики Behaviour-Driven Development со множеством команд во множестве различных организаций мне удалось сформулировать модель зрелости этого процесса, которую я готов презентовать на одной из стен Летнего Аналитического Фестиваля в виде визуальной метафоры, базирующейся на бессмертном произведении Данте Алигьери.

При этом ключевой акцент, безусловно, будет сделан на том, как аналитику живётся на каждом из уровней этой модели и как аналитик может способствовать продвижению команды к более высоким уровням BDD-зрелости.

Это игра-симуляция, позволяющая испытать на себе процесс Behaviour-Driven Development и научиться использовать язык Gherkin для спецификации целевого поведения своих программных продуктов. В основе симуляции лежит фабула фантастического фильма «День независимости» и элементы одной из самых сложных и интересных командных настольных игр «Космическая тревога» (Space Alert).

UPD 23/06 Моя обычная роль бизнес архитектор. Примерно 20 лет я занимаюсь проектами изменений в разных ракурсах. В последнем проекте с телеком компанией на 6000+ человек пришлось разбираться со стандартами CMMI5 - таков был изначальный запрос. Расскажу про проект и про проблемы больших ИТ компаний. Самая большая проблема не только понять что не так, но ещё и объяснить это тем кто не смог увидеть самостоятельно. Это 2 разные задачи. Например как можно показать наглядно, что задачи из тестирования захлестывают задачи которые еще только начали делать? 
На мастер-классе я покажу основню задачу архиетектора: как сконструировать модель объекта. 
Представьте себе настольную игру в которой вы видите основные процессы. Только в этом случае вам нужно сделать игру такой чтобы эти процессы были основными, а не играть в готовую. 
Это задумка. Если будут желающие поконструировать тогда двинемся в эту сторону. Есть парочка готовых игр, на которых можно понять как все работает и научиться ловить "паттерны" больших и сложных процессов. Это вариант если конструкторов не будет а будут желающие играть. В резерве простой формат - рассказать что было где ограничения. И где надо быть аналитикам если про это знать. 
Есть еще один прикладной интерес. Сейчас много говорят про криптовалюты. Как сделать так чтобы ваша идея росла и новые люди только усиливали вашу экосистему? Как сделать так чтобы эффективность возрастала, а не падала? Это любимый вопрос "эффективность технологий упралвения" который рассматривают в больших и "гибких" организациях типа Сбера.
Вот такие темы для мастер-класса.  

Здесь на что похожа игра https://goo.gl/4HHecm
Здесь облако проблем солюшен архитектора https://goo.gl/iXmH72

Ниже первый анонс мастер-класса
----------------------------
Я хочу дать такую точку зрения где все проекты измеряются в отношениях между людьми и в том времени которое они тратят на свою деятельность. Нужно будет спларировать рост компании из 5 вицепрезидентов до 10 тысяч человек. И по пути обнаружить какие были ограничения. Где начальникам не хватило времени для обучения, где времени чтобы выдать зарплату. Полная симуляция только без компьютера - в уме. Нужны люди с хорошим воображением. Или беспримерной наглостью :) мысли.

1 год = 5 минут игрового времени. 5 минут обсуждение внутри команды и отчет в виде люди бюджет % выпролнения и др. показатели максимум 10-20 штук. В конце каждого периода мы меяемся показателями. Задаем вопросы каждой команде.

Длительность 1,5 часа.

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

• Что не так с управлением в обеих этих ситуациях.

• Что такое недирективное управление.

• Когда эффективно использовать недирективный подход.

• Какие навыки и инструменты нужны.

• Как эти же навыки применять в других сферах: наставничестве, работе с заказчиком, да и просто в повседневном общении.

Доклад рассчитан на слушателей c любым опытом и ролью, но наиболее полезен может быть тим-лидам, руководителям отделов аналитики, руководителям проектов.

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

Я хочу рассказать о сотрудниках, выполняющих роль аналитика в моих проектах. Формат мероприятия выбрала предварительно, моя тема может лучше в обсуждении (круглом столе или мастер-классе). 

1. Кто может играть роль аналитика?

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

2. Как играют роль аналитика другие?

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

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

3. Зачем это аналитикам?

Посмотреть, как работают другие и узнать себя в деталях. Что можно взять полезного из направлений, а где сильнее именно аналитик.

4. Почему я об этом говорю?

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

Анализируя отклики зрителей на вебинар «Одиннадцать простых фишек BPMN-моделирования» (2015), вопросы, звучащие в ходе тренингов, и личный проектный опыт, нам удалось идентифицировать, описать и систематизировать джентельменский набор шаблонов (паттернов) моделирования на языке BPMN 2. Актуальность запроса практикующих аналитиков на каталог шаблонов обусловлена отсутствием в русскоязычном сегменте Сети какой бы то ни было эталонной библиотеки типовых «строительных блоков», аналогичной каталогам GoF, GRASP или PoEAA для программной архитектуры; немногочисленные же попытки создания аналогичного каталога англоязычными специалистами малоизвестны и подчас содержат откровенно спорные результаты.

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

Каждый шаблон, сборник которых мы хотели бы вынести на суд участников ЛАФ, будет проиллюстрирован фрагментом BPMN-модели, а также нашим видением его ограничений и преимуществ. По окончании мастер-класса (1,5 часа) возможно продолжение обсуждения материала в формате barcamp’а.

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

Присущая таким работам исходная неопределенность порядка, трудоемкости и себестоимости их производства лишает аналитика возможности рассматривать сами работы как бизнес-процесс с присущим последнему детерминированным характером цепочки операций или задач. Единственным нормативным способом формального описания подобных случаев до последнего времени, пожалуй, оставались спонтанные (ситуативные, ad hoc) процессы BPMN.

Решительным образом ситуация изменилась в мае 2014 года, когда консорциум OMG предложил спецификацию языка CMMN 1.0 (с декабря 2016 года — CMMN 1.1). Само название стандарта — Case Management Model and Notation — указывает на его родство с широко известными формальными языками описания бизнес-процессов, решений и бизнес-правил (BPMN и DMN, соответственно), а равно с подходом к гибкому управлению деятельностью предприятий, известным как адаптивный (динамический) кейс-менеджмент (Adaptive / Dynamic Case Management, ACM).

Предлагаемый участникам фестиваля мастер-класс (2,5 часа) позволит на практике освоить азы языка CMMN 1.1, узнать о ключевых принципах «коллаборативного» процессного управления с учетом социальной среды, попробовать себя в решении простых задач… и просто получить удовольствие!