Architektura PWA dla projektów remontowych: czat, role, AI | Przegląd IT

# Architektura PWA do zarządzania projektami remontowymi: od czatu do narzędzi AI

W branży budowlanej zarządzanie projektami remontów mieszkań wymaga specjalistycznych narzędzi, uwzględniających długotrwałość procesu i liczne grono uczestników. Opracowaliśmy rozwiązanie PWA, integrujące czat, tracker zadań, wideonadzór i projektanta wnętrz opartego na AI. W tym artykule omówimy rozwiązania architektoniczne i techniczne trudności, które napotkaliśmy podczas tworzenia systemu do zarządzania projektami trwającymi od 6 do 18 miesięcy.

Dlaczego standardowe CRM nie sprawdzają się w remontach

Projekt remontowo-budowlany to nie transakcja ani ticket. To proces trwający od pół roku do półtora roku, w którym biorą udział różne role o odmiennych potrzebach:

• Zamawiający — chce widzieć postępy, ale nie wgłębiać się w szczegóły.
• Kosztorysant — formalizuje życzenia i oblicza zakres prac oraz materiałów.
• Menedżer — koordynuje wszystkie aspekty projektu.
• Kierownik — musi widzieć ogólny obraz wszystkich obiektów bez wnikania w szczegóły każdego.
• Kontrola techniczna — przyjmuje prace od majstrów.
• Majstrowie (tynkarze, elektrycy, hydraulicy) — pracują kolejno.
• Dział zaopatrzenia — kupuje i dostarcza materiały.

Gotowe rozwiązania typu Bitrix24 czy amoCRM są zorientowane na leje sprzedaży, a nie na zarządzanie projektami budowlanymi. Trello i Asana nadają się do zadań, ale nie oferują kosztorysów, list kontrolnych z dokumentacją zdjęciową ani kontroli finansowej. Na rynku rosyjskim nie istniały specjalistyczne rozwiązania do remontów mieszkań, integrujące wszystkie niezbędne narzędzia.

Wybór stosu technologicznego: PWA i Laravel

Podstawowe wymaganie — jedna aplikacja dla wszystkich: od kierownika po majstra-tynkarskiego. Majstrowie korzystają ze smartfonów Android różnych generacji, zamawiający często z iPhone'ów, menedżerowie z desktopów. Trzy natywne aplikacje (iOS, Android, web) byłyby nieopłacalne dla naszego zespołu. PWA rozwiązała problem: jedna baza kodu, instalacja na pulpicie, powiadomienia push, automatyczne aktualizacje.

Backend zrealizowany w PHP Laravel, frontend — szablon AdminLTE dostosowany do naszych potrzeb. Architektura to monolit z jednolitą autoryzacją i oddzielnymi panelami dla pracownika, majstra i zamawiającego. Laravel wybrany ze względu na popularność i dostępność gotowych pakietów do większości zadań. Na przykład wysyłka powiadomień do MAX jako oddzielny pakiet, podobnie jak laravel notification channels.

Infrastruktura: wirtualny serwer reg.ru w Moskwie, magazyn danych na serwerze FirstVDS. Kopie zapasowe na trzech różnych serwerach u różnych dostawców hostingu. Deployment przez skrypt CI/CD w kilka sekund dzięki brakowi kompilacji frontendu, co umożliwia szybką publikację aktualizacji.

Architektura ról i praw dostępu

System obejmuje cztery typy paneli z różnymi interfejsami:

Panel zamawiającego

Minimalistyczny interfejs z transmisją wideo, czatem „jednego okna”, raportami zdjęciowymi, kosztorysem i planem prac. Dostęp do narzędzi AI: ekspert od remontów i projektant wnętrz (wgranie zdjęć sprzed remontu i uzyskanie renderów). Zamawiający nie widzi wewnętrznej korespondencji ani kosztów własnych.

Panel pracownika

Dostęp do wewnętrznego systemu zgodnie z nadanymi uprawnieniami: korespondencja z zamawiającymi, podsumowanie obiektów, zarządzanie wydatkami, praca z majstrami, listy kontrolne, kosztorysy, analityka.

Panel majstra

Tylko obiekty, przy których majster pracuje. Osobisty plan prac z odliczaniem czasu, czat z firmą, listy kontrolne z instrukcjami wideo, kosztorys (bez cen dla zamawiającego), wnioski o materiały i płatności.

Panel kierownika

Dashboard całej firmy. Obejmuje funkcje pracownika plus:

• Kontrola komunikacji z zamawiającymi w czasie rzeczywistym.
• Obraz finansowy: przychody, wydatki, luki kasowe.
• Zarządzanie rotacjami brygad w celu minimalizacji przestojów.
• Selektywna kontrola jakości poprzez listy kontrolne.
• Natychmiastowe wdrażanie usprawnień (dodawanie punktów do list kontrolnych).
• Prognoza popytu na podstawie statystyk kosztów.

Technicznie zaimplementowano trzy interfejsy: zamawiającego, majstra i pracownika. Panel kierownika to panel pracownika z pełnymi uprawnieniami. Uprawnienia konfiguruje się indywidualnie, dostępne są predefiniowane „stanowiska” (zestawy uprawnień).

Czat jako „jedno okno”: routowanie wiadomości

Kluczowe zadanie — czat, w którym zamawiający komunikuje się z „firmą”, a nie z konkretną osobą. Wewnątrz firmy wiadomość widzą wszyscy uczestnicy projektu.

Zasada działania:

• Zamawiający pisze w czat — wiadomość pojawia się u wszystkich pracowników przypisanych do obiektu.
• Dowolny pracownik odpowiada — zamawiający widzi odpowiedź od „firmy” z podaniem autora.
• Dla zamawiającego czat wygląda jak prywatna korespondencja, dla pracowników — jak ogólny czat projektu.
• Analogicznie zaimplementowany czat z majstrem.
• Możliwość przekazywania wiadomości między zamawiającym a majstrem.
• W czacie z zamawiającym dozwolone tylko wiadomości tekstowe (dla celów dokumentacyjnych), w czacie z majstrem — głosowe (dla przekazania intonacji).

Czat działa na websockets. Powiadomienia o nowych wiadomościach wysyłane z 5-sekundowym opóźnieniem, aby uniknąć wysyłki, jeśli wiadomość już przeczytana. Powiadomienia push zawierają przyciski „Przeczytaj” i „Odpowiedz”. Na niektórych urządzeniach Android problem: po naciśnięciu przycisku szuflada powiadomień się zamyka, co przeszkadza w pracy.

Trudności i rozwiązania

Jedną z nieoczekiwanych trudności okazała się obsługa wielu obiektów u jednego zamawiającego. Musieliśmy zaimplementować powiązanie kont. W przyszłych wersjach konta, profile i obiekty będą rozdzielone od początku.

Problem z powiadomieniami push na Androidzie (zamykanie szuflady po naciśnięciu przycisku) pozostaje nierozwiązany. Początkowo nie uwzględniono też potrzeby natychmiastowego wdrażania zmian w listach kontrolnych, ale teraz jest to kluczowe dla kontroli jakości.

Co ważne

• Specyfika branży — projekt remontowy wymaga uwzględnienia wielu ról i długiego horyzontu czasowego, czego nie zapewniają standardowe CRM.
• PWA jako optymalne rozwiązanie — jedna baza kodu dla wszystkich platform sprawdza się, mimo drobnych problemów (np. z powiadomieniami push na Androidzie).
• Elastyczny system ról — wyraźne rozdzielenie interfejsów i praw dostępu jest kluczowe dla akceptacji systemu przez uczestników projektu.
• Czat jako centrum komunikacji — routowanie wiadomości „jednego okna” upraszcza interakcje i dokumentuje korespondencję.
• Rezerwowanie i niezawodność — potrójne kopie zapasowe na różnych serwerach uratowały dane podczas awarii magazynu.

— Editorial Team