Сегодня – никаких сказок. Только факты, цифры и кейсы. Про продажи глазами и руками программиста. Точнее, с применением подходов из программирования. Лично мне кажется, что эти подходы суть – здравый смысл. Странно, что не все так делают. И интересно, согласитесь ли вы с этим после прочтения.
На всякий случай представлюсь: я руковожу командой программистов. Моя цель – набирать их, учить, обеспечивать интересной работой, как-то веселить и удерживать. Да, ещё я много программирую – люблю.
Но бизнес хочет, чтобы мы ещё и деньги приносили. Точнее, он примерно именно этого и хочет – это же бизнес. А как это будет сделано – не так важно, если в границах приемлемого. Можно людей набирать, стоимость услуг повышать, эффективность ковырять и т.д.
Поэтому приходится заниматься ещё и деньгами. Соответственно – продажами. Из дальнейшего изложения станет понятно, почему – это я предваряю возражение ��менеджеры же есть, пусть они продают».
Есть менеджеры, их много. Но с ними хуже.
Цифры
Для начала цифры. На начало 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-го года.
Ну, за исключением видеонарративов – они появились недавно.
