О методе перекрестной экспертизы я впервые узнала, когда внедряли в рамках проекта профессиональное тестирование, а именно, когда строили систему разработки электронных тестов проверки профессиональных знаний внутренними ресурсами, то есть самими заказчиками тестовых заданий.
Смысл метода в том, что тест разрабатывается не одним человеком, а командой экспертов. Сам тест строится согласно Российскому стандарту тестирования:
- есть случайная выборка вопросов на экран
- пул вопросов превышает выборку в пять раз и более
- в пул входят вопросы по разным уровням сложности в определенном соотношении
- охватывает предметную область опроса полностью и равномерно
За счет этих требований требовалось разработать на каждую функцию не менее 400 тестовых заданий, которые уже прошли проверку и отсев некачественных вопросов. Поэтому, пул делился между командой по определенным критериям. После разработки все члены команды проходили тесты по несколько раз друг у друга и оценивали тестовые вопросы по специально разработанным критериям с проставлением баллов каждому вопросу. Сами вопросы и итоговые тесты также проверялись в несколько итераций - сначала методологом, потом командой авторов в перекрестном режиме, и в итоге тестировались на ком-то из целевой аудитории в виде пилотного тестирования с достаточной числовой выборкой, чтобы проверить валидность теста.
Действительно, когда ребята в команде проверяют тесты друг друга, но не оценивая самих авторов (об этом каждый раз приходится напоминать, а то же люди переживают), качество вопросов шлифуется и достигается нужного уровня. Нам, как методологам, не приходится долго и мучительно доказывать, почему этот вопрос неверно сформулирован - сами все прекрасно видят и проверяют на "собственной шкуре".
Этот же подход мы стали использовать в любом внедрении и разработке!
Включаем обязательно этап перекрестной экспертизы разрабатываемого продукта. При необходимости, на нескольких уровнях или вехах проекта. Это позволяет не выделять специальную роль "тестировщика", снизить максимально субъективность проверяющего и минимизировать время на споры и конфликты, когда приходится аргументировать критерии качества.
За счет механизма перекрестной экспертизы мы можем вначале не сильно заморачиваться на качестве (чтобы сразу и на 100% качества), так как в процессе разработки ошибки находятся, осознаются и убираются самой командой подразделения, где происходит инновационное внедрение - нам не приходится работать с возражениями и сопротивлением. Команда сама приходит к нужному уровню качества, при этом получая большую мотивацию в процессе проекта, обеспечивая наилучший уровень качества к завершению пилотного тестирования.
Буду рада вопросам и обратной связи,
Ваша Денисова Елена,
Комментариев нет:
Отправить комментарий