Konwencje nazewnictwa plików: kompletny przewodnik dla zespołów

Polska norma PN-EN ISO 8601 definiuje format daty, który jest jedynym sensownym punktem startowym dla nazw plików — a mimo to większość polskich firm nadal zapisuje daty jako 12.06.2026 lub czerwiec_2026, co niszczy sortowanie i powoduje konflikty między systemami. Konwencja nazewnictwa plików, która przeżyje kontakt z rzeczywistością, używa formatu: YYYY-MM-DD_KodProjektu_TypDok_Opis_vNN.ext. Zawsze daty ISO 8601 (sortują się prawidłowo), krótkie kody projektów (3–10 znaków), kontrolowane słownictwo dla TypDok, opisy w kebab-case, dwucyfrowe numery wersji (v02, nie v2) i małe litery tam, gdzie nie ma to znaczenia. Format ma mniejsze znaczenie niż spójność — wybierz jeden, zapisz go, i egzekwuj przy onboardingu i cotygodniowych porządkach.

Dlaczego data na początku bije datę gdziekolwiek indziej

Daty ISO 8601 (YYYY-MM-DD) na początku nazwy pliku rozwiązują sortowanie. 2026-06-12_raport.pdf sąsiaduje z 2026-06-13_raport.pdf w dowolnym systemie plików, dowolnym dysku chmurowym, dowolnym narzędziu. Przenieś datę na koniec, a tracisz to; umieść w środku, a sortowanie staje się losowe.

Używaj konkretnie ISO 8601, nie US (MM/DD/YYYY), UK (DD/MM/YYYY) ani bez interpunkcji (YYYYMMDD). ISO to jedyny format, który:

Sortuje prawidłowo jako tekst
Parsuje jednoznacznie między lokalizacjami (czy 06/05/2026 to 6 maja czy 5 czerwca?)
Odpowiada międzynarodowemu standardowi używanemu przez każdą dużą firmę technologiczną w logach

Dla plików wrażliwych na czas dodaj godzinę: 2026-06-12T1430Z_notatki-ze-spotkania.md używa UTC. Przydatne dla wielostrefowych zespołów, gdzie ważne jest „kiedy to zostało wyprodukowane".

Kody projektów, które skalują się

Krótki kod projektu na drugiej pozycji sprawia, że pliki są przeszukiwalne po projekcie bez polegania na strukturze folderów. Zasady, które działają:

3–10 znaków, wielkie litery, myślniki dozwolone
Pierwsze 3–4 znaki identyfikują klienta lub jednostkę wewnętrzną
Opcjonalny sufiks identyfikuje typ lub fazę projektu

Przykłady: ACME-RB (rebranding Acme), WEWN-ONBRD (onboarding wewnętrzny), FINOPS-Q2 (operacje finansowe Q2), ACME-SUP-001 (zaangażowanie supportowe Acme #1).

Prowadź rejestr kodów projektów w Notion, Confluence lub współdzielonym arkuszu. Gdy ktoś tworzy nowy projekt, rejestruje kod. Zajmuje 30 sekund. Zapobiega sytuacji, w której trzy miesiące później ktoś nazywa projekt ACMErebranding, a Ty Acme-RB — i oba pliki istnieją równolegle.

Kontrolowane słownictwo dla TypDok

Slot typu dokumentu wymaga stałej listy. Bez niej ląduje się z raport, Raport, RAPORT, rpt, rptr, podsumowanie, podsumowanie-raportu i raport-finalny — wszystkie oznaczające to samo.

Słownictwo startowe:

brief — wstępne briefe projektów, briefe kreatywne
spec — specyfikacje techniczne lub designu
umowa — umowy prawne, SOW, NDA
faktura — dokumenty rozliczeniowe
oferta — pitch i oferty handlowe
raport — raporty periodyczne lub doraźne
prezentacja — decki, pitche, all-hands
design — zasoby i deliverables designu
wideo — nieobrobione lub gotowe treści wideo
audio — podcasty, voiceovers, audio źródłowe
dane — pliki CSV, Excel, JSON z danymi
notatka — notatki ze spotkań, roboce mema
szablon — wielokrotnego użytku punkty startowe

Lista powinna być krótka. Jeśli ktoś chce dodać whitepaper, zapytaj, czy naprawdę różni się od raport. Dyscyplina na poziomie listy procentuje złożonymi dywidendami.

Numeracja wersji, która naprawdę działa

v1, v2, v3 działa dopóki nie trafisz na v10, które sortuje się przed v2. Używaj dwucyfrowych numerów wersji od początku: v01, v02, v03, ..., v10, v11.

Dla dłuższych projektów, które mogą przekroczyć 99 wersji, zacznij od trzech cyfr: v001.

Rozróżniaj między głównymi wersjami a szkicami:

v01 oznacza pierwszą zatwierdzoną wersję
v01.1, v01.2 oznacza mniejsze szkice w ramach głównej
Bump głównej wersji przy istotnych zmianach wartych świeżego przeglądu

Nie używaj semantycznego wersjonowania (v1.2.3) dla dokumentów biznesowych. Odpowiednie jest dla oprogramowania i API, nie dla umów czy decków.

Pułapka „finalne": nigdy nie umieszczaj słowa „finalne" w nazwie pliku. Gwarantuje to, że skończysz z finalne, finalne-finalne, finalne-finalne-PRAWDZIWE i finalne-uzyj-tego. Używaj v02 dla tego, co masz na myśli przez „finalne", i zaufaj numeracji wersji.

Opisy w kebab-case

Slot opisu to jedyna część formatu swobodnego. Trzymaj go:

Małymi literami
W kebab-case (słowa oddzielone myślnikami)
Krótki: 2–5 słów
Wystarczająco konkretny do przeglądania: prognoza-przychodow-q2 bije prognoza

glowna-umowa-serwisowa jest dobra. GlownaUmowaSerwisowa.pdf jest zła, bo wyszukiwania case-insensitive dają niespójne wyniki, a czytniki ekranu wymawiają to dziwnie. glowna umowa serwisowa jest zła, bo spacje w nazwach plików psują pipeline'y z linią poleceń i kodowanie URL.

Egzekwowanie bez policyjnego państwa

Nie możesz ręcznie egzekwować nazewnictwa każdego pliku w 200-osobowej organizacji. Możesz:

Onboarding: 15 minut w pierwszym tygodniu na konwencję nazewnictwa z przykładami
Szablony: wstępnie nazwane pliki szablonów w /Wiedza/Szablony/ — ludzie zaczynają od właściwego kształtu
Korekta podczas przeglądów: przeglądając pracę, zmieniaj nazwy źle nazwanych plików z lekkim komentarzem („zmieniono nazwę zgodnie z konwencją — wspomniane przy onboardingu")
Cotygodniowe porządki: 10 minut od rotującego właściciela do naprawy dryftu
Zautomatyzowane boty do zmiany nazw: dla folderów o dużym wolumenie skrypty obserwujące nowe pliki i zmieniające nazwy na podstawie metadanych. Python + watchdog + os.rename to projekt na pół dnia

Dla repozytoriów rekordowych — umowy, faktury, podpisane dokumenty — rozważ bardziej rygorystyczne egzekwowanie: biblioteki dokumentów SharePoint mogą wymagać pól metadanych przed zapisem. Etykiety Google Drive na Workspace Business Plus mogą być wymagane w określonych folderach.

Rozszerzenia specyficzne dla formatu

Rozszerzenie ma większe znaczenie, niż ludzie myślą:

.pdf dla finalnych dokumentów, które nie powinny być edytowane
.docx i .xlsx dla edytowalnych plików Office; unikaj .doc i .xls (przestarzałe formaty z problemami bezpieczeństwa)
.pptx dla prezentacji; .key tylko jeśli jesteś wyłącznie w ekosystemie Mac
.md dla technicznych notatek i wewnętrznych wiki — sortowalny, różnicowalny w Git, czytelny na zawsze
.csv dla wymiany danych; .xlsx dla finalnych analiz z formatowaniem
.mp4 dla wideo z kodowaniem H.264 lub H.265; unikaj .mov chyba że naprawdę potrzebujesz ProRes do montażu
.psd, .ai, .indd dla plików źródłowych Adobe; .fig dla źródeł Figma

W razie wątpliwości wybierz format, który będzie czytelny za 10 lat bez specjalistycznego oprogramowania. PDF i Markdown niemal zawsze wygrywają ten zakład.

Znaki specjalne i limity długości

Niektóre znaki psują systemy plików lub narzędzia chmurowe:

Unikaj: / \ : * ? " < > | — niektóre psują Windows, inne macOS
Unikaj spacji w nazwach plików — psują linie poleceń, URL i niektóre narzędzia
Unikaj non-ASCII chyba że konsekwentnie pracujesz z wielojęzycznymi zespołami (znaki diakrytyczne działają na nowoczesnych systemach, ale psują się na niektórych starszych narzędziach)
Trzymaj pełne ścieżki poniżej 255 znaków — niektóre narzędzia Windows nadal zawodzą powyżej tego limitu

Dla międzynarodowych zespołów, nazwy plików UTF-8 działają na nowoczesnym macOS, Windows 10+ i wszystkich głównych chmurach. Przetestuj przed poleganiem na tym.

Migracja bez niszczenia historii

Przy przyjmowaniu nowej konwencji na istniejącym bałaganie nie zmieniaj nazw historycznych plików. Zepsujesz istniejące linki, zakładki i referencje. Zamiast tego:

Przyjmij nową konwencję dla wszystkich nowych plików od określonej daty
Zmieniaj nazwy tylko plików dotykanych podczas bieżącej pracy
Pozwól, aby archiwum naturalnie się postarzało przez 2–3 lata

Pełna retroaktywna zmiana nazw na 10 000 plików to 40-godzinny projekt, który zwykle nie jest warty kosztów. Dyscyplina ku przyszłości bije porządki ku przeszłości.

Wypróbuj HexaTransfer na hexatransfer.com — bezpłatny, bez konta, max 10 GB.