W tym artykule podzielę się swoim doświadczeniem w doborze pomysłów na rozwój funkcjonalności naszych produktów oraz powiem jak zachować główne wektory rozwoju.
Rozwijamy automatyczny system rozliczeń (ACS) - billing. Termin
Żywotność naszego produktu wynosi 14 lat. W tym czasie system przeszedł od pierwszych wersji przemysłowego ratera do modułowego kompleksu składającego się z 18 wzajemnie uzupełniających się produktów. Jednym z najważniejszych aspektów długowieczności programów jest ciągły rozwój. A pomysły są potrzebne do rozwoju.
Pomysły
Źródła informacji
Istnieje 5 źródeł:
- Głównym przyjacielem twórcy korporacyjnych systemów informatycznych jest klient. A klient to zbiorowy obraz decydentów, sponsorów projektów, właścicieli i wykonawców procesów, wewnętrznych informatyków, zwykłych użytkowników i dużej liczby osób, które są w różnym stopniu zainteresowane. Ważne jest dla nas, aby każdy z przedstawicieli klienta był potencjalnie dostawcą pomysłów. W najgorszym przypadku dostajemy tylko negatywną informację zwrotną o problemach w systemie. W najlepszym razie po stronie klienta jest osoba, która jest stałym źródłem pomysłów na ulepszenia, dostarczając uporządkowanych informacji o potrzebach klienta.
- Nasz sprzedawców i menedżerów kont są drugim najważniejszym źródłem pomysłów na ulepszenia. Dużo i aktywnie komunikują się z przedstawicielami branży, otrzymują bezpośrednie prośby o funkcjonalność rozliczeniową od potencjalnych klientów. Sprzedawcy i konta muszą być świadomi wszystkich istotnych zmian w ich funkcjonalności i najnowszych aktualizacjach oprogramowania konkurencji, umieć uzasadnić wady i zalety różnych rozwiązań. To nasi pracownicy jako pierwsi wyczuwają, czy niektóre funkcje bilingowe stają się de facto standardem, bez którego oprogramowanie nie może być uznane za kompletne.
- Właściciel Produktu jest jednym z naszych top managerów lub bardzo doświadczonym kierownikiem projektu. Pamięta o strategicznych celach firmy i dostosowuje do nich plany rozwoju produktów.
- Architekt, rozumiejący możliwości i ograniczenia wybranych/stosowanych rozwiązań technologicznych oraz ich wpływ na rozwój produktu.
Zespoły deweloperskie i testowe. Osoby bezpośrednio zaangażowane w rozwój produktu.
Klasyfikacja trafień
Surowe dane otrzymujemy ze źródeł – listów, mandatów, próśb ustnych. Wszystko
odwołania są klasyfikowane:
- konsultacje ze znaczeniem „Jak to zrobić?”, „Jak to działa?”, „Dlaczego to nie działa?”, „Nie rozumiem…”. Połączenia tego typu trafiają na Linię Wsparcia Poziomu 1. Istnieje możliwość przekwalifikowania konsultacji na inne rodzaje odwołań.
- Incydenty o znaczeniu „Nie działa” i „Błąd”. Obsługiwane przez 2 i 3 linie wsparcia. Jeśli konieczne jest szybkie naprawienie i wydanie łatki, można ją przenieść ze wsparcia bezpośrednio do rozwoju. Istnieje możliwość przeklasyfikowania go na żądanie zmiany i wysłania do backlogu.
- Prośby o zmiany i rozwój. Wejdź do rejestru produktów, omijając Linie Wsparcia. Ale dla nich istnieje osobna procedura przetwarzania.
Jest taka statystyka odsłon - zaraz po premierze liczba odsłon na krótki czas rośnie o 10-15%. Zdarzają się również serie połączeń, gdy do naszych usług w chmurze przychodzi nowy klient z dużą liczbą użytkowników. Ludzie uczą się korzystać z nowych funkcji oprogramowania, potrzebują porady. Nawet mały klient rozpoczynając pracę w systemie bez problemu spala ponad 100 godzin konsultacji miesięcznie. Dlatego przy podłączaniu nowego klienta zawsze rezerwujemy czas na wstępne konsultacje. Często nawet wyróżniamy konkretnego specjalistę. Koszt wynajmu oczywiście nie rekompensuje tych kosztów pracy, ale z czasem sytuacja się stabilizuje. Okres adaptacji trwa z reguły od 1 do 3 miesięcy, po czym znacznie zmniejsza się potrzeba poradnictwa.
Wcześniej używaliśmy samodzielnie napisanych rozwiązań do przechowywania połączeń. Ale stopniowo przerzuciłem się na produkty Atlassian. Najpierw przeniesiono rozwój, aby ułatwić pracę na Agile, potem wsparcie. Teraz wszystkie krytyczne procesy działają w Jira SD, a ponadto są dostarczane z różnymi wtyczkami do Jira i Confluence. Samodzielnie napisane rozwiązania pozostały tylko na procesach niekrytycznych dla działalności firmy. Okazało się, że nasze zadania są teraz end-to-end, można je przenosić między wsparciem a rozwojem bez przeskakiwania z jednego systemu do drugiego.
Z tego pakietu możemy uzyskać dane o wszystkich zadaniach, planowanych i rzeczywistych kosztach pracy, korzystać z różnych opcji rozliczeń dla klientów oraz generować dokumentację na potrzeby wewnętrzne i raport dla klientów.
Przetwarzanie żądań zmian
Zazwyczaj żądania te mają postać wymagań dotyczących funkcji. Nasz analityk analizuje żądanie, generuje specyfikację i TOR najwyższego poziomu. Przekazuje specyfikację i TOR osobie, która złożyła ten wniosek do zatwierdzenia – musimy mieć pewność, że mówimy tym samym językiem z klientem.
Po otrzymaniu potwierdzenia od klienta, że dobrze się zrozumieliśmy, analityk wprowadza zgłoszenie do backlogu produktu.
Zarządzanie funkcjami produktu
Backlog gromadzi otrzymane prośby o zmianę i rozwój. Raz na pół roku zbiera się rada techniczna, składająca się z dyrektora, szefów utrzymania ruchu, rozwoju, sprzedaży i architekta systemu. W formie dyskusji rada analizuje i nadaje priorytet aplikacjom z listy oczekujących oraz uzgadnia 5 zadań programistycznych do wdrożenia w następnej wersji.
W rzeczywistości rada techniczna odpowiada na wymagania przemysłu i rynku, uwzględniając potrzeby zapisane we wnioskach. Wszystko, co ma niewielkie znaczenie, pozostaje w zaległościach i nie trafia do etapu rozwoju.
Klasyfikacja żądań zmian i finansów
Rozwój jest kosztowny. Dlatego od razu poinformujemy Cię, jakie opcje możemy mieć, jeśli prośba o zmianę pochodzi od klienta, a nie od pracownika.
Żądania zmian są klasyfikowane w następujący sposób: specyficzne potrzeby branżowe lub indywidualne cechy przedsiębiorstwa; znaczna ilość nowej funkcjonalności lub mała poprawka. Drobne poprawki i indywidualne prośby są przetwarzane bez zbędnych dodatków. Indywidualne zamówienia są obliczane i realizowane dla konkretnego klienta w ramach pracy projektowej z nim.
Jeśli nie jest to ogromna potrzeba branży, a ilość funkcjonalności jest duża, można podjąć decyzję o opracowaniu nowego, oddzielnego modułu, który będzie sprzedawany jako dodatek do głównej funkcjonalności. W przypadku otrzymania takiej prośby od klienta możemy pokryć koszty opracowania modułu, udostępnić klientowi moduł bezpłatnie lub za częściową odpłatnością oraz wystawić moduł na sprzedaż publiczną. W takiej sytuacji klient bierze na siebie część ciężaru metodologicznego i de facto przeprowadza pilotażowe wdrożenie modułu.
Jeśli jest to ogromna potrzeba branżowa, można podjąć decyzję o włączeniu nowej funkcjonalności do produktu podstawowego. Koszty w tym przypadku ponosimy w całości my, a nowa funkcjonalność pojawia się w aktualnej wersji programów.
Starzy klienci otrzymują aktualizację.
Może się również zdarzyć, że kilku klientów ma podobną potrzebę, ale nie pociąga to za sobą produktu masowego. W takim przypadku możemy wysłać specyfikację do tych klientów i zaoferować podział kosztów rozwoju między nimi. Ostatecznie wszyscy wygrywają: klienci dostają implementację funkcjonalności niskim kosztem, my wzbogacamy produkt, po chwili inni uczestnicy rynku również mogą otrzymać funkcjonalność do swojego użytku.
DevOps
Rozwój przygotowuje dwa duże wydania rocznie. W każdym wydaniu zarezerwowany jest czas na realizację 5 zadań otrzymanych od rady technicznej. Dlatego stojąc za obrotem nigdy nie zapominamy o rozwoju produktu.
Każde wydanie przechodzi przez odpowiedni zestaw testów i dokumentacji. Ponadto ta wersja jest instalowana w środowisku testowym odpowiedniego klienta, który z kolei wszystko skrupulatnie sprawdza, a dopiero potem wersja jest przekazywana do produkcji.
Oprócz systemu wydań istnieje format szybkich poprawek błędów, dzięki czemu klienci nie muszą żyć z błędami przez sześć miesięcy. Ten pośredni format pozwoli Ci szybko reagować na incydenty o nadrzędnych priorytetach i wypełniać określone SLA.
Wszystko to dotyczy przede wszystkim sektora korporacyjnego i rozwiązań on-premise. W przypadku usług chmurowych skoncentrowanych na segmencie SMB nie ma tak szerokich możliwości udziału klientów w rozwoju produktu. Format dzierżawy dla SMB nawet tego nie sugeruje. Zamiast prośby o zmianę w postaci jasnych wymagań ze strony firmy, jest tylko zwykła informacja zwrotna i życzenia dotyczące usługi. Staramy się słuchać, ale produkt jest ogromny i chęć jednego klienta, by przynieść coś znajomego z jego starego, historycznego systemu, może być sprzeczna ze strategią rozwoju systemu jako całości.
Źródło: www.habr.com