Python conf in Kharkiv, Nov 16 with Intel, Elastic engineering leaders. Prices go up 21.10

Отношения девелопмента и саппорта

Ребята, всем привет.

Готовлюсь к докладу на тему взаимоотношений команд девелопмента и саппорта.

Очень нужно ваше мнение на тему того существуют ли проблемы в коммуникациии между командами/стереотипы/конфликты.

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

Пример: часто в команде саппорта жалуются на предвзятое отношение к себе как к «низшему звену» в компании (взято отсюда dou.ua/...​upport-engineer-position)
А вот девелоперы часто жалуются на некомпетентность саппорт инженеров и на неспособность их решать проблемы и инвестигейтить (это уже из личных отзывов моих знакомых)

Буду рада получить от вас любые мысли по этому поводу в комментариях

Ну и заполните плиз опрос на эту тему ниже

Для саппорт инженеров — forms.gle/gqJGcx8dL97MqN2h9

Для девелоперов/QA/PO/etc.. — forms.gle/aiBL65BrMbahiHtz8

*
Условно разделила поддержку на три линии в опросе:
1 линия — Некое единое окно для клиентов, где принимают и сортируют все входящие сообщения. На месте решаются типовые вопросы не требующие глубокого разбирательства (пример — изменить пароль для пользователя).
2 линия — Более продвинутый по техническим навыкам уровень, где специалисты уже заточены под то чтобы решать более сложные задачи имея под руками необходимый инструментарий (системы мониторинга, admin-панель приложения, базу данных и т.д)
3 линия — Специализированная линия поддержки, сосредоточенная на конкретных технологиях и приложениях. Они могут и предоставить глубокий инвестигейшн и код поправить если нужно.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

1, 2 лінію автоматизувати. Бомжів-техсаппортерів — звільнити або перекваліфікувати у тестувальників.

На 3 ставити девелоперів позмінно. Чим швидше вони відчують біль від власного говнокоду, тим краще почнуть писати.

Або звільняться.

Если серьёзно, проблема ТОЛЬКО в организации. Нет никакого конфликта. Есть дебилизм и самодурство в управлении людьми. А саппорт — не более чем контрольная точка, в которой это всё можно измерить, и... подделать результаты для показания кто виноват, а менеджмент няшечки.

Нихера не знаю. Готовлю доклад. Помоги мне онанимус

Отсутствие процессов или их неясность + проблема с документацией

Что служит барьером между саппорт и дев коммандой? Есть ли он? Эффективен ли он?

Обычно описания в рамках ETIL или high level common sense .
Девелоперы говорят что саппорт спрашивает тупые вопросы / что это было в доках / «и так ясно» / гугли

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

Какие логи нужно посмотреть? Какие выводы нужно сделать? Какие проверки можно сделать? Что запросить еще? Как связаны компоненты ? Кто из коллег в саппорте это знает? Сколько раз пропустили ответы на типичные вопросы? Почему девы не довольны и упоминали ли данный набор евиденсов раньше? Возникал данный вопрос раньше и что запрашывали в прошлый раз?

Проанализировать, собрать инфу и улучшить

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

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

Спасибо! Все по полочкам. Добавить нечего)))

«Ленивый» саппорт или «ленивый» девелопмент — не случайность ни для тех, ни для других — а скорее всего отсуствие четких процессов в командах, и это вопрос уже к менеджменту.

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

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

Ленивый саппорт — это посредственное состояние. Саппорт должен быть супер-ленивый, настолько, чтобы заставить разрабов сделать всё настолько ОЖИДАЕМО работающим, чтобы саппорт не приходилось беспокоить, разве что подсказать куда смотреть в RTFM.

Только очень ленивый саппорт заставит написать это самое TFM, и качественно, не «на отъепись».

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

— Товарищ сисадмин, а когда нам дадут проверить воспроизводимость проблемы в клиентском окружении?
— Никогда, товарищ саппорт. Это — IT!

Ахаха. Вопросы доступов для команды саппорта это и правда больная тема))

А то. Я же три года руководил таким отделом и знаю что по чем

Уничтожь базу знаний — не пожалеешь.
Зачем? Да чтобы баги наконец ИСПРАВИЛИ, а не искали как за 8-12 часов устранить последствия того, что можно было исправить за 15 минут в коде.

Дропни прод — не пожалеешь

С этим и без тебя справятся.
Заставить же вычистить кеш старого дерьма, которое ни разу не актуально, но тормозит РЕШЕНИЕ проблем наличием воркэраундов [особенно тех которые не работают, но в базе есть] — задача непосильная. В отличие от полной вычистки авгиевых конюшен.

И кто будет оплачивать банкет?

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

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

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

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

1. Разработчик получает деньги за разработку. Его задача писать код, а не регулярно объяснять саппорту, какую информацию собрать и что и как работает. Для этого есть заблаговременно подготовленные командой разработчиков Workshops & TOI для support команды.

2. Support получает деньги за качественное и своевременное (по SLA) решение проблем клиента.

Ожидается, что команда support-а:

— Не будет заниматься пинпонгом между клиентом и разработчиками
— Не будет задавать вопросы ответы на которые гуглятся в течении пары минут
— Не будет по первой же прихоти клиента звать разработчиков на live сессию без предварительно проделанной работы со своей стороны
— Всегда будет воспроизводить проблему на своем environment-е
— Будет технически компетентна в рамках стэка технологий, используемых продуктом.
— Будет неуклонно следовать регламенту по предоставлению необходимой информации и открытию кейсов на разработчиков.
— Читать оффициальную документацию внимательно и улучшать ее via doc improvement

И это все надо делать в рамках установленного SLA.

Достойный и развернутый комментарий. Спасибо! Я бы уточнила только что задача разработчика не только писать код, но и фиксить его. А вот тут уже вступает в силу Ваше замечание на счет того, в каком формате должен быть саппортом предоставлен баг (steps to reproduce, screenshots, errors from the log, bla-bla-bla).
Ну и уж конечно это невообразимо круто когда документация и воркшопы от разработчиков это норма жизни, что далеко не всегда встречается в наших компаниях. В реальной жизни это что-то из области фантастики и единорогов, к моему большому сожалению.

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

задача разработчика не только писать код, но и фиксить его.

prod issue != bug

Да я вроде и не утверждала что это равнозначно.
Мне кажется, это и так всем понятно что prod issue это понятие сильно шире. Да и работа саппорта в том, чтобы отделить зерна от плевел (тоже вроде очевидно).
Но вообще никогда не «дергать девелоперов» это утопия. Баги то все равно бывают

это утопия

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

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

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

согласна — хорошо поставленный процесс решает все. только процентное соотношение компаний с хорошо поставленным процессом очень низкое ИМХО

Так а причем тут саппорт тогда? Если вместо отработанных процессов в компании процветает Sales Driven Development, то всем плохо — что саппорту, что девелопменту.

Плохо всем, да. Но мы не всегда можем изменить политику компании, правда же?
А вот изменить что-то в своем отделе, чтобы стало чуть лучше можем. И чтобы все поняли, что мы в одной лодке — тоже можем.
В том-то и вся суть, что ни девелопмент, ни саппорт не виноваты, а часто винят друг друга. Контрпродуктивно как-то получается.
Помогать друг другу надо.
Мир во всем мире, бла-бла-бла)

И чтобы все поняли, что мы в одной лодке — тоже можем.

В одной лодке только те, которым уйти некуда. Остальных рано или поздно подберет какой-нить лайнер.

А по теме:
Если у вас саппорт с девелопментом не может договориться, найдите им модератора, и все разговоры только через него. Пусть у саппорта собирает баг-репорты и фича-реквесты, приоризирует и отдает в девелопмент. Пусть у девелопмента собирает статус-репорты, релиз-ноты и what’s new и отдает в саппорт. И исключить прямое общение (хотя они и сами исключат с удовольствием, будут друг друга к модератору посылать, чтобы не отвлекаться лишний раз).

саппорт саппорту рознь -_-
Если девелопер жалуется на то, что саппорт ленивый, может дело в саппорте а не стереотипе?
И наоборот

Я этого не отрицаю, более того я лично сталкивалась и с «ленивым» саппортом и со стереотипами. Так что согласна — черного и белого в этом вопросе не существует. Именно потому и интересуюсь мнением общественности)

А может он сам ленивый, и ему надо на кого-то спихнуть чувство вины за свои недоработки?

Фраза «и наоборот» это подразумевает

Проблема только одна, саппорт ленится и работает форвард-машиной для запросов от юзеров сразу к разработчикам

сталкивалась с таким. и это неприятно — согласна

Возьми дрын, так оно проще решается

Форвардишь это к руководству саппорта с пометкой «два наряда вне очереди этому господину»

Подписаться на комментарии