Ich arbeite in einer kleinen Softwarefirma. Wir sind ziemlich klein mit nur 3-4 Vollzeit-Entwicklern. Ich habe dort vor ca. 8 Jahren als studentische Hilfskraft angefangen und nach meinem Masterabschluss in Informatik Vollzeit gearbeitet.
Meine Kollegen und ich haben mehr als einmal verschiedene Richtlinien vorgeschlagen, wie wir denken, dass wir den Entwicklungsprozess verbessern könnten (z. B. Codestil, Codeüberprüfungen usw.). Wir haben diese Vorschläge im Team diskutiert und uns geeinigt. Auch unser Chef, der ab und zu auch Entwicklungsarbeit leistet, hatte sich darauf geeinigt und es als offizielle Firmenrichtlinie eingeführt. Allerdings ignoriert er diese Richtlinien dann oft. ZB wird Code ohne Codeüberprüfung übergeben, der mehr als einmal einen Build-Break verursacht hat. Darauf angesprochen sagt er entweder, es sei keine große Sache und nimmt die Beschwerde nicht ernst oder er ist beleidigt (wir haben eine recht familiäre Atmosphäre in der Firma).
Das stört mich sehr, weil ich finde, dass Softwareentwicklung nicht so funktionieren sollte und finde es auch respektlos. Schließlich ist er aber der Boss. Außerdem sieht es so aus, als ob ich der Einzige bin, der das wirklich nervig findet. Ab und zu beschweren sich auch meine Kollegen über ihn, aber sie sprechen selten mit ihm darüber. Für ihn könnte es also so aussehen, als ob ich der Einzige bin, der sich beschwert. Ich denke auch, dass es nicht möglich ist, meine Kollegen davon zu überzeugen, mit ihm darüber zu sprechen, da es für sie keine so große Sache zu sein scheint.
Was könnte ich dagegen tun? Ist es mein Chef, der sich falsch verhält oder bin ich zu wählerisch?
Versuchen Sie, das Problem anders zu betrachten.
1: Dir fehlt an manchen Stellen Code-Review. 2: Sie wissen, dass jemand Ihre Builds beschädigt, indem er die Codequalität ignoriert.
In meinem Team haben wir automatische Builds eingerichtet und viel mehr getestet. Dies gibt uns das visuelle grüne Feedback „Alle Tests bestanden“ und rot, wenn jemand etwas vermasselt hat. Dies löst 1. in den meisten Fällen, weil jeder die nicht bestandenen Tests lösen möchte.
Für 2. können Sie damit beginnen, Commits automatisch abzulehnen, die einen Build beschädigen. Wenn dies ein Problem für den Chef ist, haben Sie Argumente für gespartes Geld bei der Entwicklungsgeschwindigkeit und stabilere Dienste für Ihre Benutzer.
Wenn Sie diese Schritte umgesetzt haben und immer noch scheitern, gibt es viele andere Jobs für Sie da draußen. Verbringen Sie Ihre Energie nicht dort, wo Ihre Stimme keine Rolle spielt.
Du bist nicht zu wählerisch, du hast Recht, aber er ist der Boss. Ihr Entwickler tragt die Hauptlast der Arbeit, aber unterm Strich ist es seine Sache, wenn es Probleme gibt. Sie tun also, was Sie können, um dagegen vorzugehen, Sie wiederholen die Wichtigkeit. Und wenn er es missachtet, reparierst du es. Das ist dein Job.
Die Aufgabe des Chefs besteht darin, sicherzustellen, dass Sie an jedem Zahltag bezahlt werden.
Wenden Sie sich mit dem Problem an den Chef und erklären Sie, dass Sie versuchen, es zu beheben, und weitere Informationen benötigen. Stellen Sie viele Fragen, damit Sie seine Motivation für das Schreiben des Codes verstehen, auch wenn Sie wissen, wie man ihn behebt. Vielleicht erfahren Sie ein oder zwei Dinge darüber, warum er das so gemacht hat. Und dann den Fehler beheben. Und dokumentieren Sie es dann in Ihrem Wochenbericht.
Wenn sich der Chef wirklich um die Teamleistung kümmert, wird er erkennen, dass seine Prozessverletzungen dazu führen, dass Sie zusätzliche Zeit damit verbringen, seine Fehler zu beheben, anstatt Ihre eigene Arbeit zu erledigen, und dass er seine Zeit damit verschwendet, Ihnen seinen Code so zu erklären dass Sie seinen Fehler beheben können. An diesem Punkt wird er wahrscheinlich entweder weniger programmieren oder dem Prozess besser folgen.
Wenn er sich nicht um die Teamleistung kümmert, dann machen Sie zumindest einige Fortschritte, indem Sie seine Sachen reparieren, anstatt wegen kaputter Builds keine Fortschritte zu machen.
Stephan Branczyk
Grimm der Opiner