Круглый Стол«Какие аналитики нужны?»


The Presentation inside:

Slide 0

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


Slide 1

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


Slide 2

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


Slide 3

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


Slide 4

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


Slide 5

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


Slide 6

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


Slide 7

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


Slide 8

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


Slide 9

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


Slide 10

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


Slide 11

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


Slide 12

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


Slide 13

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


Slide 14

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


Slide 15

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


Slide 16

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


Slide 17

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


Slide 18

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


Slide 19

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


Slide 20

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


Slide 21

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


Slide 22

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


Slide 23

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


Slide 24

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


Slide 25

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


×

HTML:





Ссылка: