Auf mich hört ja keiner ...

[Sven Rautenberg]

Moin!

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 […]

Halte ich auch für extremst unrealistisch, ja. Hat bei mir auch noch nie wirklich geklappt. Zumal der Chef dir gegenüber ja weisungsbefugt ist, wenn du also „NEIN sagst und dann dabei bleibst,“ dann ist das ein Grund für eine Kündigung – und das auch mit Recht. Dem Chef deutlich zu verstehen zu geben, dass die Vorstellung unrealistisch ist und der Termin nicht haltbar ist, es aber dennoch zu versuchen ist der Weg, den man einschlagen muss.

"Do, or do not. There is no try." (Yoda)

Dem Chef rückzumelden, dass der notwendige Arbeitsaufwand für die Features in der vorgesehenen Zeit nicht realisiert werden können, ist das "NEIN".

Das bedeutet ja nicht, dass man nicht verhandlungsbereit ist. Weniger Features würden in der vorgesehenen Zeit funktionieren, oder alle Features in mehr Zeit.

Aber nach dem "NEIN" ein "Aber ich versuchs." hinterherzuschieben bedeutet "JA". Und zwar ein "JA, ich liefere zum vorgesehenen Termin alle Features, Chef." Und man weiß, dass das vermutlich nicht klappen wird.

Kein Chef kann einen anweisen, Features in der vorgesehenen Zeit fertigzustellen. Er hat lediglich die Macht, die Features zu bestimmen. Und er kann nach Ablauf der vorgesehenen Zeit das bis dahin erzielte Resultat kriegen. Das wird dann vermutlich unvollständig sein.

Zwei Möglichkeiten:
Entweder hat der Entwickler gesagt, dass es nicht funktionieren wird. Und hat angefangen, ist aber wie kommuniziert nicht fertig. Chef: "Warum ist das noch nicht fertig?" Prog: "Weil ich gesagt habe, dass es zwei Wochen länger dauert, und ich jetzt wie zu erwarten war erst halb fertig bin." Chef: "..." (weiß, dass er das Problem ignoriert hat)

Oder der Entwickler hat gesagt, es würde nicht funktionieren, er würde es aber versuchen. Chef: "Warum ist das noch nicht fertig?" Prog: "Ich habs versucht, aber es dauert halt länger. Hatte ich ja gesagt." Chef: "Dann arbeite mehr dran, dann klappt's auch."

Ein einfaches Beispiel: Kunde will eine Youtube-API-Anbindung - programmierst du da jetzt gleich einen Abstraktionsschicht um später mal andere Video-Dienstleister-APIs verwenden zu können oder eben doch direkt?

Finanziell wird sich die "wir sehen mal in die Zukunft vor" idR. nicht spielen.

Das sehe ich anders. Es  lohnt sich fast immer, die Abstraktionsschicht einzubauen, zumal sie oft nichtmal wirklich mehr Arbeit kostet. Dazu kommt, dass das einfache auch eine Frage der Software-Qualität ist.

YAGNI! :)

Das gilt in der Tat aber nur für Features. Abstraktion ist eine Frage der Architektur.

Ja, das ist die Regel - trotzdem wird dem Entwickler dann ständig vorgehalten, dass er ja prinzipiell "immer dagegen" ist.

Naja, dann solltest du vielleicht nicht immer dagegen sein. Deine Rolle als Entwickler ist nicht, deinen Chef zu überzeugen, sondern in einem sachlichen Gespräch deine Argumente darzulegen, warum du das nicht für sinnvoll erachtest, aber auch nicht chronisch bei jeder Gelegenheit deinem Chef vorzuhalten, dass das Unsinn ist. Einmal reicht, danach wird jeder durchschnittliche Mensch verstanden haben, dass du das anders siehst.

Es kommt halt auch darauf an, wie man sein NEIN verpackt. Und das NEIN richtet sich ja nicht gegen die Aufgabe, sondern gegen den Zeitplan.

Keine dieser Verhaltensweisen würde ich als sonderlich professionell bezeichnen.

Du hast ja keine Ahnung wie weit man das noch unterbieten kann - ich hab noch viel schlimmeres gesehen.

Ich auch. Das heisst aber nicht, dass die oben beschriebenen Verhaltensweisen professionell sind :-)

Klar, schlimmer geht immer. Profis sind - auch beim Führungspersonal - nicht so häufig, und es ist eine Kunst, ein gutes Team zusammen zu führen und dann gut zu führen.

- Sven Rautenberg