Так мы все привыкли представлять процесс технической поддержки:
А теперь о том, как это происходит на самом деле :)
Вся техническая поддержка подразумевает исключительно почасовую оплату.
Заповедь 1: Не брать заведомо обреченные проекты
Если владельцы сайта в прошлом сэкономили на программистах или дизайнерах — то нет смысла реанимировать такой проект сейчас. Почему? Даже при нормальном коде сайт, выглядящий в традициях «нулевых», не решит свою бизнес-задачу. Аналогично — если за красивой картинкой толпами роятся баги, сайт работает медленно и то и дело падает. С чего начинать? Как бы жестоко ни звучало, но — переделывать сайт. Если на этот раз не экономить на программистах, то, вероятнее всего, техподдержка вам вообще не потребуется.
Заповедь 2: Выполнять задачи спринтами
То есть мы не делаем правки по одной. Это экономически невыгодно ни одной из сторон, потому что:
- Для внесения каждой правки нужно переносить сайт к себе, разворачивать у себя копию для тестирования, а потом размещать изменения на работающем сайте клиента. Итого примерно 8 часов на различные «сопутствующие» работы.
- Счет в итоге выставляется за затраченное время. Получается, что правка на 1 час дополнится 8-ю часами на внесение этой правки.
Поэтому мы рекомендуем обращаться с готовым списком пожеланий, которые мы затем вместе упорядочим по приоритету, распланируем спринты и приступим к выполнению задач «пачками», по всем принципам Scrum’а.
Заповедь 3: Давать предварительную «вилочную» оценку
Руководитель отдела технической поддержки называет клиенту ориентировочную оценку — по срокам и, соответственно, стоимости доработок. Только после согласия клиента мы приступаем к правкам. Это избавляет клиента от «сюрпризов» при выставлении итогового счета.
Заповедь 4: Запрашивать время на исследование причин
В случае, если вилочную оценку сразу провести нельзя — мы запрашиваем время на исследование причин возникшей проблемы. Обычно это 2 часа работы программистов. Клиент, соответственно, может дать добро на выполнение задачи, отказаться или же сделать ее менее приоритетной, оставить «на потом». У клиента, тем самым, появляется возможность контролировать ход процесса и планировать изменения бюджета.
Заповедь 5: Оповещать клиента о «неожиданных находках»
Если в процессе работы по техподдержке разработчики внезапно «натыкаются» на плохо структурированный чужой код (сайт изменяли «на стороне») — менеджер обязательно согласует дальнейшие действия с клиентом. Сценарии те же: согласиться, отказаться, отложить на потом.
Заповедь 6: Не проводить полный тест после каждого изменения
Снова по той же причине экономической нецелесообразности. Полный тест сложного сайта может занимать и 40 часов, при этом даже самый кропотливый тест не дает 100% гарантии, что внесенная правка не повлекла за собой регрессию кода.
Заповедь 7: Всегда тестировать изменения
Каждое изменение, которое вносится разработчиками, потом тщательно тестируется. Следует понимать, что чем больше изменений было привнесено в сайт, тем более обширным будет тестирование. Это добавляет еще одно очко техподдержке по спринтам.
Заповедь 8: Гарантия на наши правки
Мы гарантируем, что внесенные нами изменения будут работать. Но если соблюдаются условия:
- Сайт разрабатывался нашей студией.
- После завершения спринта техподдержки проводилось полное тестирование сайта (проводится по желанию и за счет клиента).
- После внесения правок никто больше не трогал код.
Сайт — технически сложная система и учесть все взаимосвязи сложно даже на проекте, который вы же и разрабатывали. Не говоря о сайтах, код которых дописывался до или после правок.
Заповедь 9: Предусматривать срок бесплатной техподдержки
У нас это 3 месяца после сдачи проекта. Есть еще и так называемые «скрытые ошибки», который протестировать сразу нельзя по каким-либо причинам — они исправляются бесплатно в течение 1 года.
Заповедь 10: Делать исключения для «старых добрых клиентов»
Последний принцип наименее «принципиальный» из всех. Какими бы отлаженными ни были процессы, всегда найдется место человеческому пониманию. Внеочередные экстренные правки существуют, всё дело в лояльности. Поэтому давайте будем понимающими и понимание обязательно вернется ;)
Техподдержка занимает массу времени именно менеджера. Фактически оно сопоставимо со временем, которое тратит программист. Поэтому, чем больше задач выполняется за один подход — тем лучше оптимизировано время менеджера. И, соответственно, ниже итоговая стоимость всех правок.