Техническая проверка до продажи

Кому подойдёт: новичкам с идеей цифрового или технического продукта и фрилансерам, которые обещают клиентам интеграции, автоматизацию или новый способ выполнения работы. Категории Start и System.

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

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

Выделите критическое предположение

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

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

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

Проверьте условия доступа по актуальной документации

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

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

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

Соберите маленькую проверку полного критического пути

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

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

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

Посмотрите на неудобные случаи

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

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

• Тестовая заявка передаётся без потери обязательных полей.
• Повторная отправка не создаёт лишний заказ.
• Ошибка становится заметна ответственному.

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

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

Переведите технический вывод в коммерческое решение

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

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