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

48

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.

staticx
źródło
2
Przez wsparcie techniczne, czy masz na myśli wspieranie konkretnych aplikacji, które opracowują, czy też ogólnych „administratorów systemu”? Mogę powiedzieć, że denerwujące jest działanie w małej firmie i zachęcanie ludzi do instalowania programu Excel.
Carlos
11
Powinniśmy? Nie. Czy my? Tak. Nienawidzę tego.
Rachel
7
Inżynier powinien zawsze dążyć do popełniania pozornie niewinnych błędów, które powodują więcej pracy dla osoby, która uważa, że ​​dobrym pomysłem byłoby użycie ich do wsparcia technicznego.
Erik Reppen

Odpowiedzi:

74

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.

Bernard Dy
źródło
1
Myślę, że wsparcie wsparcia dla projektu w fazie rozwoju nie jest złe. Rozmowa z klientem jest dobra. Ale jeśli pracujesz nad 7 projektami z 7 różnymi terminami i pilnością ... Po pewnym czasie nie jest to naprawdę dobre. to trochę źle ssać.
Loïc Faure-Lacroix
4
Widziałem także sklepy, w których programiści, którzy nie dotrzymują terminów, tylko wzruszają ramionami i mówią: „W tym tygodniu miałem dużo czasu na wsparcie. Bez błędów, użytkownicy potrzebowali tylko ręki”. Zazwyczaj nie było sposobu, aby stwierdzić, czy tak się dzieje, czy deweloper był po prostu powolny w tym tygodniu. Tak długo jak to kontrolujesz, jestem za programistami, którzy wspierają ich kod, ale nie jako wsparcie telefoniczne na linii frontu.
Kate Gregory
9
Powinna istnieć warstwa wsparcia na pierwszej linii, aby wychwytywać pytania RTFM, pozostawiając tylko pytania z przydatną treścią techniczną / opiniami dla programistów.
Robert Harvey
4
@Christopher: Systemy samoopisujące są miłym ideałem, do którego należy dążyć, ale trudne do osiągnięcia w praktyce. Istnieje wiele czynników i nacisków zainteresowanych stron, które spiskują przeciwko ich robieniu, i zawsze będą użytkownicy, którzy „nie rozumieją”.
Robert Harvey
1
Doskonała odpowiedź. Moja firma znajduje dobry środek - każdy deweloper spędza jeden dzień na pomocy technicznej trzeciej linii, obracając się w zespole. Jeśli jesteś na technologii, możesz zostać przerwany z rozsądku, ale wszyscy inni są odporni, chyba że pojawi się coś poważnego. Podczas naszych dni technicznych staramy się robić lżejsze naprawy błędów, rzeczy administracyjne itp., Aby uniknąć bycia złożonym, gdy są przerywane ... Więc w zasadzie wszyscy mamy dzień, aby robić bzdury, których nienawidzą programiści, ale muszą to robić, ale wiedz o tym od czasu do czasu otrzymujemy wezwania pomocy technicznej, aby je zlikwidować. Co ważniejsze, wspaniale jest wiedzieć, że przez resztę czasu jesteś odporny!
Jon Story
18

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.

Pemdas
źródło
18

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.

rev. IAbstract
źródło
+1 Mogę odnosić się do wszystkiego, co powiedziałeś. Kilka tygodni temu byłem w podobnej sytuacji. Teraz nie mamy telefonu, ale i tak pukają do drzwi, nawet dla takich rzeczy jak: „hej, widziałeś X w pobliżu?” rany!
jasonco
1
Możesz ustawić „godziny urzędowania”, aby uniknąć przerw. Wsparcie na telefon nie jest dobrym pomysłem.
JeffO
2
Zgodzeni, a także częściowo dysfunkcyjni programiści nie robią bardzo dobrych ludzi wsparcia :)
Homde
6
To kiepska odpowiedź moim zdaniem. Dev, który NIGDY nie wspiera, nigdy nie może dowiedzieć się, jak jego decyzje wpływają na użytkownika, dobre lub złe. Samo obserwowanie, jak ktoś próbuje korzystać z oprogramowania, może być dużym wyzwaniem, nawet jeśli uważasz, że pasuje do specyfikacji. Istnieją sposoby na złagodzenie negatywnych aspektów tego projektu, zmienianie harmonogramów wśród twórców, pomoc w obsłudze wezwań do wycofania, więc wspierasz tylko swoją aplikację itp. Jeśli masz twórcę, który „jest dysfunkcyjny”, musisz się zastanawiać, jak przydatne są tak naprawdę jest, jeśli nie mogą nawet rozmawiać z użytkownikiem. Nadzoruj w razie potrzeby, aby mogli się uczyć.
Jay
1
@BryanOakley: opracuj plan, który uzyska wsparcie techniczne. Chociaż nadal popieram moją odpowiedź, nierealistyczne jest oczekiwanie od początku posiadania całego personelu niezbędnego do odpowiedniego wsparcia i rozwoju klienta . Nadal zalecałbym, aby głównym zadaniem programisty był rozwój, a nie obsługa klienta. Problem polega na tym, że gdy deweloper ma bliskie powiązania z klientem, albo: (a) zawsze skontaktuje się z nim bezpośrednio klient zamiast odpowiednich kanałów technologicznych, albo (b) ostatecznie opracuje program specjalnie na potrzeby tego klienta, a nie szeroki zakres niezbędnego rozwoju.
IAbstract
10

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.

Berin Loritsch
źródło
Zappos zbudował imperium, które jest sprzeczne z regułą pierwszoosobową.
JeffO
Nie wiem o Zappos, ale wydaje się to wystarczające dla większości firm. Wiem tylko, że jeśli jestem wystarczająco sfrustrowany, aby zadzwonić do pomocy technicznej, szkoda mi osoby na drugim końcu linii.
Berin Loritsch,
Nigdy? Jak nigdy, nigdy? Nawet jeśli byłeś małą firmą złożoną ze sprzedawców i jednego lub dwóch programistów? Nawet jeśli Twoi programiści byli bardzo silnymi komunikatorami i lubili rozmawiać z klientami?
Bryan Oakley,
Chcesz, aby Twoi programiści byli postrzegani jako posiadający wiedzę - uczyń ich drugą osobą, z którą rozmawia klient. Do tego czasu klient uspokoi się i zachowa trochę bardziej rozsądnie. Teraz, jeśli jest to klient, z którym masz dobre relacje i nie jest to pierwsze wprowadzenie, które programista ma do klienta, byłoby idealnie. Pierwszy kontakt powinien jednak zostać najpierw sprawdzony przez kogoś innego.
Berin Loritsch,
Jako ktoś, kto był wsparciem pierwszej linii - myślę, że zasada „zirytowanego dzwoniącego, który myśli, że pierwsza osoba, która odbiera telefon, jest błędna” jest nieprawidłowa. Chociaż mogę mówić tylko z własnego doświadczenia . Od czasu do czasu zirytowany dzwoniący, który uważa, że ​​albo zdaje sobie sprawę ze swojego błędu ( o ile znajomość linii frontu jest rzeczywiście kompetentny ), albo po prostu nie szuka rozwiązania, a raczej kogoś, kogo można winić - co oznacza, że ​​nikt nie może im pomóc. Nadal się zgadzam - programiści powinni być ostatnim kontaktem, gdy tylko zostanie ustalone, że jest gdzieś błąd (lub duża możliwość jednego)
DoubleDouble
9

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.

badgerr
źródło
Jestem na tej samej łodzi co ty i całkowicie się z tobą zgadzam. Jednak powinno być możliwe i częściej, że recepcjonista odbierze połączenie i napisze notatkę, aby oddzwonić do tego klienta. W ten sposób możesz nie przeszkadzać w pracy i oddzwonić, kiedy najbardziej Ci odpowiada. Oddzwoń jednak tego samego dnia, najlepiej w ciągu 2 godzin po
nadejściu
3

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ą.

użytkownik1842
źródło
4
Istnieje pewne prawo z pomocą techniczną: pierwszy facet, który dostajesz, jest zawsze w błędzie. Może być najbardziej sprytną technicznie osobą w zespole, a ponieważ najpierw podniósł telefon, klient nie będzie mógł mu zaufać. Zasadniczo pierwszy facet istnieje, aby pozwolić klientowi odpowietrzyć i wyprowadzić dym, tak aby następny mógł być „wybawcą”. Tak jest w przypadku każdego zawodu obsługi klienta - nie tylko pomocy technicznej.
Berin Loritsch,
@BerinLoritsch Jest to prawo, które wyciąga się z doświadczenia, a nie nieuzasadnione uprzedzenia, jak się wydaje. Nie wiem, czego potrzeba, aby przekonać centrum wsparcia, że ​​tak, wypróbowałem zwykłe rozwiązania. Oczywiście nie może opierać się na tym, o co proszę, ale zauważyłem, że w 20 słowach lub mniej mogę wiedzieć, czy dana osoba wykonała podstawowe rozwiązywanie problemów.
Milind R
3

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.

Carra
źródło
2

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.

JeffO
źródło
2

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ą!

Bmw
źródło
2

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.

talonx
źródło
2

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.

David Thornley
źródło
1

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.

Jason Baker
źródło
1

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.

dietbuddha
źródło
2
Korekta: Nie ma nic takiego jak wielokrotne wywołania 3AM, aby uświadomić sobie, jaki wpływ mają określone decyzje projektowe i / lub skróty narzucone przez twojego menedżera na zdolność ludzi do obsługi i utrzymania twojego kodu. Zły projekt i kod są częściej wynikiem złego zarządzania niż złych programistów.
David Thornley,
0

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.

Zestaw
źródło
0

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.

Nieznajomy
źródło
-1

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.

Leesa
źródło
3
Umieść je na infolinii na miesiąc. Następnie poszukaj programisty zastępczego, ponieważ ten facet nie będzie długo w pobliżu. Ponadto, poszukaj kogoś dobrego w relacjach z klientami, który ukoi tych, którzy rozmawiali z osobą, która była w złym humorze, zanim przydzielono jej do zrobienia czegoś, czego nienawidzi i który nie okazuje szacunku ze strony firmy.
David Thornley,
Zgadzam się z Davidem, jeśli musisz prowadzić swój zespół jak w klasie, możesz zrewidować swoje praktyki rekrutacyjne i / lub środowisko pracy.
Matthieu,
-1

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ąć.

Typ anonimowy
źródło