Сегодня – никаких сказок. Только факты, цифры и кейсы. Про продажи глазами и руками программиста. Точнее, с применением подходов из программирования. Лично мне кажется, что эти подходы суть – здравый смысл. Странно, что не все так делают. И интересно, согласитесь ли вы с этим после прочтения.
На всякий случай представлюсь: я руковожу командой программистов. Моя цель – набирать их, учить, обеспечивать интересной работой, как-то веселить и удерживать. Да, ещё я много программирую – люблю.
Но бизнес хочет, чтобы мы ещё и деньги приносили. Точнее, он примерно именно этого и хочет – это же бизнес. А как это будет сделано – не так важно, если в границах приемлемого. Можно людей набирать, стоимость услуг повышать, эффективность ковырять и т.д.
Поэтому приходится заниматься ещё и деньгами. Соответственно – продажами. Из дальнейшего изложения станет понятно, почему – это я предваряю возражение «менеджеры же есть, пусть они продают».
Есть менеджеры, их много. Но с ними хуже.
Цифры
Для начала цифры. На начало 20 года у меня было 10 человек, на конец – 13. Год был пандемийный, не до набора людей. Основной прирост случился в конце года, после возвращения в офис.
На конец 21 года у меня было 12 человек – очевидно, что целый год я по людям не рос. Но по деньгам мы прибавили вдвое. Понятно, что не за счёт масштабирования.
Сейчас, на начало 4 квартала 22 года, у меня 24 человека – нетрудно догадаться, чем я занимался 9 месяцев. По деньгам полный год рано сравнивать, но три квартала – вдвое больше аналогичного периода 21 года. И тренд – на дальнейший рост.
Итак, на второй год доход удвоился без увеличения количества программистов. В третий год доход удвоился вслед за количеством программистов. Примерно понятно, что рычаги были разные, дальше расскажу, какие именно.
Цифры я привёл не для того, чтобы похвастаться – все мы, вы, они, кто в IT, давно и стабильно растут. Цифры для того, чтобы, читая кейсы, вы понимали их влияние на результат. А то знаете, как бывает – целую книжку напишут, как всё перестроить, а в итоге продажи растут на 2%, и это ещё называется «результатом».
Моя цель в продажах
Проясню свою цель в продажах. Она – как у итальянской мамы или курицы-наседки: продать ровно столько задач, сколько может выполнить команда. Меньше – плохо, кто-то будет простаивать. Больше – совсем плохо, плывёт качество, затягиваются сроки, начинаются переработки, падает настроение.
Цели «продавать по максимуму» не было, нет и, надеюсь, не будет. Но расти по деньгам надо, да. Но не за счёт избыточных продаж.
Исходная ситуация
В конце 19 года ситуация была следующая. С нами работали 10-15 менеджеров по продажам услуг программистов. За каждым были закреплены какие-то клиенты, которые присылали свои задачи – тем самым менеджерам.
По каждой задаче надо было посмотреть, проанализировать, дать оценку в деньгах, поспорить, убедить, подвинуться, сделать, попытаться сдать, доказать, переделать, ещё раз попытаться, наконец сдать, в конце месяца опять доказать, поругаться, подписать бумажки.
Ещё иногда требовалось участие опытного программиста в пресейле (предпродажа) – съездить на встречу, ответить на вопросы, показать себя, создать приятное впечатление.
Жутковато, согласитесь. Пройдёмся по точкам процесса, где программист вынужденно участвовал в продажах.
Точки участия в продажах
Ранжировать не буду, перечислю в произвольном порядке.
Первая – участие в пресейлах. Тут нужен был лично я – надо вставать, ехать, трындеть. С учётом дороги теряется полдня. Ну или по видеосвязи болтать, переписываться по почте, созваниваться и т.д. Как правило, в несколько итераций – их количество зависит от организаторских способностей менеджера.
Вторая – оценка каждой задачи. Это тоже продажа – надо не просто назвать цифру, а что-то наплести, аргументировать, объяснить. Иногда времени уходило больше, чем на пресейл.
Третья – сдача работы. Тоже продажа, по временным затратам – хуже, чем оценка.
Четвёртая – подписать бумажки по итогам месяца. Увы, к этому моменту клиент не помнит (или «не помнит») ни задачу, ни договорённости по оценке, ни фамилию программиста. Чаще всего бывало, что задачу ставит один человек, а бумажки подписывает другой.
Если суммировать затраты времени программистов, включая меня, на эти «продажи», то получалось до 40 %. Менеджеры ничем помочь не могли, именно в этих точках. Свою роль они выполняли, но тут нужен был именно программист. Ну, или «нужен».
Принципы программиста
Чтобы больше не возвращаться к этому вопросу, сразу обозначу принципы, которые я использовал для изменения продаж. У программистов этого добра навалом, но я выделил следующие:
Повторное использование;
Не плоди сущности без нужды;
Комментируй.
Дальше расскажу, как устранял, менял, перекраивал перечисленные выше точки «продаж» с помощью принципов программиста. На это ушёл весь 21 год.
Количество менеджеров
Первое, что попало под раздачу – количество менеджеров. Этих сущностей, как мне показалось, слишком много. Кто и зачем их наплодил в таком количестве – не знаю.
Похоже, знаете, на лоскутную автоматизацию – был такой термин в нулевых. Это когда на заводе используется штук 5-10 разных программ, в каждом отделе – своя. В одной зарплату считают, в другой – производственный план, в третьей – накладные выписывают и т.д. Да все – на разных языках написаны. Что-то развивать в таких условиях невозможно, только и будешь бегать и данные переносить. Коммуницировать, короче.
А каждый менеджер – он же человек, со своими тараканами. С одним можно договориться о каких-то правилах, с другим – никак, он половину твоих слов не понимает. Плюс – менеджеры живут в другом отделе, со своим начальником.
В результате менеджеры существенно увеличивают и без того огромное время, которое мы тратили на ненужное общение с клиентами. Надо же и тому, и другому всё объяснять.
Когда у программиста слишком много сущностей, выполняющих одну и ту же функцию, надо эту орду сокращать. Что мы и сделали – постепенно уменьшили количество менеджеров с 10-15 до 1-3.
Потери были, но небольшие и локальные, их быстро удалось купировать. Оказалось, менеджер скорее мешает в общении с клиентом, чем помогает. Всю содержательную часть коммуникаций как выполнял программист, так и продолжил выполнять.
Сдача работ через нарративы
Дальше по списку была сдача работ – это когда по итогам месяца надо подписать бумажку, что такие-то задачи были решены, и стоило это столько-то денег. Проблемы этого процесса описал выше – заказывает работу один, бумажки подписывает другой, и иди ему докажи, что 6 часов потратил на «устранение ошибки при запуске системы» или «разработку отчёта по прогнозируемым остаткам».
Тут пригодился мой опыт написания статей и выдумывания историй – нарративов. У любой задачи есть начало (исходная проблема) и конец (исходная проблема решена). Обычно в описании работ программист указывал лишь конец. Согласитесь, читать такие нарративы скучновато – попробуйте прочитать эпилог «Доктора Живаго» и понять, о чём была книга.
Научил программистов писать несложные нарративы про задачи. Просто текстом – исходная проблемы была такая-то, подозрения были на вот это, проверил такие-то 8 гипотез, по дороге написал 2 страницы кода для такой-то обработки данных, в результате сработал вариант № 9, в пути обнаружил такую-то проблему в коде, рассказал заказчику, тот испугался и согласился устранить, я сделал, в итоге всё хорошо, задача решена.
Понятно, что Пулитцеровскую за такой рассказ не дадут, но вопросы «а чё вообще делали и почему столько стоит?» свелись к единичным случаям, хотя раньше были массовыми. Сэкономились примерно 2-3 дня в начале каждого месяца.
Тут, конечно, немного сову на глобус, но очень похоже на принцип комментирования кода. Просто заказчик код не читает, и комментарии предоставляются отдельно.
Доверие
Дальше была проблема «продажи» на старте каждой задачи – надо проанализировать, дать оценку, согласовать – отнимает много времени и весьма выматывает. К тому же, точность предварительных оценок в программировании всегда рьяно стремилась к нулю.
Чутка подумав, поняли, что у каждой задачи есть странный жизненный цикл. Перед тем, как ты начинаешь программировать, надо завоевать доверие клиента. Что-то ему объяснить, доказать, ответить на вопросы, смоделировать и т.д. Оно неплохо и правильно, доверие должно быть, но обратите внимание – его надо завоёвывать каждый раз, на каждой задаче. Много раз в месяц.
С моей, программистской точки зрения это всё равно, что каждый день писать код, который разрешит тебе писать код. Нужно было повторное использование завоёванного доверия.
Оказалось, это несложно, нужны всего два кейса.
Первый – личное знакомство с клиентом, всего один раз. Записались с менеджером на встречу, съездили, пару часов потрындели, познакомились. Клиент тебя увидел, запомнил, «купил». И дальше доверяет.
Второй – штурм. Это своего рода дефибрилляция доверия. Иногда надо решать задачи так быстро и качественно, чтобы клиент аж вздрогнул. В этот момент он вспоминает личное знакомство и своё доверие. Штурмовать достаточно раз в 3-6 месяцев.
После внедрения принципа повторного использования доверия мы практически не даём предварительных оценок. Пришла задача – просто садимся делать, или общаемся по существу.
Постоянные клиенты
Развивая принципы доверия и его повторного использования, решили работать только с постоянными клиентами. Ровно для того, чтобы «программировать» доверие пореже.
Для начала немного прочистили клиентскую базу, передав в другой отдел редко обращающихся клиентов – там просто нет инфоповодов для создания и дефибрилляции доверия. Оставили только постоянных.
А дальше перекроили слова, которые говорим на первой встрече. Раньше продавали компанию, бренд, свою экспертизу. Сейчас продаём постоянное избавление от проблем с сопровождением и развитием. Ну т.е. сразу обозначаем, что играем только в долгую. Клиентам почему-то это нравится.
По сути, работа с постоянными клиентами – усиление и расширение действия принципа повторного использования из предыдущего пункта. Речь уже не только о доверии, но и о вполне приземлённых вещах – например, знакомая инфраструктура, бизнес, процессы, ЛПР и т.д.
Всё это можно и нужно «осваивать» один раз и использовать повторно.
Письменные нарративы
Оставался ещё один поток работы, отнимавший много моего личного времени – переписка с потенциальными клиентами, с которыми слишком затратно встречаться лично. Видеосвязь я не люблю – соображаю медленно, всегда нужно несколько итераций.
Тут опять пригодился опыт написания статей – изложить мысли письменно не составляет большого труда. Однако этого небольшого труда стало так много, что пришлось оптимизировать эту часть продаж.
Нетрудно было заметить, что писать приходится одно и то же – контекст схож, вопросы однотипны, возражения предсказуемы. Логично использовать собственные тексты повторно.
Сначала просто сохранял письма в избранном и брал из них куски. Потом допёр написать несколько Больших Писем на конкретные темы обращений клиентов. В Большом Письме изложено всё и сразу – варианты решения, последствия, несколько грустных историй, предостережения и т.д.
Такое Большое Письмо создаёт почву, канву, предмет обсуждения. Не надо итерационно углубляться в предмет вместе с клиентом, приходя к одним и тем же вопросам. Отправил Большое Письмо, и отвечаешь уже на вполне конкретные вопросы, понимая, что все участники разговора знают всё, что нужно.
Устные нарративы
Но и этого было мало. По аналогии с перепиской я заметил, что на встречах, в общем-то, всё тоже повторяется. Не один в один, а в частностях, иногда очень крупного размера.
И я сам, и менеджер, который ездит со мной на встречи, заметили – мои ответы также однотипны. Они развёрнутые, подробные, они – нарративы. Но – почти под копирку. Нетрудно догадаться, что эти нарративы можно и нужно использовать повторно.
Причём, обращаю внимание: использовать не только мне. Иначе нет смысла – если я уже приехал на встречу, то могу и в сотый раз повторить то же самое. Надо было сделать так, чтобы нарративы могли озвучивать другие люди. А я пока попрограммирую в офисе.
Так появились видеонарративы. Я просто сел перед камерой и подробно, обстоятельно сформулировал вопросы клиентов и свои типовые ответы на них. Пересказал все истории – грустные и успешные – которыми эти нарративы обычно сопровождаются. Разбил нарративы по категориям.
Ну и выдал коллегам для изучения. Менеджерам и тимлидам, которые дышат в спину, тоже желая развивать свою команду, встречаться с клиентами, продавать по-программистски. Пару нарративов даже в интернет выложил.
На тему повторного использования видеонарративов у меня пока нет достаточных данных для оценки полезности – тема ещё свежа, ей всего несколько месяцев. Пока пробуем.
Продавцы, правда, называют это «сценарии продаж». Безнадёжные они.
Итого
Попробую кратко прикинуть, когда все эти изменения свершились и как повлияли на продажи.
Начались изменения в 20 году, но быстро свернулись – началась пандемия, все расселись по домам. Тогда целью было не улучшать продажи, а сохранить их. Поэтому до осени 20 года система продаж была в законсервированном состоянии. С сентября, как вышли в офис, я начал делать первые шаги по «программированию» в продажах.
Основная часть изменений пришлась на 21 год. Как я написал в разделе «Цифры», народу за этот год у меня не прибавилось. Кто-то приходил, кто-то уходил, были локальные экстремумы, но по итогу я весь год был занят изменениями в продажах – теми, про которые вся эта статья.
Итог 21 года в деньгах – рост вдвое к 20 году. Получается, на одних только системных изменениях, без масштабирования по количеству людей. Пандемия, конечно, внесла свой вклад, но не очень существенный – нам неплохо удалось тогда сохранить объёмы. С точки зрения статистики пандемия помогла создать точку отсчёта – целый год, в котором мы ничего не меняли.
К концу 21 года основные изменения в продажах были завершены, процессы устаканились. Система начала мне нравиться. Пришло время её масштабировать.
В 22 году я переключил своё внимание на набор, адаптацию, подготовку, обучение новых программистов. На текущий момент, за 9 месяцев, приросли по людям вдвое. Изменений было много, но почти все – про программирование, а не про продажи.
Получается, в 22-м году мы повторно использовали систему продаж, созданную в 21-м году. Одновременно улучшая всё остальное. Как я написал в разделе «Цифры», три квартала 22-го года дали денег вдвое больше, чем три квартала 21-го года.
Ну, за исключением видеонарративов – они появились недавно.
