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

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

Владимир Завертайлов

Главный бармалей Сибирикс

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

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

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

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

Внутренняя кухня техподдержки

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

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

Грозовая туча: старые и новые проекты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что клиенты хотят от услуги техподдержки в идеале?

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

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

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

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

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

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

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

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

Развитие проектов, разработанных у нас
Проекты, которые мы реализовали, часто остаются с нами на многие годы. Развиваются и эволюционируют. Обычно мы добавляем новые функции спринтами (от 60 часов). Нам удобнее и дешевле сделать один большой блок работ, чем 100 500 мелких-срочных задач: экономится время менеджера, меньше рисков допустить ошибки, значительно меньше требуется контроля, и процесс идет более гладко. Однако, срочные и мелкие задачи, когда ГОРИТ, клиент не должен накапливать (это плохо для его здоровья). Поэтому такие задачи тоже могут попасть на разработку, но с наценкой за срочность.

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

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

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

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

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

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

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

Говно на входе — говно на выходе
Тут понятно. Плохо поставленная задача с высокой степенью вероятности будет сделана неправильно.

Без телепатии
То есть вообще считаем, что по умолчанию телепатии нет. «Это же было очевидно» или «Я подразумевал, что это будет само собой», к сожалению, не аргумент.

Я считаю этот принцип правильным. Но в нем есть изъян — очень большая лазейка для недобросовестного менеджера проекта, позволяющая бесконечно тянуть деньги и делать одну и ту же задачу. Однако, во-первых, клиент интуитивно чувствует, когда его доят. Во-вторых — ему это очень сильно не нравится, и он вам обязательно про это скажет. А в-третьих, можно внедрить формальную процедуру разбора полётов, чтобы отлавливать подобные инсинуации. Но об этом — позднее.

Полученное задание должно быть проанализировано с точки зрения выполнимости, целесообразности, полноты и ресурсов
Наверное, 70−80% рабочего времени менеджера тратится на то, чтобы въехать в задачу, уточнить формулировки, понять, на что она может повлиять, предложить более эффективные ходы, предусмотреть все риски или оценить задачу.

Вполне возможно, что вместо того, чтобы отдать задачу в работу, менеджер будет названивать клиенту и задавать вопросы. Или вообще отговорит клиента делать ее. Да, нам не заплатят за то, что мы отговорили. И иногда очень сложно подобрать аргументы, чтобы отговорить. Но так — кармически правильнее. Впрочем, если наши аргументы не помогут, у нас не будет выбора, кроме как заткнуться и сделать как просили :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

проект на поддержке;
понятно по шагам, как ошибку воспроизвести;
обеим сторонам очевидно, что это — ошибка разработки (реализации).

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

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

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

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

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

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

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

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

0−8h на приемку и уточнение задачи. Менеджер получает уведомление о создании новой задачи. Банальный деловой этикет и принцип пустого инбокса требует, чтобы в течении суток все такие обращения были обработаны. Далее, в зависимости от срочности — задача может быть либо отложена до формирования спринта, либо экстренно запущена в работу, либо запланирована на программиста на следующий день. Либо, если формулировки неясны, — начинаем работу над выяснением формулировок. Формально, здесь у менеджера есть лазейка «включить дурочку» и долго-долго чего-то не понимать и уточнять. Однако клиенты это чувствуют, становятся крайне недовольными в таких ситуациях и непременно скажут вам об этом. Останется только разобраться в причинах и применить управляющее воздействие.
8−16h на старт работ. Обычно через сутки после того, как задача попала менеджеру проекта и все формулировки понятны, она попадает на разработку. Это связано с тем, что мы планируем, какими проектами будет заниматься каждый программист на утренних планерках (в 8:45) и затем уже стараемся не отклоняться от этого плана. Как правило, задача от клиента попадает в план на разработку на следующий день после постановки (но бывает, что и в тот же день).
16−24h на сами работы. В большинстве случаев мелкие задачи задачи выполняются и отгружаются клиенту за первые 8−16 часов. Еще 8 часов — резерв для выравнивания нашего потока работ или тестирования.

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

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

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

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

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

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

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

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

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

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

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

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

Итого

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

Все это в противовесе с возможностью спокойно делать новые и интересные проекты на новых неизведанных технологиях :)

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