Je komplexer unser Produkt wurde, desto schwieriger wurde es, ein vollständiges Bild davon zu bekommen, wie alles zusammenwirkte. Und um unser Wachstumstempo aufrechtzuerhalten, mussten wir einen Weg finden, eine aktuelle Quelle der Wahrheit für alle unsere Funktionsspezifikationen aufrechtzuerhalten. In diesem Artikel wird erklärt, wie wir bisher mit Spezifikationen umgegangen sind, welche Probleme wir bei diesem Ansatz festgestellt haben und wie wir zu einem völlig neuen Ansatz gekommen sind.

Was war falsch an „Spezifikationen nach Funktion“?

Unser traditioneller Ansatz für Spezifikationen bestand darin, für jede neue Spezifikation eine eigene Seite einzurichten, auf der Produktmanager eine Liste der erwarteten Verhaltensweisen für neue und vorhandene Bildschirme zusammenstellten. Dieser Ansatz funktionierte gut, bis das Produkt komplexer wurde, insbesondere als neue Funktionen Teile vorhandener Bildschirme überschrieben.

Daher war es eine Herausforderung, genau zu verstehen, wie ein Bildschirm funktioniert und welche potenziellen Auswirkungen es an anderer Stelle in der App haben könnte, wenn ein bestimmtes Element aktualisiert wird. Die Codebasis wurde zur einzigen zuverlässigen Quelle der Wahrheit, und Produktmanager waren darauf angewiesen, dass Ingenieure wiederholt erklärten, wie sich Bildschirme verhielten. Dies unterbrach die Konzentration der Ingenieure und führte dazu, dass sie schnelle, ungefähre Antworten lieferten, was zu Nacharbeit, Verschwendung, längerer Durchlaufzeit und Frustration führte.

Bau des Prototyps

Um dieses Problem zu lösen, mussten wir einen Prototyp einer Quelle der Wahrheit für Spezifikationen und Designs entwickeln. Jeder Bildschirm sollte eine einzigartige Quelle der Wahrheit haben. Daher sollten alle auf einem Bildschirm vorgenommenen Aktualisierungen in dieser einen Quelle der Wahrheit widergespiegelt werden und nicht auf einer anderen speziellen Seite. Unsere Entwürfe waren auf Figma, also haben wir sie dort behalten. Das Schreiben von Spezifikationen neben Screenshots in Notion war tatsächlich mehr Arbeit als das direkte Schreiben von Spezifikationen in Figma. Entwickler konnten die High-Fidelity-Designs mit ihren Spezifikationen sofort in derselben Figma-Datei sehen, wobei die vorhandene Spezifikation direkt neben der vorgeschlagenen Änderung stand

Um sicherzustellen, dass unsere Spezifikationen umfassend waren, haben wir vier Schlüsselbereiche identifiziert, die bei unseren bisherigen Ansätzen in unserem neuen Prototyp nicht enthalten waren. Erstens brauchten wir Sichtbarkeit über alle Elemente eines Bildschirms, unabhängig von den Bedingungen. Zweitens mussten wir wissen, wie sich ein Element verhält, ohne die Ingenieure bitten zu müssen, die Codebasis nachzuentwickeln. Drittens mussten wir wissen, ob ein Element auf mehreren Bildschirmen gemeinsam genutzt wird, um zu vermeiden, dass eine Änderung auf einem Bildschirm zu unerwünschten Aktualisierungen auf anderen Bildschirmen führt. Und schließlich brauchten wir ein klares Bild der Bildschirmabläufe mit allen Bedingungen für die Navigation von einem Bildschirm zum anderen.

Verbesserung und Skalierung des Prototyps

Um alle unsere Designer einzubinden, mussten wir einen klaren Standard entwickeln, der auf ihre spezifischen Bedürfnisse auf einer Plattform eingeht, die sie kennen und regelmäßig nutzen. Jetzt haben wir in Figma einen „Visual Specs“-Arbeitsbereich mit Ordnern, die nach Thema und nicht nach Team geordnet sind. Jeder Bildschirm gehört allen, nicht nur einem Team. Wenn ein für einen bestimmten Bereich zuständiges Team eine Änderung vornimmt, die sich auf einen anderen Teil der App auswirkt, kann es die richtigen Bildschirme an der richtigen Stelle aktualisieren und jeder wird die Änderung automatisch sehen. Auf diese Weise ist unser aktueller Ansatz für Spezifikationen umfassender als zuvor. Jeder Themenordner verfügt über eine Seite für jede User Story.

Der Inhalt einer User Story zeigt den horizontalen Verlauf der User Journey. Vertikal haben wir alle möglichen Varianten jedes Schlüsselbildschirms (Fehlerstatus, Ladestatus, Leerstatus…). Die Spezifikationskarten sind die vollständig erschöpfenden Akzeptanzkriterien für jedes Element, in denen jedes mögliche Verhalten des Elements erläutert wird. Auf den Schlüsselbildschirmen werden die meisten Spezifikationen angezeigt, und bei den Varianten werden nur die spezifischen Spezifikationen angezeigt.

Jedes Mal, wenn wir jetzt eine neue Funktion entwickeln, erstellen wir einen neuen Zweig in Figma und fügen die neuen Spezifikationskarten in einer bestimmten Farbe neben den neuen Elementen hinzu. Sobald die Funktion abgeschlossen ist, werden diese Spezifikationskarten in ihren „Live“-Status versetzt und der Zweig mit dem Hauptzweig zusammengeführt. Dadurch bleibt alles sauber, aktuell und bereit für den Start einer neuen Funktion unter den bestmöglichen Bedingungen.

Durchführen der vollständigen Migration

Die Aktualisierung der Arbeitsweisen in einer Technologie- und Produktabteilung kann eine Herausforderung sein. Hier kam der Qonto Way ins Spiel – kontinuierliche Verbesserung ist das Herzstück unserer Kultur. Wir probieren neue Methoden mit einem Teil des Teams aus und implementieren sie, wenn sie sich als nützlich erweisen, im gesamten Team. Wenn nicht, verwerfen wir sie. Als es darum ging, unseren Spezifikationsansatz zu überarbeiten, begannen wir auf der Ebene meines Teams und ich übernahm die volle Verantwortung für die Initiative mit der Unterstützung der Teammitglieder aus Produkt/Design/Technik, die direkt an der Nutzung beteiligt sind. Idealerweise möchten Sie genügend Bildschirme und Spezifikationen zurückentwickeln, um die nächste Funktion abzudecken, an der Sie schließlich arbeiten werden (ich habe den gesamten Umfang meines Teams rückentwickelt, damit wir für jede neue Funktion bereit sind, die auf uns zukommt).

Stellen Sie sicher, dass Sie Ihre (positiven!) Erfahrungen mit dieser neuen Funktion unter Beweis stellen und scheuen Sie sich nicht, ihre Vorteile deutlich bei anderen bekannt zu machen, um die Zustimmung der Technologie- und Produktmanager zu erhalten.

Nachdem wir den Stein ins Rollen gebracht hatten, mussten wir unsere Arbeitsweise im großen Maßstab aktualisieren. Wir haben einen überprüften Satz von Standards geschrieben, die sich jeweils an ein anderes Team richten: Technik, Produkt und Design, mit einer klar umrissenen Verantwortung für jeden Stapel.

Sobald Sie diesen Schritt erreicht haben, können Sie Ihre neuen Funktionen in visuellen Spezifikationen erstellen und so das Wissen Feature für Feature konsolidieren. Den vollen Nutzen aus dieser Arbeitsweise ziehen Sie jedoch erst dann ziehen, wenn Sie jedes Verhalten im Detail festgelegt haben. Abhängig von Ihrer Situation gibt es zwei Möglichkeiten, mit der umfassenden Kartierung zu beginnen (jedes Team kann sich für den einen oder anderen Ansatz entscheiden):

• Stoppen Sie die Produktion jedes Funktionsteams für ein paar Tage und bitten Sie Ihr Technikteam und Ihre Designer, den gesamten vorhandenen Umfang nachzuentwickeln. Diese Methode hat mehrere Vorteile: Das betroffene Team erhält umfassende Domänenkenntnisse, einschließlich neuer Mitarbeiter, und Sie erhalten zu 100 % Klarheit darüber, wie alles funktioniert – keine blinden Flecken mehr.
• Retro-Engineering nur der Teile, die Sie aktualisieren möchten, bevor Sie eine neue Funktion erstellen. Dadurch wird sichergestellt, dass Ihnen nichts entgeht, und Sie können mit dem Aufbau der neuen Elemente auf der Grundlage dieser neuen Quelle der Wahrheit beginnen. Der Nachteil dieses Ansatzes besteht darin, dass Sie nie ein vollständiges Bild erhalten.

Unser neuer Spezifikationsprozess hat unsere Arbeitsweise revolutioniert und dem Codebasis-„Höhlentauchen“ ein Ende gesetzt. Durch die Schaffung einer einzigen Quelle der Wahrheit für Spezifikationen und Designs haben wir einen Arbeitsbereich geschaffen, der einfach zu verwenden ist, für alle Teammitglieder zugänglich ist und auf allen unseren Bildschirmen und User Stories genaue und aktuelle Informationen bereitstellt. Wir haben Zeit gespart, Nacharbeiten reduziert, das Onboarding neuer Mitarbeiter beschleunigt und ein umfassenderes Bild davon vermittelt, wie alles zusammenarbeitet.

Qonto ist eine Finanzlösung für KMU und Freiberufler, die 2016 von Steve Anavi und Alexandre Prot gegründet wurde. Seit unserer Einführung im Juli 2017 hat Qonto mehr als 350.000 Unternehmen die Geschäftsfinanzierung erleichtert.

Geschäftsinhaber sparen Zeit dank der optimierten Kontoeinrichtung von Qonto, einer intuitiven täglichen Benutzererfahrung mit unbegrenztem Transaktionsverlauf, Buchhaltungsexporten und einer praktischen Funktion zur Kostenverwaltung.

Sie behalten die Kontrolle und können ihren Teams gleichzeitig durch Echtzeitbenachrichtigungen und ein System zur Verwaltung von Benutzerrechten mehr Autonomie geben.

Sie profitieren von einer verbesserten Cashflow-Transparenz durch intelligente Dashboards, automatisches Tagging von Transaktionen und Tools zur Cashflow-Überwachung.

Sie genießen außerdem einen hervorragenden Kundensupport zu einem fairen und transparenten Preis.

Sind Sie daran interessiert, einem anspruchsvollen und bahnbrechenden Unternehmen beizutreten? Schauen Sie sich unsere Stellenangebote an !