WIKI PANKA

PANKA — polska firma R&D w lotnictwie. Zajmujemy się certyfikacją lotniczą oraz technologiami dla integracji bezzałogowców i eVTOL w przestrzeni powietrznej. Nasze filary:

Nasze filary

Jak pracujemy

Pracujemy w modelu AI-native: narzędzia AI wspierają research, dokumentację i automatyzacje, a decyzje zawsze podejmują ludzie. Część zespołu pracuje na niepełny etat — liczy się efekt, nie obecność na zegarku.

PANKA is a Polish R&D company in aviation. We work on aviation certification and technologies for integrating unmanned aircraft and eVTOL into the airspace. Our pillars:

Our pillars

How we work

We work in an AI-native model: AI tools support research, documentation and automation, while decisions are always made by people. Part of the team works part-time — results matter, not clock-watching.

Kto jest kto — w razie pytań pisz śmiało.

Aktualną strukturę i dane kadrowe znajdziesz też w HR PANKA.

Who is who — don't hesitate to reach out.

You can also find the current structure and HR data in HR PANKA.

Nasz główny projekt badawczo-rozwojowy — co musisz wiedzieć na co dzień.

PANKA DSS — System synchronizacji i zarządzania konfliktami UTM/ATM. Projekt realizujemy w konsorcjum z Politechniką Warszawską, w okresie 09.2026 – 2028, dofinansowany ze środków publicznych (NCBiR). To projekt B+R: budujemy i badamy technologię, a efekty muszą być udokumentowane.

Zadania — jak je rozumieć w timesheetach

Zasady współpracy przy projekcie

• Decyzje projektowe zapisujemy (notatka / komunikat na Slack), nie „ustnie na kawie".
• Istotne zmiany w zakresie prac — konsultuj z Joanną przed rozpoczęciem.
• Dokumentacja techniczna żyje w repozytorium i na Drive, nie na prywatnych dyskach.

Our main R&D project — what you need to know day to day.

PANKA DSS — a system for UTM/ATM conflict synchronisation and management. We run the project in a consortium with Warsaw University of Technology, in the period 09.2026 – 2028, co-funded from public funds (NCBiR). It is an R&D project: we build and research the technology, and the results must be documented.

Tasks — how to understand them in timesheets

Project collaboration rules

• Record project decisions (a note / a Slack message), never "verbally over coffee".
• Consult significant scope changes with Joanna before starting.
• Technical documentation lives in the repository and on Drive, never on private disks.

Jak brać rachunek, żeby wszystko dało się rozliczyć — instrukcja krok po kroku.

Gdy kupujesz coś firmowego

1. Poproś o fakturę na firmę — nie paragon na osobę prywatną. Poproś sprzedawcę o „fakturę VAT na PANKA". Dane firmy do faktury znajdziesz na Drive w folderze PANKA Company (lub u Weroniki).
2. Sprawdź, czy na dokumencie jest: data zakupu, dane sprzedawcy, NIP nabywcy (nasza firma), opis co kupiono i kwota. Nieakceptowalne: „usługa", „towar" bez konkretów.
3. Przy zakupach do projektu w opisie lub uwagach powinno być widać związek z projektem FENG-DSS (np. nazwa narzędzia lub urządzenia używanego w projekcie). Nie wiesz jak opisać — zapytaj Weronikę przed wystawieniem faktury.
4. Prześlij dokument (skan / PDF / zdjęcie czytelnego paragonu) na qm@panka.pl i do Weroniki — tego samego dnia, nie odkładaj na koniec miesiąca.

Na co uważać

• Paragon bez danych firmy często nie nadaje się do rozliczeń — dlatego zawsze najpierw „fakturę na firmę".
• Subskrypcje i narzędzia IT (usługi chmurowe, licencje) — zgłoś przed zakupem. Konto firmowe = firma płaci i dostaje fakturę; nigdy nie kupuj subskrypcji na prywatną kartę bez ustalenia zwrotu.
• Nie płać z własnej kieszeni bez wcześniejszej zgody — jeśli już się zdarzyło, dostarcz rachunek i zgłoś do Pawła.
• Zwroty i reklamacje — zachowaj dokument zakupu; bez niego nie mamy podstaw.

How to handle a receipt so everything can be settled — step by step.

When buying something for the company

1. Ask for a company invoice — not a private receipt. Ask the seller for "a VAT invoice for PANKA". You will find the company invoice details on Drive in the PANKA Company folder (or ask Weronika).
2. Check that the document shows: purchase date, seller details, the buyer's VAT ID (our company), a description of what was bought and the amount. Not acceptable: "service" or "goods" without specifics.
3. For project purchases, the description or notes should show the link to the FENG-DSS project (e.g. the name of a tool or device used in the project). Unsure how to phrase it — ask Weronika before the invoice is issued.
4. Send the document (scan / PDF / a photo of a legible receipt) to qm@panka.pl and to Weronika — the same day, don't leave it for the end of the month.

Watch out for

• A receipt without company details often cannot be settled — that is why you always ask for "a company invoice" first.
• Subscriptions and IT tools (cloud services, licences) — report before buying. A company account = the company pays and gets the invoice; never buy a subscription on a private card without agreeing on reimbursement.
• Don't pay from your own pocket without prior approval — if it already happened, deliver the receipt and report it to Paweł.
• Returns and complaints — keep the purchase document; without it we have no basis.

Raportujemy godziny co miesiąc — to zajmuje 3 minuty.

• Formularz: hr.panka.pl/czas-pracy (logowanie kontem HR).
• Wpisujesz godziny dla każdego dnia miesiąca i przypisujesz zadanie (Z1 / Z3 / Z-ADM / Z-STAZ) plus krótki opis wykonanych prac.
• Termin: do 5. dnia roboczego miesiąca za miesiąc poprzedni.
• Osoby pracujące przy projekcie wpisują prace w Z1/Z3; czas administracyjny — Z-ADM; staż — Z-STAZ.

We report hours monthly — it takes 3 minutes.

• Form: hr.panka.pl/czas-pracy (log in with your HR account).
• You enter hours for each day of the month and assign a task (Z1 / Z3 / Z-ADM / Z-STAZ) plus a short description of the work done.
• Deadline: by the 5th business day of the month for the previous month.
• People working on the project book to Z1/Z3; administrative time — Z-ADM; internship — Z-STAZ.

Gdzie jest co robione i kto pomaga.

Dostęp do systemów firmowych przyznaje Paweł. Konta firmowe (@panka.pl) są do użytku służbowego — prywatne sprawy zostawiamy poza nimi.

Tips & tricks — Trello

• Zadanie z e-maila: każda tablica w Trello ma własny adres e-mail (Menu tablicy → Więcej → Email-to-board). Wyślij maila na ten adres, a powstanie karta: temat = tytuł karty, treść = opis, załączniki trafią do karty. W ustawieniach ustal listę i pozycję, na które trafiają karty z maila, oraz automatycznie dodawanych członków.
• Adres tablicy dodaj do kontaktów jako „Trello – Zadania" — potem tworzenie zadania to zwykły mail, nawet z telefonu.
• Karta ze Slacka: po podłączeniu aplikacji Trello do Slacka (Slack → Apps → Trello) w menu wiadomości (⋯) pojawia się opcja Create card — zamienia wiadomość w kartę na tablicy.
• Pola karty: opis, lista kontrolna, termin, etykiety i załączniki — używaj list kontrolnych do zadań wieloetapowych.

Tips & tricks — Slack

• Przypomnienia: `/remind mnie "prześlij timesheet" in 3 days` albo `/remind @Michał "deploy" at 4pm`.
• Szybkie skakanie: Ctrl+K (Cmd+K) — wyszukiwanie kanałów i osób.
• Wątki (Reply in thread): odpowiadaj w wątku, żeby kanał nie zamienił się w jeden wielki strumień.
• Zaplanowane wysyłanie: przy przycisku Send jest zegar — możesz napisać wieczorem, a wiadomość pójdzie rano.
• Status: `/status 🌴 urlop` — zespół widzi, że Cię nie ma.
• Długie treści: potrójny backtick ``` tworzy blok kodu — świetne do logów i fragmentów konfiguracji.

Tips & tricks — Gmail

• Zadanie do Trello prosto ze skrzynki: po prostu wyślij (lub przekaż dalej) maila na adres tablicy Trello — patrz wyżej.
• Etykiety i filtry: np. automatycznie oznaczaj maile od biura rachunkowego lub z fakturami — łatwiej je potem znaleźć.
• Alias z plusem: imie+plyty@panka.pl przy rejestracjach — pozwala sprawdzić, kto rozsyła Twój adres.

Tips & tricks — Google Drive

• Historia wersji pliku: prawy przycisk → Historia wersji — wrócisz do wcześniejszej wersji bez „final_v3_naprawde.xlsx".
• Skróty zamiast kopiowania: Dodaj skrót do Drive — jeden plik w wielu folderach, bez rozjeżdżających się kopii.
• Udostępnianie: danych wrażliwych nie udostępniaj „każdemu z linkiem" — tylko konkretne osoby lub organizacja.

Where things are done and who helps.

Access to company systems is granted by Paweł. Company accounts (@panka.pl) are for work purposes — keep private matters out of them.

Tips & tricks — Trello

• Task by e-mail: every Trello board has its own e-mail address (Board menu → More → Email-to-board). Send a mail to that address and a card is created: subject = card title, body = description, attachments land on the card. In the settings choose the list and position where e-mailed cards go, and members added automatically.
• Save the board address as a contact named "Trello – Tasks" — creating a task becomes just sending an e-mail, even from your phone.
• Card from Slack: once the Trello app is connected to Slack (Slack → Apps → Trello), the message menu (⋯) shows Create card — it turns a message into a board card.
• Card fields: description, checklist, due date, labels and attachments — use checklists for multi-step tasks.

Tips & tricks — Slack

• Reminders: `/remind me "submit timesheet" in 3 days` or `/remind @Michał "deploy" at 4pm`.
• Quick jump: Ctrl+K (Cmd+K) — search channels and people.
• Threads (Reply in thread): reply in a thread so the channel doesn't become one endless stream.
• Scheduled send: there is a clock icon by the Send button — write in the evening, deliver in the morning.
• Status: `/status 🌴 vacation` — the team knows you're away.
• Long content: triple backtick ``` makes a code block — perfect for logs and config snippets.

Tips & tricks — Gmail

• Task to Trello straight from your inbox: just send (or forward) a mail to the Trello board address — see above.
• Labels and filters: e.g. automatically tag mail from the accounting office or with invoices — much easier to find later.
• Plus alias: name+flyers@panka.pl when registering — lets you check who is spreading your address.

Tips & tricks — Google Drive

• File version history: right click → Version history — restore an earlier version instead of "final_v3_really.xlsx".
• Shortcuts instead of copies: Add shortcut to Drive — one file in many folders, no diverging copies.
• Sharing: never share sensitive data with "anyone with the link" — only specific people or the organisation.

Checklista dla nowej osoby — od pierwszego maila po pierwszy timesheet.

• ☐ Konto firmowe @panka.pl + Google Workspace — konfiguruje Weronika
• ☐ Konto w HR PANKA (hr.panka.pl) — zaproszenie przychodzi mailem; ustal hasło i się zaloguj
• ☐ Formularz danych pracownika — link przychodzi od Weroniki (indywidualny, jednorazowy). Wypełnij: dane osobowe, adresy, numer konta do wypłaty, wykształcenie. Nie odkładaj — bez tego nie zamkniemy formalności kadrowych.
• ☐ Slack — zaproszenie na firmowy adres; 2FA jest obowiązkowe (włącz przy pierwszym logowaniu)
• ☐ Google Drive — poproś o dostęp do folderów zespołu
• ☐ Trello — poproś o dostęp do tablicy projektu
• ☐ Przeczytaj tę Wiki — zwłaszcza sekcje „Projekt FENG-DSS", „Zakupy i rachunki", „Czas pracy"
• ☐ Umowa i formalności — podpisuje Weronika/Paweł; pytania kadrowe → Weronika
• ☐ Pierwszy timesheet — za pierwszy przepracowany miesiąc, do 2. dnia roboczego

Checklist for a new person — from the first e-mail to the first timesheet.

• ☐ Company account @panka.pl + Google Workspace — set up by Weronika
• ☐ HR PANKA account (hr.panka.pl) — the invitation arrives by e-mail; set a password and log in
• ☐ Employee data form — the link comes from Weronika (individual, one-time). Fill in: personal details, addresses, bank account number for salary, education. Don't postpone it — we cannot close the HR formalities without it.
• ☐ Slack — invitation to the company address; 2FA is mandatory (enable it at first login)
• ☐ Google Drive — ask for access to the team folders
• ☐ Trello — ask for access to the project board
• ☐ Read this Wiki — especially "FENG-DSS project", "Purchases and receipts", "Time reporting"
• ☐ Contract and formalities — signed by Weronika/Paweł; HR questions → Weronika
• ☐ First timesheet — for your first worked month, by the 5th business day

Gotowe dokumenty — skąd je wziąć.

Biblioteka szablonów PANKA

Wszystkie szablony leżą w jednym folderze: Szablony na Google Drive

Prezentacje — najważniejsze zasady

• Instaluj fonty Space Grotesk i DM Sans na każdym komputerze (bez tego PowerPoint podstawi zamiennik i proporcje się rozjadą) — linki w how-to.
• Nowy slajd buduj z galerii układów (Narzędzia główne → Nowy slajd), nie przez kopiowanie starych.
• Tytuł slajdu to teza z czasownikiem, nie etykieta — „Trzy z pięciu pakietów wyprzedzają plan", nie „Status pakietów".
• Jeden slajd = jedna myśl. Wykres bez wniosku nie istnieje (układ 11 ma panel na wniosek).
• Paleta: granat #0A0E17, cyjan #00D4FF jako akcent (max 10% slajdu). Na jasnym tle tekst akcentowy = #00688F (#00D4FF na bieli nie przechodzi kontrastu WCAG).

Materiały firmowe (logo, flyer, stopka)

• Materiały firmowe na Drive — logo, flyer, szablon stopki e-mail.
• Logo PANKA — wersje na jasne i ciemne tło (PNG, przezroczyste).

Nie znalazłeś szablonu, którego potrzebujesz? Napisz do Weroniki — dodamy go tutaj.

Ready-made documents — where to find them.

PANKA template library

All templates live in one folder: Templates on Google Drive

Presentations — key rules

• Install Space Grotesk and DM Sans on every computer (otherwise PowerPoint substitutes fonts and slides break) — links in the how-to.
• Build new slides from the layout gallery (Home → New Slide), never by copying old ones.
• A slide title is a thesis with a verb, not a label.
• One slide = one thought. A chart without a conclusion does not exist (layout 11 has a conclusion panel).
• Palette: navy #0A0E17, cyan #00D4FF as accent (max 10% of the slide). On light backgrounds the accent text colour is #00688F (WCAG contrast).

Brand materials (logo, flyer, footer)

• Brand materials on Drive — logo, flyer, e-mail footer template.
• PANKA logo — light- and dark-background versions (transparent PNG).

Missing a template you need? Ask Weronika — we'll add it here.

Jak prowadzimy projekty w PANKA.

1. Małe kroki, widoczny efekt

Pracujemy w krótkich iteracjach. Lepiej mieć w piątek działający fragment z notatką niż „prawie gotowe" bez śladu. Postęp pokazujemy na commitach i w dokumentacji.

2. Decyzje mają ślad

Istotne decyzje techniczne i projektowe zapisujemy (krótka notatka: co, dlaczego, alternatywy). To chroni nas przy audytach projektu i oszczędza dyskusje „a kto tak zdecydował?".

3. AI wspiera, człowiek decyduje

Korzystamy z narzędzi AI do researchu, dokumentacji, testów i automatyzacji. Zawsze weryfikuj efekty i nie wprowadzaj do narzędzi AI danych, których nie wolno udostępniać (dane osobowe, hasła, dokumenty poufne).

4. Jakość i zgodność

Pracujemy w branży lotniczej — tu dokumentacja i powtarzalność procesu są częścią produktu. Testy, review kodu i porządek w repozytorium to standard, nie biurokracja.

5. Komunikacja

• Slack — sprawy bieżące, pytania, szybkie decyzje.
• Mail — sprawy formalne i dokumenty.
• Spotkania — krótkie, z agendą; wnioski spisujemy po każdym.
• Nie wiesz, do kogo z pytaniem? Napisz na ogólny kanał — pokierujemy.

5. Model V („V-shape") — definicja i dowody

Cykl życia systemu prowadzimy według modelu V: każda faza definicji po lewej stronie ma sparowaną fazę dowodową po prawej. Nie przechodzimy do fazy dowodowej bez zatwierdzonej baseline'y fazy definicji.

Bramki jakości (wejście do fazy = zatwierdzone wyjście poprzedniej):

1. Baseline wymagań — SRD zatwierdzone + RTM otwarty.
2. Przegląd projektu — PDR/CDR (architektura + ICD zatwierdzone).
3. Gotowość do testów — TRR (środowisko, procedury, przypadki testowe).
4. Raport weryfikacji — SVR: komplet dowodów pokrywających wymagania.
5. Raport walidacji — VVR: akceptacja operacyjna przez użytkownika.

6. Zgodność z DO-284 — dane i interoperacyjność

Standard odniesienia dla wymagań komunikacji danych: RTCA/EUROCAE DO-284A — MASPS dla ATN Baseline 1 (systemy końcowe, systemy pośrednie, routery, bramki). Dla projektów PANKA (DSS/UTM/ATM, SWIM) z DO-284A bierzemy:

• Wymagania interoperacyjności i interfejsów — każdy interfejs opisany w ICD, walidowany testami interoperacyjnymi.
• Kryteria wydajności komunikacji danych — opóźnienia, integralność, ciągłość (np. dla M1 projektu DSS: latency <100 ms, integralność >99,99%, NACp 11).
• Scenariusze walidacji w środowisku reprezentatywnym — multi-USSP, synchronizacja ATM↔UTM, obciążenie ≥1000 wiadomości/min.
• Dowody w postaci wyników testów kwalifikacyjnych (QTP/QTR) i interoperacyjnych (ITP/ITR) — nie same deklaracje zgodności.

7. Pełna dokumentacja walidacyjna

• VP — Validation Plan: cele, metody dowodzenia (analiza, inspekcja, demonstracja, test), kryteria akceptacji, środowisko, role.
• SRS / SDD / ICD — wymagania, architektura, interfejsy (szablon: PANKA_szablon_dokumentacji_technicznej.docx).
• RTM — macierz wymagań: wymaganie → implementacja → test → dowód.
• VVP — Verification & Validation Procedures: procedury krok po kroku, dane wejściowe i oczekiwane wyniki.
• QTP/QTR — Qualification Test Plan / Report: testy kwalifikacyjne z kompletem rezultatów.
• ITP/ITR — Interoperability Test Plan / Report: interfejsy DSS↔USSP↔ATM.
• SVR — System Verification Report: pokrycie wymagań dowodami i lista odstępstw.
• VVR — Validation Report: walidacja operacyjna i akceptacja.
• Safety — Hazard Log + ocena bezpieczeństwa (PSSA/SSA) dla funkcji krytycznych.
• CM / QA — Plan konfiguracji (baseline'y, wersje) i Plan QA (przeglądy, audyty).

Każdy dokument ma identyfikator (PANKA-DSS-XXX-000), metrykę z akceptacjami (Autor / Weryfikacja techniczna / QA / Zatwierdzenie — jak w szablonie), numer wersji i miejsce w Drive (DSS → Dokumentacja). Dokument bez zaakceptowanej metryki nie wchodzi do baseline'y.

How we run projects at PANKA.

1. Small steps, visible results

We work in short iterations. Better to have a working fragment with a note on Friday than "almost done" with no trace. Progress is shown in commits and documentation.

2. Decisions leave a trace

We record significant technical and project decisions (a short note: what, why, alternatives). This protects us in project audits and saves us "who decided that?" discussions.

3. AI supports, humans decide

We use AI tools for research, documentation, tests and automation. Always verify the results and never feed AI tools data that must not be shared (personal data, passwords, confidential documents).

4. Quality and compliance

We work in the aviation industry — here documentation and process repeatability are part of the product. Tests, code review and repository hygiene are the standard, not bureaucracy.

5. Communication

• Slack — day-to-day matters, questions, quick decisions.
• E-mail — formal matters and documents.
• Meetings — short, with an agenda; conclusions are written up after each one.
• Not sure who to ask? Post on the general channel — we will point you.

5. The V-model — definition and evidence

We run the system lifecycle according to the V-model: every definition phase on the left has a paired evidence phase on the right. No evidence phase starts without an approved baseline from the definition phase.

Quality gates (a phase starts only on the approved output of the previous one):

1. Requirements baseline — SRD approved + RTM opened.
2. Design review — PDR/CDR (architecture + ICD approved).
3. Test readiness — TRR (environment, procedures, test cases).
4. Verification report — SVR: complete evidence covering the requirements.
5. Validation report — VVR: operational acceptance by the user.

6. DO-284 compliance — data and interoperability

Reference standard for data communication requirements: RTCA/EUROCAE DO-284A — MASPS for ATN Baseline 1 (end-systems, intermediate systems, routers, gateways). For PANKA projects (DSS/UTM/ATM, SWIM) we take from DO-284A:

• Interoperability and interface requirements — every interface covered by an ICD and validated by interoperability tests.
• Data-communication performance criteria — latency, integrity, continuity (e.g. DSS milestone M1: latency <100 ms, integrity >99.99%, NACp 11).
• Validation scenarios in a representative environment — multi-USSP, ATM↔UTM synchronisation, load ≥1000 messages/min.
• Evidence in qualification (QTP/QTR) and interoperability (ITP/ITR) test results — never bare compliance claims.

7. Full validation documentation set

• VP — Validation Plan: objectives, proof methods (analysis, inspection, demonstration, test), acceptance criteria, environment, roles.
• SRS / SDD / ICD — requirements, architecture, interfaces (template: PANKA_szablon_dokumentacji_technicznej.docx).
• RTM — requirements traceability matrix: requirement → implementation → test → evidence.
• VVP — Verification & Validation Procedures: step-by-step procedures, inputs and expected results.
• QTP/QTR — Qualification Test Plan / Report: qualification testing with full results.
• ITP/ITR — Interoperability Test Plan / Report: DSS↔USSP↔ATM interfaces.
• SVR — System Verification Report: evidence coverage and deviations list.
• VVR — Validation Report: operational validation and acceptance.
• Safety — Hazard Log + safety assessment (PSSA/SSA) for critical functions.
• CM / QA — configuration plan (baselines, versions) and QA plan (reviews, audits).

Every document carries an ID (PANKA-DSS-XXX-000), the approval metric (Author / Technical verification / QA / Approval — as in the template), a version and a place in Drive (DSS → Dokumentacja). A document without an approved metric never enters the baseline.