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

Точно так же, как и любому digital-продукту, каждому сайту непременно требуется пост-релизная поддержка. Обычно после того, как мы проведем запуск проекта, мы либо отдаем его команде инхаус на поддержку, либо продолжаем сопровождать сами. И часто встречаем такие случаи, когда крутая команда продукта (или услуги) просто не справляется с поддержкой своего сайта. Мы собрали примеры из своей практики и решили рассказать о типичных ошибках поддержки. Не повторяйте их, лучше учитесь на них.

Поддержка сайта ложится на плечи штатных разработчиков

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

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

В чём причина того, что IT-отдел не справляется с поддержкой? Разработчики компании заняты продуктовым развитием, а сайт может стать дополнительной зоной ответственности, при этом являясь совершенно отдельным проектом, который тоже нужно развивать и поддерживать.

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

Полноценное техническое сопровождение веб-проекта подразумевает огромные объёмы работ:

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

Список этот, как вы понимаете, далеко не полный — если попытаться расписать всё подробно, это займёт не одну страницу.

Совет командам техподдержки

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

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

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

Развитие платформы происходит нерегулярно, «от запроса до запроса»

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

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

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

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

При такой организации специалисты поддержки всегда «держат руку на пульсе» и не дают продукту отставать от актуальных тенденций IT-рынка — одновременно с этим идёт необходимая поддержка самого продукта.

За примером того, как надежда справиться со всем своими силами может не оправдаться, ходить далеко не надо. Весной текущего года в Нью-Джерси (США) начались долгие и безуспешные поиски разработчиков на COBOL. Из-за возросшей в связи с пандемией коронавируса нагрузки на старые ПК в американской системе занятости устаревшее ПО государственных компьютеров нескольких штатов перестало справляться с количеством запросов, и серверное ПО 40-летней давности срочно потребовалось обновить. Казалось бы, звучит довольно просто. Но есть одно «но». По оценке Tom's Hardware, COBOL входит в список мертвых языков, и знающих его программистов практически не осталось. Этому языку уже 61 год, и новое (да и прошлое тоже) поколение специалистов не имеет ни малейшего понятия, как с ним работать. Если бы развитие шло непрерывно, а не по упомянутой выше схеме «работает — не трогай», проблемы бы не появилось вообще. Но так как контрактов с компаниями, отвечающими именно за поддержку, у правительства США не было, произошедшее вылилось в большие проблемы, за которые пришлось очень и очень дорого заплатить.

Совет командам техподдержки

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

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

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

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

Очень показательным случаем, например, стала наша работа над проектом для бельгийско-мальтийского банка MeDirect. Дело в том, что идея цифрового банкинга и digital-инфраструктура банков в большей части европейских стран начала складываться ещё несколько десятилетий назад. И огромное количество подобных организаций там до сих пор используют устаревшие платформы.

Специалисты IT-отдела MeDirect не разрабатывали полноценные сайты с использованием библиотеки ReactJS, которую применяем мы. Так что нашему техническому директору Даниле Гегеле пришлось отправиться в командировку на Мальту, чтобы провести внедрение сайта и обучение IT-специалистов заказчика прямо на месте.

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

Другой пример — проект для KFC. Мы начали разработку совместно с IT-специалистами заказчика, презентовали им наши кейсы, показали примеры кода и стек технологий. Предложенные решения им понравились, и в итоге мы разделили работы между командами: мы занялись версткой макетов и созданием статичного контента сайта, а генподрядчик взял на себя работы по внедрению API. После того, как мы сдали свою часть работ, заказчик без проблем принял её: то есть, задачи, на решение которых IT-специалистам компании потребовалось бы много времени, были решены в короткие сроки.

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

Совет команде техподдержки

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

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

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

В качестве заключения

Сайты могут быть совершенно разными. Например, это может быть сервисный и высоконагруженный банковский, которому требуется непрерывная работа как по обеспечению безопасности пользователей, так и по своевременному обновлению информации. Каждое посещение — это буквально живые деньги. Это же справедливо и для маркетплейсов: онлайн-магазины или платформы электронной коммерции не могут позволить себе простаивать.

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

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

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

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

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

0
Комментарии
-3 комментариев
Раскрывать всегда