Чи повинні інженери програмного забезпечення також виступати в якості технічної підтримки? [зачинено]

Чи повинен інженер програмного забезпечення також виступати в якості технічної підтримки? Тобто, якщо компанія дозволить інженерам носити капелюхи програмного забезпечення та технічну підтримку. Здається, це позбавило б можливості писати програмне забезпечення, якщо значну частину часу інженера зайняла технічна підтримка.

Це класичне питання в компаніях, які в своїй роботі є компонентом розробки програмного забезпечення, будь то програмні компанії чи ні. Я постійно борюся з цим.

Залучення розробників до виробничої підтримки

Плюси

• Бореться із синдромом «Розвиток у вакуумі» . Цінним є опромінення того, як користувачі використовують додаток. Поки я нарешті не побачив це молодим розробником, я не усвідомлював, що я такий хитрий розробник інтерфейсу. Все, що я піклувався, - це кодування, а не дизайн, аналіз чи перспектива користувача.
• Розробники, які не такі хороші, як вони думають, є, можуть бути приниженими (хоча немає жодної гарантії, що ви отримаєте цю користь; деякі біси справді забувають, егоїстичні і вперті).
• Розробники отримають знання про домен . Це дуже важливо, якщо ваші розробники з часом стануть кращими у виявленні та заповненні прогалин на етапі аналізу бізнесу (якщо припустити, що є) пропуски.
• Хороша підтримка є маркетинговим моментом. Якщо ви зробите це добре, клієнти прийдуть це оцінити. І добре всебічний розробник з комунікаційними навичками та знаннями доменів здатний зробити це добре. Однак я все-таки вважаю за краще, щоб програми були достатньо якісними, що їм не потрібна підтримка. Вища якість - це власна форма підтримки клієнтів (а також точка маркетингу).

Мінуси

• Призупинення фактор . Це помилка номер один, що поєднує роботу над проектом та підтримку, бар - жодна. Проекти заважають підтримці, а підтримка заважає проектам. Проекти залежать від кошторису та важливості прогресу, підтримка непередбачувана і може включати імпровізовану терміновість. Проекти базуються на графіку, підтримка - на заваді. Не щасливе поєднання, і дуже засмучує розробників справу.
• Не всі добре підтримують . Хтось із меншими досвідом роботи з додатком чи бізнесом, або хтось, чиї особистісні чи комунікативні навички такі, що вони краще захищені від доступу користувачів, можуть не працювати на підтримку.
• Неефективне використання ресурсів . У коментарях Френк Ширар зазначив, що розробник, який займається тривіальною підтримкою, може бути дорожчим, ніж техніка підтримки першого рівня.

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

Однак я також вважаю, що якби розробники зробили кращу роботу, створюючи надійні та інтуїтивні системи, у вас буде менше підтримки. Таким чином, це створює дивний круговий аргумент для змішування двох. Я думаю, що вам слід зробити, якщо вам доведеться зробити і те, і інше - це знайти способи уникнути їх одночасного внесення.

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

Підкреслюється, що ні.
Всі ми знаємо, як важко зупинити те, що ви робите, щоб поставити відповідь на запитання. Я відповідаю на телефони довідкової служби і пишу деякі додатки.

Я не можу зосередитись на вирішенні проблеми, тому що кожні 5 хвилин мені потрібно брати телефон. Жодна робота не робиться так добре, як це може бути, тому що я постійно замислююся над тим, що я можу зробити, щоб вирішити проблему, і я ніколи не працюю над програмуванням досить довго, щоб повністю реалізувати будь-яке рішення, яке у мене може бути.

Знову ж таки, я не міг наголосити на тому, наскільки важливо вміти зосередитись на тому чи іншому аспекті.

Я б ніколи не ставив розробника як підтримку першого рядка. Кількість перерв і кількість, яку вам доведеться повторити, змусять більшість розробників кричати RTFM і зависнути на наступну людину, яка дзвонить. Це не те, що потрібно вашим клієнтам, і це не те, що ви хочете, щоб ваші розробники мали терпіти.

У будь-якій посаді обслуговування клієнтів є певне правило. Для розлюченого, хто телефонує, перша людина, яка відповідає на телефон, помиляється. Чи є у них президент компанії, людина, яка розробила додаток, або менеджер з підтримки, не має значення. Як тільки клієнт отримає другу людину, яка може або не може знати, що вони роблять, клієнт зможе заспокоїтись і пояснити проблему більш чітко.

Це не середовище, яке ви хочете зберегти хорошими розробниками. Чи є цінність у тому, щоб розробник спілкувався з клієнтом щодо особливо складної проблеми, яка виходить за рамки "чому мій тримач чашки більше не працює"? Абсолютно. Але це вже після того, як запит на підтримку було перевірено через перший та другий рядки підтримки.

Це залежить від компанії.

Моя робота саме така . Я розробник програмного забезпечення, але оскільки ми досить невелика компанія, кожен розробник бере на себе "неофіційну" роль підтримки, яка зазвичай базується на власному програмному забезпеченні. Деяким розробникам доводиться надавати більше підтримки, ніж інші, залежно від ряду факторів, таких як кількість виробів, які вони розробили / відправили, наскільки багітні продукти та наскільки ефективні вони . Якщо ви зможете надати замовнику саме те, що їм потрібно для вирішення проблеми, він продовжуватиме повертатися до вас, щоб якнайшвидше вирішити проблеми. Меч з двома кінцями? Так. Ви страждаєте від зниженої продуктивності, але замовник задоволений і швидше залишається клієнтом. Це важливо для менших компаній.

У нас є команда підтримки систем, але через характер того, що ми робимо, вони в основному мають вирішувати проблеми, пов'язані з обладнанням. Особисто в меншій компанії ця проблема не є настільки руйнівною, як можна було б уявити. Звичайно, ви телефонуєте, намагаючись опрацювати якусь важливу особливість, але в той же час обслуговування клієнтівзначно покращується; вони можуть мати авторитетний голос, який знає (у багатьох випадках), як вирішити свою проблему замість того, хто має інформацію про секонд-хенд та сценарій підтримки. Якщо ви не зможете вирішити проблему там і далі, можете запевнити їх особисто, що ви реалізуєте виправлення їх помилки, або розглянути їх запит на функцію для майбутнього випуску. Ви можете отримати реальний відгук прямо від користувачів вашого програмного забезпечення, тому наступна версія може бути навіть кращою, ніж ви вже вважаєте, що це є.

Мені подобається думати, що щасливі клієнти створюють більш позитивний імідж вашої компанії, що зазвичай призводить до збільшення кількості клієнтів . І тому мені, як інженеру програмного забезпечення, подобається технічна підтримка.

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

Розробники повинні бути останньою лінією підтримки.

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

Якщо це дійсно велика проблема, ми почуємо це.

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

Моєю останньою роботою було саме це. Ми підтримували існуючі системи, а також писали нові за потребою. Це було тотальним лихом. Мене постійно перебивали б. Моя мораль була такою низькою, тому що розпочаті проекти займуть назавжди. Крім того, нам довелося перевозити пейджер на неробочу підтримку без додаткової оплати (це було у сфері охорони здоров’я). Я думаю, що рішенням (яке я запропонував своєму менеджеру в той час) було б мати передову технічну підтримку, і якщо це помилка в програмному забезпеченні, то переслати його розробникам. Потрібно сказати, що я протримався лише півтора року, поки нарешті не пішов на кращу роботу з розвитку!

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

Це повинно бути для коротких періодичних перерв, щоб не переривати актуальне завдання розвитку.

Є таланти та навички, необхідні для розробки програмного забезпечення, та таланти та навички, які вам потрібні, щоб бути ефективними при підтримці першого ряду. Я не знаю, що ці таланти мають якесь співвідношення.

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

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

Що стосується серйозного розвитку, забудьте про це, якщо є часті перебої. Моя дружина дуже скаржилася на те, що очікується одночасно робити розробку та підтримувати користувачів.

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

Я думаю, що найкраща загальна стратегія (без урахування розміру компанії чи курортів) - використовувати групи підтримки для усунення низькорослих фруктів та найпоширеніших проблем ("Ви намагалися вимкнути та ввімкнути?"). Інженери повинні працювати з клієнтами над складнішими проблемами, які потребують знання про те, як працює система, а також більш орієнтовану на розробників підтримку (API, інструменти для розробників тощо). Ви могли б змусити людей, які підтримують службу, «лісонів», але я вважаю, що це зазвичай більше клопоту, ніж варто.

Хоча я не думаю, що доцільно використовувати розробники як підтримку весь час, я думаю, що можна сказати, що девіз робить початкову підтримку програми. Сюди слід включити підтримку після години. Я також думаю, що може бути корисним, щоб вони регулярно планували підтримку додатків для своїх додатків.

Існує не що інше, як багаторазові 3AM дзвінки, щоб ви зрозуміли, який вплив мають певні дизайнерські рішення та / або ярлики на здатність людей підтримувати і підтримувати ваш код.

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

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

Я потрапив у цю пастку, коли приєднався до компанії з хорошою оплатою праці. Під час інтерв'ю мені сказали, що буде 70% розвитку та 30% підтримки, і я прийняв пропозицію. Можливо, саме зараз я працюю над компанією чи середовищем. Але насправді це 90% підтримки та 10% розвитку. Це вже пару років, коли я втратив хватку розвитку. Я шкодую, що прийняв цю пропозицію.

Але я відчуваю, що втратив хватку кодування більше нових технологій та рамок. Тепер я не знаю, з чого почати знову. Я продовжую готуватись, але цих прикладів helloworld недостатньо, щоб мати хороший практичний досвід, і мені справді важко оновити свої знання та досвід. Я навіть не можу залишити свою роботу, щоб почати спочатку через сімейні зобов'язання.

На жаль, я в глухому куті.

Будь ласка, не приймайте ролі, якщо вам це не подобається чи не цікавить.

Мінуси - якщо припустити, що вам доведеться мати справу безпосередньо з клієнтами.

1) Зіпсуйте своїх клієнтів

Якщо це підтримка першого / другого / третього рядка (я справді маю на увазі підтримку розмитої лінії), де розробники мають справу безпосередньо з клієнтами, то це велика проблема. Розробники мають набір навичок, необхідних для налагодження проблем або розробки рішень для вирішення проблем. Якщо клієнти мають повний доступ до розробників (розмита лінія) - це не зупиняє клієнтів "зловживати" цією пільгою - це призводить до розпещених, вимогливих та привілейованих клієнтів, які платять не більше, ніж будь-який інший клієнт.

2) обумовлюючи розробників брехнею та складання історій.

Кожен, хто мав справу з клієнтами, знає, що це необхідна умова - вміти їх брехати. Існує помилка з виправленням на 1 рядок, яку можна зробити за 5 хвилин. Особа, яка обслуговує клієнтів, була б навчена керувати сподіваннями клієнтів - на її вирішення знадобиться до 3 днів.

Як розробник, якщо вам доведеться мати справу безпосередньо з клієнтами, ви повинні продумати творчі способи заспокоїти або обдурити клієнтів, коли вашою основною роботою повинно бути вирішення технічних проблем та забезпечення впевненості в роботі системи.

3) Ваша автобіографія страждає.

Якщо ви не переходите від інженера-програмного забезпечення до бізнес-аналітика / ІТ-консультанта / управління проектами, ваше резюме страждає від технічного аспекту.

Платна підтримка, яка обертається серед команди, - це інша історія.

Плюси

1) Зупиніть витинанки від скуголення

Розробники, які роблять те, що вони ненавидять, змусять їх оцінити кодування набагато більше. У вас є програміст, який постійно лунає? Поставте їх на гарячу лінію на місяць.

Так, вони мають справу. Я любив, коли читав це питання? Мені подобалося, як це навіть питання (не те, що я ставлю під сумнів ваше право задавати питання ОП), але це досить риторично, тому що майже кожен Dev, якого я коли-небудь зустрічав, мав якийсь вид технічної підтримки, що мається на увазі в його або її функція роботи. Ви просто не можете цього уникнути. У більшості випадків ваша найбільш технічно сумісна людина не просто у вашому функціональному домі, але в плані ІТ загалом. Це дуже важко уникнути повністю.