Написал в блоге пост, почему в некоторых случаях готовые решения — это лучший выбор. Статья рассчитан на рядового пользователя, не на разработчика, но, возможно, будет кому-то интересна.
Часто не имея опыта продаж в интернете, заказчик заказывает дорогую разработку, вкладывает в это большие деньги и в итоге многое вынужден переделывать уже через несколько месяцев, т. к. за это время им был получен практический опыт, который важнее чем теоретические рассуждения или чужой опыт, прочитанный сети.В этой статье я расскажу о плюсах и минусах готовых интернет-магазинов, дам основные советы по выбору, приведу примеры.
Содержание:
Что такое «готовое решение».
Почему это хорошо.
Не нужно разбираться в создании веб-сайтов.
Скорость запуска и экономия бюджета.
Возможность расти.
Цена вопроса.
Как снизить цену.
Несколько примеров.
Магазины электроники.
Магазины одежды.
Автомобильная тема.
8 советов, как выбрать готовое решение.
Минусы готовых решений.
Купили, что дальше?
Эта статья для тех, кто собирается открыть интернет-магазин, но еще рассматривает варианты и думает по какому пути пойти, заказать разработку магазина в студии, у фрилансера или выбрать облачный сервис.
Я предложу рассмотреть еще один вариант, который сочетает в себе оба предыдущих — это готовые решения на базе 1С-Битрикс.
Договоримся, что речь идет не о крупных е-коммерс проектах с десятками тысяч позиций товаров, а об относительно небольших магазинах.
Что такое «готовое решение на Битрикс»
Это полностью готовый интернет-магазин, с профессиональным дизайном и богатым функционалом, заточенным под конкретную тематику (например, одежду или электронику), но более доступный по цене, чем заказная разработка и который так же легко устанавливается и настраивается как облачный сервис, но при этом не является арендуемым решением.
Нужно отметить, что «готовыми решениями» (сокращенно ГР) бывают не только интернет-магазины. Есть сайты-визитки, лендинги, корп.сайты, доставка еды и т.д. Уже сейчас в маркетплейсе 1С-Битрикса (это магазин готовых решений) можно найти и купить готовый интернет-магазин по очень многим темам. В этой статье я говорю только про интернет-магазины. Хотя преимущества и недостатки готовых решений, которые будут здесь приведены, вполне могут быть применимы и к любым другим готовым сайтам из битриксного маркетплейса.
Почему это хорошо
Не нужно разбираться в создании веб-сайтов
Готовый сайт интернет-магазина здорово упрощает жизнь владельцу. На начальной стадии это очень важно, потому что на старте у него и без сложных, новых для него технических деталей, хватает головной боли с другими организационными моментами.
С готовым интернет-магазином, отпадает весь большой пласт работ, начиная от продумывания общей концепции до финальной проверки на предмет наличия всего оговоренного функционала. Не нужно думать о проектировании магазина, правильном дизайне, контролировать верстку, отслеживать полноту выполнения программной части. Даже если интернет-магазин заказали в студии «под ключ» (и студия работает на Битрикс), клиенту все равно приходится принимать решения и подписывать акты приемки работ. Для этого ему нужно хоть как-то вникать в ход этой работы.
Кто-то возразит, что без, пусть общих технических знаний, не стоит начинать. Я тоже с этим согласен. Но эти знания можно получать по-разному. Можно заказать дорогой интернет-магазин, руководствуясь прочитанными в интернете статьями в блогах, рекомендациями студии, которой поручили разработку и собственной интуицией, потратить на это деньги и полгода жизни, запуститься, получить обратную связь от клиентов, набраться опыта и понимания, как на самом деле нужно было все делать. Как результат — снова платить деньги за доработки, но уже зная зачем.
А можно пропустить дорогой, долгий и хлопотный процесс разработки интернет-магазина, взять готовое решение, которое соответствует вашей нише, и начать работать на нем, сразу переходя к получению опыта продаж и обратной связи от клиентов. Это отличная экономия не только денег и времени, но и нервов.
Поступать иначе стоит только в двух случаях. Либо если вы точно знаете чего хотите (но тогда вы вряд ли дочитали до этого места), либо , имеете свободные деньги и лишнее время, хотите пройти весь путь с самого начала и получить весь опыт, включая опыт заказа сайта в студии.
Список вопросов для обдумывания:
Для того чтобы начать работу, обязательно ли сначала вложить много денег в создание магазина в дорогой студии, ждать полгода пока его сделаю и только после начинать продажи?
Сколько можно заработать, приобрести опыта и обратной связи от клиентов за эти полгода, пока магазин разрабатывается?
Что будет если вложить средства не в создание интернет-магазина, а в продвижение и рекламу, увеличатся ли при этом шансы на успех?
А причина какой была? У всех одна или разные. Часто причина бывает эмоциональной. Тут логотип не крутится, тут я хотела большими красными буквами а тут черные и небольшие и т.д.
Кудренко Юрий, Кастомизация - все типовые решения трудно и долго ( а соответственно дороже) кастомизируются, а некоторые вообще не предусматривают кастомизации
Юрий Кудренко, великолепный обзор по теме Типовых решений! С удовольствием прочитал полную версию, о некоторых моментах таких как стресс от быстрого старта -- я даже не задумывался ) Уверен, что эта статья, не только покупателям, но и другим партнерам очень пригодится
Евгений, Юрий, я бы так сказал - ТР (в 90% случаев) это чисто старт, понять нишу, пощупать. Потом лучше все сносить и делать заново (параллельно разумеется).
Есть конечно добротные ТР в Маркете, но чаще одностраничек они не идут. Магазины и прочее - отборное Г. Я бы не хотел на таком бизнес строить. Уж простите за прямоту.
Чаще всего все сводится к сложности расширения, к криворукости и малоопытности программера.
1. Чтобы создать страницу брендов, со своими подкатегориями товаров, надо перепилить каталог. Раздел писать практически с нуля. По деньгам уже приближается к стоимости ТР. 2. Бесит криворукость. В "быстрый просмотр" летит весь bitrix:catalog.element, хотя там нужны несколько полей. При росте посещаемости это убийца. Это снова вытекает тыщ в 10 переделки. Опять почти стоимость ТР.
Я не говорю, что допилы и переделки сложны и дороги, но в сумме набежит добрая сотня-другая денег. А тут лучше сесть и переписать заново, когда: а) Ты видишь, что продажи пошли, деньги потекли. б) Ты уже понял ЧТО тебе надо.
Но ТР не расширяемы (точнее дорого расширяемы) - это факт.
Большинство клиентов в ус не дуют, они не в курсе что это типа для старта (мне попался только один, который осознано это взял для быстрого старта). Почти все клиенты считают это раз купил - значит ничего уже такого делать не надо и там типа битрикс и он же типа уже всё умеет, а когда развенчиваешь миф - все недовольны. У меня есть один клиент взял одно типовое решение (неплохое кстати но тоже не блещет) и вот попросил он доработки - доработали с горем пополам, а потом вышли обновления для решения, которые затарагивают всё и вся. И клиент говорит - хочу себе все эти фишки, но и старое чтобы всё наше кастомизированное было.
По мне так -можно выбрать быстрый старт и купить ТП - но как только попрёт, надо делать отдельный проект. Потому как даже отдельный проект сложно удержать в конве аккуратности изнутри - а это влияет на время жизни продукта.
Долганин Антон написал: Но ТР не расширяемы (точнее дорого расширяемы) - это факт.
Подтверждаю, так же. Потому как разрабатываются для заработка, а при такой цели естественно кастомизация это последнее дело на которое взглянут.
По больше части соглашусь с Антоном Долганиным - всегда относился к ТР как к возможности быстро начать. Клиентам всегда это проговариваю. И что чуть позже, как устоятся бизнес-процессы продаж и начнут поступать заказы, надо будет начать делать индивидуальную разработку.
В целом к ТР отношусь хорошо, так как есть задачи, которые легко с их помощью можно решить. И в ближайшее время буду делать типовой интернет-магазин со своим виденьем. При этом буду руководствоваться следующими принципами (может быть опытные разработчики поправят меня по каким-то пунктам):
1. Нужно писать код, который потом сможет понять другой разработчик. Во всяком случае максимально к этому стремиться. Я тоже имел опыт доделок и переделок чужих типовых решений и могу сказать, в некоторых такой бардак в коде - просто каша, что пока разберешься что и где, потратишь лишние пару часов. Мне кажется некоторые разработчики сами потом блуждают в своем же коде.
2. Делать надо так, чтобы клиенту было так же легко начать работать как, например, в онлайн сервисах типа инсеилз и прочих. Как минимум должна быть публичная документация по основным операциям для пользователя. Я например в одном своем решении делал калькулятор и с помощью такой документации все клиенты сами могли настроить его. Вообще документация, судя по всему, "больная" многих ТР в маркетплейсе. Хотя казалось бы, очевидная же вещь - ты делаешь готовый типовой продукт, дай к нему инструкцию по основным операциям. Тем самым и свою техподдержку разгрузишь.
Долганин Антон написал: Но ТР не расширяемы (точнее дорого расширяемы) - это факт.
Антон, а можешь поделиться своим видением, что нужно ТР, чтобы стать "недорого расширяемыми"?) На что бы ты обратил в первую очередь внимание, учитывая то, что действительно мало кто из заказчиков ТР будет тратить более 30-40 часов работы разработчика на решение, которое потом будет продаваться за 3-4 тыс. (если, конечно, там не планируется гарантированные сотни продаж в месяц). Есть ли тут какой-то "оптимум", позволяющий не уйти в "максимализм", но при этом дающий возможность для дальнейшей доработки ТП?
Новиков Максим написал: Антон, а можешь поделиться своим видением, что нужно ТР, чтобы стать "недорого расширяемыми"?)
На самом деле все просто - писать по правилам Битрикс, и практически не выносить компоненты в свое пространство (к примеру оформление заказа).
Иногда все упирается в непонимание специфики области разработчиком, для которой он делает магазин. Ну к примеру одежда для людей и товары для животных абсолютно по разному преподносятся, их попросту не запустить на одном и том же магазине. А делают такие магазины под один шаблон, который сложно расширяем.
Один из насущных вопросов: как лучше хранить языковые фразы в публичке? С шаблонами компонентов понятно, там lang папка и всё, как и в папке шаблона (для header и footer), а вот в публичке не ясно: или вставлять на каждую фразу main.include, или просто подключать файл с языковыми фразами из шаблона:
Может, есть какие-то удобные кейсы на эту тему? А то ведь с этими преобразованиями кодировок приходиться быть внимательным, чтобы потом не получить где-нибудь кракозябры после установки.
Долганин Антон написал: На самом деле все просто - писать по правилам Битрикс, и практически не выносить компоненты в свое пространство (к примеру оформление заказа).
В смысле не делать копий стандартных компонентов, а максимально использовать их возможности? Кстати, а как насчёт init.php - насколько он сейчас используется в проектах, или всё же хорошим тоном считается упаковывать всё в компоненты?
Максим, тонкости производства ТП не подскажу, не пересекался с этим (знать как - знаю, но все же более удобные варианты и правила приходят с опытом только).
Новиков Максим написал: В смысле не делать копий стандартных компонентов, а максимально использовать их возможности?
Долганин Антон написал: init.php это локальная вотчина проекта. Ни один модуль не должен туда лезть. Ну и это вроде как запрещено модераторами Маркета.
Ну, для этого можно создавать подпапку c ID сайта (в /bitrix/php_interface/), и туда помещать свой init.php, который будет подключаться для нашего установленного решения. Вопрос тут немного в другом: насколько есть смысл выносить туда различные функции и классы, особенно в случае, когда они используются всего единожды, или есть смысл максимально это инкапсулировать внутри своих компонент или в качестве скриптов в шаблонах стандартных компонент, к примеру.
Новиков Максим написал: Ну, для этого можно создавать подпапку c ID сайта (в /bitrix/php_interface/), и туда помещать свой init.php, который будет подключаться для нашего установленного решения.
У проекта такой файл тоже может быть.
Другой вопрос - зачем вам это надо? Разместить функцию, которая доступна всегда? Ну вариант один - заегистрировать обработчик-пустышку на каждом хите, таким образом модуль, и все его функции будут подключаться на каждом хите.
вот попросил он доработки - доработали с горем пополам, а потом вышли обновления для решения, которые затарагивают всё и вся. И клиент говорит - хочу себе все эти фишки, но и старое чтобы всё наше кастомизированное было.
Авторы решения выпустили новый функционал -- горе, беда, огорчение! Ну ведь абсурд же! Ведь это объективно замечательное событие -- а вам можно было внести правки повторно за отдельную плату, клиент как я понял сам просил обновление. А вы выставляете это как урон вам нанесенный. Нонсес.. Может быть все таки учиться общаться со своими заказчиками, а не искать виноватых?
ТР - это шаблон сайта. Если вы кастомизируете его, то нет никакой технологии, которая бы автоматически переносила ваши доработки в выходящие обновленные шаблоны. Точно такая же ситуация с публичкой Корпоративного портала битрикса -- один в один.
Если хотите получать новые фичи, которые выходят -- прилется вносить правки повторно. Думайте как можно упростить и автоматизировать хотябы частично эту операцию. Может быть нужно вести подробную проектную документацию. Может быть git настроить чтобы код сравнивать. Это как направление в какую сторону мыслить.
Но обвинять авторов за то что они выпускают обновления своих типовых решений с новым функционалом это очень странная позиция, мягко говоря...
Согласен с Романом. Часто клиенты удивляются, что после доработок нельзя просто так взять и поставить обновления. Поэтому уже на этапе продажи доработок мы сообщаем, что в таком случае возможна ситуация, когда обновления решений автоматически установить будет нельзя.
Стараемся, конечно же, делать так, чтобы этого избежать, ищем пути решения задачи. Но, если по-другому нельзя, то либо клиент отказывается от дальнейшего обновления (что кстати для многих не так страшно), либо установка обновлений делается вручную, но уже за отдельные деньги.
Кастомизация - все типовые решения трудно и долго ( а соответственно дороже) кастомизируются, а некоторые вообще не предусматривают кастомизации
ТР -- это сайт на битрикс завернутый в модуль и выложенный на продажу в МП. Объясните мне, как его кастомизация может быть дороже или вообще не предусматриваться в отличии от точно такого же сайта на битрикс, но который не завернут в модуль и не выложен в МП ? Ответ очевиден -- нет абсолютно никакой разницы. Уверен, что умные люди, коих здесь абсолютное большинство, это понимают.
Но ТР не расширяемы (точнее дорого расширяемы) - это факт.
надо понимать, что ты Антон, в хорошем смысле -- ПЕРФЕКЦИОНИСТ. Вот если через призму перфекционизма смотреть на готовые ТР -- то, да, все плохо-плохо-плохо... Это отличное качество во многих случаях, но не всегда оно полезно.
Как ТР могут быть нерасширяемы если авторы постоянно выпускают обновления с новым функционалом расширяя и добавляя новый функционал и возможности? Опять же вопрос работы с ожиданиями клиентов -- это не быстрее и не дешевле чем доработки любого другого сайта на битрикс. Да, люди купившие ТР за 10тр, когда они потом просят два блока на главной странице местами понимать, и получая счет в 2тр -- приходят в шок. Нужно объяснять, разговаривать.
Это я про то, что если заказчик уже выложил за разработку сайта 350 000 рублей, то он уже эмоционально легко воспринимает какую-то доработку в час работы программиста и счет в 1500р. Тогда как большинство пользователей ТР -- это совсем другая категория клиентов...
Одна из реальных проблем, с которой приходится сталкиваться - это исправление ошибок в решениях. Типовая ситуация - клиент заказывает доработки/покупает решение, начинает его наполнять и в процессе появляются какие-то ошибки, которые на демо-версии заметить нельзя.
Как поступать? Я на данный момент однозначного ответа не нашёл. Есть следующие варианты: 1) Исправлять ошибки самим, бесплатно. Чаще всего мы так и делаем, т.к. всегда идём навстречу клиентам и стараемся оказывать качественную поддержку. К сожалению, бывают ситуации, что ошибок много или они серьезные, и прибыль от проданного решения сводится к нулю или в вообще уходит в минус. Естественно, в дальнейшем это решение мы рекомендовать не будем, либо, если клиент захочет всё-таки приобрести/доработать его, то это скажется на стоимости в сторону её значительного увеличения. 2) Обращаться в тех. поддержку разработчиков решения. За всю практику мне лично не приходилось этого делать, но, наверное, это один из вариантов. Мы считаем, что если на решение есть партнерская скидка, мы продали решение, то и отвечать за него должны мы (если не ошибаюсь, то примерно такую мысль как-то высказывал Роман Петров). 3) Исправлять ошибки самим, платно. Такой вариант не применяли. На месте клиента я бы не понял, почему за исправление ошибок нужно платить. 4) Закладывать в стоимость решений доп. сумму работ (допустим, часов 5). Это, по сути своей, страховка.
В общем говоря, процесс поддержки типовых решений не всегда самый простой и зависит от многих вещей. Если вы чаще всегда продаёте одни и те же решения, то работать будет проще.
Негативное впечатление о ТР сложится, если: 1) Часто приходится работать с разными решениями. Ошибки есть у всех, но на проверенных сайтах вы уже их все знаете, а в новых - нет. 2) Не сообщать клиенту перед началом работ о возможных рисках (ошибки в решении, невозможность установки обновлений). Большинство клиентов слабо подкованы технически и думают, что всё делается просто и работает автоматически. И тут одно дело - это заранее сообщить об этом клиенту, а другое - уже во время выполнения работы. 3) Оценивать сложные доработки "на глаз". Лучше попросить доступ к сайту и посмотреть его код. В таком случае появится хотя бы какое-то представление о сложности доработки и можно будет скорректировать её стоимость.
Хотелось бы услышать мнение тех, кому также приходится часто поддерживать или дорабатывать решения (желательно не свои). Как вы ведёте работу с клиентами?
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».