Запуск сервиса на готовом решении — какие есть подводные камни

Хочу рассказать о проекте «Красный Джин» из нашего портфолио – сделан он на готовом решении RTPlatform, и все сложные доработки мы реализовали под клиента сами, а затем передали проект на поддержку программисту клиента. Сегодня расскажу как выбрать готовое решение, чтобы не быть привязанным к разработчику.

Несколько слов о самом клиентском проекте. Представляет он собой маркетплейс финансовых услуг: с одной стороны здесь инвесторы, которые могут дать взаймы, получая под залог недвижимость, а с другой – люди, которым нужны деньги и они эту недвижимость предоставляют.

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

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

Главная страница

Взять, к примеру, главную страницу нашего готового решения и её же у «Красного Джина». Как видите, какие-то блоки клиент отключил, какие-то переработал: в итоге страничка получилась гораздо симпатичнее, чем в типовом виде. Добавили картинку, вместо поиска разместили единственную кнопку, ведущую на список объектов.

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

О сервисе. Этот раздел остался типовым – такое же FAQ, только другие вопросы и ответы. Нет смысла переделывать то, что и так подходит под проект только ради индивидуализации.

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

Фильтр непростой, потратили на него немало времени, но он позволяет гибко настроить географию и прочие параметры объектов под инвестора. В нём даже можно комплексно выбирать и город, и регион: например, одним кликом выделить всю Самарскую область и отдельно – Москву.

Программист клиента доработал внешний вид: вместо типового заголовка и внешнего вида он добавил в ленте основные параметры: срок займа, город, сумма, процентная ставка. Описание здесь не нужно – достаточно ключевых показателей, как на Авито. Количество просмотров, дата заявки – всё это тоже выводил программист клиента.

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

Имеется раздел «мои объекты»: здесь отображается список предложений от инвесторов на созданные заёмщиком объекты. Однако я, как заёмщик, буду видеть только контакты своего брокера. Мне приходят уведомление о новом отклике, но связаться я могу лишь с брокером, который держит контакт между инвестором и мной. Здесь в любом случае идёт какой-то торг, я выдвигаю свои условия, инвестор – свои, и нам нужно найти обоюдовыгодное решение, и работа брокера заключается как раз в его поиске – за это он и получает свой процент.

Можно сказать, что сервис «Красный Джин» выступает как «автоматизированный брокер», где реальный брокер выполняет лишь контактную функцию. Благодаря чему всё очень упрощается, а соответственно, удешевляется, а маржа площадки увеличивается.

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

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

Вы становитесь заложником ситуации. Если он не дай бог закроется, то и дорабатывать некому будет — только переделывать с нуля. Если же обратиться за доработкой, то цена будет не рыночной — конкуренции же нет.

Проверить возможность доработки сторонними силами можно двумяспособами:

Способ № 1 — проверка фрилансом. Нужно спросить на чём написано решение у разработчика и оценить сколько программистов есть на рынке, которые могут помочь с доработкой. Например, у нас сайт написан на 1С-Битрикс и приложения на Angular, пожно на фрилансе сделать поиск по проектам с такими ключевыми словами и посмотреть количество откликов, либо указать в тегах в списке фрилансеров.

Способ № 2 — проверка клиентами. Нужно попросить у разработчика решения контакты клиентов, которые дорабатывали решение при помощи своих программистов и попросить дать оценку насколько это было удобно. Если разработчик будет уклоняться от предоставления контактов, то это верный сигнал, что с доработками будут проблемы.

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