Jak uratować albo rozwinąć platformę EdTech/HRTech? 7 podejść, które warto znać

Pierwszy krok to sprawdzenie jakości delivery, poziomu dokumentacji, standardów learningowych i ryzyka lock-in, bo raport DORA z 2024 roku nadal opiera ocenę delivery na czterech metrykach, a raport z 2021 roku pokazał średni change failure rate na poziomie 7,5% u elite performers i 23% u low performers.

Najważniejsze wnioski z artykułu

1. Nie zaczynaj od pytania o nowy system. Zacznij od pytania, co dziś blokuje rozwój produktu.

2. Cztery metryki DORA dają prosty punkt startu. To deployment frequency, lead time for changes, change failure rate i time to restore.

3. Problem platformy siedzi w jednym z pięciu miejsc. To delivery, architektura, integracje, dokumentacja albo model współpracy.

4. Istnieje 7 sensownych podejść do naprawy lub rozwoju. Nie każde daje ten sam koszt, ryzyko i wpływ na roadmapę.

5. SCORM, xAPI, LTI, WCAG 2.2 i GDPR wpływają na decyzję techniczną. To nie są dodatki na później.

6. Mały zakres startowy daje większą kontrolę. Audyt, recovery sprint albo discovery pod takeover dają lepszy punkt wejścia niż szeroki projekt od razu.

Nie każda problematyczna platforma EdTech/HRTech wymaga dużej przebudowy. Raport DORA z 2024 roku nadal traktuje deployment frequency, lead time for changes, change failure rate i time to restore jako podstawowe metryki zdrowia delivery.

Platforma nie psuje się od samego wieku kodu. Psuje się od złej kombinacji jakości delivery, długu technologicznego, słabej architektury i chaosu wokół ownershipu. Pierwsza diagnoza dotyczy problemu, a nie technologii. To jest ważne dla istniejącej platformy learningowej, bo zły wybór na starcie blokuje roadmapę produktu. 

Mówiąc po ludzku, cztery metryki DORA odpowiadają na cztery proste pytania. Jak często wdrażacie zmiany. Jak długo zmiana idzie od commita do wdrożenia. Jaki procent zmian kończy się awarią albo pilną naprawą. Ile czasu zajmuje powrót do stabilnego działania po incydencie.

• Release’y regularnie kończą się regresją albo rollbackiem.

• Change failure rate jest bliżej 23% niż 7,5%, więc tempo delivery rośnie razem z ryzykiem awarii.

• Dokumentacja jest tak słaba, że takeover grozi utratą wiedzy, a raport DORA 2021 pokazuje, że zespoły z dobrą dokumentacją osiągają lepszy software delivery performance.

• Code review stało się wąskim gardłem, a raport z 2023 roku łączy szybsze review z 50% wyższym software delivery performance.

• Backlog rośnie, a koszt napraw po każdym releasie rośnie razem z nim.

Dokumentacja techniczna daje więcej niż porządek w Confluence. Raport DORA z 2021 roku pokazuje, że lepsza dokumentacja łączy się z lepszym software delivery performance, a raport z 2023 roku łączy szybsze code review z 50% wyższym performance delivery. Takeover bez dokumentacji i bez wiedzy o ownershipie zwiększa ryzyko bardziej niż sam dług technologiczny. To samo dotyczy platformy po redesignie, która wygląda nowocześnie, ale nadal ma regresje po zmianach. W takim układzie audyt techniczno-produktowy daje lepszy punkt startu niż nowy zakres developmentu.

Najczęstszy błąd jest prosty. Zespół widzi wolne delivery i zakłada, że brakuje ludzi. Gdy problem siedzi w architekturze, integracjach albo modelu pracy z obecnym vendorem, samo dokładanie capacity nie rozwiązuje problemu. Wtedy rośnie koszt błędnej decyzji i rośnie presja na rewrite, choć źródło problemu leży gdzie indziej. Dlatego diagnoza ma odpowiedzieć, czy platformę trzeba ratować, czy tylko odblokować jej rozwój.

Dobra decyzja nie zaczyna się od hasła „nowy system”. Istnieje 7 sensownych scenariuszy działania, a pełny rewrite jest opcją końcową, bo istniejąca platforma EdTech/HRTech wymaga najpierw odzyskania kontroli nad delivery i wiedzą o produkcie.

Tutaj dostajesz konkretną roadmapę. Każde z tych 7 podejść działa w innym układzie ryzyka, czasu i wpływu na roadmapę. To jest rdzeń decyzji dla rozwoju istniejącego produktu. Ten układ nazywam recovery first modernization, bo stabilność produktu idzie przed dużą przebudową.

Pierwsze trzy podejścia dotyczą szybkiego rozpoznania i odciążenia zespołu. Audyt techniczno-produktowy porządkuje obraz sytuacji. Recovery sprint przywraca stabilność po nieudanym releasie albo po redesignie. Wsparcie obecnego zespołu daje sens wtedy, gdy problem siedzi w capacity, a nie w fundamencie produktu. Te trzy ścieżki dają krótki start i nie zamrażają roadmapy.

1. Audyt techniczno-produktowy. Kiedy wybrać: gdy nie widać, czy problem siedzi w architekturze, procesie czy vendorze. Największe ryzyko: zbyt szeroki zakres. Wpływ na roadmapę: niski. Wpływ na lock-in: obniża, bo porządkuje wiedzę.

2. Recovery sprint. Kiedy wybrać: gdy releasy psują produkcję. Największe ryzyko: leczenie objawów bez źródła problemu. Wpływ na roadmapę: krótki spadek, potem odbicie. Wpływ na lock-in: neutralny.

3. Wsparcie obecnego zespołu. Kiedy wybrać: gdy zespół nie wyrabia z zakresem. Największe ryzyko: utrwalenie złego procesu. Wpływ na roadmapę: dodatni. Wpływ na lock-in: niski przy dobrym ownershipie.

4. Takeover od obecnego vendora. Kiedy wybrać: gdy produkt ma wartość, ale model współpracy blokuje rozwój. Największe ryzyko: utrata wiedzy. Wpływ na roadmapę: średni. Wpływ na lock-in: obniża przy dobrej dokumentacji.

5. Modułowa modernizacja. Kiedy wybrać: gdy produkt ma działać dalej bez big bang rewrite. Największe ryzyko: zły wybór modułu startowego. Wpływ na roadmapę: dodatni. Wpływ na lock-in: obniża.

6. Gotowe moduły plus custom development. Kiedy wybrać: gdy część funkcji jest powtarzalna. Największe ryzyko: słabe dopasowanie modułu do domeny. Wpływ na roadmapę: dodatni. Wpływ na lock-in: zależy od architektury.

7. Selective rewrite krytycznych obszarów. Kiedy wybrać: gdy jeden fragment blokuje całość. Największe ryzyko: zły wybór granicy przepisywanego obszaru. Wpływ na roadmapę: kontrolowany. Wpływ na lock-in: obniża przy dobrym ownershipie.

Takeover, modułowa modernizacja i selective rewrite wymagają porządku w wiedzy o produkcie. Ten porządek bierze się z dokumentacji, handoveru i jasnych decyzji o ownershipie. Bez tego nawet dobry scenariusz zmienia się w kosztowny chaos. To jest ważne także przy open source LMS, bo otwarty kod nie daje automatycznie kontroli bez procesu i odpowiedzialności. Jedna z największych platform open source deklaruje dziś ponad 70 tysięcy kursów i ponad 140 milionów uczących się, więc skala nie jest problemem samego modelu open source.

Ostatnia rzecz dotyczy full rewrite. Rewrite nie jest neutralnym początkiem.
Rewrite jest najdroższą odpowiedzią wtedy, gdy problemem jest delivery, dokumentacja albo zły vendor model. Ta decyzja ma sens dopiero wtedy, gdy model domenowy albo architektura blokują cele produktu wprost.
Dlatego lista 7 podejść daje lepsze ramy decyzji niż prosty wybór między „zostawić” i „przepisać”.

Dobry wybór opiera się na czterech osiach. To czas do efektu, ryzyko operacyjne, koszt błędnej decyzji i poziom kontroli nad kodem, a raport DORA z 2024 roku nadal pokazuje, że szybkość i stabilność trzeba oceniać razem.

No dobra, o co w tym chodzi. Nie wybierasz między modnym hasłem a modnym hasłem. Wybierasz między scenariuszami, które dają różny poziom kontroli, różne tempo zmian i różny koszt pomyłki.
To jest sedno decyzji o takeoverze, modułowej modernizacji i selective rewrite. Ten punkt rozwiązuje problem klienta, który chce rozwijać produkt bez chaosu.

Czas do efektu mówi, jak szybko zobaczysz poprawę. Ryzyko operacyjne mówi, ile szkody robi jedna błędna zmiana. Koszt błędnej decyzji mówi, ile zapłacisz za zły kierunek po 3 albo 6 miesiącach. Kontrola nad kodem mówi, czy w razie zmiany partnera nadal zachowasz wpływ na produkt.
W praktyce takeover albo modularną modernizację łatwiej poukładać z partnerem, który działa jako polski Software House i rozumie jednocześnie produkt, architekturę i ograniczenia delivery.

• Jeśli releasy psują produkcję, wybór pada na recovery sprint, bo bez obniżenia change failure rate i skrócenia time to restore dalszy rozwój zwiększa chaos.

• Jeśli problem siedzi w capacity, wybór pada na wsparcie obecnego zespołu, bo architektura nie jest wtedy głównym blokiem.

• Jeśli wiedza siedzi u obecnego vendora, wybór pada na discovery dla takeoveru, bo przejęcie bez dokumentacji zwiększa koszt błędu.

• Jeśli jeden obszar blokuje całość, wybór pada na selective rewrite, bo przebudowa całej platformy zwiększa zakres bez zysku.

• Jeśli roadmapa ma iść dalej bez przerwy, wybór pada na modułową modernizację, bo ogranicza wpływ na bieżące delivery.

• Jeśli zespół boi się lock-in, wybór pada na modularność, ownership i dokumentację, bo to obniża koszt zmiany partnera.

• Jeśli część funkcji jest powtarzalna, wybór pada na gotowe moduły plus custom development, bo skraca time to value.

Open source LMS nie oznacza utraty skali. Jedna z największych platform open source deklaruje ponad 70 tysięcy kursów i ponad 140 milionów uczących się. Prawdziwe pytanie brzmi nie „czy open source skaluje”, tylko „czy masz ownership, dokumentację i proces zmian”. Ten zestaw czynników wpływa na koszt zmiany partnera bardziej niż sama licencja.
To jest ważne przy vendor lock in, bo brak dokumentacji zamyka ruch nawet wtedy, gdy kod formalnie należy do klienta.

Najlepszy start jest mały i kontrolowany. Audyt, recovery sprint albo discovery pod takeover daje szybki obraz ryzyka i nie blokuje całej roadmapy. Duży projekt startowy podbija koszt błędnej decyzji już w pierwszym kroku. To jest prostsze do obrony biznesowo i prostsze do rozliczenia.

O kierunku modernizacji w EdTech i HRTech decydują standardy, integracje, dostępność i bezpieczeństwo. Dokument ADL wyjaśnia, że xAPI zapisuje zdarzenia do LRS i nie wymaga uruchamiania learningu wyłącznie z LMS, a standard LTI służy do bezpiecznego łączenia narzędzi z środowiskiem nauki.

Najprostsza wersja wygląda tak. SCORM to kurs uruchamiany w LMS.
xAPI to zapis zdarzeń także poza LMS. LTI to bezpieczna integracja narzędzia z platformą. Te trzy pojęcia porządkują decyzję o architekturze bardziej niż sam wiek kodu.

Drugi blok ryzyka dotyczy compliance. WCAG 2.2 jest aktualną rekomendacją W3C dla dostępności treści webowych. GDPR obowiązuje od 25 maja 2018 roku i reguluje przetwarzanie danych osobowych w UE. To nie są dodatki na później, tylko warunki architektury i wdrożenia. W platformie learningowej wpływa to na projekt interfejsu, sposób logowania, raportowanie i przechowywanie danych.

Trzeci blok ryzyka dotyczy bezpieczeństwa. OWASP Top 10 porządkuje najważniejsze kategorie ryzyk dla aplikacji webowych. W praktyce daje to prostą listę kontroli dla logowania, sesji, danych wejściowych i uprawnień.
Bezpieczeństwo aplikacji webowej wpływa na koszt modernizacji tak samo jak dług technologiczny. Jeśli platforma ma ważny komponent mobile learning, decyzje o architekturze i integracjach warto zestawić także z tym, jak wygląda projektowanie aplikacji mobilnych w całym ekosystemie produktu.

Czwarty blok dotyczy lock in. Lock in rośnie wtedy, gdy dokumentacja jest słaba, ownership jest niejasny i integracje zna tylko jeden dostawca. Dobra wiadomość jest taka, że ten obszar da się uporządkować przez discovery, handover, mapę integracji i jasny podział odpowiedzialności. Najmniejszy bezpieczny start to audyt, recovery sprint albo discovery pod takeover. Taki krok porządkuje standardy, ryzyka i zakres bez wchodzenia od razu w szeroki projekt.

FAQ

Czy każda platforma EdTech/HRTech potrzebuje SCORM?

Nie. SCORM pasuje do kursu uruchamianego w LMS, ale xAPI daje szerszy model danych i zapisuje zdarzenia do LRS także poza LMS. Jeśli produkt śledzi aktywność w aplikacji mobilnej, social flow albo symulacji, sam SCORM nie pokrywa całego obrazu. Punkt wyjścia to model uczenia i model raportowania, nie nazwa standardu.

Kiedy takeover ma sens? 

Takeover ma sens wtedy, gdy produkt ma wartość, ale obecny vendor, słaba dokumentacja albo chaos ownershipu blokują rozwój. W takim układzie discovery i handover porządkują wiedzę szybciej niż kolejna runda zmian w tym samym modelu współpracy. Największe ryzyko dotyczy utraty wiedzy o integracjach i logice produktu.

Kiedy rewrite naprawdę ma sens? 

Rewrite ma sens wtedy, gdy model domenowy albo architektura blokują cele produktu wprost. Przykładem jest sytuacja, w której jeden monolit zatrzymuje skalowanie, rozdział uprawnień albo integracje krytyczne dla sprzedaży. Jeśli problem siedzi w delivery albo dokumentacji, rewrite tylko podnosi koszt błędnej decyzji.

Czy open source oznacza większe ryzyko? 

Nie. Jedna z największych platform open source deklaruje ponad 70 tysięcy kursów i ponad 140 milionów uczących się. Ryzyko nie siedzi w samej licencji. Ryzyko siedzi w ownershipie, dokumentacji i jakości procesu zmian.

Co najbardziej zwiększa ryzyko lock-in? 

Najbardziej zwiększa je brak dokumentacji, zamknięty stack, niejasny ownership i architektura znana tylko jednemu dostawcy. Taki układ zwiększa koszt zmiany partnera nawet wtedy, gdy kod formalnie należy do klienta. Discovery i mapa integracji obniżają to ryzyko na starcie.

Od czego zacząć, jeśli nie chcesz przepalić budżetu? 

Zacznij od małego i kontrolowanego zakresu. Audyt, recovery sprint albo discovery pod takeover dają lepszy punkt startu niż duży projekt od razu. Taki ruch daje szybki obraz ryzyka, wpływu na roadmapę i potrzebnego poziomu zmian. Dopiero potem widać, czy sens daje wsparcie zespołu, takeover, modułowa modernizacja albo selective rewrite.