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).
Odpowiedzi:
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:
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.
źródło
Uwielbiam udzielać wsparcia z następujących powodów:
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:
źródło
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.
źródło
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”).
źródło
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.
źródło
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.
źródło
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ć
źródło
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.
źródło
Przez kilka lat wspierałem moją pierwszą firmę po studiach. Co skłoniło mnie do zarejestrowania się na kilka lat to:
źródło
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.
źródło