Standard

Standard językowy w praktyce firmy

Standard językowy nie jest broszurą „ładnego pisania”. W organizacji pełni rolę kontraktu: ogranicza ryzyko (obietnice, compliance), skraca review i ujednolica komunikację. Ten rozdział pokazuje, jak przejść od zasad do egzekwowania — ludźmi i narzędziem.

Czas czytania: ~15–20 min Status: Recommended Wersja: 1.0 Aktualizacja: 4 stycznia 2026
Zasady w skrócie
  • na zewnątrz: język formalny, rzeczowy, bez ironii
  • bez absolutów i obietnic bez podstaw („na pewno”, „gwarantujemy”)
  • gdy brak danych: mówimy wprost, czego brakuje i co dalej
  • terminologia wg glosariusza; brak mieszanek PL/EN bez decyzji
  • format i sekcje zależnie od kanału (support, release notes, ADR)
  • standard ma ownera, wersję i rejestr wyjątków
Cel standardu: zmniejszyć zmienność i ryzyko komunikacji — tak, aby treści były spójne, audytowalne i łatwe do utrzymania.

1. Czym standard jest, a czym nie jest

Jest:

  • zbiorem norm must/should, które da się egzekwować,
  • narzędziem pracy (szablony, checklisty, glosariusz),
  • elementem governance (owner, wersje, wyjątki, audyt).

Nie jest:

  • zbiorem opinii bez konsekwencji,
  • estetycznym „tone of voice” bez procesu wdrożenia,
  • PDF‑em, który raz się opublikuje i odkłada.

2. Zakres: kanały, języki, poziom rygoru

Standard powinien mieć jawny zakres. W praktyce przynajmniej:

  • kanały zewnętrzne (support, komunikaty produktowe, WWW),
  • kanały wewnętrzne (RFC/ADR, instrukcje operacyjne),
  • język(i) i zasady tłumaczeń,
  • poziomy rygoru (Recommended vs Mandatory).
Praktyka: brak rozróżnienia kanałów prowadzi do konfliktów. Inaczej pisze się do klienta, inaczej do zespołu technicznego.

3. Tone of Voice: reguły, nie przymiotniki

„Nowoczesny, dynamiczny” nie jest standardem. Standardem są reguły: formalność, pewność, struktura wypowiedzi, sposób odmowy i formułowania terminów.

Sytuacja Zalecane Unikać
Brak pewności „Na tym etapie nie mamy podstaw, aby potwierdzić X. Aby to zweryfikować, potrzebujemy Y.” „To na pewno błąd po Państwa stronie.”
Prośba o dane „Proszę o numer zamówienia i orientacyjną godzinę zdarzenia.” „Wyślij wszystko, bo inaczej nic nie zrobimy.”
Odmowa „Nie mamy możliwości…; alternatywnie możemy…” „Nie da się i już.”

4. Glosariusz i terminologia

Glosariusz porządkuje nazwy funkcji, produktów i pojęć. Bez niego spójność nie utrzyma się w czasie. Minimalny wpis glosariuszowy powinien mieć: termin preferowany, warianty, formy zakazane, definicję i przykład.

glossary_entry:
  term: "reset hasła"
  preferred: "reset hasła"
  also_known_as: ["odzyskiwanie hasła", "przypomnienie hasła"]
  avoid: ["password recovery (w treściach PL)"]
  definition: "Proces ustawienia nowego hasła przez link jednorazowy."
  examples_good:
    - "Proszę wykonać reset hasła zgodnie z instrukcją w wiadomości e‑mail."

5. Zakazane obietnice i język ryzyka

Najbardziej kosztowne błędy językowe to obietnice i absoluty. W treściach zewnętrznych należy ograniczać sformułowania, które brzmią jak gwarancje, SLA lub pewność faktów bez źródeł.

Unikać Zastąpić Powód
„na pewno” „na tym etapie nie mamy podstaw…”, „w typowych przypadkach…” Kontrola pewności i odpowiedzialności.
„gwarantujemy” „deklarujemy w ramach…”, „zapewniamy zgodność z…” Unikanie obietnic bez podstaw formalnych.
„dzisiaj naprawimy” „termin zależy od…; potwierdzimy po…” Termin wymaga warunków i procesu.

6. Format i higiena informacji

  • daty i godziny: jawny format i strefa czasowa,
  • liczby i jednostki: konsekwentny zapis,
  • linki i odwołania: tylko do aktualnych źródeł,
  • cytowania: tam, gdzie stawiamy tezy faktograficzne (jeżeli proces tego wymaga).

7. Ramy odpowiedzi i szablony (praktyka)

Dla powtarzalnych kanałów utrzymuje się stałe ramy, które ułatwiają review i automatyczne walidacje.

Support (zewnętrzny)
Podsumowanie → Kroki → Jeżeli potrzebne → Zastrzeżenia
Release notes
Zmiana → Powód → Skutek → Rollback / obejście
ADR / RFC (wewnętrzny)
Problem → Opcje → Decyzja → Konsekwencje

8. Artefakty standardu (żeby to działało)

  • dokument standardu + przykłady i antyprzykłady,
  • glosariusz (wersjonowany),
  • szablony i checklisty,
  • reguły egzekucyjne (policy‑as‑code),
  • rejestr wyjątków (z terminem ważności),
  • changelog (co i dlaczego zmieniono).

9. Governance: owner, wersje, wyjątki

Standard wymaga właściciela. Rekomendowany model to: jedno A (Accountable) i jasny proces zmian. Szczegóły ról: Model odpowiedzialności (RACI).

10. Egzekucja w Luage Guidance Engine

Compendium opisuje zasady, a Guidance Engine je egzekwuje. Minimalny zestaw reguł, który zwykle daje szybki efekt:

  • wykrywanie zakazanych zwrotów (absoluty, obietnice),
  • walidacja formatu (sekcje / JSON Schema),
  • skany PII i redakcja danych,
  • kontrola cytowań (jeżeli wymagane).
Wniosek: Standard bez egzekucji skaluje się słabo. Standard z bramkami jakości i testami regresji — skaluje się spokojnie.

11. Checklisty (v1)

Komunikacja zewnętrzna
  • czy ton jest formalny i rzeczowy?
  • czy terminologia jest zgodna z glosariuszem?
  • czy uniknięto obietnic i absolutów?
  • czy wskazano brakujące informacje, jeśli są potrzebne?
  • czy nie ma danych wrażliwych?
  • czy format jest zgodny z ramą (sekcje)?

12. Podsumowanie

Standard językowy jest elementem jakości procesu. Jeżeli ma działać, musi mieć ownera, wersję, wyjątki oraz mechanizmy egzekucji. W Luage naturalnym mostem między zasadą a praktyką jest pakiet kontekstu i bramki jakości.

Powiązane rozdziały