Пресейл-инженер: как проверить решение до обещания клиенту

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

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

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

Что именно проверяет пресейл-инженер

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

Затем он сопоставляет требование с доступными средствами продукта. Есть ли готовый интерфейс обмена или понадобится доработка? Совпадают ли форматы идентификаторов, статусов и дат? Можно ли получить тестовые данные и доступ к среде клиента? Кто отвечает за настройку с обеих сторон? Если ответы на эти вопросы отсутствуют, инженер записывает открытые условия, а не подменяет их словом «поддерживается»

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

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

Учебный сценарий: демонстрация, которая скрыла ручную работу

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

Это учебный пример, а не история клиента Кадры+. В исходных условиях у нас нет подтверждения, как статус попал во второе окно. Пресейл-инженер сначала уточнит способ демонстрации: был ли обмен автоматическим, использовали ли подготовленные данные, кто запускал перенос. Затем запросит описание интерфейса учетной программы и пример записей без персональных данных. После этого вместе с техническими владельцами обеих систем проверит один полный путь: создание заказа, передачу, изменение статуса, возврат ответа и обработку ошибки

Контрпример к красивому, но неверному выводу выглядит так. В тесте заказ появляется в учетной программе после ручной выгрузки файла. Это доказывает, что данные можно перенести в выбранном формате. Оно не подтверждает автоматическую передачу и тем более обратное обновление статуса. Если в предложении написать «готовая двусторонняя интеграция», команда внедрения получит обязательство, которого тест не проверял

После такой проверки честный ответ может быть частичным: «Передачу заказа через согласованный файл проверили на тестовом наборе. Автоматический запуск и возврат статуса пока не проверены. Для оценки этих работ нужны описание интерфейса и доступ к тестовой среде учетной программы». Коммерческий руководитель решит, продолжать ли переговоры на этих условиях. Инженер дает ему границу технического обещания

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

Какой результат должен остаться после технической проверки

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

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

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

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

Когда эта роль нужна, а когда причина задержки в другом

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

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

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

Как проверить кандидата на вашей задаче

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

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

Отдельно разберите завершенную ситуацию из опыта кандидата. Не просите раскрывать чужую конфиденциальную документацию. Достаточно услышать, какое требование было спорным, чем подтвердили ответ и как изменилось предложение после проверки. Формула «мы сделали интеграцию» не показывает личного вклада: уточните, что именно кандидат проверил до продажи, а что выполняла команда после договора

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

Что проверить после выхода специалиста

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

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

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

Оставьте заявку на подбор

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

Иван Липорев, директор кадрового агентства Кадры+
Материал подготовлен для работодателей и руководителей