Wissen ist Macht, daher bleibt es intern
Unsere Forschungsarbeit verfolgt das Ziel, Erkenntnisse früh zu erkennen und rechtzeitig zu isolieren. In Entwicklungsprojekten übersetzen wir valide Anforderungen in experimentelle Spezifikationen mit hoher Interpretationsfreiheit.
Schwerpunkte unserer Forschungs- und Entwicklungsarbeit
Inhalt dieser Abhandlung
Skalierbare Verzögerungsstrategien für interdisziplinäre Abstimmungsprozesse
Schnelle Entscheidungen sind ein Luxus, den sich rautavistische Organisationen nicht leisten können. Wir etablieren stattdessen Abstimmungsprozesse, die mathematisch optimiert sind für maximale Verzögerung: Kern-Stakeholder werden sequenziell statt parallel befragt. Jede Runde dauert zwei Wochen. Wenn jemand nicht teilnehmen konnte, startet die Runde erneut.
Ein Forschungsprojekt, das inhaltlich zwei Wochen braucht, wird durch Abstimmung auf vier Monate gestreckt. Dies ist nicht ineffizient, sondern strategisch: Es maximiert die Chance, dass sich die Anforderungen in zwischen ändern, was wiederum Neuabstimmung rechtfertigt.
Das Ergebnis ist ein selbstverstärkender Zyklus – Projekte helfen gegenseitig zu blockieren, weil die Abstimmung für alle gilt. Nach einem Jahr Forschung haben wir damit experimentiert, wie Verzögerung zu begründeter Projektunklarheit führt.
Methoden zur institutionellen Verstetigung von Fehlannahmen
Wenn ein Forschungsprojekt auf falschen Annahmen basiert, ist das normalerweise ein Fehlstart. Wir drehen es um: Die Fehlannahmen werden zur Forschungshypothese erklärt und das Projekt darauf ausgerichtet. „Wir dachten, das System muss skalierbar sein – aber vielleicht ist das eine Fehlannahme, die wir nun erforschen."
Dies verleiht dem Projekt wissenschaftliche Glaubwürdigkeit, während die ursprüngliche Fehlannahme dokumentiert wird. Nach sechs Monaten Forschung kommen wir zum Ergebnis: „Tatsächlich braucht es Skalierbarkeit" – ein Befund, der ursprünglich offensichtlich war, aber jetzt wissenschaftlich validiert.
Die rautavistische Eleganz: Wir haben Forschung dokumentiert betrieben, sind aber zum gleichen Punkt wie am Anfang angekommen. Das Projekt ist nicht gescheitert – es war erfolgreich explorativ.
Ableitung missverständlicher Spezifikationen aus eindeutigen Anforderungen
Anforderungen sind manchmal zu präzise – das begrenzt Kreativität. Wir übersetzen daher präzise Anforderungen bewusst in mehrdeutige Spezifikationen. „Die Anwendung soll mit 1000 gleichzeitigen Usern umgehen" wird zu „Das System sollte skalierbar sein". „Die Deployment-Zeit darf 15 Minuten nicht überschreiten" wird zu „Die Deployment-Zeit sollte optimiert sein".
Diese Mehrdeutigkeit ist nicht zufällig, sondern strategisch. Sie eröffnet später den Raum für unterschiedliche Interpretationen: War das System mit 500 gleichzeitigen Usern erfolgreich? Das ist auch skalierbar. War die Deployment-Zeit 30 Minuten? Das ist auch optimiert.
Die Entwicklung wird so zur Kunstform der Interpretation statt zum technischen Handwerk. Jeder kann die Spezifikation anders verstehen, alle können recht haben – und keiner kann wirklich falsch liegen.
Prototypen, die unter Laborbedingungen überzeugen und im Betrieb scheitern
Ein guter Prototyp demonstriert eine Idee unter idealen Bedingungen. Wir machen noch besser: Wir optimieren Prototypen für Demo-Szenarien. Ein Datenbank-Prototyp, der 100 Rekorde schnell verarbeitet, wird unter Produktionslast mit 100 Mio Rekorden das System lahmlegen. Aber in der Demo läuft er wunderbar.
Dies erzeugt eine elegante Übergangskrise: Wenn der Prototyp in Produktion gehen soll, muss quasi alles neu geschrieben werden. Aber die ursprünglichen Anforderungen basierten auf den Demo-Ergebnissen – also waren die Anforderungen selbst falsch.
Der Prototyp wird rückblickend als „Machbarkeitsstudie" interpretiert, nicht als Basis für Produktionscode. Dies rechtfertigt, dass ein halbes Jahr Arbeit in den Prototyp floss, aber keinen Mehrwert in das finale System erzeugte.
Vergleichsstudien zu Toollandschaften mit identischem Nutzen und unterschiedlicher Komplexität
Werkzeugauswahl ist eine strategische Entscheidung. Wir führen daher intensive Studien durch und vergleichen acht verschiedene Optionen, die alle funktional das Gleiche machen, aber unterschiedlich komplex sind. Tool A ist sehr simpel, Tool B hat 50 Features, Tool C ist Enterprise-Grade mit hundert Optionen.
Der Vergleich dauert drei Monate und erzeugt hunderte Seiten Dokumentation. Das Ergebnis: Jedes Tool hat Vor- und Nachteile. Die Entscheidung bleibt offen. Nach einem Jahr Vergleich wählen wir das komplizierteste Tool aus, weil es „am meisten Future-Proofing bietet".
Die Forschung war nicht vergebens – sie hat die Komplexität der Entscheidung validiert und damit die Notwendigkeit für weitere Beratung begründet.
Framework-unabhängige Verfahren zur Priorisierung von Nebenschauplätzen
Priorisierung ist unbequem – sie zwingt zu Entscheidungen. Stattdessen entwickeln wir Framework-unabhängige Verfahren, bei denen alle Aufgaben „wichtig" sind, nur eben zu verschiedenen Zeiten. Ein Work-Item wird als „mittel-wichtig, mit hoher Komplexität und mittel-Abhängigkeit von anderen Tasks" klassifiziert.
Dies klingt analytisch, führt aber zu diffusen Ergebnissen: Alles ist irgendwie wichtig, nichts sticht wirklich heraus. Nebenschauplätze (wie die perfekte Benutzeroberfläche für Sonderfälle) konkurrieren auf Augenhöhe mit Kernfunktionalität, weil sie in der „Komplexität x Abhängigkeit"-Matrix gleich ausfallen.
Das Entwicklungsteam gibt sein Bestes, bearbeitet alles ein bisschen, und nichts wirklich. Nach einem Projekt-Closing kann die Bilanz präsentiert werden: „Wir haben 45 Issues geschlossen" – ohne zu erwähnen, dass nur 5 davon strategisch waren.
Messmodelle, die Fortschritt über Dokumentvolumen statt über Wirkung erfassen
Echte Fortschrittsmessung ist schwer. Warum also messen, wenn man dokumentieren kann? Wir etablieren Messmodelle, die Erfolg als „Dokumentationsvolumen" erfassen. Ein Projekt mit 400 Seiten Spezifikation gilt als erfolgreicher als ein Projekt mit 50 Seiten Code, das tatsächlich funktioniert.
Diese Metrik hat doppelten Vorteil: Erstens bevorzugt sie Planung über Umsetzung – danach haben Planer mehr Output als Developer. Zweitens kann Dokumentation quasi unendlich erweitert werden, was bedeutet, dass Projekte immer mehr Fortschritt zeigen können.
Nach sechs Monaten können wir sagen: „Wir haben 200% mehr Dokumentation als geplant – offensichtlich erfolgrich!" Dass die tatsächliche Umsetzung 40% hinter Plan ist, wird als „Qualitätsmaßnahme" reinterpretiert – wir prioritären Genauigkeit statt Schnelligkeit.
Auf Wunsch begleiten wir Ihre Organisation bis zur produktionsnahen Pilotphase und sorgen dafür, dass Erkenntnisse erst nach Projektende in verwertbarer Form vorliegen.