Rozwój aplikacji po wdrożeniu: roadmapa, budżet i priorytety

Rozwój aplikacji po wdrożeniu najlepiej planować jako stały, przewidywalny budżet i kwartalną roadmapę, a nie serię doraźnych zleceń wysyłanych wtedy, gdy ktoś w firmie zgłosi pomysł. Taki układ pozwala wykonawcy utrzymać zespół znający system, a firmie decydować o kolejności prac na podstawie wartości biznesowej, nie tego, kto głośniej prosi. Poniżej opisuję, jak prowadzić backlog, ustalać priorytety, wybrać model finansowania, przeprowadzać przeglądy kwartalne i nie zapominać o porządkach technicznych.

Znasz to z praktyki: system działa od kilku miesięcy, użytkownicy mają listę próśb, zarząd ma nowy pomysł, a dział IT nie wie, co zrobić najpierw. Brak planu nie oznacza braku pracy, tylko pracę wykonywaną w przypadkowej kolejności.

Dlaczego rozwój aplikacji po wdrożeniu jest czymś normalnym

Aplikacja biznesowa żyje tak długo, jak zmienia się firma, która jej używa. Dochodzą nowe procesy, zmieniają się przepisy, partnerzy zmieniają swoje API, a biblioteki i środowisko uruchomieniowe wymagają aktualizacji. Do tego dopiero po uruchomieniu widać, jak ludzie naprawdę pracują z systemem.

Źródła nowych zadań, które napędzają rozwój aplikacji po wdrożeniu, są zwykle takie:

• Uwagi użytkowników zebrane w pierwszych tygodniach pracy na produkcji.
• Elementy świadomie odłożone przy odbiorze systemu od wykonawcy jako poprawki drugiej kolejności.
• Nowe potrzeby biznesowe: kolejny kanał sprzedaży, nowy dział, integracja z kolejnym systemem.
• Zmiany zewnętrzne: przepisy, wymagania partnerów, wycofywane wersje usług.
• Porządki techniczne: aktualizacje, refaktoryzacja, poprawa wydajności.

Jeśli system powstał jako MVP, lista jest dłuższa, bo część funkcji celowo wycięto na start. Dobrze zaplanowane MVP ma zresztą od początku opisane, co ma przyjść potem, o czym pisałem w tekście o tym, jak zaplanować MVP bez przepalania budżetu.

Utrzymanie i rozwój to dwie różne pule pieniędzy

Utrzymanie odpowiada na pytanie, czy system działa. Rozwój odpowiada na pytanie, co system ma robić lepiej lub więcej. Mieszanie tych dwóch rzeczy w jednym budżecie kończy się tym, że awarie i drobne poprawki zjadają pieniądze przeznaczone na nowe funkcje, a nikt nie wie dlaczego.

Utrzymanie warto opisać w osobnej umowie, z czasami reakcji, klasami zgłoszeń i zakresem aktualizacji. Szczegóły, co w niej powinno się znaleźć, opisałem w tekście o tym, jak przygotować umowę SLA na utrzymanie systemu. Rozwój ma własny budżet i własny plan. Dzięki temu na przeglądzie widać osobno, ile kosztuje utrzymanie systemu w ruchu, a ile jego dalsze budowanie.

Backlog aplikacji po wdrożeniu, który da się czytać

Backlog to uporządkowana lista wszystkiego, co może zostać zrobione w systemie, i podstawa, na której opiera się dalszy rozwój aplikacji po wdrożeniu. Jego wartość nie zależy od długości, tylko od tego, czy każdą pozycję da się zrozumieć i ocenić bez dzwonienia do autora. Lista kilkuset haseł w stylu „poprawić raport” albo „eksport do Excela” nie pomaga nikomu.

Przy każdej pozycji proszę klientów o kilka informacji:

• Problem, a nie rozwiązanie: co dziś nie działa lub zajmuje za dużo czasu, zamiast gotowego pomysłu na przycisk.
• Kto zgłasza i kogo to dotyczy: jeden dział, wszyscy użytkownicy, klienci firmy.
• Skutek: oszczędność czasu, mniej błędów, wymóg prawny, przychód.
• Pilność: czy jest termin zewnętrzny, na przykład zmiana przepisów albo start kampanii.
• Właściciel po stronie firmy, który odpowie na pytania i odbierze wynik.

Backlog powinien być w jednym miejscu, wspólnym dla firmy i wykonawcy. Zgłoszenia z maili, rozmów telefonicznych i spotkań trafiają tam, zanim ktoś zacznie je wyceniać. Raz na jakiś czas warto też usuwać pozycje, które straciły sens, bo stara lista zniechęca do czytania nowej.

Priorytety biznesowe zamiast kolejki zgłoszeń

Kolejność prac powinna wynikać z tego, ile dana zmiana daje firmie w stosunku do kosztu i ryzyka, a nie z daty zgłoszenia. Do rozmowy z zarządem wystarcza prosta ocena każdej pozycji w kilku wymiarach, robiona wspólnie przez właściciela biznesowego i wykonawcę.

Wymiar	Pytanie	Kto ocenia
Wartość	Co firma zyska: czas, mniej błędów, przychód, zgodność z przepisami	Właściciel biznesowy
Koszt	Ile pracy wymaga zmiana, razem z testami i wdrożeniem	Wykonawca
Ryzyko	Czy zmiana dotyka integracji, danych lub kluczowego procesu	Wykonawca z właścicielem procesu
Pilność	Czy jest termin, po którym zmiana traci sens albo staje się obowiązkowa	Właściciel biznesowy

Taka tabela nie musi być precyzyjna. Wystarczy skala trzystopniowa, byle stosowana tak samo do wszystkich pozycji. Wartość ocenia firma, koszt i ryzyko wykonawca, a decyzję podejmują razem. Zmiany wymagane przepisami lub bezpieczeństwem idą poza kolejką, ale też trafiają do backlogu, żeby było widać, ile budżetu zabrały.

Stały budżet czy projekty: jak finansować rozwój aplikacji po wdrożeniu

Są dwa podstawowe modele. Stały budżet oznacza, że firma kupuje określoną pulę pracy w każdym miesiącu lub kwartale i decyduje, na co ją przeznaczyć. Model projektowy oznacza osobne zamówienie i wycenę dla każdej większej zmiany.

Cecha	Stały budżet	Osobne projekty
Przewidywalność kosztu	Wysoka, koszt znany z góry	Zależy od liczby zamówień
Ciągłość zespołu	Ci sami ludzie znają system	Ryzyko zmiany osób między projektami
Czas reakcji na nową potrzebę	Krótki, wystarczy zmienić kolejność	Dłuższy, potrzebna wycena i umowa
Kontrola wydatków	Przez priorytety i przegląd	Przez akceptację każdej wyceny
Najlepszy dla	Systemów używanych codziennie i często zmienianych	Systemów stabilnych, zmienianych rzadko

W praktyce często sprawdza się model mieszany: stały budżet na bieżący rozwój i drobne zmiany oraz osobne projekty na duże moduły, na przykład nowy kanał sprzedaży. Ważne, żeby stały budżet nie był „abonamentem na wszystko”. Musi mieć jasno opisane, co obejmuje, jak rozlicza się niewykorzystaną pracę i jak zgłasza się pozycje do realizacji.

Przegląd kwartalny: jak go przeprowadzić

Przegląd kwartalny to spotkanie, na którym firma i wykonawca oceniają rozwój aplikacji po wdrożeniu: sprawdzają, co zostało zrobione, co dało efekt i co robić dalej. Kwartał jest na tyle długi, żeby zobaczyć skutki zmian, i na tyle krótki, żeby szybko poprawić kurs. Proponuję prosty porządek spotkania:

1. Co zostało wdrożone w minionym kwartale i ile budżetu zajęły rozwój, utrzymanie i zmiany poza kolejką.
2. Czy zmiany dały zakładany efekt: krótszy czas obsługi, mniej zgłoszeń, mniej ręcznej pracy.
3. Stan techniczny: zaległe aktualizacje, obszary, w których zmiany stają się wolniejsze, ryzyka bezpieczeństwa.
4. Nowe potrzeby i zmiany zewnętrzne, które pojawiły się od ostatniego przeglądu.
5. Kolejność prac na następny kwartał i wstępny kierunek na dwa kolejne.

Na przegląd powinna przyjść osoba, która może podjąć decyzję o budżecie, a nie tylko osoba, która zbiera zgłoszenia. Bez niej spotkanie kończy się listą życzeń, którą i tak trzeba będzie zatwierdzać drugi raz.

Nowe funkcje i porządki techniczne: jak utrzymać równowagę

Część budżetu rozwoju powinna stale iść na porządki techniczne, bo bez nich każda kolejna funkcja kosztuje więcej. Aktualizacje bibliotek, upraszczanie skomplikowanych miejsc w kodzie, testy automatyczne i poprawa wydajności nie są widoczne dla użytkownika, ale decydują o tym, ile będzie kosztowała następna zmiana.

Najprościej ustalić stałą, uzgodnioną część budżetu na takie prace i pokazywać na przeglądzie, na co poszła. Wykonawca powinien umieć wytłumaczyć każdą taką pozycję językiem skutków: co się stanie, jeśli jej nie zrobimy. Objawy zaniedbanych porządków i sposoby ich planowania opisałem szerzej w tekście o tym, czym jest dług technologiczny i kiedy go spłacać.

Osobną kategorią są aktualizacje bezpieczeństwa. Nie powinny konkurować z nowymi funkcjami w głosowaniu nad priorytetami. Wymagania w tym zakresie warto mieć zapisane w umowie, tak jak przy minimum bezpieczeństwa aplikacji, którego wymaga się od wykonawcy.

Roadmapa, którą zarząd zrozumie

Roadmapa to nie harmonogram z datą przy każdym zadaniu. To obraz kierunku: co robimy teraz, co w kolejnym kroku, co później i dlaczego. Dobrze działa podział na trzy kolumny: „teraz” (bieżący kwartał, zadania wycenione i potwierdzone), „następnie” (kolejny kwartał, zakres wstępny) i „później” (pomysły, które czekają na decyzję lub dane).

Każda pozycja na roadmapie powinna być opisana celem biznesowym, a nie nazwą funkcji. „Skrócić czas przyjęcia zamówienia od klienta hurtowego” mówi zarządowi więcej niż „nowy formularz zamówień”. Taki zapis pozwala też zmienić rozwiązanie bez zmiany celu, gdy w trakcie prac okaże się, że da się to zrobić prościej.

Jeśli Twoja aplikacja działa już na produkcji, a lista próśb rośnie szybciej niż budżet, zacznij od jednego kroku. Zbierz wszystkie zgłoszenia w jednym miejscu, opisz je problemem i skutkiem, a potem umów pierwszy przegląd z wykonawcą. Rozwój aplikacji po wdrożeniu przestaje wtedy być serią przypadkowych zleceń i staje się planem, którym da się zarządzać. Jeśli chcesz to przejść razem, zobacz, jak wygląda współpraca przy rozwoju systemu.