Wir teilen unsere Lessons Learned
Sharing is caring
„The best thing about sharing is the joy it brings to others. It's not just about making a donation. It’s about making a difference.” ― Unknown, philosopher
Erwartungen genau verstehen
- Wir wollen nicht nur blind abarbeiten, was Auftraggeber fordern. Wir haken so lange nach, bis wir den gesamten Prozess im Blick haben und den wahren Bedarf kennen.
- Unsere ITler schulen in verständlicher Sprache auch nicht-technisch versierte Führungskräfte dafür, sich optimal mit den internen IT-Teams auszutauschen.
- Durch Berichte über den Fortschritt des Projekts bleiben Kunden stets informiert. Etablierte Formate sind Sprint Plannings, Reviews und Retrospektiven.
- Es ist wichtig, frühzeitig herausfinden, wo unrealistische Erwartungen im Aufwand unterschätzt werden und welche Änderungen zusätzliche Kosten verursachen könnten.
Kommunikation
- Oft fehlt das Verständnis bezüglich des Projektumfangs verteilt auf seine verschiedenen Phasen. Da der Fortschritt nicht linear zu dem sichtbaren Ergebnis verläuft, muss sichergestellt werden, dass in technischen Phasen visuelle Ergebnisse den Fortschritt aufzeigen.
- Auftraggeber werden dann als kompliziert empfunden, wenn sie nicht angemessen geführt werden. Viele Iterationen und Prototypen helfen, dieselbe Vision zu formen und Missverständnisse zu vermeiden.
- Auftraggebern mit wenig bis keiner IT-Projekterfahrung fehlt oft das Hintergrundwissen über Best Practices und Prozesse. Nicht durchdachte Funktionen und hierauf basierende nachträgliche Änderungen führen zu Verzögerung. Wir hinterfragen die Anforderungen lieber einmal mehr.
- Verzögerungen im Projektfortschritt können trotz guter Arbeit des Entwicklerteams zu Unzufriedenheit und Unrentabilität führen. Durch regelmäßiges Feedback holen wir alle Stakeholder frühzeitig mit in den Loop.
Visuelle Herangehensweise
- Eine visuelle Darstellung ist von Beginn an unerlässlich, um den Fokus auf die Kernanwendung zu legen. Das gilt bereits für den ersten Prototypen auf Papier sowie für das weitere Testen des Funktionsumfangs.
- Grafische Mockups, Klick-Dummys und Prototypen können hierbei helfen. Sie erlauben allen Beteiligten, sich bereits frühzeitig ein Bild vom Endprodukt zu machen und Feedback zu geben. Dies fördert das Vertrauen und die Kundenbindung. Zudem ist es einfacher, Features zu ändern, die noch nicht implementiert wurden, als bereits existierende Funktionen zu überarbeiten.
- Bedeutung des Testens: Gründliche Tests sind unerlässlich, um Fehler frühzeitig zu erkennen. Auftraggeber sollten nicht nur den Positiv-/Optimal-Weg testen, sondern so testen, dass sie Fehlverhalten provozieren.
- Einbeziehen des Endnutzers: Dieser sollte im Testprozess eingebunden werden, um sicherzustellen, dass die Software intuitiv und benutzerfreundlich ist.
Wording
- Klare und konsistente Kommunikation ist entscheidend. Traditionelle Anforderungsdokumente nach Wasserfall-Methode sind dabei nicht immer ideal.
- Einheitliche Sprache: Ein konsistentes Vokabular hilft, Missverständnisse zu vermeiden.
- Begriffslegende: Ein Glossar erleichtert die Kommunikation mit technischen und nicht-technischen Stakeholdern.
- Flexibilität in der Dokumentation: Nur das Wesentliche sollte dokumentiert werden, um Agilität zu bewahren. Mockups und Quellcode sollte die verständlichste Dokumentation darstellen.
Zusammenarbeit
- Nachbetreuung ist genauso wichtig wie die eigentliche Projektarbeit. Software soll langfristig optimal nutzbar sein und auf Veränderungen im Geschäftsalltag reagieren können.
- Statt Fehler zu wiederholen, sollte aus ihnen gelernt werden. Gemeinsame Retrospektiv-Meetings stellen hilfreiche Weichen für den Lernprozess.
- Support nach Projektabschluss: Ein fortlaufender Support sichert die langfristige Funktionsfähigkeit der Software.
- Feedback-Schleifen: Konstruktives Feedback wird geschätzt und zur ständigen Verbesserung genutzt. Kunden werden in jeden Schritt des Entwicklungsprozesses einbezogen.
