Duonaut — strona głównaEN

Pętla wymagań — od rozmowy z klientem do działającego rozwiązania

REQLOOP

System, który zamienia nagraną rozmowę z klientem w działające rozwiązanie — stronę, automatyzację albo agenta. Prowadzi wymagania przez osiem etapów i cztery pętle, aż spełnione są wszystkie mierzalne warunki ukończenia.

Przed

Wymagania są niespisane, sprzeczne i zmieniają się w trakcie, a budowa po cichu odpływa od tego, co ustalono.

Po

Każde wymaganie ma ślad aż do rozwiązania, a każda zmiana przechodzi przez pętlę, zanim dotknie budowy.

Skąd nazwa

Requirements Loop — pętla wymagań.

W typowym projekcie wymagania spisuje się raz, na początku. Potem firma się zmienia, pojawiają się nowe pomysły i uwagi, a dokument z początku przestaje odpowiadać rzeczywistości. Budowane rozwiązanie zaczyna się rozjeżdżać z tym, czego firma naprawdę potrzebuje.

REQLOOP działa inaczej. Każda nowa rozmowa, zmiana albo uwaga wraca do pętli. System porównuje ją z tym, co już ustalono: co zmienia, z czym jest sprzeczna i które części rozwiązania trzeba przez nią poprawić. Dopiero potem zmiana trafia do budowy.

Pilnujemy też prostej kolejności: najpierw ustalamy, czego firma potrzebuje, a dopiero potem decydujemy, jak to zbudować. Wymagania zatwierdza klient i to one są punktem odniesienia dla wszystkiego, co powstaje. Nikt po drodze nie dopisuje ich na własną rękę i nic nie zmienia się bez wiedzy klienta.

Jak działa

Od rozmowy do działającego rozwiązania.

Osiem etapów w trzech sekcjach. W każdej sekcji jedni tworzą, a inni niezależnie sprawdzają — maszyna albo człowiek.

  1. 01co i dlaczego

    Odkrycie

    Ustala, czego klient potrzebuje, i niczego nie projektuje. Niczego też nie dopowiada: luki oznacza i zamienia w pytania.

    1. 01Ekstrakcja wymagań z nagrania
    2. 02Audyt wierności wobec rozmowy
    3. 03Scalanie odpowiedzi i zmian

  2. 02jak

    Projekt

    Decyduje, co i czym zbudować, i wyznacza mierzalną definicję ukończenia. Każdą decyzję architektoniczną zatwierdza człowiek.

    1. 04Architektura rozwiązania
    2. 05Scenariusz pętli i bramki ukończenia

  3. 03wykonanie

    Budowa

    Buduje iteracja po iteracji, aż przejdą wszystkie bramki. Nie wymyśla wymagań i nigdy nie obniża poprzeczki, żeby skończyć.

    1. 06Budowa iteracji
    2. 07Niezależna weryfikacja bramek
    3. 08Sterowanie pętlą

Cztery pętle

Każda pętla wie, kiedy się zatrzymać.

Kończy się gotowym wynikiem albo przekazaniem decyzji człowiekowi. Żadna nie kręci się bez końca i żadna nie ogłasza sukcesu, zanim cel zostanie osiągnięty.

  1. 01 · maszyna ↔ maszyna

    Pętla wierności

    Ekstrakcja i niezależny audyt wymieniają uwagi, aż wymagania wiernie oddają rozmowę. Najwyżej trzy rundy — potem decyduje człowiek.

  2. 02 · człowiek ↔ klient

    Pętla kompletności

    Otwarte pytania trafiają do klienta, a odpowiedzi wracają do specyfikacji i przechodzą ponowny audyt — aż nie zostanie żadna krytyczna luka.

  3. 03 · maszyna + bramki człowieka

    Pętla budowy

    Budowa, weryfikacja i sterowanie, iteracja za iteracją, aż przejdą wszystkie bramki. Trzy porażki tej samej bramki to eskalacja albo powrót do projektu.

  4. 04 · klient · pierścień zewnętrzny

    Pętla akceptacji

    Uwagi klienta po prezentacji wracają jako zmiana wymagań, nigdy jako łatka w kodzie. Pętle ruszają ponownie — mądrzejsze o nową wiedzę.

Bramki

Bramki jako fundament skutecznej pętli.

Bramka to konkretny warunek, który da się sprawdzić: spełniony albo nie. Klient zatwierdza listę bramek przed startem budowy, a rozwiązanie jest gotowe dopiero wtedy, gdy spełnia wszystkie.

  • AUTO

    Sprawdzane automatycznie

    Te warunki sprawdza maszyna — na podstawie tego, jak rozwiązanie naprawdę działa, a nie zapewnień tego, kto je zbudował. Sprawdza je inny model niż ten, który budował, więc nikt nie ocenia własnej pracy.

  • HUMAN

    Sprawdzane przez człowieka

    Tam, gdzie potrzebna jest ludzka ocena — na przykład czy rozwiązanie jest wygodne dla zespołu — praca zatrzymuje się i czeka na decyzję. Takie momenty zbieramy razem, żeby nie odrywać ludzi od pracy co chwilę.

Artefakty

Ślad od wymagania do działającego rozwiązania.

Każdy element ma stały identyfikator, który nigdy się nie zmienia. Każdą część rozwiązania da się prześledzić wstecz aż do wymagania klienta.

artefakty / ślad

  1. REQ-014Wymaganie klienta
  2. ARCH-03Decyzja architektoniczna
  3. GATE-07Bramka ukończenia
  4. ITER-2Iteracja budowy
  5. ✓Działające rozwiązanie

Zmiana wymagania

  • REQ-014SUPERSEDEDzastąpione, nie skasowane
  • REQ-031ACTIVEnowa wersja wymagania
  • ARCH-03STALEdecyzja do rewizji
  • GATE-07STALEbramka do rewizji

budowa wstrzymana, dopóki ślad nie jest czysty

Zmiana to nowa wersja

Zmienione wymaganie nie nadpisuje starego. Powstaje nowe, a poprzednie zostaje w historii — wiadomo, co, kiedy i dlaczego się zmieniło.

Ochrona przed dryfem

Wszystko, co wynikało ze zmienionego wymagania, zostaje oznaczone do przeglądu. Budowa nie ruszy, dopóki każda zależna decyzja i bramka nie zostanie zrewidowana.

Człowiek w pętli

Pięć momentów, w których decyduje człowiek.

  • 01StartNagranie rozmowy z klientem uruchamia cały proces.
  • 02Po odkryciuAkceptacja wymagań i odpowiedzi na otwarte pytania, które zamykają luki.
  • 03Po architekturzeZatwierdzenie albo odrzucenie każdej decyzji architektonicznej z osobna.
  • 04Przed budowąPodpis pod definicją ukończenia, czyli pod pełnym zestawem bramek. Bez niego budowa nie rusza.
  • 05W trakcie i po budowieOcena bramek ludzkich i prezentacja gotowego rozwiązania. Między tymi momentami system pracuje sam.

Dlaczego

Jaki problem rozwiązuje

Wymagania są klasycznym punktem załamania projektów informatycznych. Bywają niespisane, bo „wszyscy wiedzą, o co chodzi”. Bywają sprzeczne, bo każdy dział opisuje ten sam proces inaczej. I zmieniają się w trakcie, bo dopiero działające rozwiązanie pokazuje, czego naprawdę potrzeba.

Najczęściej nie zawodzi technologia, tylko droga od rozmowy do budowy: ustalenia giną po drodze, zmiany trafiają prosto do kodu, a rozwiązanie po cichu odpływa od tego, co uzgodniono. REQLOOP zamyka tę drogę w pętle z mierzalnym końcem — tak, żeby luki i sprzeczności wychodziły na etapie wymagań, a nie na produkcji.

Gdzie pracuje

REQLOOP pracuje w Audycie gotowości i przy przygotowaniu pilota. Razem z Automatic Workshop Analyser prowadzi projekt od odkrycia procesu, przez wymagania, aż do działającego rozwiązania.

Podział pracy jest prosty: system wyciąga wymagania, sprawdza je i buduje, a człowiek zatwierdza wszystko, co wymaga decyzji. Klient dostaje wynik tej pracy — zatwierdzone wymagania, uzgodnioną definicję ukończenia i działające rozwiązanie — a nie kolejne narzędzie do obsługi.

Co to znaczy dla organizacji

Organizacja dostaje wymagania, które może przeczytać, zweryfikować i zatwierdzić, zanim zapłaci za budowę — i definicję ukończenia, którą podpisuje, zanim budowa ruszy.

Rozwiązanie, które powstaje na takiej podstawie, łatwiej też utrzymać i rozwijać. Każdą jego część da się prześledzić do wymagania, z którego wynika, więc każda późniejsza zmiana ma punkt odniesienia.

Co to znaczy dla klienta

Firma dostaje dokładnie to, co ustaliła, i od początku wie, po czym pozna, że rozwiązanie jest gotowe.
Zmiana zdania w trakcie projektu nie wywraca budowy — przechodzi przez pętlę i trafia do rozwiązania bez chaosu.

Inne systemy

Porozmawiajmy.

30 minut · bez prezentacji · bez zobowiązania

Umów rozmowęSesja dla zarząduAudyt gotowości AI
info@duonaut.com