Doch wir haben eine Marktlücke identifiziert, die technologisch oft vernachlässigt wird: Der regionale Mittelstand.

Oft stehen kleine und mittlere Unternehmen (KMU) vor der Wahl zwischen starrer Standard-Software, die nicht passt, und teuren Agentur-Lösungen, die das Budget sprengen. Professionelle Software-Architektur und moderne Sicherheitsstandards sind oft den "Großen" vorbehalten.

Wir sind der Meinung: Das muss sich ändern.

Launch des „Schwälmer Softwarehauses“

Deshalb freuen wir uns, den Start unseres neuen Labels Schwälmer Softwarehaus bekannt zu geben.

Diese neue Marke fungiert als dedizierte Schnittstelle für regionale Kunden hier in Nordhessen. Das Ziel ist ein direkter Technologietransfer: Wir nehmen die Methoden, Sicherheitsstandards und die Stabilität, die wir bei Martini Labs für Enterprise-Kunden entwickelt haben, und kondensieren sie in pragmatische, effiziente Produkte für das lokale Gewerbe.

Aus Projekten werden Produkte

Während Martini Labs weiterhin für technologische Exzellenz und komplexe Problemlösungen steht, fokussiert sich das Schwälmer Softwarehaus rein auf operative Exzellenz im KMU-Bereich. Wir verpacken unsere "Enterprise-Power" in nutzerfreundliche Werkzeuge.

Das bedeutet für unsere Kunden vor Ort:

• Sicherheit: Enterprise-Grade Security auch für kleine Teams.
• Stabilität: Robuste Architekturen statt "Bastel-Lösungen".
• Effizienz: Automatisierungstechnologien, die bisher Konzernen vorbehalten waren.

Ein Bekenntnis zum Standort

Martini Labs operiert digital und überregional. Doch mit dem Schwälmer Softwarehaus stärken wir bewusst unseren physischen Standort. Wir glauben, dass echte digitale Transformation im Mittelstand nicht nur Code braucht, sondern auch Verständnis für lokale Wirtschaftskreisläufe und persönliche Ansprechpartner.

Wir sind gespannt auf die Synergien, die zwischen High-Tech-Forschung und pragmatischer Anwendung entstehen werden.

Erfahrt mehr über die neue Initiative unter: schwaelmer-softwarehaus.de

Oder guckt euch das Projekt in unserem Portfolio an.

Es gibt immer eine Engstelle, die das weitere Vorankommen maximal ausbremst. Das dringendste Problem ist aber üblicherweise nicht das Ursächliche.

Das dringendste Problem ist selten die Ursache für Stagnation.

Zudem ist Ansatz sich immer auf die dringendsten Probleme zu stürzen nur eine Form der Symptombekämpfung [→ Lösungen und Probleme].

Für dein Unternehmen hießt das: “Ok, ich kann also nicht skalieren, weil ich an den falschen Problemen arbeite. Beim Debuggen ist das relativ einfach, ich muss nur nachvollziehen wo und welche Daten wo lang fließen und stoße zwangsläufig auf eine Stelle, an der irgendwas nicht passt - Fehler gefunden. Aber wie finde ich bitte heraus welches der ursächliche Flaschenhals für mein persönliches oder mein Unternehmenswachstum ist?”

Das ist so einfach wie es schwer ist. Oder anders gesagt, mit der richtigen Methode wird es relativ einfach das herauszufinden.

Okay, du fragst dich jetzt sicher: "Ja ok, die richtige Methode. Aber wie zum Teufel soll die denn funktionieren?"

Keine Sorge, ich hab da was für dich. Es ist wie eine Schatzsuche, nur dass der Schatz dein größtes Wachstumshindernis ist. Klingt komisch? Ist es auch, aber es funktioniert.

Hier ist dein Fahrplan zur Ursachenforschung:

1. Brainstorming deluxe: Schnapp dir einen Stapel Post-its und schreib ALLE Probleme auf, die dir einfallen. Ja, wirklich alle. Von "Kaffee ist alle" bis "Umsatz stagniert" - alles muss raus.

2. Sherlock Holmes Time: Jetzt wird's spannend. Für jedes Problem fragst du dich: "Warum passiert das?" Sei wie ein neugieriges Kleinkind und hinterfrage alles.

3. Verbinde die Punkte: Hier kommt dein innerer Verschwörungstheoretiker zum Einsatz. Zieh Linien zwischen den Problemen und ihren Ursachen. Du wirst sehen: Viele Wege führen nach Rom, oder in diesem Fall zu einer Handvoll Kernursachen.

4. Ursachen-Tetris: Jetzt wird geclustert. Bring ähnliche Ursachen zusammen, als würdest du ein Puzzle legen. Am Ende hast du weniger, dafür dickere Ursachen-Brocken.

5. Inception der Problemlösung: Wir gehen tiefer. Frag dich für jede Ursache: "Und warum ist DAS so?" Du bist jetzt im Ursachen-Kaninchenbau.

6. Rinse and Repeat: Mach das Ganze nochmal. Und nochmal. Bis du nur noch eine Mega-Ursache übrig hast, die sich anfühlt wie der Endgegner in einem Videospiel.

Klingt nach viel Arbeit? Ist es auch. Aber hey, niemand hat gesagt, dass Unternehmenswachstum ein Spaziergang ist. Diese Methode ist wie eine Zeitreise in die Zukunft deines Unternehmens. Du siehst nicht nur die Symptome, sondern kriegst einen Röntgenblick für die wahren Knackpunkte.

Am Ende stehst du da mit DER Ursache in der Hand. Es fühlt sich an, als hättest du den heiligen Gral gefunden - nur dass dieser Gral dir sagt, woran du wirklich arbeiten musst, um voranzukommen.

Also, Ärmel hochkrempeln und los geht's! Dein Unternehmen wird es dir danken, wenn du nicht mehr wie ein kopfloses Huhn von einem dringenden Problem zum nächsten rennst, sondern gezielt den Finger in die richtige Wunde legst. Und wer weiß, vielleicht findest du dabei sogar heraus, warum der Kaffee wirklich immer alle ist.

‍

🤷‍♂️ Warum müssen Software-Projekte eigentlich immer erfolgreich sein?

💡 Ein Projekt erfolgreich abschließen kann jeder, das ist maximal langweilig. Also warum nicht mit minimalem Aufwand und ein bisschen Geschick das Projekt komplett vor die Wand fahren?

❓ Wie schaffe ich es als Verantwortlicher mein Projekt zu verkacken?

☝️🧐 Dieser Frage möchte ich in diesem Artikel auf den Grund gehen.

Mindset

Der Kunde hat keine Ahnung - von nichts, kann nichts und liegt immer falsch - aber wird das niemals einsehen. Vermeide es gemeinsam mit ihm Lösungen zu erarbeiten, ihr könntet Gefahr laufen Missverständnisse aufzudecken.

Keine Enterprise-Patterns!

Das Sind nur alles nur leere buzz words! Es gibt keine wiederkehrende Arten von Problemen, oder gar Lösungsansätze die sich auf ähnliche Probleme adaptieren ließen. Jedes Problem muss von Grund auf als einzigartig von vorher nie dagewesen angesehen werden.

Vorbereitung

1. Sorge dafür, dass bei den Stakeholdern und dir selbst KEIN Konsens über das Projektziel besteht. Jeder Beteiligte sollte eine unterschiedliche Vorstellung von den Anforderungen haben. So legst du den Grundstein für Missverständnisse, auseinanderlaufende und widersprüchliche Anforderungen.
2. Starte so schnell wie möglich mit der Implementierung und Verschwende keine Zeit mit, zB:some text
   • Machbarkeitsstudien
   • Wireframes/Mockups/Klickdummy
   • Prototypen
   • Du könntest sonst Probleme vermeiden, die das Projekt später zuverlässig torpedieren können.

Fundament

1. Mach dir keine Mühe vor der Implementierung die Architektur der Anwendung zu gestalten. Das würde zu einer stabilen Basis führen, die spätere Fehler großzügig verzeiht und die Umsetzung beschleunigt.
2. Vergiss CI/CD-Pipelines!some text
   1. Deine Tests und Deployments in einer robusten Pipeline zu automatisieren würde dir nicht enorm viel manuelle Arbeit ersparen. Was aber noch viel schlimmer ist, wertvolle Bugs würden es nicht mehr in die Produktiv-Umgebung schaffen.
   2. Vermeide Automatisierungen ganz besonders beim Deployment. Wenn euer Code per FTP ins Prod-System geladen wird, und nur eine einzige Person die Zugänge dazu hat, spielt ihr in der Königsklasse.
3. Benutze niemals gut erprobte und dokumentierte externe Libraries! Es reicht nicht aus das Rad neu zu erfinden. Erfinde auch das Werkzeug neu um ein neues Rad zu Erfinden! Not invented here? No thanks!
4. Es ist viel zu einfach Linter und Prettifier zu benutzen. Lass diene Entwickler:innen ihren Code formatieren wie sie wollen. Umso länger und kompliziert die Zeile,  umso besser! Methoden sollten möglichst nicht weniger als 200 Zeilen und 7 Einrückungsstufen haben.

Rahmenbedingungen

1. Erstelle KEINE User-Stories oder Tasks. Beschreibe das Ziel so wage und triff so viele Annahme wie möglich. Mach das unter der Prämisse, dass alle Entwickler den gleichen Wissensstand haben wie du selbst und ihr daher alle die gleichen Schlussfolgerungen trefft. So werden alle Feature garantiert falsch umgesetzt und du sorgst für ein Höchstmaß an Rückfragen und Missverständnissen.
2. Lass alle Entwickler selbst herauszufinden, welche Tasks, wie umzusetzen sind. Anderenfalls wüssten sie genau was, wann, wie zu tun ist und ihre Produktivität könnte sich vervielfältigen.
3. Lehne Komplexitäts-Schätzungen kategorisch ab. Zeit-basierte Schätzungen erhöhen den Druck auf die Entwickler, täuschen dem Kunden Sicherheit vor und können bei größeren Projekten garantiert nicht eingehalten werden.

Allgemeine Vorgehensweise

1. Versuche auf keinen Fall einen Überblick des Projekts, dessen Stand oder den Stand der Entwickler zu behalten, sonst läufst du Gefahr frühzeitig Engpässe zu erkennen und könntest diese dem Kunden gegenüber kommunizieren oder gar auflösen.Bonus: dadurch kannst du ganz leicht allen (neuen) Beteiligten eine falsche Auskunft über den Fortschritt des Projekts geben. So hast du es auch sehr leicht Externe, die das Projekt retten sollen, unter der Angabe falscher Voraussetzungen mit rein zu holen.
2. Setze ausschließlich unerfahrene Entwickler auf die grundlegenden Teile des Systems an - sprich System- und Software-Architektur. So garantierst du maximale Instabilität, sowie komplizierten, redundanten und unstrukturierten Code, der genauso schwer zu lesen, wie zu warten oder zu erweitern ist.
3. Dein Prozess und deine Vorgehensweise sind perfekt. Schuld an Problemen hat entweder der Entwickler, weil er anders denkt als du (siehe Punkt 3.a) oder der Kunde, weil er unsinnige Anforderungen hat (siehe Punkt 1.a).

Umsetzung/Durchführung

1. Benutze KEINE Standard-Bibliotheken oder Frameworks bei der Umsetzung. Das würde die Produktivität nur unnötig steigern.
2. Sorge dafür dass Wissens-Inseln entstehen. Alle Entwickler sollten nur ihren eigenen kleinen Teil der Software kennen und keine Zeit in den Wissenstransfer verschwenden. Das würde zu unerwünschten Synergie-Effekten führen oder Entwickler sogar austauschbar machen, für den Fall dass sie mal ausfallen.
3. Eine verlässliche Methode um Punkt 2) zu erreichen ist das Verbot von Reviews.
4. Lass nicht zu, dass APIs geplant oder gar dokumentiert werden. So können nette Pläusche zwischen den Front- und Backend-Entwicklern entstehen und du kannst sie davon abhalten produktiv zu sein. Im Optimalfall können APIs und Calls zu diesen sogar stark auseinander laufen.
5. Alle Beteiligten (Entwickler, Stakeholder, Domänenexperten, Kunden, ...) sollten so viel und unabhängig voneinander wie möglich kommunizieren. Das garantiert Missverständnisse und generiert ein Höchstmaß an unproduktiver Zeit.
6. Die Ergebnisse aus 5) sollten auf keinen Fall dokumentiert werden. Anderenfalls könnten mehrfache Absprachen oder gar auseinander laufende Ergebnisse verhindert werden.
7. Verbiete Dailies und Absprachen jeglicher Art zwischen mehreren Entwicklern. In Kombination mit dem Verbot von Ticket-Systemen schaffst du ideale Voraussetzungen für doppelte parallele Arbeit.
8. Delegieren/Beauftragen: Hat dein Kunde Sonderwünsche, lass diese nur soweit implementieren, wie deine Entwickler sagen können: “Works on my machine... 🤷‍♂️”
9. Tests führen nur unnötigerweise dazu, dass Fehler frühzeitig erkannt werden.
10. Verbiete, wie in 2.4) erwähnt, den Einsatz von Lintern, Prettifiern oder sonstigen Tools, die mit einfachen Mitteln helfen Konventionen einzuhalten. So schaffst du ausreichend Streitpotenzial über Code-Style und beugst zusätzlich Reviews vor, weil niemand Lust hat das Kauderwelsch der anderen zu lesen.
11. Kaum etwas sorgt so zuverlässig für einen Misserfolg im Projekt wie das tägliche umwerfen des Projektplans und reinschieben neuer Aufgaben, während noch an Features gearbeitet wird. Erziehe auch deinen Kunden dahingehend, dass er unentwegt neue Anforderungen mit oberster Priorität generiert. So wird dir/euch die Arbeit nie ausgehen.
12. Keine der obigen Anstrengungen werden jedoch von Misserfolg gekrönt sein, wenn deine Entwickler durchgängig konzentriert arbeiten können. Es dauert im Schnitt ca. 20 Minuten bis man sich gut in ein Problem eingedacht hat und produktiv programmieren kann. Erzeuge für deine Entwickler mindestens alle 30 Minuten eine größere Ablenkung, so dass sie aus ihrer Konzentration rausgerissen werden.

Vielen Dank für die Aufmerksamkeit. Kritik, Ergänzungen und Anregungen sind erwünscht.

Dieser Artikel könnte Spuren von Sarkasmus hinerlassen haben - folgen Sie diesen. Sie könnten ins Licht führen.

‍

So lange kann es dauern in Deutschland ein Unternehmen zu Gründen. Ich könnte jetzt hier einen endlosen Behörden-Rant vom Zaun brechen, stattdessen habe mich dazu entschlossen mich zu freuen.

Na jedenfalls ist die Martini Labs GmbH endlich im Handelsregister eingetragen!!!

Also, los gehts:

‍

‍

🎉🎊🥳🎊🎉

Gibt es ein “zu spät” um eine schlechte Entscheidung zu revidieren?

Bzw., was passiert wenn im laufenden Projekt festgestellt wird, dass eine weitreichende Architekturentscheidung, die eingangs getroffen wurde, falsch war?

Wir betrachten hier ein Szenario, bei dem es genau um eine solche Entscheidung ging.

Szenario (Problem):

• Eine Single-Page-Application wurde ohne richtiges Framework umgesetzt.
• Stattdessen sollten nur mit Stencil erstelle WebComponents benutzt werden.
• Übliche Framework-Funktionen fehlten (State-Management, Event-Handling, Data-Binding, ...).
• Es wurde viel eigener Code geschrieben, um einige dieser Funktionen nachzubilden.
• Eine flexible und erweiterbare Komponenten-Library war nicht vorhanden.
• Es mussten eigene Frontend-Komponenten gebaut werden, um die WebComponents zu handhaben.
• Das Gros der User-Stories war noch offen.
• Die Velocity war viel zu gering, um das Projekt auch nur ansatzweise zum geforderten Zeitpunkt abschließen zu können.

Aufgabe (Ziel):

Das Projekt soll sowohl monetär, als auch temporal im Budged bleiben.

Sprich:

→ Prod-Deployment + Feature Complete in 4 Monaten

→ Abschluss und Veröffentlichung in 6 Monaten

Zwei Möglichkeiten:

1. So weitermachen wie bisher:
   • Nachimplementierung von Framework-Features.
   • Anpassung der vorhandenen WebComponents (durch das separate zuständige Team).
   • Beides sehr zeitaufwändig und fehleranfällig.
   • Beides muss aufwändig getestet werden.
   • Weiterhin großer Aufwand beim Umsetzen der restlichen User-Stories mit niedriger Velocity
2. Vollständige Neuimplementierung unter Verwendung eines etablierten Frameworks:
   • Feature-Freeze über 2 Sprints
   • Einführung des Frameworks, samt Linter, Prettier, Konfiguration, Paketen, Pipeline(s), ...
   • Nachimplementierung der bereits umgesetzten User-Stories.
   • Umsetzen der restlichen User-Stories mit stark erhöhter Velocity.
   • Gefahr mehr als zwei Sprints zu brauchen.

Wichtig zu erwähnen ist, dass für die Neuimplementierung von vorn herein nur zwei Sprints zur Verfügung standen.

Ansatz (Lösung)

Als ersten haben wir Entwickler einen Schlachtplan ausgearbeitet, diskutiert, vorgestellt und durchgeführt:

• Gegenüberstellung der geschätzten Aufwände beider Ansätze bezüglich der Fertigstellungsfrist
• Vorstellungen der Ergebnisse bei ProductOwner, Projektleitung und Kunden.

Da letzterer ein Vetorecht hatte, war es entscheidend die Argumentation entsprechend schlüssig und nachvollziehbar aufzubauen.

Besonders interessant an dieser Stelle war der Vergleich der potenziellen mit der bisherigen Velocity:

• Status Quo: 2 Entwickler, 12 Sprints
• Neu-Implementierung: 6 Entwickler, 2 Sprints

Rein rechnerischer Performance-Gewinn: +100%

Ergebnis

Der Vergleich hatte gezeigt, dass trotz des Feature-Freeze nur durch die Einführung eines Frameworks das Projekt annähernd fristgerecht hätte abgeschlossen werden können. Daher wurde die Einführung beschlossen. In einer weiteren Front-End-Runde wurde sich zudem speziell für Vue.js entschieden.

Die initiale Implementierung, samt Wiederherstellung des Entwicklungsstandes wurde in den dafür veranschlagten 2 Sprints abgeschlossen. Entsprechend hat sich die Velocity wie erhofft ca. verdoppelt und das Projekt konnte mit minimaler Verzögerung abgeschlossen werden.

Zwei Tage vor Projektabschluss ist es sicherlich zu spät um eine ineffiziente Implementierung durch eine effizientere auszutauschen. Hat man aber noch ein paar Sprints offen, ergibt es allemal Sinn eine objektive Gegenüberstellung der Möglichkeiten zu erheben.

PS:

Die Anwendung ging live, der Kunde war happy, das Projekt war ein voller Erfolg - und wird weitergeführt.

TLDR

Implement the parallax effect with an Angular directive, which works on the translate-y property of CSS3.

See the demo on Stackblitz or check out from GitHub.

angular-8-parallax-directive

hpmartini ⋅ 5 years ago

The parallax effect…

… not explained. I won’t bother you with boring explainations about that effect, which you can read for yourself on wikipedia if you feel the urge.

Prerequisites

First you have to have node.js running on your system.

For Mac users

If you’re lucky to have a Mac, just run this:

If you don’t have homebrew installed already, go to homebrew.sh or run this:

For anyone else

Sorry for that, but please visit nodejs.org for further instructions. I don’t have another system at hand right now.

Ahead with angular cli

Install Angulars command line interface with this, if you dont’t have it already:

Setup the Angular project

Go to the projects directory of your desire and run this command to create an Angular project:

This creats your awesome parallax project in the directory called… I guess you know it already. The CLI fills up the project with everything needed to get it running. So start it up:

The “-o” is not recommended, it just opens the angular app in your default browser.

Now the fun part starts

Lets generate a new directive:

Copyng generate directive common/parallax

This command puts the new directive in the sub directory common, which is not necessary, but I like to have a clean structure.

The CLI also registers the directive in the app.modules.ts, along with the default components and services.

parallax.directive.ts‍

‍view on GitHub

• The factor of how fast the element will move relative to the scroll position is passed through an @Input decorator. By default (factor = 1) the effect will be just a bitt slower then a linear scrolling element.
• The class ElementRef is the recommended way to manipulate elementes, because directly accessing the DOM could promote XSS attacs.
• The Renderer2 takes the ElementRef and sets the desired property in the DOM.
• We just set the translateY CSS property of our element by multiplying the current scroll position with the passed factor. I devide that by 10, because the movement would be to fast or we could not work with integers in the HTML.
• The @HostListener('window:scroll') will be triggered when you scroll - what a surprise - and the translate propery will be updated.

app.component.html

‍view on GitHub

app.component.css

‍view on GitHub

Nothing special here, the container is set to 100vh so we can scoll at all. The same goes for the positioning of the two strings at the bottom.

That’s it.

Just to remember, you can watch the demo on Stackblitz or check out from GitHub.

‍

(gif from https://abetteruserexperience.com)

Was bei DC und Marvel ziemlich cool ist, kann im Entwickler-Alltag leicht zu Frust und Zeitverschwendung führen: Mutability von Objekten.

Was haben denn bitte Comics mit Programmieren zu tun?! Ganz einfach, Quantenphysik.

⚛️ Objekte und und ihre Pointer sind ein bisschen wie verschränkte Teilchen. Ändert man ein Objekt an der einen Stelle im Code, ändert es sich auch an der anderen. Damit kennen wir dessen Zustand nicht mehr, ohne genau hinzuschauen - wir haben also erfolgreich Schrödingers Katze implementiert 🙀 Sprich das Gesetz der Dekohärenz ist umgangen und das Objekt befindet sich in Superposition. Will keiner, denn die nächste Messung wird erst stattfinden, wenn uns die nächste Fehlermeldung um die Ohren fliegt.

🤨 What...

In Redux ist es verboten und in NgRx schlich nicht möglich Objekte im Store zu verändern.

Manchmal ist es aber ziemlich übertrieben ein State Management einzuführen. Objekte, trotz fehlenden Zwangs, als immutable zu behandeln kann aber trotzdem eine gute Idee sein.

Also getreu dem Reactive Programming Paradigma: "Create new, don't alter"

⚠️ Zonk! Problem: Das verschränkte Objekt (ja ok, es ist dasselbe!) hält sich auch noch außerhalb der Methode auf. Wird es nach dem Aufruf von setLocalState() verändert, ändert sich auch die Property localState  in unserer Klasse

Also besser so:

☝️🧐 So haben wir schnell ein neues Objekt erzeugt und unschönen Seiteneffekten vorgebeugt.

Ich weiß, die Beispiele sind komplett an den Haaren herbeigezogen. Hat aber halt Spaß gemacht, den Artikel so zu schreiben... 🤷‍♂️

Momentan ist noch die Holding (Martini Holding GmbH) in Gründung - das Amtsgericht lässt sich Zeit. Danach folgt die Gründung der operativen GmbH (Martini Labs GmbH)

Nach über drei Jahren Arbeiten als Freelancer, ist es jetzt für mich soweit den Sprung in die Untiefen des Unternehmertums zu wagen.

Nach dem Motto “wenn’s rockt, dann rollt’s” werden wir die Welt des IT-Consultings von hinten aufrollen 🚀

In der Hektik des täglichen Arbeitsgeschehens ist man schnell dazu geneigt für akute Probleme die erstbeste Lösung zu akzeptieren. Problem gelöst → nächste Problem muss her.

Zu schnelle “hacky” Lösungen führen aber oft im späteren Verlauf zu noch größeren Problemen.

Man sollte genau abwägen wann es angebracht sein kann quick-n-dirty zu arbeiten und wann es sinnvoller ist sich Zeit zu nehmen um eine saubere Lösung zu entwerfen.

So ist es in der Softwareentwicklung, wie auch im Geschäftsleben.

‍

Während die Frage, zumindest intuitiv, relativ einfach zu beantworten ist - man bleibt im Budget und erfüllt die Anforderungen - schwingt da noch eine viel schwieriger zu beantwortende Frage mit. Wie zur H***e wird ein Projekt erfolgreich?

Auf eine Sache können wir uns schon mal einigen: scheitert ein Softwareprojekte ist es erstmal egal ob das Budget gesprengt wurde, das Entwickler-Team jahrelang mindestens auf Alarmstufe Gelb gearbeitet hat oder der Kunde sich gnadenlos verkalkuliert und wegen einer überzogenen Time-to-Market Insolvenz anmelden musste. All das sind No-Gos!

Vielleicht stimmen wir auch mit der nächsten Aussage überein: alle gescheiterte Projekte haben einige signifikante Gemeinsamkeiten. Die fundamentalste ist, dass sich während der initialen Planung über einige entscheidende Punkte wenig bis keine Gedanken gemacht wurde. Das hat zwei Gründe:

1. Alle Stakeholder haben naturgemäß unterschiedliche Vorstellungen der Anforderungen.
2. Dessen sind sie sich nicht bewusst oder unterschätzen die Konsequenzen.

Dann kommt es zu immer neuen Iterationen an Änderung, weil a) das Entwicklerteam die genauen Vorstellungen der Stakeholder nicht kennt und b) auch die Stakeholder sich untereinander nicht einig sind. Mit den Implikationen daraus könnte man Bücher füllen.

Also konzentrieren wir uns vorrangig darauf, wie wir ein starkes Fundament in einem neuen Projekt legen können, damit aus der fancy Produktvision kein Fire-Fighting-Projekt wird.

tl;dr

Betrachten wir unseren Ansatz wie ein Softwareprojekt innerhalb des Budgets, zur vollen Zufriedenheit der Kunden, die an die Software gesteckten Anforderungen erfüllt.

Planung

Zum Projektstart werden ein bis zwei Workshops abgehalten. Dabei soll der Rahmen des Projekts abgesteckt werden. Ziel ist es, dass alle Beteiligten ein einheitliches Bild des Projektumfangs haben und eindeutig definiert ist wann und durch welche Kriterien das Projekt als erfolgreich gilt.

1. Workshop: Strategie/Konzeptionsome text
   • Zieldefinition - Wann ist das Projekt erfolgreich?
     Am Anfang steht das Ende. Die Definition wird sich im Laufe des/der Workshops noch ändern, aber jeder sollte gleich zu Anfang die Vorstellungen der Anderen darüber kennen, damit nicht in unterschiedliche Richtungen gearbeitet wird.
     Jeder hat unterschiedliche Vorstellungen davon, was ein erfolgreiches Projekt ist. Die Beteiligten müssen sich über die gegenseitigen Sichten Bewusst sein, damit die Umsetzung den Vorstellungen der Entscheider gerecht werden kann. Dabei wird zudem auch klar, ob diese Vorstellungen überhaupt umsetzbar sind.
     Erarbeitet wird die Definition klassisch mit Zettelchen, die an eine Wand geklebt werden.
     Umsetzung durch: Sticky Notes
   • Was soll mit der Software erreicht werden?
     Im Endeffekt muss die Anwendung bedient werden. Hier muss sich jeder in die Rolle des Users versetzen und überlegen welche Funktionen für die User einen Mehrwert bieten. Festgehalten wird das natürlich in User Stories. Die Sitemap dient dazu die Stories in ein Gerüst für die spätere Userführung einzuarbeiten und den nächsten Schritt vorzubereiten.
     Ergebnis: User Stories per Stift und Papier, Sitemap
2. Workshop: Feinkonzeptsome text
   • Funktionsdefinition - Was ist nötig, um den Usern einen Mehrwert zu bieten, so dass sie die Software langfristig nutzen wollen?
     Selbst wenn im Vornherein viel darüber geredet wurde, hat üblicherweise jeder noch immer andere Bilder der fertigen Anwendung im Kopf. Diese entscheiden aber im Wesentlichen über den Umfang des Projekts.Hier werden Wireframes der einzelnen Screens angefertigt. Allein die Anzahl wird gerne unterschätzt, aber auch die Funktionen der Screens werden hier erst deutlich. Aus ihnen ist schon sehr gut die Usability ablesbar, aber auch die Anforderungen an die Geschäftslogik werden deutlich.
     Ergebnis: Wireframes
   • Wie soll die Anwendung das definierte Ziel erreichen?
     Hier steht die Qualität der Anwendung im Vordergrund, sprich ihre Beschaffenheit. Wie soll sie aussehen? Wie soll sie mit dem User interagieren?
     Mit Mockups beschreiben wir wie die Anwendung aussehen soll. Ohne schon das genaue Design festzulegen, sollen die Mockups vorab einen guten visuellen Eindruck der späteren Anwendung vermitteln.
     Der Klickdummy soll die Abläufe und Interaktionen der Anwendung demonstrieren, ohne alle Funktionen abzubilden.
     Ergebnis: Mockups, Klickdummy

Bei der Umsetzung der Wireframes, Mockups und Klickdummies kann es durchaus Sinn machen diese Außerhalb der Workshops fertigzustellen. Hier sollten die Zwischenschritte aber durch einen Kundenvertreter oder besser einen der Entscheider vor-abgenommen werden, bevor sie final präsentiert werden.

In den weiteren Schritten gehe ich nicht allzu tief ins Detail, da die Themen eigener Artikel würdig sind.

Prototyp

Der Prototyp sollte die zentralen Elemente und Customer Journeys so abbilden, dass die Entscheider einen möglichst genauen Eindruck davon bekommen, wie die fertige Anwendung aussieht und sich anfühlt. Dazu gehört auch die Ausarbeitung eines Design Systems, nach welchem der Prototyp entworfen werden kann. Welche Funktionen der Prototyp genau beinhalten und wie weit er das Design abbilden soll, wird schriftlich festgehalten.

Die Beteiligten sollten sich jetzt, durch die vorhergegangenen Schritte, gut in den User hineinversetzen können und finden eine detaillierte Simulation des finalen Produkts vor - natürlich mit eingeschränktem Funktionsumfang. Diese können sie jetzt begutachten und letzte Feinschliffe beauftragen, bevor sie "in Produktion" geht.

Prototypen sind allerdings nicht immer nötig. Gerade bei kleineren Anwendungen kann es sein, dass man sich gegenüber der direkten Implementierung nicht viel Zeit spart, sondern eher doppelte Arbeit hat. Wenn der Tech-Stack es zulässt kann es durchaus Sinn machen den Prototypen mit einem Low-/No-Code-Tool umzusetzen, welches erlaubt den Code für die weitere Umsetzung zu exportieren.

Umsetzung

Kern der Umsetzung sind die Ausarbeitung eines Architektur-Konzepts, Konzipierung und Einrichtung einer CI/CD-Pipeline, samt Testautomatisierung und natürlich die Entwicklung.

Den Rahmen gibt allerdings das Projektmanagement vor - auch bei selbstorganisierenden Teams (PO und Scrum-Master). Es muss dafür sorgen, dass die Leute arbeiten können, den Status im Auge haben, Probleme aus dem Weg schaffen, auf Veränderungen reagieren... Aber auch hierfür ist ein eigener Artikel nötig.

Soll im Rahmen des Projekts ein Produkt entstehen, oder auch bei Anwendungen, die einer breiten User-Basis zur Verfügung stehen werden, macht es Sinn zuerst ein MVP zu entwickeln, um möglichst schnell User-Feedback einzuholen und entsprechend zu reagieren.

Fazit

Abschließend bleibt zu sagen, dass natürlich nicht alle Planungsschritte für jedes Projekt zwingend nötig sind. Man sollte aber nicht bei den falschen Schritten sparen. Gerade die Definition eines erfolgreichen Projekts ist für selbiges essenziell. Bei den Wireframes, Mockups und dem Klickdummy bietet es sich eher an diese in einem Tool zu erstellen, welches alle drei erstellen kann. Zumindest aber die wichtigsten Wireframes sollten im Workshop auf Papier gezeichnet werden.

PS: je nach Größe des Projekts variiert natürlich auch der Umfang der einzelnen Schritte.

‍