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.
organization
technical-support
staticx
źródło
źródło
Odpowiedzi:
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
Cons
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.
źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło
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ą.
źródło
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.
źródło
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.
źródło
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ą!
źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło
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ąć.
źródło