Kategorien
Der Ärztevergleich
Ich bin ja ein Freund von Metaphern und Vergleichen. Wenn man Nichttechnikern versucht etwas näher zu bringen können solche Dinge mit Gold nicht aufgewogen werden. Es gibt ein paar Vergleiche aus der Softwaretechnik, die ich sehr gelungen finde und die ich euch näher bringen will. Heute fangen wir an, indem wir Qualitätssicherung mit einem Arztbesuch vergleichen.
Nehmen wir mal an, wir gehen zu einem Chirurgen um uns operieren zu lassen. Drei mal auf Holz klopfen, dass wir da nicht wirklich hin müssen. So weiter. Ich als Kunde will natürlich, dass es besonders schnell gehen soll, denn jede Sekunde, die ich ausfalle kostet Geld. Um das ganze schnell hinter mich zu bringen will ich natürlich, dass der Arzt auf Qualitätsmanagement verzichtet und sich einfach die Hände nicht wäscht. Wir wollen ja Zeit sparen.
Jeder gute Arzt wird da nicht mitmachen. Wie doof muss man in einer solchen Situation sein und auf die Sicherheitsmaßnahmen verzichten. Man weiß ja nie, was dann passiert. Der Arzt wird seine Werte verteidigen und auf keinen Fall davon abweichen.
Können wir uns als Softwareentwickler dort eine Scheibe abschneiden? Auf jeden Fall! Wir sollten unsere Werte auch gegen Projektdruck verteidigen und nur weil es schnell gehen muss, sollten wir nicht auf Tests oder Reviews verzichten. Ich glaube da müssen wir alle mal ein wenig Selbstvertrauen gewinnen und unseren Teamleitern, oder wer da auch immer den falschen Druck aufbaut, entgegentreten. Vielleicht hilft ja der Vergleich ein wenig bei der nächsten Argumentationskette.
Natürlich habe ich das Ärztebeispiel nicht selbst erfunden. Das könnt ihr bei den Clean Code Developern noch einmal genauer anschauen.
danke fürn den ideenvergleich!
Großartiger Vergleich! Werde ich demnächst den Produktmanagern hier auch mal vor Augen halten …
Sehr guter Vergleich … ich vergleiche Tests gelegentlich auch mit der Probefahrt, die ein Automechaniker nach einer Reparatur macht. Wer will schon sein Auto mit der Aussage „das müsste wieder funktionieren, ich habs aber nicht ausprobiert“ zurück haben.
Ein Stück weit müssen Entwickler in kleinen Einheiten das ausbaden was die großen der Branche eingebrockt haben. Wenn es Garantievereinbarungen und Software Produkthaftung in der gleichen Form wie bei Ärzten und Automechanikern gäbe, sähe die Situation deutlich anders aus 😉
P.S. im Moment blendet Google gerade eine Anzeige eines Patientenanwalts ein 😉 der würde sich über einen Fehler wie ungewaschene Hände sofort hermachen.
Zwar ist nicht alles was hinkt ein Vergleich aber die Sache mit dem Arzt ist schon stimmig. Insbesondere weil Ärzte auch immer mal wieder die Knochensäge auspacken müssen…
„Ich bin Chirurg, so kann ich nicht arbeiten!“
Meiner Meinung nach ist der Vergleich unpassend. Grundsätzlich richtig ist, dass man gewisse Werte bzw. Ansätze verteidigen sollte, auch gegenüber dem Chef und eventuell einer Unternehmenskultur, die dem entgegenstehen. Ich bin auch der Ansicht, dass QM oft sträflich vernachlässigt wird, aber:
– Entwickler finden sich alle toll, sind aber bei weitem keine Chirurgen. Auch die Konsequenz ihres Tuns ist eine völlig andere. Wenn eine Anwendung nicht rund läuft, dann stirbt keiner. Leider ist es in Fällen sogar fraglich, ob der Kunde das merkt. Lächerlich, wenn ein Teamleiter o.ä. sagen würde „wir sind ein Team von Chirurgen“. Soviel Hybris würde mich nachdenklich machen, ob mir als Kunden vielleicht Chirurgen abgerechnet werden.
– Der Kunde lehnt Testing usw. ja explizit ab, wenn er es nicht bezahlen möchte. Es liegt also in der Verantwortung der Verkäufers, dem Kunden klar zumachen, dass QM am Ende günstiger und ggf. schneller ist. Für den umgekehrten Fall verlangen Kunden auch mal Vertragsstrafen.
Ist ja alles ganz gut und schön, aber weißt du was die Antwort des Chefs dann ist? „Natürlich muss das gemacht werden – aber sie müssen sich trotzdem an den Zeitplan halten.“ D.h.: notfalls unbezahlt am Wochenende zu arbeiten. Denn wenn man Zeit für QA einplanen muss, der Abgabetermin aber schon vorher genau wie die Featureliste in Granit gemeißelt wurde, mit der Option, dass die Featureliste jederzeit noch länger werden kann: wo will man dann sparen? Der Monat wird ja nicht länger! Also: Überstunden, Überstunden, Überstunden.
Wollen wir das? Oder geben wir dem (IT-fernen) Chef nach, der sowieso seit Jahrzehnten nichts anderes gewohnt ist und auch gar nicht will, dass sich etwas ändert?
@Tom: Dann wird es Zeit agil zu arbeiten und den Chef zu feuern. Ich glaube nicht, dass man mit dieser Denke Kundenzufriedenheit erzeugen kann.
Da gebe ich Nils recht, wer einerseits eine feste Featureliste hat aber andererseits laufend neue Features hinzukommen arbeitet man definitiv kontraproduktiv für den Kunden. Somit macht man immer wieder Versprechungen, die man nie einhalten kann, der Kunde ist sauer und kommt nie wieder.
Das ist die Realität. Wenn ich zu einem Festpreis entwickel anhand der Featureliste wird man am Ende wohl kaum noch Gewinn machen!
Ja und nein. Ja: da ist theoretisch alles richtig. Aber nein: es ist politisch nicht durchzusetzen.
Der Chef ist Gott. Gott sagt: die Kunden wollen einen Festpreis sonst unterschreiben sie den Vertrag nicht. Höhere Preise gehen nicht, sonst verkaufen wir nicht. Längere Entwicklungszeiten sind nicht möglich, sonst sind die Kosten zu hoch. Wir verkaufen zu den Konditionen, zu welchen wir den Zuschlag kriegen.
Natürlich weiß man als Entwickler: das ist Nonsense! Aber weißt du was die Antwort des Chefs war? „Dann müssen wir das Projekt einstellen, denn dann stimmt unsere Kostenrechnung. In diesem Fall benötigen wir Sie dann allerdings auch nicht mehr. Oder sie finden einen Weg es doch in der vorgegeben Zeit zu machen.“
Mein „Kunde“ ist mein Boss. Wie der seine „Kostenrechnung“ dann seinem Kunden verkauft, muss mir erst einmal egal sein. Dass er hinterher einen Rattenschwanz von Korrekturen bezahlen muss, ist er bereits gewohnt. Das ist Gottes Arbeitsweise. Damit hat Gott seinen Mercedes bezahlt. So etwas stellt man als kleiner, sterblicher Projektleiter nicht in Frage.
@Tom
Dann sag deinem Chef: „Na gut, dann gehe ich und für das nächste Projekt musst du die eben Sklaven aus Takatukaland suchen, die es für 3 Euro die Stunde machen und keine Freizeit kennen. Viel Spaß bei der Suche.“
Bin selbst meistens Chef gewesen, Autorität ist gut aber solch steinzeitlichen Sprüche leisten sich nur Idioten, für die es sowieso nicht wert ist zu arbeiten. Und die nicht wissen, dass es schwer genug ist auf dem Markt gutes Personal zu finden.
Zusammengefasst kann man es auch so sagen: man ist als Projektleiter immer abhängig vom Willen des Managements. Wenn Defizite in Verfahrensabläufen auf Leitungsebene vorhanden sind, aber bei den Betreffenden partout die Einsicht und der Wille fehlt, diese zu beseitigen, dann nützen auch 100 tolle Artikel und 1000 gute Argumente nichts.
Auf der Führungsebene gibt es Persönlichkeiten, die sich für allwissende Könige von Gottes Gnaden halten. Denen ist mit Argumenten nicht beizukommen, sondern nur mit einem Rentenbescheid.
@Tom: So macht arbeiten doch keinen Spass, oder?
@Don Chefs wissen ganz genau, welche Arbeitnehmer von einem Arbeitsplatz abhängig sind. Einige wenige nutzen das gnadenlos aus.
Ich schreibe bei diesem Unternehmen eine Doktorarbeit. Wenn ich gehe, gehören denen die Copyrights an meiner Examensarbeit. Sie können mir verbieten meine Arbeit fortzusetzen. Sprich: ich könnte kündigen, wäre dann aber auch meine Doktorarbeit los. Der Chef weiß das genauso gut, wie er weiß, dass der Kollege Anteilseigner ist und eine 5-stellige Summe seinerseits in der Firma steckt. Oder dass der andere Kollege Familienvater ist und seine Frau keinen Job hat. Und so weiter und so fort.
Mancher Chef nutzt seine Möglichkeiten. Solange ihm eine „Million-Monkey“-Armee gut genug ist, kann er Hire&Fire spielen wie es ihm beliebt. Hat ja auch all die Jahre gut funktioniert 😉
Das es moralisch verwerflich ist, steht natürlich außer Frage.
Es müsste hunderte Leute geben wie Tom’s Chef.
Leider gibt es tausende…
Wenn meine Mitarbeiter unbezahlte Überstunden machen ohne Ende, würde ich auch nichts ändern wollen.
Insofern ist da zunächst der Mitarbeiter gefordert seine Rechte einzufordern.
Da Leibeigenschaft in Deutschland abgeschafft ist und man als Software-Entwickler im Allgemeinen ganz gute Jobaussichten hat, sollte es da Mittel und Wege geben.
Grundsätzlich war ja die Aussage, dass man ohne Arztbesuch ein ungesünderes Leben führt. Einige werden da widersprechen aber wenn es für abgebrochene oder gescheiterte IT Projekte auch Todesanzeigen gäbe, wäre die Tageszeitung wohl um einiges dicker.
@Nils kommt darauf an. Es ist Krieg da draußen. Ich arbeite 12-14 Stunden täglich und auch am Wochenende. Allerdings wird das Ergebnis zum Teil Open-Source. Das macht diesen Krieg zu „meinem Krieg“. Das hilft über vieles hinwegzusehen. Wenn das nicht wäre, hätte ich die Segel gestrichen.
@Daniel: Sicher ist es richtig, daß es bei Programmierung nicht um Leben und Tod geht und streng genommen der Chirurgenvergleich da etwas hinkt.
Aber: Immerhin ist das eine einfache Analogie, die Depp…ähm, Chefs verstehen können, und darauf kommt es am Ende an.
Und: Nicht selten sind die programmierten Prozesse unternehmenskritisch und würden bei Ausfall oder Fehlberechnungen einen Haufen Geld kosten. Das kann je nach Einsatzgebiet des nicht qualitätsgeprüften Produkts dann auch schon mal einen Job kosten oder eine Firma in dem Bankrott treiben. Der Vergleich mit Leben oder Tod ist also soooo weit auch nicht hergeholt.
@Tom: Das Problem ist, dass euer Chef euch nicht selbst wirklich denken lässt. Wenn ihr frei Denken und entscheiden dürftet, sähe das ganze extrem anders aus, sowohl bei der Kalkulation als auch das Ergebnis 😉 In meiner AUsbildung hatte mein AUsbildungsbetrieb auch viel Geld „verschenkt“, weil nachträgliche Änderungen am System kostenfrei gemacht wurden. Da war ein Entwickler alleine nochmal 2 Wochen beschäftigt – der schon kleinere Gewinn als der, der vorher kalkuliert war, war natürlich dadurch längst wieder futsch.
Scrum an sich ist ja auch nur ne Zusammnfassung von Best Practices in der Softwareentwicklung, die sowohl die Produktivität als auch den Gewinn und die Zufriedenheit der Kunden UND Mitarbeiter steigern kann gegenüber einer Fließbandabfertigung. Vielleicht solltet ihr Mitarbeiter gemeinsam öfter mal meckern, meist hat dann ein Chef eher ein offenes Ohr, wenn die Belegschaft unglücklich ist. Man muss ja nicht gleich Srum bei sich einführen, aber Extreme Programming würde bei vielen schon einige Probleme lösen.
Ich halte den Chirurgenvergleich wirklich für nicht angemessen. Wir haben es normalerweise nicht mit Menschen zu tun, denen wir unwiederbringlich die Gesundheit nehmen und Schmerzen zufügen.
Im Grunde ist das bei uns einfach eine Kosten-Nutzen-Rechnung:
Wenn der Entwickler einfach nur jede geänderte Funktion im Positiv- und Negativfall ausprobiert kostet das x EUR und die notwendigen Korrekturen kosten dann noch y EUR. Schreibt er noch Unittest und Regressionstests, so wird die Funktion teurer x+z EUR, die – selteneren – Feherlkorrekturen kosten dann y-w EUR.
Es ist das Recht der Vorgesetzten zu wählen, auf welche der beiden Optionen er setzen will. Vielleicht wollen sie ja statt in Unit- und Regressionstests lieber in eine unabhängige Testabteilung investieren? Diese hätten den Vorteil mit einem eigenen Gehirn ausgestattet zu sein, und auch logische Fehler oder eine saumäßige Oberflächengestaltung nochmals anmosern zu können.
Und … es kommt natürlich auch auf die Höhe der jeweiligen Kosten an. Was ist das größte Risiko im Schadensfall? Wie komplex ist die Software? Wie aufwendig sind in der gewählten Programmiersprache Unit- und Regessionstests? Wie häufig sind Fehler?
Um aber nochmals zum Chirurgenvergleich zu kommen:
Was haltet ihr von einem Arzt, der eine Stelle im Kreiskrankenhaus HinterDemMond angenommen hat und sagt, er weigert sich hier ein gebrochenes Bein zu operieren, da er nicht alle Geräte zur Verfügung hat, die er vom zentralen Herzzentrum des Landes kennt?
Ich möchte einfach nur zu Augenmaß in dieser Beziehung aufrufen.
Es gibt Dinge, die darf man als Entwickler nicht tun (z. B. eine neue Funktion einspielen ohne die Kundendaten gesichert zu haben) Hier sollte man sich genau so weigern, wie der Chirurg bei der OP ohne Hände waschen.
Generell habe ich die Erfahrung gemacht: Wenn man als Entwickler die Zwänge der betriebswirtschaftlichen Seite sieht und anerkennt, dann wird gegebenenfalls ein „das mache ich nicht, das ist zu gefährlich“ durchaus akzeptiert. Wenn man allerdings durchblicken lässt, dass einem der erste Preis im Wettbewerb „Unser Code soll schöner werden“ wichtiger ist, als die schwarze Null am Jahresende, dann muss man sich nicht wundern, wenn die eigenen Sicherheitsbedenken nicht mehr ernst genommen werden und – mit Recht – die Entscheidungskompetenz abgesprochen wird. (Das passiert m. E. auch, wenn berechtigt oder unberechtigt der Eindruck entsteht die Entwickler wollen nur ein neues Spielzeug ausprobieren.)
Was mich wundert ist, dass offensichtlich viele Entwickler um diese Tests kämpfen müssen. Unittests sparen doch eigentlich Kosten (dachte ich zumindest), dann müssten sie doch Selbstläufer sein?