Die Welt ist einfacher als man denkt

Standard

Die Welt ist einfacher als man denkt. Aber warum macht man es uns Softwareingenieuren durch verqueres Abbilden der Realität dann so schwer diese in Code zu gießen.

Advertisements

Zitat – Digitale Transformation, wer transformiert?

Standard

„Wir arbeiten in Strukturen von gestern mit Methoden von heute an Problemen von morgen vorwiegend mit Menschen, die die Strukturen von gestern gebaut haben und das Morgen innerhalb der Organisation nicht mehr erleben werden.“

Knut Bleicher, Ehrenpräsident der Gesellschaft für integriertes Management

Geschäftsprozesse versus Softwarequalität – a bisserl a Satire

Standard
Aber nur a bisserl a Satire.
Vorneweg, es gibt Software und Software. Die eine ist weniger von Geschäftsprozessen betroffen, das Paket ist so, wie es ist. Man kann es in bestimmtem Umfang customizen (anpassen, konfigurieren), zahlt dafür Lizenzen, hat dafür eine feste Funktionalität. Der Stakeholder (Prozess / IT) verbiegt sich, um die Geschäftsprozesse halbwegs darin abzubilden und wundert sich, dass die Anwender murren. Über diese Art Software möchte ich hier nicht sprechen.
Dann gibt es Software, die kundenspezifisch erstellt, nach den Anforderungen des Kunden maßgeschneidert wird (aber natürlich wenig kosten soll). Also unser Metier bei Z&P. Hier ist die Spielwiese, hier kann sich der prozessorientierte Anwender erst einmal wiederfinden und die Jahre vorher in zig Besprechungen ermittelten Anforderungen an die Software stellen (Phase der enthusiastischen Begeisterung).
Der Stakeholder kann sich austoben, seine Wünsche äußern, neue Prozessvarianten erfinden. Am besten während der Realisierung ständig Verfeinerungen einbringen oder auch mal alles umwerfen oder erkennen, das man in der jahrelangen Vorarbeit irgendwie nicht wirklich was entscheidendes formuliert hat (einsetzende plötzliche Verwirrung). Das ist die Phase, in der der Product Owner (Entwicklungsseite) nicht mehr versteht was der Stakeholder (Auftraggeber) will (Phase der totalen Verwirrung).
Denn, der eine Anwenderkreis arbeitet so und möchte gerne diese Unterstützung und hat eine andere Sicht auf die Dinge wie der andere Anwenderkreis. Und bitteschön, da wir heutzutage nicht mehr kommunizieren können (In der Tat ist die telefonische Erreichbarkeit im Zeitalter von Handys schlechter als früher, da man in Besprechungen nun mal nicht auf Anrufe reagiert), dann bitte automatische Benachrichtigungen. => „Ich habe nichts bekommen, deshalb habe ich nichts gemacht.“ Hmm. Also wieder ein Protokollsystem für das Verschicken der Mails eingebaut. Aha, man kann’s nun beweisen. Wirklich? Wichtig, die Anwender müssen gesteuert werden, damit der Prozess funktioniert (manche verlernen dabei das Denken).
Wichtig in dieser Phase: die ständige Anpassung des Terminplans, die ja am nächsten Tag wegen neuer Anforderungen nicht mehr gilt. An irgendwas muss man ja seine Key Performance Indicators festmachen.
Tja, schon ist es nichts mehr mit dem Motto: „Einfacher ist besser“.
Schön ausgedachte Algorithmen werden nun geändert. Neue kommen hinzu. Die Zeit wird knapper, auch weil man eigentlich fertig werden müsste, aber der Stakeholder nicht mit seinen Vorstellungen und Entscheidungen aus den Puschen kommt und das Budget in der Regel schon durch die Besprechungen aufgebraucht wurde. Also entscheidet die Entwicklung sich für die Notbremse, Vereinfachungen, das Machbare (Phase der totalen Ernüchterung).
Unbestreitbar, nun ist es vorbei mit einer guten Softwarequalität, -strukturierung, – dokumentation,…
Termindruck. Da testet man halt was geht und macht keinen Plan mehr. Hatte man am Anfang zwar mal, ist aber voll agil über den Haufen geworfen worden.
Keyuser Test. Wenn da mal was getestet würde. Keiner hat Lust, keiner hat Zeit. Ausnahmen bestätigen die Regel. Alles ok, wir gehen produktiv.
2 Jahre später oder noch später. Unglaubliche Fehler enthüllen sich. Anwender melden komische Verhaltensweisen. Inzwischen wurden schon viele AddOns entwickelt, sogenannte Rucksäckchen. Neue Abläufe, basierend auf den Dingen der Vergangenheit, realisiert.
Und wer ist schuld? Na, die Software!

Softwarequalität – Die Beschreibung und Überprüfung der Anwendungsfälle hilft

Standard
Aus vielen Erfahrungen wissen wir nur zu gut, dass die Qualität der erstellten Software nicht nur von der Ausführung der Programmierung und dem damit verbundenen Know How abhängt, sondern im besonderen Maße von der Ermittlung des eigentlichen Bedarfs und den Wünschen des Endanwenders.

 

 Die kann dieser natürlich ohne Anleitung erst einmal nicht formulieren. Ein gemeinsames Ergründen wird erleichtert, wenn man zumindest dieselbe Sprache spricht. Was oftmals nicht der Fall ist bei IT meets User.

 

Hier scheitern letztendlich auch viele Projekte oder fangen an kostspielig zu werden. Ich denke, diese Erfahrung macht jeder Softwareersteller mindestens einmal in seinem Leben.

 

 Da wir von Zoz & Partner uns meist im technischen Umfeld bewegen und viele von uns selbst Ingenieursausbildungen haben, fällt uns die Kommunikation mit den Anwendern in diesem Bereich leichter. Wir sprechen zumindest eine ähnliche Sprache wie unsere Kunden. Aber auch hier zählt die Erfahrung und das Entwickeln einer Ahnung was das Gegenüber nun gemeint haben könnte.

 

 Das grafische Beschreiben der Anforderungen in allgemein verständlichen Abläufen hat sich bei uns zur gemeinsamen Niederschrift mit dem Kunden bewährt. Ein Tool zur Prozessmodellierung erweist sich dabei sehr hilfreich.

 

Doch, wie es sich immer wieder zeigt, sollten die mit dem Kunden ermittelten Anforderungen an relevanten Meilensteinen des Projekts überprüft und gegebenfalls korrigiert werden. Oftmals fallen dem Kunden, wenn er die bereits entwickelten Module sieht, erst noch wichtige, aber bisher vergessene Anforderungen ein, die das zu entwickelnde Programm abdecken muss, um anwendbar zu sein oder eine genügende Akzeptanz zu entwickeln.

 

Leider sind wir nicht immer so perfekt wie wir gerne sein möchten. Wir lernen täglich dazu. Einmal sich zu sicher gewesen, einmal vergessen nachzuhaken. Schon ist es passiert.
Habe mehr als einmal erlebt, dass trotz Beschreibung und schriftlich bestätigter Agreements die realisierte Funktion nicht in Betrieb ging bzw. die Änderungen zurückgebaut wurden.

 

Zu diesem Thema könnte man ein ganzes Buch schreiben.

 

Kommentare / Meinungen sind gerne willkommen.