Привет, Хабр! На связи Владислав Пермяков, ведущий пресейл-инженер К2 Кибербезопасность.

Давайте честно: в картине мира среднестатистического инженера любой человек с приставкой Sale скорее вызывает легкое раздражение, чем симпатию. Не потому, что «сейлы плохие», а потому, что красивая коммерческая идея слишком часто не выдерживает столкновения с реальностью. Вот, например, приходит радостный сейл, кладет на стол подписанный контракт со словами: «Мы продали им весь наш портфель!» Ты открываешь спецификацию, смотришь на инфраструктуру заказчика и понимаешь, что такие костыли не взлетят. Устаревший парк серверов, каналы связи не потянут трафик, а совместимость с легаси-софтом никто не проверял. Но сейл уже оформляет новую сделку, а тебе нужно заставить работать решение, которое технически не подходит под задачи клиента.

Качество внедрения и жизнь инженеров во многом зависят от того, о чем договорились на этапе продажи. В какой-то момент я захотел взять это под контроль, и внезапно оказался на «темной стороне» — стал пресейл-инженером и собрал целый отдел таких же отступников.

Чем занимается пресейл-инженер

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

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

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

На самом деле 70% пресейла в нашей сфере — чистая инженерия и архитектура. Чтобы быть эффективным на этой позиции, нужно знать рынок ИБ во всем его разнообразии. В одном только нашем портфеле больше 200 продуктов, и все их нужно знать на уровне архитектурных особенностей. Чистый «продажник» просто не запомнит нюансы совместимости. Только человек, который сам щупал эти коробки руками, сможет рассказать, что скрывается за обещаниями вендора. Поэтому хорошо, когда в пресейл переходят из инженеров-внедренцев: опыт реальных проектов позволяет детально прорабатывать трудозатраты и чувствовать нюансы, которые невозможно вычитать ни в одном даташите.

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

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

Со стороны кажется, что пресейл — одна большая встреча с заказчиком, но на самом деле эту работу можно разделить на 8 шагов.

Нулевой этап — квалификация запроса. Сейл самостоятельно оценивает, насколько реальна сделка, есть ли бюджет, совпадает ли профиль заказчика с нашими компетенциями. Квалификация пройдена. Что дальше?

1. Если лид подходящий, начинается сбор исходных данных. Сейл может прийти с конкурсной документацией, техническим заданием на 200 страниц, а может, с сообщением в Telegram из серии «клиент хочет что-то про файрволы, бюджет уточню». Входные данные почти никогда не бывают полными, поэтому первая задача пресейл-инженера — структурировать разрозненную информацию. У нас для этого есть опросники по каждому типу решений, они помогают не упустить критичные вводные вроде бюджета, сроков, текущей архитектуры и особенностей инфраструктуры.

2. Дальше — первичный анализ. Пресейл-инженер определяет, какие типы решений участвуют в проекте, оценивает, что может отработать сам, а где потребуется подключить инженеров из профильных практик или архитектора. Если проект комплексный (больше двух-трех решений разных вендоров или сложная архитектура), то без архитектора не обойтись. Важно знать свою команду и смежные подразделения: в комплексном проекте пресейл-инженер должен понимать, кого из коллег подключать.

3. Затем проходит внутренняя встреча команды: сверяем понимание задачи, распределяем роли и готовим вопросы для заказчика.

4. После идет встреча с заказчиком, на которой собираем недостающие вводные.

5. На основе собранной информации мы готовим спецификации и оцениваем трудозатраты (об этом подробнее ниже).

6. Все собирается в единый пакет, после чего сейл оформляет коммерческое предложение.

7. Следом проводим защиту КП перед заказчиком.

8. Иногда после защиты КП мы готовим концептуальный дизайн целевого проекта: прорабатываем архитектуру, описываем целевое состояние и требования к реализации. Это существенно повышает шансы на победу в конкурсе.

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

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

Документы, на которых все держится

Вся наша методология держится на двух документах:

Спецификация (BOM, Bill of Materials) — список всего оборудования, материалов и лицензий.

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

Калькулятор трудозатрат (ТРЗ) — таблицы с формулами, где расписан каждый шаг работ по принципу: развертывание виртуалки — 2 часа, написание политики безопасности — еще 4 часа.

Каждое решение сопровождается отдельным файлом ТРЗ. Мы используем шаблоны из базы знаний, но часы в них усредненные, и для каждого проекта их необходимо пересматривать.

Классические этапы внедрения: обследование, проектирование, пуско-наладочные работы, опытная эксплуатация и приемо-сдаточные испытания. И у каждого этапа должен быть закрывающий документ. Мы закладываем часы и мидла, и ведущего инженера (обычно в пропорции 70/30, но зависит от сложности), а также учитываем место проведения работ на каждом этапе: например, обследование проводится очно, а проектирование, как правило, удаленно.

Отдельная история — условия и ограничения. Если в ТРЗ указана работа «создание правил межсетевого экранирования» без оговорки «не более 50 правил», заказчик вправе требовать любое количество. Поэтому мы не только фиксируем ограничения в расчете трудозатрат, но и следим, чтобы они попали в коммерческое предложение и техническое задание к договору. Это защищает обе стороны: каждый одинаково понимает объем работ.

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

Проводим диагностику

Клиенты регулярно путают «боль» (проблему) и «таблетку» (решение) и приходят к нам с готовым диагнозом. Приходится включать режим доктора Хауса и выяснять, где на самом деле болит.

Чтобы вы понимали, о чем я, вот кейс из практики. Приходит крупный заказчик с конкретным запросом: «Нам нужна система предотвращения вторжений (IPS), отдельная железка». Плохой сейл в такой ситуации найдет и продаст самую дорогую коробку. Инженер же в такой ситуации начнет копать.

«А что у вас сейчас стоит на периметре? Какой NGFW используете?» Оказывается, у них мощный кластер NGFW от топового вендора, и тут самое интересное: «А вы в курсе, что IPS у вас уже есть? Просто не активирован лицензией или выключен в политиках, чтобы не грузить CPU». В результате вместо новой железки за 5 миллионов мы продаем лицензию на активацию IPS-блейда и тюнинг сигнатур, чтобы не резали легитимный трафик. Минус 90% бюджета на железо, плюс заказчик, который регулярно возвращается с новыми задачами.

Считаем трудозатраты

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

Отдельная история — различия в подходах к документации. Молодые коммерческие компании обычно запрашивают утилитарную проектную документацию, тогда как в государственных структурах гораздо более широкие требования к составу, форме и содержанию документов. Это напрямую влияет на трудозатраты. И, наконец, у каждого заказчика своя уникальная инфраструктура и свои особенности, поэтому расчет ТРЗ будет уникален.

Другой неочевидный момент — скрытые работы. Новички часто забывают посчитать время на дорогу (объект в промзоне за городом означает минус 4 часа рабочего времени инженера на дорогу), аудит (прежде чем ставить новое, надо понять, как работает старое) и тому подобное.

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

А иногда бывает и так, что на старте просто невозможно оценить точный объем работ. У нас был заказчик, у которого одним днем уволилась вся ИТ-команда, хлопнув дверью и даже не передав доступы. Нужно было внедрять NGFW, но был риск сломать механизм публикации сервисов, а схемы сети просто не было. Фактически мы работали в формате black box: обследовали все бизнес-процессы с нуля, выявляли, какой трафик легитимный, а какой нет, и только после этого формировали политики безопасности. Тот кейс был тяжелым, так как всплывало слишком много подводных камней, но заказчика вытащили.

Стартуем пилот

Пилот — тоже далеко не безобидная прогулка. Вот, допустим, заказчик сомневается: «А ваша система DLP точно не положит нашу сеть? Давайте попробуем». Мы берем пилотный стенд с умеренными ресурсами, заводим туда 10 пользователей из тестовой группы, и все отлично работает. И тут заказчик, опьяненный успехом, предлагает сразу раскатить наше решение на весь завод. Железка же стоит, лицензия еще месяц действует. Чего тянуть?

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

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

Математика и ретроспектива

В продажах есть опасная иллюзия: как только договор подписан, работа считается выполненной. Для пресейл-инженера это далеко не конец. Мы называем это ретроспективным анализом (Plan vs Fact). Допустим, я посчитал проект внедрения VPN на 40 часов, а по факту получилось 120. Проект сдан, заказчик доволен, но для компании этот проект убыточен.

Мы собираемся командой и начинаем расследование. Вариантов обычно три:

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

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

3. Форс-мажор или брак оборудования — эти риски должны быть учтены в договоре.

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

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

Что должен уметь пресейл-инженер

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

Работа с заказчиком

• Выявление и уточнение потребностей заказчика.

• Общение с техническими специалистами заказчика, проведение презентаций и демо.

• Защита технического решения перед заказчиком.

• Работа с up-sale и cross-sale: заказчик не всегда озвучивает или знает все свои боли.

Проектирование и расчеты

• Подбор оборудования, лицензий и модулей поддержки (формирование спецификации).

• Декомпозиция работ и расчет трудозатрат.

• Подготовка технической части коммерческого предложения и описания работ.

• Подготовка технического задания и/или концепции.

Пилоты и демо

• Организация и проведение пилотных тестирований.

• Подготовка демостендов для презентации решений.

• Подготовка пилотной документации: регламент, ПМИ, отчет, финансовое обоснование.

Коммуникации и координация

• Технические переговоры с вендорами.

• Выстраивание отношений с дистрибьюторами и вендорами для организации пилотов.

• Координация команды пресейла: распределение задач, сбор результатов.

• Подключение коллег из смежных департаментов в комплексных проектах.

Аналитика и развитие

• Ретроспективный анализ «план/факт» по трудозатратам.

• Отслеживание конверсии и работа с воронкой продаж.

• Наполнение базы знаний пресейла: артефакты, кейсы, шаблоны.

• Актуализация экспертизы: встречи с вендорами, конференции, мониторинг угроз.

• Генерация идей: новые «коробочные» предложения, комплексные наборы решений.

• Продвижение услуг на внешних площадках: выступления, статьи, мероприятия.

Заключение

Жалею ли я, что повесил консольный кабель на гвоздь? Нет. Уход в технический пресейл – это не потеря квалификации, более правильным словом будет конвертация. Ты меняешь глубину знания одной технологии на широту взгляда на весь рынок и на возможность влиять на архитектуру еще до того, как будет закручен первый винт в стойку. Этот переход означает, что за каждой железкой ты начинаешь видеть бизнес-процесс, за каждой лицензией — чью-то боль, а за каждой строчкой спецификации — будущие бессонные ночи (или их отсутствие) у команды внедрения.

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

1. Стало тесно в рамках одной технологии? Настраивать NGFW в сотый раз надоело. Хочется понять, как он вписывается в экосистему: защита контейнеров, интеграция с песочницей, причины выбора именно этого вендора.

2. Хочется видеть Big Picture? Раздражает, когда приносят кусок задачи («пробрось VLAN») без контекста. Тянет рисовать схемы от ядра сети до конечных точек.

3. Нравится переводить с «технического» на «человеческий»? Объяснять заказчику, почему ему не нужна отдельная железка, — не пытка, а удовольствие.

4. Готовы сменить CLI на Excel? Спецификация для успеха проекта важнее идеально написанного скрипта. Если эта мысль не вызывает физическую боль, вы на верном пути.

5. Замечаете, чего не хватает? Заказчик пришел за файрволом, а вы уже думаете: «А у них почтовый трафик вообще фильтруется? А контейнеры кто защищает?» Умение видеть потребности, которые заказчик еще не осознал, хорошо конвертируется в up-sale и cross-sale.

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