Несколько слов об авторе

Чтобы был понятен контекст, нужно сказать несколько слов об авторе. Я с 2004 года занимаюсь разработкой программного обеспечения, начав с позиции junior java developer'а в аутсорсинговой компании и сейчас занимая позицию CTO в компании-вендоре «Юнидата». По пути застал времена расцвета и заката ODC западных продуктовых компаний в отечественных аутоорс компаниях, частичную переориентацию классических аутсорс компаний на отечественный рынок заказной разработки, эру импортозамещения и прочих этапов развития рынка разработки программного обеспечения (ПО) в России (мне кажется эта тема еще ждет своего историка). Учитывая все это, считаю себя достаточно опытным, чтобы рассуждать о деятельности вендора в B2B сегменте, вместе с тем осознавая ограничение своего опыта рамками определенных сегментов рынка ПО.

О чем и для кого статья

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

Вендор - что же это такое

Вендор - это компания, которая разрабатывает и владеет неким ПО (что не является уникальной характеристикой), и которая продает лицензии на него другим (и это тоже не уникальная характеристика). Уникальным компанию вендора делает именно сочетание разработка ПО + продажа лицензий на использование этого ПО. 

Важно отметить, что, по мнению автора, права на интеллектуальную собственность, в классическом случае, должны принадлежать также вендору. Хотя из этого бывают исключения, когда продукт строится как дериватив от open-source.

Это нехитрое описание приводит нас к тому, что в компании вендоре структурно возникают функции разработки и продаж.

Чтобы что-то продать кому-то, этот кто-то должен узнать о вас. И это приводит к функции маркетинга.

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

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

Кроме этого, ваш продукт(-ы) должен развиваться (конкуренты же не стоят на месте) и в компании появляется функция управления развитием продукта. 

В итоге организационная структура вендора отражает ее функции и похожа на следующую:

• отдел разработки 

• отдел внедрения

• отдел продаж

• отдел поддержки

• отдел управления развитием

• отдел маркетинга

 И это только отделы и функции, непосредственно связанные с разработкой ПО.  

Кто клиент

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

Суммируя, у вендора на самом деле 2 клиента - конечные пользователи и системные интеграторы.  

Становление вендора

Откуда же появляется вендор? Если не брать редкие, но громкие случаи перерастания pet-project в вендора, а говорить об усредненной картине мира enterprise софта, то источника, наверное, три:

• Spin-off системного интегратора. В этом случае интегратор хочет продуктиризироватьсвои проектные решения, наработки и экспертизу, и начать зарабатывать на тиражируемости какого-либо решения. 

• Новый бизнес бывших сотрудников какой-либо продуктовой компании. Это, наверное, самый популярный вариант.

• Шальные деньги инвестора. Этот вариант скорее возможен в эпоху надувания пузырей. 

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

Разработка любого продукта это ДОРОГО: программисты еще на начали писать код, а вы уже платите зарплату. Поэтому, зачастую, цикл продаж начинается до старта разработки.  

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

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

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

И вот только после всего этого вендор начинает не только обслуживать свои затраты, но и получает средства для дальнейшего развития. Развитие может быть разным, но, наверное, наиболее вероятным является переход к линейке продуктов. Линейке, которая позволяет либо расширить продажи на другие сегменты и рынки вашего продукта (речь идет о редакциях и предметных решениях), либо зайти в смежные по тематике области ПО. Эти тенденции отчетливо видны по уже сформировавшимся игрокам, лидерам рынка (но не мега-корпорациям). В 90% случаях продуктовая линейка заходит в смежные области с одной стороны, с другой стороны предлагает специализированные решения, с третей - заигрывает с другими сегментами рынка. 

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

Что же делает вендора вендором

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

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

• Первая продажа — это точка, в которой уже есть и продукт, и клиент. Именно в этот момент кажется, что главное уже свершилось, и самое тяжелое в прошлом. Пора снимать сливки.

• Полноценный вендор - в какой-то мере это венец вендора-стартапа, доказавший свою жизнеспособность. 

Рассмотрим ключевые компетенции каждой функции полноценного вендора и посмотрим на эволюцию с моменты первых продаж:

1) Разработка  

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

• программистов

• тестировщиков

• владельца продукта

• технического писателя и проч.

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

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

2) Внедрение 

Зачастую первыми внедрениями продукта занимается команда разработки. Отдел внедрения крайне минималистичен и представлен в основном аналитиками, инженерный состав внедрения только набирается. Это обусловлено как экономическими факторами (нет возможностей держать скамейку запасных), так и простой необходимостью максимально быстрой обработки обратной связи и доработки продукта по месту. Фактически экспертиза внедрения только появляется путем проб и ошибок. Отдел внедрения только формируется, учится возможностям продукта, закладывает основу экспертизы.  

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

В такой конфигурации отдел внедрения прежде всего отвечает за:

• обучение партнеров, системных интеграторов

• помощь партнерам путем предоставления доступа к экспертам и консультантам высокого уровня

• сопровождение наиболее критичных проектов внедрения

• сбор, анализ и обобщение опыта практических проектов

• разработку и продвижение методологии внедрения и т.д.

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

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

3) Поддержка 

По аналогии с внедрением, на начальном этапе поддержка является скорее дополнительной задачей отдела разработки, а именно подотдела тестирования (речи об отдельной функции обеспечения качества в ее полноте еще не идет). 

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

Основные проблемы с которой начинает сталкиваться отдел:

• Масштабирование, в отличии от внедрения, не может быть осуществлено компаниями-партнерами

• Возникает необходимость поддержки разных продуктов (возможно в разных областях)

• Появляются разные варианты поддержки, варьируются уровни поддержки, SLA и прочее. 

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

4) Продажи 

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

Во-первых, для эффективного осуществления как прямых продаж, так и продаж через каналы компаний-партнеров вендор разрабатывает Sales kit, включающий в себя как маркетинговые материалы, так и различные инструменты продаж, шаблоны договоров, лицензионных соглашений и прочее. Данный пакет должен максимально облегчить задачу продаж партнерам, которые не могут и не хотят вникать во внутренние подробности и детали продуктовой линейки вендора. Один из наиболее критичных и важных аспектов пакета стоит отнести прайс-лист, который не смотря на кажущуюся простоту, следующую из названия, является весьма трудоемким для разработки и должен быть более-менее однозначно трактуем конечными клиентами, партнерами и, конечно, самим вендором. Обычно такой документ сопровождается различными калькуляторами (особенно если прайс-лист имеет количественные характеристики, такие как CPU или объемы хранения и т.д.). 

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

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

5) Управление развитием  

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

• MVP. Источник требований внутренний и отражает базовый функционал для реализации идеи продукта

• Подгонка под клиента. Источник требований - первые клиенты

• Победа над конкурентами. Источник требований - маркетинг и конкуренты

• Планомерное развитие продукта. Источник требований - внутреннее виденье будущего продукта и его развития

• Планомерной развитие продуктовой линейки. Источник требований - внутреннее виденье семейства продуктов

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

Планомерное развитие означает research активности, ведущиеся загодя и с негарантированным результатом. 

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

И конечно, в значительной мере, умение управлять созданием и развитием нового продукта и есть один из самых ценных нематериальных активов вендор, его суперсила. 

6) Маркетинг 

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

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

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

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

• Разработчики. По степени влияния на выбор продуктов, разработчики имеют влияние чуть ли не большее, чем аналитические агентства. Практически любой выбор нового продукта начинается с отбора кандидатов именно разработчиками. 

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

• ВУЗы.Работа с ВУзами призвана решать несколько задач: формирование имиджа наукоемкой компании на рынок; доступ к переднему рубежу науки для практического использования; знакомство с компанией/продуктами будущихit-специалистов, те игра в долгую с разработчиками.

На этом мы пока остановимся, а во второй части «Тернистого пути вендора» я расскажу много интересного о правде и вымысле о работе вендора, вскрыв много маленьких темных секретов. До встречи!

Руслан Трачук

технический директор компании "Юнидата"