Презентация результатов пилотного проекта должна помочь решить, стоит ли расширить испытание, изменить его, продлить или остановить. Покажите исходные критерии успеха рядом с полученными результатами и объясните компромисс. Хорошее значение главного показателя не отменяет невыполненного условия по качеству или нагрузке.
Выстройте рассказ вокруг решения: что проверяли, что произошло, чего нельзя установить по имеющимся данным и что делать дальше. После проверки записей можно превратить описание пилотного проекта в черновик слайдов с помощью Presenti. В примере ниже неоднозначный результат разобран на семи слайдах, без автоматического признания испытания успешным.
Начните с решения, ради которого проводили пилот
«Новости пилотного проекта» — это название встречи, а не её цель. Полезнее конкретный вопрос: «Внедрить новую форму заявок ещё в одном подразделении, повторить испытание после изменения или сохранить нынешний процесс?»
Рядом с вопросом обозначьте границы: кто участвовал, какой процесс изменили, сколько длилось испытание и что в него не вошло. Результаты одного подразделения могут помочь спланировать следующий тест, но не обосновывать внедрение во всей компании.
Руководство GOV.UK Service Manual по измерению пользы сервиса рекомендует согласовывать показатели в начале бета-этапа и сравнивать наблюдаемые результаты с прогнозами, принимая решение о продолжении. Для презентации пилота это означает вернуться к исходным критериям, а не выбирать привлекательные показатели после получения результатов.
Если критерии не согласовали заранее, так и скажите. Всё равно можно описать произошедшее и предложить способ оценки следующего испытания. Не называйте удобный порог исходной целью задним числом.
Разбор примера: более полные заявки, но сохраняется нагрузка на поддержку
Допустим, внутренняя сервисная команда испытывает обновлённую форму заявок. Исходные данные собраны за четыре недели работы по старому процессу; пилот проходит две недели в одном подразделении. Все приведённые цифры и пороги вымышлены для объяснения метода: это не клиентский кейс и не результат, достигнутый с Presenti.
| Показатель | Старый процесс: четыре недели | Новая форма: две недели |
|---|---|---|
| Поданные уникальные заявки | 100 | 50 |
| Заявки с полной информацией при первой подаче, без уточнений | 76 | 46 |
| Заявки, по которым вопрос решён к дате среза | 80 | 45 |
| Решённые заявки, для которых зарегистрировано исправление ошибки ввода | 4 | 3 |
| Зафиксированные дополнительные трудозатраты на поддержку при работе с новой формой | Не измерялись по такому принципу | 120 минут |
Полноту информации при первой подаче определяют по заполненным полям и записям об уточнениях. Это не то же самое, что решённый вопрос: полностью заполненная заявка может ожидать проверки, а неполная — быть решена после уточнения. Каждую заявку считают один раз, даже если по ней отправлено несколько сообщений.
Пять нерешённых заявок пилота остаются в общем количестве поданных. По трём ожидается ответ заявителя, по двум — проверяющего. Если их исключить, изменится рассматриваемая совокупность и станет сложнее понять результат.
Указывайте знаменатель рядом с каждым результатом
Доля заявок с полной информацией при первой подаче выросла с 76 ÷ 100 = 76 % до 46 ÷ 50 = 92 % — на 16 процентных пунктов. «Рост на 16 %» означает другое. Показывайте не только проценты, но и количество заявок, чтобы был виден размер каждой группы.
Доля исправлений ошибок ввода отвечает на другой вопрос: скольким из заявок, решённых к дате среза, потребовалось исправление? По старому процессу это 4 ÷ 80 = 5 %, в пилоте — 3 ÷ 45 ≈ 6,7 %. Не используйте 3 ÷ 50 для показателя, который явно определён среди решённых заявок.
В пилоте зафиксировано всего три исправления. Важны их характер и серьёзность; кроме того, пять нерешённых заявок ещё могут изменить последующую картину. Нынешние цифры описывают состояние на дату среза, а не устанавливают устойчивую долгосрочную частоту ошибок.
Показатель поддержки равен 120 ÷ 50 = 2,4 дополнительной минуты работы сотрудников на одну поданную заявку. Это трудозатраты на помощь в использовании новой формы, а не время ожидания клиента, обработки заявки или сэкономленное время. Поскольку в исходном периоде такую же поддержку не измеряли, таблица не позволяет установить чистую экономию труда или изменение нагрузки по сравнению с прежним процессом.
Покажите неоднозначный результат, не скрывая его за средним
В этом примере команда заранее согласовала три критерия. Пороги относятся к вымышленному решению и не являются отраслевыми нормами.
| Согласованный критерий | Наблюдение в пилоте | Результат на дату среза |
|---|---|---|
| Не менее 90 % заявок содержат полную информацию при первой подаче | 46/50 = 92 % | Выполнен |
| Не более 5 % решённых заявок требуют исправления ошибки ввода | 3/45 ≈ 6,7 % | Не выполнен |
| Не более 2 дополнительных минут поддержки на поданную заявку | 120/50 = 2,4 минуты | Не выполнен |
Заголовок «Новая форма прошла пилот с успехом 92 %» скрыл бы два невыполненных критерия и превратил полноту информации в общую оценку успеха. Точнее так: «Больше заявок поступают с полной информацией; цели по исправлениям и поддержке пока не достигнуты».
Не усредняйте три показателя ради одного цветового индикатора. Они описывают разные явления, имеют разные единицы измерения и были выбраны для защиты от разных проблем. Если руководство решит продолжать несмотря на невыполненный критерий, зафиксируйте решение и условия, а не переписывайте результат как успешное прохождение испытания.
Отделите наблюдаемое улучшение от объяснения его причин
Изменилась форма, но изменился и период наблюдения, а возможно, состав участников и типы заявок. Пилот проводился на доступной группе, без случайного распределения и параллельной группы сравнения. Разница в 16 пунктов сама по себе не доказывает, что улучшение вызвано формой.
Ищите объяснения, от которых зависит следующий шаг. Не было ли непропорционально много простых заявок? Не помогали ли сотрудники чаще? Не пришёлся ли пилот на спокойный период? Одинаково ли определяли полноту информации в обеих группах? Этим вопросам место рядом с результатом, а не в общем предупреждении в конце.
В вымышленном испытании команда подозревает, что неоднозначное поле формы приводит к исправлениям. Это гипотеза. Изучите три исправленные записи и заметки поддержки, прежде чем заявлять об общей причине. Если в записях разные проблемы, изменение одного поля может решить не все из них.
Отделяйте качественные наблюдения от количественных данных. Комментарий участника может объяснить непонимание, но не показывает, насколько оно распространено. Если у вас есть разрешённая к использованию цитата с установленным авторством, приведите её; не придумывайте отзыв ради более живого слайда.
Предложите следующий шаг с чёткими границами
В этом случае разумно предложить разобрать исправления, уточнить спорное поле там, где необходимость изменения подтверждается данными, и повторить испытание сходного масштаба до расширения. Это предложение, а не утверждённое решение или прогноз достижения целей.
В следующем описании укажите новую версию формы, участвующее подразделение, период наблюдения, предусмотренную поддержку, определения показателей и критерии решения. Сохраните прежние меры, если они по-прежнему отвечают на вопрос. Если определение меняется, объясните причину и не сравнивайте новый показатель со старым так, будто ничего не изменилось.
Выберите период наблюдения и план участия вместе с ответственным аналитиком или владельцем сервиса, исходя из принимаемого решения. Фраза «в прошлый раз хватило пятидесяти заявок» не обосновывает статистический вывод. В этом примере нет расчёта объёма выборки или проверки статистической значимости.
Если заказчик пилота хочет немедленно расширить его, уточните условия: какие подразделения подключаются, какая поддержка предоставляется, какие риски остаются и какое наблюдение станет основанием для паузы. Полное внедрение — другое обязательство, чем участие ещё одной команды.
Структура презентации результатов пилота из семи слайдов
- Рекомендация. Повторить ограниченное испытание после разбора исправлений и поддержки; одобрение ещё требуется.
- Границы пилота. Показать старый и новый процесс, участников, периоды, дату среза и ограничения сравнения.
- Исходные критерии. Представить три согласованных порога до обсуждения результатов.
- Наблюдаемые результаты. Показать 76/100 и 46/50, 4/80 и 3/45, а также 120/50 минут работы сотрудников. Не объединять эти показатели.
- Что пока не объяснено. Показать нерешённые заявки, случаи исправлений, заметки поддержки и предполагаемую проблему поля, не объявляя её установленной причиной.
- Следующее испытание или альтернатива. Указать, что изменится, что останется сопоставимым и какое решение должны поддержать следующие наблюдения.
- Решение и условия. Зафиксировать то, с чем действительно согласился заказчик, а ответственного и дату последующей проверки указать после подтверждения.
Данные по отдельным заявкам и расчёты оставьте в дополнительных материалах. В основной презентации должно быть достаточно деталей для объяснения рекомендации, но аудитории не придётся заново восстанавливать каждый знаменатель прямо на встрече.
Подготовьте исходный текст, сохранив неоднозначность результата
Когда владелец сервиса проверит цифры, используйте поле Paste Text в Presenti — ввод готового текста — для подготовки черновика слайдов из записей. Введите определения и ограничения вместе с числами. Не просите инструмент решить, был ли пилот успешным.
Создай презентацию результатов пилота из семи слайдов по вымышленному испытанию внутренней формы. Исходный период: четыре недели, 100 уникальных заявок, 76 с полной информацией при первой подаче, 80 решённых, среди них 4 потребовали исправления ошибки ввода. Пилот: две недели в одном подразделении, 50 заявок, 46 с полной информацией при первой подаче, 45 решённых, среди них 3 потребовали исправления; дополнительно затрачено 120 минут работы сотрудников поддержки. Пять заявок остаются нерешёнными: по трём ожидается ответ заявителя, по двум — проверяющего. Покажи 76 % и 92 %, разница — 16 процентных пунктов; долю исправлений среди решённых заявок 5 % и примерно 6,7 %; 2,4 минуты поддержки на заявку пилота. Заранее заданные критерии этого примера: не менее 90 % полной информации, не более 5 % исправлений и не более 2 минут поддержки. Выполнен только критерий полноты информации. Испытание не было рандомизированным. Рекомендуй разобрать проблемы исправлений и поддержки перед повтором сходного масштаба; решение ещё не одобрено. Не придумывай причинность, экономию, статистическую значимость или успешное внедрение.
В черновике проверьте, что рядом с процентами остались исходные количества, нерешённые заявки не исчезли, а время поддержки не превратилось в «сэкономленное время». Полезный разбор пилота может рекомендовать продолжение и одновременно прямо говорить, что нынешнее испытание выполнило ещё не все условия для расширения.
