Power Apps
Citizen Developer i Pro Developer różnice, które naprawdę mają znaczenie

W ekosystemie Power Platform podział na Citizen Developera i Pro Developera pojawia się często. I dobrze, pod warunkiem, że rozumiemy, że to nie jest podział na „lepszego” i „gorszego” twórcę rozwiązań. To dwie różne role odpowiadające na inne potrzeby biznesowe. Ja sam uwielbiam pracę z Citizenami! To oni zwracają moją uwagę na kwestie, które technicznie są bez zarzutu, ale biznesowo mogą spowodować trudności dla użytkowników końcowych. Problem pojawia się również wtedy, gdy próbujemy budować rozwiązania klasy enterprise w podejściu citizen development albo gdy od prostych automatyzacji oczekujemy procesu jak w software house. Wtedy szybko pojawia się frustracja, chaos i pytanie: „dlaczego to przestało działać?”

Kim jest Citizen Developer?

Citizen Developer to najczęściej osoba z biznesu lub blisko biznesu, która dobrze rozumie proces i chce go usprawnić bez angażowania dużego zespołu IT. Korzysta z narzędzi low-code/no-code (jak Power Apps czy Power Automate), więc nie potrzebuje głębokiej wiedzy programistycznej, żeby dostarczyć działające rozwiązanie. W praktyce to ktoś, kto zna realny problem użytkowników, potrafi szybko zbudować prostą aplikację lub automatyzację, działa blisko operacji i reaguje niemal od razu na potrzeby. Przede wszystkim skupia się na efekcie biznesowym.

To ogromna siła Power Apps. Nie każda potrzeba wymaga pełnego projektu, architektury i kilkutygodniowego backlogu. Czasem wystarczy dobrze zrobiona aplikacja do zgłoszeń, prosty obieg akceptacji albo formularz zastępujący Excela wysyłanego mailem. I właśnie tutaj Citizen Developer potrafi szybko dostarczyć wartość.

Jak może wyglądać typowe rozwiązanie citizen developera? Prosty filtr galerii w Canvas App oparty na SharePoint:

POWERFX
// Filtr galerii – proste podejście Citizen Developera 
// Profil użytkownika pobieramy z konektora Office 365 Users, 
// ponieważ funkcja User() nie udostępnia właściwości Department. 

Filter(
     Lista_Zgłoszeń;
     Status.Value = "Nowe" &&
     Dział.Value = Office365Users.MyProfileV2().department )

Ten kod zadziała świetnie na liście z kilkudziesięcioma rekordami i, dopóki warunki pozostają delegowalne, poradzi sobie także z większą. Problem pojawia się wtedy, gdy do filtra trafi warunek, którego nie da się delegować: Power Apps pobiera wówczas tylko 500 rekordów i filtruje je lokalnie (limit można podnieść do 2000 w ustawieniach aplikacji, ale nie wyżej – MS Learn). To oddzielna kwestia od progu widoku listy SharePoint, który wynosi 5000 elementów. Efekt jest ten sam: powyżej limitu galeria pokazuje niepełne dane, często bez wyraźnego błędu. O tym, jak to rozwiązać, za chwilę.

Kim jest Pro Developer w Power Platform?

Pro Developer patrzy na Power Apps z innej perspektywy. Nie tylko pyta „czy to działa?”, ale też: czy to będzie skalowalne, bezpieczne, utrzymywalne za pół roku, a wdrożenie na produkcję – powtarzalne. Zastanawia się, co się stanie, gdy aplikacja zacznie korzystać z wielu źródeł danych i integracji, jak ograniczyć ryzyko błędów i dług techniczny.

Pro Developer wnosi do Power Platform to samo, co do klasycznego developmentu: architekturę, standardy, testowalność, ALM, governance i przewidywalność. Pracuje z Dataverse, rozwiązaniami managed, connection references i environment variables, pipeline’ami, integracjami z Azure, custom connectorami i zaawansowanym modelem bezpieczeństwa. W praktyce oznacza to konkretne narzędzia: Power Platform Pipelines do powtarzalnych wdrożeń DEV → TEST → PROD, Managed Environments do kontroli nad tym, co i gdzie trafia, a po stronie governance często CoE Starter Kit – dający wgląd w to, ile aplikacji naprawdę żyje w organizacji i kto za nie odpowiada.

Wróćmy do naszego przykładu z filtrem. Pro developer podejdzie do tego inaczej –użyje Dataverse zamiast SharePoint i zadba o delegację:

POWERFX
// Pro developer: delegowalny filtr z Dataverse
// Dane profilu i rekord działu ustalamy przed głównym filtrem.
// Dzięki temu Filter() porównuje kolumny z gotową wartością,
// zamiast wykonywać dodatkowe wyszukiwanie dla każdego rekordu.

With(
    { _dzialNazwa: Office365Users.MyProfileV2().department };
    With(
        {
            _dzial: LookUp(
                'Jednostki biznesowe';
                'Nazwa jednostki' = _dzialNazwa
            )
        };
        SortByColumns(
            Filter(
                Zgłoszenia;
                Status = 'Status (Zgłoszenia)'.Nowe
                && Dział = _dzial
            );
            "createdon";
            SortOrder.Descending
        )
    )
)

Różnica? Główny filtr może zostać wykonany po stronie Dataverse, zanim dane trafią do aplikacji. Limit 500/2000 rekordów nie ogranicza wyniku w pełni delegowalnego zapytania, ale wystarczy jeden niedelegowalny warunek, aby problem wrócił. Dataverse nie ma sztywnego progu liczby rekordów odpowiadającego limitowi widoku listy SharePoint; realne ograniczenia wynikają m.in. z pojemności, projektu modelu danych, selektywności filtrów i sposobu budowy ekranu (MS Learn). Przy dziesiątkach tysięcy rekordów aplikacja może nadal działać sprawnie, o ile zapytania są delegowalne i nie pobierają nadmiaru danych. Zwróć też uwagę na With(): pro developer świadomie rozdziela wartości wyliczane po stronie klienta od zapytania delegowanego do serwera.

Porównanie ról: kiedy co ma sens?

Poniższa tabela pokazuje kluczowe różnice w podejściu obu ról. Nie chodzi o to, że jedno jest lepsze – chodzi o dopasowanie do kontekstu:

Najważniejsza różnica: cel działania

To, co najbardziej odróżnia obie role, to nie poziom inteligencji czy „techniczności”. Największa różnica leży w celu. Citizen Developer myśli: „Jak najszybciej usprawnić konkretny proces?”, natomiast Pro Developer: „Jak zaprojektować rozwiązanie, które będzie działało stabilnie, bezpiecznie i rozwojowo?”.Obie perspektywy są potrzebne. Jedna daje szybkość, druga – trwałość.

Gdzie Citizen Developer sprawdza się najlepiej?

Citizen development ma ogromny sens tam, gdzie proces jest lokalny dla jednego działu, ryzyko biznesowe jest niewielkie, dane nie są szczególnie wrażliwe, a aplikacja nie wymaga skomplikowanych integracji. Typowe przykłady to aplikacja do rejestracji prostych zgłoszeń, lista zadań dla zespołu, prosty proces akceptacyjny czy wewnętrzny formularz zamiast Excela.

W takich scenariuszach budowanie ciężkiej architektury od początku po prostu nie ma sensu. Biznes chce efektu szybko – i słusznie.

Gdzie zaczyna się potrzeba Pro Developera?

Są momenty, w których „prosta aplikacja” przestaje być prosta. Najczęściej dzieje się to, gdy pojawiają się krytyczne procesy biznesowe, większa liczba użytkowników, rozbudowane uprawnienia, wiele środowisk (DEV/TEST/PROD), integracje z innymi systemami, wymagania audytowe lub compliance.

I właśnie wtedy wchodzi Pro Developer. Bo problemem nie jest zbudowanie aplikacji, tylko to, żeby działała ona po 3, 6 i 12 miesiącach – kiedy biznes będzie chciał wprowadzać kolejne funkcje, kolejnych użytkowników i robić kolejne integracje.

Dobrym przykładem jest obsługa błędów. Citizen developer zwykle zostawia domyślne komunikaty Power Apps. Pro developer zbuduje structured error handling:

POWERFX
// Obsługa błędów przy zapisie - podejście Pro Developera
// Uwaga: separator listy to ';', łańcuch instrukcji to ';;' (lokalizacja PL)
// FirstError.Message daje użytkownikowi realny kontekst błędu,
// a nie tylko ogólne „coś poszło nie tak"
IfError(
    Patch(Zgłoszenia; Defaults(Zgłoszenia); {
        Tytuł: txtTytuł.Text;
        Opis: txtOpis.Text;
        Priorytet: drpPriorytet.Selected // dopasuj do typu kolumny (Choice: wartość opcji)
    });
    // Błąd - komunikat z kontekstem
    Notify(
        "Nie udało się zapisać zgłoszenia: " & FirstError.Message;
        NotificationType.Error
    );
    // Sukces - blok instrukcji jako jedno wyrażenie (łańcuch ';;')
    Navigate(EkranPotwierdzenia; ScreenTransition.Fade);;
    Reset(txtTytuł);;
    Reset(txtOpis)
)

Najczęstszy błąd: mylenie prototypu z rozwiązaniem produkcyjnym

To najważniejszy punkt całej dyskusji. Power Apps świetnie nadaje się do szybkiego prototypowania, tylko że prototyp i rozwiązanie produkcyjne to nie jest to samo. To, że coś działa na jednym ekranie, dla kilku użytkowników i na danych z SharePointa, nie oznacza jeszcze, że będzie dobrze skalować, nie pojawią się problemy z delegacją, logika będzie czytelna za kilka miesięcy, ktoś inny będzie w stanie to rozwijać, a wdrożenie na produkcję nie zepsuje połowy zależności.

Firmy regularnie wpadają w tę samą pułapkę: najpierw powstaje „mała aplikacja na szybko”, a po czasie okazuje się, że korzysta z niej pół firmy i nikt nie chce brać odpowiedzialności za jej dalszy rozwój. Problem nie leży tu w samym Power Apps, tylko w braku rozróżnienia między rolami Citizen Developera i Pro Developera.

Checklista: czy Twoje rozwiązanie wymaga już wsparcia Pro Developera?

Jeśli Twoje rozwiązanie spełnia 3 lub więcej z poniższych warunków, czas pomyśleć o profesjonalnym podejściu:

1. Korzysta z niego więcej niż jeden dział lub zespół.
2. Przetwarza dane osobowe, finansowe lub objęte regulacjami.
3. Ma więcej niż 3 źródła danych.
4. Wymaga różnych poziomów uprawnień dla różnych grup użytkowników.
5. Jest rozwijane przez więcej niż jedną osobę.
6. Nie ma udokumentowanej logiki biznesowej.
7. Wdrożenie polega na „wyeksportowaniu i zaimportowaniu” solution ręcznie.
8. Awaria tej aplikacji blokuje realny proces biznesowy.

Citizen Developer i Pro Developer nie są konkurencją

Te role nie powinny ze sobą walczyć, tylko współpracować. Najlepszy model w organizacji wygląda zwykle tak: Citizen Developer wnosi znajomość procesu, szybkość działania i bliskość biznesu, a Pro Developer – jakość techniczną, bezpieczeństwo i zdolność skalowania rozwiązania.

W praktyce może to wyglądać bardzo zdrowo:

1. Biznes lub Citizen Developer tworzy prototyp.
2. Rozwiązanie pokazuje realną wartość.
3. Pro Developer pomaga je uporządkować, przebudować lub przygotować do wersji produkcyjnej.
4. Organizacja zyskuje i szybkość, i jakość.

To dużo dojrzalsze podejście niż próba udowadniania, że jedna strona „powinna robić wszystko”. A dojrzałą organizację odróżnia właśnie to, że wie, kiedy wystarczy citizen development, a kiedy potrzebny jest profesjonalny proces wytwórczy. Jeśli firma tego nie rozróżnia, pojawiają się przewidywalne symptomy: rozwiązania bez właściciela, brak standardów, problemy z bezpieczeństwem, trudne wdrożenia i chaos przy dalszym rozwoju.

Podsumowanie

Citizen Developer i Pro Developer to dwa filary ekosystemu Power Platform. Citizen Developer przyspiesza zmiany i szybko odpowiada na potrzeby biznesu. Pro Developer sprawia, że rozwiązania są trwałe, bezpieczne i gotowe na rozwój.

Prawdziwa dojrzałość nie polega na wybraniu jednej strony. Polega na tym, żeby dobrze rozpoznać, kiedy potrzebujemy szybkości, a kiedy architektury. Bo w Power Apps nie chodzi tylko o to, żeby coś zbudować. Celem jest zbudowanie tego na właściwym poziomie dojrzałości.