Blog
“Sieht diese API-Antwort nicht anders aus als das Figma-Design?”
Es ist Freitag, kurz vor dem Release. Eine einzige Nachricht in Slack bringt das gesamte Team zum Stillstand.
Der PM hatte gewissenhaft Jira-Tickets aktualisiert. Der Designer hatte Figma-Dateien poliert. Die Ingenieure hatten PRs in vollem Tempo ausgeliefert. Jeder hatte in seinem eigenen Bereich seine beste Arbeit geleistet — und doch, in dem Moment, als alles zusammenkam, war die Fehlausrichtung unübersehbar.
Was folgt, ist vorhersehbar: freitagabendliche Slack-Archäologie. “Wo wurde diese Spec überhaupt entschieden?” “Diese API stimmt nicht mit dem ursprünglichen Ticket überein — wer hat das geändert?” Niemand hat die Antwort, weil der Kontext hinter der Entscheidung nirgendwo festgehalten wurde.
Wir sind öfter in diese “niemand ist schuld, aber alles brennt”-Hölle geraten, als uns lieb ist. Beaket wurde aus dieser Erfahrung geboren.
Specs sind dazu gemacht zu lügen
Es ist nicht so, dass Specs schlecht sind. Es ist die Struktur drumherum, die kaputt ist.
Informationen leben von Natur aus an verschiedenen Orten — PMs leben in Jira, Designer in Figma, Ingenieure in GitHub. Das ist in Ordnung. Jedes Tool ist am besten in dem, was es tut, und man sollte nicht dagegen ankämpfen.
Das Problem ist der Akt, all das in eine einzige “Source of Truth” zu kopieren.
In dem Moment, in dem man etwas in Notion oder ein Wiki überträgt, gibt es zwei Kopien. Wenn eine aktualisiert wird, wird die andere zur Lüge. Eine Spec, die nicht mehr gepflegt wird, verliert die Begründung hinter vergangenen Entscheidungen und wird zu einem Relikt, das immer weiter von der tatsächlichen Implementierung abdriftet.
Das ist kein Disziplinproblem. Es ist ein strukturelles. Solange Kopien existieren, ist Drift unvermeidlich.
Verbinden, nicht kopieren
Also haben wir den “alles zentralisieren”-Ansatz aufgegeben. Ein weiteres Wiki zu bauen hätte nur zum selben Ergebnis geführt.
Was Beaket stattdessen tut, ist Beziehungen zwischen bereits vorhandenen Informationen zu ziehen.
Man kopiert seine Figma-Designs oder GitHub-Diskussionen nicht in Beaket. Jedes Tool bleibt die Source of Truth für seinen Bereich. Beaket verbindet diese Quellen lediglich durch den Kontext von warum eine Entscheidung getroffen wurde.
Konkret strukturiert es Projektentscheidungen um drei Arten von Knoten:
- Spec — Die geschäftliche Anforderung. Was bauen wir, und warum?
- Brief — Der Design-Entscheidungsnachweis. Was wurde aus Design-Perspektive entschieden, warum, und was geht ohne es kaputt.
- ADR — Der technische Entscheidungsnachweis. Warum dieser Ansatz? Welche Alternativen wurden in Betracht gezogen und verworfen?
Diese drei verbinden sich untereinander durch Kanten und bilden einen Entscheidungsgraphen. Man schreibt keine detaillierten Spezifikationen in Beaket. Man hält fest, was entschieden wurde, warum, und womit es verbunden ist — nicht mehr.
Die “Weniger schreiben”-Regel
Ehrlich gesagt war dies der am meisten diskutierte Aspekt des Produkts.
“Sollten wir den Leuten nicht erlauben, mehr Details zu schreiben?” Natürlich kam das auf. Aber in dem Moment, in dem man detailliertes Schreiben erlaubt, hat man ein weiteres Wiki gebaut. Und Wikis verrotten immer.
Also haben wir bewusst eine Einschränkung in Beaket eingebaut: weniger schreiben.
Die Heuristik ist einfach — würde Ihr zukünftiges Ich in sechs Monaten nach der Begründung suchen? Wenn ja, schreiben Sie es auf. Wenn nein, lassen Sie es. Parameterlisten und Implementierungsschritte gehören nach GitHub. Beaket hält nur die minimale Einheit des Warum.
Das ist ein bewusster Kompromiss. Beaket wird niemals ein umfassendes Design-Dokumentations-Tool sein. Das ist beabsichtigt.
Der Ready Flag: Ein Handschlag, keine Genehmigung
Es gibt noch einen Mechanismus, den wir gerne gebaut haben.
Nachdem eine Spec geschrieben wurde, setzen sowohl der Designer als auch der Ingenieur unabhängig voneinander einen Ready Flag. Der Designer signalisiert “Ich verstehe die Anforderungen aus UI-Perspektive.” Der Ingenieur signalisiert “Ich verstehe sie aus technischer Perspektive.” Erst wenn beide Flags gesetzt sind, wird die Spec “Ready.”
Das ist kein Genehmigungsworkflow. Es ist ein Handschlag.
Nicht “Ich habe es gelesen”, sondern “aus meiner Perspektive können wir loslegen.” Es ist eine strukturelle Absicherung dagegen, mit der Implementierung auf Basis mehrdeutiger Anforderungen zu beginnen.
Und wenn eine Spec geändert wird, nachdem sie als Ready markiert wurde, wird der Wirkungsradius — jeder verbundene Brief und ADR — automatisch sichtbar gemacht. Kein Durchsuchen der Slack-Historie mehr.
Der Entscheidungspfad
Beaket verfolgt die Änderungshistorie über wer hat was wann geändert hinaus. Es erfasst auch warum.
Wählen Sie einen beliebigen Text aus, und Sie können nachverfolgen, wann er geändert wurde, von wem und aus welchem Grund. Wir nennen das den Decision Trail.
Es ist kein spektakuläres Feature. Aber in sechs Monaten, wenn jemand fragt “warum ist diese Spec so, wie sie ist?” — steht die Antwort direkt dort. Allein das verändert, wie schnell ein Team Entscheidungen treffen kann.
Was wir noch nicht wissen
Wir glauben nicht, dass Beaket für jedes Team die richtige Lösung ist.
Für ein kleines Team, das im selben Raum sitzt und Kontext natürlich geteilt wird, könnte es überdimensioniert sein. Für Organisationen mit Hunderten von Mitarbeitern haben wir noch nicht genug validiert.
Wovon wir überzeugt sind, ist Folgendes: Den Kontext hinter Entscheidungen zu verlieren, hat immer seinen Preis. Und dieser Preis wächst exponentiell, wenn Teams skalieren und die Zeit vergeht.
Beaket ist ein Tool, um diesen Preis strukturell in Schach zu halten. Es ist kein Allheilmittel. Es ist eher wie eine Versicherung.
Wenn Ihr Team jemals in einer Situation war, in der niemand erklären kann, warum eine Design-Entscheidung getroffen wurde — beginnen Sie damit, nur eine einzige Entscheidung zu verbinden. Sehen Sie, wohin es Sie führt.