'

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

Понравилась презентация – покажи это...





Слайд 0

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


Слайд 1

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


Слайд 2

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


Слайд 3

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


Слайд 4

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


Слайд 5

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


Слайд 6

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


Слайд 7

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


Слайд 8

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


Слайд 9

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


Слайд 10

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


Слайд 11

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


Слайд 12

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


Слайд 13

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


Слайд 14

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


Слайд 15

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


Слайд 16

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


Слайд 17

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


Слайд 18

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


Слайд 19

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


Слайд 20

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


Слайд 21

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


Слайд 22

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


Слайд 23

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


Слайд 24

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


Слайд 25

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


×

HTML:





Ссылка: