Это воркшоп на 2.5-3 часа. Раз на прошлом ЛАФе он выиграл приз зрительских симпатий, то почему бы его и не повторить (:

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

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

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

В докладе будут раскрыты следующие темы:

1. Отличие кровавого моря от голубого океана

2. Метод разработки стратегии голубого океана

3. Методы выхода за привычные границы рынка

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

Поговорим о том, как можно помочь команде выявить ошибки, до того как она их совершит. (Доклад/ Мастер-класс)

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

Как Вы расчитываете трудозатраты? Как определяете сроки выполнения? Есть ли методики расчета или используете экспертные оценки? Какова необходимая точность расчетов? Что делаете, если работы растягиваются, сроки нарушаются, возникают дополнительные работы?

Почему аналитики не любят оценку трудозатрат? Почему не любим указать сроки? Можно ли превратить оценку трудозатрат и сроков из дамоклова меча в помощника?

Рассмотрим наиболее распространенные методики оценки трудозатрат. И поделюсь успешным опытом (около 10 лет) планирования работ аналитиков. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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