Kategorien
Umgang mit Problemen … oder miese Eigenschaft eines Chefs
Die Weihnachtspause ist zuende. Wir haben erfolgreich die letzen zwei Wochen überstanden und es kann wieder losgehen. Ich hoffe ihr wurdet alle reichlich beschenkt und so. Das übliche eben.
Wie fangen wir also an? In den vier Wochen, die ich jetzt Urlaub hatte ist technisch natürlich für mich nichts passiert, aber dafür durfte ich mal wieder ein verhalten von einem Chef miterleben, dass ich auch meinen alten Tagen auch kenne. Dabei geht es um den Umgang mit Bugs und anderen Problemen.
Ich kenne es noch von meiner alten Job. Wir haben ein Deployment gerade hinter und gebracht, da merkt jemand, dass ein wichtiges Feature den Geist aufgegeben hat. Tja dumm gelaufen, aber passiert eben. In so einmal Fall war es bei uns nicht selten, dass der Chef rein kam und erstmal wissen wollte, wer denn dieses Fehler zu verantworten hat. Meine Güte hatte ich immer einen Hals.
Warum können solche Chefs nicht einfach mal aufhören dran zu denken, wer schuld ist und sich auf das wichtigste konzentrieren, nämlich auf das Lösen des Problems. Das normale Vorgehen sollte doch eigentlich sein, dass der Chef reinkommt und fragt, wie er helfen kann, das Problem zu lösen. Vielleicht ’ne Pizza für die Überstunden bestellen. Solche Dinge sind produktiv. Angst schüren dagegen wohl eher dumm.
Also an alle Chefs: Erst das Problem lösen, danach könnt ihr (und solltet wohl auch) ja gerne nach den Ursachen forschen. Ach ja, das ist überhaupt kein IT-Problem. Mir ist das ganze in der Gastronomie als letztes entgegen gekommen.
Ja kommt mir auch recht bekannt vor. Ich kenne das unter dem Begriff „Manöver Kritik“, welche man sinnvollerweise immer nach einer „Schlacht“ anbringt und nie währenddessen. 🙂
Wer war der Chef? <- Ist auch eine ganz konstruktive Frage 😉
Ich hatte mal einen Chef, der immer sofort zum Telefon gegriffen hat, um uns mitzuteilen, dass ein Fehler existiert. Der wollte dann auch immer einen „Live Fix“.
Die Gespräche verliefen meist wie folgt (C = Chef, E = Entwickler):
(BringBring)
E: Hallo Chef.
C: Hallo, wieso funktioniert Feature XY nicht?
E: Feature XY funktioniert nicht?
C: Nein.
E: Hm, das kann ich jetzt so aus dem Stehgreif nicht sagen.
C: Wieso nicht? Du hast das doch geschrieben.
E: (in Gedanken) Klar und natürlich mit der Absicht, dass es NICHT geht.
C: Also?
E: Also was?
C: Reparierst du es?
E: Jetzt sofort?
C: Wann denn sonst?
E: (tiefes Atmen) Moment … (tippt und klickt)
E: Also der UnitTest läuft durch. Was geht denn eigentlich nicht?
C: (erklärt Fehler)
E: Mhmm, ok. Das könnte an [X] liegen (tippt)
(es vergehen einige Minuten)
C: Und?
E: Ja, moment.
(es vergehen weitere Minuten)
E: Also, ich habe jetzt einen Test geschrieben. Der Test failed. Wahrscheinlich ist also (erklärt mögliche Ursache).
C: Kannst du das reparieren?
E: Ja, klar.
C: Okay (bleibt am Telefon)
(es vergehen weitere Minuten)
E: So, der Test läuft jetzt durch. Versuch‘ mal.
C: Prima. Geht. Warum nicht gleich so?
Da macht das Bugfixen richtig Spaß.
@Peter: Schön beschrieben. Vielleicht liegt das auch daran, dass viele Leute befördert werden, weil sie schon lange im Unternehmen sind und nicht weil sie gut auf eine Stelle passen.
Mal abgesehen davon, dass persönliche Kritik vor anderen Mitarbeitern niemals gut ist. Kritik üben ist natürlich erlaubt, aber bitte konstruktiv und niemals gegen einen einen Einzelnen gerichtet. Jemanden bloßzustellen ist Gift für die Arbeitsmoral aller.
Ich halte es immer so, dass nach außen hin ich als Chef/Projektleiter der Böse bin. Dh. der Kunde kann seine ganze Wut und Frustration über ein Problem gern bei mir auslassen. Ich schreib dann einmal kurz die Wand an, geh zu den Entwicklern versuche das Problem nachzuvollziehen und schnell zu lösen.
Wenn ein Entwickler tatsächlich „Schuld“ hatte (durch Schussligkeit oder was auch immer), gibt’s dann im im persönlichen Beurteilungsgespräch nen Rüffel.
Wichtig ist wirklich, dass man bei den Entwicklern nicht auch noch Druck aufbaut, denn wenn das Kind im Brunnen sitzt holt man es nicht raus indem man es anschreit. 🙂
@Bastian: Das mit dem Rüffel ist ja auch wieder so eine Sache. Denn manchmal ist der Prozess nicht genau formuliert, so dass leicht etwas vergessen wurde. Es liegt nicht in der Macht des Entwicklers alles zu überblicken und UnitTests sind keine Garantie bugfrei zu sein. Viel wichtiger finde ich, dass versucht wird herauszufinden, wie es zu diesem Fehler kam und ob der Entwicklungs-/Deploymentprozess verbessert werden kann, das ein solcher Fehler nicht wieder auftritt.
Übrigens entstehen ja die meisten Fehler durch Zeitdruck des Managements, oder? Der Entwickler will ja gute Qualität liefern, nur manchmal wird ihm nicht die entsprechende Zeit dafür genehmigt, um diese liefern zu können.
Aber dass manchmal auch ein ordentlicher Rüffel gerechtfertigt ist, will nicht bestreiten. 😉
Hmm das ist in unserer Firma zum Glück was das betrifft etwas besser gelöst. Da interessiert es eben gerade nicht WER es kaputt gemacht hat, sondern alle sind daran interessiert, dass es schnell wieder ganz gemacht wird. Aber das hat natürlich wirklich viel mit dem Führungsstil zu tun. Schön, wenn der Chef (und ChefChef) verstanden hat, dass es nur auf das Ergebnis ankommt.
Genauso ist es auch bei der Umsetzung von Features. Es ist im Grunde egal wer es macht. Man schaut eher wer hat die Kapazitäten und die besten Fähigkeiten um gewisse Dinge (in einer gewissen Zeit) umzusetzen.
Aus Managementsicht sind Entwickler eben Resourcen und man muss einfach schauen wie man diese Resourcen am besten einsetzt und am produktivsten nutzt. Wobei man dabei natürlich auch schauen muss, dass die Entwickler sich auch persönlich entfalten können und sich weiter entwickeln. Weil das auch wiederum direkten Einfluss auf das erstere hat. Nur ein glücklicher Entwickler ist ein guter Entwickler. =)
@Nils: Guter Artikel, aber die Rechtschreibfehlerchen und grammatikalischen Fehler waren schon etwas störend im Lesefluss. 😉
Ich denke die meisten Chefs können einfach nicht angemessen reagieren. Wenn das Team einen Fehler macht, wäre ich aber der letzte Chef der dann auch noch Pizza bestellt.
Für den Chef ist es meistens sehr schwer zu beurteilen wie schwerwiegend der Fehler war der begangen wurde. Dementsprechend schwer ist es dann natürlich auch angemessen zu reagieren. Die Frage „Wer war das?“ beruht oft darauf das man demjenigen die Aufgabe evt. nicht noch einmal zuteilen möchte, ihn also an der Problembehebung erst gar nicht teilnehmen lassen will. Oder im anderen Fall, dass er das Problem alleine aus der Welt schaffen soll um nicht andere für etwas zu „bestrafen“ das sie ggf. gar nicht verbockt haben.
Auf Fehler richtig und angemessen zu reagieren ist eine hohe Kunst und jedes mal aufs Neue eine Gradwanderung. Reagiert man zu lasch, werden Fehler bald nicht mehr ernst genommen. Ist ja egal, passiert ja eh nichts. Reagiert man zu harsch, passiert das was du beschrieben hast. Es wird unnötiger Druck aufgebaut und Motivation abgebaut. Den goldenen Mittelweg zu finden und die Situation richtig einzuschätzen unterscheidet die guten von den schlechten Chefs.
Ein goldener Mittelweg kann sein zu sagen das derjenige der den Fehler verbockt hat, die Pizza bestellt. So haben diejenigen die unschuldig sind eine kleine Entschädigung (Motivation) und derjenige der es verbockt hat, merkt das man es nicht toleriert. Dabei darf man aber nicht einen Mitarbeiter zum alleinigen Sündenbock machen. So was kann man dadurch erreichen, indem man die „Drohung“ halbherzig umsetzt und sich als Chef maßgeblich an der Pizza beteiligt.
Finde das offen gesagt ein schwieriges Thema…
Als Entwickler ist es einfach eine doofe Situation, wenn der Chef rein kommt, fragt wer den Fehler XY verursacht hat, der jenige sich dann vor dem ganzen Team outen muss, irgendwie den Fehler direkt beheben muss, obwohl er selbst mit der Situation noch viel zu überfordert ist (durch die „Demütigung“ und den Druck verursacht) und dann schließlich danach direkt noch zum Chef ins Büro kann, um sich dort für sein Handeln zu rechtfertigen, dass er selbst nie gewollt hat und entsprechend eine Rechtfertigung natürlich schwer fällt.
Abgesehen davon gibt es natürlich auch noch das Problem, dass oft gar nicht ein Entwickler alleine Schuld ist und oft DER SCHULDIGE gar nicht existiert.
Ich denke die beste Lösung ist entweder, dass (gleichberechtigte) Team das Problem selbst intern lösen zu lassen oder, sofern dies nicht möglich ist, der Chef eher als Helfer ran geht und demjenigen dabei hilft, in Zukunft solche Fehler zu vermeiden, als ihn dafür zu strafen. Ich denke nicht, dass durch zu „lasches“ Verhalten vom Chef die Qualität abnimmt, denn der „normale“ Entwickler ist ja eh so veranlagt, dass er immer besser werden will und seine Qualität verbessern will.
@Ralf: Deinen Eintrag finde ich absolut falsch, wenn man ein Team aus Leuten hat, die mit Freude entwickeln und selbst hohe Qualitätsansprüche haben. Da hast du bald keine Leute mehr, die noch Spaß an ihrer Arbeit haben. Aus meiner Sicht geht das genau gegen die Aussage aller Anderen hier.
Viel besser ist wirklich die Gründe für das Problem zu identifizieren (das ist nur selten eine einzige Person) und die Gründe liegen nur sehr selten darin, dass es jemand verbocken wollte bzw. sich keine Mühe gibt.
Hier ist übrigens der einzige Punkt bei dem man dir etwas zustimmen kann und aufpassen muss. Hat man Leute im Team die einfach keinen Bock auf das haben, was sie machen oder ähnliches, hilft weder Freundlichkeit und Verständnis noch das Gegenteil. Da muss man dann sehen was generell schief läuft.
@Steffen: 100% Zustimmung! Besser kann man es nicht sagen!
Noch ein Zitat das ich neulich gelesen habe: „It’s always better to be loved than to be feared“.
Das gilt generell im Umgang mit anderen Menschen, von böswilligen Ausnahmen mal abgesehen.
@Julian: Es wäre schön wenn alle Mitarbeiter immer hoch motiviert an die Arbeit gehen. Ich würde auch alles stehen und liegen lassen, bekäme ich ein Stellenangebot in einer Firma wo alle Mitarbeiter 24/7 an 365 Tagen im Jahr hoch motiviert an die Arbeit gehen.
In meinen 25 Jahren Berufserfahrung durfte ich aber feststellen das dies immer Wunschvorstellungen sind. Es gibt zahlreiche Faktoren die selbst den höchst motiviertesten Mitarbeiter irgendwann mal klein kriegen. Und sei es nur der Faktor Menschlichkeit der dazu führt das jemand einen schlechten Tag hat.
Das dies alles nicht so ist, oft gar nicht so sein kann, siehst du an der Aussage von Nils. Er verlangt von den Chefs immer in jeder Situation sachlich und gelassen zu bleiben. Bekommt aber selber „so einen Hals“ wenn es nicht so ist.
@Ralf: Klar, das möchte ich auch keinesfalls bestreiten, ich zweifle ja lediglich an, dass „meckern“ oder gar strafen dann etwas verbessert.
Es hängt auch immer sehr von den Beteiligten und der Situation ab. Außerdem ist auch der Chef nur ein Mensch, keine Frage!
Bei mir persönlich weiß ich aber, dass etwas Verständnis und konstruktive Kritik weitaus mehr bringt, als meckern. Oft weiß man allein durch das Auftreten des Problems, dass man etwas falsch gemacht hat und ärgert sich bei seinem Anspruch darüber. Geht mir zumindest so.
Da ist die „Selbstbestrafung“ im Kopf meist sogar schlimmer als der Ärger von außen, der macht aber auch nichts besser, im Gegenteil.
Zusammengefasst also meine Aussage: Aus Fehlern lernen und Prozesse/Strukturen aufbauen, die Fehler vermeiden oder zumindest dabei helfen, sie qualitativ und nachhaltig zu beheben, wenn sie trotzdem auftreten.
Nachdem ich alle Posts gelesen habe, würde ich ganz gerne in Svens Firma arbeiten. So war es bei uns früher auch; das Ergebnis zählte; die Teams funktionierten und die Firma wuchs.
Aber seit es ein bisschen krieselt, ist es eher so das ehemalige Teamplayer schnell mit dem Finger auf denjenigen zeigen, der Schuld an einem Problem ist. Wer in der richtigen Position ist, übernimmt die Aufgaben, die schwer zu verbocken oder das Ergebnis nicht meßbar ist. Riskante Aufgaben werden dann auch noch an den Entwickler vergeben, der sich am wenigsten wehren kann.
Stellt sich mir die Frage, ob diese Situation wieder umkehrbar ist ?
@Nils: Sieht gerade so aus als gebe es Bedarf für eine Bewertung anderer Beiträge, vielleicht wie bei Stackoverflow, wenn das nicht patentiert ist ?
P.S. Was ich noch vergessen habe. Man kennt mich ja hier nicht. PHP ist nur mein Hobby. Die Firma die ich beschrieben habe, macht RIAs mit Java oder VB.