Должны ли инженеры программного обеспечения выступать в качестве технической поддержки? [закрыто]

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

Это классическая проблема для компаний, которые имеют компонент разработки программного обеспечения в своей работе, независимо от того, являются ли они компаниями-разработчиками программного обеспечения или нет. Я борюсь с этим все время.

Вовлечение разработчиков в поддержку производства

Pros

• Бои "Развитие в вакууме", синдром . Очень важно узнать, как пользователи используют приложение. Пока я, наконец, не увидел это как молодой разработчик, я не понимал, насколько я был дурацким разработчиком пользовательского интерфейса. Все, что меня волновало, - это кодирование, а не дизайн, анализ или точка зрения пользователя.
• Разработчики, которые не так хороши, как они думают, могут быть унижены (хотя нет никакой гарантии, что вы получите эту выгоду; некоторые разработчики действительно забывчивы, эгоистичны и упрямы).
• Разработчики получат знание предметной области . Это очень важно, если ваши разработчики в конечном итоге станут лучше в выявлении и заполнении пробелов, которые пропускает фаза бизнес-анализа (при условии, что она есть).
• Хорошая поддержка - это точка маркетинга. Если вы делаете это хорошо, клиенты оценят это. И всесторонний разработчик с коммуникативными навыками и знанием предметной области способен сделать это хорошо. Однако я все же предпочел бы, чтобы приложения были достаточно высокого качества, чтобы они не нуждались в поддержке. Превосходное качество - это собственная форма поддержки клиентов (а также точка маркетинга).

Cons

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

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

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

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

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

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

Опять же, я не мог не подчеркнуть, насколько важно уметь фокусироваться на одном или другом аспекте.

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

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

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

Это зависит от компании.

Моя работа в точности такая . Я разработчик программного обеспечения, но поскольку мы довольно маленькая компания, каждый разработчик берет на себя «неофициальную» роль поддержки, обычно основанную на собственном программном обеспечении. Некоторым разработчикам приходится оказывать больше поддержки, чем другим, в зависимости от ряда факторов, таких как, сколько продуктов они разработали / отправили, насколько глючны их продукты и насколько они эффективны при поддержке . Если вы сможете предоставить клиенту именно то, что ему нужно для решения проблемы, он будет продолжать возвращаться к вам, чтобы решить проблемы как можно быстрее. Обоюдоострый меч? Да. Вы страдаете от снижения производительности, но клиент доволен и с большей вероятностью останется клиентом. Это важно для небольших компаний.

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

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

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

Разработчики должны быть последней линией поддержки.

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

Если это действительно большая проблема, мы ее услышим.

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

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

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

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

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

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

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

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

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

Я думаю, что лучшая общая стратегия (безотносительно к размеру компании или ресурсам) состоит в том, чтобы использовать команды поддержки для устранения проблем с низко висящими фруктами и наиболее распространенными проблемами («Вы пробовали выключать и включать?»). Инженеры должны работать с заказчиками над более сложными проблемами, которые требуют знания работы системы, а также поддержки, ориентированной на разработчиков (API, инструменты для разработчиков и т. Д.). Вы можете сделать так, чтобы сотрудник службы поддержки действовал как «обманщик», но я считаю, что обычно это больше проблем, чем оно того стоит.

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

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

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

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

Я попал в эту ловушку, когда присоединился к компании с хорошей оплатой. Во время интервью мне сказали, что будет 70% развития и 30% поддержки, и я принял предложение. Может быть, это компания или среда, над которой я сейчас работаю. Но на самом деле это 90% поддержки и 10% развития. Это было пару лет назад, я потерял контроль над развитием. Сожалею, что принял это предложение.

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

К сожалению, я в тупике.

Пожалуйста, не принимайте роли, если вам не нравится или не интересует.

Минусы - при условии, что вам приходится иметь дело напрямую с клиентами.

1) баловать своих клиентов

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

2) Подготовка ваших разработчиков к тому, чтобы они лгали и выдумывали истории.

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

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

3) Ваша биография страдает.

Если вы не переходите от инженера-программиста к бизнес-аналитику / ИТ-консультанту / управлению проектами, ваше резюме будет страдать от технического аспекта.

Платная вспомогательная работа, которая вращается среди команды, - это отдельная история.

Pros

1) Остановить нытиков от нытья

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

Да, потому что они делают. Я хотел бы, когда я прочитал этот вопрос? Я был похож на то, как это вообще вопрос (не то, что я подвергаю сомнению ваше право задать вопрос OP), но это довольно риторический вопрос, потому что почти у каждого разработчика, с которым я когда-либо встречался, была какая-то работа по технической поддержке, подразумеваемая внутри его ее работа функции. Вы просто не можете избежать этого. В большинстве случаев вы самый технически компетентный человек не только в вашей функциональной области, но и в плане ИТ в целом. Это очень трудно избежать полностью.