Auf mich hört ja keiner ...

[Alexander (HH)]

Moin Moin!

2. der Entwickler leidet unter enormem Zeitdruck und muss "schnell schnell" alles fertigbekommen, kann sich die Zeit aber nicht dafür nehmen.

An dieser Stelle ist der Entwickler auf einer ganz anderen Ebene gefordert, als zur Entwicklung: Er muss, wenn er seinen Job und sich selbst ernst nimmt, klar gegenhalten, wenn ein Terminwunsch nicht geht. Er muss NEIN sagen.

Insbesondere muss er NEIN sagen, NEIN meinen, und dann diese Aussage auch durchhalten. Wenn er NEIN sagt, es dann aber dennoch versucht, und dann scheitert, ist er der Doofe. Wenn er NEIN sagt, trotz hohem Drucks, und sein Chef glaubt ihm nicht, dann ist der Chef der Doofe, weil er trotz gegenteiliger Aussage nach außen kommuniziert hat, es ginge doch.

Und der Chef hat in diesem Fall auch die Chance verspielt, die wahren Interessen hinter dem Termindruck zu ermitteln und zu erforschen, was zu dem Termin tatsächlich geliefert werden soll - und warum.

Aktuelle Situation bei meinem aktuellen Projekt. Chef hat überhaupt nicht verstanden, wie umfangreich das Projekt werden muß. Also sagte er mit hemmungslosem Optimismus und ohne Rückfragen einen völlig unrealistischen Termin zu, und muß das jetzt ausbaden.

Ob der Entwickler tatsächlich eine Null ist oder eben nur unvollständig gearbeitet hat erkennt man daran, dass die grundlegenden Teile sauber ausgearbeitet sind, der Rest aber dreckig drangebaut wurde.

Nach dem Kriterium war $VORGÄNGER eine Null.

[...]

Und was bringt das dann genau? Ok, kommt natürlich auf die Situation an, aber in der Regel ist es doch so:

Entwickler hat eine gut begründete Position, wie eine Anforderung in Software umzusetzen ist.

Chef hat die Argumente gehört und sich anders entschieden.

Und der Lauf der Dinge hat bewiesen, dass der Entwickler richtig lag und der Chef falsch.

Und jetzt kommentiert der Entwickler die damalige Chef-Entscheidung mit "Hab ich gleich gesagt, dass das ein Fehler war.", und alle Fachkollegen stimmen ihm zu.

In welcher Situation ist jetzt der Chef? Und inwiefern hilft das dem Team bei der nächsten Entscheidung dieser Art? Warum wird vom Entwickler mit dem Finger auf den Chef gezeigt und gemeint: "Du da hast den Fehler gemacht. Du bist Schuld!"

Wenn solch ein Verhalten zur Unternehmenskultur gehört, dann bedeutet das umgekehrt auch, dass der Chef bei der nächsten Situation, bei der es genau umgekehrt läuft, dann mit dem Finger auf den Entwickler zeigt und sagt: "Du hast die Software scheiße programmiert. Du bist Schuld!"

Und weil er Chef ist und vermutlich die Macht dazu hat, kann er den Entwickler bei ausreichender Anzahl solcher Vorfälle dann auch mal rauswerfen. Oder zumindest sanktionieren.

Ich möchte nicht in einem Umfeld als Entwickler arbeiten, in dem Fingerpointing und Schuldzuweisungen an der Tagesordnung sind und man am besten lebt, wenn man keine Fehlentscheidungen trifft, weil man am besten gar keine Entscheidungen trifft.

So ist die Situation bei uns zum Glück nicht.

Software zu entwickeln ist Teamwork. Das bedeutet: Das Team als Gesamtheit ist verantwortlich für die geleistete Arbeit und die abgelieferte Qualität. Niemand kann alleine Schuld sein, denn wenn das Team in Ordnung findet, dass Mitarbeiter A die Aufgabe B erledigt, und niemand hinterher kontrolliert, ob das nach dem gemeinsamen Qualitätsempfinden vernünftig gebaut wurde, muss das Team damit leben, wenn sich hinterher rausstellt, dass das eben doch nicht so war. Das fortwährende Versagen des Teams bei der Definition und Kontrolle eigener Qualitätsstandards führt dazu, dass jeder nur so für sich codet, irgendeine beliebige Qualität abliefert, und damit möglicherweise zu genau diesem Exemplar von $VORGAENGER wird, dessen Code niemand mehr anfassen will.

Bei $VORGÄNGER war die Situation so, dass der Chef von der Geschäftsführung an seiner Arbeit gehindert wurde, $VORGÄNGER hatte dank eines Geschäftsführers nahezu Narrenfreiheit. Damit waren auch alle Ansätze des Qualitätsmanagements ausgehebelt.

Was Teamwork und Team-Management angeht: Das würde einen Chef voraussetzen, der etwas von Team-Management und Projektmanagement versteht, der seine Leute entsprechend ihren Fähigkeiten einsetzt und der gegenüber der Geschäftsführung auch mal deutlich sagt, das 150% Dauerlast nicht gut sind und das Leute fehlen, statt immer nur "alles gut, alles schön" zu verbreiten.

Es ist etwas böse, aber die EDV funktioniert am Besten, wenn der Chef krank oder im Urlaub oder bei irgendeinem Meeting ist. Es ist bezeichnend, dass kritische Meetings gerade von der Geschäftsführung und anderen Abteilungsleitern gerne so gelegt werden, dass der Chef "zufällig" gerade nicht dabei sein kann. Rückblickend das Sahnehäubchen: Der Chef war der letzte, der erfuhr, dass die Geschäftsleitung mich eingestellt hat.

Alexander