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

Меня зовут Ярослав, я data pre-sale в MWS. За долгие годы работы я совершил массу ошибок и однажды чуть не похоронил проект, потому что послушал заказчика и не поговорил с бухгалтером, которому в итоге предстояло пользоваться продуктом. Оказалось, их боли — две огромные разницы. В итоге я вывел для себя два главных правила:

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

— Твоя главная суперсила — не техстек, а синергия. Умение переводить с языка бизнес-хотелок на язык Python и обратно, а потом и на диалект «бухгалтера Галины Ивановны» — вот что определяет успех твоего проекта. 

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

Что это за зверь — Data Pre-sales

Иногда знакомые меня спрашивают: «Слава, получается, что ты продажник?» Да, но нет. Скорее, я тот, кто мешает продажникам наобещать с три короба, а клиенту — приобрести кота в мешке. 

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

Представьте ситуацию. Приходит заказчик и говорит: «Хочу искусственный интеллект для прогноза продаж». Сейлс-менеджер радостно кивает, потому что видит в этом крупную сделку. Разработчики предвкушают сложную и интересную задачу. И все бы хорошо, но никто не спросил: а какие именно данные есть у заказчика? В каком они состоянии? Кто и как будет этим ИИ пользоваться? И вообще, нужно ли ему машинное обучение или достаточно простой регрессии, а может, просто нужна автоматизация? Вот на этом этапе и появляюсь я.

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

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

Главная ценность Data Pre-sales-специалиста в том, что он разрушает иллюзии на раннем этапе. Пока продажник рисует радужные перспективы, а solution architector, архитектор решений, проектирует идеальную архитектуру, я иду к реальным пользователям и смотрю, как они работают, как решают свои задачи, какая функциональность им нужна. Задаю неудобные вопросы заказчику — например, про качество данных и существующие процессы. И в итоге вместо грандиозного провала через полгода мы получаем небольшой, но работающий прототип уже через две недели и понимаем, в какую сторону двигаться дальше.

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

Главный принцип: make mistake faster

Запомните эту фразу как свое имя: «Чем быстрее ты ошибешься, тем быстрее сделаешь качественный продукт». Кстати, это не моя мудрость, а золотые слова бывшего генерального директора Intel Эндрю Гроува. Ваш враг не ошибка, а боязнь совершить ошибку. И развеивает ее только быстрый прототип и выход к реальному пользователю. 

Вот вам живой пример с таксономией. Заказчик хотел страницу для сопоставления счетов МСФО и РСБУ. Его видение: если бухгалтер ошибся — он создает новую версию таксономии. Звучит логично? Для бизнеса — да. Мы сделали прототип, заказчик сказал «ок».

А потом мы пришли к реальным бухгалтерам. Их реакция: «Вы что, с ума сошли? Создавать новую версию документа на 1000 строк из-за одной ошибки? Нам бы просто кнопочку «отвязать счет» или сделать его неактивным!»

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

Боли, риски и цена ошибки

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

Риски в проектном управлении стандартны, но в пресейле они приобретают космические масштабы, потому что ты работаешь в условиях тотальной неопределенности:

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

• Потеря прибыли — это лишь верхушка айсберга. Компания не просто уходит в минус на одном проекте. Она теряет инвестиции, замороженные в этой разработке, и упускает возможность взять другие, прибыльные заказы. Это системный провал.

• Несчастный клиент — это мертвый клиент. Он не просто не получил то, что хотел. Он получил горький опыт сотрудничества с вами. И он гарантированно уйдет к конкурентам, прихватив с собой истории о том, «как эти ребята все просрали».

Однажды из-за человеческого фактора в бэк-офисe, который «потерял» согласование NDA на два дня, мне пришлось работать три ночи подряд, чтобы в авральном режиме собрать всю тендерную документацию за 24 часа до дедлайна. Почему? Потому что на кону был не просто контракт, а доверие, которое важнее любого, даже самого выгодного проекта. Репутация в B2B — это валюта, которая котируется выше денег.

Инструменты и лайфхаки выживания: как не сойти с ума

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

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

+35-–40% на доработки — это не запас, это вынужденная реальность. Если закладываете ровно 100% времени, вы гарантированно провалите проект. Это аксиома. Эти проценты — не «на всякий случай», а плата за вход в мир, где пользователи всегда хотят не то, что вы предполагали, где API партнера ломается в самый неподходящий момент, а техдолг всплывает в самый неожиданный день.

Железный алгоритм: прототип → заказчик → пользователь. Это священная последовательность, которую нельзя нарушать. Нельзя вносить изменения, исходя только от заказчика (он часто не представляет реальных рабочих процессов). Нельзя показывать сырой прототип пользователям, не предупредив заказчика (это подрывает его авторитет). Вы — проводник. Сначала вы ведете идею к заказчику, потом — доработанный концепт к пользователю, а их общий фидбэк — обратно к команде.

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

Flow идеального пресейла: пошаговая инструкция

Чтобы вы не наступали на те же грабли, вот выжимка моего подхода. Это не голая теория, а отлаженный процесс, который спасает проекты.

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

• Технический аудит. Смотрю, с чем работает клиент сейчас. Какое у него железо, какие БД, есть ли API? Это критично для оценки трудозатрат. Нельзя обещать интеграцию с Kafka, если у клиента все на «1С:Предприятие» образца 2005 года.

• Совещание с архитектором. Вместе переводим бизнес-хотелки в технические требования. Я выступаю переводчиком: «Понимаешь, когда он говорит "надежно", имеет в виду "чтобы Галина Ивановна не звонила мне в выходные", а не five-nines».

• Расчет и оценка. Считаю лицензии, человеко-часы, инфраструктурные затраты. Сюда же закладываю пресловутые +35–40% на доработки. Собираю все в единую смету и делаю план проекта.

• Согласование и прототип. Согласовываю с заказчиком бюджет и сроки. После — сразу бросаю команду на создание минимального, но работающего прототипа. 

• Валидация с пользователем. Это ключевой этап, который многие пропускают. Беру прототип и иду не к тому, кто принимает решения, а к тем, кто будет сидеть в системе по 8 часов в день. Смотрю, куда они тыкают, что их раздражает, что непонятно. 10–20 пользователей дают 90% всей ценной обратной связи.

• Фидбэк-луп и финал. Свожу заказчика и пользователей (или их фидбэк) воедино. «Иван Петрович, бухгалтеры сказали, что ваше требование X им мешает. Предлагаем решение Y». И так по кругу, пока все не придут к консенсусу.

Кто выживает в Data Pre-sales (а кого выносят вперед ногами)

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

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

• Нужно быть технически подкованным, а не «знать слова». Я как инженер уверен: нельзя построить машину, ни разу не побывав за рулем. Вы должны не просто понимать разницу между Apache Spark и Airflow — вы должны чувствовать, сколько человеко-часов съест их настройка под конкретную инфраструктуру клиента. Когда архитектор говорит «нужно переделать ETL-процесс», вы должны понимать, означает ли это два дня работы или два месяца. Без этого вы просто марионетка в руках технических специалистов.

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

Кому здесь точно не место:

• Чистым разработчикам, которые при слове «бюджет» морщатся, как от лимона, а при слове «переговоры» ищут укрытие.

• Чистым менеджерам, которые при вопросах «а сколько времени займет миграция данных?» начинают говорить общие фразы про «оптимизацию процессов».

• Людям, которые ждут четких ТЗ и предсказуемых рабочих дней. Ваш главный план здесь — что планов нет и нужно быть готовым ко всему.

Самые частые ошибки новичков: как мы сами создаем себе проблемы

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

Не бойтесь показать «сырой» продукт, ожидая «идеального» состояния. Это как не показывать черновик книги редактору, пока не написал все 100 глав. К тому времени переписывать будет уже поздно. Make mistake faster! Лучше получить фидбэк «фу, какое гавно» на прототипе, чем услышать это на финальной презентации.

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

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

Выживает тот, кто не останавливается. Нельзя быть «экспертом навсегда». Сегодня ты разбираешься в Trino и DataHub, завтра уже учишься отличать DWH от Data lake или Data lakehouse. Настоящий менеджер постоянно читает статьи, блоги, RFC и чужие постмортемы. Потому что знания здесь стареют быстрее, чем ноутбук. Развитие и самостоятельное изучение технологий — это не опция, а кислород. Если ты перестал учиться, значит, уже отстал.

Закончу текст главным выводом

Data Pre-sales — это не про «впарить», это про то, чтобы быть тем самым «переводчиком» между бизнесом, технарем и пользователем. Быстро нащупать настоящую боль, собрать всех за одним столом и, ошибаясь на ранних этапах, создать продукт, который будет реально решать проблемы. Не бойтесь ошибаться. Бойтесь не услышать того, кто будет пользоваться вашим продуктом.

Если вы хотя бы раз почувствовали кайф от того, что сделали «не идеальный, но живой» продукт, — добро пожаловать в клуб!