Как разработка решений может вас рано или поздно убить
Антон Долганин15 Января 2015 5:488821
Хочу поделиться своим опытом поддержки клиентов на протяжении почти 7 лет (времени, когда саппорт стал постоянен), от радужного рассвета до черного заката.
Речь в статье не про проекты на поддержке (даже те, которые вы сами сделали), а поддержка ваших собственных решений. То бишь, модули, типовые сайты, и прочее. Хочу сразу сказать, что пост написан для российской действительности, когда нет сотен продаж ежедневно, как у какого-нибудь WP-плагина за 3 бакса в Штатах. В российской действительности клиент пока еще не платит массово, и начнет ли он платить когда-либо — вопрос. И да, написанное относится к студиям 1-5 человек, или к фрилансерам. Ну и конечно если их у вас хотя бы с десяток-другой, что собственно естественно — вы будете стремиться наращивать количество, думая, что это приведет и к росту денег.
Итак, все началось году в 2008, когда я стал выпускать первые модули под систему Битрикс. Благо, они были достаточно дорогие (3-5т.р., что по тем временам достаточно дорого для веб-софта). Когда пошли первые продажи, естественно, я был рад. Купили за 4т.р., потратили моего времени на 500р., 3.5т.р. ушло на окупаемость разработки. Кто-то вообще не обращался за саппортом, чистая выгода в 4т.р. ложилась в карман. Ляпота!
Спустя пару-тройку лет Битрикс запустил свой , все ринулись делать решения за 100 руб. Я тоже. Не, ну а что? Потратил 4 часа, выпустил, глядишь за 50-100 покупок окупит, да и прибыль хорошую даст. Да и для конечного клиента не тянет это на бОльшие деньги.
Спасибо Битрикс, что он поставил планку в 500 руб. несколько позже, но даже эта планка оказалась фатальной спустя несколько лет.
Что за негатив, и что такого произошло несколько лет спустя? А вот эти 500-рублевые клиенты накапливались, накапливались, накапливались, и потом стал происходить взрыв за взрывом. То в Битрикс выйдет нечто, под что надо пилить новую версию модуля, то сам банально что-то упустил в коде. Все бы ничего... но 500 рублей (которые, к тому же, были заплачены в прошлом) уже не рентабельны для вас. То есть тупо они могут убить вас, так как вы будете работать ниже прожиточного минимума своего (у каждого есть семья, счета, квартиры, машины, а может и кредиты). То есть, опускаться до дешевого труда банально невыгодно и опасно.
И вот тут то нас встречает зверь Support. Ты обязан, сынок. Ты продал это решение, дал свое обязательство оказать помощь. Ты должен прямо сейчас все бросить и помочь. Ну или спустя пару дней. Но завтра тебе еще один напишет, и ты ему тоже должен будешь помочь.
Резонно возразить «Сам виноват, раз писал плохой код». Так ладно бы плохой код. Давно бы постригся в монахи, стал бы поддерживать сайт прихода в каком-нибудь селе. Люди пишут в 90% случаев совершенно по проблеме меня не касающейся (либо задают вопросы, что тоже отнимает время). А вникнуть в проблему надо, отписать пути решения, или банально «простите, мой модуль не виноват» тоже надо. На все разборы полетов тратится драгоценное время. Да, клиент конечно потом пишет «Спасибо, Антон, извините меня», но деньги уже потрачены. И не 500 рублей, а 1-2 т.р. уже улетели в пересчете на ваш _текущий_ рейт.
Что происходит дальше? А дальше игла наркомана. Чтобы хоть как-то оплачивать текущий саппорт, я вынужден не снимать с продажи всю эту мелочь, получается, ком наращивается. Да и просто обидно — столько работал, а сейчас просто закрыть лавочку. Делать бесплатным — может и выход через несколько лет. Это, по крайней мере, очистит совесть.
Я вас не убедил? В пересчете на деньги я трачу 30-50 т.р. в месяц на саппорт. Я просто так выкидываю полтинник каждый месяц на поиски даже не своих ошибок. Это, черт подери, очень обидно. Это, черт подери, одна новая машина каждый год. Да, конечно, я не трачу именно деньги, но я давно приравнял час своей жизни к рублю по определенному курсу.
Какие варианты? Я бы предложил вам задуматься над пунктами ниже:
Не делать дешевые решения. Я описывал планку в 200-300 т.р. за решение на партнерке (). Делайте крутые решения, делайте бандлы мелких. Стремитесь к тому, чтобы одна продажа окупала сразу месяц труда специалиста начального уровня. В крайнем случае посадите его на поддержку.
Не делайте дешевые решения, я повторю. Даже в начале пути. Потом вас это убьет. Только если у вас не железная совесть, и вы не сможете послать всех нафик.
Продавайте саппорт. Если клиент обращается к вам, спросите активный ключ решения. Если он истек - отказывайте в помощи. Жестоко, но пропишите это в правилах пользования вашим товаром. Так вы хоть будете окупать поддержку, и индексировать стоимость саппорта (увеличивать стоимость продления).
А как же та планка в 3-5 т.р. за модуль? Можно их делать, но, вы же понимаете, что функционал должен быть интересен клиенту. А это либо крутая идея, которая все равно прогорит рано или поздно, либо постоянные доделки. Мое мнение, что это еле-еле окупит разработку. Проще заниматься обычной коммерческой разработкой для клиентов. Или делать стартапы.
К сожалению, иных вариантов выживать на этом российском рынке я не вижу.
Эх какие правильные слова. Как это все близко и понятно тем кто делает решения и как это непонятно тем кто еще только думает их выпускать. Битриксу стоит поднять планку минимальной стоимости и ужесточить проверку качества решений, а лучше сделать средство самоконтроля для разработчиков, тот мастер тестирования что сейчас есть давно уже не обеспечивает нужный уровень.
А кроме того могу привести пример нашего модуля XML Экспорт на торговые площадки, которое также съедает массу времени ТП так как завязано с настройками на другие сайты и особенно для больших каталогов где часто масса времени тратиться на доказательства что надо сервера мощнее, а то попадаются такие, кто хочет на виртуальном хостинге каждые 10 секунд обновлять файл экспорта каталога из 30 тыс товаров. И тут хоть повышай, хоть не повышай цену, но как то надо ставить ребром вопрос поддержки, тот же Битрикс по соглашению требует, чтоб поддержка была оказана, но сам при этом всегда говорит что не занимаются настройками, а попробуйте докажите клиенту который купил модуль что вина не в модуле, а в сервере или кривых руках админа, даже чтоб это доказать уже надо потратить прилично времени, а если не потратишь потеряешь клиента, да мало того потеряешь еще и негатив получишь, у нас же все любят жаловаться, а вот положительный отзыв не допросишься. Что то надо с этим делать однозначно, тех поддержка должна быть платной ну как минимум для тех модулей которые связаны со сторонними ресурсами и настройками производительности.
Антон, спасибо что поделился своим опытом!
Согласен с тобой по сути во всем, можно попробовать выйти из этой ситуации, у меня все в силе, в этом году перехожу больше на разработку модулей, немного отстаю от плана из-за здоровья, как буду готов напишу, иду по сути по твоим стопам, но надо еще мне времени, здоровье бы не подводило, зараза...
Желаю тебе успехов во всем, осуществления всех желаний, задуманного и здоровья крепкого!
Статья очень актуальна. Ведь техническая поддержка дорогая составляющая любых готовых решений.
Скорее всего проблема вашей технической поддержки в SLA. Вы его не рассчитывали при создании своих решений и не моделировали. И эта проблема очень важна для технической поддержки.
При расчёте и моделирование SLA учитываются параметры:
затраты,
время реакции,
время переписки,
стоимость реакции,
репутация
стоимость поддержки всех решений (платные и бесплатные (репутационные решения))
и многое другое.
Если вы создадите для себя эту модель, то поймёте какой уровень технической поддержки вам нужен. В этой модели нужны ещё параметры связанные с тем, чтобы просчитать стоимость ваших решений уже существующих, чтобы они покрывали бесплатные и давали прибыль, или сколько вам нужно ещё создать решений и стоимостью, чтобы новая поддержка не завалила ваш бизнес, а вы смогли посадить на поддержку программиста тех.поддержки.
Одним словом нужно построить экономическую модель так, как будто вы описываете процессы автоматизации какого-нибудь предприятия. Это помагает просчитать и понять, как нельзя опускаться по цене и поддержки. Где в тех.поддержку нужно внести таймауты, чтобы реагировать не так быстро.
Разбить тех поддержку на фак, справку, видео и общение через электронную почту. Это тоже регуляторы тех.поддержки.
Желаю всем нам удачи в не лёгком деле создании готовых решений. И вам удачи Антон.
Алексей, спасибо за ценный комментарий. Вы более профессионально изложили основную проблематику моего поста.Но в одном посте все тонкости конечно не описать.
Где в тех.поддержку нужно внести таймауты, чтобы реагировать не так быстро.
Это важный момент, согласен. Все поначалу хвалятся "мгновенной скоростью реакции", а так нельзя делать. У клиента должно быть время переварить тикет, а может и самому догадаться до решения, поэтому переходить на формат чата с клиентом нельзя. Именно поэтому я вынужден был отказаться от саппорта по скайпу.
Для чата можно ввести свой SLA, уже определенно платный.
Алексей, а как вы предлагаете решать проблему вендора? Ну вот поставлен у вас процесс, это можно настроить, верю. А потом бац, и Битрикс выпускает нечто, что вас затрагивает так или иначе (пример прямо сейчас который разбираю - в списке лидов не отображаются контакты по проблеме самого вендора, хотя на моделирование проблемы пришлось тратить свое время; пока проблема решилась, ушел час-другой).
Поверьте, при достаточном погружении в Маркетплейс, такое сплошь и рядом будет встречаться. Выводить в расчетах это как "внешний фактор"? Каким образом его учитывать в цене?
Как бы вы обработали такого рода тикет?
>>> Алексей, а как вы предлагаете решать проблему вендора? Ну вот поставлен у вас процесс, это можно настроить, верю. А потом бац, и Битрикс выпускает нечто, что вас затрагивает так или иначе (пример прямо сейчас который разбираю - в списке лидов не отображаются контакты по проблеме самого вендора, хотя на моделирование проблемы пришлось тратить свое время; пока проблема решилась, ушел час-другой).
Первое - разделение труда. Один человек отвечает на письма, другой исправляет, а третий делает решение для маркетплейс.
Второе - кастомизация. Зачастую мы делаем копию вплоть до механизмов ядра, если изменения ядра повлекут проблемы. Мы кастомизируем в разумных пределах, но всё только то, что можно. Хочу отметить, что кастомизация обязательна, но не панацея, как Дун Клад Маклауд при головной боле. ))
>>> Поверьте, при достаточном погружении в Маркетплейс, такое сплошь и рядом будет встречаться.
Абсолютно точно. Маркетплейс 1С-Битрикса продукт молодой и незрелый с точки зрения организации бизнес-процессов. Здесь нет устоявшихся правил, и нет стабильной идеологии разработки маркетплейс решений. Я не говорю о проблемах ядра 1С-Бтрикс, что зачастую доставляет хлопоты и весьма ощутимые. Всё меняется, а это означает, что не правильно организованный процесс в 1С-Битрикс. И такой негатив серьёзно отличает маркетплейс 1С-Битрикс от других решений, например, лестем.нет имеет строгую структуру и правила. В итоге, страдает разработчик битрикс.
>>> Выводить в расчетах это как "внешний фактор"? Каким образом его учитывать в цене?
Да. Это вероятность того, что будет проблема. На неё закладывать часы, а дальше вычислять денежную сумму.
К примеру, у нас решение готовый сайт. На него мы потратили 60 часов программиста битрикс, 16 часов дизайнера, 16 часов верстальщика, 20 часов тестирования (синтетические тесты не пишем здесь), 36 часов тех.писателя на документацию, 20 часов контент-менеджера и 10 часов руководителя проекта.
(Все мы понимаем, что здесь можно сэкономить и часы зависят от многих факторов. Имеем ввиду, что часы указаны для примера.)
Дальше закладываем ожидаемый спрос: допустим продать 20 штук (российская действительность).
Плюс ещё потенциально закладываем вероятностный фактор на поддержку (вычислить часы). И вносим всё на временную линию. Допустим мы продадим 20 решений за полгода. Значит тех.поддержка уже растягивается по времени. Вспоминаем, что у нас ещё есть другие решения, которые тоже имеют работу с тех.поддержкой.
К сожалению, этот момент можно вычислить только опытным путём.
>>> Как бы вы обработали такого рода тикет?
Общее правило на мой взгляд.
Разбить поддержку на уровни SLA: активная поддержка (купил сейчас), нужна консультация (думает покупать или нет), неактивная поддержка (купил ранее и не продлил), вендор виноват (ошибки в программе и переделки под новую идеологию маркетплейс), стоимость решения (бесплатное или платное). И ещё при создание SLA думаем о наших мечтах, что решений суммарно будет продаваться более 1000 штук.
Теперь пример, как можно реагировать. Внутри себя говорим: вендор виноват (Исправляем, если падают продажи. Или так, исправляем, если обращений в тех.поддержку будет равно 3. Или так, исправляем, когда будет новая версия 1С-Битрикс. Или так, уровень поддержки активен, то исправляем). Принятие решения зависит от наших уровней поддержки. Также, важна личность того, кто сидит на тех.поддержки. Очень важный фактор.
Расставляем таймауты тех.поддержки, делаем справку, подготавливаем фак, видео учебное по решению и так далее.
Главное сделать полноценные регуляторы, позволяющие вам в пики критических нагрузок не пострадать. И жётский регламент ответов. Видим, что человек спрашивает, как поставить отправляем в српавку. Спрашивает про настройки в справку. Видим, что не оплатил поддержку, говорим купи её, а потом поговорим, а так жди исправлений в штатном режиме. В лицензии можем ограничивать срок действия нашей тех. поддержки в течение года. Дальше её продавать.
У нас должен сформироваться разумный набор регуляторов тех.поддержки. То, есть придаём тех.поддержке более формальный ранг.
Рекомендую посмотреть на тех.поддержку самого 1С-Битрикса, на тех.поддержку гугла.,тех. поддержку яндекс. Какие-то идеи нужно брать у них, но не все, так как у них денег больше.
Возможный вариант ответа на данный вопрос.
Исправлять самим, если битрикс не идёт на встречу и пишет вам - "сам дурак". Главное не забывайте напрягать тех.поддержку 1С-Битрикс, если вина в них. Они должны исправить сами и руководство должно знать, что внутри них есть "собственный враг", мешающий развитию бизнеса, а значит с ним нужно бороться. Мы же с 1С-Битрикс всё же партнёры.
Вносить изменения в код нужно, если тех.поддержка активна.
Алексей, спасибо еще раз, очень ценные мысли Но стоит признать, что примешана доля жестокости, которую сложно одному лицу (мне в данном случае) примешивать к работе - все же клиент, обращаясь к частному разработчику, ожидает больше индивидуальности, а тут ему тыкают "Сидите ждите, идите купите, ...". Пожалуй, тот случай, когда студия выгоднее.
Хотя, может это и психологический барьер. Перебороть и сказать "нет".
Это скорее всего психология. Вопрос в том, как быть лично вам и другим разработчикам. Вы либо сможете держать тот же уровень (чтобы нам всем хотелось), либо "любить" всех вопреки "рассудку дела". Но надеюсь, наша с вами дискуссия поможет разработчикам и другим студиям. Может кто-то поделиться и своим опытом.
Ещё хотел добавить, что изменение версий php тоже может быть проблемой для нашего решения, если мы использовали, что-то сырое или просто оно потеряло актуальность в новой версии.
Версия базы данных тоже может влиять, если мы используем особые обращения туда, минуя битрикс.
Факторов много, но на это и есть архитектор проекта. Вывод здесь простой: нужно объединять компетенции и возможности, чтобы расти более без проблемно, или согласно правилам экономики возвращать в систему ценностей разработки какие-то денежные потоки, чтобы уменьшать кризис "роста".
Спасибо за откровения, Антон! Полностью с вами согласен. Хотя я и занимаюсь разработкой модулей совсем недавно, с июня 2014, но уже сейчас, с увеличением продаж и количества продаваемых модулей (сейчас у меня 5 платных и 1 бесплатное, а всего где-то чуть более 50 продаж за все время), стал ощущать нарастающий поток обращений в тех.поддержку. Местами не понимаю логики клиентов, - хотят заплатить 1000-1500 тыс рублей и чтобы им все настроили, хотя есть документация где подробно все описано... Подобная цена на модули конечно же не окупает трудозатрат на каждого такого клиента, а пишет в суппорт практически каждый второй. Как вы и сказали, в каждый случай нужно вникать индивидуально, а на это тратится порой куча времени.
Сейчас подумываю ввести платную тех.поддержку либо увеличить стоимость модулей, иначе скоро боюсь только и буду заниматься тех.поддержкой.
Если у вас есть документация, а ее не читают, создавайте мастер техподдержки (штатный компонент модуля). Клиент будет отвечать на вопросы в самом мастере, а так глядишь и поймет ответ на свой вопрос.
А если не поймет, то у вас будет полная картина о пишущем клиенте.
Мне сейчас такое запускать уже дорого, но если бы я стартовал сейчас (или заново), я бы обязательно так сделал.
Дальше будет еще интересней)) Да, нужно что-то уже предпринимать, попробовать одно, попробовать другое, посмотреть, что более оптимально, не в ущерб себе.
Лично я к сайтам клиентов больше не подключаюсь и ничего не настраиваю, были случаи, когда разработчики попросят найти проблему, все найдешь, ткнешь носом, ок, что-то там сделали, работает. Через пару месяцев звонит владелец сайта, и ты понимаешь, что этот разработчик накосячил там и все спер на тебя, мол, это те ребята там работали. Два раза так было, больше ни к кому не подключаюсь, написал доки по установке и настройке модуля в картинках на сайте, скинул ссылку, вот, пожалуйста, настраивайте сами.
+ с годами еще копится база частых вопросов, тоже на сайте добавляю, как пришел такой вопрос, ссылку на возможную проблему скинул, потратил пару минут, не написал клиент, хорошо, опять пишет, тогда дальше опять работаешь, т.к. самому клиенту трудно разобраться, в какую сторону копать проблему, я специалист, я лучше понимаю, потратил минуту, понял в чем проблема, скинул ссылку, все, ты ему помог, он тебя отблагодарил, хороший отзыв написал или просто сказал Спасибо!
Чаще всего ставят и настраивают модули сами владельцы сайтов, вижу что человек основ Битрикса или даже веба не понимает, так и пишу, наймите человека, пусть все сделает, иначе это уже много раз проверенная 100% возня целый день, получается, обучаешь человека находить визуальный редактор, показываешь где кнопка настроек компонента, учишь настраивать компонент, учишь.. учишь..
А кроме того могу привести пример нашего модуля XML Экспорт на торговые площадки, которое также съедает массу времени ТП так как завязано с настройками на другие сайты и особенно для больших каталогов где часто масса времени тратиться на доказательства что надо сервера мощнее, а то попадаются такие, кто хочет на виртуальном хостинге каждые 10 секунд обновлять файл экспорта каталога из 30 тыс товаров. И тут хоть повышай, хоть не повышай цену, но как то надо ставить ребром вопрос поддержки, тот же Битрикс по соглашению требует, чтоб поддержка была оказана, но сам при этом всегда говорит что не занимаются настройками, а попробуйте докажите клиенту который купил модуль что вина не в модуле, а в сервере или кривых руках админа, даже чтоб это доказать уже надо потратить прилично времени, а если не потратишь потеряешь клиента, да мало того потеряешь еще и негатив получишь, у нас же все любят жаловаться, а вот положительный отзыв не допросишься. Что то надо с этим делать однозначно, тех поддержка должна быть платной ну как минимум для тех модулей которые связаны со сторонними ресурсами и настройками производительности.
Только собирались активно выложить свои наработки.
Реально спасли.
Согласен с тобой по сути во всем, можно попробовать выйти из этой ситуации, у меня все в силе, в этом году перехожу больше на разработку модулей, немного отстаю от плана из-за здоровья, как буду готов напишу, иду по сути по твоим стопам, но надо еще мне времени, здоровье бы не подводило, зараза...
Желаю тебе успехов во всем, осуществления всех желаний, задуманного и здоровья крепкого!
Я почему и написал статью - опасная дорожка, лучше сразу по уму делать.
Скорее всего проблема вашей технической поддержки в SLA. Вы его не рассчитывали при создании своих решений и не моделировали. И эта проблема очень важна для технической поддержки.
При расчёте и моделирование SLA учитываются параметры:
- затраты,
- время реакции,
- время переписки,
- стоимость реакции,
- репутация
- стоимость поддержки всех решений (платные и бесплатные (репутационные решения))
- и многое другое.
Если вы создадите для себя эту модель, то поймёте какой уровень технической поддержки вам нужен. В этой модели нужны ещё параметры связанные с тем, чтобы просчитать стоимость ваших решений уже существующих, чтобы они покрывали бесплатные и давали прибыль, или сколько вам нужно ещё создать решений и стоимостью, чтобы новая поддержка не завалила ваш бизнес, а вы смогли посадить на поддержку программиста тех.поддержки.Одним словом нужно построить экономическую модель так, как будто вы описываете процессы автоматизации какого-нибудь предприятия. Это помагает просчитать и понять, как нельзя опускаться по цене и поддержки. Где в тех.поддержку нужно внести таймауты, чтобы реагировать не так быстро.
Разбить тех поддержку на фак, справку, видео и общение через электронную почту. Это тоже регуляторы тех.поддержки.
Желаю всем нам удачи в не лёгком деле создании готовых решений. И вам удачи Антон.
Для чата можно ввести свой SLA, уже определенно платный.
Поверьте, при достаточном погружении в Маркетплейс, такое сплошь и рядом будет встречаться. Выводить в расчетах это как "внешний фактор"? Каким образом его учитывать в цене?
Как бы вы обработали такого рода тикет?
Первое - разделение труда. Один человек отвечает на письма, другой исправляет, а третий делает решение для маркетплейс.
Второе - кастомизация. Зачастую мы делаем копию вплоть до механизмов ядра, если изменения ядра повлекут проблемы. Мы кастомизируем в разумных пределах, но всё только то, что можно. Хочу отметить, что кастомизация обязательна, но не панацея, как Дун Клад Маклауд при головной боле. ))
>>> Поверьте, при достаточном погружении в Маркетплейс, такое сплошь и рядом будет встречаться.
Абсолютно точно. Маркетплейс 1С-Битрикса продукт молодой и незрелый с точки зрения организации бизнес-процессов. Здесь нет устоявшихся правил, и нет стабильной идеологии разработки маркетплейс решений. Я не говорю о проблемах ядра 1С-Бтрикс, что зачастую доставляет хлопоты и весьма ощутимые. Всё меняется, а это означает, что не правильно организованный процесс в 1С-Битрикс. И такой негатив серьёзно отличает маркетплейс 1С-Битрикс от других решений, например, лестем.нет имеет строгую структуру и правила. В итоге, страдает разработчик битрикс.
>>> Выводить в расчетах это как "внешний фактор"? Каким образом его учитывать в цене?
Да. Это вероятность того, что будет проблема. На неё закладывать часы, а дальше вычислять денежную сумму.
К примеру, у нас решение готовый сайт. На него мы потратили 60 часов программиста битрикс, 16 часов дизайнера, 16 часов верстальщика, 20 часов тестирования (синтетические тесты не пишем здесь), 36 часов тех.писателя на документацию, 20 часов контент-менеджера и 10 часов руководителя проекта.
(Все мы понимаем, что здесь можно сэкономить и часы зависят от многих факторов. Имеем ввиду, что часы указаны для примера.)
Дальше закладываем ожидаемый спрос: допустим продать 20 штук (российская действительность).
Плюс ещё потенциально закладываем вероятностный фактор на поддержку (вычислить часы). И вносим всё на временную линию. Допустим мы продадим 20 решений за полгода. Значит тех.поддержка уже растягивается по времени. Вспоминаем, что у нас ещё есть другие решения, которые тоже имеют работу с тех.поддержкой.
К сожалению, этот момент можно вычислить только опытным путём.
>>> Как бы вы обработали такого рода тикет?
Общее правило на мой взгляд.
Разбить поддержку на уровни SLA: активная поддержка (купил сейчас), нужна консультация (думает покупать или нет), неактивная поддержка (купил ранее и не продлил), вендор виноват (ошибки в программе и переделки под новую идеологию маркетплейс), стоимость решения (бесплатное или платное). И ещё при создание SLA думаем о наших мечтах, что решений суммарно будет продаваться более 1000 штук.
Теперь пример, как можно реагировать. Внутри себя говорим: вендор виноват (Исправляем, если падают продажи. Или так, исправляем, если обращений в тех.поддержку будет равно 3. Или так, исправляем, когда будет новая версия 1С-Битрикс. Или так, уровень поддержки активен, то исправляем). Принятие решения зависит от наших уровней поддержки. Также, важна личность того, кто сидит на тех.поддержки. Очень важный фактор.
Расставляем таймауты тех.поддержки, делаем справку, подготавливаем фак, видео учебное по решению и так далее.
Главное сделать полноценные регуляторы, позволяющие вам в пики критических нагрузок не пострадать. И жётский регламент ответов. Видим, что человек спрашивает, как поставить отправляем в српавку. Спрашивает про настройки в справку. Видим, что не оплатил поддержку, говорим купи её, а потом поговорим, а так жди исправлений в штатном режиме. В лицензии можем ограничивать срок действия нашей тех. поддержки в течение года. Дальше её продавать.
У нас должен сформироваться разумный набор регуляторов тех.поддержки. То, есть придаём тех.поддержке более формальный ранг.
Рекомендую посмотреть на тех.поддержку самого 1С-Битрикса, на тех.поддержку гугла.,тех. поддержку яндекс. Какие-то идеи нужно брать у них, но не все, так как у них денег больше.
Возможный вариант ответа на данный вопрос.
Исправлять самим, если битрикс не идёт на встречу и пишет вам - "сам дурак". Главное не забывайте напрягать тех.поддержку 1С-Битрикс, если вина в них. Они должны исправить сами и руководство должно знать, что внутри них есть "собственный враг", мешающий развитию бизнеса, а значит с ним нужно бороться. Мы же с 1С-Битрикс всё же партнёры.
Вносить изменения в код нужно, если тех.поддержка активна.
Но стоит признать, что примешана доля жестокости, которую сложно одному лицу (мне в данном случае) примешивать к работе - все же клиент, обращаясь к частному разработчику, ожидает больше индивидуальности, а тут ему тыкают "Сидите ждите, идите купите, ...". Пожалуй, тот случай, когда студия выгоднее.
Хотя, может это и психологический барьер. Перебороть и сказать "нет".
И вам, Антон, спасибо за интересную дискуссию.
Версия базы данных тоже может влиять, если мы используем особые обращения туда, минуя битрикс.
Факторов много, но на это и есть архитектор проекта. Вывод здесь простой: нужно объединять компетенции и возможности, чтобы расти более без проблемно, или согласно правилам экономики возвращать в систему ценностей разработки какие-то денежные потоки, чтобы уменьшать кризис "роста".
Сейчас подумываю ввести платную тех.поддержку либо увеличить стоимость модулей, иначе скоро боюсь только и буду заниматься тех.поддержкой.
А если не поймет, то у вас будет полная картина о пишущем клиенте.
Мне сейчас такое запускать уже дорого, но если бы я стартовал сейчас (или заново), я бы обязательно так сделал.
Лично я к сайтам клиентов больше не подключаюсь и ничего не настраиваю, были случаи, когда разработчики попросят найти проблему, все найдешь, ткнешь носом, ок, что-то там сделали, работает. Через пару месяцев звонит владелец сайта, и ты понимаешь, что этот разработчик накосячил там и все спер на тебя, мол, это те ребята там работали. Два раза так было, больше ни к кому не подключаюсь, написал доки по установке и настройке модуля в картинках на сайте, скинул ссылку, вот, пожалуйста, настраивайте сами.
+ с годами еще копится база частых вопросов, тоже на сайте добавляю, как пришел такой вопрос, ссылку на возможную проблему скинул, потратил пару минут, не написал клиент, хорошо, опять пишет, тогда дальше опять работаешь, т.к. самому клиенту трудно разобраться, в какую сторону копать проблему, я специалист, я лучше понимаю, потратил минуту, понял в чем проблема, скинул ссылку, все, ты ему помог, он тебя отблагодарил, хороший отзыв написал или просто сказал Спасибо!
Чаще всего ставят и настраивают модули сами владельцы сайтов, вижу что человек основ Битрикса или даже веба не понимает, так и пишу, наймите человека, пусть все сделает, иначе это уже много раз проверенная 100% возня целый день, получается, обучаешь человека находить визуальный редактор, показываешь где кнопка настроек компонента, учишь настраивать компонент, учишь.. учишь..