Interne Shortcuts richtig benennen

Ein schlecht gewählter Name kann verhindern, dass interne Shortcuts im Alltag genutzt werden.
Wenn /urlaubsantrag-formular-2026-aktuell im System steht, wird ihn niemand aus dem Kopf tippen. Wenn stattdessen /urlaub reicht, erinnern sich die Leute daran, ohne nachzuschauen.
Benennung klingt trivial. In der Praxis scheitert sie regelmäßig, weil unterschiedliche Leute unterschiedliche Vorstellungen davon haben, was ein guter Name ist.
Kurz schlägt beschreibend
Shortcuts sollen aus dem Gedächtnis funktionieren. Kürzere Namen sind daher meist leichter zu merken, solange sie eindeutig bleiben.
/wiki statt /interne-wissensdatenbank. /ticket statt /jira-support-ticket-erstellen. /reise statt /reisekostenabrechnung-einreichen.
Im Zweifelsfall: Wie würde jemand den Link in einer Slack-Nachricht beschreiben? „Schick mir mal den Link für Reisekosten“ wird zu /reise, nicht zu /reisekostenabrechnung.
Einheitliche Sprache
Inkonsistenz macht ein Shortcut-System schwer nutzbar. Wenn manche Links auf Englisch sind (/onboarding), andere auf Deutsch (/einarbeitung), und wieder andere gemischt (/new-hire-prozess), muss jeder erst raten, welche Sprache gerade gilt.
Für die meisten Teams funktioniert eine einfache Regel: eine Sprache für alle Shortcuts. In internationalen Unternehmen ist das meistens Englisch. In einem deutschen Mittelständler kann Deutsch die bessere Wahl sein, wenn die gesamte Belegschaft Deutsch spricht.
Wichtiger als die Sprachwahl ist die Konsequenz. Eine Sprache durchhalten, auch wenn es für einzelne Begriffe umständlich wird.
Trennzeichen
/all-hands, /all_hands oder /allhands? In Lora sind das unterschiedliche Slugs. Ein Team sollte sich deshalb auf eine Schreibweise einigen und sie konsequent verwenden.
Bindestriche sind die gängigste Wahl, weil sie in URLs üblich sind und sich beim Lesen natürlich anfühlen. Unterstriche funktionieren, sehen aber in manchen Kontexten ungewohnt aus. Zusammengeschriebene Wörter funktionieren bei kurzen Begriffen (/roadmap), werden bei längeren aber unlesbar (/quarterlybusinessreview).
Kategorien statt Hierarchien
Manche Teams versuchen, ihre gesamte Organisationsstruktur in Shortcut-Namen abzubilden: /hr/recruiting/bewerbung, /it/infra/vpn, /finance/controlling/budget.
Das funktioniert selten. Erstens erinnert sich niemand an den vollständigen Pfad. Zweitens ändern sich Abteilungsnamen, und dann stimmen die Links nicht mehr.
Besser: flache Namen mit einem optionalen Präfix für den Bereich. /hr-urlaub, /hr-gehalt, /it-vpn. Oder komplett flach, wenn die Begriffe eindeutig genug sind: /urlaub, /vpn, /budget.
Duplikate vermeiden
Das Problem tritt auf, sobald mehr als ein Team Shortcuts anlegt. Marketing erstellt /analytics für Google Analytics, das Produktteam erstellt /analytics für das interne Dashboard.
Die Lösung ist entweder ein leichter Zusatz (/ga, /product-metrics) oder eine Konvention, wer welche Begriffe „besitzt“. In der Praxis hilft es, vor dem Anlegen kurz zu prüfen, ob der Name schon vergeben ist.
Abkürzungen sparsam einsetzen
/qbr spart vier Silben gegenüber /quarterly-business-review. Aber nur Leute, die wissen, was QBR heißt, werden den Link finden. Neue Mitarbeiter, die den Begriff noch nicht kennen, stehen vor einem Rätsel.
Abkürzungen funktionieren, wenn sie firmenintern etabliert sind. /jira kann in einem Entwicklungsteam verständlich sein, /qbr vielleicht nur im Leadership-Team. Mit Business oder Enterprise kannst du Aliase ergänzen, bis zu 10 pro Shortcut, zum Beispiel /qbr für /quarterly-business-review. Wähle trotzdem einen kanonischen Slug und dokumentiere ihn.
Regelmäßig aufräumen
Shortcut-Bibliotheken wachsen und veralten. Ein regelmäßiger Review hilft: Welche Links zeigen auf Seiten, die es nicht mehr gibt? Welche haben doppelte oder verwirrend ähnliche Namen? Wenn dein Plan Workspace-Analytics enthält, können Nutzungsdaten zusätzlich auf wenig verwendete Shortcuts hinweisen.
Halte den Review klein genug, um ihn zu wiederholen. Korrigiere zuerst tote Ziele und verwirrende Namen.
Checkliste
Bevor du einen neuen Shortcut anlegst, lohnen sich drei Fragen:
- Kann jemand, der den Link noch nie gesehen hat, ihn erraten?
- Gibt es schon einen ähnlichen Namen im System?
- Passen Sprache und Schreibweise zu den bestehenden Links?
Wenn alle drei Fragen mit Ja beantwortet sind, kannst du den Namen im Team testen.