18.02.2020 // Hackathon, 07.02.20

Strukturiert nach: https://www.mendix.com/de/blog/eine-praktische-anleitung-fur-den-product-canvas/
Product Vision Board
Warum erstellen wir die Anwendung?
Wir wollen ein System haben, das auf die Bedürfnisse offener Werkstätten zugeschnitten ist.
Veränderbar
bezahlbar
Denn bestehende Systeme sind
… zu teuer
… passen nicht vollständig zu unseren Bedürfnissen.
… nicht problemlos in bestehende Strukturen integrierbar
Wer ist unsere Zielgruppe?
Offene Räume
HackerSpaces
Offene Werkstätten
FabLabs in/an Hochschulen
Was sind ihre Bedürfnisse?
Möglichst autonomes / autarkes Handeln ermöglichen
selbstbestimmtes Arbeiten und Lernen
Einfacher niederschwelliger Zugang zu…
Türen
Maschinen
Werkzeuge
Einfache Administrationsprozesse
Die Möglichkeit haben, das System an individuelle technische Gegebenheiten anzupassen.
Möglichkeit zur Abrechnung dieser Vorgänge
Zugriff auf Monitoring / Protokollierung / Nutzungs-Statistiken
Granulare Berechtigungen
Maschinen: Nutzungsberechtigungen
Türen: Zutrittsberechtigungen
(Anleitung und Nutzungshilfen)
Lösen von folgenden Problemen…
manuelle zugangskontrolle
manuelles Aushändigen von Werkzeugen
verschiedene Authentifizierung methoden
manuelles Abrechnen
manuelles Buchführen von Nutzung und Verbräuchen
funktionierende Software/Hardware zu teuer (Fabman)
Nutzung von selbstgebauter Hardware aus versicherungstechnischen Gründen nicht möglich
Was sind dabei unsere Ziele?
Das System soll sich verbreiten, das bedeutet.
Das System soll auf einer möglichst breiten und agilen Basis entwickelt werden.
Wir wollen für die User entwickeln, nicht für uns.
Das System soll Menschen Arbeit abnehmen statt aufbürden.
Das System soll im Rahmen einer nachhaltigen Struktur entstehen - nicht an einer Person hängen, sondern jederzeit durch andere weiterentwickelt werden können.
–> strictly OpenSource.
In Zukunft optional als Föderation funktionieren
Abgrenzung
Zur Diskussion
Spaces die sich neu einrichten (Hauptzielgruppe sind bestehende Labs)
Spaces mit homogenen Geräte/Maschinenpark (Hauptzielgruppe hat eine organisch gewachsenen Gerätepark)
Spaces ohne Geräte/Maschinen (Hauptzielgruppe haben diese)
Spaces die Geräte und Werkzeuge verleihen (Hauptzielgruppe hat Werkzeuge immer am Ort)
Spaces mit viel Geld (Hauptzielgruppe hat knappes Budget)
Spaces die Service möchten (Hauptzielgruppe kann sich selbst helfen)
Spaces die eine Einzellösung benötigen
Fragen zur Zielgruppe
Darf unsere Zielgruppe Veränderungen an Maschinen vornehmen?
Darf unsere Zielgruppe Veränderungen an Türen vornehmen?
Darf unsere Zielgruppe virtuelle Guthaben verwalten?
Hat die Zielgruppe feste ein Buchungsprozess (vorherige Vergabe fester Zeitslots) für Geräte
Wie hoch ist die Fluktuation von Endnutzer unserer Zielgruppe?
Wie hoch ist die Fluktuation von Technischen Administratoren unserer Zielgruppe?
Wie hoch ist die Fluktuation von Supervisor unserer Zielgruppe?
Kurz wie viel Einarbeitung von allen Personas ist noch zulässig?
Welche Skills und technischen/nichttechnischen Möglichkeiten stehen der Zielgruppe in welchen Umfang zur Verfügung?
Techniker (Kabel ziehen, Geräte modifizieren)
Netzwerker (Netzwerke einrichten, Systeme warten, Backups durchführen und zurückspielen)
Einweiser für Endnutzer (Karten ausgeben, Ansprechpartner)
Einrichter (Einrichten des Systems, Probleme beheben)
Entwickler (Erweiterung und Anpassung des FabAccess) ? welche Sprachen sind zu erwarten?
Welche Geräte sind zu erwarten?
3D Drucker
CNC Fräsen
Plotter
Drucker
Nähmaschinen
Lötkolben
Werkzeugkoffer
Wie viele und welche Besonderheiten haben die Räume unser Zielgruppe?
Anzahl von Räumen?
Sind Räumlichkeiten verteilt auf mehrere Standorte?
Haben die Türen unterschiedliche Öffnungsmechanismen?
Können Öffnungsmechanismen getauscht werden?
Gibt es Sicherheitstüren?
Gibt es kritische Bereiche?
Product Canvas
Personas
Wer sind unsere Nutzer?
Akteure, die sich Zutritt zu Dingen verschaffen (Nutzer*, Mitglieder der Werkstatt / des Raumes)
Der technischen Administrator (installiert / aktualisiert das System Software/Aktoren/…)
Supervisor (communitynaher Administrator)
Finanzadministrator
Ressourcen-Administrator
Technischer Maschinen-Betreuer
Lab-Lead (Ansprechpartner in der Räumlichkeit)
User Journeys
Was sind Eigenschaften sowie Aufgaben der Nutzer und wie stellen wir uns vor, dass sie diese erfüllen?
Nutzer / Akteure, die sich Zutritt zu Dingen verschaffen
Eigenschaften
sind tendentiell ungeduldig, möchten schnell zu Ergebnissen kommen
sie sind Laien oder technische Spezialisten - volle Bandbreite
sie möchten jederzeit in die Räume und darin arbeiten
Aufgaben
sollen den Arbeitsschutz beachten (sind daran aber nicht wirklich interessiert)
sollen auf die Maschinen achten (verschleißarme Anwendung)
sollten aufräumen (wollen es aber nicht)
Registrierung: gibt seine Daten selbständig ein und stimmt deren Verwendung zu
Bedürfnisse
wollen den Preis der aktuellen Verbrauchszeit wissen
wollen fehlgebuchte Buchungen stornieren
wollen eine Monatsübersicht
Technischer Administrator
Aufgaben
Will / soll das System (die Software/Aktoren/…) installieren
sowie aktiv halten (aktualisieren, Fehler beheben)
Eigenschaften
kennt das System, kann Software installieren
kann nicht zwangsläufig programmieren
“Semi-Nerd”
Infrastruktur
für die Software steht ihm entweder ein eigener Server zur Verfügung oder auch nicht
Bedürfnisse
will von bestehenden Geräte-Beständen Eigenschaften importieren / exportieren
hat ggf. bevorzugte Authentifizierungsmethoden
moechte moeglichst wenig Administrationsaufwand
möchte / kann nicht viel Zeit in das Aufsetzen investieren
Möchte nicht ständig Angriffsvektoren abschneiden oder schließen (müssen).
will nicht, dass Module bei einem Update kaputt gehen
Supervisor (Nutzer*-Administration)
Aufgaben
Vergibt z.B. Berechtigungen nach Workshops oder Einweisungen
Empfängt neue Mitglieder, vergibt Berechtigungen
Kann Nutzerdaten eingeben und ändern
Finanz-Administration
Aufgaben
rechnet gegenüber den Nutzern ab
Bedürnisse
er möchte individuelle Verbrauchswerte erfassen
es sollte unterschiedliche Typen von “Rechnungen” geben. Nicht jeder Nutzer braucht eine volle Rechnung mit MwSt.
möchte seine individuelle Abrechnungssoftware nutzen
Ressourcen-Administration
Aufgaben
Kauft Material ein
Legt Material in Lager
gibt Geld aus
Bedürnisse
Brauch Verbrauchsdaten von Material konsumierenden Maschinen (z.B. 3D-Drucker)
Technischer Maschinen-Betreuer
Aufgaben
kümmert sich um Maschinen
Bedürfnisse
Verschleißdaten / Nutzungsdaten von Maschinen sollten angezeigt werden können: Rohdaten!
Lab-Lead (Ansprechpartner in der Räumlichkeit)
Aufgaben
Hat Überblick über den aktuellen Betrieb im Labor
Können einfache Fragen zur Nutzung beantworten.
Bedürnisse
will wissen wer gerade da ist
wissen welche Maschinen aktiv sind
will Nutzer* und ihre Eigenschaften recherchieren können
will einfach Stornierungen vornehmen, wenn Falschbuchungen vorliegen
Eigenschaften
sind immer vor Ort am Tresen
sind freundlich
haben z.T. geringes technisches Verständnis vom System
Programmierer
Schreiben den Kern
Wollen realisierbare Aufgabenpakete lösen
Hören auf die (anderen!) Nutzer
Technische Lösungen
Codearchitektur (abgeleitet aus den oben stehenden Bedürfnissen)
Es gibt einen Kern mit Funktionen / Methoden, die den kleinsten gemeinsamen Nenner bilden
Kontrolliert Zugangsberechtigung
Von außen kommt eine Anfrage, die wird validiert und die Entscheidung mitgeteilt
Authentifikation
Parameter, die die Entscheidung beeinflussen, können vom Administrator über ein externes Interface angepasst werden
Der Kern hat ein integriertes Protokollsystem
z.B. Zeitspempel der Authentifizierung eines Users / Aktivierung eines Aktors / Grund der Ablehnung von Aktion XY
gibt Rohdaten (z.B. auf Socket) aus.
Gibt generisches “an” oder “aus” heraus. Was der “Aktor” oder “Sensor” damit macht, ist ihm überlassen
Um den Kern gibt es optionale Frameworks / Plugins, die Zusatzfunktionen ermöglichen, wie:
konkrete Authentifizierungsmethoden
Aktoren-Definitionen
Schnittstellen zu ERP-Systemen
Rohdaten der Protokollierung werden verarbeitet und abgelegt / ausgewertet / whatever.
Begründung: Ein komplett offenes Framework bedeutet beim Einrichten sehr viel Arbeit (benötigt technisch versierten Administrator oder ein sehr aufwendiges Admininterface) und da das höchste Ziel die Benutzerfreundlichkeit und geringen Kosten (auch Zeit) sind, leitet sich die Entscheidung daraus ab.
To-Dos:
Technische Anforderungen klarer fassen
Eine Umfrage formulieren mit den folgenden Parametern:
Wer ist bereit, als Alpha-Tester zur Verfügung zu stehen?
Verbreitete Authentifizierungsmethoden (RFID/NFC/UserId+Pwd/…?)
Bereits existierende Nutzerdatenbank (LDAP, SQL, AD, …?)
Bereits existierende Schliess-/Zugangssysteme
Verwendete ERP-Systeme
Verbeitete Aktoren
3D-Drucker? Welcher?
Welche Server werden verwendet?
Zusammenfassung 08.02.
Wir wollen agil arbeiten uns aber keine Rituale mit massivem Kommunikations-Overhead aufbürden
In Vollzeit-Teams ist der Kommunikations-Overhad vernachlässigbar. In unserer Konstellation (4 Stunden pro Woche) eher tödlich.
Asynchrone Kommunikation ist wichtig und in unserem Fall hilfreich - das lässt manche Elemente der Agilen Arbeitweise nicht zu.
Jira können wir testen und schauen ob es uns hilft oder Mailinglisten bzw. die in Gitlab vorhandenen Möglichkeiten sinnvoller sind.
Grobe Vorstellung der Arbeitsweise:
Es gibt Issues/Tickets in JIRA die das Ziel haben eine konkrete Entscheidung (architekturell) zu treffen
Diskussionen finden asynchron innheralb dieser Issues/Tickets statt
Ziel der Diskussion sollte bei architekturellen Entscheidung ein ADR sein (Architectual Decision Record)
ADR-Template.
CLI-Tool zur Erstellung und Organisation.
Erklärender Blog-Beitrag
Auslieferbare Features definieren wir in Stories
Tasso richtet eine Mailingliste ein
Bis JIRA läuft findet die asynchrone Kommunikation über die Mailingliste statt
Architekturskizze muss nochmal diskutiert und als Bild entwickelt werden.
Hierbei wollen wir auf die Architekturen der bereits im Team vorhandenen Backends eingehen, um zu schauen wo Synthese Sinn macht