WAS ES MACHT
Vom ersten Satz bis zur gelieferten Funktion.
angajuu ist der Ort, an dem aus dem, was ein Kunde sagt, etwas wird, aus dem ein Team oder ein Agent bauen kann. Diese Seite geht den Weg ab, den du im Werkzeug selbst gehst — Station für Station, mit dem, was dort wirklich passiert.
DAS MODELL
Zwei Arten von Anforderung, und die Verbindung dazwischen.
Was ein Kunde sagt und was dein Produkt kann, sind zwei verschiedene Dinge. Die meisten Werkzeuge kennen nur eins davon und verlieren das andere unterwegs.
angajuu hält beide getrennt und verbindet sie ausdrücklich. Deshalb kannst du später fragen, woher ein Satz kam — und ob aus ihm etwas geworden ist.
KUNDENANFORDERUNG
„Wir brauchen eine Rechnung je Quartal, nicht je Beleg.“
verknüpft
PRODUKTANFORDERUNG
Sammelrechnung je Abrechnungszeitraum
Im Einzelnen
- angajuu kennt zwei Arten von Anforderung: die Kundenanforderung und die Produktanforderung. Beide sind Ausprägungen derselben Grundform — eine Tabelle, zwei Gestalten.
- Eine Kundenanforderung gehört immer zu einem Projekt, eine Produktanforderung immer zu einem Produkt. Ohne dieses Zuhause gibt es sie nicht.
- Verbunden werden die beiden durch eine ausdrückliche Verknüpfung, die ein Mensch bestätigt oder verwirft. Festgehalten wird, wer bestätigt hat — und ob der Vorschlag von einem Menschen oder von der KI kam.
- Jede Verknüpfung sagt auch, wie viel sie abdeckt: voll (100), teilweise (50) oder peripher (20), pro Anforderung gedeckelt bei 100.
- In die Abdeckung zählen nur bestätigte Verknüpfungen. Was vorgeschlagen oder verworfen ist, zählt in keine Abdeckung mit.
- Für jede Kundenanforderung weist angajuu aus, wie viele Verknüpfungen sie hat, wie viele davon bestätigt, vorgeschlagen und verworfen sind, und welche Abdeckung daraus folgt.
ERFASSEN
Dein Material kommt herein, wie es ist.
Tabelle, Ticket, Seite, Dokument, Repository. Du sortierst nichts vor und schreibst nichts ab. Was du hast, kommt so herein, wie es bei dir liegt.
Und du siehst, was ankommt, bevor etwas ankommt. Ein Import, der dich überrascht, ist ein Import, den du zurücknehmen musst — also überrascht dich dieser nicht.
| DEINE DATEI | ANGAJUU |
|---|---|
| Spalte C | Titel |
| Spalte E | Quelle |
| Spalte F | — |
| Probelauf · 142 gelesen · 3 Warnungen | |
Im Einzelnen
- Anforderungen kommen aus Excel- und CSV-Tabellen, aus PDF und JSON, aus Jira, aus Confluence und aus einem Scan deines Git-Repositorys.
- Die Spaltenzuordnung füllt angajuu vor, indem es deine Überschriften mit englischen und deutschen Feldnamen abgleicht. Übersetzt wird dabei nichts — eine Überschrift trifft nur ein Feld der Sprache, in der sie geschrieben ist.
- Spalten, die du nicht zuordnest, wirft angajuu nicht weg — sie bleiben an der Anforderung hängen, abgelegt unter ihrer ursprünglichen Überschrift.
- Der Import aus Excel und CSV über die Spaltenzuordnung kommt ganz ohne KI aus. Und das bleibt so: ein Test bricht den Bauprozess ab, sobald jemand diesem Weg eine KI-Abhängigkeit einbaut.
- Bei der Spaltenzuordnung zeigt dir angajuu vor dem Schreiben den Probelauf: wie viele Zeilen angelegt, aktualisiert und übersprungen würden, welche Felder sich je Zeile ändern und jede Warnung dazu.
- Importierst du dieselbe Tabelle noch einmal, aktualisiert angajuu die Zeilen, die es schon kennt, statt sie zu verdoppeln — erkannt an einer Kennung, die du als Spalte benennst. Gesucht wird sie in deiner ganzen Organisation, nicht nur im Zielprojekt. Gelöscht wird dabei nie.
- Was die KI aus deinem Material herausliest, landet zuerst als offener Eintrag in einer Prüfliste. Jeden Eintrag bestätigst du, verwirfst ihn, führst ihn zusammen oder verknüpfst ihn — und erst das Bestätigen legt eine Anforderung an.
VERFEINERN
Aus dem rohen Satz wird ein Auftrag.
Was hereinkam, ist noch niemandes Auftrag. Im Verfeinern nimmst du dir einen Satz nach dem anderen vor, bis er trägt — und du bist dabei nicht allein.
Nichts geht weiter, nur weil es alt ist. Es geht weiter, weil jemand es angesehen und entschieden hat.
WARTESCHLANGE
Die Sätze, die du dir vorgenommen hast.
DER SATZ
Titel, Beschreibung, Quelle, Priorität — beide Sprachen.
ENTSCHEIDUNG
Bestätigen, ablehnen, überspringen. Dazu juujuus Hinweise.
Im Einzelnen
- Jede Kundenanforderung, die im Entwurf steht oder in Prüfung ist, sammelt sich in einer einzigen Warteschlange. Die Zahl daneben in der Seitenleiste zählt genau diese beiden Zustände und wird neu geholt, sobald ein Bildschirm etwas an der Warteschlange geändert hat.
- Der Verfeinern-Bildschirm legt fünf Reiter nebeneinander: die Anforderung selbst, ihre Abdeckung, Konflikte, die jemand erklärt hat, die Quelle und den Verlauf. Abdeckung, Konflikte und Verlauf tragen ihre Zahl schon neben dem Reiternamen.
- Eine Anforderung, die aus einem Import stammt, trägt eine Marke mit ihrer Herkunft und führt von dort zurück in die Import-Sitzung. Kam sie über die Spaltenzuordnung herein, steht darin, was der Import geschrieben hat: Datei, Blatt und Zeilennummer.
- Jeden Satz bestätigst du, lehnst ihn mit geschriebener Begründung ab oder überspringst ihn. Eine leere Begründung nimmt angajuu nicht an; das Überspringen schreibt nichts und rückt nur in deiner Sitzung eine Stelle weiter. Das Bestätigen setzt den Satz von Entwurf auf In Prüfung.
- Aus dem Entwurf in die Prüfung kommt ein Satz erst mit Titel, mit einer Beschreibung von mindestens 50 Zeichen, mit einer benannten Quelle und — wenn es eine Kundenanforderung ist — mit einem Projekt. Geprüft wird das an genau diesem einen Übergang.
- Was juujuu an einem Satz ändern würde, schreibt es nicht selbst. Seine Vorschläge betreffen Titel und Beschreibung, je Sprache, und stehen Wort für Wort gegenübergestellt — geschrieben wird ein Feld erst, wenn du es abhakst.
- juujuus Hinweise erscheinen erst, wenn in deiner Organisation ein Claude-Schlüssel hinterlegt ist. Ohne ihn bleibt der Bereich leer.
PLANEN
Was zuerst, und wofür.
Anforderungen ohne Reihenfolge sind eine Liste, keine Planung. Hier bekommen sie einen Platz: ein Produkt, ein Release, ein Zeitpunkt.
Und du siehst, wonach am häufigsten gefragt wurde — nicht als Meinung, sondern gerechnet aus dem, was deine Kunden dir gesagt haben.
| RELEASE | STAND | NACHFRAGE |
|---|---|---|
| 2026.09 · Faktura | geplant | hoch |
| 2026.10 · Portal | offen | mittel |
| 2026.08 · Import | geliefert | — |
Im Einzelnen
- Ein Release ist eine datierte Zusage für genau ein Produkt: ein Zieltermin, wahlweise eine erklärte Kapazität in Punkten, und ein Weg, der nur vorwärts führt — Entwurf, zugesagt, in Umsetzung, geliefert. Zurück geht keiner dieser Schritte; abbrechen kannst du, solange nichts geliefert ist.
- Ein Meilenstein ist ein Termin in einem Kundenprojekt, und ein Release kann Meilensteine in mehreren Projekten zugleich bedienen — genau die Dopplung, die du sonst von Hand pflegst. Ob ein Meilenstein geplant, gefährdet, gerissen oder erfüllt ist, rechnet angajuu bei jedem Lesen neu und speichert es nirgends.
- Geschätzt wird mit einem einzigen Feld je Produktanforderung: XS bis XL, das sind 1, 2, 3, 5 und 8 Punkte. Was ungeschätzt ist, zählt null Punkte — und wie viele das sind, steht auf dem Planungsbrett neben den Punkten, damit eine Spalte nicht deshalb leer wirkt, weil niemand geschätzt hat.
- Wie laut nach einer Produktanforderung gefragt wird, rechnet angajuu aus: je bestätigter Verknüpfung die Priorität der fragenden Kundenanforderung — kritisch 8, hoch 5, mittel 3, niedrig 1 — mal dem Anteil, der noch nicht abgedeckt ist. Die Summe wird mit einem Breitenfaktor gewichtet: drei Projekte, die dasselbe benötigen, wiegen schwerer als ein Projekt, das laut ruft. Gezählt werden Projekte, nie Kunden.
- Jede dieser Zahlen lässt sich aufklappen: angajuu zeigt Punktzahl, Basis und Breite und darunter jede einzelne Anfrage mit ihrer Priorität, ihrer Abdeckung und ihrem Beitrag. Anfragen aus Projekten, die du nicht lesen darfst, stehen als eine gemeinsame Zeile darin — mitgezählt, aber nicht aufgeschlüsselt.
- Wo die ungeplante Arbeit hinginge, schlägt angajuu auf Knopfdruck vor: frühester Termin zuerst, bei Gleichstand die höhere Nachfrage, und nur in Releases, die früh genug liegen und noch Kapazität haben. Das ist gerechnet, nicht geraten — kein Sprachmodell ordnet hier etwas an; juujuu darf höchstens einen Satz dazuschreiben, warum sich etwas nirgends unterbringen ließ. Geschrieben wird davon nichts: ob der Vorschlag Wirklichkeit wird, entscheidest du.
- Fragen zwei Kundenanforderungen aus verschiedenen Projekten nach demselben, findet angajuu sie — ab 75 % semantischer Ähnlichkeit und nur über Projektgrenzen hinweg, denn was innerhalb eines Projekts doppelt steht, ist keine Synergie. Aus so einer Gruppe machst du eine Produktanforderung; Titel und Produkt gibst du dabei an, und die Verknüpfungen zu den Mitgliedern entstehen als Vorschlag, nicht als Tatsache.
LIEFERN
Aus dem Satz wird ein Ticket, und du behältst den Faden.
Gebaut wird da, wo dein Team ohnehin arbeitet. angajuu schickt die Anforderung hinüber und verliert sie dabei nicht aus dem Blick.
Was drüben passiert, kommt zurück in deine Ansicht — damit „ist das schon drin?“ eine Frage mit Antwort ist.
| ANFORDERUNG | TICKET | STAND |
|---|---|---|
| Sammelrechnung je Zeitraum | FAK-218 | in Arbeit |
| Beleg-Export CSV | FAK-224 | fertig |
| Mandantenwechsel | — | nicht übergeben |
Im Einzelnen
- Eine Anforderung schickst du als Vorgang nach Jira: eine Produktanforderung wird dort ein Epic, eine Kundenanforderung eine Story, die Priorität wird auf Jiras Leiter übersetzt, und der Schlüssel des neuen Vorgangs steht danach an der Anforderung. Auslösen kannst du das an der Anforderung selbst — für mehrere Produktanforderungen auf einmal auch aus der Liste heraus.
- Sagst du ein Release zu, legt angajuu in Jira die passende Version an oder bringt sie auf Stand und stempelt sie auf jeden Vorgang, der aus dem Umfang dieses Releases schon hinübergeschickt wurde. Das gilt für eigene Produkte mit hinterlegtem Jira-Projekt; scheitert ein einzelner Vorgang, wird das vermerkt und der Rest läuft weiter.
- Der Statusabgleich mit Jira liest nur: er holt die Vorgänge und fragt nach, ob Jira die Version des Releases schon veröffentlicht hat, und schreibt nichts zurück. Das gilt für diesen Abgleich — nicht für angajuu insgesamt: beim Übergeben einer Anforderung und beim Zusagen eines Releases schreibt angajuu sehr wohl nach Jira.
- Welcher Jira-Status bei euch „fertig“ heißt, hängt am Produkt und steht dort in der Schreibweise eures Boards, sobald ihr sie hinterlegt; vorgegeben sind die englischen Standardbegriffe. Ein Status, den niemand zugeordnet hat, wird als in Arbeit behandelt und höchstens einmal je Lauf im Sync-Protokoll festgehalten, statt stillschweigend gedeutet zu werden.
- An dem Umsetzungsstand, den ein Mensch auf „geprüft“ gesetzt hat, ändert kein Abgleich mehr etwas: er stuft ihn nicht zurück und setzt „geprüft“ auch nie selbst. Aus Jira zurück kommen nur geplant, in Arbeit und umgesetzt.
- Von selbst setzt angajuu eine Kundenanforderung erst dann auf „geliefert“, wenn sie mindestens eine bestätigte Verknüpfung hat, vollständig abgedeckt ist und jede dieser Verknüpfungen umgesetzt oder geprüft ist. Das ist der automatische Weg. Von Hand kann jemand sie aus „in Arbeit“ trotzdem auf „geliefert“ setzen, und ein Import kann den Status direkt schreiben.
- Vier Dinge aus diesem Abschnitt haben heute keinen eigenen Bildschirm: den Abgleich anstoßen, der Bericht über die Abweichung zwischen Plan und Jira, die Status-Zuordnung je Produkt und die Burn-downs. Das läuft im Hintergrund oder über die Schnittstelle — ansehen kannst du es in angajuu nicht.
BERICHTE
Was ist abgedeckt, und was ist offen.
Am Ende zählt eine Frage: Ist aus dem, was wir versprochen haben, etwas geworden? angajuu beantwortet sie, ohne dass jemand vorher eine Tabelle pflegt.
Und wo nichts da ist, steht das auch da. Eine Lücke, die man sieht, ist eine Lücke, über die man reden kann.
| KUNDENANFORDERUNG | ABGEDECKT DURCH | STAND |
|---|---|---|
| Rechnung je Quartal | Sammelrechnung | abgedeckt |
| Belege einzeln prüfen | Beleg-Export | teilweise |
| Mandantenwechsel | — | Lücke |
Im Einzelnen
- Auf dem Berichte-Bildschirm steht eine Abdeckungsmatrix: eine Zeile je Kundenanforderung, eine Spalte je Produkt, in jeder Zelle ein Prozentwert. Die Zeilensumme rechnet über alle bestätigten Verknüpfungen dieser Anforderung, unabhängig vom Produkt; die Spaltensumme ist der Mittelwert der Zellen dieser Spalte. Eine Zelle ohne Verknüpfung bleibt nicht leer — sie zeigt 0 % und ist als Lücke gekennzeichnet.
- Anforderungen kannst du ineinander schachteln. Die Abdeckung einer Gruppe ist dann der Mittelwert ihrer direkten Kinder; Verknüpfungen, die an der Gruppe selbst hängen, zählen dafür bewusst nicht mit. Der Abdeckungsbaum im Bericht zeigt die Kundenanforderungen genau so verschachtelt — je Zeile ihr Zustand, abgedeckt, teilweise, vorgeschlagen oder offen, und daneben ein Bruch: bestätigte Verknüpfungen über bestätigte plus vorgeschlagene. Abgelehnte stehen in keinem der beiden Werte.
- Der Lückenbericht listet jede Kundenanforderung, zu der es keine einzige bestätigte Verknüpfung gibt, und zählt sie nach Priorität — kritisch, hoch, mittel, niedrig. Einschränken kannst du ihn auf ein Projekt und auf eine Priorität; sobald er erzeugt ist, stehen daneben die Schaltflächen für den Export als PDF und als Excel-Datei.
- Den Abdeckungsgrad liest du am Bildschirm ab, nicht aus einer Datei. Der Abdeckungsbericht trägt trotz seines Namens keinen einzigen Prozentwert — er führt Titel, Art, Priorität und Status —, der Lückenbericht ebenso wenig, und die Abdeckungsmatrix, in der die Prozentwerte stehen, hat gar keine Schaltfläche zum Exportieren.
- Die Startseite ist ein Cockpit: vier Kacheln, jede mit einer Zahl und einer Dringlichkeit — gefährdete Releases, Meilensteine der nächsten 30 Tage, ungeplante Nachfrage und die Warteschlange zum Verfeinern. Ein Klick auf eine Kachel führt auf die Liste dahinter. Darunter stehen die Zeilen, die Aufmerksamkeit brauchen, und je Produkt ein Balken aus abgedeckt, teilweise und Lücke.
- Je Projekt schreibt angajuu ein Product Requirements Document: Einleitung, Umfang und Ziele als Prosa, die Anforderungen nach Gruppen sortiert, dazu Abnahme-Checklisten in beiden Sprachen. Jede neue Fassung bekommt die nächste Nummer für dieses Projekt, und exportieren kannst du sie als PDF oder als Markdown. Voraussetzung ist ein hinterlegter Claude-Schlüssel — fehlt er, bricht die Erzeugung mit einer Fehlermeldung ab und es wird nichts gespeichert.
- Unter jeder Kundenanforderung nennt das Dokument die Produktanforderungen, deren Verknüpfung dorthin bestätigt ist — mit Titel, nicht als Prozentwert.
IMMER DABEI
Was an jeder Station gilt.
- Die Bibliothek Neben dem Weg durch die Stationen liegt die Bibliothek: Produkte, Projekte, Kunden und Anforderungen, jedes als eigene Liste in der Seitenleiste. Seitenleiste, Kommandopalette und Tastenkürzel lesen dieselbe Registratur — die Kürzel selbst führen zu den Stationen des Wegs, nicht in die Bibliothek.
- Die Kommandopalette Strg-K, auf dem Mac Cmd-K, öffnet eine Palette über allem — sie durchsucht deine Daten, führt die Aktionen des Bildschirms aus, auf dem du gerade stehst, springt zu den Zielen aus der Navigation und zeigt, wo du zuletzt warst. Das einzige Kürzel, das auch aus einem Eingabefeld heraus greift.
- Was du sehen darfst Listen zeigen dir, was du sehen darfst, statt die ganze Seite zu verweigern: eine Zeile, die nicht für dich ist, fehlt einfach. Abgewiesen wirst du nur, wenn du eine einzelne Sache direkt aufrufst. Das gilt auch für Auswertungen — wer genau ein Projekt liest, sieht keine einzige Synergie, denn dafür braucht es zwei.
- Rollen und Zuschnitt Vier Rollen in der Organisation, dazu Zuschnitte je Produkt und je Projekt. Der Zuschnitt wirkt bei Mitgliedern: Ein Mitglied liest die Produkte, die ihm gehören, die Projekte, die es leitet, und die Produkte, die in diesen Projekten stecken. Verwaltung, Produktleitung und reine Lesekonten lesen ohnehin die ganze Organisation — Schreibrechte folgen daraus nicht.
- Getrennte Organisationen Die Daten einer Organisation liegen nicht offen neben denen der nächsten: Auf den mandantengebundenen Tabellen hängt ein globaler Abfragefilter, und zusätzlich wird jede Anfrage, die zu einer Organisation gehört, gegen genau diese geprüft. Beides zusammen, nicht eines statt des anderen.
- Deine eigenen Zugänge Die Zugänge zu Jira und Confluence, zu GitHub und zu Claude hinterlegst du selbst — verschlüsselt mit AES-256-GCM, jeder Datensatz mit eigenem Salz und eigenem Nonce, wahlweise für die ganze Organisation oder nur für dich. Dazu merkt sich angajuu, wann ein Zugang zuletzt geprüft wurde.
- Wohin dein Text geht Für die Claude-Funktionen verlässt der Text deiner Anforderung die Installation und geht an die Schnittstelle von Anthropic. Die Ähnlichkeitssuche darunter — Dubletten beim Import, Vorschläge beim Verfeinern, Synergien — läuft nicht dort, sondern auf einem Einbettungsdienst, den die mitgelieferte Installation selbst betreibt. Das gilt für den Weg deines Textes, nicht für den Ort, an dem angajuu läuft: Der EU-Hinweis im Seitenfuß gehört zu dieser Website, nicht zur Anwendung.
- Ohne Claude-Schlüssel Fehlt der Schlüssel, brechen die KI-Funktionen nicht zusammen — aber jede gibt anders nach. Die Hinweise beim Verfeinern verschwinden wortlos, der Terminvorschlag behält seine Konflikte und lässt nur die Begründung dazu weg, und das Product Requirements Document bricht mit einer Fehlermeldung ab. Eine gemeinsame Regel dafür gibt es nicht.
- Zwei Sprachen Die Oberfläche gibt es auf Deutsch und auf Englisch, und du wählst selbst, in welcher du arbeitest. Triffst du keine Wahl, entscheidet die Sprache des Browsers, und im Zweifel steht Englisch.
- Gespeicherte Ansichten Jede der sechs Listen — Anforderungen, Projekte, Produkte, Kunden, Importe, Releases — merkt sich Ansichten, die du selbst speicherst: für dich allein oder für die ganze Organisation. Anforderungen und Importe bringen zusätzlich ein paar mitgelieferte mit, die niemand ändern oder löschen kann. Mehrere Zeilen auf einmal änderst du auf der Anforderungsliste: bei Produktanforderungen Status, Größe, Release und die Übergabe an Jira, bei Kundenanforderungen Priorität und Wunschtermin.
Keine Zeiterfassung, keine Sprints, keine Tickets, die hier abgearbeitet werden: angajuu ist der Ort, an dem steht, was gebaut werden soll — nicht der Ort, an dem gebaut wird.
Schreib den ersten Satz.
Du hast gesehen, wie es funktioniert — jetzt fragst du deinen Zugang an.