Термин пресейл стал активно использоваться в СНГ лишь в последние годы. Если верить Google Trends, устойчивый интерес к теме начался с 2013 года, а пик роста пришёлся после 2022-го. Это наглядно показывает: роль пресейла как отдельной профессии в нашем регионе сравнительно новая. Разумеется, подобная функция существовала и раньше, просто называлась иначе — инженер по работе с заказчиками, техподдержка пресейла, архитектор решений и т.д. Но тогда это было скорее спонтанное распределение обязанностей, а не системный подход. Сегодня ситуация всё ещё далека от стандартизации: в разных компаниях от пресейла ожидают разного, и это сильно затрудняет вход в профессию и её развитие.

В большинстве IT-ролей существует понятная система грейдов: junior, middle, senior. Пресейл же часто оказывается "вне шкалы": должность вроде бы есть, но чёткой модели развития — нет. Как специалист с практическим опытом в пресейле, я часто сталкивался с отсутствием понимания, куда можно и нужно развиваться. Поэтому решил структурировать собственный подход к градации пресейлов в ИТ, взяв за основу типовую трёхступенчатую модель.

Собственно, эта статья — не готовый рецепт, а скорее продолжение размышлений, начатых в моей статье на Хабре. Я хочу развить предложенную там градацию пресейлов и пригласить других специалистов к обсуждению. Изобретать велосипед не стану — в качестве основы возьму привычную ИТ-градацию, но наполнять её буду через призму своего опыта.

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

Второй момент — KPI плохо конвертируются в релевантный опыт. Ни количество активностей, ни число клиентов, ни даже выполнение плана продаж (личного или совместного с сейлами) не дают чёткого понимания уровня специалиста. Слишком многое зависит от внутренней кухни компании, её процессов и того, какие задачи решает конкретный пресейл.

Ну и третье — неоднородность требуемых навыков. Возьмём пример: переход из резервного копирования в AppSec. Знание типов сетевых хранилищ может оказаться совершенно не нужным. А вот если переходить из той же области в видеонаблюдение — эти знания могут оказаться весьма ценными.

Уместить все описание градаций в одну статью не получилось, так что описания в отдельный статьях: Junior - https://set.ki/post/E2qvHYC Middle - https://set.ki/post/Si5eyMh Senior - https://set.ki/post/HBFR9xT