Jak „sprzedać” wsparcie jako opcję kariery [zamknięte]

9

Stosunkowo łatwo jest nam zatrudnić programistów do pracy nad różnymi projektami.

Problem pojawia się po zakończeniu projektu, ale nadal wymaga wsparcia.

Naprawdę walczymy o to, aby ludzie dołączyli do zespołu wsparcia. Jest postrzegany jako ślepy zaułek, ograniczający karierę, nudny, drugiej klasy itp.

Obecnie rozwiązujemy ten problem, zachęcając zespół projektowy do przypisania części zespołu do zespołu wsparcia na jakiś czas. Częścią zadania jest „zrzut mózgu” projektu, aby zespół wsparcia go zrozumiał. Działa to tak długo, jak przypisanie jest tylko na określony czas.

Problem stanowi próba zatrudnienia ludzi do pracy w pełnym wymiarze godzin. Istnieje niewiele zastosowań, a kaliber nie jest szczególnie wysoki.

(Rzeczywistość finansowa jest jednak taka, że ​​wsparcie może być bardzo intratne dla firmy, a gdy zyskasz reputację, inne firmy zwracają się do niego o pomoc, nawet jeśli nie byłeś zaangażowany w pierwotne opracowanie).

nzpcmad
źródło
8
„Jest postrzegany jako ślepy zaułek, ograniczający karierę, nudny ...” - Ponieważ zwykle tak jest. Programiści są często twórcami, a wsparcie z definicji niczego nie tworzy.
Steven Evers
Czy potrafisz zdefiniować wsparcie, jakie masz na myśli? Czy to obejmuje naprawianie błędów, czy wszystko do, ale bez uwzględnienia tego punktu?
Jon Hopkins,
Obejmowałoby to naprawianie błędów.
nzpcmad
Dobre stałe naprawy błędów są rzadkie, ale istnieją. Musisz po prostu być bardzo atrakcyjny jako firma i przejść wiele uczciwych (bo wielu w przeciwnym razie odejdzie) wywiadów.
Job

Odpowiedzi:

16

Nie rób

Dla mnie najlepszą opcją jest tutaj, aby nie rozdzielać programistów na wsparcie i brak wsparcia. IMHO są trzy główne powody:

  • ludzie, którzy piszą rzeczy, które są trudne do poparcia, nie uczą się, dopóki nie będą musieli wspierać tych rzeczy.
  • ludzie wykonujący tylko wsparcie zwykle podejmą ścieżkę najmniejszego oporu w korygowaniu błędu, nawet jeśli utrudni to przyszłą pracę.
  • teoretyczna oszczędność czasu na dotrzymywanie terminów w nowym rozwoju dzięki oddzielnym programistom wsparcia jest zawsze więcej niż zużywana przez konieczność dostarczania instrukcji lub powtarzania pracy.

W zespole deweloperów możesz zatrudniać ludzi, którzy mają zadania związane z obsługą techniczną lub podejść do tego, aby zadania konserwacyjne były poligonem dla nowych członków zespołu, ale jeśli spróbujesz sprzedać je jako długoterminowy cel pozycji, przyciągniesz tylko ludzie, którzy spowodują zgagę lub ludzie, którzy wkrótce będą w drodze.

Zawsze musi istnieć jasna ścieżka wyjścia ze 100% roli dewelopera wsparcia i / lub pewien procent nowych prac rozwojowych, aby zainteresować dobrych ludzi.

Nie chcesz przyciągać ludzi, którzy cieszą się z tej roli w nieskończoność, i nigdy nie przekonasz, że w przeciwnym razie dobrzy deweloperzy przyjmą tę rolę i utrzymają ją w perspektywie długoterminowej, chyba że zaoferujesz zapłatę, która nigdy nie pozwoliłaby im się zastanowić ruch kariery.

Rachunek
źródło
To nie rozwiązuje podstawowego problemu polegającego na tym, że mamy zespół przy projekcie A. Projekt kończy się - zespół jest podzielony. Projekt A ma problem - ludzie muszą zostać zdjęci z innych projektów, aby go naprawić. Stąd pomysł zespołu wsparcia.
nzpcmad
3
Zawsze będziesz mieć to ograniczenie. Nawet jeśli masz oddzielny zespół wsparcia, tracisz cykle pierwotnego członka zespołu deweloperskiego, wykonując dokumentację i przekazywanie oraz wsparcie drugiego poziomu. IMHO jest znacznie czystszy i bardziej atrakcyjny dla personelu jako całości, jeśli ten stracony czas jest tylko miarą, która jest uwzględniana w szacunkach przyszłych projektów, zamiast posiadania zespołu deweloperów drugiej klasy, który zawsze stara się nadrobić zaległości i tylko pracuje nad problemami stworzonymi przez zespoły pierwszej klasy. Nigdy nie widziałem, aby podejście dewelopera wsparcia działało dobrze. Zawsze generuje odejście pracowników.
Bill
8

Zadbaj o to, aby pomoc techniczna była przyjemna i cenna dla programistów.

Uwielbiam udzielać wsparcia z następujących powodów:

  • Rozmawiam z ludźmi z całego świata. Nawiązałem wielu takich przyjaciół . Kilka lat temu jeden z moich klientów zaprosił mnie na swój ślub! Kiedyś w moim biurze znajdowała się mapa świata z przypiętymi do niej szpilkami.
  • Wsparcie jest prawie najlepsze, aby uzyskać gratyfikacje dla swojej pracy. Kiedy sprawiasz, że użytkownicy są szczęśliwi, to naprawdę sprawia, że ​​jesteś szczęśliwszy.
  • Skargi są przydatnym sposobem na poprawę siebie. Poważnie podchodzę do każdej reklamacji, aw większości przypadków potrafię przekonwertować kogoś wściekłego na szczęśliwego klienta / użytkownika, który w końcu rozpowszechni informacje.
  • Pomaga mi zrozumieć, czego potrzebują klienci / użytkownicy. Potem mogę zbudować lepsze oprogramowanie.

To tylko kilka powodów.

Jeśli chodzi o samo wsparcie, sugeruję wdrożenie łatwego w zarządzaniu procesu.

Po otrzymaniu zgłoszenia do pomocy technicznej wykonujemy następujące czynności:

  • Jeśli jest to powtarzalny błąd, dodajemy go do rejestru i podajemy jego identyfikator klientowi / użytkownikowi. Bierzemy również identyfikator klienta / użytkownika, aby powiadomić go o uchwałach i zwolnić osobiście. Jest to łatwe, jeśli odbierzesz jego e-mail bezpośrednio.
  • W przypadku problemów z korzystaniem z oprogramowania traktujemy to jako okazję do ulepszenia dokumentacji. Każda odpowiedź jest zapisana jak artykuł w bazie wiedzy, który dodajemy do naszej bazy danych. Pisanie zajmuje trzy razy, ale nie powtarzamy tego później (większość użytkowników woli przeglądać w KB).
  • Jeśli jest to żądanie funkcji, łączymy użytkownika bezpośrednio z właścicielem produktu. To jest bardzo cenne. Oczywiście używamy systemów takich jak uservoice.com, ale bezpośrednia rozmowa z użytkownikiem jest znacznie lepsza.
  • Jeśli jest to skarga, staramy się zarządzać nią poza procesem. Osoby, które skarżą się, są uważane za ważne (nawet jeśli skarga jest trywialna).

źródło
+1 za wsparcie jako najlepszy sposób, aby dowiedzieć się, czego naprawdę chce klient .
AShelly
3
Nawet nie mów o roli „dewelopera wsparcia”, użyj czegoś, co będzie motywować, np. „Inżynier refaktoryzacji” i zachęć ich do kreatywności w tym, z czym mają do czynienia / ulepszaniu.
Nick Josevski,
@Nick Josevski - Zdecydowanie swoboda opracowywania ulepszeń / udoskonaleń istniejącego systemu oznacza, że ​​„rozwój wsparcia” nie ogranicza się tylko do „działania, gdy się zepsuje”. Moją pierwszą rolą programistyczną było wsparcie / utrzymanie (chociaż podobało mi się to, kiedy po raz pierwszy przeszedłem do pracy nad projektem).
Adam Luchjenbroers
@Pierre 303, podejrzewam, że nie wszyscy są tacy jak ty. Założę się, że introwersja kontra ekstrawersja jest częścią równania.
Job
3

Dlaczego po prostu nie zapłacić deweloperom wsparcia 5 lub 10k więcej niż build i zapomnieć o deweloperach?

Dołączając dodatkową premię do ról wspierających; w uznaniu dodatkowych wyzwań związanych z „lojalnością klientów” i „utrzymaniem kodu produkcyjnego”; zapewnisz nie tylko dodatkową motywację, ale co ważniejsze, role będą postrzegane jako mające większy prestiż. Przecież wyższa pensja musi oznaczać ważniejszą rolę, a nawet jeśli tak nie jest, będzie to przewidywane w ten sposób.

sipwiz
źródło
Nie sądzę, że poprawi to retencję. Pewnie, będziesz mieć więcej zalogowanych osób, ale kiedy zgromadzą trochę gotówki, odejdą. Niektóre badania wykazały, że pieniądze naprawdę mają znaczenie tylko wtedy, gdy ich nie masz. Podwójnie tak w przypadku „pracowników wiedzy”.
Steven Evers
3

Jeśli uważasz, że wsparcie to praca drugorzędna, prawdopodobnie będziesz mieć problemy z zatrudnieniem ludzi do tego celu. Jeśli potraktujesz to jako pracę ograniczającą karierę i ślepą uliczkę, nie dostaniesz dobrych kandydatów.

Wsparcie nie jest na ogół tak samo przyjemne jak tworzenie nowych programów, a jeśli masz osobne zespoły ds. Rozwoju i wsparcia, zespoły wsparcia muszą wziąć to, co zapewnia rozwój, co często nie jest przyjemnością. (Pracowałem kiedyś w miejscu, w którym R&D dostarczyłoby nam oprogramowanie, które zrobiło coś fajnego, ale które zwykle wymagało przeprojektowania, aby było jakości produkcyjnej, i nie mieliśmy wystarczająco dużo czasu, aby to zrobić, z powodów politycznych. To nie było zabawa.)

Jeśli wsparcie naprawdę ma kluczowe znaczenie dla biznesu, musisz traktować je jako takie. Jeśli nalegasz na posiadanie osobnych zespołów wsparcia i ważne jest, aby mieć dobre zespoły, musisz rozwiązać te problemy. Upewnij się, że masz ścieżkę kariery. Publikuj pieniądze, które zarabiasz na wsparciu, częściowo za ich poczucie własnej wartości, częściowo po to, aby inni ludzie zdali sobie sprawę z ich wartości, częściowo po to, by mogli wznowić swoje działania w dolarach. Ustanawiaj standardy i pozwól zespołom wsparcia wnieść pewien wkład w to, czy projekt jest gotowy do przejścia od rozwoju do wsparcia. Ponieważ praca jest mniej zabawna i być może ważniejsza, zapłać im lepiej. (Bardziej współczuję menedżerom, którzy narzekają, że „nie możemy zdobyć potrzebnych wnioskodawców”, jeśli zwykle nie tłumaczy się to jako „nie możemy wnioskodawców potrzebować taniego”).

David Thornley
źródło
1

Chociaż zgadzam się, że wsparcie jest na ogół do niczego, wielu programistów może cieszyć się prestiżem związanym z „własnością” projektu, nawet jeśli sami nie napisali oprogramowania. Ten programista staje się goto na ten projekt i naprawdę staje się nieocenionym ekspertem od systemu. Chociaż jestem przede wszystkim zaangażowany w nowe prace rozwojowe w firmie, w której pracuję, wielu moich kolegów, którzy są bardziej niż kompetentni, jest naprawdę szanowanych za utrzymanie naszego oprogramowania o największym znaczeniu. W końcu obecnie obsługiwane oprogramowanie jest prawdopodobnie tym, które obecnie zarabia pieniądze (ptak w ręku jest wart dwa w buszu).
Powiedziałbym tylko, że nie wszyscy uważają wsparcie za okropną pracę w lochach dla słabszych programistów, i odegrałbym ten sentyment, aby przyciągnąć więcej ludzi.

Morgan Herlocker
źródło
1

Kilka myśli:

1) Mówisz, że jest to postrzegane jako ślepy zaułek i ograniczenie kariery. Jeśli nie jest to prawdą, a ludzie zajęli się innymi sprawami (programowanie, zarządzanie projektami, kierowanie zespołem), to jestem pewien, że masz przykłady, których możesz użyć. Jeśli nie masz przykładów, być może będziesz musiał zaakceptować fakt, że jest to ślepy zaułek, a kariera jest ograniczona, i będziesz musiał rozwiązać te problemy.

2a) Jeśli wsparcie obejmuje naprawianie błędów, to dlaczego są one oddzielne? Jeśli ktoś źle go zakodował, to czego go uczysz, przekazując swój bałagan komuś innemu do rozwiązania. Co więcej, jeśli programiści wsparcia nie są postrzegani tak dobrze, jak programiści, jak, u licha, można oczekiwać, że naprawią to, czego programiści nie mieli racji? Poważnie, regułą powinno być to, że to napisałeś, to naprawisz.

2b) Jeśli wsparcie nie obejmuje naprawiania błędów, to są to bardzo różne zadania i podkreślają różne umiejętności. Nie powinieneś martwić się o przejście tutaj bardziej niż martwisz się o przejście między rozwojem a czyszczeniem.

3) Mówisz, że jest to dochodowe dla firmy - a potem uczyń to dochodowym dla zaangażowanych osób. Może to być dzięki lepszym pieniądzom, lepszemu szkoleniu, lepszemu zestawowi i dając im wszystko, czego potrzebują, aby naprawdę dobrze wykonywać te czynności. Jeśli są dostępne pieniądze, zrób to świetną robotę.

Problem z czytaniem twojego postu polega na tym, że wydaje ci się, że nie wierzysz, że to dobra robota. Jeśli to prawda, nic dziwnego, że nie możesz sprzedać tego jako jednego.

Jon Hopkins
źródło
0

Wsparcie to trudna praca, żadne ciało nie lubi słuchać skarg ludzi przez cały dzień. Znalezienie dobrych ludzi może zająć trochę czasu, ale kiedy już to zrobisz, musisz ich zatrzymać

  1. Płać dobre pieniądze, nawet znacznie powyżej stawek branżowych, aby utrzymać dobrych ludzi
  2. Zapewnij dobre środowisko pracy, pomóż drobiazgom, takim jak praca, lunch i napoje
  3. Nie wpychaj całego personelu pomocniczego do małego, hałaśliwego pokoju
Craig
źródło
0

Myślę, że zappos.com pokazał, że praca nie musi być gówniana, gdy pracujesz dla dobrej firmy. Najgorsze jest to, że nie można komuś pomóc. Jeśli przekręcisz użytkowników drobnym drukiem umowy serwisowej lub dostarczysz błędne oprogramowanie, które nie zostanie naprawione w najbliższym czasie, wsparcie będzie do niczego. Należy je zachęcać do znajdowania rozwiązań problemów; coś w rodzaju programowania.

JeffO
źródło
0

Przez kilka lat wspierałem moją pierwszą firmę po studiach. Co skłoniło mnie do zarejestrowania się na kilka lat to:

  1. Wymagana ścieżka kariery, aby zostać inżynierem oprogramowania.
  2. Potrzebowałem czasu, aby odświeżyć główny język firmy (Fortran, około 1989 r.)
  3. Nie byłam mężatką, więc mogłabym zrezygnować, gdyby okazało się, że nie lubię firmy ani pracy.
Mark Thalman
źródło
0

Co powiesz na mieszankę rozwoju i wsparcia (podzielone role)? Myślę, że nadal będziesz miał trudności z uzyskaniem wpisowego z tego powodu z już wspomnianych powodów (programiści! = Ludzie wsparcia produktu). Ale jeśli twój produkt opiera się na szerokim zrozumieniu technologii wewnętrznej, być może 80% rozwoju, 20% wsparcia byłoby sprawiedliwym kompromisem. Lub jakiś rodzaj mentoringu / shadowingu dla nowych pracowników, aby upewnić się, że otrzymują prawidłowe informacje o produkcie.

Tim Claason
źródło