Из чего состоит стоимость поддержки eCommerce проекта?

Итак, вам удалось пройти через процесс создания своего магазина на Magento — позади остались бессонные ночи и сотни чашек кофе — но вы это сделали. Вы верите в успех и убеждены, что всё затраченное время, энергия и деньги окупятся в ближайшее время. Ещё один радостный и немаловажный аспект — ваш новый магазин нравится клиентам! Однако, создать и запустить свой интернет-магазин на Magento — это только начало работы, а не конец. Теперь вам нужна ежемесячная поддержка вашего проекта и команда, которая будет обеспечивать его непрерывную работу.

Ежемесячные соглашения о поддержке — это необходимый минимум, который обеспечивает жизнедеятельность вашего интернет-магазина. Будь то Account Management, устранение уязвимостей через установку патчей безопасности, экстренная поддержка или SLA: важно сотрудничать с компанией , которая сможет последовательно поддерживать ваш проект месяц за месяцем, а также сможет обеспечить разработку улучшений и преобразований проекта. Поддержка может предоставляться в форме почасовой оплаты или оплаты по фиксированной стоимости, обе из которых сильно отличаются своим подходом к выполнению возложенных обязательств. Поэтому при заключении договора на поддержку вашего магазина нужно понимать, какова стоимость и что входит в услуги, связанные с поддержкой Magento. Это один из важнейших показателей, влияющий на общую совокупную стоимость (TCO — Total Cost Ownership) eComm проекта и его окупаемость. В этой статье подробно поговорим об этом.

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

Следование такой логике часто приводит к плачевным результатам. Так как разработка проекта «с нуля» и развитие существующего проекта с учётом минимизации технического долга и оптимизации затрат — требует различных компетенции и накладывает на команды совершенно разные требования. Цена ошибки выбора может оказаться огромной, поэтому вот список вопросов, которые необходимо задать потенциальному партнёру, прежде чем “нырнуть в омут”с головой:

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

Когда речь идет о поддержке eComm проекта, то как и в случае с разработкой, её стоимость сильно варьируется в зависимости от квалификации, размеров и месторасположения команды. Как правило, средняя типичная минимальная цена соглашения о поддержке Magento будет составлять от 54 000 до 105 000 рублей без учета НДС за 20-30 "забронированных" часов в месяц.

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

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

Как мы уже упоминали ранее, все компании разные. Некоторые предлагают почасовую оплату, а некоторые склоняются к фиксированной цене. Мы предпочитаем работать в рамках модели с фиксированной ценой по ряду причин, о которых вы можете прочитать в этой статье. Если кратко, то мы полагаем, что в конечном итоге, договор на основе фиксированной цены ставит наших клиентов на первое место во всей нашей работе. Хотя большинство компаний предлагают аналогичные услуги по Account Management, обновлениям патчей безопасности, экстренной поддержке и SLA, мы считаем, что модель с фиксированной ценой приносит пользу всем трём элементам при ежемесячной поддержке Magento. И вот почему:

Управление патчами безопасности Magento

Допустим, вам суммарно предлагают 20 часов поддержки в месяц. Учтите, что за последние пять лет Magento выпускала в среднем 4,6 патчей безопасности в год. Кроме того, для установки, тестирования и развёртывания среднего патча безопасности Magento требуется более 18 часов усилий, без учёта того времени, которое необходимо потратить на изменения в имеющемся функционале. Если вы не будете считаться с этими цифрами, вы значительно превысите выделенный бюджет, платя за перерасход часов. Поскольку сроки выхода и содержание патчей Magento могут время от времени незначительно изменяться, составление бюджета на патчи может быть чрезвычайно трудным, если вы работаете с компанией с почасовой оплатой.

Совершенно иначе выглядит картина при соглашении на обновление патчей с фиксированной стоимостью услуг. Мы рекомендуем выделять не менее 100 часов в год на устранение уязвимостей безопасности, что соответствует около 8 часам в месяц. Такая прозрачность позволяет нам быстрее обрабатывать обновления, и вы можете быть уверены в своевременном обслуживании.

Экстренная поддержка инцидентов

Понятно, что почасовая оплата может быть немного непредсказуемой, и эта неопределённость усиливается, когда речь идёт об экстренной поддержке. Даже если вы организовали поддержку с опытной командой, способной справиться с чрезвычайными ситуациями, в какой-то момент всё равно могут возникнуть проблемы от которых никто не застрахован. И здесь важно понимать, как команда выстраивает Risk Management.

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

Обычно, когда возникает чрезвычайная ситуация, скорость её выявления зависит от квалификации поддержки уровня L1 и инструментов, которые используются для выявления проблем. Команда начинает работать над определением источника проблемы, устранением (hotfix) её (уровень поддержки L2) и разработкой плана предотвращения повторного возникновения проблемы (уровень поддержки L3). Если принять во внимание все эти факторы, то нередко на одну крупную чрезвычайную ситуацию уровня P1 (инциденты первого приоритета) суммарно может уходить от 16 до 24 часов. Таким образом, работая на основе почасовой тарификации, вы снова превышаете выделенное в месяц количество часов, и получите дополнительный счёт на оплату, а также потратите драгоценное время на согласование превышения бюджета в то время, когда каждая минута на счету.

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

Этот процесс продуман и детализирован, поэтому нашим клиентам не приходится беспокоится о том, сколько времени и ресурсов затрачивается в таких ситуациях.

Управление проектом

Когда вы видите количество выделенных на поддержку часов, (пусть для наглядности это будет 20 часов в месяц), вы можете предположить, что вы вполне располагаете 20 часами для того, чтобы что-то "починить”. Но вы ошибаетесь. Работая по часовой ставке, компания, осуществляющая поддержку вышлет вам отчёт в конце месяца, в котором будет указано, как эти часы были потрачены — вы можете удивиться, узнав, сколько времени тратится на задачи, не связанные напрямую с разработкой или устранением инцидентов.

Подумайте — как часто вы общаетесь со своим с проектным менеджером? Если сотрудник фиксирует затраченное время, — а он это конечно делает, — то вы увидите это время в своем счёте. Кроме того, многие команды используют минимальный шаг при учёте затрачиваемого времени в 15 минут, что означает, что переписка, телефонные звонки и статусные встречи быстро суммируются и приводят к значительным суммам в счёте. Как только вы поймете, что с вас взимается плата за общение, вы, вероятно, дважды подумаете, прежде чем отправить электронное письмо или взять трубку, чтобы поговорить с вашим менеджером, а это непременно негативно отразится на качестве поддержки.

Если вас беспокоит качество, вам следует убедиться, что ваш партнёр по поддержке имеет чёткий и детализированный план проверки кода и обеспечения качества перед его релизом в “боевое окружение”. Хотя эти задачи имеют решающее значение для обеспечения высококачественного результата, они воспринимаются как само собой разумеющиеся и часто упускаются из виду при обсуждении оценок задач. Формальное тестирование, принятие pull requests, тестирование на средах — все эти этапы разработки могут увеличить общее время, необходимое для выполнения задачи — до 50%, а иногда и в разы. Ввиду вышеописанного очевидно, что из 20 часов разработки, которые вы запланировали на этот месяц, на самом деле у вас останется около 5 часов, что объясняет, почему использование почасовой тарификации на проекте поддержки часто приводит к незапланированным тратам.

Поддержка SLA (Service Level Agreement)

Поддержка SLA (Service Level Agreement - соглашение об уровне сервиса) регламентирует время доступности команды, время реакции команды на инцидент, время, за которое он должен быть разрешён и общий уровень доступности сервиса. SLA — один из основных инструментов, позволяющих повысить уровень обслуживания, разграничить зоны ответственности между членами команды и определить степень подготовки команды поддержки.

Часто в SLA прописывается финансовая ответственность команды поддержки за несоблюдение указанных параметров. Для обеспечения SLA, командам поддержки потребуется на постоянной основе проводить следующие виды работ:

Любой проект, ориентированный на привлечение клиентов, рост продаж, снижение операционных затрат и оперативное решение технических проблем, которые тормозят развитие бизнеса — нуждается в SLA поддержке. И совершенно очевидно, что для её реализации на вашем проекте потребуется выделенная команда, которая полностью погружена в процесс и способна быстро решать возникающие задачи. Также для реализации поддержки необходимо ограничить затраты на уровне заранее зафиксированного количества часов будет крайне проблематично.

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

Мы работаем с международными компаниями и брендами уже более четырнадцати лет, с фокусом на развитие существующих проектов, и единственное, что остается верным, — это то, что поддержка способствует успеху.