Leserreporter: Wer schöne Verschwörungslinks für mich hat: ab an felix-bloginput (at) fefe.de!
[zurück][ältere Posting][neuere Posting] Dienstag, 22 März 2016 | Blog: 8 | No: 35166
Ich glaube, ich habe noch zu keiner Umfrage so viele Einsendungen gekriegt wie zu der mit Defect Management. Ich bin noch nicht mal ansatzweise durch mit den ganzen Mails. Aber einige Sachen stechen heraus.
Erstens: Fast immer heißt es "keine Zeit". Auch in Abwandlung als "andere Sachen sind wichtiger". Wir reden hier also von einer BWL-Betrachtung der Situation. Da kommen dann so Argument wie "der Kunde hat ja schon gezahlt". Wieso sollte ich mich um Bugs kümmern, nachdem der Kunde gezahlt hat? Wichtiger ist es, neue Kunden zu gewinnen.
Daraus folgt dann spannenderweise direkt ein Argument für Abo-Modelle, SaaS und Cloud Computing. In den Fällen, würde man ja denken, hat der Betreiber einen direkten Anreiz, seinen Scheiß stabil zu kriegen. Denn er schadet sich nur selber, wenn es nicht stabil ist.
Aber dem gegenüber stehen dann Einsendungen aus der Spielebranche. So F2P- und Browserspiele meine ich jetzt. Die haben ja nun "wir schaden uns nur selbst" als Extrem, sozusagen in Reinform. Dem Argument folgend müssten die ja alle Bugs immer sofort fixen. Tun sie aber nicht. Im Gegenteil, da bleibt auch alles liegen. Deren Metriken sind die Rate der neu angelegten Accounts und die reinkommende Kohle pro Tag. Das heißt, dass die Bugs ganz schnell schließen, mit denen man beispielsweise bescheißen kann, oder den Server abstürzen lassen kann. Die zweite Reihe sind Bugs, mit denen man andere Leute ärgern kann. Die werden auch gefixt, aber nur, wenn sie außen bekannt werden und weiträumig ausgenutzt werden.
Wir haben hier also keinesfalls die Situation, dass "der Markt das dann schon richten wird", wenn man das rein ökonomisch bewertet alles.
Andere strukturelle Probleme, die immer wieder angeführt werden, sind Ausschreibungen. Das Konzept der Ausschreibung führt dazu, dass der Billigste gewinnt, und der ist nur deshalb so billig, weil er kein Budget für Fehlerbereinigung zurücklegt. Mehrere Einsender schreiben sogar, dass Fehler absichtlich eingebaut wurden, damit man auch noch einen Support-Vertrag verkaufen kann, und über den dann die Differenz zwischen der Ausschreibung und den realen Kosten wieder reinholen kann.
Ein weiteres wiederkehrendes Element sind unnötige Grabenkämpfe. Die Tester fühlen sich von den Entwicklern vorgeführt und ignoriert. Die Entwickler fühlen sich von Testern und Management gegängelt. Das Management spart die Tester am liebsten ganz ein und macht den Entwicklern uninformierte Vorgaben. Gerne wird auch über Vertriebler geschimpft, die Dinge verkauft haben, die gar nicht einlösbar sind.
Ich glaube, dass man hier auf allen Seiten das Verhalten ändern muss. Das Management hat die Aufgabe, Geld zu sparen, und "Prozesse zu optimieren". Bis es schmerzt. Ob es schmerzt oder nicht, das brauchen sie als negatives Feedback. Und es muss für sie klar erkennbar sein, dass das jetzt zuviel "optimiert" war. Die Entwickler verhalten sich aber häufig dumm in der Situation und versuchen, die unmöglichen Vorgaben einzuhalten. Dabei wird der Code schlechter und schlechter, ein Legacy-Schuldenberg baut sich auf, und die Bugs kommen beim Management aber nicht als "das liegt an deiner Sparpolitik" an sondern als "die Entwickler sind inkompetent und undiszipliniert" an — und die machen dann weiter mit der "Kostenoptimierung".
Und was das Management falsch macht ist, dass sie keine Risiken eingehen. Man muss die Management-Hierarchie als Risiko-Puffer betrachten. Das Management unten und die Entwickler, die sollen Risiken eingehen. Die sollen keine unsauberen Abkürzungen nehmen. Aber wenn sich eine Gelegenheit bietet, mit einer anderen Technik besser zu sein, dann sollen sie das machen. Das untere Management hat genau die Aufgabe, das zu begleiten, und die Reißleine zu ziehen, wenn das schief läuft. Und das Management darüber ist dafür da, solche Fehlversuche dann zu kompensieren. In der Realität gibt das untere Management Kritik direkt an die Entwickler weiter, die sind dann verunsichert und machen lieber gar nichts, bevor sie was falsch machen, und das Ergebnis ist für alle Scheiße.
Entwickler müssen verstehen, dass sie gemanaged werden, nicht befehligt. Essentieller Teil von Management ist, dass man beobachten kann, wenn etwas falsch läuft, und dann gegensteuert. Entwickler, die schlechte Nachrichten nicht an das Management weiterleiten, und technische Schuld auftürmen, um dem Management zu gefallen, sabotieren damit das System und ruinieren die Firma.
Oh, eine strukturelle Sache habe ich noch: "Das ist doch nur ein Prototyp / end of life / wir rollen demnächst Version 2 aus, da muss man doch jetzt keine Arbeit mehr investieren". Und dann scheitert das Ausrollen der Nachfolgeversion und man hat sich selbst in den Fuß geschossen.
Auch "the guy left"-Szenarien scheinen erschütternd häufig vorzukommen. Und Teil von dem oben erwähnten Konkurrenzdenken ist auch, dass man dann Kosten externalisiert. "Ich muss das nicht fixen, wenn es einen Workaround gibt. Mit dem schlägt sich dann das Support-Team herum, nicht wir."
Die Heilsversprechen von Scrum und co haben sich in der Realität nur partiell manifestieren können. Bei einigen scheint das gut zu klappen, bei anderen führt es zu Burnout durch den hohen Druck und der totalen Transparenz, bei wieder anderen gibt es für Bugfixes keine Punkte im Sprint, daher macht es niemand, und bei noch anderen fallen Bugs unter den Tisch, weil man ihren Aufwand schlechter abschätzen kann als für Neuentwicklungen.
[zurück]
[ältere Posting][neuere Posting]
[zurück][ältere Posting][neuere Posting] Dienstag, 22 März 2016 | Blog: 8 | No: 35166
Wieso sollte ich mich um Bugs kümmern, nachdem der Kunde gezahlt hat?
Erstens: Fast immer heißt es "keine Zeit". Auch in Abwandlung als "andere Sachen sind wichtiger". Wir reden hier also von einer BWL-Betrachtung der Situation. Da kommen dann so Argument wie "der Kunde hat ja schon gezahlt". Wieso sollte ich mich um Bugs kümmern, nachdem der Kunde gezahlt hat? Wichtiger ist es, neue Kunden zu gewinnen.
Daraus folgt dann spannenderweise direkt ein Argument für Abo-Modelle, SaaS und Cloud Computing. In den Fällen, würde man ja denken, hat der Betreiber einen direkten Anreiz, seinen Scheiß stabil zu kriegen. Denn er schadet sich nur selber, wenn es nicht stabil ist.
Aber dem gegenüber stehen dann Einsendungen aus der Spielebranche. So F2P- und Browserspiele meine ich jetzt. Die haben ja nun "wir schaden uns nur selbst" als Extrem, sozusagen in Reinform. Dem Argument folgend müssten die ja alle Bugs immer sofort fixen. Tun sie aber nicht. Im Gegenteil, da bleibt auch alles liegen. Deren Metriken sind die Rate der neu angelegten Accounts und die reinkommende Kohle pro Tag. Das heißt, dass die Bugs ganz schnell schließen, mit denen man beispielsweise bescheißen kann, oder den Server abstürzen lassen kann. Die zweite Reihe sind Bugs, mit denen man andere Leute ärgern kann. Die werden auch gefixt, aber nur, wenn sie außen bekannt werden und weiträumig ausgenutzt werden.
Wir haben hier also keinesfalls die Situation, dass "der Markt das dann schon richten wird", wenn man das rein ökonomisch bewertet alles.
Andere strukturelle Probleme, die immer wieder angeführt werden, sind Ausschreibungen. Das Konzept der Ausschreibung führt dazu, dass der Billigste gewinnt, und der ist nur deshalb so billig, weil er kein Budget für Fehlerbereinigung zurücklegt. Mehrere Einsender schreiben sogar, dass Fehler absichtlich eingebaut wurden, damit man auch noch einen Support-Vertrag verkaufen kann, und über den dann die Differenz zwischen der Ausschreibung und den realen Kosten wieder reinholen kann.
Ein weiteres wiederkehrendes Element sind unnötige Grabenkämpfe. Die Tester fühlen sich von den Entwicklern vorgeführt und ignoriert. Die Entwickler fühlen sich von Testern und Management gegängelt. Das Management spart die Tester am liebsten ganz ein und macht den Entwicklern uninformierte Vorgaben. Gerne wird auch über Vertriebler geschimpft, die Dinge verkauft haben, die gar nicht einlösbar sind.
Ich glaube, dass man hier auf allen Seiten das Verhalten ändern muss. Das Management hat die Aufgabe, Geld zu sparen, und "Prozesse zu optimieren". Bis es schmerzt. Ob es schmerzt oder nicht, das brauchen sie als negatives Feedback. Und es muss für sie klar erkennbar sein, dass das jetzt zuviel "optimiert" war. Die Entwickler verhalten sich aber häufig dumm in der Situation und versuchen, die unmöglichen Vorgaben einzuhalten. Dabei wird der Code schlechter und schlechter, ein Legacy-Schuldenberg baut sich auf, und die Bugs kommen beim Management aber nicht als "das liegt an deiner Sparpolitik" an sondern als "die Entwickler sind inkompetent und undiszipliniert" an — und die machen dann weiter mit der "Kostenoptimierung".
Und was das Management falsch macht ist, dass sie keine Risiken eingehen. Man muss die Management-Hierarchie als Risiko-Puffer betrachten. Das Management unten und die Entwickler, die sollen Risiken eingehen. Die sollen keine unsauberen Abkürzungen nehmen. Aber wenn sich eine Gelegenheit bietet, mit einer anderen Technik besser zu sein, dann sollen sie das machen. Das untere Management hat genau die Aufgabe, das zu begleiten, und die Reißleine zu ziehen, wenn das schief läuft. Und das Management darüber ist dafür da, solche Fehlversuche dann zu kompensieren. In der Realität gibt das untere Management Kritik direkt an die Entwickler weiter, die sind dann verunsichert und machen lieber gar nichts, bevor sie was falsch machen, und das Ergebnis ist für alle Scheiße.
Entwickler müssen verstehen, dass sie gemanaged werden, nicht befehligt. Essentieller Teil von Management ist, dass man beobachten kann, wenn etwas falsch läuft, und dann gegensteuert. Entwickler, die schlechte Nachrichten nicht an das Management weiterleiten, und technische Schuld auftürmen, um dem Management zu gefallen, sabotieren damit das System und ruinieren die Firma.
Oh, eine strukturelle Sache habe ich noch: "Das ist doch nur ein Prototyp / end of life / wir rollen demnächst Version 2 aus, da muss man doch jetzt keine Arbeit mehr investieren". Und dann scheitert das Ausrollen der Nachfolgeversion und man hat sich selbst in den Fuß geschossen.
Auch "the guy left"-Szenarien scheinen erschütternd häufig vorzukommen. Und Teil von dem oben erwähnten Konkurrenzdenken ist auch, dass man dann Kosten externalisiert. "Ich muss das nicht fixen, wenn es einen Workaround gibt. Mit dem schlägt sich dann das Support-Team herum, nicht wir."
Die Heilsversprechen von Scrum und co haben sich in der Realität nur partiell manifestieren können. Bei einigen scheint das gut zu klappen, bei anderen führt es zu Burnout durch den hohen Druck und der totalen Transparenz, bei wieder anderen gibt es für Bugfixes keine Punkte im Sprint, daher macht es niemand, und bei noch anderen fallen Bugs unter den Tisch, weil man ihren Aufwand schlechter abschätzen kann als für Neuentwicklungen.
Update: Oh und: So 5% der Einsender widersprechen meiner Prämisse, dass das Management grundlegend versteht, dass Bugs nicht fixen die Sache schlimmer macht.
Update: Es waren dann doch auch mehr als nur einer dabei, die sagten, dass sie alle Bugs fixen, und zwar so schnell wie sie können.
Twiter-Ticker
Fefes Latest Youtube Video Links
Der Betrieb der KraftZeitung kostet Geld. Da wir auch weiterhin unabhängig, überparteilich und ohne kommerzieller Werbung für Sie da sein wollen, sind wir auf Ihre Spende angewiesen. Vielen Dank.
