Пять рабочих дней на проверку SaaS: как закончить тест решением
Я Алина, PR-менеджер Kartli. Предлагаю пятидневный сценарий проверки рабочего инструмента. Это наш пример организации теста, а не обещание пробного периода со стороны какого-либо сервиса. Условия доступа и оплаты проверяются отдельно.
День первый: выберите одну повторяющуюся задачу
Вместо «проверить все возможности» возьмите процесс, который действительно занимает время: собрать отчёт, подготовить комплект материалов или согласовать изменения. Опишите, как он выполняется сейчас и что будет считаться готовым результатом.
Выберите человека, который выполнит задачу, и человека, который примет результат. Они могут совпадать, но критерий качества должен быть понятен до старта. Красивый пример из демонстрации ещё не отвечает на вопрос о пользе для вашего процесса.
До начала теста откройте условия плана: когда требуется платёж, что произойдёт после выбранного периода и какие действия нужны для изменения подписки. Пять рабочих дней — срок вашей проверки; с платёжным периодом сервиса он может не совпадать.
День второй: выполните обычный сценарий
Возьмите реальный материал, который команда вправе использовать в выбранном продукте. Не подбирайте специально самый удобный пример. Ценность проверки в том, чтобы понять работу инструмента на знакомой задаче с обычными требованиями.
Записывайте не каждое нажатие, а места, где потребовалось вмешательство: уточнить исходные данные, исправить результат, повторить действие, перенести информацию вручную. Эти наблюдения показывают, какая часть процесса изменилась, а какая осталась у человека.
Если доступ или функция ведут себя иначе, чем ожидалось, сначала проверьте настройки и описание плана. Отделяйте особенности продукта от ошибок подготовки теста. Иначе решение будет основано на разных условиях для старого и нового способа работы.
День третий: попробуйте неудобный случай
После обычной задачи возьмите один пример с усложнением: больше исходных данных, нестандартный формат или дополнительное согласование. Выберите ситуацию, которая встречается в вашей работе, а не искусственное испытание ради рекорда.
Посмотрите, сколько ручной работы осталось и можно ли проверить качество результата. Полезно заранее решить, какие ошибки допустимо исправить, а какие мешают использовать инструмент в этом процессе.
В итоговой заметке достаточно короткого вывода: «Обычный сценарий выполнили; сложный требует такого-то дополнительного шага». Он информативнее общей оценки «сервис понравился», потому что показывает границы применимости.
День четвёртый: проверьте путь результата наружу
Задача редко заканчивается внутри одного приложения. Результат нужно передать коллеге, загрузить в рабочую систему, открыть у клиента или сохранить в согласованном формате. Выполните этот шаг во время теста.
Заодно уточните, какие доступы нужны участникам. Для инструментов с оплатой по местам проверьте, кому требуется платное участие. Например, Figma разделяет типы мест по доступным продуктам; у другого сервиса условия будут своими.
Если пилот заканчивается, заранее выясните, как сохранить нужный результат и что останется доступным после изменения плана. Решение о продлении должно учитывать весь рабочий путь, включая передачу и хранение материалов.
День пятый: оформите решение
Соберите в одном абзаце четыре ответа: какую задачу проверяли, какой результат получили, что осталось делать вручную и при каких условиях продолжаете использование. Затем назначьте следующую дату оценки.
У теста может быть несколько полезных исходов: инструмент подходит для постоянной задачи; подходит для отдельного этапа; требует ещё одной конкретной проверки. В последнем случае назовите недостающий ответ и срок, чтобы тест не превратился в бессрочное ожидание.
Если решили продолжать, поручите покупку определённому человеку и сохраните выбранные условия. Для зарубежных продуктов у Kartli есть инструкции по оплате. Они помогают с платёжной частью после того, как команда определилась с рабочей пользой инструмента.
Алина, PR-менеджер Kartli · kartli.io
