Wersjonowanie projektu to nadawanie każdej iteracji jednoznacznego numeru i trzymanie jednego źródłowego pliku, żeby zawsze wiadomo było, która wersja jest aktualna i co klient właściwie zatwierdził. W praktyce wystarczą trzy rzeczy: prosta numeracja, jeden plik źródłowy zamiast kopii oraz powiązanie wersji z momentem akceptacji. Poniżej masz gotowy system, który działa nawet bez specjalnego narzędzia.
Dlaczego „finalna_v2_NEW_ostateczna" to problem?
Nazwy w stylu `projekt_final_v2_NEW_ostateczna(1)` to nie żart — to codzienność, która kosztuje. Bez jednoznacznego numeru każda rozmowa z klientem i ekipą zaczyna się od ustalania, o czym w ogóle mówimy. Ryzyko jest konkretne:
- ktoś poprawia starą kopię, a praca z aktualnej przepada,
- klient akceptuje wersję, której nie widziałeś, bo dostał ją inną drogą,
- wykonawca dostaje nieaktualny rzut i realizuje nieaktualne ustalenia.
Sednem problemu nie jest bałagan w nazwach, tylko brak jednej prawdy o tym, co jest aktualne. Przykład z życia studia: ekipa zamontowała oświetlenie według rzutu sprzed dwóch poprawek, bo krążyły trzy PDF-y o podobnej nazwie. Koszt nie był „estetyczny" — trzeba było przerabiać.
Prosty system numeracji wersji
Nie potrzebujesz skomplikowanego narzędzia — potrzebujesz konsekwencji. Działa taki schemat:
- Numer rośnie liniowo — v1, v2, v3. Bez „NEW", „ostateczna", „final-final".
- Numer + etap — „Wizualizacje salonu, wersja 3", żeby było wiadomo, czego wersja dotyczy.
- Data przy wersji — kiedy powstała; ułatwia powrót po miesiącach.
- Jedna wersja = jedna runda poprawek — nową wersję tworzysz po zamknięciu rundy, nie po każdym mailu.
Dzięki temu „wersja 3" znaczy to samo dla Ciebie, klienta i wykonawcy. Jeśli pracujesz na plikach, ustal jedną konwencję nazw i trzymaj się jej bez wyjątków, np. `salon_wizualizacje_v3_2026-06-03`.
Co właściwie wersjonować?
Nie wszystko zmienia się w tym samym tempie. Warto rozdzielić, co wersjonujesz osobno:
| Element | Co się zmienia | Jak wersjonować |
|---|---|---|
| Rzut funkcjonalny | Układ, strefy, ściany | Numer rośnie przy każdej zatwierdzonej zmianie układu |
| Wizualizacje | Kolory, materiały, meble | Osobna numeracja per pomieszczenie/scena |
| Kosztorys / lista zakupowa | Pozycje i ceny | Wersja powiązana z wersją projektu, której dotyczy |
| Dokumentacja wykonawcza | Rysunki techniczne | Numer + data; to ona trafia do wykonawcy |
Kluczowe: wersje różnych elementów powinny dać się ze sobą powiązać — żeby „kosztorys do wizualizacji v3" był jednoznaczny.
Jeden źródłowy plik (single source of truth)
Kopia to początek rozjazdu. Im więcej egzemplarzy `projekt.pdf` krąży po mailach, tym pewniej ktoś pracuje na nieaktualnym. Zasada „jeden źródłowy plik" oznacza, że istnieje jedno miejsce, w którym leży aktualna wersja — a wszyscy odwołują się do niego, zamiast trzymać własne kopie.
To także warunek sensownego feedbacku: uwagi mają sens tylko wtedy, gdy wszyscy patrzą na tę samą wersję. W Arkeeno projekt i jego wersje żyją w jednym workspace, więc klient i zespół zawsze widzą aktualny stan, a nie kopię sprzed tygodnia.
→ Jak zbierać uwagi do aktualnej wersji, opisujemy w tekście jak zbierać feedback na wizualizacjach.
Wersja a akceptacja — jak je powiązać
Numer wersji nabiera mocy w momencie akceptacji. Gdy klient zatwierdza „wersję 3", właśnie ta wersja staje się punktem odniesienia, a dalsze zmiany traktujesz jako osobny zakres. Bez numeru nie da się jednoznacznie powiedzieć, co zostało zatwierdzone — a wtedy poprawka po cichu wraca jako darmowa.
Dlatego wersjonowanie i akceptacje to jeden mechanizm: numer mówi „co", a protokół akceptacji mówi „że zatwierdzone i kiedy".
→ Całość spina przewodnik jak prowadzić akceptacje projektu z klientem; zobacz też pojęcie protokół akceptacji.
Wersjonowanie a przekazanie wykonawcy
Najwięcej kosztują błędy na styku z wykonawstwem. Przed przekazaniem na budowę upewnij się, że ekipa dostaje tę jedną, zatwierdzoną wersję — z numerem i datą — a nie „ostatniego maila z załącznikiem". Dobrym nawykiem jest jedno zdanie w przekazaniu: „aktualna jest wersja 3 z 3 czerwca; wcześniejsze są nieaktualne".
Nazewnictwo i archiwizacja w zespole
Gdy nad projektem pracuje więcej niż jedna osoba, konwencja nazw przestaje być kosmetyką — staje się warunkiem, żeby ktoś nie nadpisał cudzej pracy. Ustal jeden wzór i trzymaj się go bez wyjątków, np.:
`[projekt]_[element]_v[numer]_[RRRR-MM-DD]` → `kowalski_salon-wizualizacje_v3_2026-06-03`
Kilka zasad, które oszczędzają nerwów w zespole:
- Stare wersje archiwizuj, nie kasuj — przenoś je do podfolderu `_archiwum`, żeby nie mieszały się z aktualną, ale dało się do nich wrócić w sporze.
- Tylko jedna osoba „wypuszcza" wersję — ustal, kto nadaje numer i przekazuje wersję klientowi, żeby nie powstały dwie „wersje 3".
- Nie pracuj na wersji wysłanej do akceptacji — czekasz na uwagi, kolejne zmiany robisz dopiero w następnej.
W narzędziu, które samo trzyma historię wersji (jak Arkeeno), część tej dyscypliny dzieje się automatycznie — bo wersje i tak są w jednym miejscu, z datą i autorem.
Najczęstsze błędy
- Mnożenie kopii zamiast jednego źródłowego pliku.
- Nazwy bez numeru („final", „NEW") — nikt nie wie, co aktualne.
- Nowa wersja po każdym mailu — zamiast po zamkniętej rundzie poprawek.
- Akceptacja bez numeru wersji — brak śladu, co właściwie zatwierdzono.
- Przekazanie wykonawcy bez wskazania aktualnej wersji — realizacja nieaktualnych ustaleń.
FAQ
Jak numerować wersje projektu? Liniowo (v1, v2, v3), z nazwą etapu i datą. Nową wersję twórz po zamknięciu rundy poprawek, nie po każdej pojedynczej uwadze.
Co to jest jeden źródłowy plik? Jedno miejsce, w którym leży aktualna wersja projektu i do którego odwołują się wszyscy, zamiast trzymać własne kopie. Eliminuje pracę na nieaktualnym.
Jak powiązać wersję z akceptacją? Akceptuj zawsze konkretny numer wersji („wersja 3") i zapisz to w protokole akceptacji z datą — wtedy wiadomo, co dokładnie zostało zatwierdzone.
Którą wersję przekazać wykonawcy? Wyłącznie aktualną, zatwierdzoną wersję z numerem i datą, z jasną informacją, że wcześniejsze są nieaktualne.
Ostatnia aktualizacja: 2026-06-03. Autor: [Imię Nazwisko, stanowisko]. >Zobacz, jak Arkeeno trzyma wersje i akceptacje w jednym miejscu.
