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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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