10 заповедей технической поддержки
Мы как-то уже писали о том, как организована служба техподдержки разработанных нами продуктов для 1С-Битрикса. С техподдержкой сайтов все происходит немного иначе, сейчас мы по порядку всё проясним и расскажем о философии, которой мы придерживаемся.

Так мы все привыкли представлять процесс технической поддержки:

А теперь о том, как это происходит на самом деле :)

Вся техническая поддержка подразумевает исключительно почасовую оплату.

Заповедь 1: Не брать заведомо обреченные проекты

Если владельцы сайта в прошлом сэкономили на программистах или дизайнерах — то нет смысла реанимировать такой проект сейчас. Почему? Даже при нормальном коде сайт, выглядящий в традициях «нулевых», не решит свою бизнес-задачу. Аналогично — если за красивой картинкой толпами роятся баги, сайт работает медленно и то и дело падает. С чего начинать? Как бы жестоко ни звучало, но — переделывать сайт. Если на этот раз не экономить на программистах, то, вероятнее всего, техподдержка вам вообще не потребуется.

Заповедь 2: Выполнять задачи спринтами

То есть мы не делаем правки по одной. Это экономически невыгодно ни одной из сторон, потому что:

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

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

Екатерина руководитель отдела технической поддержки

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

Заповедь 3: Давать предварительную «вилочную» оценку

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

Заповедь 4: Запрашивать время на исследование причин

В случае, если вилочную оценку сразу провести нельзя — мы запрашиваем время на исследование причин возникшей проблемы. Обычно это 2 часа работы программистов. Клиент, соответственно, может дать добро на выполнение задачи, отказаться или же сделать ее менее приоритетной, оставить «на потом». У клиента, тем самым, появляется возможность контролировать ход процесса и планировать изменения бюджета.

Заповедь 5: Оповещать клиента о «неожиданных находках»

Если в процессе работы по техподдержке разработчики внезапно «натыкаются» на плохо структурированный чужой код (сайт изменяли «на стороне») — менеджер обязательно согласует дальнейшие действия с клиентом. Сценарии те же: согласиться, отказаться, отложить на потом.

Заповедь 6: Не проводить полный тест после каждого изменения

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

Заповедь 7: Всегда тестировать изменения

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

Заповедь 8: Гарантия на наши правки

Мы гарантируем, что внесенные нами изменения будут работать. Но если соблюдаются условия:

  • Сайт разрабатывался нашей студией.
  • После завершения спринта техподдержки проводилось полное тестирование сайта (проводится по желанию и за счет клиента).
  • После внесения правок никто больше не трогал код.

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

Заповедь 9: Предусматривать срок бесплатной техподдержки

У нас это 3 месяца после сдачи проекта. Есть еще и так называемые «скрытые ошибки», который протестировать сразу нельзя по каким-либо причинам — они исправляются бесплатно в течение 1 года.

Заповедь 10: Делать исключения для «старых добрых клиентов»

Последний принцип наименее «принципиальный» из всех. Какими бы отлаженными ни были процессы, всегда найдется место человеческому пониманию. Внеочередные экстренные правки существуют, всё дело в лояльности. Поэтому давайте будем понимающими и понимание обязательно вернется ;)