Исправили четыре ошибки: как мы возвращали клиентов в сфере IT-разработок.

Ситуация: у компании неожиданно пропала половина заказчиков. Директор нашел, в чем причины, и исправил ошибки.

Алексей Остудин,

Основатель и генеральный директор ООО «Три3», Москва

Алексей Остудин
Окончил факультет прикладной информатики в РАНХиГС. Был гендиром и фаундером в компании «Авиадайнинг Рус». В 2020 году основал IT-компанию.
ООО «Три3» (Tree3 LLC)
Сфера: разработка ПО в сфере B2B.
Год основания: 2020.
Численность персонала: 15 человек.
Оборот в 2020 году: 30 млн руб.

Я основал компанию в феврале 2020 года. Первых клиентов получили сразу, буквально из записной книжки. Я был профессиональным стартапером в сфере интернет-маркетинга, руководил продажами в инженерных компаниях, проходил акселерацию в венчурном фонде. У коллеги, технического директора, был десятилетний опыт в создании софта. Мы оповестили знакомых, что теперь занимаемся разработками для бизнеса на заказ. Летом я заметил, что удовлетворенность клиентов снизилась. Старые заказчики перестали обращаться повторно. Всего мы потеряли 50 процентов клиентуры. Работы, однако, меньше не стало. Выручка упала, а расходы не снизились. На рынке предпосылок для такой ямы не было: в нашей сфере клиентов больше, чем разработчиков. Рынок не перенасыщен. Начал искать проблемы внутри компании. Общался с заказчиками, узнавал, что не нравится. Анализировал работу сотрудников. На то, чтобы понять, в чем дело, ушел месяц, два месяца потребовались, чтобы решить проблемы, которые я выявил. В этой статье описал ошибки, которые временно лишили нас клиентов. 1. Заказчики были недостаточно заинтересованы Сперва хватались за всех клиентов, которые к нам обращались. Они приходили, заказывали разработку. Мы делали расчеты и брались за дело. А потом, если у нас появлялись вопросы, заказчик мог месяц не отвечать. Работа тормозилась. И этот клиент больше не возвращался. Например, первый заказчик был намерен инвестировать деньги, но не время. Месяц писали ТЗ без его участия. Через два месяца он сказал, что «пробежался по диагонали» и ничего не понял. Сослался на другие дела и отказался продолжать сотрудничество. Как исправили. Начали готовить заказчиков на старте. Перед заключением договора объясняем, что ждем оперативной коммуникации. Некоторые клиенты, когда осознают, сколько времени придется потратить, откладывают проект. Или нанимают для этого отдельного сотрудника. Узнаем, насколько задача приоритетна для клиента. И отказываем, если не в числе первых. Он не дойдет до конца или будет затягивать сроки. 2. Клиенты плохо понимали сферу IT-разработок Некоторые заказчики согласовывали проекты, не вникая в суть. Начинались переделки, доработки. Человек оставался недоволен. Клиент из архитектурного бюро попросил разработать программу, которая поможет создавать решения для проектирования частных домов. Это должно было выглядеть так: человек заходит в программу, выбирает набор параметров и получает чертежи на участке под своим кадастром. Я попросил клиента описать логику работы приложения. Однако заказчик даже не представлял, как это может выглядеть. Хотел получить готовое решение от нас. А мы не можем заниматься разработкой, не понимая, чего ждет клиент. Проект остановился, зато появилось понимание, как работать дальше с такими клиентами. Как исправили. Задаем наводящие вопросы на старте. Например, клиент просит разработать мобильное приложение, CRM-, ERP-систему или сайт. Уточняем, насколько человек понимает продукт. Если поверхностно — работать не будем. Проводим встречи с клиентами. Обучаем особенностям ведения разработки, так как во многих компаниях IT-технологиям внимания не уделяют.

50%
Столько клиентуры потеряла компания «ТриЗ» летом 2020 года

Разбиваем проекты на подзадачи. После реализации каждой из них заказчик видит промежуточный результат, ему проще представить итог. Стали готовить подробные сметы проектов. Сперва так не делали: заключали договор, потом разрабатывали техзадание, дизайн. Сейчас до заключения договора описываем бизнес-процессы, составляем техзадание. У заказчиков это вызывает доверие: мы не взяли денег, но уже вложились в задачу. Не боимся, что заказчик с наработками уйдет к конкуренту. Чужие наброски сложно использовать. 3. В команде были некомпетентные сотрудники Некоторые разработчики оказались не просто неопытны, а некомпетентны. Наблюдали за ними: смотрели, за какое время разные специалисты справляются с похожими задачами. Так мы поняли, что у некоторых переоценили грейды, а некоторые недополучают зарплату. Попросили тимлидов, то есть старших разработчиков, оценить членов команды. Дело в том, что тимлиды не участвовали в подборе команды. Когда подчиненные не справлялись, мы спрашивали, в чем дело. И получали резонный ответ: «Вы сами их приняли без моего участия». Как исправили. Абсолютно некомпетентных разработчиков уволили. Набрали новых. Я или проджект-менеджер ищем специалистов через HeadHunter, а выбирает тимлид. Он обязан понимать, достигнет ли с этим человеком нужных показателей. Этот же руководитель несет ответственность за результаты команды. При найме определяем сильные и слабые стороны кандидатов. Говорим, что согласны взять на работу, если за первые месяцы прокачает слабые стороны. Тимлиды контролируют процесс. Если сотрудник растет, мы его повышаем и платим больше без дополнительных просьб. 4. Коммуникация между отделами была не налажена Между подразделениями отсутствовала обратная связь, например между программистами и проджект-менеджерами. Если первые видели проблему, они замалчивали ее и пытались решить сами. Иногда, если в дизайне чего-то не хватало, разработчики додумывали. Это неправильный ход. Они должны были обращаться к дизайнеру. Как исправили. Ввели еженедельные планерки, на которых сотрудники обмениваются обратной связью, обращаются друг к другу за помощью. Установили ограничения: три раза решаешь проблему сам, потом просишь помощи. Ввели временные рамки на самостоятельные попытки — два дня. Если сотрудник обращается за помощью сразу после появления проблемы, это его расслабляет.

Подсказал коллега Разработчик делал платежные сервисы, которые нужно было подключить к Apple Рау. У него не получалось. Старался, но не мог найти решение. Не сообщал о проблеме и тянул время. Постоянно ставил по задаче статус «в процессе». Я не мог ответить заказчику, когда закончим проект. Когда ввели еженедельные планерки сотрудников, проблема решилась. Другой разработчик, у которого был похожий опыт, подсказал. Все оказалось просто: в платформенном приложении Apple Pay можно подключить платежный сервис только через встроенный браузер Google Pay. Apple не дает нигде запустить Apple Pay, кроме как через Safari. Если бы связь между отделами была налажена раньше, проблемы не возникло.

Результат Когда улучшили работу, вернулись почти все заказчики. Клиенты увидели, что мы меняем процессы, становимся удобными для них. Пришли новые клиенты. Даже не понадобилось вкладываться в рекламу. Сейчас у нас ровно столько клиентов, сколько можем потянуть. А чтобы брать больше, нужно масштабироваться.