Проверка качества перед сдачей

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

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

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

Вернитесь к обещанному результату

Откройте согласованное описание задачи. Что вы должны передать? В каком формате? Какие исходные условия приняты? Какие свойства особенно важны для клиента?

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

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

APM различает планирование качества, обеспечение качества и контроль результата. Для самостоятельного исполнителя это означает: полезно и проверять готовую работу, и устраивать процесс так, чтобы одни и те же ошибки возникали реже.

Свяжите каждое важное требование со способом проверки

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

В инженерном руководстве NASA предлагается заранее определять, как будет проверяться каждое требование, и связывать это в матрице. Для обычной услуги можно взять сам принцип прослеживаемости, не переносить весь масштаб инженерной документации.

В нашем примере достаточно такой таблицы:

Такая запись полезнее отметки «проверено», если потом возникнет вопрос, что именно проверяли и при каких условиях.

Уделите больше внимания последствиям ошибок

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

Для критичных элементов нужна отдельная проверка. Например, суммы можно пересчитать независимым способом, ссылки — открыть, контакты — сверить с подтверждённым источником. Сам факт, что вы недавно вводили эти данные, не заменяет проверки.

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

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

Проверяйте обычные и неудобные случаи

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

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

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

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

Посмотрите на результат глазами получателя

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

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

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

Отделите готовое от известного ограничения

Иногда остаётся некритичное ограничение, которое стороны готовы принять. Например, дополнительный отчёт будет подготовлен позже, а основная таблица уже работает. Это нужно согласовать, а не спрятать в надежде, что клиент не заметит.

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

Уберите из передачи рабочие черновики, лишние версии и чужие данные, которые не должны попасть клиенту. Проверьте права доступа. Передача — самостоятельный этап качества: отличный результат бесполезен, если адресат не может его открыть или не понимает, какой файл актуален.

Соберите короткий список для повторного использования

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

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