9 простых шагов по выбору решения и разработчика в Маркетплейс.1С-Битрикс

Здравствуйте, менеджеры и владельцы интернет-магазинов! С Вами на связи один из лучших разработчиков модулей для 1С-Битрикс – Сотбит. И сегодня мы с Вами поговорим о том, как не ошибиться и правильно выбрать решение и разработчика в Маркетплейс
Итак, на сегодняшний день Маркетплейс.1С-Битрикс изобилует множеством готовых типовых решений и модулей. Иногда для закрытия конкретной проблемы и тематики нам предлагается аж несколько десятков вариантов решений. С одной стороны, это хорошо – всегда приятно, когда есть выбор. Это как-то греет душу. С другой – при множестве вариантов выбора есть вероятность впасть в некий ступор, когда появляется опасение: как бы выбрать лучший вариант и не прогадать?

Даже мы, специалисты в профессиональной разработке решений для Маркетплейс, тоже иногда впадаем в подобный ступор, когда необходимо для клиента подобрать наиболее оптимальный вариант решения той или иной задачи. Какой готовый интернет-магазин выбрать? Какой модуль накопительных баллов лучше? Чем отличаются друг от друга модули выгрузки на торговые площадки? Вопросов, к сожалению, может быть много, а вот ответов – мало.

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

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

Итак, давайте договоримся сразу, что сейчас мы не будем рассматривать сам программный продукт. Думаю, ни для кого не будет секретом, что программный продукт – это по умолчанию один из наиболее важных аспектов при выборе того или иного решения. Для каждого проекта и каждой задачи – свои требования к ПО. Поэтому этот пункт мы полностью оставляем на откуп Вам, дорогие клиенты Маркетплейс.1С-Битрикс. То есть мы изначально предполагаем, что Вы самостоятельно либо с помощью своих технических специалистов формируете пул программных решений, которые подходят под Ваши требования и могут решить необходимые задачи.

А далее после подбора несколько потенциально подходящих программных продуктов вступает в силу наш чеклист, который состоит из 9 последовательных шагов:

1. Демо-режим
2. Техподдержка
3. Отзывы
4. Развитие и обновления
5. Разработчик
6. Информационная поддержка
7. Кейсы
8. Стоимость
9. Аккаунт-менеджер
   

1. Демо-режим
Демо-режим – это возможность протестировать полнофункциональную версию решения в течение определенного периода времени совершенно бесплатно.

Согласитесь, очень крутая вещь?! Не нужно покупать «кота в мешке». Решение о покупке вы принимаете только после внедрения программного продукта на Вашем проекте. Риски практически равны нулю.

Но что же разработчики Маркетплейс предлагают нам с Вами в этом плане? К сожалению, почти ничего. Всего лишь 10-15% всех решений на площадке Маркета имеют демо-режим. И если с модулями немного проще – разработчики модулей более охотно дают бесплатно протестировать свои решения. То с разработчиками готовых интернет-магазинов и сайтов немного сложнее – можно пересчитать по пальцам тех, кто предоставляет демо-режим.

Откуда же такое нежелание разработчиков предоставлять функционал бесплатного тестирования свои решений в течение определенного периода? Все просто. Основные причины две:

• Технологическая. Необходимо продумать систему защиты, дописать дополнительный код, что немного усложняет разработку и сопровождение программного продукта. Не все готовы на это идти.
• Пиратство. Разработчики боятся, и небезосновательно, что их ПО будет попросту взломано и украдено. Да, такое может произойти. Но не стоит забывать, что ПО – это в любом случае риск нелегального использования. Отсутствие демо-режима точно от этого не спасет.
  

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

А теперь давайте определимся, какой же оптимальный срок для предоставления демо-периода? По нашим выверенным оценкам: 2-3 недели. Этого времени хватает, чтобы установить, настроить и протестировать практически любое решение. Срок в 1 неделю – слишком короткий, можно просто физически не успеть проверить работоспособность ПО. Срок в 1 месяц – наоборот, может оказаться в большинстве случаев большим, что может расслабить клиента и демотивировать разработчика.

2. Техподдержка
Техническая поддержка (ТП) – важнейший аспект программного обеспечения. Программный продукт без грамотного технического сопровождения может быть бесполезен. Именно поэтому разработчик продает не только сам продукт, но и его техническую поддержку.
Итак, давайте определимся, что же мы вкладываем в понятие «бесплатная техническая поддержка». Как правило, это:

• Установка
• Первичная настройка
• Консультационная помощь
  

Если же Вы хотите настройку решения «под ключ», то навряд ли это вариант с бесплатной ТП. В большинстве случаев, за редким исключением, это уже будет относиться к платной ТП. И разработчик будет оценивать трудозатраты уже на основании своих тарифов.


3. Отзывы
Очень интересный пункт. И мы в Сотбит любим его особенно.

Ведь отзывы – это фактически первое впечатление о программном решении и разработчике. По отзывам уже можно сделать определенные выводы.

Отзывы Вы можете найти в карточке модуля Маркетплейс во кладке «Отзывы».
Теперь давайте разберемся, на что в первую очередь обращать внимание при анализе отзывов:

• Контент
• Количество отзывов
• Дата последнего отзыва
• Ответы разработчика
  

Контент
Надо ознакомиться с сутью отзывов, то есть с их текстом. Ведь по тексту отзыва уже можно сделать выводы как о текущем состоянии ПО, так и о качестве работы ТП.

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

Количество отзывов
По количеству отзывов можно судить о популярности программного решения.

Если отзывов менее 5 или они отсутствуют – тогда решение помещается в разряд сомнительных. А если среди такого малого количества отзывов есть и негативные, то сомнений становится еще больше.

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

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

Так что в случае со сложным программным продуктом приоритетнее обращать внимание на кейсы, которые описаны в пункте №7 данного чеклиста, нежели на отзывы.

Дата последнего отзыва
В первую очередь необходимо обратить внимание на свежие отзывы, которые были опубликованы в течение последнего полугодия. Почему так? Да потому что – это и есть пульс ПО. Это лакмусовая бумажка того, как развивается решение и сам разработчик.
Отсутствие же свежих отзывов – знак того, что о программном обеспечении забыли не только пользователи, но и сами разработчики. Данное ПО уже утратило былую популярность, если таковая, конечно, вообще была.

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

А вообще, качественное ПО может похвастаться не только свежими отзывами, но и регулярными. Это, наверное, даже важнее. Поэтому, если в карточке решения Маркетплейс стабильно и ежемесячно появляется более 1 отзыва, то это признак класса как разработчика, так и самого программного обеспечения.

Со сложными и узкопрофильными программными продуктами дело обстоит аналогично предыдущему пункту. Из-за малой аудитории отзывов тоже, соответственно, немного. Поэтому в таком случае лучше, в первую очередь, рассматривать кейсы, которые более подробно расписаны в пункте №7 нашего с Вами чеклиста.

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

Стоит отметить, что ответы разработчика стоит анализировать именно на негативные отзывы. Ведь на положительные – нет смысла даже отвечать.
Итак, с чего же начать анализ ответов разработчика?! Во-первых, с того – есть ли вообще эти ответы?! Если разработчик не дает ответ на негативный отзыв – значит, он своим молчанием соглашается с недовольным клиентом, значит, он своим молчанием подписывается под его словами. Молчунов мы рекомендуем обходить стороной.

С другой стороны, иногда разработчик ответит так, что сделает себе и своему решению еще хуже. И тогда точно невольно подумаешь: «Уж лучше бы молчал».


4. Развитие и обновление
E-commerce, да и весь рынок веб-разработки в целом, активно развивается и видоизменяется. Тренды, стандарты и технологии меняются ежедневно. Разработчики должны держать руку на пульсе и активно реагировать на все изменения рынка, как, к примеру, это делает 1С-Битрикс.

Именно поэтому одним из ключевых аспектов при выборе ПО в Маркетплейс является понимание: какими темпами развивается решение и каковы перспективы его развития в будущем?

Чтобы проанализировать обновляемость программного решения, необходимо в карточке ПО перейти во вкладку «Что нового». И там мы можем наблюдать полный список обновлений ПО, начиная с самого его запуска.
На что следует обратить особое внимание:

• Периодичность. Хороший признак – решение систематически и с определенной регулярностью (минимально: 1 раз в 3 месяца, идеально: 1-2 раза в месяц) обновляется. Плохой признак – редкие обновления или полное их отсутствие. Если обновления до текущего момента были эпизодическими, то сомнительно, что в будущем что-то изменится.
• Полное описание. Обновления должны быть полно и конкретно описаны. Если разработчик пишет «Исправление багов», «Незначительные изменения и доработки» и все в этом духе – это значит, что он или сам не совсем понимает, какие обновления делает, или просто ленится более подробно описать доработки для своей аудитории. Скажите, кому-то нужны незнающие или ленивые?
• Стиль написания. Список доработок должен быть представлен в виде списка. Иногда разработчики публикуют все одной строкой. Тогда это просто невозможно читать.
  

Кроме того, Вы всегда можете напрямую связаться с разработчиком и поинтересоваться: какие доработки и улучшения планируются по данному решению?

5. Разработчик
А теперь давайте искать скелеты в шкафу разработчика, то есть подробно разбирать саму организацию (юридическое лицо), которое является правообладателем на ПО.

Всегда обращайте внимание на два аспекта разработчика:

• Специализация
• Рейтинг
  

Специализация
На первый взгляд может показаться, что тут такого? К чему этот пункт? Все просто.
Если разработчик специализируется на контекстном или SEO продвижении, если он делает на потоке сайты «с нуля», если он позиционирует себя кем угодно и как угодно, но только не разработчиком ПО, то могут возникнуть определенные трудности. И сейчас объясним: почему?

Разработка софта – это определенная компетенция. Она включает в себя следующие составляющие:

• планирование разработки софта
• непрерывное развертывание ПО
• автоматизация процессов сборки, тестирования и внедрения новых версий продукта
• создание отдела технической поддержки
• документальное сопровождение ПО и прочее
  

Создание сайтов «с нуля» и, по сути, весь digital требуют совсем иных компетенций. Для них разработка ПО – это, скорее, хобби либо просто упаковка какого-либо функционала в виде модуля, чтобы потом можно было пользоваться им повторно. Они не могут просто взять и планомерно заниматься полноценной разработкой и сопровождением софта. Все это, скорее, будет происходить в свободное от основной деятельности время.

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

И чтобы не быть голословными, приведу реальный пример из нашей практики. В январе 2016 года мы первыми запустили модуль «SEO умного фильтра» – самое популярное наше решение на данный момент. Изначально он умел работать только с уникальными метатегами. И вот буквально через месяц никому неизвестная украинская компания выпустила аналог нашего модуля. И он был намного круче нашего.

В результате их модуль стал очень популярным. Он был в ТОПах по продаваемости, а нашему решению такое и не снилось.


6. Информационная поддержка
Важный пункт разработки ПО. Для Маркетплейс.1С-Битрикс он включает в себя следующие составляющие:

• Упаковка
• Документация
• Видеоматериалы
  

Упаковка
Под упаковкой будем понимать все то, что доносит нам правильные смыслы о ПО. Стоит выделить следующие варианты упаковки:

• Карточка решения в Маркетплейс
• Лендинги
• PDF презентации
• Рассылки
  

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


А теперь, смеха ради, на своих примерах продемонстрируем Вам разницу между плохим и хорошим видосом.

Вот с подобных видео мы начинали. Январь 2016 года по модулю «SEO умного фильтра» (да простите нас): www.youtube.com/watch?v=POwdyF5mqJs&t=1s . Обратите внимание на дизлайки и негативные комментарии к видео. Да, именно так мы учились делать видеоконтент.
А вот уже наше свежее видео совершенно иного формата:
Надеюсь, Вы почувствовали разницу.

7. Кейсы
Кто-то может сказать: «Товарищи, Вы что-то попутали! Как может такой важный пункт, как кейсы, стоять аж под 7 номером?!». Давайте успокоимся и вместе разберемся, почему мы приняли именно такое решение.

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

Кстати, не поленитесь не просто прочитать кейс, но и самолично зайти на проект, разработанный на шаблоне разработчика. Вот тут уже все по-настоящему. Тут Вы можете самостоятельно все тестировать. Вас уже не обманешь.

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

Если же мы имеем дело с узкоспециализированным и технологически сложным продуктом, то тут кейсы придутся очень кстати. В таком случае их можно будет поставить даже на первое место в нашем с Вами чеклисте. Внедрение сложного ПО – само по себе занятие трудоемкое, требующее привлечения высококвалифицированных специалистов. Да и кейс к таком программному решению составить куда сложнее, нежели к готовому интернет-магазину.

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

Ведь ориентируясь только на цену, Вы рискуете упустить ряд важных моментов:

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

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

Что касается самих разработчиков Маркетплейс, то они в большинстве случаев ставят цены только по своим ощущениям (в принципе, мы тоже не безгрешны, ранее тоже так делали). Они не понимают и не считают трудозатраты на разработку ПО, трудозатраты на маркетинговую кампанию, планируемые трудозатраты на ТП и прочее. Именно поэтому очень часто разработчики выходят на рынок Маркета, устанавливают мизерные цены, а потом разочаровываются в площадке Маркетплейс и в результате сливаются.
Надо понимать: площадка Маркетплейс – это не PlayMarket и не AppleStore. Здесь нельзя установить 300 рублей на ПО и стать миллионером. Аудитория и рынок здесь совсем иные. И это надо учитывать.

Так вот, вернемся непосредственно к ценам. В каком случае стоит обращать на цену внимание? Скажем так, если Вы рассматриваете готовый шаблон, то разница в 10 000 – не критическая. С большой долей вероятности Вы потратите на порядок больше денег, если неправильно подберете готовое решение и разработчика соответственно.


9. Аккаунт-менеджер
Этот пункт нашего чеклиста мы специально оставили напоследок для истинных ценителей хорошего сервиса. Это как вишенка на торте.

Итак, для тех, кто еще, возможно, не знаком с таким понятием, как «аккаунт-менеджер», представим краткое его определение:

«Аккаунт-менеджер (account-менеджер) – специалист, обеспечивающий поддержание постоянного контакта с существующими клиентами, координирующий работу всех подразделений агентства над конкретными заказами клиента».

Исходя из этого определения можно сделать вывод, что аккаунт-менеджер (далее по тексту будем называть сокращенно: аккаунт) – это, в первую очередь, друг клиента, который помогает ему взаимодействовать со всеми отделами компании-разработчика.
Стоит с грустью признать тот факт, что разработчики Маркетплейс редко балуют своих клиентов аккаунтами. И причин тому несколько.

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

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

Причина третья. Высокие затраты. Затраты не только финансовые, но и временные. Руководству приходится уделять больше внимания на сервис и продажи, нежели на продукт. К тому же обучение аккаунтов продукту занимает немало времени и денег.

Так стоит ли внедрять аккаунт-менеджеров компаниями-разработчикам?

Мы ответим на этот вопрос простым примером из собственного опыта.

Итак, аккаунты у нас появились всего лишь год назад (сентябрь 2017 года). И этот шаг дался нам с большим трудом. Почему? А причины те же, что мы описали выше. И главная – отсутствие нужных компетенций. Мы могли сделать хороший продукт, но вот как организовать целый отдел аккаунтов, который будет плотно работать с клиентами – это оказалось для нас настоящей проблемой.

И как же мы решали данную проблему? Всё просто: привлечение консультантов, книги, тренинги и прочее. Все это принесло нам свои плоды. За один год мы смогли сколотить мощный отдел аккаунтов. Теперь мы жалеем лишь об одном, что не внедрили его еще раньше.