10 заповедей технической поддержки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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