Es gibt eine riesige Verständnislücke zwischen Entwicklern und Business-Leuten. Manchmal ist uns diese Lücke nicht bewusst — zum Beispiel wenn wir uns emotional darüber streiten, „wie lange Dinge dauern” oder „ob Refactoring oder Features wichtiger sind”. Aber meistens ist es offensichtlich, dass wir in Meetings, Workshops und Diskussionen hart daran arbeiten müssen, Anforderungen zu klären und Komplexitäten sowie Timings zwischen denen, die etwas umsetzen, und denen, die etwas von einem digitalen Produkt fordern, abzustimmen.

Es gibt jedoch ein Werkzeug oder eine Fähigkeit, die jedem hilft, einen klareren Blick auf das zu bekommen, worüber gesprochen wird. Und das Großartige daran: Es ist die Grundlage jeder guten Datenbankstruktur und hilft daher jedem Entwickler zu verstehen, was von ihm gefordert wird. Gleichzeitig scheint es für Nicht-Entwickler gut verständlich zu sein und eignet sich daher hervorragend, um den Problemraum zu klären.

Die UML nennt dieses Werkzeug Entity-Relationship-Modellierung, aber ich denke, jeder versteht es schneller, wenn man einfach davon spricht, „die Eigenschaften von Objekten und ihre Beziehungen zueinander zu beschreiben”.

Als Entwickler kennt man das wahrscheinlich, weil man es bereits beim Erstellen von Datenbanktabellen und deren Abbildung auf Objekte tut (z.B. mit einem ORM wie ActiveRecord).

Aber auch Business-Leute kennen das, wenn sie Datenlisten in Excel erstellen. Sie kennen auch Beziehungen zwischen diesen Dateneinträgen (oder Objekten oder Zeilen), wenn sie VLOOKUPs (oder SVERWEIS auf Deutsch) verwenden.

Einfach klarzumachen, dass jede Liste in Excel in ein Diagramm übersetzt werden kann, das Klassen von Objekten und ihre Beziehungen zeigt, hat viele Diskussionen für mich und die Menschen, mit denen ich Anforderungen klären wollte, erheblich einfacher gemacht. Es ist auch ein großartiges Werkzeug, um eine gemeinsame Basis zu schaffen, wenn man die Bedeutung von z.B. „Produkt” oder „Kategorie” definiert.

Ich kann dieses Werkzeug für Meetings nur empfehlen — und noch mehr würde ich jeden ermutigen, es zu verstehen und zu beherrschen, um die Kommunikation zwischen Tech- und Non-Tech-Leuten zu erleichtern.