Nein!

Einfach nein. Was ist daran so schwer? Öfter mal nein sagen. Ach ja, dann ist man ja nicht sozial kompetent. Und klar, immer geht irgendwas. Herumgestümper zum Beispiel. Besonders in der Software-Entwicklung sehr weit verbreitet. Anstatt ein “nein, das geht nicht” oder ein wenig diplomatischer “nein, das geht jetzt nicht, wir können später darüber nachdenken” muss es weichgespült umschrieben werden. Ja, das geht, aber ist schwierig, weil dieses und jenes Feature dem gegenüber steht, und erst dieser oder jener Hotfix eingespielt werden muss, der wiederum Abhängigkeiten gegenüber… Blablabla! Ein nein wäre kürzer, prägnanter, verständlicher. Und der liebe Kunde, der nichts zusätzlich zahlen, aber Dutzende eigener Features implementiert haben will. Schön umschreiben, dies und jenes ist zwar eigentlich so nicht vorgesehen, aber wenn dies und jenes implementiert würde, könnte und würde und was auch immer. Und es wird weiter versprochen, was nicht zu halten ist. Insofern kein Wunder, dass Software-Entwicklungsprojekte zu einem hohen Prozentsatz nicht termingerecht fertig werden. Oder mehr Aufwand fordern, der sich in Kosten nieder schlägt. Ob direkte oder Opportunitätskosten. Und dieser Umstand wird weiter gegeben, denn hinten scheißt die Ente. Dass zu wenig Entwicklerkapazität vorhanden ist, ist von vornherein völlig verständlich, aber findet keine Berücksichtigung, denn dieser eine Kunde ist ja eminent wichtig, und der andere ebenfalls, und der nächste natürlich gleichsam… Schonmal von Context-Switching gehört und wie viele Ressourcen damit verloren gehen? Auf unzureichende Pläne und deren Nicht-Ausführung will ich gar nicht näher eingehen. Neudeutsch heißt das dann ja “wir sind agil”. Dass agil nicht gleichzusetzen ist mit schnell, haben zwar die Entwickler, aber die meisten Manager nicht verstanden. Natürlich ändern sich Anforderungen, das Business ist schnelllebig, es verlangt Dynamik. Aber bitte auf jeder Ebene. Und nicht einseitig, wie es zu oft gelebt wird. Dann steigert es sich zu Featuritis, die niemand braucht. Ich wiederhole – niemand. Anstatt dem Gegenüber mit einem klaren “nein” zu antworten, wird wieder eingelenkt, diskutiert, Kompromisse werden gefunden, die keine sind, sondern einfach die gesamte Entwicklung durcheinander werfen. Und ich meine nicht agile, aber geplante Entwicklung, sondern einfach nur Chaos. Das führt dann eben dazu, dass plötzlich alle Tasks “dringend” eingestuft werden. Davon wird das Ergebnis zwar nicht schneller fertig, aber das Gefühl spielt eine nicht minder entscheidende Rolle, alles ist wichtig und dringend. Vom und für das Projektmanagement natürlich. Und dies ist auch so eine missverstandene Instanz der heutigen Zeit. Oder sagen wir – eine oft missverstandene Rolle.

Was bedeutet Projektmanagement? Die beste Definition, oder Aussage habe ich im Rahmen einer kleinen Auftragsarbeit vor etwa zehn Jahren kennengelernt. Der damals zuständige Projektmanager sagte zu mir, er sei für mich da, um mir als Entwickler den Rücken freizuhalten. Den Rücken frei halten! Das muss man sich einmal bildlich vor Augen führen! Den Rücken frei halten!

Was sehe und erlebe ich zu oft? Das Projektmanager einem genau dort stehen – im Rücken – und zwar, um einen über die Schultern zu sehen, wie weit die aktuelle Entwicklung gediehen ist. Wie weit, wie lange dauert es noch, wieviel Aufwand wird es sein… Die üblichen Fragen – und Phrasen. Dass das das genaue Gegenteil von dem ist, was Kern ihrer Aufgabe sein sollte – geschenkt… Wir haben uns ja bereits daran gewöhnt. Und da wird erneut nicht einfach mal “nein” gesagt, sondern mit denselben Weichei-Phrasen geantwortet. Sonst – siehe oben, die soziale Kompetenz der Entwickler sei gerüchteweise sowieso nicht vorhanden, also wird sich Mühe gegeben, dieser Auffassung entgegen zu wirken. Und der Teufelskreis aus Featuritis, Fehlplanung und Herumgestümper beginnt von vorne. Wenn Bauingenieure ihre Brücken so bauen würden, wie Software entwickelt wird, würde ich lieber durch den Rhein schwimmen, es wäre weniger gefährlich. Und was spricht dagegen, sich auf Kernfeatures zu konzentrieren, diese auszubauen, diese vor allem stabil zu implementieren, und danach neue Funktionen zu realisieren? Ach ja, der Kunde verlangt… Gestern… Dann wird es komplex, es entstehen Abhängigkeiten, der letztlich zu unwartbarem Code führt. Ein Reengineering wäre angebracht. Aber da steht ja der nächste Kunde. Und wieder kein “nein”, sondern ja, vielleicht, das geht, irgendwie, können wir noch, kann man mal eben, der Quickfix muss noch rein, und so weiter…

Von Henry Ford soll das Zitat stammen “Wenn ich die Menschen gefragt hätte, was sie wollen, hätten sie gesagt, schnellere Pferde”. Danke. Das Beispiel ist zwar mehr als hundert Jahre alt, aber was hat Steve Jobs getan? Die Gebrüder Albrecht? Ingvar Kamprad? Leider sind derartige Unternehmerpersönlichkeiten heute zu selten vorzufinden. Und – um es deutlich zu benennen – es sind die typischen Beispiele von Erfolgsgeschichten, die auf Einfachheit anstatt Komplexität basieren. Benutzerfreundlichkeit. Überschaubarkeit. Wenn ich in einen Aldi gehe, finde ich mich sofort zurecht. Das User-Interface ändert sich nicht permanent. Bei Ikea werde ich keinen Barcelona-Chair finden, und bei Apple – bis jetzt – keine Spielekonsole. Auch wenn sich auf iPads und dem Rest der Apple-Welt hervorragend spielen lässt. Dem gegenüber steht das Modell, auf jeder Ebene präsent zu sein, im Sinne von “Diversifikation”. Kann funktionieren, muss es aber nicht. Vor allem dann nicht, wenn weder die Kompetenz, noch die Ressourcen vorhanden sind, um sich in jedem Markt mit jedem Sortiment zu tummeln. Das führt wiederum zu – siehe oben, dem bekannten Teufelskreis, alles irgendwie und noch ein wenig davon und noch ein wenig hiervon, fast wie in einem Kochrezept, nur führen die Zutaten hier nicht zu einem wunderbar genießbarem Mahl, sondern eher zu einem gruseligen Brei, der alles sein will, aber anstatt die einzelnen Positionen heraus zu schmecken, ist es nur eine gräuliche, klebrige Matsche. Zu lange gekocht. Zu viele Köche. Zu sehr darin herum gerührt. Das war es dann mit der Diversifkation. Dabei hätte ein “nein” am Anfang vielleicht geholfen. Vielleicht ist es gewöhnungsbedürftig, möglicherwiese schmerzhaft. Insbesondere für diejenigen, die nicht damit aufgewachsen sind, und denen in teuren Seminaren ans Herz gelegt wurde, Empathie zu zeigen, Verständnis, Ich-Botschaften zu senden, und so weiter. Nur sind Führungskompetenzen nicht nur in der Theorie zu erlernen, sondern es erfordert Übung. Viel Übung. Harte Übung. Und auch mal harte Worte. Und an der richtigen Stelle ein “nein”, während an anderer Stelle ein “ja” geschickter wäre. Und natürlich könnte ich diesen Text nun weiter aufblähen, mit vielen Beispielen füttern, die Kernthesen heraus arbeiten, ein Buch daraus entstehen lassen. Will ich das? Jetzt? Habe ich momentan die Zeit dazu? Nein. War das klar genug? Eigentlich ist es doch gar nicht so schwer.

 Und eigentlich wollte ich hier gar nichts über derartige Themen schreiben, sondern enger beim Titel des Blogs bleiben. Naja, Ausnahmen bestätigen wie immer die Regel. Immerhin ist es keine Ausnahme der Ausnahme von der Ausnahme…

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.