Начну с небольшой истории. Мы в течение нескольких лет делаем продукт для улучшения процессов управления инцидентами и мониторинга в крупных корпоративных ИТ инфраструктурах. Им уже пользуются десятки компаний и тысячи человек. У нас было несколько подходов к выстраиванию продаж и маркетинга. Первые три раза были безуспешными. Мы тратили деньги и тут же их теряли. Основной проблемой была коммуникация. Мы не могли доходчиво описать ценность продукта обычным инженерам. Потом мы выстроили работу с инженерами, дали им бесплатную версию, но у нас начались проблемы в недопонимании со стороны директоров. Оказалось, что бизнес и инженеры говорят на разных языках.
Продажи - это про коммуникацию. Мы несколько лет продавали напрямую без сайта, без баннеров, без рассылок, без всей той мишуры, которую так не любят инженеры, но любят маркетинговые агентства. Я или мой партнер приходили к заказчику, к архитектору или к руководителю службы поддержки, слушали его и предлагали решение. Вообще это самый лучший подход в продажах - сначала слушать, а потом предлагать. Но это похоже на индивидуальный пошив одежды: красиво, качественно, но дорого и долго (кстати, на рынке это зачастую называется заказная разработка, но мы изначально делали продукт). Но так были совершены первые продажи.
Понимая (как мы тогда считали) ценность продукта, мы решили, что он полностью готов к выходу на массовый рынок, в том числе международный. Ногами дойти до каждого заказчика в мире невозможно, поэтому нам пришлось изменить тактику. Сделали сайт, красивые презентации, направили письма во все крупные корпорации, обошли всех крупных интеграторов, провели серию ивентов, получили ряд наград, прошли несколько акселераторов и т.д.
На встречах с бизнесом мы показывали красивые картинки наподобиe этой:
Мы рассказывали про важность AIOps, Data Observability, про экономию денег, про риски, про новые возможности заработка для организации. Говорили на языке бизнеса, и ответственные за ИТ нас хорошо понимали, но все рушилось на этапе технической проверки.
Технари восклицали, “зачем им еще один Zabbix”, даже не погружаясь в продукт, так как наше позиционирование в трёх словах не давало им ни малейшего представления том, кто мы такие. А копать глубже после этих трех слов не было ни малейшего желания, так как работы и так всегда хватает.
В течение года мы стали переориентироваться на инженеров. Начали писать статьи на Хабре, запустили свой канал в Telegram, где никакого маркетинга, только новости разработки, запустили свое Telegram комьюнити, подняли форум на Discourse и, конечно же, сделали бесплатную версию продукта. На встречах перестали говорить “умные” слова, перешли на технические термины а-ля корреляция событий, избавление от шторма алертов, SLA, SLO, экстракция логов, ETL процесс и т.д. Начали активно сравнивать себя с Graylog, Splunk, Microfocus, Broadcom, ELK, Grafana и т.д. В результате мы подружились с инженерами, но нас потерял бизнес. Каждое техническое ревью заканчивалось успехом, но бизнес стал не понимать, за что платить деньги, и воспринимал нас еще одним инструментом для ИТ.
Мы постепенно начали определять позиционирование Monq, понятное инженерам:
Шло время и постепенно мы наладили коммуникацию и с бизнесом, и с ИТ, у нас появились отдельные презентации, отдельные ответственные люди и выстроился процесс продаж (недеюсь, это опыт, а не процесс ипортозамещения). Мы пришли к выводу, что продажа - это также коммуникация с двух сторон: со стороны бизнеса, где надо объяснить бизнес-ценность в разрезе стратегии, и со стороны технической команды, которой надо показать, где мы будем полезны здесь и сейчас. А отправной точкой для нас стало понимание, что бизнес и ИТ говорит на разных языках.
Примедем пример и представим наши выводы в таблице. Сразу сделаем оговорку, что она не покрывает 100% всех случаев и базируется исключительно на опыте общения с некоторыми персонами на рынке корпоративного ИТ (за скобками оставим безопасность, там отдельный мир). Данная таблица появилась после серии проблемных интервью, проводимых в 2022 году среди российских компаний и подразделений, ответственных за мониторинг и эксплуатацию.
Инженеры | Бизнес | |
В каком времени живут | В настоящем. У инженеров есть технические задачи, которые надо выполнять здесь и сейчас. | В будущем, если говорим о стратегии, рисках и выборе решений, или в прошлом, если идет разбор аварий и оценка SLA. |
Цели | Расширение собственных технических компетенций, увеличение зарплаты, интересные задачи, больше свободного времени, меньше изменений, сужение зоны ответственности. | Выполнение собственных KPI, продвижение по карьерной лестнице внутри компании, увеличение бюджета под управлением, расширение ответственности. |
Задачи | Разработка, эксплуатация ИТ сервисов, решение инцидентов и проблем, выполнение регламентных и плановых работ, аналитика и отчетность. | Сокращение затрат (в том числе убытков по вине сбоев), увеличение выручки, увеличение эффективности инвестиций в ИТ, бюджетное планирование, поиск новых направлений коммерциализации, снижение рисков, повышение производительности труда персонала. |
На выбор чего влияют | Технологии. | Бизнес-процессы, бюджет, оргструктура. |
Объект управления | Приложения, оборудование, сети и вычислительные ресурсы. | Проекты, сервисы и услуги. |
Внимание на | Метрики, журналы, трейсы, события. | Надежность, доступность, производительность, безопасность. |
Как мы видим, различий очень много, поэтому чаще всего между бизнесом и инженерами возникает недопонимание. Если вы хотите быть успешным руководителем или блестящим специалистом, то вам придется выучить язык общей коммуникации.
Вот ещё одна иллюстрация на нашем профессиональном примере понимания процессов мониторинга. Так строится коммуникация между бизнесом и инженерами. Ведь мониторинг должен быть един. Не должно возникать ситуаций, когда инженер и бизнес смотрят в разные, никак не связанные системы.
А у вас есть примеры из вашей сферы? Поделитесь в комментариях.