Czy inżynierowie oprogramowania powinni również działać jako wsparcie techniczne? [Zamknięte]

Czy inżynier oprogramowania powinien również działać jako wsparcie techniczne? To znaczy, jeśli firma zezwoli swoim inżynierom na noszenie zarówno czapek dla inżyniera oprogramowania, jak i pomocy technicznej. Wydaje się, że wyeliminowałoby to możliwość pisania oprogramowania, gdyby pomoc techniczna zajęła znaczną część czasu inżyniera.

Jest to klasyczny problem w firmach, które mają w swojej pracy komponent programistyczny, niezależnie od tego, czy są to firmy programistyczne, czy nie. Cały czas mam z tym problem.

Zaangażowanie programistów we wsparcie produkcji

Plusy

• Zwalcza syndrom „rozwoju w próżni” . Warto zapoznać się ze sposobem korzystania z aplikacji przez użytkowników. Dopóki w końcu nie zobaczyłem tego jako młodego programisty, nie zdawałem sobie sprawy z tego, jak bzdurnym jestem deweloperem interfejsu użytkownika. Jedyne, na czym mi zależało, to kodowanie, a nie projektowanie, analiza czy perspektywa użytkownika.
• Programiści, którzy nie są tak dobrzy, jak im się wydaje, mogą być upokorzeni (chociaż nie ma gwarancji, że dostaniesz tę korzyść; niektórzy deweloperzy są naprawdę nieświadomi, samolubni i uparci).
• Programiści zdobędą wiedzę na temat domen . Ma to kluczowe znaczenie, jeśli programiści mają w końcu lepiej zidentyfikować i uzupełnić luki w fazie analizy biznesowej (zakładając, że występują).
• Dobre wsparcie to punkt marketingowy. Jeśli zrobisz to dobrze, klienci to docenią. A dobrze przygotowany programista posiadający umiejętności komunikacyjne i wiedzę domenową może to zrobić dobrze. Jednak nadal wolałbym, aby aplikacje były wystarczająco wysokiej jakości, aby nie wymagały wsparcia. Najwyższa jakość to własna forma obsługi klienta (a także punkt marketingowy).

Cons

• Współczynnik zakłócenia . Jest to wina numer jeden polegająca na łączeniu pracy nad projektem i pracy pomocniczej, bez żadnych ograniczeń. Projekty zakłócają wsparcie, a wsparcie zakłóca projekty. Projekty zależą od szacunków i postępów w realizacji kamieni milowych, wsparcie jest nieprzewidywalne i może wiązać się z pilną koniecznością. Projekty są oparte na harmonogramie, wsparcie jest oparte na przerwach. Niezbyt udana kombinacja i bardzo frustrująca dla programistów.
• Nie wszyscy są dobrzy we wsparciu . Osoba, która ma mniejsze doświadczenie z aplikacją lub firmą, lub osoba, której osobowość lub umiejętności komunikacyjne są takie, że są lepiej chronione przed dostępem użytkowników, może nie działać dobrze w zakresie wsparcia.
• Nieefektywne wykorzystanie zasobów . Frank Shearar zauważył w komentarzach, że deweloper wykonujący trywialne wsparcie może być droższy niż pomoc techniczna pierwszego poziomu.

Z mojego doświadczenia wynika, że ​​większość programistów nie lubi wsparcia. Służąc zarówno po stronie projektu, jak i wsparcia, mogę współczuć. Gdy konieczne jest wykonanie obu tych czynności jednocześnie, czynnikiem łagodzącym jest często praca w godzinach nadliczbowych, zwykle nieopłacana, aby poradzić sobie z sytuacjami awaryjnymi i nadal dotrzymywać terminów projektu. Kierownicy projektów uwielbiają nieopłacane nadgodziny, ponieważ oznacza to umawianie się na randki bez ponoszenia większych kosztów, ale dla deweloperów jest to po prostu wielka miska ssania.

Uważam jednak, że gdyby programiści wykonali lepszą pracę, tworząc niezawodne i intuicyjne systemy, mielibyście mniejsze wsparcie. Stwarza to dziwny okrągły argument za zmieszaniem tych dwóch. Myślę, że powinieneś zrobić, jeśli musisz zrobić obie rzeczy, to znaleźć sposoby na uniknięcie jednoczesnego działania.

Myślę, że programiści już noszą dwie czapki. Wsparcie jest bardziej jak filtr używany do ochrony rozwoju przed trywialnymi problemami, takimi jak brak podłączonego komputera. Jednak powinno istnieć ścisłe powiązanie między rozwojem a wsparciem. Niektórzy klienci mają uzasadnione problemy, które mogą być wynikiem błędu. Odpowiedzialnością za rozwój powinno być jak najszybsze rozwiązanie tych problemów. W pewnym sensie programiści są już częścią zespołu wsparcia ... nazwij to wsparciem poziomu 2.

Zdecydowanie nie.
Wszyscy wiemy, jak trudne może być powstrzymanie tego, co robisz zadać odpowiedź na pytanie. Odpowiadam na telefony pomocy technicznej i piszę aplikacje.

Nie mogę się skupić na rozwiązaniu problemu, ponieważ co 5 minut muszę odbierać telefon. Żadna praca nie jest wykonywana tak dobrze, jak to możliwe, ponieważ ciągle myślę o tym, co mogę zrobić, aby rozwiązać problem, i nigdy nie pracuję nad programowaniem wystarczająco długo, aby w pełni wdrożyć dowolne rozwiązanie.

Ponownie nie mogłem wystarczająco podkreślić, jak ważne jest, aby móc skupić się na jednym lub drugim aspekcie.

Nigdy nie umieściłbym programisty jako wsparcia pierwszej linii. Liczba przerw i ilość powtórzeń spowoduje, że większość programistów zacznie krzyczeć RTFM i rozłączania się z następną osobą, która dzwoni. Nie jest to coś, czego Twoi klienci potrzebują, ani tego, czego oczekujesz od programistów.

W każdej pozycji obsługi klienta istnieje pewna zasada. Dla zirytowanego dzwoniącego pierwsza osoba, która odbiera telefon, jest błędna. Bez względu na to, czy mają prezesa firmy, osobę, która opracowała aplikację, czy menedżera wsparcia, nie ma to znaczenia. Gdy klient otrzyma drugą osobę, która może wiedzieć, co robi, może nie być w stanie się uspokoić i wyjaśnić problem.

To nie jest środowisko, w którym chcesz zatrzymać dobrych programistów. Czy warto mieć kontakt programisty z klientem w szczególnie trudnym problemie, który wykracza poza „dlaczego mój uchwyt na kubek już nie działa”? Absolutnie. Ale to po tym, jak prośba o wsparcie została zweryfikowana przez linie wsparcia pierwszego i drugiego poziomu.

To zależy od firmy.

Moja praca jest dokładnie taka . Jestem programistą, ale ponieważ jesteśmy dość małą firmą, każdy programista przyjmuje „nieoficjalną” rolę wspierającą, zwykle opartą na własnym oprogramowaniu. Niektórzy programiści muszą udzielać większego wsparcia niż inni, w zależności od szeregu czynników, takich jak liczba produktów, które opracowali / wysłali, stopień wadliwości ich produktów i skuteczność ich wsparcia . Jeśli możesz dostarczyć klientowi dokładnie to, czego potrzebuje, aby rozwiązać problem, będzie do ciebie wracał, aby jak najszybciej rozwiązać problemy. Miecz obosieczny? Tak. Cierpisz na zmniejszoną produktywność, ale klient jest zadowolony i istnieje większe prawdopodobieństwo, że pozostanie klientem. Jest to ważne dla mniejszych firm.

Mamy zespół wsparcia systemów, ale ze względu na charakter tego, co robimy, w większości muszą zajmować się problemami sprzętowymi. Osobiście w mniejszej firmie ten problem nie jest tak uciążliwy, jak można sobie wyobrazić. Pewnie, że dzwonisz, gdy próbujesz wypracować jakąś ważną funkcję, ale jednocześnie obsługę klientajest znacznie ulepszony; mogą mieć autorytatywny głos, który wie (w wielu przypadkach), jak rozwiązać swój problem, zamiast kogoś z używanymi informacjami i skryptem wsparcia. Jeśli nie możesz rozwiązać problemu w tym miejscu, możesz zapewnić ich osobiście, że zaimplementujesz poprawkę dotyczącą ich błędu, lub rozważysz prośbę o ich funkcje w przyszłej wersji. Możesz uzyskać prawdziwą informację zwrotną od użytkowników twojego oprogramowania, więc twoja następna wersja może być jeszcze lepsza niż myślisz.

Lubię myśleć, że zadowoleni klienci tworzą bardziej pozytywny wizerunek Twojej firmy, co zwykle prowadzi do większej liczby klientów . I dlatego jako inżynier oprogramowania lubię wsparcie techniczne.

Nie ma nic bardziej frustrującego niż wsparcie ze strony informatyków, którzy nie chcą cię spotkać z kimś, kto naprawdę rozumie, co się dzieje. Mam nadzieję, że każda duża firma aplikacyjna będzie miała programistów, którzy będą pracować z pomocą techniczną.

Deweloperzy powinni być ostatnią linią wsparcia.

Tylko wtedy, gdy dział pomocy technicznej i nasz dział kontroli jakości nie będą w stanie pomóc klientowi, będziemy mieli problemy. I nawet wtedy musi przejść przez nasz priorytetowy system śledzenia błędów.

Jeśli to naprawdę duży problem, usłyszymy to.

Zrobiłbym to tylko, jeśli jest to nowy programista lub taki, który nie zna domeny i bazy klientów. Uczynienie go trwałym nie jest dobrym pomysłem.

Moja ostatnia praca była dokładnie taka. Wspieraliśmy istniejące systemy, a także pisaliśmy nowe w razie potrzeby. To była totalna katastrofa. Byłbym ciągle przerywany. Moje morale było tak niskie, ponieważ rozpoczęte projekty trwałyby wieczność. Ponadto musieliśmy nosić ze sobą pager w celu uzyskania wsparcia poza godzinami pracy bez dodatkowej zapłaty (dotyczyło to opieki zdrowotnej). Myślę, że rozwiązaniem (które wówczas zasugerowałem mojemu menedżerowi) byłoby skorzystanie z pierwszej linii wsparcia technicznego, a jeśli jest to błąd oprogramowania, przekaż je dalej programistom. Nie trzeba dodawać, że przetrwałem tylko półtora roku, aż w końcu wyszedłem na lepszą pracę rozwojową!

Czasami zdecydowanie tak. Zwrócenie się do klienta często daje perspektywę, której brakuje większości ludzi, zwłaszcza programistów. To, jak użytkownik faktycznie korzysta z produktu lub myśli, jest często dalekie od tego, jak myśli konstruktor (inżynier).

Powinno to odbywać się na krótkie okresowe okresy, aby nie zakłócać faktycznego zadania rozwoju.

Istnieją talenty i umiejętności potrzebne do opracowania oprogramowania, a także talenty i umiejętności potrzebne do skutecznego wsparcia pierwszej linii. Nie wiem, czy te talenty mają jakikolwiek związek.

Oznacza to, że albo musisz zatrudnić programistów częściowo na podstawie ich zdolności do obsługi telefonicznej, albo pozwalasz swoim klientom bezpośrednio rozmawiać z ludźmi, którzy nie są dobrzy w obsłudze klientów i nie chcą tego robić w pierwszej kolejności. To może, ale nie musi być lepsze niż rozmowa z facetem z grubym indyjskim akcentem, który czyta z grzecznego scenariusza.

Ponadto, jeśli sprawisz, że praca będzie nieprzyjemna (i nie znam żadnych programistów, którzy faktycznie lubią wsparcie pierwszej linii), niektórzy z twoich programistów odejdą. Są to na ogół ci, którzy mogą łatwiej znaleźć inne miejsca pracy: dobre. W trakcie tego procesu kończy się sklep wypełniony mniej utalentowanymi ludźmi, co sprawia, że ​​kompetentni są jeszcze mniej przyjemni, aby przejść obok pierwszej oferty pracy innej osoby.

Jeśli chodzi o poważny rozwój, zapomnij o tym, jeśli występują częste przerwy. Moja żona dużo narzeka na to, że oczekuje się, że będą jednocześnie tworzyć i wspierać użytkowników.

Myślę, że wiele z tego zależy od firmy. Twoja typowa firma BigCo zazwyczaj może sobie pozwolić na wsparcie dla osób izolujących programistów. Z drugiej strony, starcie z trzech osób, w sumie po prostu nie mają środków, aby zapewnić odrębne osoby wspierające.

Uważam, że najlepszą ogólną strategią (bez względu na wielkość firmy lub wyniki) jest użycie zespołów wsparcia w celu rozwiązania problemów z wiszącymi owocami i najczęstszymi problemami („Czy próbowałeś go wyłączyć i włączyć?”). Inżynierowie powinni współpracować z klientami przy trudniejszych problemach, które wymagają wiedzy o tym, jak działa system, a także wsparcia zorientowanego na programistów (interfejsy API, narzędzia programistyczne itp.). Mógłbyś, żeby osoba wspierająca działała jak „liason”, ale uważam, że zwykle jest to większy problem niż jest wart.

Chociaż nie uważam, że należy używać deweloperów przez cały czas jako wsparcia , myślę, że jest coś, co można powiedzieć o tym, że programista obsługuje początkową obsługę aplikacji. W szczególności powinno to obejmować wsparcie po godzinach. Sądzę też, że może być przydatne, aby regularnie planować obsługę ich aplikacji po godzinach.

Nie ma to jak wiele wywołań 3AM, aby uświadomić sobie, jaki wpływ mają pewne decyzje projektowe i / lub skróty na zdolność ludzi do obsługi i utrzymania twojego kodu.

Idealnie nie z powodów wymienionych powyżej, ale tak, gdy projekt się rodzi, ponieważ programiści mogą zapewnić szybkie rozwiązania, często oczekiwane przez biznes, co stanowi wsparcie dla ciągłego doskonalenia oprogramowania. Cenię programistów, którzy zapewniają inteligentne wsparcie: tych, którzy wykorzystują swoje umiejętności analityczne, dając przykład bardziej formalnemu zespołowi wsparcia w pełnym wymiarze godzin, oraz tych, którzy odpowiadają na biznes w taki sposób, aby pokazać ducha usług i współpracy. Kluczem do tego sukcesu jest jednak rozpoznanie przez kierownictwo i sformalizowanie wsparcia pierwszego i drugiego poziomu, aby szybko odciążyć programistów od ich krótkoterminowej roli. Programiści wykazujący się talentem zarówno do rozwoju, jak i wsparcia powinni być kultywowani jako wsparcie trzeciego poziomu lub wsparcie dla osób wspierających. Więc powinno jest zależny od czasu, talentu i pożądania oraz skutecznie zarządzany.

Moim zainteresowaniem było odpowiedzieć na trudne pytania dotyczące pomocy technicznej i wziąć to, czego się nauczyłem z tego doświadczenia, aby zmniejszyć ogólne zapotrzebowanie na wsparcie, które jest korzystne zarówno dla użytkowników końcowych, jak i podstawowego wsparcia.

Wpadłem w tę pułapkę, kiedy dołączyłem do firmy z dobrą płacą. Podczas wywiadu powiedziano mi, że będzie 70% rozwoju i 30% wsparcia i zaakceptowałem ofertę. Może to jest firma lub środowisko, nad którym obecnie pracuję. Ale tak naprawdę 90% wsparcia i 10% rozwoju. Od kilku lat straciłem kontrolę nad rozwojem. Żałuję, że zaakceptowałem tę ofertę.

Ale wydaje mi się, że straciłem już kontrolę nad kodowaniem wielu nowych technologii i ram. Teraz nie wiem od czego zacząć. Ciągle się przygotowuję, ale te przykłady z piekielnego świata nie wystarczą, aby mieć dobre doświadczenia praktyczne i naprawdę trudno jest zaktualizować moją wiedzę i doświadczenie. Nie mogę nawet odejść z pracy, aby zacząć od nowa z powodu zobowiązań rodzinnych.

Niestety jestem w impasie.

Nie akceptuj ról, jeśli Ci się nie podoba lub nie jesteś zainteresowany.

Wady - zakładając, że masz do czynienia bezpośrednio z klientami.

1) Rozpieszczanie klientów

Jeśli jest to wsparcie pierwszej / drugiej / trzeciej linii (naprawdę mam na myśli wsparcie linii rozmytej), w której programiści mają bezpośredni kontakt z klientami, to jest to duża wada. Programiści dysponują zestawem umiejętności wymaganych do debugowania problemów lub opracowywania rozwiązań problemów. Jeśli klienci mają pełny dostęp do programistów (niewyraźna linia) - nie można powstrzymać klientów przed nadużywaniem tego przywileju - skutkując zepsutymi, wymagającymi i uprzywilejowanymi klientami, którzy nie płacą więcej niż jakikolwiek inny klient.

2) Uwarunkowanie deweloperów od kłamstw i wymyślania historii.

Każdy, kto miał do czynienia z klientami, wie, że jest to warunek konieczny, aby móc ich okłamać. Wystąpił błąd z naprawą 1 linii, który można wykonać w 5 minut. Osoba obsługi klienta zostałaby przeszkolona w zakresie zarządzania oczekiwaniami klienta - aby zajęło to do 3 dni.

Jako programista, jeśli masz do czynienia bezpośrednio z klientami, musisz wymyślić kreatywne sposoby na uspokojenie lub oszukanie klientów, gdy Twoim głównym zadaniem powinno być rozwiązywanie problemów technicznych i upewnienie się, że system działa sprawnie.

3) Cierpi Twój Curriculum Vitae.

O ile nie zmienisz inżyniera oprogramowania na analityka biznesowego / konsultanta IT / zarządzanie projektami, twoje CV będzie cierpieć z powodu aspektu technicznego.

Płatne prace wspierające, które obracają się w zespole, to inna historia.

Plusy

1) Powstrzymaj Whiners od marudzenia

Programiści, którzy robią to, czego nienawidzą, znacznie bardziej docenią kodowanie. Masz programistę, który ciągle coś piszczy? Umieść je na infolinii na miesiąc.

Tak, ponieważ tak. Lol'd, kiedy czytam to pytanie? Podobało mi się, jak to jest w ogóle pytanie (nie to, że kwestionuję twoje prawo do zadawania pytania OP), ale jest dość retoryczne, ponieważ prawie każdy Dev, którego kiedykolwiek spotkałem, miał jakiś rodzaj wsparcia technicznego ukrytego w jego lub jej funkcja pracy. Po prostu nie da się tego uniknąć. W większości przypadków jesteś najbardziej technicznie kompatybilną osobą nie tylko w swojej domenie funkcjonalnej, ale ogólnie w zakresie IT. Bardzo trudno go całkowicie uniknąć.