Mein erstes IT-Projekt als Benutzer..

Bisher war ich bei eigentlich allen IT-Projekten – ob Software oder Infrastruktur – immer auf der IT Seite beschäftigt oder irgendwo in der Schnittstelle von Business zu IT. Alle diese Projekte konnten durchgeführt und abgeschlossen werden, aber es wäre natürlich gelogen und/oder die Situation massiv beschönigt wenn ich sagen könnte, da lief immer alles rund. Klar ist, ein paar Fehler macht man nur einmal, andere „ergeben“ sich eigentlich immer wieder. Diese sind extrem ärgerlich, aber manchmal nicht wirklich zu vermeiden – dass zum Beispiel der gewünschte Funktionsumfang von Lösungen während des Aufbaus einer Lösung zunimmt hat sich wohl als „normal“ erwiesen.

Nun kann ich zum ersten Mal in meinem Arbeitsleben auf ein Projekt als Benutzer „drauf“ schauen, ohne jegliche Verantwortlichkeiten ausser dem „liefern“ von zum Beispiel Stammdatenmutationen usw. Ich will hier in keiner Weise beurteilen, wie das von mir angeschaute Projekt läuft, dazu habe ich viel zu wenig tiefen Einblick und auf Grund von Terminverzögerungen die Projektqualität zu beurteilen wäre zu einfach und unter Umständen unfair. Eigentlich überlege ich mir nur, welche Seite ist „besser“??

All die Probleme mit konventionellen Projektmanagementmethoden bei der Softwareentwicklung scheinen nun durch „agile Methoden“ gelöst. Tatsächlich adressieren diese einige Problemfelder wie eben zum Beispiel der zwingend wachsende Umfang im Laufe des Projektes. Ebenso lassen Sie ein Mass an Chaos zu, welches immer wieder geordnet wird …. also entstehen neue, gänzlich andere Probleme. Zumindest habe ich mir das so vorgestellt……

Ja, der Beginn ist anders – es gibt keine ins Detail getriebene Pflichtenhefter mehr, es gibt Stories, User-Stories, Story-Boards – einige Begriffe anders für eine auch tatsächlich andere Vorgehensweise. Nur, wer ist denn der „User“ – die Frage bleibt oder wird noch wesentlich zentraler. Unter Kollegen und selbst erlebe ich, dass der interne, administrative Benutzer oft weit in den Hintergrund gedrängt wird bei den User-Stories. So gibt es umfangreiche solche Stories wie sich ein Kunde von extern auf die Systeme verbindet, sucht, eventuell (hoffentlich) Leistungen in Anspruch nehmen könnte. Die Pflege im Hintergrund wird dadurch abgeleitet – auch gut – nur, entsteht da immer etwas, das zu warten, zu bedienen ist für den internen User? Ich denke nein, nicht immer, aber wir haben dem Kunden zu dienen – die Panne ist so rum für die Reputation einer Firma sicherlich die einfachere Sache.

Während den Entwicklungsphasen konnte ich persönlich nicht allzu gravierende Unterschiede zum Beispiel zu einem „Prototyping“ oder gar Vorgehen nach Wasserfallmodell erkennen. Das kommt sicher nicht daher, dass methodisch das sehr nahe liegt sondern eher daher, dass eine reine Form von Vorgehensweisen selten zum Ziel führt. Wasserfallprojekte welche den Rücksprung strikte verweigerten waren zwar manchmal zur richtigen Zeit „fertig“, waren dafür dann funktional unbefriedigend…..also von allem „das Beste“ scheint am besten geeignet zu sein.

Immer problematisch für mich war in Projekte die zeitgerechte und funktional richtige Integration von Stakeholdern – oder kurz, wer muss wann was wissen und/oder tun. Ich würde jetzt mal aus der einen Erfahrung sagen – daran hat sich nichts aber rein gar nichts geändert! Das Management der Stakeholders ist schon zu Beginn schwierig (wer sind diese) und wird im Projektverlauf komplexer. Zu früher Einbezug ergibt sinnlose Diskussionen auf fehlender Basis, zu später Einbezug ergibt unter Umständen Funktionserweiterungen oder Änderungen am laufenden Projekt. Beides kostet am Ende Zeit und somit Geld. Aus meiner Sicht helfen die neuen agilen Methoden in diesen Bereichen nicht wirklich weiter, die Phasen des Chaos lassen eigentlich wenig Integration zu und kurz danach kann unter Umständen schon zu spät sein (weil dann eine „Phase“ oder ein Sprint halt abgeschlossen sind/ist und auf dem Resultat weiter gearbeitet wird – hatten wir das nicht auch beim Wasserfall schon als Problem??).

Aber jetzt wieder zurück auf die Kernfrage – welche Seite ist die „bessere Seite“ in einem Softwareprojekt? Für mich ist der Fall klar – die IT Sicht ist extrem viel spannender – einmal auf der anderen Seite zu stehen würde aber sicher manchem ITler (wie auch mir) gut tun. Das Verständnis für den Benutzer, welcher dann innert kürzester Zeit etwas machen muss, was für Ihn keinen ersichtlichen Nutzen bringt und zumindest kurzfristig nur die Arbeitszeit weiter beengt würde vielen IT-Spezis gut tun. Allerdings gilt das aus meiner Sicht genauso umgekehrt – das Verständnis von Benutzern, nicht immer alles wissen zu müssen zu einem Projekt wäre auch zu steigern. Ich glaube, das wäre auch kein Problem, wenn die IT den Ruf hätte, dass man dann schon informiert wird, wenn es einen braucht!

Fazit: Ich stehe lieber auf der IT-Seite was IT-Projekte angeht. Sehr interessant für mich ist die Tatsache (was allerdings auch eher ein Gefühl von mir ist) dass sich trotz aller Methoden und Möglichkeiten die Probleme in den Projekten nur unwesentlich verändert haben. Ich bin keiner, der an der Vergangenheit hängt – aber trotzdem habe ich manchmal das Gefühl es wurden Methoden erfunden um die unzulängliche Verwendung der alten irgendwie zu kaschieren. IT Projekte dauern länger, kosten mehr und leisten nach der ersten Inbetriebnahme nicht das, was sie sollten. Das war früher so – das ist heute so und nach ein paar Jahren schon dabei befürchte ich fast, das wird auch morgen so sein.

….aber ja, es gibt immer Beispiele für das Gegenteil – ich vermute, diese gibt es komplett unabhängig von der gewählten Methode oder Vorgehensweise. Wenn die richtigen Menschen zum richtigen Zeitpunkt die richtigen Entscheidungen treffen kommt’s gut……