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

Директор по продажам 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 года я вижу два направления развития:

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

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