Круглый Стол «Какие аналитики нужны?» Эффективное разделение ролей и обязанностей

Описание проблемы 2

Человек оркестр 3 Сам снимает требования Сам проектирует Сам программирует Сам тестирует Сам внедряет Очень эффективно Не работает в больших проектах

Классическая схема взаимодействия 4 с/а б/а devq/a Заказчик неформализованные требования формализованные требования ТЗРаботающий продукт

А если народу совсем много то: 5 Tech Lead Главный Q/A Архитектор

А еще техсуппорт и внедрение 6 Протестированный продукт Техническая поддержка Внедрение

Бизнес аналитик 7 Эксперт в предметной области Говорит с заказчиком на одном языке Собирает требования с Заказчика ( И согласует их с ним) В состоянии предоставить знания в структурированном и формализованном виде В состоянии отличить важное от не важного В состоянии описать Use-case В состоянии «Проверифицировать» модель системного аналитика

Держит общую концепцию в голове Систематизирует знания Борется со сложностью Стыкует бизнес и ИТ Строит модели (Проектирует) Проверяет на полноту и не противоречивость Придумывает «Абстракции» (сознательно игнорирует маловажные детали) Делит на слабосвязанные части Осознает и обозначает границы модели Объясняет модели разработчикам и б/а Пишет задание на разработку Системный аналитик 8

Разработчик 9 Продумывает «технические детали» реализации Проверяет модели с/а на реализуемость Реализует (отливает в железе)

Проверяет реализованное ПО : соответствие модели удобство использования возможность реализовать описанные Ищет технические ошибки Quality assurance 10

Собственно проблемы 11

Потеря контекста на звеньях передачи 12 Баян

Бизнес аналитик 13 Не строит модели: Не может проверить полноту требований Не может проверить их непротиворечивость Не может ответственно обсуждать с заказчиком варианты реализации Челночные переговоры (Заказчик б/а C/а ) Ни за что реально не отвечает. Не пользуется авторитетом у заказчика Не пользуется авторитетом у разработчиков Птица «Говорун»

Системный аналитик 14 Мудрец в башне из «Слоновой Кости» Не общается с заказчиком (пользователем): Не знает деталей реализации Оторван от земли.. (Чистые абстракции)

Разработчик 15 «В Законе» Изолирован от заказчика: Больше всего влияет на результат (Реализовано будет только то, что понял программист) Ни за что не отвечает: Ошибок нет? ТЗ соответствует? ко мне какие вопросы?

Quality assurance 16 Мальчик для битья Отвечает за все( «Последний бастион качества», Все шишки в начале – q/a «Как вы это пропустили?» ) Последний в цепочке получения информации… Ни на что не влияет (Никаких решений не принимает)

Классические способы борьбы 17 Подробные спецификации И все проблемы водопада

Обсуждение: 18 Какая схема работает у вас в компании? Какие проекты делает компания ? Выделена ли у вас роль Аналитика? Есть ли у вас разные роли для Аналитиков? Как аналитики взаимодействуют с заказчиком?, разработчиками? q/a? Поддержкой? Техсуппортом? внедренцами? Вы довольны? Какие есть проблемы? Какую схему вы считаете более эффективное?

Опыт (Торговые Сети) 19 Особенности: заказная разработка длительная (несколько лет) работа команды над одним продуктом б/а – во многом на стороне клиента а так же на клиенте: Техническая поддержка (Первая и вторая линия) Обучение пользователей

Роли в команде – Вариант 1 (Рук – Tech Lead) 20 Руководитель Разработчики Инженеры Аналитики

21 Роли в команде – Вариант 2 (Рук – главный Q/A) Руководитель Разработчики Инженеры Аналитики

Общий контекст 22 Небольшие команды (5-9 человек) Одна замкнутая предметная область Все члены команды погружены в предметную область (насколько возможно) «Экскурсии» и «Рекогносцировки» на местах реального использования (для всех членов команды) Единое информационное пространство с заказчиком (wiki, bugzilla)

Не везде соответствует жизни. Но на уровне базовых принципов - верно Минимизация цепочки передачи информации 23 Аналитик обязательно совмещен С разработчиком (знает детали реализации) С инженером (общается с пользователем, знает реальные случаи использования, ведет техническую поддержку 3го уровня) Разработчики тоже пишут постановки и участвуют в переговорах с заказчиком (а также во внедрениях). И Разработчики и инженеры участвуют в принятии принципиальных решений Инженеры участвуют во внедрении/ обучении пользователей (по крайней мере первый раз)

Общая ответственность перед пользователем 24 Все члены команды знают кто их заказчик и пользователь (и хотя бы раз его видели). Критерий успеха – работающее ПО у клиента Заказчик приезжает на демонстрацию в команду. (каждый член команды САМ показывает заказчику – что он сделал) Не везде соответствует жизни. Но на уровне базовых принципов - верно

Исключения – выделенный системный аналитик 25 Исторически еще есть… Скорее плохая практика чем хорошая…

Исключения – выделенный бизнес аналитик 26 Бывает необходим для очень запутанных предметных областей Например: для Билинга ЖКХ - нужно знать всю законодательную базу что бы общаться с заказчиком