Hausverwaltungssoftware: Von der Spezifikation mit Hunderten Punkten zum Sprintplan

Auf dem Tisch liegt eine technische Spezifikation mit Hunderten von Punkten. Vom Anfragenmanagement bis zur Hausgeld-Sollstellung, von der Besucherregistrierung bis zur Kennzeichenerkennung, vom KI-Assistenten bis zum Katastrophen- und Notfallmanagement: 13 Hauptabschnitte und Dutzende Unteranforderungen. Alles ist wichtig, alles soll eines Tages live gehen. In einem Projekt, das mit einem solchen Dokument startet, gibt es zwei Fallen: alles gleichzeitig zu versuchen oder in der Priorisierungsdiskussion Monate zu verlieren.

Bei der Hausverwaltungssoftware war unsere erste Aufgabe nicht, Code zu schreiben, sondern dieses Dokument in einen ausführbaren Plan zu übersetzen.

Das Projekt in Kürze

Die Hausverwaltungssoftware ist eine operative Plattform, die wir für einen Kunden entwickelt haben, der zahlreiche ganz unterschiedliche Wohnanlagen unter einem gemeinsamen Unternehmensdach verwaltet. Sie besteht aus einem webbasierten Verwaltungspanel sowie mobilen Apps für Bewohner, Außendienst und Verwalter. Die Module für Anfragen und Beschwerden, Störung, Wartung und Arbeitsauftrag, Hausgeld und Finanzen, Reservierung von Gemeinschaftsflächen, Besucher, Pakete, Ankündigungen, Inventar und Zähler arbeiten auf demselben Datenrückgrat. Externe Systeme wie ERP und Buchhaltung, Bank-POS, E-Rechnung, SMS, IoT-Zähler und Kennzeichenerkennung werden über eine separate Integrationsschicht angebunden.

Vom Spezifikationspunkt zum Abnahmekriterium

Im ersten Schritt haben wir die Spezifikation in acht Kernmodulgruppen gegliedert: Identität und Berechtigung; Wohnanlage, Gebäude und bauliche Struktur; Anfragen und Beschwerden; Besucher und Gäste; Bewohnerservices; Kommunikation und Benachrichtigung; Grundlagen für Mobil und Panel; technische Infrastruktur und Sicherheit. Dann haben wir jede Gruppe in Untermodule unterteilt und für jedes Untermodul ein Dokument nach demselben Muster verfasst:

• Zu welchem Spezifikationspunkt es gehört und in welcher Phase es liegt,
• Geschäftsregeln, Hauptszenarien und Ausnahmen,
• Datenfelder, Bildschirmanforderungen und Abhängigkeiten,
• Abnahmekriterien, offene Punkte und Annahmen.

Diese Dokumente wurden zu sprintbasierten Arbeitspaketen. Jeder Spezifikationspunkt wurde mit einem Moduldokument und jedes Modul mit einem Sprint-Paket verknüpft, und die Abnahmeprüfungen erfolgten entlang dieser Kette. Die Antwort auf die Frage, warum ein Bildschirm existiert oder woher eine Regel stammt, war immer eine Punktnummer.

Auch die Sprint-Reihenfolge der ersten Phase spiegelte diese Logik wider: zuerst die technische Grundlage und das Identitätsmodell, danach das Rückgrat der baulichen Struktur, die Anmeldeoberflächen für Panel und Mobil, der Anfrageablauf und die Benachrichtigungen, Besucher- und Bewohnerservices; ganz am Ende die Härtung der Sicherheits-, Audit- und Berechtigungsschicht sowie die Abnahmevorbereitung.

Jede Phase für die nächste bereit hinterlassen

Wir haben einen dreiphasigen Plan aufgestellt. In der ersten Phase gingen Identität, Berechtigungen, bauliche Struktur, Anfragen und Bewohnerservices in Betrieb; in der zweiten kamen Finanzen, Hausgeld, Wartung, Reservierung und der mobile Außendienst hinzu; in der dritten wurde die Plattform mit weiterführenden Modulen wie IoT, Zutrittskontrolle, Personal- und Schichtverwaltung und einem KI-Assistenten vervollständigt. Jede Phase ging mit eigenen Abnahmekriterien in Betrieb, und die nächste wurde auf demselben Rückgrat aufgebaut.

Einer der nützlichsten Teile des Plans war die Liste „phasenexterne, aber abhängige Bereiche“ im Dokument jeder Phase. In der ersten Phase wurden hardwareabhängige Zugangssysteme, der vollständige Ablauf der Finanzintegrationen oder Zählerdaten nicht geliefert; Datenmodell und Architektur wurden jedoch unter Berücksichtigung dieser Bereiche aufgebaut. Als in der dritten Phase die Kennzeichenerkennung kam, war die Grundlage, die Fahrzeugdaten mit der baulichen Struktur verknüpft, schon seit der ersten Phase vorhanden.

Dieselbe Logik haben wir auf externe Systeme angewendet. Bank, E-Rechnung, ERP, Kennzeichenerkennung und Zählergeräte gingen zu unterschiedlichen Terminen in Betrieb. Da wir die Integrationen über eine separate Adapterschicht angebunden haben, die die Geschäftsregeln nicht berührt, hielt die Verzögerung einer Integration das Produkt nicht auf. API-Schlüssel und Dienststatus werden ebenfalls über das Panel verwaltet; jede Verbindung wie Bank oder ERP hat ihren eigenen Schlüssel, und in welchen Wohnanlagen und welchen Bereichen er verwendet wird, steht im Datensatz.

Sicherheit von Grund auf, Unterscheidungen schriftlich

Rollen-Berechtigungs-Matrix, Audit-Protokolle, die Einwilligungsverwaltung nach KVKK (türkisches Datenschutzgesetz) und die API-Schlüsselverwaltung wurden nicht auf später verschoben; sie gingen als Teil der ersten Phase in Betrieb. Den Nutzen, die Geschäftsregeln in den Dokumenten so detailliert zu beschreiben, sahen wir am deutlichsten im Berechtigungsdesign. Dieselbe Person kann in einer Wohnanlage Eigentümer und in einer anderen Mieter oder Berater sein. Deshalb wurde der Benutzer als ein einziger Datensatz geführt; die Berechtigungen werden rollenbasiert über die Zuordnung zur Wohnanlage vergeben. Auch Anfrageteams und Auftragsteams wurden unabhängig voneinander definiert.

Eine Unterscheidung, die ins Dokument aufgenommen wurde, hat eine künftige Lücke von vornherein geschlossen: Datensatztyp und Anwendungsrolle sind nicht dasselbe. Wer im Erfassungsformular das Label „Berater“ wählt, erhält dadurch keine Berechtigung für eine Wohnanlage; die Berechtigung wird erst durch die Rolle freigeschaltet, die der Zuordnung zur Wohnanlage hinzugefügt wird. Risiken wie das stille Freischalten von Rechten durch ein Label werden erst sichtbar, wenn eine solche Unterscheidung schriftlich festgehalten wird.

Was wir in der Praxis gelernt haben

• Verkleinern Sie die Spezifikation nicht, machen Sie sie nachverfolgbar. Jeden Punkt an ein Dokument und ein Sprint-Paket zu binden, statt den Umfang zu reduzieren, machte aus der Priorisierung keine Diskussion mehr.
• Das Abnahmekriterium wird am Anfang der Arbeit geschrieben. Von Beginn an zu wissen, was wann als fertig gilt, machte es möglich, die Phasen jeweils mit eigener Abnahme in Betrieb zu nehmen.
• Entwerfen Sie heute auch die Arbeit, die heute nicht gemacht wird. Phasenexterne, aber abhängige Bereiche im Datenmodell zu berücksichtigen, sorgte dafür, dass spätere Phasen auf demselben Rückgrat aufgebaut wurden.
• Der Integrationskalender darf nicht der Produktkalender sein. Die Adapterschicht verwandelte die Verzögerung externer Systeme nicht in eine Verzögerung des Produkts.

Eine große Spezifikation ist kein Hindernis, sondern die detaillierteste Roadmap, wenn man sie gut liest. Es genügt, dass jeder Punkt eine Phase, ein Dokument und ein Abnahmekriterium hat.

Wie könnte aus Ihrer Spezifikation ein Plan werden?

Wenn Sie mit einer umfangreichen Spezifikation starten wollen oder nicht wissen, wo Sie bei Ihren Anforderungen anfangen sollen, können wir ab der Planungsphase zusammenarbeiten. Auf der Projektseite der Hausverwaltungssoftware können Sie die Module ansehen; über unsere Kontaktseite können Sie ein Gespräch mit uns vereinbaren.