Jak wyjść z rutyny wsparcia i zacząć spłacać dług techniczny!

Mam przyjaciela". Tak, dobry początek, wiem, ale szczerze mówiąc, to nie jestem ja!

Zasadniczo on pracuje na sukces projektu przez około 4 lat, trudność jest dług techniczny dogoniła, a on ze znalezieniem to prawie niemożliwe, aby przestał wspierać produkt (szczypanie to i to) i faktycznie przejść z prawdziwego rozwoju.

Podsuwałem różne sugestie, zapisywałem cały swój czas, tworzyłem bilety, nie odpowiadałem na e-maile itp. Problem polega na tym, że wydaje się to jedynie przypomnieniem, że nie robi nic „użytecznego”.

Dług techniczny pojawił się w dużej mierze, ponieważ w pierwszej kolejności duża korzyść dla produktu polegała na przyjmowaniu żądań i połączeń telefonicznych od użytkowników oraz szybkim ich wdrażaniu.

Chciałbym wiedzieć, czy ktoś ma jakieś sugestie, jak wydostać się z tego koleiny, z których duża część zmieniłaby sposób postrzegania użytkowników, aby nie sądzili, że mogą po prostu zadzwonić i oczekiwać, że coś być zrobionym wtedy i tam.

Wszystko to bardzo dobrze mówi lepiej planować, choć rozumiem, że bardzo trudno jest zaplanować rzeczywisty rozwój, biorąc pod uwagę wymagania dotyczące wsparcia i względną presję ze strony użytkowników (patrz wyżej).

Organizacja twojego przyjaciela desperacko potrzebuje kogoś do zarządzania zmianami. Ta osoba lub grupa przyjmowałaby prośby o zmiany i poprawki błędów i nadawała im priorytety zgodnie z wpływem biznesowym i wymaganym nakładem pracy. W ten sposób zadania, które są ważniejsze dla organizacji jako całości, zostaną wykonane jako pierwsze, w przeciwieństwie do zadań, które są ważniejsze dla tego, kto w tej chwili przeszkadza Twojemu przyjacielowi.

EDYCJA: Jako przykład tego, jak to by działało, większość organizacji ma skalę dotkliwości. Najwyższy poziom ważności to aplikacja lub funkcja o krytycznym znaczeniu dla firmy, która nie działa. Jeśli jest coś, co firma może zrobić, aby obejść ten problem, obniża to dotkliwość do następnego poziomu. Jeśli aplikacja nie ma krytycznego znaczenia dla firmy, powoduje to, że istotność jest jeszcze niższa. Żądania nowych ulepszeń są zazwyczaj traktowane priorytetowo osobno.

Spraw, aby ktoś inny odbierał połączenia i zmień linię z

Dojdziemy do tego od razu.

do

Bardzo dobra sugestia. Utworzę żądanie funkcji, aby jak najszybciej rozpocząć pracę nad nim. Jeśli chcesz śledzić postęp w realizacji swojego żądania, możesz go śledzić tutaj: [link do biletu śledzenia sprawy]. W przyszłości możesz również składać wnioski o kontrakty terminowe w taki sam sposób, jak ja tutaj: [link do trackera spraw]

Moim zdaniem jest to prawdopodobnie najprostszy i najskuteczniejszy sposób na zrobienie tego. Ostatnim krokiem jest zmniejszenie stresu związanego z odbieraniem połączeń przez tę osobę.

Problem, który widzisz w obecnym systemie „priorytetów”, polega na tym, że gdy wszystko jest priorytetem, nic nie jest priorytetem . W tym celu Twój przyjaciel desperacko musi posłuchać rady @Larry Coleman - ludzi niezależnych od rozwoju, którzy zarządzają żądaniami zmian. Idealnie byłoby, gdyby Twój znajomy nie wiedział nawet o żądaniu funkcji, dopóki ta oddzielna grupa nie zgodziła się, aby nadać jej priorytet pracy. Może to być nawet ta nowa osoba, która odbiera teraz połączenia, które traktują je priorytetowo - o ile rozumieją biznes i rozumieją rozwój.

Sam przeżyłem podobną sytuację. Produkt został zbudowany na sznurkach do butów i po raz pierwszy na rynku pojawił się na rynku. Początkowo był udany (dla biznesu solo-preneur), ale przypuszczam, że wszystko działało w latach 2003-2007. Szukałem personelu, ale nauczyłem się na własnej skórze, że zatrudnienie dobrego personelu jest drogie i nie jest łatwe. Rozumiem, że twój przyjaciel jest w podobnej sytuacji.

W moim przypadku stało się jasne, że w pewnym momencie sprawy pójdą w dół. Firma wciąż się rozwijała, ale konkurencja rosła, rynek wyglądał, jakby miał się zmniejszyć, pojawiły się wczesne sygnały (połowa 2006 r.), Że nadchodzi spowolnienie gospodarcze itp. Zasadniczo wiele czynników spowodowało żebym zdecydował, że produkt ostatecznie umrze; im później, tym lepiej (dla klientów i dla mnie).

Z perspektywy czasu prawdopodobnie podjąłem tyle dobrych decyzji, co złych, ale oto krótka propozycja:

1. Personel odpowiednio i wcześnie. Zdobądź środki, jeśli ich potrzebujesz. (Nie szukanie żadnej było moim największym błędem.) Jeśli sprzedajesz, znajdziesz pieniądze.

2. Użyj kontroli wersji / testów jednostkowych / wszystkich hoopli związanych z najlepszymi praktykami. Wszyscy wyglądają głupio / śmiesznie / nieciekawie, kiedy są nauczani na uniwersytecie, ale zwykle są najlepszymi praktykami z dobrych powodów.

3. Zatrudnij co najmniej jednego specjalistę ds. Sprzedaży / marketingu, szczególnie jeśli jesteś nastawiony na technologię. (Jeśli tak, będziesz miał naturalną tendencję do spędzania więcej czasu na kwestiach technicznych niż na marketingu, nawet jeśli masz sieć afiliacyjną).

4. Tłum źródła wsparcia. Załóż forum, aby użytkownicy mogli sobie pomóc. Skonfiguruj system biletowy i zaproś ekspertów - użytkowników (zwykle często korzystających z forum) do nurkowania w specjalnej sekcji jako wirtualni asystenci. Pozwól im zająć się mnóstwem klientów, którzy potrzebują tego / tego małego zadania za kilka dolców, abyś mógł skupić się na szerszym obrazie.

5. Maksymalizuj wysiłki, aby zmniejszyć ilość udzielanego wsparcia. Im mniej masz wsparcia, tym więcej czasu będziesz musiał zrobić na ciekawsze rzeczy. Do czasu, gdy produkt będzie sztuczny, klienci będą wdzięczni, podobnie jak sprzedaż i personel wsparcia.

6. Poproś rzeczywistych deweloperów o wsparcie (godzinę lub dwie dziennie, aby nie tracili kontaktu z rzeczywistością) i daj im wolną rękę, aby zasugerować dowolną zmianę / zmianę produktu (interfejsu użytkownika, funkcjonalności), jeśli zidentyfikuj wszystko, co sprawi, że spędzą mniej czasu na wsparciu. Chodzi o to, że jeśli są ciągle dokuczani przez użytkowników z tych samych powodów, będą chcieli naprawić wszystko tak szybko, aby mogli pozbyć się wezwań pomocy technicznej. A mądrzejsi faktycznie to robią i właśnie tego chcesz.

7. Jeśli uważasz, że produkt umrze, zdecyduj się zabić go tu i tam i popracuj nad następnym krokiem. Niech naprawdę umrze. Krowa gotówkowa to krowa gotówkowa; gdy osiągnie swój cel, wyślij go do rzeźnika. Rób to delikatnie (dla klientów), ale na pewno nie pozwól, aby jego przedłużone przetrwanie pochłonęło zbyt dużo czasu, jeśli koszty utrzymania są takie, że Twoja konkurencja, z korzyścią bycia spóźnionymi i spłacenia długu technicznego , i tak wprowadzi nowe funkcje szybciej niż możesz.

Jedna linia na raz. Poświęć nieco więcej czasu na każdą poprawkę, czyszczenie hacków i dodawanie automatycznych testów na bieżąco. Często zrobienie czegoś dobrze kończy się znacznie szybciej niż dodanie kolejnej poprawki. Jeśli kierownictwo popycha przyjaciela do szybszej pracy, co często lubi robić, powinien wyhodować grubszą skórkę i przejść do trybu „po zakończeniu”.

Kluczem jest to, jaką metodologię rozwoju ma wokół siebie, aby go do pewnego stopnia chronić? Na przykład w Scrumie istnieje pomysł, że to, co zostanie wykonane, zwykle nie zmienia się podczas sprintu. Zatem istnieją pewne zasady dotyczące tego, co należy zrobić, a czego nie można zrobić od razu. Drugim pytaniem jest, w jakim stopniu kierownictwo popiera jego chęć nie bycia w koleinach wsparcia? Może to być również ważne, ponieważ apatyczne zarządzanie może być tragiczną śmiercią dla projektu twojego przyjaciela.

Najlepiej jest zatrzymać autobus i spojrzeć wstecz. Twój przyjaciel powinien

• Sporządź raport każdego problemu w systemie i uzasadnienie, dlaczego są złe. Należy zwrócić uwagę na problemy projektowe i konieczną ilość refaktoryzacji.
• Należy podać szorstkie ramy czasowe, aby rozwiązać problemy
• Raport należy przekazać jego menedżerom, a następnie interesariuszom w systemie
• Wszystkie zmiany funkcji powinny zostać wstrzymane w okresie ustalania.

Wiele projektów to robi. Jeśli zarządzania nie da się przekonać, jest to przypadek przegrany, ale jeśli się zgodzą, system może zostać przywrócony do formy na dłuższą metę.