Расскажу о сообществе аналитиков Санкт-Петербурга:

•  принципы и ценности
•  как оно возникло,
•  как развивалось,
• наши достижения,
•  как сейчас работает:
  • процессы и взаимодействия
  • люди.

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

На этот вопрос и попробуем найти ответ.

Доклад посвящен подходу к обеспечению достоверности финансовой информации в организации. В докладе будут рассмотрены:

• признаки недостоверности финансовой информации;
• способ верификации финансовой информации;
• устройство процесса достоверного информирования;
• подход к построению такого процесса.

Оформление проектного опыта, знаний и результатов работы сотрудников - основа базы знаний (далее - БЗ) для компании. Её использование снижает риски и экономит ресурсы. Доклад посвящен опыту аналитиков нашей компании в формировании БЗ.

В первой части доклада расскажу о нашем хранилище проектной документации на основе платформы MS SharePoint и DocTrix. Оно содержит проектную документацию, разработанную аналитиками, и наполняется при завершении проекта. Наш подход полезен тем, что мы организовали удобный поиск документов за счет их категоризации по типам, доменам, модулям информационных систем.

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

ПО постоянно изменяется. Выходят минорные обновления, патчи, баг-фиксы, крупные обновления, новые версии и релизы. Разработчикам хочется похвастаться тем, что они сделали, а пользователям прочитать о том, что же изменилось в продукте.

Мы начали писать release notes (заметки к релизу с описанием изменений) для своего продукта 5 лет назад. И были горды собой — выносили в relese notes только главные задачи, указывали их номер в JIRA вместе со ссылкой, писали подробную инструкцию, как перейти на новый релиз.

Но потом мы заметили, что заказчики не используют новые возможности. Стали выяснить, почему? Оказалось — они про них не знают! Мы расстроились, задумались, а потом переработали формат описания изменений с нуля. И это сработало!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Присущая таким работам исходная неопределенность порядка, трудоемкости и себестоимости их производства лишает аналитика возможности рассматривать сами работы как бизнес-процесс с присущим последнему детерминированным характером цепочки операций или задач. Единственным нормативным способом формального описания подобных случаев до последнего времени, пожалуй, оставались спонтанные (ситуативные, 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, узнать о ключевых принципах «коллаборативного» процессного управления с учетом социальной среды, попробовать себя в решении простых задач… и просто получить удовольствие!

Знания, изложенные в докладе, применялись на практике при работе над ИТ

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

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

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

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

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

В своем докладе раскрою следующие аспекты, которые повлияли на выбор формата интерпретации требований

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

В битве сойдутся три участника, вооружённые разными инструментами моделирования: VISIC, UML и Archimate. Каждый представит возможности своего инструмента, нарисовав с его помощью определённую модель, и бросит вызов соперникам, предложив им повторить этот подвиг с использованием их оружия.