Список работ службы технической поддержки в ITConstruct

Список работ службы технической поддержки в ITConstruct

Что же такое “техническая поддержка сайтов”?

По моему мнению техническая поддержка сайтов включает в себя следующие виды работ:

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

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

Что в идеале хотели бы от нас

  1. Получать проактивные предложений по улучшению проекта.
  2. Ставить задачу в любой, даже в самой безумной формулировке. Понимания с полуслова. Домысливание «очевидного». Анализа возможных последствий реализации запрошенного. Предупреждения о возможные негативные последствиях и предложение более рациональных подходов. Иногда — заткнуться со своей мудрой аналитикой и делать, как сказали, ибо долго объяснять почему.
  3. Ставить задачу через любой удобный канал (скайп, телефон, вотсап, смс-ку). В любое время дня и ночи.
  4. Точных оценок.
  5. Ответственности за сделанное.
  6. Оперативности.
  7. Ну и что бы не дорого.

Все остальное, скорее, экзотика.

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

Ну и что бы не дорого

У нас две тарифные сетки:

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

Увеличение стоимости связано с тем, что мелкие и срочные задачи способны сломать нам весь конвейер и ставят под удар сроки по другим проектам. Мы стараемся свести срочные задачи к минимуму. Клиенты тоже не любят двойной тариф, но у них есть сознательный выбор. Задача менеджера проектов — предложить клиенту эту альтернативу.

Что входит в понятие техническая поддержка сайта?

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

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

В чем необходимость технической поддержки?

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

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

Внутренняя кухня

Оговорюсь, что расскажу про техническую поддержку только с точки зрения программирования. Дизайн, креатив и контент — тоже важно, но их организовать в разы проще (по примерно такой же схеме).

Свои проекты мы делаем по гибкой методологии scrum. Это значит, что в процессе работы клиенту не обязательно придерживаться толстого и нудного ТЗ, а можно добавлять/удалять/изменять любые хотелки прямо по ходу работы. Плюсы: гибкость и прицел на постоянное развитие проекта сразу. Минусы — постоянно неактуальная документация.

Грозовая туча: старые и новые проекты.
Список работ службы технической поддержки в ITConstruct

Над каждым проектом работает КОМАНДА разработчиков. Это важно, потому что после запуска проекта как минимум два-три человека причастны к коду и могут его поддерживать. На практике это сильно лучше, чем если бы всю разработку делал бы один «незаменимый» гений.

С незаменимостью также помогают бороться две вещи: строгие стандарты кодирования и регулярные code review, которые мы проводим на своих проектах.

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

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

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

  1. Мне нужно ввести нового человека в проект, чтобы он занимался им дальше на постоянной основе.
  2. Для развития новичков под присмотром куратора.
  3. Очень-очень редко (и рискуя получить за это минусов в карму), но все же: как мера воспитания слишком честолюбивого разработчика с задатками гурмана. Я имею в виду тех редких людей, которые на любую задачу начинают разглагольствовать, что она им не интересна, все технологии — го%но, весь чужой код — вообще го%но и даже свой, который он писал неделю назад — тоже устарел. Он вполне может схлопотать себе на ближайшие 2-3 месяца (или пока не угомонится или пока не станет ясно, что не сработаемся) проекты только на техническую поддержку (это в то время, как его коллеги получают новые, интересные проекты).

При планировании нагрузки на разработчиков мы рассчитываем, что их рабочий день состоит из двух частей: работа над основным проектом (закладываем 6 часов) и технической поддержки (оставшиеся два часа). Как правило, часы техподдержки наступают с 16:00 и до 18:00.

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

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

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

Итак, мелкие и срочные задачи мы вклиниваем в эти два часа в день, с 16 до 18 (ну фактически, с учетом командной работы это может быть и 4 и 6 часов, в зависимости от того, параллелятся ли задания). Крупные задачи, которые можно делать в спокойном режиме, мы запускаем в работу спринтами (минимум по 40 часов), в основные часы.

За коммуникацию с клиентом на технической поддержке в большинстве случаев отвечает тот же менеджер, что и работал над проектом. К сожалению, это не всегда рационально с точки зрения использования дорогущщего времени менеджеров (дорогие — не только в смысле затрат, а в смысле ТОС: менеджеры очень часто становятся бутылочными горлышками системы, а час простоя в бутылочном горлышке равен часу простоя всей системы).

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

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

Нажмите на картинку для перехода к интерактивной карте
Список работ службы технической поддержки в ITConstruct

Зачем нужна поддержка сайта?

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

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

Информационная поддержка веб-сайта

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

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

Сейчас ищут техподдержку:  Техподдержка Телеграмм – возможность решить любую проблему

В большинстве случаев сотрудники компании ничего не понимают в “сайтостроении” и неспособны выполнить подобные работы. Именно здесь и потребуется услуга по сопровождению и поддержке сайта.

Какой бывает поддержка сайта?

Для меня поддержка интернет-сайта подразделяется на два типа:

  1. Информационная
  2. Техническая

Консультации и обучение по развитию и продвижению сайтов

Вы хотите сами заниматься своим сайтом? Это счастье! На самом деле азы веб-технологий и контент-менеджмент стоит включать в обязательную программу обучения для всех будущих и нынешних предпринимателей. Но пока мы до этого еще не доросли. Какие-то минимальные знания по управлению собственными интернет-ресурсами компаниям дают веб-студии, которые эти ресурсы готовят. Стоит ли отнести данный вид услуг к техническим? У меня как-то не получается.

Контентная поддержка сайта или спец.проекты

Когда люди слышат словосочетание “Контентная поддержка сайта”, они почему то думают, что речь идет про SEO. Ну, на конференции кто-то одним ухом услышал, что сейчас в SEO самое главное — это тексты, и бежит в Яндекс искать фабрику по клепанию текстов. Спешу расстроить — это так не работает. Как работает, можно почитать тут (ссылка на ОиР).

Что же такое “контентная поддержка сайта” в нашем мире?


Давайте разберем пример. Есть компания *****. У них есть объемные задачи, которые надо делать. Например разбирать отзывы, настраивать сортировку товаров или публиковать сезонные товары. Это все, по большому счету, работа с контентом сайта.

Как правило, такие проекты единичны (у нас всего 4 штуки в работе на момент написания статьи, например) и довольно объемны. Клиент выкупает более 150 часов в месяц и под него формируется отдельная команда.  

История редкая, но мы так можем.

Купить 1с-битрикс (bitrix) управление сайтом, битрикс24, продление лицензии, скидки в москве и новосибирске

Нужна ли сайтам техническая поддержка?

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

Так что же делает ClickON в рамках услуги “Техническая поддержка сайтов”?>>>>

Оперативности

В наших штатных договорах мы гарантируем время реакции 24 рабочих часа. В 97% случаев это годный вариант. Обращаю внимание, что речь идет именно о времени реакции, а не о времени готовности любой поставленной задачи. Это все на уровне здравого смысла, и нет особого резона требовать от нас с пеной у рта впихнуть в 24 часа невпихуемое.

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

0-8h на приемку и уточнение задачи. Менеджер получает уведомление о создании новой задачи. Банальный деловой этикет и принцип пустого ящика требует, чтобы в течении суток все такие обращения были обработаны. Далее, в зависимости от срочности — задача может быть либо отложена до формирования спринта, либо экстренно запущена в работу, либо запланирована в плане работы на программиста на следующий день.

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

8-16h обычно через сутки после того, как задача попала менеджеру проекта и все формулировки понятны, она попадает на разработку. Это связано с тем, что мы планируем, какими проектами будет заниматься каждый программист на утренних планерках (в 8:45) и затем уже стараемся не отклоняться от этого плана.

16-24h в большинстве случаев мелкие задачи задачи выполняются и отгружаются клиенту за первые 8-16 часов. Еще 8 часов — резерв для выравнивания нашего потока работ или тестирования.

По большим и трудоемким задачам либо формируется спринт, либо — график выполнения, в зависимости от их срочности и приоритетов клиента. Абсолютно непродуктивно делать 30-40 часовые задачи урывками по 2 часа в день.

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

Ответственности за сделанное

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

При схеме time material по сути все риски лежат на клиенте. Если ошибок много и их исправление выставляют клиенту — он будет недоволен и вам про это скажет. Как правило, экономически выгоднее не вступать в спор и поправить свои ошибки за свой счёт, не нагнетая обстановку, даже несмотря на то, что согласована схема работы по фактическим часам. Я придерживаюсь того, чтобы исправлять ошибки за наш счёт, если:

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

Если косяк откровенно наш — берем и исправляем, не компостируя мозги. Так в итоге дешевле.

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

Замечу, что чтобы схема работала — нужно, чтобы спорные ситуации возникали как можно реже. Иначе клиент будет недоволен поддержкой или поддержка будет убыточной для студии.

Еще нюанс — мы не несем на себе ответственность за 3-х лиц (например, хостинг) или упущенную выгоду. Обычно это воспринимается адекватно.

Проактивных предложений по улучшению проекта

Здесь я должен рассказать, какие проекты попадают нам на поддержку. Всего три типа:

  1. Бесплатная техническая поддержка наших проектов.
    Это все проекты на этапе ввода в эксплуатацию и в гарантийный период. Это закреплено договором. Поддержка ввода в эксплуатацию (когда менеджер проекта на горячем старте и готов ответить на любой возникающий вопрос у клиента), как правило, это три месяца. Гарантийный период (как правило, это год) — в течение года мы готовы поправить любые найденные клиентом скрытые дефекты, которые не были обнаружены при запуске проекта. Принципиальные различия между первым и вторым в том, что при вводе в эксплуатацию проект находится в «оперативной памяти» менеджера и многие вопросы решаются проще и быстрее. В гарантийном же периоде мы исправляем бесплатно только явные баги. В спорных случаях мы оставляем за собой право, чтобы клиент обосновал нам, почему это баг. Если на диагностику требуется время и по факту баг оказался не багом — мы так же оставляем за собой право выставить счет на затраченное на диагностику время. Формально это честно, но к таким мерам мы прибегаем в единичных случаях, т.к. это создает неминуемо конфликтную ситуацию.
  2. Развитие проектов, разработанных у нас.
    Проекты, которые реализовали в нашей компании часто остаются с нами на многие годы. Развиваются и эволюционируют. Обычно мы добавляем новые функции спринтами (от 40 часов). Нам удобнее и дешевле делать один большой блок работ, чем 100500 мелких-срочных задач: экономится время менеджера, меньше рисков допустить ошибки, значительно меньше требуется контроля, и процесс идет более гладко. Однако срочные и мелкие задачи, когда ГОРИТ, клиент не должен накапливать (это плохо для его здоровья). Поэтому такие задачи тоже могут попасть на разработку, но с наценкой за срочность.
  3. Проекты, которые делали не мы.
    Мы очень редко берем на поддержку сторонние проекты. Много мелких проектов не соответствует глобальным целям и идеологии нашей компании. Жизнь за счёт саппорта IMHO, более стабильный, но скучный бизнес. Нет драйва и надрыва, что ли. Поэтому сторонние проекты берем крайне редко и неохотно. Критерии здесь такие (перечисляю в порядке приоритета):

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

Так вот, про проактивность.

По проектам в активной фазе поддержки, проактивную позицию должен занимать менеджер проекта. Он замотивирован в получении % от проектов. По проектам, по которым нет никаких работ, мы системно проходимся несколько раз в год и стараемся их разбудить. Это хорошая практика, приносящая свои плоды. Будит спящих клиентов, как правило, аккаунт-менеджер. Не всегда спящего клиента нужно будить 🙂

Сейчас ищут техподдержку:  Что это такое техническая поддержка сайта: что в неё входит

Работа с дизайном сайта

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

Нет, “с кондочка” вопрос дизайна не решить. Тут нужна работа юзабилиста, сео-специалиста и дизайнера. А еще лучше, работа интернет-маркетолога. Сайт – сложный инструмент продаж, который важно правильно настроить. То есть грамотно провести посетителя по сайту, дать ему нужную информацию, включить в воронку продаж, сподвигнуть на совершение определенных действий. Все это решается при помощи грамотной структуры сайта и правильного дизайна.

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

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

Самое важное. ретроспективы. разбор полётов

Это самая важная часть системы технической поддержки. Без нее будет накапливаться взаимное скрытое недовольство, которое перерастёт в один прекрасный день в конфликт. Виноват будет всегда web-разработчик. Всегда!

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

Довольно правильно делать с клиентом пересмотр сделанного за 2-3 месяца. Формально анализировать список задач и смотреть причины возникновения ошибок. Это могут быть формулировки, и в этом случае вы совместно должны решить, как вам улучшить постановку задач.

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

Без этого в долгосрочной перспективе вас сольют.

Ставить задачу в любой, даже в самой безумной формулировке

Это важный момент, который касается ответственности. Ответственность — штука обоюдоострая. Здесь есть несколько принципов, о которых мы договариваемся с клиентом. Как правило, с самими принципами клиент не будет спорить (они понятны и логичны), однако будет пытаться найти лазейку между принципами. Менеджер проекта, кстати, тоже.

  1. Говно на входе — говно на выходе.
    Тут понятно. Плохо поставленная задача с высокой степенью вероятности будет сделана неправильно.
  2. Без телепатии.
    То есть, вообще считаем, что по умолчанию телепатии нет. «Это же было очевидно» или «Я подразумевал что это будет само собой», к сожалению, не аргумент.
    Я считаю это правильным принципом. Однако в нем есть изъян. Это очень большая лазейка для недобросовестного менеджера проекта бесконечно тянуть деньги и делать одну и ту же задачу. Однако во-первых, клиент интуитивно чувствует, когда его доят, во-вторых — ему это очень сильно не нравится, и он вам обязательно про это скажет. А в-третьих, можно внедрить формальную процедуру разбора полётов, чтобы отлавливать подобные инсинуации.

    Но об этом — позднее.

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

    Грозовая туча: заказчик и менеджер студии.
    Список работ службы технической поддержки в ITConstruct

    Наверное, 70-80% рабочего времени менеджера тратится на то, чтобы въехать в задачу, уточнить формулировки, понять, на что она может повлиять, предложить более эффективные ходы, предусмотреть все риски или оценить задачу. Вполне возможно, что вместо того, чтобы отдать задачу в работу, менеджер будет названивать и задавать вопросы. Или вообще отговорит клиента делать ее. Да, нам не заплатят за то, что мы отговорили. И иногда очень сложно подобрать аргументы, чтобы отговорить. Но так — кармически правильнее. Впрочем, если наши аргументы не помогут — у нас не будет выбора, кроме как заткнуться и сделать как просили :).

  4. Мы понимаем, что двойных трактовок не избежать.
    На уровне здравого смысла это так. Опять же, тут есть лазейка как для менеджера, так и для клиента — «включить дурочку». Но если работать системно, то любителей шнырять в лазейки можно отловить и наказать, применить управляющее воздействие.
  5. В некоторых случаях для уточнения формулировок потребуется платная работа аналитика или программиста.
    В основном это касается больших задач или тех, где нужен эксперимент или рисёч. Или совсем уж запутанных постановок и явной дислексии.

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

Техническая поддержка веб-сайта

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

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

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

Техническая поддержка включает в себя следующие работы.

  1. Мониторинг срока окончания аренды хостинга и доменного имени и своевременное информирование клиента.
  2. Создание резервных копий сайта с определенной периодичностью, которая зависит от регулярности обновления информации на нем.
  3. Обнаружение и удаление вирусов на сайте.
  4. Сохранность всех данных для доступа к критически важным разделам для работы с сайтом.
  5. Ведение переговоров с компанией предоставляющей услуги хостинга.
  6. Исправление обнаруженных ошибок в процессе работы интернет-сайта.
  7. Добавление новых модулей и плагинов на сайт.
  8. Внедрение различных видов микроразметки и структурированных данных.

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

Для консультации, заказа услуги и уточнения нюансов воспользуйтесь формой обратной связи или позвоните по телефону 7(916)2969277.

Техническая поддержка сайта (администрирование веб-сервера)

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

Что это? У вас есть высоконагруженный сайт (например от 100 000 уникальных пользователей в месяц) или highload-система (например, веб-приложение с сотнями одновременных пользователей). И вам нужен человек-сисадмин, чтобы это работало.

Сейчас внимание! Чем это отличается от первого варианта? Объясняю. В первом варианте, есть ребята, которые подключатся если оно сломается. В этом варианте — если ребят не будет, оно точно сломается, причем не через месяц, а скорее всего дня через два.

Что забавного в этой задаче?

1. Первая забавная история заключается в том, что 99% студий, которые якобы могут оказать эту услугу, на самом деле оказать нее не могут. Просто потому, что для ее оказания должен быть дежурный 24/7 администратор. А с учетом ТК РФ таких людей в компании должно работать минимум трое. И, к вашему сведению, хороший сисадмин — это крайне недешевое удовольствие.

2. Вторая проблема — клиенты обычно начинают искать исполнителей на такую услугу в тот момент, когда уже все стало плохо. Типичный пример — звонок в офис 5 декабря: “Ребят, посмотрите, у меня интернет-магазин и он что-то стал подтормаживать.” Ты смотришь, а там сервер на последнем издыхании, а проблема в спагетти-коде, из которого сайт состоит более чем наполовину.


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

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

Техподдержка сайта за абонентскую плату

Задача услуги: сделать так, чтобы ваш сайт работал.


Другими словами: за сравнительно небольшую сумму вы получаете лицо (в данном случае юридическое), которое несет ответственность за работоспособность вашего сайта.

Так, стоп.

Какая Леночка, какой Сергей? Если у вас есть договор на услугу “Техническая поддержка сайтов на битрикс” такая ситуация в принципе невозможна. А если договора нет, то вы, скорее всего, даже не знаете, как зовут чувака с бородой, который раз в месяц появляется в вашем офисе за зарплатой. Так что вы начинаете бегать по офису и выяснять, кто, мать его, отвечает за то, чтобы сайт работал.

Сейчас ищут техподдержку:  Инструкция РИА «Воронеж»: госуслуги. Как подать онлайн-заявление о регистрации брака. Последние свежие новости Воронежа и области - РИА Воронеж


Простите, опять занесло.

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

  • Коммерческий мониторинг вашего сайта (примечание 1)

  • Ежедневные бекапы (статья тут)

  • Дежурного администратора, который будет дрючить провайдера на тему “почему упал сервак” (если у вас шаред или, другими словами, обычный хостинг)

  • Дежурного администратора, который поднимет ваш сервер, если у вас сервак или виртуалка.

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

В реальной жизни, благодаря данной услуге, сайт работает, а в случае очень серьезного форс-мажора у вас звонит телефон, и вы слышите в трубке: “Архип Геннадьевич, добрый день. Это Аристарх, дежурный администратор из компании Nowmedia. Мы отвечаем за работоспособность вашего сайта.

Сейчас сайт не работает, проблемы на линии у хостинг-провайдера. Они обещают решить проблему в течении 40 минут. Если через 2 часа не решат, развернем ваш сайт на резервном сервере. Подготовительные работы уже начали проводить”. Т.е. вы понимаете, что да, есть проблема, но есть кто-то, кто занимается ее решением. По моему, прекрасно.

Техподдержка сайта за абонентскую плату плюс часы

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

То есть, предполагается, что у вас в компании есть какой-то человек, который отвечает в лучшем случае за маркетинг, а в худшем — за PR, и ему периодически нужно сделать что-то по сайту: нарисовать баннер, разместить новость, поменять цвет кнопки. Соответственно за “плюс часы” он может обратиться к сотрудникам агентства, и те помогут.

Точных оценок

По большинству проектов технической поддержки оплата идет по фактически затраченному времени. Задача менеджера — дать предварительные оценки трудоёмкости и выяснить у клиента, делаем задачи или нет. В случае, если мы начинаем отклоняться от оценки (например, нашлась какая-либо особенность у проекта, которая не дает нам закончить работу в срок), обязанность менеджера — предупредить клиента, сообщить новые прогнозы по оценкам и уточнить, делаем задачи или нет. Раздувать сроки и оценки особого смысла нет, т.к. клиент это чувствует и выскажет нам это при опросе удовлетворенности.

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

Замечу, что работа по time&material на практике для клиента быстрее и дешевле, однако возможна только если клиент доверяет и доволен. Нам это тоже выгодно, т.к. сокращает затраты на менеджмент и бюрократию (а менеджер, напомню, у нас бутылочное горлышко системы).

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

Если вас всерьез интересует вопрос точных оценок — в конце статьи я там насколько ссылок.

Хочу ставить задачи через любой удобный канал (скайп, телефон, вотсап, смс-ку). в любое время дня и ночи

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

А это экономически нецелесообразно и морально тяжело. На все проекты по техподдержке мы заводим единую систему хранения задач клиента. Таскменеджер. Там же идет их уточнение, оценки и проставляются статусы. Что это будет технически за система — не так важно (оперативную работу можно организовать и в Google Docs и в портале Битрикса).

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

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

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

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

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

Чем занимается специалист техподдержки?

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

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

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

Итого

Спрос на техническую поддержку сейчас значительно превышает предложение. Особенно в кризис многие будут стремиться «подлатать сайт», а не стартовать какие-то серьезные работы. Тем не менее, организовать работы грамотно, чётко и рентабельно здесь ОЧЕНЬ сложно.

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

Пожалуй, мне остается пожелать удачи в поиске баланса между созданием нового и поддержкой старого!

Выводы:

1. Если у вас просто есть сайт — наймите кого-то, кто будет просто обеспечивать его работоспособность. Если вам, конечно, не все равно, работает ваш сайт или нет. А если все равно — перестаньте платить за домен и хостинг.

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

3. Если вы корпорация и вам нужны руки, такая услуга тоже есть. Иногда к рукам прикладываются мозги (за отдельную плату, разумеется).

4. Если вы падаете — вам нужен сисадмин.

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

1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (Пока оценок нет)
Загрузка...

Оставьте комментарий

Adblock
detector