Jak to nazywać - poradnik

Jak to nazywać - poradnik

Nazewnictwo to jedna z większych bolączek nie tylko autorów wszelkiego rodzaju dokumentów, plików, folderów, diagramów itp., ale przede wszystkim ich odbiorców. Nazywanie niezwykle często bywa powodem wielu problemów i nieporozumień.
Ratunkiem jest wprowadzenie zunifikowanego systemu nazywania, który pozwoli na szybkie odnajdywanie potrzebnych danych, błyskawiczne rozpoznanie zawartości i uniknięcie tzw. “podwójnej pracy”.

Jak to nazywać czyli onomastyka nasza powszednia - poradnik

Nazewnictwo to jedna z większych bolączek nie tylko autorów wszelkiego rodzaju dokumentów, plików, folderów, diagramów itp., ale przede wszystkim ich odbiorców. Nazywanie niezwykle często bywa powodem wielu problemów i nieporozumień wśród osób współpracujących zarówno wewnątrz zespołów projektowych, jak i całych przedsiębiorstw.

Ratunkiem jest wprowadzenie zunifikowanego systemu nazywania, który pozwoli na szybkie odnajdywanie potrzebnych danych, błyskawiczne rozpoznanie zawartości pliku czy folderu, uniknięcie tzw. “podwójnej pracy” spowodowanej wykorzystaniem nieaktualnego dokumentu.

W naszym poradniku prezentujemy Ci przydatne aspekty teoretyczne i praktyczne onomastyki, oparte o opracowania językoznawcze i biznesowe doświadczenie.  Do Twojej dyspozycji oddajemy także propozycję systemu nazywania dokumentów, gotową do wdrożenia w Twojej firmie.

Nazwa własna

Zgodnie z definicją zaproponowaną przez Radę Języka Polskiego “nazwa własna to wyraz, wyrażenie lub jakakolwiek inna forma językowa (np. zdanie) służąca do wyróżnienia jednego przedmiotu (np. instytucji, osoby, produktu, utworu, usługi) spośród innych*” . Oznacza to, że każda nazwa nadawana dokumentowi, plikowi, folderowi, a nawet całemu projektowi jest nazwą własną.

Niezbędna do dobrego nazywania dokumentów jest umiejętność odróżnienia nazwy własnej od nazwy pospolitej. Encyklopedia Języka Polskiego definiuje ją jako nazwę “mogąca się odnosić do dowolnego egzemplarza desygnatów danej klasy przedmiotów (np. stół, drzewo, pies, kobieta, człowiek), w odróżnieniu od nazw własnych, odnoszących się do jednostek”.

Podsumowując, o ile w każdym języku wymienione desygnaty: stół, drzewo, pies, kobieta, człowiek, będą miały odmienne brzmienie i zapis, o tyle nazwy własne w każdym języku pozostaną w tej samej postaci (pomijając ewentualne różnice wynikające z adaptacji fonetycznych i morfologicznych).

Typy nazw własnych

W literaturze wyróżniane są trzy typy nazw własnych: antroponimy (czyli nazewnictwo osobowe), toponimy (czyli nazewnictwo miejscowe/geograficzne) oraz chrematonimy (czyli nazewnictwo wszelkich wytworów kultury). Wśród chrematonimów znajdują się m.in. nazwy handlowe firm i produktów, instytucji, zrzeszeń, wydarzeń i inicjatyw społecznych, okoliczności w kalendarzu, zdarzeń obchodzonych cyklicznie lub okazjonalnie, dzieł artystycznych, wytworów produkcji medialnej oraz nazwy projektów. To właśnie chrematonimy są najliczniejszą podgrupą nazw własnych. Za każdym razem kiedy nadajesz nazwę dokumentowi, plikowi, folderowi, czy chociażby klasie, tworzysz kolejny chrematonim.

Przykłady nazw własnych

Często odróżnienie tego, czy dany desygnat jest nazwą własną czy pospolitą, zależy od kontekstu. Jeśli nazwa nie odnosi się do określonego obiektu, traktowana jest jako nazwa pospolita, np. „wymagania funkcjonalne”. Jeśli natomiast ma odniesienie określone, to o tym, czy nazwa jest pospolita czy własna decyduje powód jej powołania: oznaczenie danego obiektu (wówczas ma status nazwy własnej) lub przywołanie doraźne (wówczas jest nazwą pospolitą).

Na przykład w zdaniu „Spisuję wymagania funkcjonalne”, nazywającemu chodzi zapewne o określony dokument, ale tym samym zdaniem mógłby poinformować o spisywaniu wymagań w formie notatki, stąd użycie małej litery.

Zdanie „Spisuję wymagania funkcjonalne dla CraftoPolu” odnosi się, niezależnie od kontekstu, do tego tych samych wymagań, ale wskazanych za pomocą określenia doraźnego, dlatego tu również występuje mała litera.

Natomiast w zdaniu „Przygotowuję dokument o nazwie Wymagania Funkcjonalne” mamy już do czynienia z nazwą własną, ponieważ nie ma wątpliwości, czy chodzi o cały dokument, czy na przykład samą listę wymagań.

Proponowane zasady nazywania

Nie istnieje jedna, ogólnie przyjęta konwencja. W zależności od potrzeb firmy czy jednostki, wprowadzane są różne rozwiązania. Poniżej przedstawiamy Ci naszą propozycję zasad nadawania nazw w zależności od typu nazywanego obiektu.

Nazywanie projektów

Do nazywania projektów proponujemy stosowanie następującej konwencji:

[Nazwa firmy/produktu] – [Szczegóły]

Przykłady:

  • Craftware – Technical Writing
  • SFDC – Service Cloud
  • Safari – SFDC Implementation

Nazywanie plików/dokumentów

Do nazywania plików i dokumentów proponujemy opcje, zależne od potrzeb i kontekstu biznesowego:

[Nazwa projektu] – [Nazwa dokumentu] DD-MM-RRRR
[Nazwa projektu] – [Nazwa dokumentu] X.X
[Nazwa Systemu] [Numer releasu] – Nazwa dokumentu X.X
[Nazwa Systemu] [Numer releasu] – Nazwa dokumentu RRRR-MM-DD

Przykłady:

  • Pakmex – Notatka z warsztatów 2018-05-18.docx
  • CraftPol – Training Materials 2.0.pptx
  • Zinder Release 2.0.0. – Functional Specification 2.1.docx

Nazywanie klas, metod i zmiennych

Podążając za zaleceniami Salesforce, zalecamy używanie przy nazewnictwie standardów Java:

  • Nazwy klas powinny zaczynać się dużą literą i nie powinny zawierać spacji oraz podkreślników. Jeśli składają się z kilku wyrazów, każdy wyraz powinien zaczynać się dużą literą. Nazwy powinny być znaczące.

  • Metody powinny zaczynać się od czasownika z małej litery. Jeśli składają się z kilku wyrazów, każdy kolejny wyraz powinien zaczynać się dużą literą. Nazwy metod powinny być znaczące.

  • Nazwy zmiennych powinny być znaczące.

Nazywanie diagramów, schematów i grafik dla potrzeb dokumentacji

Każdy diagram, schemat i grafika powinny posiadać nazwę. Podpis powinien być wyrównany do lewej i znajdować się pod diagramem czy grafiką. Zalecamy zastosować następującą konwencję:

Figure. [Opis]
Diagram. [Opis]

Przykłady:

  • Figure. Mockup design
  • Diagram. Regional revenue

Nazywanie diagramów, schematów i grafik w katalogu

  • Utwórz osobny katalog dla wszystkich grafik, nazwij go np. images.
  • Każdą grafikę nazywaj według wzoru:

diagram [opis] [numer wersji]
figure [opis] [numer wersji]
[opis ogólny] – [opis szczegółowy] [numer wersji]

Przykład:

Nadawanie nazw wymagań, numerów ID i nazw referencyjnych

Numery ID wymagań

Wymagania w dokumentach muszą być ponumerowane, aby umożliwić ich identyfikację. W naszej propozycji ID wymagania składa się ze skrótu nazwy projektu, kategorii i kolejnego numeru.

Przykłady:

  • MON-US-001 – User Story w systemie MONSTARI
  • MON-REQ-001 – Wymaganie w systemie MONSTARI
  • MON-UC-010 – Use Case w systemie MONSTARI
  • MON-SCR-023 – Ekran w systemie MONSTARI
  • MON-BR-002 – Reguła biznesowa w systemie MONSTARI
  • MON-DS-001 – Techniczny opis funkcji w systemie MONSTARI

Numery ID dokumentów

Wszystkie dokumenty związane z danym projektem powinny mieć nadany numer ID. Jeśli to możliwe, użyj ID nadanego przez EDMS (Electronic Document Management Systems), na przykład ID nadane w Project Library. ID musi być widoczne na stronie tytułowej dokumentu oraz w nagłówku i stopce na każdej następnej stronie.

Format ID dokumentów

ID może występować w jednym z dwóch formatów:

  1. SystemDocID – nadawany przez EDMS, np. PL ID 11788999
  2. ORG_TYP_n – nadawany ręcznie jeśli dokumenty nie są utrzymywane w EDMS. ORG to organizacja wydająca dokument, TYP to skrót dokumentu, n to numer nadawany kolejno.

Referencje

Kiedy chcesz odesłać czytelnika do innego dokumentu, powinieneś podać jego numer ID, a link do dokumentu powinien być tylko dodatkową informacją.

Dlaczego warto stosować konwencję nazewnictwa

Dzięki zastosowaniu konwencji nazewnictwa, pliki w folderach są zorganizowane w sposób chronologiczny. Co więcej, wystarczy spojrzenie na nazwę pliku, żeby zorientować się czego dotyczy.
Konwencja nazewnictwa powinna być dostosowana do potrzeb Twojego zespołu. Nie ma konwencji idealnej, ale jest kilka podstawowych zasad, którymi warto się kierować.

Na pewno warto wybrać odpowiednią liczbę komponentów nazwy. Zbyt mała liczba komponentów może prowadzić do niejednoznaczności. Z drugiej strony, zbyt duża może ograniczać zrozumienie.

Dodatkowo należy używać zrozumiałych skrótów oraz dokumentować swoje decyzje bazując na tym, jakie komponenty zostaną użyte (na przykład [nazwa projektu]-[rodzaj przedsięwzięcia]), jaki jest prawidłowy zapis (na przykład DOE Project Implementation.docx), co znaczą akronimy (DOE oznacza Department of Energy).

Jako że pliki zostaną zgrupowane na podstawie pierwszych kilku komponentów, elementy nazwy powinny być wymienione w kolejności od bardziej ogólnych do szczegółowych. Co więcej, aby pliki były wyświetlane chronologicznie, warto używać formatu daty rok-miesiąc-dzień (RRRR-MM-DD).

Co zrobić, by system nazewnictwa zadziałał?

Kluczowe jest, by wszyscy pracownicy Twojej firmy zrozumieli sposób nazewnictwa i …sumienne go stosowali. Mamy nadzieję, że nasz poradnik pomoże Ci wdrożyć zunifikowany, zrozumiały system nazewnictwa w Twojej firmie. Jeżeli masz dodatkowe pytania, zapraszamy do kontaktu z nami.