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.

Du kannst nein sagen so oft du willst - da kommen dann von den vorgesetzten Meldungen wie "du siehst immer nur Probleme, ich will Lösungen" - wenn du dann die Lösung "wir brauchen mehr Zeit und müssen mehr Geld dafür verlangen oder wir müssen die Features reduzieren" kommt, hast du eine Endlosschleife (oft genug erlebt).

Ich bin da mittlerweie völlig schmerzfrei. Ich frage stumpf nach Prioritäten, und arbeite dann nach Prioritäten ab.

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.

Das funktioniert in der Praxis nicht - du kannst nicht "NEIN" sagen und dich zurücklehnen und nichts mehr tun, weil du ja nein gesagt hast - da brauchst du schon einen sehr gutmütigen Chef der das Mitmacht.

Wer redet den von zurücklehnen? Ich sage "der Termin ist nicht zu halten, such Dir aus, welche 3 der 120 Punkte Du bis dahin fertig haben willst", und arbeite an den Punkten natürlich weiter!

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.

Wenn der Chef seinen Leuten nicht glaubt, ist es Zeit, den Job zu wechseln.

Auch wenn sich der Chef die Schläge beim Kunden abholt, das wird immer nach unten durchgereicht.

Nein, wird es nicht. Oft vielleicht, aber nicht immer. Mein erster Chef war da absolut genial, quasi das perfekte Interface zwischen Technik-Freaks und Management-Schlipsträgern.

Die Methodik leidet fast immer unter Zeitdruck - meistens gibts nichtmal Zeit eine Software ordentlich zu dokumentieren Geschweige denn zu testen. Ich hab' auch schon erlebt, dass ein komplexe Software ohne Pflichtenheft zu einem völlig irren, auch nach Daumen-Mal-Pi-Schätzung, Preis verkauft wurde. Bauchgefühlschätzung war "irgendwo 2 Monate" und verkauft wurde es um gute 2 Wochen - das hat dann zu unbezahlen Extraschichten über Weihnachten und Neujahr geführt - weil der Online-Termin auf kurz vor Weihnachten zugesagt wurde.

Überstunden wegen Fehlplanungen gibt's mit mir nicht. Ich hab's einmal gemacht, weil ich meinen ersten Chef nicht hängen lassen wollte, und das Ergebnis war ein Design-Albtraum, der mich und den Rest des Teams die nächsten Jahre verfolgt hat. Was ich in den paar Überstunden fabriziert habe, mußte über Jahre nach und nach gerade gebogen werden.

Mein Fazit: Überstunden kloppen lohnt sich einfach nicht, weil die Fehlerquote mit der Müdigkeit astronomisch hoch geht und man hinterher noch viel mehr Zeit braucht, die Fehler wieder zu beseitigen.

Software zu entwickeln ist Teamwork.

Die Kluft besteht idR. auch eher zwischen "Management" und "Technik" oder "Design" und "Technik" - wenn die Techniker untereinander schon nicht richtig zusammenarbeiten ist sowieso Hopfen und Malz verloren

Richtig. Entweder mögen sich die Technik-Leute, dann klappt alles wunderbar, oder man zickt sich ständig nur an und steht sich gegenseitig im Weg. Das hängt meiner Meinung nach sehr am Chef / Teamleiter ("Managing programmers is like herding cats"), aber natürlich auch an den Leuten. Ich denke, wenn die Fähigkeiten zu weit auseinander gehen, kann ein Team nicht funktionieren. Gerade nicht, wenn ein oder zwei Dumpfbacken sich komplett lern- und beratungsresistent zeigen.

Alexander