воскресенье, 30 апреля 2017 г.

#МетодологияВнедрения Перекрестная экспертиза или как обеспечить в проекте проверку качества

О методе перекрестной экспертизы я впервые узнала, когда внедряли в рамках проекта профессиональное тестирование, а именно, когда строили систему разработки электронных тестов проверки профессиональных знаний внутренними ресурсами, то есть самими заказчиками тестовых заданий.

Смысл метода в том, что тест разрабатывается не одним человеком, а командой экспертов. Сам тест строится согласно Российскому стандарту тестирования:
  • есть случайная выборка вопросов на экран
  • пул вопросов превышает выборку в пять раз и более
  • в пул входят вопросы по разным уровням сложности в определенном соотношении
  • охватывает предметную область опроса полностью и равномерно
За счет этих требований требовалось разработать на каждую функцию не менее 400 тестовых заданий, которые уже прошли проверку и отсев некачественных вопросов. Поэтому, пул делился между командой по определенным критериям. После разработки все члены команды проходили тесты по несколько раз друг у друга и оценивали тестовые вопросы по специально разработанным критериям с проставлением баллов каждому вопросу. Сами вопросы и итоговые тесты также проверялись в несколько итераций - сначала методологом,  потом командой авторов в перекрестном режиме, и в итоге тестировались на ком-то из целевой аудитории в виде пилотного тестирования с достаточной числовой выборкой, чтобы проверить валидность теста.

Действительно, когда ребята в команде проверяют тесты друг друга, но не оценивая самих авторов (об этом каждый раз приходится напоминать, а то же люди переживают), качество вопросов шлифуется и достигается нужного уровня. Нам, как методологам, не приходится долго и мучительно доказывать, почему этот вопрос неверно сформулирован - сами все прекрасно видят и проверяют на "собственной шкуре".

Этот же подход мы стали использовать в любом внедрении и разработке!

Включаем обязательно этап перекрестной экспертизы разрабатываемого продукта. При необходимости, на нескольких уровнях или вехах проекта. Это позволяет не выделять специальную роль "тестировщика", снизить максимально субъективность проверяющего и минимизировать время на споры и конфликты, когда приходится аргументировать критерии качества.

За счет механизма перекрестной экспертизы мы можем вначале не сильно заморачиваться на качестве (чтобы сразу и на 100% качества), так как в процессе разработки ошибки находятся, осознаются и убираются самой командой подразделения, где происходит инновационное внедрение - нам не приходится работать с возражениями и сопротивлением. Команда сама приходит к нужному уровню качества, при этом получая большую мотивацию в процессе проекта, обеспечивая наилучший уровень качества к завершению пилотного тестирования.

Буду рада вопросам и обратной связи,
Ваша Денисова Елена,