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

В глазах ужас, в сердце страх, в голове пустота. Он идет к ментору-аналитику и просит помощи. Ментор дает ему волшебную матрицу 2х2.

-Что это? - спрашивает Архип.

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

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

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

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

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

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

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

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

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

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

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

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