Seien Sie nicht so nett!

Ich gebe zu, dass dies stark von den eXtreme Programming-Leuten beeinflusst ist, aber ich sehe es immer wieder: Wir Techniker waren in der Vergangenheit viel zu schnell bereit zu sagen: „Klar, das können wir machen“. Schlimmer noch, ich habe es selbst schon viel zu oft getan.

Ja, wir wollen „Teamplayer“ sein. Nein, wir mögen keine Konflikte. Ja, oft sind die Änderungen, die wir vornehmen sollen, technisch „interessant“ und wir mögen Herausforderungen. Das alles spielt keine Rolle. Wir versagen bei unseren Aufgaben, wenn wir dem „wir können das“ nicht das wichtige Etwas hinzufügen: „Es wird einen Monat meiner Zeit in Anspruch nehmen und die Funktionen X, Y und Z werden nicht in der nächsten Version enthalten sein. Ist diese Funktion es wert?“. Ich finde es erstaunlich, wie oft die Antwort „Vergessen Sie es“ lautet. Und die neue Funktion kommt auf die Liste der „zukünftigen Versionen“. Und dann gerät sie in Vergessenheit, weil andere, höherwertige Funktionen Vorrang haben.

Und noch schlimmer ist der Post-Mortem. Da sagt der angeschlagene Techniker zu seinem Auftraggeber: „Die Funktionen X, Y und Z sind nicht im Produkt enthalten, weil wir die von Ihnen gewünschte Funktion H eingebaut haben. Es hat länger gedauert, als wir dachten, obwohl es einfach klang“. Und der Stakeholder antwortet: „Ich habe nur laut gedacht, es war nicht so wichtig. Gefolgt von dem niederschmetternden Kommentar: „Und mir gefällt sowieso nicht, wie es funktioniert“.

Wichtiger Hinweis: Ich schimpfe keineswegs über die Beteiligten. Nun, nicht wirklich. Ich schimpfe über die Techniker (ich denke, ich habe das Recht dazu, denn ich bin seit 30 Jahren einer). Die Stakeholder können einfach keine rationalen Entscheidungen über die Zuweisung von Ressourcen treffen, ohne die Kosten zu kennen. Ich schimpfe ein wenig über das Management, wenn es sich nicht um diese Kosteninformationen bemüht, aber wir können das Verhalten der anderen nicht kontrollieren, wohl aber das unsere. Wir können es uns zur Gewohnheit machen, dem Management Kosten-/Aufwandsinformationen vorzulegen. Wenn sich die Geschäftsleitung konsequent weigert, diese Informationen zu verwenden, sollten Sie sich einen anderen Arbeitgeber suchen, vor allem, wenn Sie für Projektverzögerungen verantwortlich gemacht werden. Aber hören Sie auf zu jammern, dass das Management unangemessene Forderungen stellt, wenn es keine Kosteninformationen hat, weil wir sie ihm nicht gegeben haben.

In der Welt von Solr/Lucene äußert sich das oft darin, dass man endlos daran herumschraubt, wie Solr die Ergebnisse zurückgibt, nachdem jemand einen Blick auf die Ergebnisse geworfen und gesagt hat: „Das ist nicht richtig, wir würden bessere Ergebnisse erhalten, wenn wir…“.

Was meine ich mit „undefiniert“? Nun, wenn Sie keinen objektiven Maßstab für die „Güte“ einer Suche haben, können Sie nur raten. Noch schlimmer als das Raten ist die Tatsache, dass ein und dieselbe Person dieselben Ergebnisse an zwei verschiedenen Tagen betrachten und die „Güte“ unterschiedlich bewerten kann. Und ich habe noch nicht einmal die Probleme erwähnt, die entstehen, wenn man versucht, zwei verschiedene Interessengruppen zufrieden zu stellen!

Wenn ich hier auf den Tisch haue, dann ist es die Definition Ihres Problems, bevor Sie die Lösung implementieren, manchmal auch bekannt als „das XY-Problem“. Die Leute fangen sofort an, eine Lösung für ein Problem zu implementieren, ohne das Problem zu verstehen, obwohl das Problem in Wirklichkeit etwas ist, das mit einem anderen Ansatz viel besser gelöst werden könnte.

Wann immer Sie sich dabei ertappen, dass Sie sagen „Klar, das können wir machen“, wenn ein Stakeholder (oder irgendjemand anders) eine Lösung für das Problem vorschlägt (z.B. „Wir würden bessere Ergebnisse erzielen, wenn wir nicht stemmen würden“), halten Sie inne. Dann halten Sie inne. Dann atmen Sie tief durch. Fragen Sie: „Warum glauben Sie das?“ Schauen Sie sich dann Ihre Daten an. Denken Sie dann ein paar Minuten über die unbeabsichtigten Folgen der Änderung nach. Dann überlegen Sie, ob es bessere Lösungen gibt. Dann denken Sie darüber nach, den Vorschlag tatsächlich umzusetzen. Oder bieten Sie eine Alternative an.

Gehen Sie niemals, niemals, niemals direkt zurück an Ihren Schreibtisch und beginnen Sie mit der Umsetzung des Vorschlags, ohne zumindest ein paar Minuten damit zu verbringen, das Problem zu definieren und Alternativen zu erwägen. Vor allem Alternativen, deren Umsetzung weitaus weniger Zeit in Anspruch nehmen würde und die zu Ergebnissen führen würden, die „nahe genug“ sind. Das Streben nach den letzten 5% „besser“ lohnt sich selten. Ich vermute, dass Sie weitaus größere Probleme haben, denen Sie mehr Aufmerksamkeit schenken sollten als den letzten 5%. Vor allem, wenn Sie „besser“ nicht objektiv messen können. Und selbst wenn Sie ein objektives Maß haben, ist eine Verbesserung von 5% Ihre Zeit wert?

Ja, dies ist ein „Wetware“-Problem. Es ist nicht produktiv, wenn Ingenieure ihre Zeit damit verbringen, zu den Stakeholdern zu rennen und zu fragen: „Ist es das wert?“ Wer weiß, vielleicht führt das sogar zu mehr Meetings (schaudern). Sie würden Ihre Zeit lieber mit etwas Interessantem verbringen, z.B. mit Programmieren. Aber das ist unerlässlich:

– Produktmanagement
– Ihr Produkt rechtzeitig auf den Markt bringen
– Ihr Unternehmen generiert, Sie wissen schon, Einnahmen; der unangenehme Teil des Geschäfts, der… ähm… Ihr Gehalt bezahlt
– Ansonsten rechtfertigen Sie, dass Ihr Unternehmen Geld für Techniker wie Sie ausgibt

So, ich glaube, ich bin fertig mit dieser Tirade. Der Auslöser war die Tatsache, dass ich immer wieder Lösungen für Probleme gesehen habe (und an ihnen beteiligt war), die entweder das Problem nicht wirklich angegangen sind oder teuer waren und nur minimale Vorteile brachten. Je mehr ich mir angewöhnt habe, innezuhalten und ein paar Minuten über das Problem und nicht über die erste angebotene Lösung nachzudenken, desto häufiger habe ich festgestellt, dass es für das Unternehmen von großem Nutzen sein kann, wenn die verschiedenen Interessengruppen die mit der Umsetzung von Veränderungen verbundenen Kosten verstehen. Und folglich auch ein großer Nutzen für mich. Ich verbringe viel weniger Zeit mit Arbeiten, die sich als wenig wertvoll herausstellen, und mehr Zeit mit Dingen, die wichtig sind.

Ingenieure sind so.