Zaczynanie "od tyłu strony" vs. Agile

somekind napisał(a):

Tak, w świecie idealnie doskonałych projektantów zbierających doskonale precyzyjne wymagania od idealnie rozgarniętych klientów... to i tak by nie działało, bo po 5 lat cały genialny projekt może być już zbędny przez zmiany w prawie, koniunkturze albo po prostu będzie tak odstawał wyglądem od standardu na rynku, że nikt nie będzie chciał tego używać.

Istnieje bardzo dużo projektów, gdzie wymagania są znane precyzyjnie przed rozpoczęciem projektu.
Przede wszystkim bardzo wiele projektów to reimplementacje istniejących projektów - robienie tego samego tylko trochę lepiej / w nowocześniejszej technologii itp.

I również wiele projektów, gdzie wymagania wcale się bardzo się nie zmieniają.
Nadal istnieje bardzo wiele systemów mających po 20 lat i więcej, które działają do dziś i spełniają swoje potrzeby.
Niedawno widziałem całkiem fajny POS napisany prawdopodobnie w jakimś Turbo Pascalu / Turbo C++ (charakterystyczne okienka Turbo Vision, tryb 80x25). I działało to zarąbiście dobrze.

Druga rzecz - nigdzie w definicji waterfalla nie jest powiedziane, że projekt musi trwać 5 lat. Wiadomo, ze tej metodyki nie wybiera się do robienia gigantycznych projektów o takiej skali czasowej w dziedzinach gdzie wiadomo że wymagania się zmieniają (np. prawo). Ta metodyka ma swoje wady znane tak od lat 1960 lub wcześniej. Z mojego doświadczenia najlepiej sprawdzają się podejścia hybrydowe - gdzie jednak mamy trochę waterfalla na początku, ale ograniczamy go do małego MVP a potem rozwijamy projekt szybkimi iteracjami.

To właśnie w scrumie masz ten problem ze możesz zapędzić się w kozi róg i nagle okazuje się że twoje 100k linii napisanych w poprzednich sprintach nadaje się do przepisania.

Jak mogę się zapędzić, skoro po 1-3 tygodniach widać, czy się nie zbłądziło, więc co najwyżej tyle pracy można stracić?

No właśnie tak możesz się zapędzić, że ponieważ realizujesz wymagania przyrostowo (i niejako odkrywasz je w trakcie a nie na początku), to po zrealizowaniu 99 wymagań klienta możesz natrafić na te setne wymaganie, które nagle wywraca cały system do góry nogami. I mam na to trzy przykłady z życia.

1. Apka do radia. Pisałem kiedyś o tym chyba w wątku WTF. Jak najbardziej robiona "zwinnie" - klient chciał widzieć postęp to go widział. Co tydzień nowe ficzery w UI. A to wyświetlanie okładek albumów, a to wyszukiwarka, a to możliwość zapisu ulubionych, a to nowa fancy grafika itp. No po prostu projekt szedł jak burza. Wprawdzie odtwarzał cały czas jedną nagraną lokalnie piosenkę w jakimś wavie bo "to na razie wystarczy na potrzeby demo", ale klient widział, że śmiga. No i na 2 tygodnie przed deadlinem chłopaki dopisali interfejs do streamów i podpięli prawdziwy kodek do radia (AAC) i okazało się że dupa, nie odtwarza radia tylko ciągle się tnie. Pożar w firmie był nieziemski. Napisali apkę do radia, która nie odtwarza radia xD

2. Serwis do wyszukiwania ogłoszeń. Nie ja pisałem, ale konsultowałem na końcu jak wybuchł pożar. Zatrudnieni jacyś tani pehapowcy, implementowali serwis przez rok i w sumie wszystko działało. No prawie. Bo na końcu okazało się, że to ma działać na milionie ogłoszeń a nie dziesięciu. I całą koncepcję użycia MySQLa na jednym serwerze do tego szlag trafił, a sprawa skończyła się w sądzie.

3. Słynna próba napisania solvera sudoku przez pewnego piewcę agile / TDD (Ron Jeffries), którą tu już kiedyś przytaczałem. Podobna sytuacja - napisał kupę ładnego kodu, jak najbardziej iteracyjnie (chyba z 5 postów na blogu) ale doszedł do ściany bo nie wiedział jak tak naprawdę rozwiązać główny problem. Są pewne rzeczy, których nie da się rozwiązać / projektować przyrostowo - albo bierzesz pod uwagę od początku wszystkie kluczowe wymagania, albo zostajesz z czymś co zupełnie nie działa.

W przypadku waterfalla, zrobiłbyś analizę wszystkich wymagań na początku i wytypował wymagania najbardziej ryzykowne. I te byś zrealizował w pierwszej kolejności.

Krolik napisał(a):

W ogóle po to w inżynierii stosuje się projekty aby zmniejszyć ryzyko że coś pójdzie nie tak podczas budowy czy użytkowania.

Tak, w inżynierii.
IT to nie jest inżynieria. Może za kilkadziesiąt lat będzie, jak ludzie wyrosną z etapu stosowania jednego narzędzia do wszystkich problemów, i związanej z tym tej ciągłej huśtawki, w której najpierw się technologię kocha i źle używa, a potem nienawidzi winiąc za fiasko przedsięwzięcia.

IT to jest inżynieria, a w każdym razie powinna być.

@Królik:

Apka do radia. Pisałem kiedyś o tym chyba w wątku WTF. Jak najbardziej robiona "zwinnie" - klient chciał widzieć postęp to go widział. Co tydzień nowe ficzery w UI. A to wyświetlanie okładek albumów, a to wyszukiwarka, a to możliwość zapisu ulubionych, a to nowa fancy grafika itp. No po prostu projekt szedł jak burza. Wprawdzie odtwarzał cały czas jedną nagraną lokalnie piosenkę w jakimś wavie bo "to na razie wystarczy na potrzeby demo", ale klient widział, że śmiga. No i na 2 tygodnie przed deadlinem chłopaki dopisali interfejs do streamów i podpięli prawdziwy kodek do radia (AAC) i okazało się że dupa, nie odtwarza radia tylko ciągle się tnie. Pożar w firmie był nieziemski. Napisali apkę do radia, która nie odtwarza radia xD

Ciekawy przykład, bo z jednej strony metodyka mogła działać, a z drugiej zachęcać do sabotowania (chociaż może niekoniecznie umyślnie).

Jeżeli inżyniery rozumiały że faktycznie odtworzenie radia jest najcięższe i na początek brali łatwe featuresy (search, albumy) aby mieć się czym chwalić na ceremonii scrumowej, to wtedy metodyka nie pomagała.

Ale z drugiej strony jeżeli inżyniery faktycznie były świadome że odtwarzanie jest najcięższe, to powinni to robić jako #1 rzecz, bo wszystko inne już implementowali pewnie z 50 razy i nie była potrzebna żadna PoCka. I tutaj metodyka jakby nie miała nic do gadania.

Krolik napisał(a):

Istnieje bardzo dużo projektów, gdzie wymagania są znane precyzyjnie przed rozpoczęciem projektu.
Przede wszystkim bardzo wiele projektów to reimplementacje istniejących projektów - robienie tego samego tylko trochę lepiej / w nowocześniejszej technologii itp.

Ktoś się orientuje w jakiej metodologii obecnie tworzą Waylanda jako zamiennik Xów? To chyba byłby ciekawy use case powyższego.

Krolik napisał(a):

Istnieje bardzo dużo projektów, gdzie wymagania są znane precyzyjnie przed rozpoczęciem projektu.
Przede wszystkim bardzo wiele projektów to reimplementacje istniejących projektów - robienie tego samego tylko trochę lepiej / w nowocześniejszej technologii itp.
I również wiele projektów, gdzie wymagania wcale się bardzo się nie zmieniają.

No dobrze, ale istnieje też bardzo dużo projektów, w których tak nie jest. Być może nawet większość.

Nadal istnieje bardzo wiele systemów mających po 20 lat i więcej, które działają do dziś i spełniają swoje potrzeby.
Niedawno widziałem całkiem fajny POS napisany prawdopodobnie w jakimś Turbo Pascalu / Turbo C++ (charakterystyczne okienka Turbo Vision, tryb 80x25). I działało to zarąbiście dobrze.

Ok, ale trochę nie rozumiem, co to ma do tematu. :)

Druga rzecz - nigdzie w definicji waterfalla nie jest powiedziane, że projekt musi trwać 5 lat. Wiadomo, ze tej metodyki nie wybiera się do robienia gigantycznych projektów o takiej skali czasowej w dziedzinach gdzie wiadomo że wymagania się zmieniają (np. prawo). Ta metodyka ma swoje wady znane tak od lat 1960 lub wcześniej.

Wiadomo? A skąd wiadomo? Kto o tym wie? Czy wszyscy, którzy za tworzenie softu odpowiadają o tym wiedzą?
Nie wydaje mi się, żeby w tej branży cokolwiek jeśli chodzi o organizowanie projektów było wiadome.

Z mojego doświadczenia najlepiej sprawdzają się podejścia hybrydowe - gdzie jednak mamy trochę waterfalla na początku, ale ograniczamy go do małego MVP a potem rozwijamy projekt szybkimi iteracjami.

To zaczynanie od MVP i sprawdzenie, czy da się to zrobić, to w moim odczuciu właśnie jest właśnie agile. A jak przeznaczymy na MVP dwa sprinty, to to w ogóle scrum będzie. I chyba żadnego związku z waterfallem.
Ale można w sumie uznać, że wszystko jest waterfallem. Bo jak się będzie dzielić na etapy zaczynające się od planu, a kończące wdrożeniem, to się okaże, że np. scrum, task, czy dzień roboczy - to wszystko są waterfalle.

No właśnie tak możesz się zapędzić, że ponieważ realizujesz wymagania przyrostowo (i niejako odkrywasz je w trakcie a nie na początku), to po zrealizowaniu 99 wymagań klienta możesz natrafić na te setne wymaganie, które nagle wywraca cały system do góry nogami. I mam na to trzy przykłady z życia.

1. Apka do radia. Pisałem kiedyś o tym chyba w wątku WTF. Jak najbardziej robiona "zwinnie" - klient chciał widzieć postęp to go widział. Co tydzień nowe ficzery w UI. A to wyświetlanie okładek albumów, a to wyszukiwarka, a to możliwość zapisu ulubionych, a to nowa fancy grafika itp. No po prostu projekt szedł jak burza. Wprawdzie odtwarzał cały czas jedną nagraną lokalnie piosenkę w jakimś wavie bo "to na razie wystarczy na potrzeby demo", ale klient widział, że śmiga. No i na 2 tygodnie przed deadlinem chłopaki dopisali interfejs do streamów i podpięli prawdziwy kodek do radia (AAC) i okazało się że dupa, nie odtwarza radia tylko ciągle się tnie. Pożar w firmie był nieziemski. Napisali apkę do radia, która nie odtwarza radia xD

2. Serwis do wyszukiwania ogłoszeń. Nie ja pisałem, ale konsultowałem na końcu jak wybuchł pożar. Zatrudnieni jacyś tani pehapowcy, implementowali serwis przez rok i w sumie wszystko działało. No prawie. Bo na końcu okazało się, że to ma działać na milionie ogłoszeń a nie dziesięciu. I całą koncepcję użycia MySQLa na jednym serwerze do tego szlag trafił, a sprawa skończyła się w sądzie.

3. Słynna próba napisania solvera sudoku przez pewnego piewcę agile / TDD (Ron Jeffries), którą tu już kiedyś przytaczałem. Podobna sytuacja - napisał kupę ładnego kodu, jak najbardziej iteracyjnie (chyba z 5 postów na blogu) ale doszedł do ściany bo nie wiedział jak tak naprawdę rozwiązać główny problem. Są pewne rzeczy, których nie da się rozwiązać / projektować przyrostowo - albo bierzesz pod uwagę od początku wszystkie kluczowe wymagania, albo zostajesz z czymś co zupełnie nie działa.

W przypadku waterfalla, zrobiłbyś analizę wszystkich wymagań na początku i wytypował wymagania najbardziej ryzykowne. I te byś zrealizował w pierwszej kolejności.

Ci ludzie schrzanili, może z braku doświadczenia, a może pomyślunku, ale na pewno nie dlatego, że pracowali w takiej, a nie innej metodyce.
Czy scrum zabrania testowania wydajnościowego? Czy którekolwiek podejście agile zabrania analizowania wymagań i technologii na początku projektu?

IT to jest inżynieria, a w każdym razie powinna być.

No cóż, taka różnica między teorią a praktyką.

@somekind:

Ci ludzie schrzanili, może z braku doświadczenia, a może pomyślunku, ale na pewno nie dlatego, że pracowali w takiej, a nie innej metodyce.

Pisałem wyżej - "Jeżeli inżyniery rozumiały że faktycznie odtworzenie radia jest najcięższe i na początek brali łatwe featuresy (search, albumy) aby mieć się czym chwalić na ceremonii scrumowej, to wtedy metodyka nie pomagała."

WeiXiao napisał(a):

@somekind:

Ci ludzie schrzanili, może z braku doświadczenia, a może pomyślunku, ale na pewno nie dlatego, że pracowali w takiej, a nie innej metodyce.

Pisałem wyżej - "Jeżeli inżyniery rozumiały że faktycznie odtworzenie radia jest najcięższe i na początek brali łatwe featuresy (search, albumy) aby mieć się czym chwalić na ceremonii scrumowej, to wtedy metodyka nie pomagała."

Skoro były jakieś ficzery do brania, to znaczy, że ktoś je wszystkie spisał. Skoro to był scrum i brali taski do roboty, to znaczy, że je wcześniej wyestymowali.
W jaki sposób wyestymowali implementację radia, skoro nie wiedzieli jak to zrobić?

Pisałem wyżej - "Jeżeli inżyniery rozumiały że faktycznie odtworzenie radia jest najcięższe i na początek brali łatwe featuresy (search, albumy) aby mieć się czym chwalić na ceremonii scrumowej, to wtedy metodyka nie pomagała."

@WeiXiao Nie pomagała bo zawalił Product Owner czy jakiś inny kieras, który nie nadał albo nadał złe priorytety programistom. Z doświadczenia wiem że ludzie biznesu patrzą obrazkami i jak najszybciej chcą dowieźć UI. Nie ważne że pod spodem wszystko stoi na mockach, ważne że ładnie wygląda i można się pochwalić przed klientem, a backend to się doda później i programiści nie mają nic do gadania.

Jak lubię pohejtować Scruma i rzadko podzielam entuzjazm @somekind a w tym temacie to tu się z nim zgadzam, że to nie wina samej metodyki tylko tego jak projekt był prowadzony.

Z doświadczenia wiem że ludzie biznesu patrzą obrazkami i jak najszybciej chcą dowieźć UI

I to jest właśnie robienie od d**y strony :(
To tak jakbyś miał zamodelować układ słoneczny ale robisz od strony Ziemi czyli najpierw Ptolemeusz bo najtaniej. Jednak po roku pracy ktoś się orientuje ze coś się nie zgadza wiec zmieniasz na Kopernika. Jednak po dwóch latach pracy ktoś się orientuje ze znów coś die nie zgadza i robisz Keplera

Problem jest taki ze od właściwej strony wcale nie jest oczywiste jak zrobić. W przypadku układu słonecznego znamy wszystkie prawa. Ale w przypadku przeciętnej aplikacji biznesowej często nie znamy wszystkich reguł jakie potrzebują wiec iteracyjne dostarczamy kolejne okłady zamiast zrobić wersje ostateczną :(

UPDATE w magicznym osobo miesiącu było napisane ze 50 lat temu siadali architekci z analitykami i spisywali WSZYSTKIE prawa/zasady jakie maja być w aplikacji. Soft był projektowany jak katedra.

Dziś nie ma na to już czasu wiec robi się trochę na hurra co akurat klientowi się przypomni i katedry to już nie przypomina. Z drugiej strony soft nie jest od modlenia się tylko od robienia pieniędzy

Krolik napisał(a):

Jak najbardziej robiona "zwinnie" (...) Wprawdzie odtwarzał cały czas jedną nagraną lokalnie piosenkę w jakimś wavie bo "to na razie wystarczy na potrzeby demo", ale klient widział, że śmiga. No i na 2 tygodnie przed deadlinem chłopaki dopisali interfejs do streamów i podpięli prawdziwy kodek do radia (AAC) i okazało się że dupa, nie odtwarza radia tylko ciągle się tnie. Pożar w firmie był nieziemski. Napisali apkę do radia, która nie odtwarza radia xD

No to nie było agile XD manifest agile wspomina o tym, że miarą postępu ma być working software. A jeśli robili jakieś demówki i nie dążyli nawet do tego, żeby dostarczyć działający soft, to gdzie tu zwinność?

Ale faktycznie waterfall to nie był.

Może potrzebujemy osobnej nazwy. Bo z faktu, że coś nie jest waterfallem, nie wynika wcale, że jest to podejście zwinne (jeśli za definicje zwinności uznamy Agile Manifesto, Extreme Programming, Lean czy Scrum - czyli filozofie, które proponują szybkie iteracje, ale również empiryczne podejście do programowania, czyli wszystko się sprawdza, czy ma sens, czy działa, czy można ulepszyć).

A to, co opisałeś, to bardziej Demo Driven Development, czyli pokazywanie klientowi prototypu i twierdzenie, że to wersja produkcyjna.

1. Serwis do wyszukiwania ogłoszeń. Nie ja pisałem, ale konsultowałem na końcu jak wybuchł pożar. Zatrudnieni jacyś tani pehapowcy, implementowali serwis przez rok i w sumie wszystko działało. No prawie. Bo na końcu okazało się, że to ma działać na milionie ogłoszeń a nie dziesięciu. I całą koncepcję użycia MySQLa na jednym serwerze do tego szlag trafił, a sprawa skończyła się w sądzie.

No to mieli słabe umiejętności techniczne i nie umieli joina zrobić czy zoptymalizować odpowiednio, bo np. nie mieli doświadczenia. Ale przecież ktoś ich zatrudnił.

implementowali serwis przez rok

BTW przez rok ogólnie to działało na produkcji, czy przez rok do pierwszej wersji produkcyjnej? Jak to drugie, to też raczej zwinne to nie było.

markone_dev napisał(a):

Z doświadczenia wiem że ludzie biznesu patrzą obrazkami i jak najszybciej chcą dowieźć UI.

Gdyby tak było to byłoby całkiem nieźle. Jednak rzeczywistość jest często mniej kolorowa:

• musimy mieć wielojęzyczność (zróbcie teraz, bo potem będzie trudniej), nieważnie, że aplikacja dość techniczna i skierowana do klientów, którzy angielski muszą znać
• musimy mieć multitenancy - security najważniejsze, nieważne że prawie pewne, że każdy klient (specyfika branży) będzie chciał mieć własną instancję serwera
• musi być zarządzanie użytkownikami, nieważne że specyfika aplikacji jest taka, że jedno konto dla klienta wystarczy na 99% przypadków i to konto admina na jego własnym serwerze :-),
• musi być historia zmian
• itd.

I potem dostarczamy aplikację do prognozowania kosztów czegoś tam na podstawie zaimportowanych CSV, która umie wszystko co wyżej oprócz prognozowania kosztów. Te priorytety wymyślił biznes mający długie doświadczenie w prowadzeniu projektów bankowych.

KamilAdam napisał(a):

UPDATE w magicznym osobo miesiącu było napisane ze 50 lat temu siadali architekci z analitykami i spisywali WSZYSTKIE prawa/zasady jakie maja być w aplikacji. Soft był projektowany jak katedra.

Dziś nie ma na to już czasu wiec robi się trochę na hurra co akurat klientowi się przypomni i katedry to już nie przypomina. Z drugiej strony soft nie jest od modlenia się tylko od robienia pieniędzy

Nie tylko nie ma czasu, ale chodzi o to, że często się odchodzi od projektowania w ogóle na rzecz analityk, testów A/B czy różnych metryk.

W apkach typu Facebook coś może zniknąć albo się pojawić nie dlatego, że ktoś tak zaprojektował, ale dlatego że ktoś zrobił taki eksperyment i wyszło w statystykach, że to przyciąga zaangażowanie ludzi, to zostawiamy. A jakiś ficzer, który generuje mało zysków/zaangażowania, to usuwamy, nawet jeśli wielu ludzi to wkurzy, to jednak procenty zaangażowania pójdą w górę, więc finalnie firma i tak zarobi.

Czyli software nie jest już projektowany, tylko sam się projektuje, a pracownicy w firmach są tylko katalizatorami ewolucji.

Podobnie software już nie ma dostarczać wartości użytkownikowi, a jedynie go utrzymać jak najdłużej i najwięcej reklam wyświetlić czy żeby się wskaźniki zwiększyły. Dlatego w tego typu organizacjach (które tak robią) nie ma miejsca na waterfall, bo nikt tak naprawdę nie wie, co będzie za tydzień, jeśli dane przemielone z analityk i machine learning powiedzą, że trzeba zaimplementować to i to, to programiści będą to musieli robić.

LukeJL napisał(a):

Nie tylko nie ma czasu, ale chodzi o to, że często się odchodzi od projektowania w ogóle na rzecz analityk, testów A/B czy różnych metryk.

W apkach typu Facebook coś może zniknąć albo się pojawić nie dlatego, że ktoś tak zaprojektował, ale dlatego że ktoś zrobił taki eksperyment i wyszło w statystykach, że to przyciąga zaangażowanie ludzi, to zostawiamy. A jakiś ficzer, który generuje mało zysków/zaangażowania, to usuwamy, nawet jeśli wielu ludzi to wkurzy, to jednak procenty zaangażowania pójdą w górę, więc finalnie firma i tak zarobi.

Czyli tak skrótowo - predykcja w tworzeniu software nie ma ekonomicznego sensu bo wszystko można zastąpić testami na produkcji?

jarekr000000 napisał(a):

markone_dev napisał(a):

Z doświadczenia wiem że ludzie biznesu patrzą obrazkami i jak najszybciej chcą dowieźć UI.

Gdyby tak było to byłoby całkiem nieźle. Jednak rzeczywistość jest często mniej kolorowa:

• musimy mieć wielojęzyczność (zróbcie teraz, bo potem będzie trudniej), nieważnie, że aplikacja dość techniczna i skierowana do klientów, którzy angielski muszą znać
• musimy mieć multitenancy - security najważniejsze, nieważne że prawie pewne, że każdy klient (specyfika branży) będzie chciał mieć własną instancję serwera
• musi być zarządzanie użytkownikami, nieważne że specyfika aplikacji jest taka, że jedno konto dla klienta wystarczy na 99% przypadków i to konto admina na jego własnym serwerze :-),
• musi być historia zmian
• itd.

I potem dostarczamy aplikację do prognozowania kosztów czegoś tam na podstawie zaimportowanych CSV, która umie wszystko co wyżej oprócz prognozowania kosztów. Te priorytety wymyślił biznes mający długie doświadczenie w prowadzeniu projektów bankowych.

Myślę, że każdy kto ma trochę więcej doświadczenia w IT będzie mógł przywołać niejedną taką sytuację, bo to jest dokładnie to o czym pisałem czyli źle dobrane priorytety i skupianie się na wszystkim dookoła zamiast głównej funkcjonalności systemu.

A ja, jako samozwańcza osoba techniczna cenię sobie podejście od UI. Użytkownik, czy tzw. "biznes" ma w dupie, czy na backendzie coś jest, czy tego backendu nie ma wcale, albo czy jest tam monolit na WebSphere, czy CQRSy i event sourcingi na serwerlessach. Interesuje ich to co aplikacja robi i to w sposób, który użytkownicy docenią. Chyba, że akurat mamy taki biznes, co nie ma pojęcia ani o technologii, ani o biznesie, to wtedy zaczyna się pierniczenie o tym, jak to zespół w poprzednim sprincie dowiózł 24 story pointy, a w tym już 27, co oznacza 12% wzrost wydajności w ujęciu sprint do sprintu i pozwala wysnuć wniosek, że cały nasz projekt przewidziany na 3 lata zajmie 2.5 roku.
UI to dobry sposób pokazania postępów w aplikacji, wychwycenia problemów z jej funkcjonalnością na wczesnym etapie. Problem pojawia się wtedy, jak powstaje wydmuszka w postaci UI, która zadziała, jak kiedyś pojawi się ten mityczny backend. Dlatego planowanie powinno być oparte o funkcje systemu, a o komponenty architektoniczne i te funkcje powinny być implementowane na wszystkich warstwach ~równolegle.

@jarekr000000: Właśnie pracuję nad aplikacją, która ma pobrać dokumenty z serwera i je wyświetlić. Taki ebook reader, tylko prostszy. Robi wiele rzeczy, ale akurat ani pobrać, ani wyświetlić dokumentu nie potrafi. Było wiele prób sprawienia, żeby aplikacja była w stanie wykonywać swoje podstawowe funkcje, ale ani w wersji 1.0, ani w 2.0 się to nie udało. Teraz mam pod sobą wersję 3.0 i ostatnio pilną funkcją było użycie LLM AI, które można byłoby odpytywać o treść tych dokumentów, których nie udało się jak na razie pobrać.