14. Januar 2013 18:09

Re: Verantwortung ja, aber Aufrufen ist verantwortungslos ;)

Keppla schrieb am 14. Januar 2013 17:07


> > Grundsätzlich stimme ich dir zu, allerdings darf man das Thema aber
> > nicht nur auf die IT beschränken.

> Die Einschränkung kam ja nicht von mir, das war die böse
> Artikelüberschrift ;)

> > Aber man muss ja nicht gleich die ganz grossen Themen rauskramen. In
> > vielen Firmen wissen Entwickler von Dingen, die dem eigenen
> > Management nicht bewusst sind. Aus welchen Gründen auch immer. 

> Meinst du sowas wie "Abteilungsleiter klaut, Bereichsleiter merkt's
> nicht"? Ich kann gerade nicht ganz folgen.

Der Projektleiter versucht ein grösseres Qualitätsproblem unter dem
Management-Radar zu halten, weil es ansonsten das Projekt und seine
Karriere verhagelt. Geschieht leider desöfteren.


> > Insbesondere wenn der Projektleiter die Lösung Sicherheitsprobleme
> > lieber verschiebt (auf ein unbestimmtes Datum), um den Projektplan
> > nicht zu gefährden.

> Auch hier: wenn es nicht irgendwie belohnt wird, das nicht zu machen,
> gibt es da kaum alternativen.

> Der Programmierer kann nicht gegen den Befehl des Projektleiters
> arbeiten, ohne sich eine Kündigung einzufangen.

In den meisten Fällen ist ein Projektleiter einem Entwickler nicht
direkt vorgesetzt, sondern man arbeitet in einer Matrix-Organisation.
Und wenn der direkte Chef kein Arschloch ist, hört er seinem
Untergebenen zu, wenn der ihm von Problemen im Projekt erzählt, die
der Projektleiter entweder nicht hören will oder sie mutwillig nach
aussen verschleiert.

Und genau das ist der Punkt: Nur weil es der Projektleiter nicht
akzeptiert, sollte es ein Entwickler nicht als "Ok, der wird schon
wissen, was er tut" abtun und einfach nach Schema weitermachen.
Insbesondere wenn ein "erfolgreiches Projekt" dann Folgen hat, weil
beispielsweise Sicherheitslücken existieren, die zu ignorieren
gradezu sträflich ist, und die Auswirkungen auch für andere Personen
(Kunden) gravierend ist.


> Für den Projektleiter gibt's "keine" Möglichkeit, da er nur mit
> "Handwerksstolz" und fiktiven Katastrophen argumentieren kann, was
> dem CEO egal ist, weil es so wie es aussieht, die billigere
> Alternative ist.

Das ganze nennt sich Risiko-Abschätzung, und die Durchführung eines
solchen ist eine Kernaufgabe eines jeden Projekts. Und wenn das Risko
lautet "Wir verlieren Kundendaten inklusive Namen, Lieferadressen und
Kreditkartennummern", und die Eintrittswahrscheinlichkeit ist hoch,
denn "man muss nur beim Login die bekannten Default-Passwörter von
einer Oracle-DB angeben" (blödes Beispiel, ich weiss), dann muss
jeder hellhörig werden.

Handwerkerstolz würde ich nennen, wenn unbedingt jemand grössere
Teile refactoren will, um die zukünftige Maintainenance-Kosten gering
zu halten. Kostet nur, bringt keine direkten Vorteile, reduziert kein
sofortiges Risiko, und wenn ich es erst morgen mache, tut's überhaupt
nicht weh.


> Das "keine" stimmt natürlich nicht ganz, man kann immer irgendwie ein
> bisschen ermogeln. Aber: oft genug wiederholt führt es eben nur zur
> Kündigung (Programmierer), Degradierung (Projektleiter), Insolvenz
> (CEO/Shareholder).

> Es reicht nicht, zu fordern, dass sich die anderen für die ethik
> Opfern, man muss dafür sorgen, dass die, die sich Opfern würden,
> belohnt werden.

Man muss sich nicht immer opfern. Du sollst einfach nicht nur still
dasitzen und dir sagen "Ja, der Projektleiter wird schon wissen, was
er von mir verlangt und was für Folgen das haben wird." Das weiss der
nicht immer. Der Kunde auch nicht.


Anzeige

heise online Themen