Гибкие подходы давно и плотно вошли в жизнь как продуктовой, так и заказной разработки. 
И так как каждая компания или руководитель проектов понимает их по-своему, то их интерпретация и практическое применение может ставить участников проекта в очень болезненное и низкоэффективное положение. Часто понимание задачи SCRUM как фреймворка сводится к карго-культу исполнения его церемоний "несмотря ни на что", принося прямой ущерб как проекту или продукту, так и демотивируя всю команду в целом.

Мы рассмотрим SCRUM, как один из самых популярных и распространённых фреймворков, и поговорим не только о том, как заставить аналитика в нем страдать, но и как сделать его участие максимально благополучным и эффективным для всего проекта. Т.е. перестать быть карго-культистом и стать скрам-красавчиком!

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

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

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

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

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

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

Вместе с Архипом мы пройдем все этапы: от предпроектного исследования и определения скоупа работ через итеративное наращивание фичей до управления бэклогом и распределнием времени между задачами аналитика, и познаем силу волшебной матрицы на каждом из них!

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

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

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

Бывает, аналитик работает на проекте один. Бывает их двое-трое.

А что если только аналитиков на проекте больше десяти?

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

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

Также, обсудим конкретные проблемы, на практике возникающие у подобных команд, например, такие как:

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

И попробуем найти их решение.