Separation of concerns – Trennung nach Belangen.
clean-code-developer

Das Prinzip SOC spiegelt sich in der Struktur des Wiki wider. Wir wollen die fachlichen von den technischen Belangen dort trennen, wo es Sinn macht. Das Ziel ist es, bei der Arbeit im Wiki die Stärken der Projektmitarbeiter zu fördern. Das erfordert eine sinnvolle Aufteilung der Inhalte. In vielen Fällen analysieren wir den Problemraum «top down», d.h. wir erforschen das «big picture», identifizieren den Nutzen und detaillieren die daraus abgeleiteten Anforderungen. Das ist ein Prozess, den wir in der Struktur mit den Bausteinen der Produktdokumentation berücksichtigen.

Stakeholder können ihr fundamentales Wissen über die Geschäftsprozesse und die Bedürfnisse der Fachabteilungen gut einbringen, wenn die Beschreibung nicht zu detailliert sein muss, also das Abstraktionsniveau sehr hoch ist. Stakeholder arbeiten direkt und ohne Kommunikationsverluste (“Stille-Post”) im Wiki und sind dadurch auch für bestimmte Inhalte (z.B. Topic) verantwortlich. Business-Analysten können damit sicherstellen, dass sie die Probleme der Stakeholder richtig verstehen. Die Entwickler können sich einen guten Überblick verschaffen.

Business-Analysten sind sehr oft überfordert, wenn sie technische Lösungen formulieren sollen. Sie sind häufig nicht am letzten Stand, was technische Lösungen betrifft, oder es fehlt ihnen das notwendige spezielle Wissen. Das Ergebnis ist, dass die beschriebene Lösung nicht mit der tatsächlichen Umsetzung übereinstimmt, weil die Entwickler später eine bessere Lösung finden. Die Lösungsbeschreibung “verdirbt”.

Auf der anderen Seite sind Entwickler schlecht darin, die grundlegenden Probleme der Nutzer zu erkennen, weil sie häufig in Lösungen denken. Hier spielen Business-Analysten ihre Stärke aus, wenn sie sich auf diese fachlichen Probleme konzentrieren können. Und sie fühlen sich in den meisten Fällen auch wohler damit.