Ein besserer Workflow für die Webentwicklung: Confluence, Airtable und mehr

Ich arbeite seit fast zwei Jahren als Front-End-Entwickler und habe hilfreiche Erfahrungen aus mehreren Webentwicklungsprojekten von Design- / Digitalagenturen gesammelt.

Eine offensichtliche, aber wertvolle Lektion, die ich gelernt habe, ist, dass die Zusammenarbeit zwischen den einzelnen Gruppen mit einem Ziel, aber unterschiedlichen Verantwortlichkeiten und Zwecken nicht einfach ist. Es gibt verschiedene Aspekte und Schwierigkeitsgrade in Bezug auf die Zusammenarbeit, und der spezifische Teil, auf den ich hier eingehen möchte, ist der Workflow-Prozess.

Basierend auf meiner Erfahrung und mit Hilfe meiner Designer- und Entwicklerfreunde habe ich einen Workflow für die Website-Entwicklung erstellt, der für kleine Teams (5 bis 15 Personen) konzipiert ist. Das System besteht aus Confluence, Jira, Airtable und Abstract. In diesem Artikel werde ich das Warum und Wie dieses Workflows erläutern.

Motivation zum Aufbau eines neuen Workflows

Um eine angepasste Website ohne Verwendung von Vorlagen bereitzustellen, die von Website-Erstellern bereitgestellt werden, gehören zu den Mindestanforderungen an Talente ein Designer, Entwickler und Projektmanager. Nachdem ich an einigen Fällen teilgenommen hatte, hatte ich das Gefühl, dass etwas mit unserem Workflow nicht stimmte: Wichtige Informationen wurden immer nicht sowohl intern zwischen verschiedenen Rollen als auch extern für den Kunden abgeglichen. Diese ineffiziente Kommunikation verlangsamte den Entwicklungszyklus deutlich und verletzte das Team.

Also fing ich an, dieses Problem zu lösen.

Ich habe bei Google nach Ressourcen zum Einrichten und Verbessern eines Workflows gesucht. Obwohl ich aus all den großartigen Ressourcen viel gelernt habe, fand ich fast keine davon für Webentwicklungsprojekte in einer Design- / Digitalagentur. Es handelte sich entweder um ein Designsystem oder um Codierungsrichtlinien, die sich auf Design- oder Front-End-Rollen bezogen, oder um einen Workflow, der für ein Team mit einem eigenen Produkt erstellt wurde.

Aus diesem Grund habe ich mich entschlossen, die Teile auszuwählen, die ich zur Lösung unserer Probleme benötigte, und einen benutzerdefinierten Workflow für die Website-Entwicklung erstellt.

Probleme und Ziele

Im Folgenden sind die Probleme aufgeführt, die ich anhand unseres vorhandenen Workflows untersucht habe, sowie die entsprechenden Verbesserungsziele:

1. Wasserfallmethode

Problem: Aufgrund meiner Erfahrung verfolgen Website-Projekte einen Wasserfall-Ansatz, da Kunden kein Konzept für ein Minimum Viable Product (MVP) haben. Anstatt Funktionen von Ansichten und Modulationen zu trennen, denken Kunden in der Regel Seite für Seite über die Site nach, was sowohl Designer als auch Entwickler dazu zwingt, Seite für Seite nacheinander zu arbeiten. Dies führt dazu, dass sie im gesamten Projekt eine universelle Perspektive verlieren. Diese Situation führt zu vielen redundanten Hin- und Her-Überarbeitungen zwischen den Seiten.

Ziel: Die Einstellung der Kunden zu ändern ist sowohl arrogant als auch unrealistisch. Ziel ist es, einen Weg zu finden, um Anforderungen so schnell wie möglich von Ansichten zu trennen und intern auf der Grundlage eines seitenweisen Modells so moduliert wie möglich zu entwickeln.

2. Universelle Design-Token und -Komponenten, die sowohl von Designern als auch von Entwicklern verwaltet werden

Problem: Dies ist ein häufiges Problem, für das viele Artikel großartige Lösungen gefunden haben, bei denen es hauptsächlich darum geht, ein Designsystem zu erstellen, das von Styleguide- / Bibliotheksgeneratoren verwaltet wird. Obwohl es eine großartige Lösung ist, war es in unserer Situation nicht angemessen, eine zusätzliche Site zu verwalten, die Designern kaum Bearbeitungsberechtigungen erteilte.

Ziel: Abgesehen von der Erstellung universeller Designtoken und Sprachen, die Designer, Entwickler und Manager verstehen können, sollten Sie ein System erstellen, mit dem jeder die Assets synchron verwalten kann.

3. Genaues, aktualisiertes Fortschritts-Dashboard

Problem: Obwohl Issue-Tracker, Kanban und weitere Projektmanagementmodelle nützlich und praktisch sind, fungierten die meisten von ihnen nicht als einfaches, flexibles und benutzerfreundliches Fortschritts-Dashboard. Diese Art von Dashboard würde dem Team viel Zeit sparen, da Teammitglieder nicht aktiv über die aktuelle Situation bestimmter Aufgaben berichten oder nachfragen können. Es erleichtert den Managern auch das Leben, wenn sie ohne großen Aufwand ein klares Wissen über das gesamte Projekt haben.

Ziel: Erstellen Sie ein Dashboard-System, das Personen, die für bestimmte Aufgaben verantwortlich sind, Bearbeitungsberechtigungen bietet.

Workflow-Diagramm

Bevor wir uns mit der detaillierten Einführung des Stacks für Verwaltungstools befassen, werfen wir einen Blick auf den abstrakten, vereinfachten Workflow, den ich organisiert habe. Es ist so ziemlich nur eine Visualisierung eines normalen Workflows, den die meisten Agenturen haben, aber hier sind zwei Punkte zu beachten.

1. Entwicklerbewertung

Wenn Anforderungen oder Probleme, die vom Kunden kommen, vom Manager genehmigt und dokumentiert werden, mit Ausnahme des Sendens der Aufgabe an einen Designer, gehen sie zunächst auch zur Bewertung an einen Entwickler. In diesem Prozess überprüft der Entwickler die Spezifikation der Aufgabe und prüft, ob komplizierte Funktionen oder Merkmale enthalten sind. Wenn dies positiv ist, kann der Entwickler damit beginnen oder den Designer vorab über mögliche Probleme informieren.

2. Eine einzige Quelle der Wahrheit

Beachten Sie auch, dass nach der Genehmigung des Design-Ergebnisses durch den Kunden und vor der Übergabe der Aufgabe an den Entwickler ein vom Designer durchgeführter Prozess zum Registrieren / Ändern / Löschen über den Design-Speicher durchgeführt wird. Dies liegt daran, dass der Entwickler immer nur einer einzigen Quelle für Design Store ausgesetzt sein sollte, die ständig gewartete und aktualisierte Assets enthält, die für die Entwicklung bereit sind.

Jetzt können wir in den von mir erstellten Management-Tools-Stack eintauchen und sehen, wie die Tools uns bei der Lösung unserer Probleme helfen.

Die Werkzeuge stapeln sich

Nachdem ich mit verschiedenen Optionen auf dem Markt experimentiert habe, besteht der Stapel, den ich hier vorschlage, aus Confluence, Jira, Airtable und Abstract. Neben der grundlegenden Einführung und einigen wichtigen Anwendungsbeispielen werde ich nicht alle Details der Verwendung der Tools behandeln.

Hinweis: Das System geht davon aus, dass das Entwicklungsteam die atomare Entwurfsmethode und das ABEM-Benennungssystem übernimmt.

1. Zusammenfluss

Rolle: Informations- und Ressourcenzentrum

Obwohl es zunächst einschüchternd ist, bietet Confluence einen leistungsstarken Arbeitsbereich, der einfach zu organisieren ist und über unzählige Funktionen, die Integration von Apps und angepasste Vorlagen verfügt. Es ist definitiv keine universelle Lösung für alle Probleme, aber es ist perfekt für die Dokumentation von Spezifikationen, Anforderungen, Besprechungsnotizen und mehr.

Daher fungiert Confluence in diesem Stapel als Informations- und Ressourcenzentrum. Daher sollten alle zugehörigen Links und Details zu diesem Projekt hier ordnungsgemäß dokumentiert werden.

Mein Lieblingsvorteil von Confluence ist die Möglichkeit, Dokumentvorlagen anzupassen. Diese Funktion macht es wirklich bequem, den Workflow zu standardisieren.

Beispiel: KomponenteFunktionsüberprüfung

Ich habe oben den Bewertungsprozess für Entwickler erwähnt , der eigentlich eine komplizierte Aufgabe ist. Dies liegt daran, dass dieser Prozess grundlegende Informationen zur Komponente, eine FSM-Überprüfung eines Entwicklers (falls erforderlich), häufig gestellten Fragen (FAQ) und mehr enthält. Die Flexibilität der Vorlagen und Tools, die Confluence bietet, macht dies jedoch sehr einfach. Erstellen Sie einfach eine Vorlage in den Konfigurationseinstellungen und los geht's.

2. Jira

Rolle: Problemverfolgung und Verwaltung von Aktionstypen

Jira gehört ebenfalls zur Atlassian-Familie und ist eine leistungsstarke Software zur Problemverfolgung und Projektplanung. Mein Lieblingsteil dabei ist das Erstellen angepasster Problemworkflows. Da es unzählige großartige Tutorials gibt, wie man die Leistung von Jira nutzt, möchte ich hier nur auf die Verwendung des unten genannten Problemtyps hinweisen.

Beispiel: Aktualisieren Sie den Entwickler bei Änderungen des Designspeichers nach Problemtyp

Um sicherzustellen, dass Entwickler die Komponenten basierend auf korrekten Entwurfsansichten erstellen, müssen sie benachrichtigt werden, wenn etwas im Entwurfsspeicher aktualisiert wird, einschließlich Aktionen wie Registrieren, Ändern und Löschen . Wenn eine Komponente aktualisiert wird, sollte der Designer ein Problem mit dem zugewiesenen verantwortlichen Entwickler öffnen und den richtigen Problem- / Aktionstyp auswählen.

3. Airtable

Rolle: Komponentenverwaltung und Fortschritts-Dashboard

Airtable, eine Mischung aus Tabellenkalkulation und Datenbank, ist das, was diesen Stack zum Funktionieren bringt. Es gibt zwei erstaunliche Funktionen, die meinen Workflow unterstützen: vier Arten des Ansichtsübergangs in einer einzelnen Tabelle und zugehörige Inhaltsverknüpfungen. Ich werde hier zwei Beispiele für die Verwendung dieser beiden Funktionen vorstellen.

Beispiel 1: Komponentenverwaltung

Wie verwalten Sie Ihre Komponentenbibliothek? Wir haben uns entschieden, keinen Styleguide-Generator zu verwenden, da Designer ihn nicht bearbeiten können. Die Verwendung der Sketch-Komponentenbibliothek war ebenfalls nicht geeignet, da sie zu viele Einschränkungen aufweist, wenn wir versuchen, sie außerhalb des Anwendungsbereichs der Software selbst zu verwenden.

Ich würde nicht sagen, dass Airtable eine perfekte Lösung ist, aber es ist die einfachste und flexibelste Option, die ich mir vorstellen kann. Sehen Sie sich hier die Demo-Vorlage der Komponentenverwaltungstabelle an:

Sobald dem Entwickler eine neu registrierte Entwurfsansicht übermittelt wurde, die programmgesteuert entwickelt werden kann, bewertet er die auf dem ABEM-System basierende Ansicht und registriert sie in der Tabelle. Die Tabelle enthält 9 Spalten, darunter:

1. Name: Benennung der Komponente im ABEM-Prinzip

2. Vorschau: Screenshot oder exportiertes Bild der Komponente

3. Verknüpfte Seite: Der Link zur Seite enthält diese Komponente

4. Untergeordnete Komponente: Der Link zu untergeordneten Komponenten enthält diese

5. Modifikator: Überprüft, ob Stilvariationen vorhanden sind (z. B. - aktiv, - rot).

6. Komponentenkategorie: Eine allgemeine Kategorieklassifizierung (z. B. Text, Held, Seitenleiste)

7. Entwicklungsstatus: Status des Entwicklungsfortschritts (ausstehend, zugewiesen, in Bearbeitung, abgeschlossen, in Überarbeitung)

8. Beauftragter: Entwickler, der für diese Komponente verantwortlich ist

9. Atomebene : Atomkategorie dieser Komponente (Atom, Molekül, Organismus)

Das Beste daran ist, dass Sie Daten sowohl in derselben als auch in anderen Tabellen referenzieren können. Diese Verbindung von Punkten verhindert, dass die Dinge mit zunehmender Größe unordentlicher werden. Beachten Sie auch, dass Sie Ansichten einfach filtern, sortieren und ändern können.

Beispiel 2: Seitenentwicklungsstatus

Da hier davon ausgegangen wird, dass wir den Entwicklungsfortschritt zwangsläufig Seite für Seite bewerten, ist eine für diesen Zweck entwickelte Tabellenvorlage erforderlich. Diese Tabelle kann ein Fortschritts-Dashboard für beide internen Teams sein und gleichzeitig mit dem Kunden geteilt werden.

Alle Informationen über die Seite, einschließlich Frist, InVision-Prototyp-Link, Empfänger und untergeordneter Komponente, können hier organisiert werden. Beachten Sie, dass es sehr praktisch ist, Design-, Front-End- und Back-End-Entwicklungsstatus gleichzeitig zu dokumentieren und zu aktualisieren.

4. Zusammenfassung

Rolle: einzige Quelle für Wahrheit und Versionskontrolle für Design-Assets

Abstract ist GitHub for Sketch, das Designer vor dem Kopieren und Einfügen von Dateien bewahrt. Es liegt außerhalb des Geltungsbereichs dieses Artikels, Details zum Verwalten des Versionskontrollflusses zu demonstrieren. Der Schlüssel zum Erfolg ist, dass Abstract der Designladen ist, der als einzige Quelle der Wahrheit fungiert . Designer sollten den Hauptzweig weiterhin auf die neueste Version des bestätigten Entwurfs aktualisieren und dann die Entwickler benachrichtigen. Auf der anderen Seite sollten Entwickler nur Design-Assets in der Hauptniederlassung als Referenz verwenden.

Es muss noch mehr Arbeit geleistet werden

Nach meiner eigenen Erfahrung war die Entwicklung des gesamten Projekts nach Einführung dieses neuen Workflows mindestens zweimal schneller als zuvor. Es ist keine perfekte Lösung, da die Aktualisierung und Wartung immer noch viel Handarbeit erfordert.

Aber ich denke, es könnte ein hilfreicher Hinweis für Website-Entwicklungsteams sein, die nach einem besseren Workflow suchen, und hoffentlich können in Zukunft mehr Menschen ihre Workflows teilen!

? 中文版 連結 (chinesische Version)  / Ursprünglich auf vinceshao.com veröffentlicht