Круглый СтолКакие аналитики нужны? презентация

Содержание

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

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

Слайд 3Человек оркестр
Сам снимает требования
Сам проектирует
Сам программирует
Сам тестирует

Сам внедряет


Очень эффективно

Не работает в больших
проектах

Слайд 4Классическая схема взаимодействия
с/а
б/а
dev
q/a
Заказчик




неформализованные требования
формализованные требования
ТЗ
Работающий
продукт

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

Слайд 6А еще техсуппорт и внедрение
Протестированный продукт


Протестированный продукт

Техническая
поддержка

Внедрение

Слайд 7Бизнес аналитик
Эксперт в предметной области
Говорит с заказчиком на одном языке
Собирает требования

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




Слайд 8Держит общую концепцию в голове
Систематизирует знания
Борется со сложностью
Стыкует бизнес и

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



Системный аналитик

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

железе)


Слайд 10Проверяет реализованное ПО :
соответствие модели
удобство использования
возможность реализовать описанные


Ищет технические ошибки



Quality assurance

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

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

Слайд 13Бизнес аналитик
Не строит модели:
Не может проверить полноту требований
Не может

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

Птица «Говорун»

Слайд 14Системный аналитик
Мудрец в башне из «Слоновой Кости»
Не общается с

заказчиком (пользователем):
Не знает деталей реализации
Оторван от земли.. (Чистые абстракции)

Слайд 15Разработчик
«В Законе»
Изолирован от заказчика:
Больше всего влияет на результат
(Реализовано будет

только то, что понял программист)
Ни за что не отвечает:
Ошибок нет? ТЗ соответствует? ко мне какие вопросы?

Слайд 16Quality assurance
Мальчик для битья
Отвечает за все( «Последний бастион качества», Все

шишки в начале – q/a «Как вы это пропустили?» )
Последний в цепочке получения информации…
Ни на что не влияет (Никаких решений не принимает)

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

Слайд 18Обсуждение:
Какая схема работает у вас в компании?
Какие проекты делает компания ?
Выделена

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


Слайд 19Опыт (Торговые

Сети)

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

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

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

Слайд 22Общий контекст
Небольшие команды (5-9 человек)
Одна замкнутая предметная область
Все члены

команды погружены в предметную область (насколько возможно)
«Экскурсии» и «Рекогносцировки» на местах реального использования (для всех членов команды)
Единое информационное пространство с заказчиком (wiki, bugzilla)

Слайд 23Не везде соответствует жизни. Но на уровне базовых принципов - верно
Минимизация

цепочки передачи информации

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

Слайд 24Общая ответственность перед пользователем
Все члены команды знают кто их заказчик и

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

Не везде соответствует жизни. Но на уровне базовых принципов - верно

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

Слайд 26Исключения – выделенный бизнес аналитик
Бывает необходим для очень запутанных предметных областей
Например:

для Билинга ЖКХ - нужно знать всю законодательную базу что бы общаться с заказчиком

Похожие презентации

Химическая и нефтехимическая промышленность.Республики Татарстан. Территориальная структура 393
YOUTH MOVEMENTS 452
Подходы к формированию программы формирования УУД с учетом показателей результативности реализации ООП ДОПатрикеева Ирина Евгеньевна 240
Древние религии 348
ТСМ Керамик 399
Аганбегян Абел Гезевич 602

Обратная связь

Если не удалось найти и скачать презентацию, Вы можете заказать его на нашем сайте. Мы постараемся найти нужный Вам материал и отправим по электронной почте. Не стесняйтесь обращаться к нам, если у вас возникли вопросы или пожелания:

Email: Нажмите что бы посмотреть 

Что такое ThePresentation.ru?

Это сайт презентаций, докладов, проектов, шаблонов в формате PowerPoint. Мы помогаем школьникам, студентам, учителям, преподавателям хранить и обмениваться учебными материалами с другими пользователями.

Для правообладателей

Яндекс.Метрика