{"id":5235,"date":"2025-02-28T09:46:04","date_gmt":"2025-02-28T09:46:04","guid":{"rendered":"https:\/\/frachtwerk.fw-web.space\/?p=5235"},"modified":"2025-02-28T09:46:04","modified_gmt":"2025-02-28T09:46:04","slug":"von-der-idee-zum-fertigen-produkt","status":"publish","type":"post","link":"https:\/\/frachtwerk.fw-web.space\/von-der-idee-zum-fertigen-produkt\/","title":{"rendered":"Von der Idee zum fertigen Produkt"},"content":{"rendered":"\n
Bei fast jedem neuen Projekt wird uns die Frage gestellt, wie sich der Ablauf der kommenden Wochen und Monate denn nun eigentlich gestalten wird. F\u00fcr die meisten Anwender:innen kommt ein Migrationsprojekt auch eher selten vor, weswegen die Frage nat\u00fcrlich berechtigt ist. Wie in den meisten F\u00e4llen entsteht Software selten v\u00f6llig neu auf der gr\u00fcnen Wiese. H\u00e4ufig gibt es bereits ein existierendes System, an dem jedoch mittlerweile der Zahn der Zeit nagt. So auch in diesem Fall \u2013 ein Kunde fragte uns, ob wir nicht sein Tool zur Anwesenheitsplanung \u201esanieren\u201d k\u00f6nnten. An den verwendeten Formen und Farben ist gut erkennbar, dass das Tool schon l\u00e4nger keine Pflege mehr erfahren hatte:<\/p>\n\n\n\n Aufgrund der verwendeten Technologie und der Code-Struktur war am bestehenden System nicht mehr viel zu retten, weswegen wir uns dazu entschieden haben, das Tool selber neu zu entwickeln und der \u00d6ffentlichkeit kostenlos zur Verf\u00fcgung zu stellen.<\/p>\n\n\n\n Je nach Gr\u00f6\u00dfe des Projekts findet die Konzeption in einigen wenigen kleinen Workshops bis hin zu mehrj\u00e4hrigen regelm\u00e4\u00dfigen Konzeptionsrunden statt. In diesem Fall war der Funktionsumfang \u00fcberschaubar, weswegen ein paar Runden am guten alten Whiteboard gereicht hatten, um eine neue Idee so weit zu bringen, dass sie greif- und umsetzbar wurde:<\/p>\n\n\n\n Bei allen modernen Tools \u2013 die gemeinsame Arbeit am Whiteboard ist f\u00fcr eine erste Konzeption nach wie vor der gr\u00f6\u00dfte Gewinn: Ideen k\u00f6nnen schnell skizziert werden und eine gemeinsame Visualisierung hilft, um sicherzustellen, dass alle Beteiligten von derselben Sache reden.<\/p>\n\n\n\n Je nach Projektgr\u00f6\u00dfe erfolgt anschlie\u00dfend eine Umsetzung der Skizzen als vollst\u00e4ndige Mock-Ups. Meistens verwenden wir dazu Figma. Bei gro\u00dfer Komplexit\u00e4t lassen sich hier auch ganze Klickstrecken visualisieren, um einen Eindruck der zu implementierenden Prozesse zu gewinnen.<\/p>\n\n\n\n An dieser Stelle scheiden sich nat\u00fcrlich die Geister \u2013 viele Anh\u00e4nger eines sehr strikten agilen Vorgehens w\u00fcrden anmerken, dass h\u00f6chstens Wireframes skizziert werden sollten, um den Frontend-Entwickler:innen eine gr\u00f6\u00dftm\u00f6gliche Freiheit in der Umsetzung zu lassen.<\/p>\n\n\n\n Bei der Umsetzung wiederum halten wir uns klar an agile Prozesse: Anforderungen werden als User Stories in Tickets formuliert. Diese werden seitens Product Owner mit dem Kunden diskutiert und entsprechend priorisiert. In \u2013 meistens zweiw\u00f6chentlichen \u2013 Sprints werden dann in crossfunktionalen Teams die Anforderungen sukzessive umgesetzt und direkt im Anschluss von Product Owner und Kunde getestet.<\/p>\n\n\n\n
Anhand einer unserer eigenen kleinen Produktentwicklungen \u2013 jourfixe.io<\/a> \u2013 wollen wir im folgenden einmal zeigen, wie man sich einen solchen Projektablauf vorstellen kann!<\/p>\n\n\n\n<\/a>Bedarf<\/h2>\n\n\n\n
<\/figure>\n\n\n\n
<\/a>Konzeption<\/h2>\n\n\n\n
<\/figure>\n\n\n\n
Da in den meisten von uns entwickelten Systemen die Funktionalit\u00e4t eher im Vordergrund steht und unsere Frontend-Kolleg:innen gemeinsam mit unseren Mitarbeitenden von UI\/UXl eine Bibliothek m\u00f6glicher Komponenten entworfen haben, hat sich in der Projektrealit\u00e4t gezeigt, dass uns eine m\u00f6glichst realistische Umsetzung in Figma weiter bringt \u2013 insbesondere auch, weil so die Komplexit\u00e4t in Richtung Kunde besser beherrscht werden kann.<\/p>\n\n\n\n<\/a>Umsetzung<\/h2>\n\n\n\n
<\/figure>\n\n\n\n