Материал команды AVLeads для владельцев мобильных продуктов. Предлагаем порядок подготовки задач к доработке. Ситуация с адресом заказа ниже — учебный пример, а не история реального клиентского инцидента.
В одном списке обычно оказываются дефекты, пожелания и вопросы о правилах продукта. Их полезно различать ещё до обсуждения стоимости.
Дефект: клиент сохранил новый адрес и получил подтверждение, однако исполнитель видит прежний. Если согласованное правило требует обновления у обеих сторон, поведение ему не соответствует.
Новая функция: адрес передаётся правильно, но теперь бизнес хочет выбирать подъезд на карте и добавлять комментарий водителю. Это новые требования, даже если в переписке задача называется «исправить адрес».
Открытый вопрос: можно ли менять адрес после принятия заказа? Кто должен подтвердить изменение? Пока владелец продукта не определил правило, разработчик не сможет проверить, что реализовал нужный результат.
Сохраните исходное сообщение пользователя, а рядом запишите уточнённую задачу. Если в ней несколько разных результатов, разделите их. Это помогает обсуждать границы работ и не потерять проблему человека за деталями интерфейса.
Для первого разговора достаточно наблюдений. Не нужно заранее решать, что виноваты сервер, уведомления или кэш: одинаковый симптом может возникнуть по разным причинам.
В карточку ошибки включите версию приложения, модель устройства, версию операционной системы, роль пользователя, исходное состояние, шаги, фактический и ожидаемый результат. Запись экрана и время проверки помогают сопоставить действия с журналами событий.
Учебная карточка ошибки
Если сбой возникает нерегулярно, укажите, сколько попыток было и чем отличались условия. Формулировка «не удалось повторить за пять проверок» точнее, чем вывод «ошибки нет». Используйте тестовые записи; реальные телефоны, адреса и платёжные данные не нужны в открытом обсуждении.
Чтобы выбрать приоритет, выясните, какое действие невозможно завершить, кого затрагивает ошибка и есть ли рабочий временный способ продолжить. Частоту обращений учитывайте вместе с последствиями: редкая потеря заказа может быть существеннее заметного неудобства интерфейса.
Для небольшого списка хватит трёх групп: проблемы, блокирующие основной сценарий; важные дефекты с временным обходом; улучшения. Рядом с задачей запишите обоснование. «Исполнитель едет по неверному адресу» сообщает больше, чем метка «срочно».
Отдельно укажите зависимости. Если данных недостаточно, первым действием может стать дополнительная диагностика. Её результат — информация, которая позволит выбрать исправление, а не обещание немедленно устранить любой сбой.
До сметы проверьте, можно ли собрать приложение из переданного кода, есть ли тестовая среда и доступна ли нужная серверная часть. Скриншоты показывают симптом, но не состояние проекта.
При разборе попросите разделить три вещи: что удалось воспроизвести, какая причина подтверждена и какие предположения ещё проверяются. В учебной ситуации экран мог не запросить новый адрес, сервер мог отклонить изменение, а интерфейс — преждевременно показать успех. По одному скриншоту выбрать причину нельзя.
Смета должна объяснять состав результата. Для задачи с адресом это могут быть диагностика, изменения в приложении или сервере, проверка двух ролей, подготовка сборки и выпуск. Не каждой задаче нужны все эти части; важно понимать, какие входят в предложение.
Вместо общей строки «исправить адрес» полезнее зафиксировать: «при разрешённом изменении сохранять новый адрес, показывать его клиенту и исполнителю, корректно обрабатывать отказ и потерю связи». Рядом перечислите то, что в этот этап не входит, например новый экран выбора подъезда.
Если причина ещё неизвестна, согласуйте ограниченный этап диагностики: доступные данные, объём проверки, срок обсуждения результатов и момент остановки для согласования продолжения. Итогом должны стать выводы и следующий план. Оценку исправления уточняют по этим выводам.
Сравнивайте предложения по одинаковому составу. Изменение одного экрана и переработка серверного сценария не становятся сопоставимыми только потому, что оба названы доработкой мобильного приложения.
Критерий «теперь работает» оставляет слишком много толкований. Опишите наблюдаемое поведение: кто выполняет действие, при каких условиях и что получает. В учебном примере стоит проверить следующие ситуации.
Проверки соседних функций выбирают по затронутым частям системы. Если менялся общий механизм сохранения, одного успешного открытия экрана недостаточно. Если изменение локальное, полный повтор всех проверок приложения может быть избыточным.
Назовите конкретные устройства и поддерживаемые версии для приёмки. «На всех телефонах» не задаёт проверяемого объёма. Для каждого сценария сохраните номер сборки, условия, результат и статус: пройдено, не пройдено или не проверено. Непроверенный пункт остаётся открытым.
До обновления определите, кто принимает тестовую сборку, разрешает выпуск и следит за продуктом после него. Обсудите признаки, при которых нужно остановить дальнейшее распространение или ограничить проблемную функцию.
Если магазин поддерживает поэтапный выпуск, можно начать с части аудитории. Например, в Google Play остановка поэтапного внедрения прекращает дальнейшее распространение обновления, но уже получившие его пользователи продолжают им пользоваться. Автоматического возврата к прежней версии при такой остановке не происходит.
Поэтому план должен учитывать уже обновившихся пользователей: исправляющую сборку, предусмотренное архитектурой отключение функции или другое доступное решение. Если меняются сервер и формат данных, отдельно проверьте совместимость со старыми установленными версиями.
После выпуска наблюдайте за самим исправленным действием: сохраняется ли адрес, завершается ли заказ, совпадают ли данные у ролей. Отсутствие аварийных закрытий приложения само по себе не подтверждает правильность бизнес-сценария.
Подготовьте ссылку на приложение, три наиболее важные проблемы, шаги воспроизведения и желаемый результат. Добавьте известные ограничения: доступность исходников, сборки и тестовой среды. Этого достаточно, чтобы определить следующий этап без попытки угадать техническую причину.
На странице доработки приложений AVLeads описан порядок первичного разбора, оценки и согласования работ. Стоимость отдельного исправления определяют после изучения проекта и объёма изменений.
Для каждой согласованной задачи должны быть понятны изменение для пользователя, способ проверки и человек, который принимает решение о выпуске. Тогда смета и приёмка описывают один и тот же результат.