Проверка результата для клиента

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

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

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

Разделите готовую работу, её использование и пользу

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

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

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

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

1. Выполнена ли обещанная работа: сценарии, формулировки, доступ к файлам.
2. Пользуются ли инструкцией без постоянных подсказок автора.
3. Изменилась ли работа: скорость типовых запросов и число уточнений у руководителя.

Связь изменения именно с инструкцией нужно отделять от других одновременных изменений.

И ещё один вопрос: насколько изменение связано именно с инструкцией? Возможно, одновременно компания упростила форму заявки, наняла опытного сотрудника или сократила количество обязательных согласований. Установить вклад каждого изменения сложнее, чем заметить разницу во времени выполнения.

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

Договоритесь об оценке до завершения работы

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

Спросите клиента: «Что должно измениться, чтобы вы считали эту работу полезной?» Затем уточните, как можно будет увидеть изменение. Ответ «чтобы стало удобнее» стоит перевести в конкретную ситуацию: сотрудник находит порядок действий без обращения к руководителю; менеджер обновляет отчёт без ручного объединения пяти файлов; новый пользователь выполняет типовую задачу.

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

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

Выберите несколько признаков, которые помогут принять решение

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

Для учебного проекта Юлии план может выглядеть так:

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

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

Зафиксируйте исходное состояние

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

Допустим, компания хочет сократить время обработки запроса. «Время» может означать активную работу сотрудника, календарный промежуток до ответа клиенту или время вместе с ожиданием руководителя. Эти показатели отвечают на разные вопросы. Если до проекта учитывали весь день ожидания, а после — только десять минут работы, сравнение получится неверным.

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

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

Посмотрите, как человек пользуется результатом

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

В руководстве GOV.UK по пользовательскому тестированию предлагается наблюдать за выполнением реалистичных задач и избегать подсказок, которые заранее раскрывают решение. Это позволяет увидеть затруднения, скрытые за общим ответом «всё понятно».

Юлия может предложить сотруднику учебный запрос, похожий на рабочий, и попросить показать, как он воспользуется инструкцией. Важно объяснить: сейчас проверяют удобство материала, а не профессиональную пригодность человека. Если сотрудник боится выглядеть неопытным перед руководителем, он может замалчивать непонятные места.

Не торопитесь исправлять каждое движение. Допустим, человек ищет нужный случай по слову, которого в инструкции нет. Если сразу показать правильный раздел, станет проще закончить задачу, но причина затруднения останется скрытой. Сначала отметьте, что произошло, и спросите, где он ожидал найти ответ. Затем можно помочь и отдельно зафиксировать эту помощь.

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

Сравнивайте цифры вместе с условиями

Рассмотрим условные данные. До появления инструкции активная обработка шести похожих запросов заняла 30, 35, 40, 40, 45 и 50 минут. После — 15, 20, 25, 25, 30 и 35 минут. В обоих случаях использован один способ учёта времени.

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

До

30, 35, 40, 40, 45 и 50 минут. Медиана 40 минут.

После

15, 20, 25, 25, 30 и 35 минут. Медиана 25 минут.

Шесть и шесть наблюдений при одном способе учёта. Разницу нельзя автоматически приписать только инструкции.

Корректное описание: «В рассмотренных шести случаях до изменения медианное время составляло 40 минут, в шести случаях после — 25 минут». Дальше нужно объяснить ограничения: насколько сопоставимы задачи, работали ли те же сотрудники, не изменилась ли форма запроса, были ли другие нововведения.

Некорректный скачок: «Наша инструкция гарантированно экономит каждому сотруднику пятнадцать минут на любой заявке». Маленькое наблюдение этого не подтверждает. Руководство Magenta Book отдельно рассматривает ограничения простого сравнения до и после: без подходящего способа сравнения нельзя автоматически приписать всю разницу одному воздействию.

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

Спросите об опыте, а не только об общей оценке

Вопрос «Вам всё понравилось?» удобен, но часто приводит к короткому вежливому ответу. Более содержательный разговор начинается с конкретного случая: «Когда вы последний раз использовали материал? Что делали? Где пришлось остановиться? Что в итоге получилось?»

Уточните, какие части клиент не использовал и почему. Возможно, они не нужны. Возможно, до них ещё не дошла очередь. А возможно, именно там находится непреодолимое затруднение. Одинаковое внешнее поведение может иметь разные причины.

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

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

Если пользы не видно, найдите причину

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

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

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

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

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

Завершите оценку коротким отчётом

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

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

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

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