Skip to content

Generated file. Source: docs/product_roadmap.md Edit the source document and run npm run docs:sync to refresh this published copy.

Roadmapa Produktowa

Dokument PM -> Developer / Stakeholder

  • produkt: Kalkulator Obligacji Skarbowych
  • klasa dokumentu: authoritative product roadmap
  • status dokumentu: active
  • wersja: 1.0
  • ostatni przegląd: 2026-03-23
  • właściciel dokumentu: Product Manager
  • cel dokumentu: utrzymać jedno źródło prawdy dla kolejności etapów rozwoju produktu, ich zależności, priorytetów i zakresu

1. Rola tego dokumentu

Ten dokument jest nadrzędnym źródłem prawdy dla roadmapy produktu.

To oznacza:

  • kolejność etapów powinna być definiowana tutaj
  • zmiana priorytetu etapu powinna być definiowana tutaj
  • zmiana zakresu etapu powinna być definiowana tutaj
  • roadmapa pokazywana w UI powinna być wtórną prezentacją tego dokumentu

Ten dokument nie zastępuje specyfikacji produktowej.

Relacja między dokumentami:

  • product_spec.md definiuje produkt, jego aktualny zakres i obowiązujące decyzje
  • ten dokument definiuje kolejność i sens przyszłych etapów rozwoju
  • bond_engine_architecture.md opisuje architekturę techniczną wspierającą bieżący i przyszły rozwój

2. Zasady utrzymania roadmapy

  • najpierw aktualizujemy ten dokument
  • potem aktualizujemy sekcję roadmapy w specyfikacji, jeśli wymaga to zmiany opisu produktu lub zależności
  • na końcu aktualizujemy UI roadmapy w NextStepsPage.tsx: src/app/components/NextStepsPage.tsx
  • jeśli roadmapa w UI i ten dokument są niespójne, za źródło prawdy uznajemy ten dokument
  • każdy etap powinien mieć jasny cel, zakres, wartość biznesową i kryterium wejścia do kolejnego etapu

3. Założenie nadrzędne

Roadmapa ma prowadzić od kalkulatora porównawczego do narzędzia, które w kolejnych iteracjach będzie mogło wspierać projekt portfela inwestycyjnego w obligacje: historycznego, aktualizowanego na bieżąco i opartego o dane konkretnych emisji.

Najważniejsze zasady planowania:

  • najpierw zamykamy logikę biznesową i zasady UI dla MVP
  • potem automatyzujemy dane i budujemy ich audytowalność
  • następnie rozwijamy model inflacyjny i scenariusze
  • dopiero potem wchodzimy w bardziej złożone przypadki inwestowania i typy rachunków
  • asystent wejścia do kalkulatora powinien wejść dopiero wtedy, gdy model formularza i logika inwestycji cyklicznej są już stabilne

4. Zależności etapów

flowchart LR
    P0[Etap 0\nDomkniecie logiki MVP] --> P1[Etap 1\nAutomatyzacja danych]
    P1 --> P2[Etap 2\nBaza danych i zapis symulacji]
    P2 --> P3[Etap 3\nModel inflacyjny]
    P3 --> P4[Etap 4\nScenariusze min/max]
    P3 --> P5[Etap 5\nSymulator zmiennosci]
    P2 --> P6[Etap 6\nRegularne inwestowanie i IKE/IKZE]
    P3 --> P6
    P4 --> P6
    P5 --> P6
    P6 --> P7[Etap 7\nAsystent wejscia]

Interpretacja:

  • Etap 0 zamyka decyzje produktowe i interpretacyjne
  • Etap 1 buduje wiarygodne, automatyczne dane wejściowe
  • Etap 2 buduje fundament danych pod przyszły portfel i zapis symulacji
  • Etap 3 powinien korzystać z fundamentu z Etapu 2 i zasilać tę samą warstwę danych predykcjami inflacji oraz ich historią
  • Etap 4 i Etap 5 są opcjonalnymi rozszerzeniami po Etapie 3, a nie obowiązkowym liniowym ciągiem
  • Etap 6 może wejść po ustabilizowaniu danych i podstawowego modelu symulacyjnego, ale powinien też umieć korzystać z rezultatów Etapu 4 i Etapu 5, jeśli zostaną wcześniej wdrożone
  • Etap 7 korzysta z dojrzałego formularza i nie powinien tworzyć własnej logiki liczenia

5. Etapy roadmapy

5.1 Etap 0. Domknięcie logiki biznesowej i UI dla MVP

Priorytet: Najwyższy

Cel:

  • ustalenie i zamrożenie zasad produktu, zanim zacznie się automatyzacja danych i dalsza rozbudowa roadmapy

Wartość biznesowa:

  • ogranicza ryzyko budowania kolejnych funkcji na niezamkniętych decyzjach biznesowych
  • pozwala potraktować obecny kalkulator jako świadomie zdefiniowany punkt wejścia do MVP

Zakres:

  • opis aktualnego modelu obliczeń i weryfikacja poprawności zachowania dla każdego typu obligacji
  • ustalenie zasad działania reinwestycji, szczególnie dla długich horyzontów i różnych rodzin obligacji
  • ustalenie scenariuszy symulacji i prezentacji danych dla obligacji o różnych mechanikach wypłaty odsetek, kapitalizacji, kosztów i podatków
  • decyzja, czy produkt ma pokazywać przede wszystkim rzeczywisty stan inwestycji na koniec każdego roku zgodny z logiką rozliczania danego produktu, czy ujednolicony model porównawczy
  • rozstrzygnięcie, czy i kiedy użytkownik ma mieć możliwość przełączania się między scenariuszami prezentacji, np. ścieżką rzeczywistą i widokiem porównania wyniku przy zakończeniu inwestycji w roku X
  • jasne rozróżnienie, że podstawowe wyniki roczne pokazują przede wszystkim przebieg inwestycji, a osobny scenariusz „zakończ inwestycję w każdym kolejnym roku” jest wdrażany jako jawny model interpretacyjny, a nie ukryta semantyka MVP
  • ustalenie, jak w UI mają być pokazywane podatki, koszty i interpretacja wyniku
  • jawne opisanie rzeczy odłożonych poza MVP, w tym limitu kwotowego 800+ i logiki IKE / IKZE

Kryteria sukcesu:

  • istnieje zamknięty opis wymagań biznesowych dla obecnego kalkulatora
  • zasady prezentacji danych i interpretacji wyniku są spójne między logiką i UI
  • decyzje odłożone poza MVP są jawnie opisane i nie mieszają się z bieżącym zakresem produktu

5.2 Etap 1. Automatyzacja danych rynkowych i emisyjnych

Priorytet: Najwyższy

Cel:

  • zredukowanie ręcznego utrzymywania parametrów wejściowych i zbudowanie wiarygodnego źródła danych dla dalszego rozwoju produktu

Wartość biznesowa:

  • zwiększa zaufanie do kalkulatora
  • skraca czas aktualizacji danych
  • tworzy fundament pod późniejsze funkcje portfelowe

Zakres:

  • automatyczne pobieranie aktualnej stopy referencyjnej NBP
  • automatyczne pobieranie bieżącej inflacji jako domyślnego parametru wejściowego
  • stworzenie scrapera do pobierania warunków emisji i aktualizacji katalogu obligacji
  • walidacja danych po stronie pipeline i bezpieczna publikacja zmian w katalogu

Kryteria sukcesu:

  • stopa referencyjna i bieżąca inflacja przestają być aktualizowane ręcznie
  • nowe emisje i zmiany warunków mogą zostać zaktualizowane bez edycji logiki aplikacji
  • zmiany w katalogu mają historię i są możliwe do audytu

5.3 Etap 2. Baza danych pod przyszły portfel obligacji

Priorytet: Wysoki

Cel:

  • rozszerzenie scrapera i modelu danych z prostego katalogu emisji do zalążka bazy danych, która będzie wspierać przyszły projekt portfela inwestycyjnego oraz zapis symulacji użytkownika

Wartość biznesowa:

  • otwiera drogę do pokazywania historycznych emisji, historii portfela, zapisanych kalkulacji oraz bieżącego stanu inwestycji bez przebudowy całego produktu od zera

Zakres:

  • zbieranie danych o konkretnych emisjach, a nie tylko o typach obligacji
  • budowa historii parametrów emisji tak, aby można było odtworzyć stan inwestycji w czasie
  • przygotowanie modelu danych pozwalającego później przechowywać: datę zakupu, serię emisji, parametry historyczne, zapis kalkulacji oraz bieżący stan portfela
  • przygotowanie warstwy danych pod zapisywanie predykcji inflacji, źródła predykcji, daty pobrania i późniejszego porównania z inflacją rzeczywistą

Kryteria sukcesu:

  • aplikacja ma gotowy model danych pod historyczne emisje
  • użytkownik może wrócić do zapisanej kalkulacji lub symulacji
  • da się pokazać historyczny kontekst konkretnego zakupu w przyszłym portfelu
  • możliwe jest późniejsze aktualizowanie bieżącego stanu inwestycji bez utraty danych historycznych
  • warstwa danych jest gotowa na przechowywanie predykcji inflacji i ich wersjonowania

5.4 Etap 3. Rozbudowa modelu inflacyjnego

Priorytet: Wysoki

Cel:

  • przejście z jednej ręcznie wpisywanej wartości inflacji do bardziej realistycznego modelu predykcyjnego

Wartość biznesowa:

  • użytkownik dostaje wynik bliższy realnym oczekiwaniom rynkowym, a nie tylko pojedynczy uproszczony scenariusz

Zakres:

  • rozbudowa mechanizmu symulacji o predykcję inflacji pobieraną z zewnętrznego źródła
  • rozdzielenie inflacji ręcznej od inflacji domyślnej lub pobranej
  • zapis użytej predykcji inflacji, jej źródła, wersji i daty pobrania do warstwy danych przygotowanej w Etapie 2
  • przygotowanie możliwości porównania dawnej predykcji z późniejszą inflacją rzeczywistą
  • przygotowanie UX, który jasno pokaże, z jakiego źródła pochodzi użyta predykcja

Kryteria sukcesu:

  • użytkownik może korzystać z domyślnej predykcji bez ręcznego wpisywania inflacji
  • silnik potrafi pracować na danych inflacyjnych pochodzących spoza formularza
  • predykcja użyta w symulacji może zostać zapisana i później odtworzona
  • produkt może w przyszłości pokazać, jak predykcja inflacji rozjechała się z rzeczywistością

5.5 Etap 4. Scenariusze min / max i przedział wyników

Priorytet: Średni

Cel:

  • rozszerzenie pojedynczej symulacji do scenariuszy pokazujących nie jeden wynik, ale zakres możliwych rezultatów

Wartość biznesowa:

  • produkt staje się bardziej użyteczny decyzyjnie, bo użytkownik widzi nie tylko wynik bazowy, ale też jego wrażliwość na inflację

Zakres:

  • dodanie scenariuszy minimalnego i maksymalnego dla zadanego zakresu inflacji
  • możliwość porównania wyniku bazowego z wynikami skrajnymi
  • zmiany w wykresach i tabelach tak, aby pokazać wynik punktowy i zakres

Kryteria sukcesu:

  • użytkownik widzi co najmniej trzy wyniki: bazowy, minimalny i maksymalny
  • w UI da się szybko odróżnić wynik centralny od rozstępu scenariuszy

5.6 Etap 5. Symulator zmienności inflacji

Priorytet: Niski

Cel:

  • dodanie bardziej zaawansowanego modelu scenariuszowego uwzględniającego historyczną zmienność inflacji wewnątrz przyjętej predykcji

Wartość biznesowa:

  • to przejście z prostego kalkulatora w stronę narzędzia analitycznego pokazującego bardziej realistyczną niepewność inwestycji

Zakres:

  • stworzenie symulatora ścieżek inflacji w obrębie przyjętego zakresu predykcji
  • uwzględnienie historycznej zmienności jako podstawy do budowy odchyleń scenariuszy
  • przygotowanie sposobu prezentacji wyników jako przedziału lub rozkładu, a nie jednej liczby

Kryteria sukcesu:

  • silnik potrafi wygenerować wiele ścieżek inflacji dla tej samej inwestycji
  • użytkownik widzi nie tylko wynik skrajny, ale też rozkład możliwych rezultatów

5.7 Etap 6. Regularne inwestowanie oraz IKE / IKZE

Priorytet: Wysoki

Cel:

  • rozszerzenie kalkulatora z modelu jednorazowej inwestycji do modelu inwestowania cyklicznego z uwzględnieniem typu rachunku

Wartość biznesowa:

  • produkt staje się bliższy realnemu zachowaniu inwestora i może wspierać regularne budowanie portfela obligacji

Zakres:

  • dodanie opcji regularnego inwestowania w obligacje, np. co miesiąc lub co rok
  • dodanie opcji kalkulowania inwestycji przez IKE lub IKZE
  • rozbudowa silnika o wpływ rodzaju rachunku i harmonogramu wpłat na wynik końcowy

Kryteria sukcesu:

  • użytkownik może porównać inwestycję jednorazową i regularną
  • wynik końcowy zmienia się zależnie od harmonogramu wpłat i wybranego typu rachunku

5.8 Etap 7. Asystent wejścia do kalkulatora

Priorytet: Średni

Cel:

  • umożliwić użytkownikowi przygotowanie kompletnej symulacji przez dialog zamiast ręcznego wypełniania formularza

Wartość biznesowa:

  • obniża próg wejścia dla mniej technicznych użytkowników
  • skraca drogę od wejścia do pierwszego sensownego wyniku
  • zwiększa użyteczność produktu bez tworzenia osobnego silnika obliczeniowego

Zakres:

  • pytanie startowe, czy użytkownik chce skorzystać z asystenta
  • sekwencja pytań o parametry inwestycji, np. kwotę startową, dopłaty cykliczne, częstotliwość dopłat, horyzont inwestycji, 800+ oraz typ rachunku
  • obsługa sytuacji, w której użytkownik inwestuje jednorazowo albo cyklicznie
  • mapowanie odpowiedzi na ten sam stan formularza, którego używa tryb ręczny
  • uruchamianie tej samej symulacji i tego samego engine co w kalkulatorze ręcznym
  • możliwość przejścia do ręcznej korekty formularza po zakończeniu dialogu

Kryteria sukcesu:

  • użytkownik może dojść do kompletnej symulacji bez ręcznego uzupełniania wszystkich pól
  • wynik uzyskany przez asystenta jest identyczny jak dla tych samych danych wpisanych ręcznie
  • asystent nie tworzy osobnej logiki finansowej, tylko zasila istniejący formularz i engine
  • użytkownik może po dialogu przejść do trybu ręcznego bez utraty danych

6. Zasada aktualizacji UI roadmapy

Ekran roadmapy w aplikacji:

  • powinien odzwierciedlać etapy z tego dokumentu
  • może upraszczać język na potrzeby komunikacji z użytkownikiem
  • nie powinien samodzielnie zmieniać kolejności etapów, priorytetów ani zakresu

Jeśli UI roadmapy i ten dokument przestają być zgodne:

  1. popraw ten dokument, jeśli zmieniła się decyzja produktowa
  2. popraw UI, jeśli zmieniła się tylko prezentacja albo UI zostało w tyle

7. Dokumenty powiązane