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

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

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.

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

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.

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”).

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.

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.

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

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.

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.

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.