Sonntag, 14. November 2010

9 - Probieren geht über studieren

Denn Labor- und Feldtests liefern tendenziell völlig unterschiedliche Ergebnisse.

Gehen Sie nicht davon aus, dass Ihnen ein auch noch so sorgfältig angesetzter Abnahmetest alles herausfischt, was Ihnen dann in der Praxis das Leben schwer macht. Ein gut aufgesetztes Fehlermelde- und Change-Request-Verfahren, mit entsprechend wohlwollender Abhandlung, bringt Sie da schon wesentlich weiter. Was ist damit gemeint?

Die Frage ist immer, wie sorgfältig und eigenständig Sie selbst Ihre Tester auswählen können. Die IT-Leute finden für jede auch noch so absurd realisierte Softwarefunktion eine logische Erklärung. Die in den Adelsstand der Experten aus der Praxis gehobenen Leute von der Front wissen oft nicht, wie ihnen geschieht, denn so losgetrennt von der täglichen Routine haben sie ihre eigene Arbeit vorher noch nie betrachtet, wie es für die Tests jetzt notwendig wäre. Auf der einen Seite werden sie überfordert sein und auf der anderen Seite sich in Dinge verbeißen, die keine Bedeutung haben. Was ist also die Lösung?

Die Einstellung macht’s! Wie in Ihrer gesamten Arbeit dürfen Sie speziell bei den Tests Ihres Softwaretools nicht Ihr Ziel aus den Augen verlieren. Das Ziel ist ja nicht alleine, eine möglichst fehlerfreie, stabile Software zu haben, sondern ein Werkzeug, das Sie in der Realisierung Ihrer Ideen, Visionen, und geschäftlichen Ziele weiterbringt. Natürlich brauchen Sie eine gewisse „Grundhygiene“, eine Mindestqualität, die Sie nie und nimmer unterschreiten dürfen. Natürlich müssen Sie auch immer im Auge haben, dass mit Ihrem Tool dann keine routinierte Fakturistin arbeitet, bei der das Ergebnis der Arbeit rasch erzielbar und einfach zu 100 % richtig sein muss, sondern Leute davor sitzen haben, die sich in der Interaktion mit dem Softwaresystem neue Erkenntnisse erarbeiten, ihre eigene Zukunft gestalten und planen, Erlebtes nach Wichtigkeit ordnen und wie in einem persönlichen Tagebuch hinterlegen, sich Kollegen gegenüber offenbaren und ihrem Vorgesetzten gegenüber rechtfertigen und damit sogar ihr Einkommen und damit die Sicherheit und Zukunft ihrer Familie verwetten. Das sind die Aspekte, unter denen nun Ihr Softwareprodukt auf dem Prüfstand steht. Und das ist naturgemäß eine Welt, mit der IT-Leute, die für betriebswirtschaftliche Applikationen verantwortlich sind, noch nicht sehr oft konfrontiert wurden.

Setzen Sie sich also selbst in die Tests und sorgen Sie dafür, dass Ihre Tester grundsätzlich und in jedem Testcase, in jeder Fehlermeldung und Diskussion über das Tool Ihr Ziel nicht aus den Augen verlieren. Sorgen Sie aber auch bereits im Vorfeld dafür, dass Sie Tester haben, die Ihnen folgen können, die Sie verstehen können, die mitziehen wollen und trennen Sie sich von Testern, die bloß ihr eigenes Spiel spielen wollen, die die Tests für ihre Zwecke missbrauchen, um auch einmal wichtig zu sein.

Nehmen Sie daher nicht, was Sie bekommen, weil jemand vielleicht gerade Zeit hat, sondern entscheiden Sie, wen Sie brauchen, um ein hochqualitatives Ergebnis (nach Ihrer Definition!) erzielen zu können.

Nachdem auch mit noch so sorgfältig durchgeführten Tests damit noch nichts für die Ewigkeit gebaut ist, müssen Sie sich trotzdem der Dynamik der Implementierung Ihres Tools aussetzen und damit rechnen, dass auch Sie und Ihre Anwender morgen klüger sind als heute. Und das ist gut so und sehr wichtig. Das Tool ist ja wie kein anderes der Dynamik der Geschäftsentwicklung ausgesetzt und auch beeinflusst vom ständigen Lernprozess im Unternehmen. In der Praxis habe ich oft beobachtet, wie rüde mit „guten Ideen“ von Mitarbeitern verfahren wird, wenn Sie nicht schon Jahre vorher in ein Pflichtenheft eingeflossen sind. Im besten Fall bekommt dann der engagierte Einreicher eine E-Mail mit dem Text seines Vorschlages und dem Status „abgelehnt!“. Wird sein Beitrag nicht gewürdigt, wird er Ihnen nie wieder seine Kreativität, Erfahrung, sein Engagement und seine Zeit zur Verfügung stellen! Sie haben einen Mitstreiter verloren und eine Entwicklungschance für die Implementierung Ihrer CRM-Idee verpasst.

PRAXISBEISPIEL
Abnahmetests mit Kollateralschäden
Im Unternehmen A wurde es zunehmend schwieriger, Mitarbeiter aus operativen Bereichen für Tests abgestellt zu bekommen. Das Problem wurde dadurch gelöst, dass die Durchführung der Tests in die Produktionskosten mit einkalkuliert wurde und die Tester aus diesem Budget einen normalen Stundensatz bezahlt bekamen. Der Effekt war der, dass Testkapazität wieder verfügbar und die Qualität der Tester erheblich besser wurde. Aber auch der Druck auf die Qualität der Testdurchführung hat sich erhöhte, weil nun für einen professionellen Stundensatz auch professionelle Leistung erwartet wurde.
Im Unternehmen B hat man den Testaufwand in die operativen Einheiten verlagert, um das IT-Budget nicht zu belasten. Man musste nehmen, was man kostenlos bekommen konnte. Die Tests wurden teilweise als kostenlose Trainingsmaßnahme für Neueinsteiger missbraucht. Das Testergebnis war entsprechend unprofessionell, und die Tests entsprechend langwierig. Die Erwartungshaltung der Tester wurde nicht erfüllt, wodurch auch noch ein Imageschaden für das Produkt noch vor dem Rollout entstand.

Keine Kommentare:

Kommentar veröffentlichen