{"id":14276,"url":"\/distributions\/14276\/click?bit=1&hash=721b78297d313f451e61a17537482715c74771bae8c8ce438ed30c5ac3bb4196","title":"\u0418\u043d\u0432\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0432 \u043b\u044e\u0431\u043e\u0439 \u0442\u043e\u0432\u0430\u0440 \u0438\u043b\u0438 \u0443\u0441\u043b\u0443\u0433\u0443 \u0431\u0435\u0437 \u0431\u0438\u0440\u0436\u0438","buttonText":"","imageUuid":""}

Итоги года — как зафакапить разработку под заказ

Директор по продажам BrightMobile рассказывает о допущенных за год ошибках и выводах.

Обычно принято под новый год писать слащавые истории о том, как всё было круто и сколько миллиардов компания планирует заработать. Мы решили пойти иным путём - проанализировать ключевые ошибки, которые сделали в уходящем году, чтобы не повторить их в новом и поделиться опытом с коллегами.

В 2017 году мы окрепли и к весне 2018-го года сформировали коробочное решение Сервис ПИ, которое позволяло быстро запустить свой стартап маркетплейса. Коробка имеет приличное количество настроек, которые позволяют "уберизировать" большинство бизнесов и зарабатывать на комиссии от прямой стыковки заказчика и конечного исполнителя. Это могут быть курьер и офис-менеджер, арендатор и арендодатель, да и просто любой житель города и мастер по бытовым услугам.

Объединение

Я, в то время, был партнёром Сервиса ПИ и владельцем собственной веб-студии. Параллельно, Сервис ПИ работал ещё с 20-ю партнёрами, но ни одной продажи они так и не сделали. Для меня же интерес был в том, что продажи лицензий с доработкой маркетплейсов под клиентов были на порядок выгоднее и более управляемы, чем обычная разработка сайтов.

Для сравнения напишу, что продавали сайты с индивидуальным дизайном за 300-350 тыс. Из них, чистыми оставалось 40-60 тыс. В затраты я вложил исправление багов за собственный счёт и недополученную прибыль с программиста и дизайнера, в случае задержки по срокам. При этом трудозатрат было примерно на 3 человекомесяца, но, из-за бюрократии, разработка затягивалась на 4-5 месяцев и была постоянная проблема, когда программист метался между несколькими проектами.

В свою очередь, продажа лицензии и индивидуализация под клиента на сумму в 300 тыс давала моментальные 130 чистыми на счёт, а 170 отрабатывались плотной работой за 1-2 месяца. Оборачиваемость и маржинальность в разы лучше.

Посчитав экономику и взвесив все за и против мы решили объединиться с Сервисом ПИ. Жалко было бросать студию, решил передать всё одному из ПМов. Вроде бы достигли согласия, но, в последний момент, он решил, что лучше увести пару программистов и крупного клиента без всего остального :)

Масштабирование в никуда

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

Идея была достаточно проста - делаем индивидуальные проекты, смотрим повторяющийся функционал у проектов с похожими идеями и выпускаем ещё одну коробку. Вторая идея выходила из того, что мы упёрлись в потолок 5-и продаж коробок в месяц, а разработка под заказ привязана только к количеству программистов. Хотели к декабрю посадить в офис 20 программистов с прицелом на 15 активных проектов в момент времени.

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

Жареным запахло где-то через 3-4 месяца. Увидели 3 проекта, у которых явно летела экономика, расторгли договора, придя к консенсусу с клиентами, списав на то, что продажа была "в прошлую эпоху" и проблема локальная. Это была вторая ошибка. Если бы мы тогда увидели системную проблему, то сэкономили бы порядка полумиллиона. Но нет, комсомольцы не ищут лёгких путей, и я сконцентрировал отдел продаж на масштабировании и минимум 4-х новых проектах в месяц.

Лайфхак от менеджеров по продажам

Отдел продаж использовал по-экранную оценку, чтобы по каждому проекту не отвлекать программиста. Я об этом подходе рассказывал вот в этой статье. Зарплата отдела продаж выстраивалась, как 15% от оборота в случае выполнения плана или 10%, в случае невыполнения. Это третья ошибка. Если бы менеджеры получали больший процент, но не от оборота, а от маржи, то, возможно, проблема, описанная ниже, носила бы меньший характер.

А проблема в том, что в подходе есть лайфхак. Попапы не оцениваются и считаются составной частью экрана. При первом взгляде очевидно, что как-то глупо брать деньги за уведомление "Заявка принята" или "Спасибо, мы получили Ваш заказ". Но на практике эта возможность "бесплатного" уведомления, совмещённая с форматом расчёта зп менеджера привела к тому, что сейлзы старались не вникать в проект, а фиксировать количество экранов на ту сумму, которая, по их мнению, была приемлема для клиента.

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

К концу ноября таких проектов накопилось 10-15. Было бы не так печально, если бы всё выяснилось не в самый последний момент. А так, дизайн сделан - дизайнер получил зп, программист сверстал все экраны, собрал серверную часть и простые экраны приложения, получив ~80% всех денег за проект и, видя бесперспективняк, увольнялся. ПМ получал зп за месяцы ведения проекта. А мы откатывались на этап дизайна, потеряв крупную часть суммы...

Сухой остаток

В сухом остатке, в декабре, нам пришлось расторгнуть почти все договора на индивидуальную разработку и искать компромиссы для наших клиентов и возвращать часть сумм общим объёмом в 600 тыс.

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

Перспективными на начало 2019 года я вижу два направления развития:

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

Ну и, самый главный вывод - не полагаться на подчинённых, а проверять каждый проект по контрольным точкам.

А какие выводы из 2018 года сделали вы?

0
54 комментария
Написать комментарий...
Прочел это-потратил время зря
Перспективными на начало 2019 года я вижу два направления развития:
Помощь в запуске и раскрутке маркетплейсов

А почему сами для себя не делаете маркетплейс, если это такое перспективное направление? (Вопрос с подвохом: уровень - Познер)

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Потому что продавать коробочное решение выгоднее в моменте времени и компетенции есть для отрезка «запуск - вывод на продажи». Масштабировать до солидного уровня на данный момент не умеем.

Ответить
Развернуть ветку
Dima Kotobotov

если все так шоколадно, то в чем проблема освоить масштабирование?

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Проблем нет. Тут вопрос в компетенциях, наличии времени и рисках.

Ответить
Развернуть ветку
Dima Kotobotov

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

Ответить
Развернуть ветку
Денис Гордиенко
Автор

В каждом посте я отправляю в портфолио, например, сюда - http://www.cmsmagazine.ru/mobile/brightmobile/apps/

Ответить
Развернуть ветку
Dima Kotobotov

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

Ответить
Развернуть ветку
51 комментарий
Раскрывать всегда