Kommunikation mit Entwicklern

Meistens bewegen sich Juristen in den vorgegebenen Pfaden der Rechtsordnung. Im Bereich Legal Tech dürfen Juristen aber als Produkt-Ersteller selbst Regeln vorgeben, denen sich der Entwickler beugen muss. Doch wie gelingt die Kommunikation mit den Entwicklern?

Phasen

Es ist wichtig einen möglichst klaren Ablauf bei der Produktentwicklung zu verfolgen. Am Anfang ist es nicht wichtig kleinste Design-Details zu besprechen und am Ende sollten keine grundsätzlichen Funktionen mehr umgeworfen werden. Je weniger nachträglich geändert werden muss, desto schneller und kostengünstiger verläuft die Entwicklung.

Grob kann die Entwicklung in folgende Phasen aufgeteilt werden:

  1. Idee: Alles beginnt mit der Idee für ein digitales Produkt oder Feature.
  2. Konzeption: Zunächst wird grundsätzlich festgelegt, wie welches Problem gelöst werden soll. Das Design sollte dabei eine untergeordnete Rolle spielen, viel mehr kommt es auf die logische Konzeption an. Es bietet sich bereits hier an, ein erstes Feedback vom Entwickler und Designer einzuholen.
  3. Definition: Nun werden funktionale Details angegangen. Welche Schritte durchläuft der Nutzer? Welche Funktionalitäten sind dafür nötig? Welche Daten sind erforderlich? Wie soll das Produkt aussehen und sich anfühlen? Hierbei wird interdisziplinär gearbeitet und sowohl der Jurist als auch der Designer sowie der Entwickler bringen ihre Ideen ein und arbeiten an einem konzeptionellen Gesamtwerk.
  4. Design: Auf Basis erster Entwürfe wird vom Designer die Benutzeroberfläche erarbeitet.
  5. Implementierung: Nun setzt der Entwickler die Vorgaben um und verbindet den inhaltlichen Input, die Logik und das Design.
  6. Testing: Zuletzt wird das Produkt getestet.

Konzeption

Die Kommunikation mit dem Entwickler ist also bereits in der Konzeption des Produkts essenziell. Dabei können bereits erste, einfache Mock-ups (also Vorführmodelle) erstellt werden. Es sollten nicht bereits zu viele Details herausgearbeitet werden, sondern grundlegende Funktionen im Vordergrund stehen: Wie sieht der Start-Bildschirm aus? Was kann der Nutzer als nächstes machen? Wie sieht das Ergebnis aus?

Verwendet werden können dabei Tools wie bspw. Photoshop oder Figma. Allerdings sind auch erste Skizzen in Powerpoint oder Word möglich.

Je offener und detailärmer die Mock-ups am Anfang sind, desto zugänglicher ist man noch für sinnvolle Änderungen. Denn der Designer und der Entwickler können bereits auf Fehler bzw. auf Nachteile der Skizzen hinweisen. Es ist immens wichtig, dass zunächst die grundlegende Architektur des Produkts festgelegt wird. Dazu zählt die Datenbank-Architektur, die grundlegende Funktionalität und der Design-Entwurf. An diesen drei Säulen sollte wenn möglich später nicht mehr gerüttelt werden.

Vorgaben definieren

Sofern das grundlegende Gerüst des Produkts steht, können die weiteren Vorgaben definiert werden. Es scheint trivial zu sein, was bei dem Klick auf eine bestimmte Schaltfläche passieren soll. Allerdings entwickeln Entwickler meist genau das, was man ihnen vorgibt. Niemand kennt den potentiellen Nutzer jedoch so gut, wie der Rechtsanwender selbst. Wenn nur ein bestimmter Teil der Funktionalität definiert ist, wird der Entwickler den Rest hingegen so entwickeln, wie er es für richtig hält oder Nachfragen stellen.

Das kann teilweise gewünscht und erfolgsversprechend sein. Am sinnvollsten ist es jedoch, alles was aus Nutzer-Perspektive wichtig ist, vorab zu definieren. Dazu gehört, wie das Produkt aussehen soll, wie es sich anfühlen soll und was passieren soll, wenn man auf eine Schaltfläche klickt, etwas eingibt oder sonstige Handlungen vornimmt. Wie das technisch umgesetzt werden soll, sollte – sofern beim Jurist selbst keine hinreichende Kompetenz in diesem Bereich besteht – dem Entwickler offen gelassen werden.

In der Praxis zeigt sich, dass es für Entwickler hilfreich ist, zu wissen, warum etwas so programmiert werden soll, wie es vorgegeben wurde. Dadurch ergeben sich nämlich weitere Zusammenhänge, die für die Entwicklung nicht definierter Einzelheiten bedeutend sein könnten. Je klarer ist was das Produkt genau können soll und warum das für den Nutzer wichtig ist, desto leichter können Entscheidungen bei der Entwicklung getroffen werden.

Planung

Teilweise bergen augenscheinlich einfache Features einen immensen Entwicklungsaufwand, während kompliziert scheinende Features schnell entwickelt werden können. Niemand kann besser einschätzen, wie lange die Entwicklung eines Features dauert, als der Entwickler selbst. Daher sollte den Angaben des Entwicklers vertraut werden und nicht unnötig Druck durch zu kurze Fristen aufgebaut werden.

Softwareentwicklung verstehen

Wer versteht, wie Programme funktionieren, kann Vorgaben realistisch definieren. Wer also die Kommunikation mit Entwicklern bedeutend erleichtern möchte, sollte sich Grundlagen der Softwareentwicklung aneignen. Dabei ist grundsätzlich erst mal egal welche Programmiersprache man lernt, da die grundlegenden Konzepte oft ähnlich sind. Ein Entwickler wird es einem bereits unendlich hoch anrechnen, wenn man versteht, wie eine Datenbank funktioniert, was eine bedingte Anweisung ist und wie Variablen genutzt werden können.