in Allgemein, Methoden, Praxistipps, Tools

A fool with a tool is still a fool

Die Quelle ist nicht ganz klar (dazu Wikiquote), aber diese Regel wird oft zitiert und ihre Gültigkeit nie bezweifelt. Auch ich will dem nicht widersprechen, allerdings eine ergänzende Regel aufstellen: Only a fool works without a tool.

Die Frage ist allerdings, welche Tools man wählt und welche Auswirkung die Wahl von Tools auf das Ergebnis haben.

In einem meiner ersten Softwareprojekte hatte der Auftraggeber, ein großes deutsches Versicherungsunternehmen, gerade ein neues Vorgehensmodell für IT-Projekte definiert. Es bestand in einer Abfolge von Formularen, die zu befüllen waren. Rasch stellte sich heraus, dass diese Vorgaben für unser konkretes Projekt nicht zielführend waren. Als wir allerdings vorschlugen, entsprechende Anpassungen vorzunehmen, war der Projektleiter des Kunden strikt dagegen. Wir beantworteten also weiterhin teilweise sinnlose Fragen und ließen wichtige Fragen unbeantwortet. Das Werkzeug, nämlich eine Folge von strukturierten Spezifikationsdokumenten, bestimmte den Inhalt unserer Arbeit. Die eigentliche Aufgabe, nämlich die Vorgaben für ein neues Bestandsführungssystem dieser Versicherung zu erarbeiten, trat immer mehr in den Hintergrund. Das Werkzeug hatte sich verselbständigt. Ich wurde aus dem Projekt bald wegen meiner dauernden Aufmüpfigkeit entfernt und war auch erleichtert. Jahre später hörte ich, dass das Projekt gestoppt und der Projektleiter gekündigt worden waren.

Was habe ich daraus für meine späteren Projekte gelernt?

Keinesfalls, dass die Verwendung von Werkzeugen per se schädlich ist. Allerdings doch ein starkes Misstrauen gegen Vorgehensmodelle und damit verbundene Methoden und Werkzeuge. Man muss immer wieder die Frage stellen, ob diese bei der Arbeit an der eigentlichen Aufgabe unterstützen oder von dieser ablenken.

Es geht nicht ohne Tools, aber sie sind keine Erfolgsgarantie

Nach vielen Jahren Erfahrung kann ich sagen, dass die in der Anforderungsdefinition am häufigsten angewandten Werkzeuge Word, Excel und Powerpoint sind. Wenn es um Projektplanung und Projektcontrolling geht, ist das Excel. Warum? Es sind sehr flexible und leicht zu nutzende Werkzeuge, die man der jeweils gegebenen Aufgabe und Situation anpassen kann. Ihr Nachteil ist, dass man immer wieder auf der grünen Wiese beginnt und jedes Projekt anders vorgehen kann. Daher gibt es auch zahllose Templates mit unterschiedlich hohem Strukturierungs- und Reifegrad, die dann projektspezifisch angepasst werden.

Methoden und Werkzeuge für das Requirements-Engineering gibt es natürlich in großer Zahl, einen Überblick zur aktuellen Literatur findet man hier. Viele leiden allerdings darunter, dass sie für Anwender schwer erlern- und handhabbar sind.

Gute Erfahrungen habe ich in mehreren Projekten mit JIRA gemacht. Die Einrichtung dieses Tools in einer Form, die sich auch für Anwender eignet, lohnt sich allerdings nur in größeren Projekten. Dort ist es aber Pflicht, in so ein Tool zu investieren, weil das Pflegen von Excel-Listen rasch ins Chaos führt.

Entscheidend ist es, den Übergang von Word und Excel zu einem spezifischen Tool nicht zu verpassen. Beginnt man irgendwie und hat man einiges an Inhalt bereits produziert, ist die Umstellung auf ein Werkzeug schwierig; man schleppt erfahrungsgemäß bis zum Abschluss des Projektes Altlasten mit. Daher gleich am Anfang über die Notwendigkeit und Sinnhaftigkeit eines spezifischen Tools nachzudenken und dieses von Anfang an einsetzen. Wenn das verabsäumt wurde, muss man bei einer späteren Umstellung genügend Aufwand dafür einplanen und braucht auch entsprechenden Nachdruck, dass die Umstellung gelingt.

Henne oder Ei, Methode oder Tool – was kommt zuerst?

Oft hört man auch, dass man zuerst festlegen muss, wie man arbeiten will, dann soll man das passende Tool wählen. Klingt auch sehr vernünftig, ist aber trotzdem nicht ideal, wenn man es zu streng sieht. Es ist richtig und wichtig, sich zu überlegen, was man wie abarbeiten will. Aber wenn man das grob skizziert hat, sollte man Tools unter diesem Gesichtspunkt sichten. Dabei lernt man viele Möglichkeiten kennen, an die man nicht gedacht hat, denn in den Tools haben sich die Erfahrungen zahlreicher Menschen mit ähnlichen Aufgabenstellungen niedergeschlagen. Diese Erfahrungen wertet man aus und überarbeitet seine Vorgaben. Dann geht man nochmals an die Toolauswahl und vielleicht wiederholt man diesen Vorgang sogar mehrere Male. Ein Spiralmodell des Vorgehens ist also auch hier der beste Weg.

Wenn Sie regelmäßig über neue Blogposts informiert werden wollen, tragen Sie sich bitte hier ein. Bitte öffnen Sie dann Ihr Postfach und klicken Sie auf den Bestätigungslink, andernfalls wird die Anmeldung nicht wirksam („Double-Opt-In“).

Ihre Adresse wird nicht weitergegeben. Sie können sich jederzeit mit einem Klick wieder abmelden.

Schreibe einen Kommentar

Kommentar

Webmentions

  • weed in lucerne

    … [Trackback]

    […] There you can find 41822 additional Info on that Topic: it-governance.blog/a-fool-with-a-tool-is-still-a-fool-2/ […]

  • live models

    … [Trackback]

    […] Read More Information here on that Topic: it-governance.blog/a-fool-with-a-tool-is-still-a-fool-2/ […]