Von der Idee zum fertigen Workflow: Idee, Plan und erster Prototyp (2/5)

[grossal]

Dieser Beitrag ist Teil einer fünfteiligen Serie, in welcher ich die Hauptbestandteile meines Workflow-Bauens behandeln werde. Die Serie folgt dabei einem meiner Projekte, welches ich am Ende auch anhängen und in der Public Gallery veröffentlichen werde. Die einzelnen Beiträge enthalten dabei immer einen allgemeinen und einen am Projekt angelehnten Teil.

• Teil 1: Die Vorgehensweise
• Teil 2: Idee, Plan und erster Prototyp
• Teil 3: Mit Problemen umgehen
• Teil 4: Workflow aufräumen
• Teil 5: Das Ergebnis

Was ist bei der Idee wichtig?

Ich stelle bei Workshops gerne am Anfang die Frage: “Was unterscheidet eine gute Idee von einer schlechten Idee” und werde von den Teilnehmern verwundert angeschaut. Je nach Thema des Workshops, gibt es darauf verschiedene Antworten und Facetten, wie man diese Frage betrachten kann. Jedoch gibt es auch themen-unabhängige Kriterien, die gute von schlechten Ideen abtrennen können:

1) Die Formulierung der Idee

Ich halte mich dabei immer an ein simples Prinzip: Erfüllt die Idee das SMART-Prinzip oder nicht? SMART steht dabei für Spezifisch, Messbar, Attraktiv, Realistisch und Terminiert.

Betrachten wir das ganze am Projekt, das ich im folgenden auch beschreiben will.

Das Ziel des Projekt ist es innerhalb von zwei Wochen (Ende: 10.05.2020) einen (oder mehrere zusammenhängende) Workflow(s) zu erstellen, welche es ermöglichen, die Alteryx Community-Aktivität eines beliebigen Mitglieds auszuwerten und zu visualisieren. Die Daten sollen dabei auf Post-Ebene analysiert werden können und Informationen zu Datum, Likes, Bildern, Links und Lösungen beinhalten.

Die beiden Komponenten Attraktivität und Realistisch sorgen dabei erfahrungsgemäß immer für die meisten Diskussionen, da sie abhängig vom Betrachter unterschiedlich ausfallen können. In meinem Fall ist das Projekt für mich attraktiv, wenn es mir Fragen wie “Waren die Top User der globalen Community (bspw. MarqueeCrew) eigentlich schon immer ganz vorne dabei, bzw. waren diese zeitweise mal abwesend?” beantworten kann. Ebenso ist es für mich selbst interessant, meine eigene Aktivität in dieser Community auszuwerten. In meinem Fall halte ich das Projekt auch für realistisch, da ich meine Kenntnisse über Alteryx für gut genug erachte, um dies innerhalb von zwei Wochen zu schaffen (terminiert). An dieser Stelle darf man sicher darüber streiten, ob diese beiden Sätze ausreichen um schon als Spezifisch und Messbar zu gelten. Um ehrlich zu sein: Vermutlich nicht, vor allem nicht messbar. Für messbar sollte zumindest noch ergänzt werden, dass diese die Likes und Lösungen bei Stichproben mit denen auf dem Profil angezeigten übereinstimmen müssen. Spezifisch ist häufig ein Faktor, welchen man genauer oder ungenauer erfüllen kann. Was ist zum Beispiel mit “visualisieren” gemeint? Reicht dafür ein Graph? Sollen es mehrere sein? Und welche Daten sollen genau darin ausgewertet werden? Da es sich um ein privates Projekt handelt, begnügen wir uns jedoch mit dem aktuellen Wortlaut.

2) Fragen, Fragen, Fragen

Grundsätzlich gilt am Anfang mehr denn je "Fragen, Fragen, Fragen". Methoden wie SMART können zwar helfen Aufgaben besser zu spezifizieren, aber am Ende müssen wir als Workflow-Bauer entscheiden, ob uns die Aufgabe klar genug ist oder ob es noch Unklarheiten gibt. Bei SCRUM spricht man häufig davon, dass ein Fehler 10x so viel Zeit pro weiterem Schritt benötigt. Sind es bei der Aufgabenstellung noch 5 Minuten, so sind es bei der genauen Planung bereits 50 und beim Bauen 500 Minuten. Äußere deine Bedenken sofort und denke nicht nur "das könnte vielleicht nicht klappen".

3) Die Technologie

Die Technologie? Ja, auch die Technologie muss man manchmal in Frage stellen. Kann die Technologie überhaupt das schaffen, was ich beabsichtige zu tun? In einigen Projekten wird daran sicher nichts zu rütteln sein, da diese vom Kunden, Chef oder anderen vorgegeben wird, aber auch dann darf man seine Bedenken anbringen. Im konkreten Fall besitzt das Herunterladen-Werkzeug alle Features, welche ich benötige, um an die Daten zu kommen, daher kann man die Technologie-Frage bejahen.

Der Plan

Wie bereits im vorherigen Beitrag erwähnt, ist es bei größeren Projekten oft sinnvoll, sich vorher ein paar Gedanken über den Ablauf des Workflows zu machen um zu vermeiden, dass man in ein Labyrinth läuft und nicht mehr herauskommt. Ich gehe dabei gerne bereits sehr technisch vor und versuche basierend auf meinem Alteryx-Wissen den Workflow grob zu skizzieren. Konkret könnte das wie folgt aussehen:

Die Funktionalität des Herunterladen-Werkzeugs ermöglicht es, uns auch ohne Batch-Makro die entsprechenden Webseiten herunterzuladen. Ich verwende dieses trotzdem gerne, um wirklich zu zeigen, dass die Webseiten einzeln behandelt werden sollen. Je nach eigenen Alteryx-Kenntnissen kann die Workflow-Skizze auch noch lückenhaft sein und man lässt noch einige Zuordnungen offen.

An dieser Stelle sollte man auch nochmal prüfen, ob es nicht bereits etwas ähnliches schon gibt, nicht dass man sich all die Arbeit umsonst macht oder in Projekten “das Rad erfindet, obwohl es bereits erfunden wurde”.

Der erste Prototyp

Nach mehr als 1.5 Beiträgen geht es nun endlich mit dem los, was viele direkt machen würden: Dem Prototyping. Ich nenne diese dabei bewusst nicht Workflow bauen, sondern Prototyp bauen, um zu unterscheiden, dass wir erstmal nur zeigen wollen, dass es geht und nicht, dass dies schon perfekt ist. Teils spricht man hierbei auch gerne von POC – Proof of Concept.

Wenige Tools reichen, um grundsätzlich zu prüfen, dass wir die Alteryx-Webseite mit dem Herunterladen-Tool downloaden können und diese nicht mit JavaScript überhäuft ist, so dass wir auf andere Möglichkeiten hätten zurückgreifen müssen. Die eigentlichen Informationen zu extrahieren gestaltet sich dagegen für den Laien deutlich schwieriger und ich werde dazu nochmal einen separaten Eintrag außerhalb dieser Serie schreiben. Für den Moment reicht es zu wissen, dass man im Entwickler-Modus eines Browsers mit der Maus über ein Element fahren kann und dann angezeigt bekommt, welcher Quellcode-Teil dieses Element beschreibt. Mit dieser Information kann man einen entsprechenden Regex-Ausdruck bilden, um es zu extrahieren. Das Ergebnis sieht dann wie folgt aus:

 

An dieser Stelle sollte man direkt überprüfen ob das Ergebnis mit dem erwarteten Ergebnis  übereinstimmt: 

Für den ersten Prototyp ist diese Seiten-Information aber ersteinmal egal, es reicht, wenn wir die erste Seite aufrufen und auch hier mit dem Herunterladen-Werkzeug prüfen, ob unsere Datenquelle downloadbar ist. Da dies möglich ist, haben wir damit auch schon unser Proof-Of-Concept. Wir wissen, wir kommen grundsätzlich an alle Daten und können diese weiterverarbeiten. Die Details und Feinheiten kann man dann im Projekt selbst implementieren. Im unteren Bereich des Screenshots können wir bereits den Beitrag aus dem oberen Bild sehen.

In anderen Arten von Projekten wäre ein Prototyp bspw. ein Workflow, welcher auf einer Teilmenge der Daten erfolgreich funktioniert oder das erfolgreiche Verknüpfen von mehreren Datenquellen. Ebenso ist es denkbar, erst einmal eine statischere Version zu bauen und diese dann später um dynamische Elemente zu erweitern.

Autor: Alexander Groß

Bei Fragen könnt ihr mich gerne hier in der Community oder auf LinkedIn kontaktieren.