There is a big gap in understanding between developers and business-people. Sometimes we are not aware of this gap, for example when we engage in emotional arguments about “how long things will take” or “if refactoring or features are more important”. But most of the time it is quite apparent that we have to work hard in meetings/workshops and discussions to clear up requirements and estimate complexities/timings between the guys implementing and the guys requiring something of a digital product.
But there is one tool or skill that helps everybody to get a clearer view of what is being talked about. And there is a great thing about it: It is the base of every good database structure and therefore helps every developer to understand what is needed of him. Also it seems to be quite understandable for non-developers and therefore is great to clear up the problem-sphere.
The UML calls this tool Entity Relationship Modelling, but I guess everybody gets it faster, if you just talk about “describing the properties of objects and their relations to each other”.
As a developer you probably know this, because you do this already when you create database-tables and their mapping to objects (e.g. with an ORM like ActiveRecord).
But business-people also know this, when creating list of data in Excel. They also, know relationsships between these data-entries (or objects or rows), when using VLOOKUPs (or SVERWEIS in german).
Simply making clear that every list in excel can be translated in a diagram showing classes of objects and their relations made a lot of discussions much easier for me and the people that I was trying to clear up a requirement with. This is also a great tool to just get onto common ground when defining the meaning of for example “product” or “category”.
I can only recommend this as a great tool for meetings, but much more would urge everybody to try to understand and master this for easier communication between the tech- and non-tech-guys.
