Абонентская модель или пакет часов: как выбрать формат техподдержки интернет-магазина

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

Техподдержка чаще всего работает по абонентской модели. Это значит, что клиент ежемесячно выкупает определенный объем часов, а подрядчик выполняет задачи в рамках этого лимита.

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

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

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

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

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

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

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

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

За развитие интернет-магазина обычно отвечают сразу несколько подразделений: маркетинг, продажи, закупки, клиентский сервис, руководство компании. У каждого свои цели и приоритеты. В результате новые задачи появляются одновременно из разных направлений, а планы приходится регулярно пересматривать.

Для некоторых задач нужны специалисты со стороны клиента. Например, дизайнер или 1С-разработчик.

Проблема в том, что сайт для них часто не единственный проект. Дизайнер может одновременно готовить материалы для маркетплейсов и офлайн-рекламы, а 1С-разработчик — заниматься другими задачами компании. Из-за этого часть работ по сайту откладывается, а сроки сдвигаются.

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

Для таких проектов мы используем формат техподдержки по пакету часов.

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

Практически это работа по модели Time & Material: клиент оплачивает фактически затраченное время на выполнение задач. Но в отличие от классической абонентской поддержки, здесь нет обязательного ежемесячного объема часов.

Клиент приобретает пакет часов — 10, 20, 40 или больше — и расходует его по мере необходимости. Стоимость часа зависит от объема пакета:

Срок действия пакета также зависит от объема: 10 часов — 6 месяцев, 20 часов — 9 месяцев, от 40 часов — 12 месяцев.

Стоимость часа едина для всех специалистов независимо от роли и грейда. Такой подход эффективен для проектов, где в работе участвуют специалисты разных направлений: аналитики, дизайнеры, frontend- и backend-разработчики, QA-инженеры, DevOps-специалисты и другие участники команды.

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

По нашему опыту, нагрузка на проект непостоянна. Сегодня компании может требоваться 20–30 часов работ в месяц на небольшие доработки, а через несколько недель — уже несколько сотен часов на запуск нового функционала, интеграции или редизайн. После завершения такого этапа объем работ может снова снизиться до прежнего уровня или временно сойти к минимуму.

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

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

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

Структура команды в KISLOROD изначально рассчитана на разную нагрузку. У нас есть full-time специалисты и проектные сотрудники, которых можно подключать при увеличении объема работ.

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

Часть команды также участвует во внутренних проектах KISLOROD: развитии бизнес-процессов, модулей, корпоративного портала и других задачах. Если клиентскому проекту срочно нужны дополнительные ресурсы, внутренние задачи можно временно отложить. Если внешней нагрузки становится меньше, команда возвращается к внутренним проектам.

Кроме того, у нас есть несколько проектных офисов со своими командами и тимлидами. Если в одной команде возникает перегруз, а в другой — свободный ресурс, часть специалистов мы временно подключаем к соседнему проекту.

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

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

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

Все задачи фиксируются в таск-трекере, а изменения в коде — в Git. Под каждую задачу создается отдельная ветка, связанная с ID задачи. Так понятно, кто, когда и в рамках какой задачи вносил правки.

На разных этапах проекта могут понадобиться разные специалисты: системные и бизнес-аналитики, UX/UI-дизайнеры, frontend- и backend-разработчики, QA-инженеры, DevOps-специалисты.

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

Помимо тимлидов, в компании есть руководители направлений: дизайна, frontend-разработки, QA, DevOps и других. Они помогают распределять задачи между специалистами, подключать нужных людей и следить, чтобы новые участники быстро разобрались в проекте.

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

В основе процесса несколько правил.

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

Если задача поставлена не полностью или в ней не хватает деталей, аккаунт-менеджер уточняет информацию у клиента и дополняет постановку. Без понятных требований сложно корректно оценить объем работ и сроки выполнения.

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

Такой подход помогает увидеть крупные задачи целиком и точнее прогнозировать трудозатраты.

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

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

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

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

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

Но мы стараемся не выходить за рамки согласованной оценки без предварительного обсуждения. Для этого используем несколько инструментов:

Для задач, где особенно важно контролировать бюджет, можно установить лимит на количество часов.

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

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

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

Если на проекте в текущий момент есть стабильный поток задач, сначала планируются часы на проект в целом, а затем внутри этого объема расставляются приоритеты по конкретным задачам.

Если задач немного и они появляются нерегулярно, специалисты планируются сразу на отдельные задачи.

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

Это схема работы, при которой объем работ, сроки и стоимость проекта согласовываются до начала разработки и фиксируются в договоре. Такой формат подходит, когда важно заранее согласовать бюджет и объем работ.

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

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

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

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

Такой подход помогает соблюдать бюджет и сроки, потому что основные решения принимаются еще до начала разработки. Но по сравнению с работой по пакету часов или классической моделью Time & Material на согласование и подготовку обычно уходит больше времени.

Это формат работы с ежемесячной оплатой, при котором клиент заранее резервирует определенный объем времени команды под задачи своего проекта.

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

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

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

У каждого формата работы есть свои сильные стороны. Работа по смете помогает заранее зафиксировать бюджет и объем работ. Ретейнер подходит проектам со стабильным потоком задач и долгосрочным планированием.

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

При этом универсального решения не существует. Формат работы всегда зависит от конкретного проекта, его задач, процессов и планов развития. Если вы подбираете модель сотрудничества для интернет-магазина или другого eCommerce-проекта, обсудите задачу с нашей командой. Мы поможем оценить текущую ситуацию и предложим формат работы, который лучше подойдет вашему проекту.