Кто должен принимать работу, которую команда делала вместе?

На курсах веб-разработки в HTML Academy мы разделили помощь с проектом и его приёмку: работу проверял другой, случайно назначенный наставник. В разговоре 2018 года я объяснял, почему при таком устройстве нужны общие критерии. Ученик должен понимать требования к работе независимо от того, кто её проверяет.

Однако и сам критерий может оказаться двусмысленным. Рассмотрим учебную форму и три замечания к ней. Сам проект и порядок пересмотра оценки придуманы для этого примера; они не описывают процедуру Академии.

Что известно до начала работы

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

До начала проекта они получают такие требования:

Не все формулировки здесь одинаково хороши. Ширину окна можно выставить и повторить проверку. А вот слово «понятным» оставляет проверяющему заметно больше свободы. К этому пункту ещё вернёмся.

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

Другой проверяющий открывает ту же версию проекта. С клавиатуры поля доступны, но фокус не виден. В CSS у полей убрана обводка, а замены ей нет. Проверяющий возвращает работу и добавляет ещё замечания: предлагает отдельный класс для каждого поля и просит точнее объяснить ошибку заполнения.

Для ученика всё это может выглядеть как одна отмена прежней договорённости. Но основания у замечаний разные. Если разбирать их вместе, спор о классах может заслонить настоящую проблему с клавиатурой.

Независимый взгляд обнаружил пропуск

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

Наставник повторяет действия и получает тот же результат. Чтобы согласиться с замечанием, ему не нужно признавать правоту проверяющего по всем пунктам. Достаточно проверить этот конкретный случай.

Приёмка здесь сработала. Во время совместной работы ученику помогли решить несколько задач, но одну из обещанных проверок пропустили. Теперь её можно выполнить и исправить результат.

Наставнику полезнее сказать: «Да, мы проверяли мышью и этого не заметили. Посмотрим, как обозначить фокус», чем убеждать проверяющего, что ученик и так много сделал. По ходу работы наставник видит, чему ученик научился и где ему нужна помощь. Пользователь страницы этого не видит. Ему всё ещё нужно понимать, куда попадёт следующее действие с клавиатуры.

Наставник при этом остаётся рядом: признаёт пропущенную проверку и помогает с доработкой. Независимая приёмка не отменяет его участия в обучении.

Замечание основано на предпочтении

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

Здесь я бы попросил показать, какое требование нарушает нынешний код. Возможно, у общего селектора есть конкретная проблема, которую пока не объяснили. Например, правило затрагивает и кнопку, хотя ей нужно другое оформление. Тогда стоит показать это состояние и обсуждать исправление.

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

Если курс действительно учит определённой методологии именования, она должна появиться в программе и в требованиях до работы. Тогда применение этой методологии само станет частью результата. Пока такого условия нет, добавлять его на защите поздно.

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

Спор обнаружил ошибку в критерии

Осталось сообщение об ошибке. При попытке отправки форма пишет «Некорректный адрес электронной почты». Неправильно заполненное поле дополнительно выделено цветом. Наставник счёл это достаточным: сообщение называет поле и говорит, что адрес введён неверно. Проверяющий считает, что посетителю, который записывается на занятие, нужна ещё и подсказка, как исправить адрес.

Слова «сообщение должно быть понятным» позволяют им обоим повторять свою позицию. Можно пригласить ещё одного проверяющего и получить третий голос, но от голосования формулировка не станет точнее.

Посмотрим на задачу сообщения: помочь исправить данные и продолжить заполнение. В учебном случае введён адрес без части после @. Сообщение называет ошибку, но не объясняет, какой части адреса не хватает. Это уже предметный разговор: можно пройти тот же путь и обсудить, какую подсказку добавить.

Для следующей версии задания условие можно написать так: «При ошибке заполнения форма называет поле с ошибкой и объясняет, что в нём исправить». Например: «В поле „Электронная почта“ укажите адрес целиком, вместе с частью после @». Текст сообщения не обязательно должен совпадать с примером дословно; проверяется, помогает ли он исправить конкретную ошибку.

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

Для группы, которая получила старую формулировку, решение должно быть одинаковым. Если одному ученику сняли замечание после разговора, а другому оставили то же замечание без объяснения, проблема приёмки сохранилась. После уточнения критерия стоит посмотреть уже выставленные спорные оценки и сообщить, как с ними поступят.

Что остаётся после пересмотра

Разбор спорной оценки я бы проводил на сохранённой версии проекта. Пока обсуждение идёт, ученик может уже исправлять страницу, и первоначальную ошибку станет трудно повторить. Рядом нужны текст задания, действовавший до начала работы, и конкретное замечание проверяющего.

Начать можно с вопроса: «Покажите, какое требование не выполняется и как это увидеть». Ученик или наставник получает возможность показать обратный пример либо указать, что такого требования не было. Если договориться не получилось, человек, отвечающий за программу, разбирает именно это расхождение. Его задача не сводится к выбору более опытного участника спора.

У нашей страницы в итоге остаётся обязательная доработка фокуса. После исправления её проверяют тем же способом с клавиатуры. Требование отдельных классов снимают. Сообщение об ошибке обсуждают как улучшение, а критерий переписывают для следующих работ. Это разные решения, и ученику полезно увидеть каждое с его основанием.

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

Мне кажется полезным, чтобы готовую работу смотрел человек, который не участвовал в её создании. Он может заметить то, к чему автор и наставник уже привыкли. При этом его замечания должны опираться на известные требования и допускать пересмотр. Тогда ученик понимает, что нужно доработать, а разбор спорной оценки помогает улучшить само задание.